idnits 2.17.1 draft-ietf-idr-autosys-guide-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([IDRP], [EGP], [BGP-4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 1995) is 10693 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1654 (ref. 'BGP-4') (Obsoleted by RFC 1771) ** Obsolete normative reference: RFC 1519 (ref. 'CIDR') (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1583 (ref. 'OSPF') (Obsoleted by RFC 2178) Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Hawkinson 2 INTERNET-DRAFT Panix 3 Category: Informational T. Bates 4 MCI 5 January 1995 7 Guidelines for creation, selection, and registration 8 of an Autonomous System (AS) 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 Abstract 30 This draft discusses when it is appropriate to register and utilize 31 an Autonomous System (AS), and lists criteria for such. ASes are the 32 unit of routing policy in the modern world of exterior routing, and 33 are specifically applicable to protocols like EGP (Exterior Gateway 34 Protocol, now at historical status; see [EGP]), BGP (Border Gateway 35 Protocol, the current de facto standard for inter-AS routing; see 36 [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the 37 Internet will eventually adopt when BGP becomes obsolete; see 38 [IDRP]). It should be noted that the IDRP equivalent of an AS is the 39 RDI, or Routing Domain Identifier. 41 Table of Contents 43 1. Introduction ............................................ 2 45 2. Motivation .............................................. 3 47 3. Definitions ............................................. 3 49 4. Commom errors in allocating ASes ........................ 6 51 5. Criteria for the decision -- do I need an AS? .......... 6 53 5.1 Sample Cases ........................................... 7 55 5.2 Other Factors .......................................... 7 57 6. Speculation ............................................. 8 59 7. One prefix, one origin AS ............................... 9 61 8. IGP issues .............................................. 9 63 9. AS Space exhaustion ..................................... 10 65 10. Security Considerations ................................ 10 67 11. Acknowledgments ........................................ 10 69 12. References ............................................. 11 71 13. Authors' Addresses ..................................... 12 73 1. Introduction 75 This memo discusses when it is appropriate to register and utilize an 76 Autonomous System (AS), and lists criteria for such. ASes are the 77 unit of routing policy in the modern world of exterior routing, and 78 are specifically applicable to protocols like EGP (Exterior Gateway 79 Protocol, now at historical status; see [EGP]), BGP (Border Gateway 80 Protocol, the current de facto standard for inter-AS routing; see 81 [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the 82 Internet will eventually adopt when BGP becomes obsolete; see 83 [IDRP]). It should be noted that the IDRP equivalent of an AS is the 84 RDI, or Routing Domain Identifier. 86 2. Motivation 88 This memo is aimed at network operators and service providers who need 89 to understand under what circumstances they should make use of an 90 AS. It is expected that the reader is familiar with routing protocols 91 and will be someone who configures and operates Internet 92 networks. Unfortunately, there is a great deal of confusion in how 93 ASes should be used today; this memo attempts to clear up some of this 94 confusion, as well as acting as a simple guide to today's exterior 95 routing. 97 3. Definitions 99 This document refers to the term ``prefix'' throughout. In the current 100 classless Internet (see [CIDR]), a block of class A, B, or C networks 101 may be referred to by merely a prefix and a mask, so long as such a 102 block of networks begins and ends on a power-of-two boundary. For 103 example, the networks: 105 192.168.0.0/24 106 192.168.1.0/24 107 192.168.2.0/24 108 192.168.3.0/24 110 can be simply referred to as: 112 192.168.0.0/22 114 The term ``prefix'' as it is used here is equivalent to ``CIDR 115 block'', and in simple terms may be thought of as a group of one 116 or more networks. We use the term ``network'' to mean classful 117 network, or ``A, B, C network''. 119 The definition of AS has been unclear and ambiguous for some 120 time. [BGP-4] states: 122 The classic definition of an Autonomous System is a set of 123 routers under a single technical administration, using an inte- 124 rior gateway protocol and common metrics to route packets within 125 the AS, and using an exterior gateway protocol to route packets 126 to other ASes. Since this classic definition was developed, it 127 has become common for a single AS to use several interior gate- 128 way protocols and sometimes several sets of metrics within an 129 AS. The use of the term Autonomous System here stresses the 130 fact that, even when multiple IGPs and metrics are used, the 131 administration of an AS appears to other ASes to have a single 132 coherent interior routing plan and presents a consistent picture 133 of what networks are reachable through it. 135 To rephrase succinctly: 137 An AS is a connected group of IP networks run by one or more 138 network operators which has a SINGLE and CLEARLY DEFINED routing 139 policy. 141 Routing policy here is defined as how routing decisions are made in 142 the Internet today. It is the exchange of routing information 143 between ASes that is subject to routing policies. Consider the case 144 of two ASes, X and Y exchanging routing information: 146 NET1 ...... ASX <---> ASY ....... NET2 148 ASX knows how to reach a prefix called NET1. It does not matter 149 whether NET1 belongs to ASX or to some other AS which exchanges rout- 150 ing information with ASX, either directly or indirectly; we just 151 assume that ASX knows how to direct packets towards NET1. Likewise 152 ASY knows how to reach NET2. 154 In order for traffic from NET2 to NET1 to flow between ASX and ASY, 155 ASX has to announce NET1 to ASY using an exterior routing protocol; 156 this means that ASX is willing to accept traffic directed to NET1 157 from ASY. Policy comes into play when ASX decides to announce NET1 to 158 ASY. 160 For traffic to flow, ASY has to accept this routing information and 161 use it. It is ASY's privilege to either use or disregard the infor- 162 mation that it receives from ASX about NET1's reachability. ASY might 163 decide not to use this information if it does not want to send 164 traffic to NET1 at all or if it considers another route more 165 appropriate to reach NET1. 167 In order for traffic in the direction of NET1 to flow between ASX and 168 ASY, ASX must announce that route to ASY and ASY must accept it from 169 ASX: 171 resulting packet flow towards NET1 172 <<=================================== 173 | 174 | 175 announce NET1 | accept NET1 176 --------------> + -------------> 177 | 178 AS X | AS Y 179 | 180 <------------- + <-------------- 181 accept NET2 | announce NET2 182 | 183 | 184 resulting packet flow towards NET2 185 ===================================>> 187 Ideally, and seldom practically, the announcement and acceptance pol- 188 icies of ASX and ASY are identical. 190 In order for traffic towards NET2 to flow, announcement and accep- 191 tance of NET2 must be in place (mirror image of NET1). For almost all 192 applications connectivity in just one direction is not useful at all. 194 It should be noted that, in more complex topologies than this exam- 195 ple, traffic from NET1 to NET2 may not necessarily take the same path 196 as traffic from NET2 to NET1; this is called asymmetrical routing. 197 Asymmetrical routing is not inherently bad, but can often cause per- 198 formance problems for higher level protocols, such as TCP, and should 199 be used with caution. 201 It is important to realise that with current destination based for- 202 warding technology routing policies must eventually be expressed in 203 these terms. 205 Policies are not configured for each prefix separately but for groups 206 of prefixes. These groups of prefixes are ASes. 208 An AS has a globally unique number (sometimes referred to as an ASN, 209 or Autonomous System Number) associated with it; this number is used 210 in both the exchange of exterior routing information (between neigh- 211 boring ASes), and as an identifier of the AS itself. 213 In routing terms, an AS will normally use one or more interior gate- 214 way protocols (IGPs) when exchanging reachability information within 215 its own AS. See ``IGP Issues''. 217 4. Common errors in allocating ASes 219 The term AS is often confused or even misused as a convenient way of 220 grouping together a set of prefixes which belong under the same 221 administrative umbrella, even if within that group of prefixes there 222 are various different routing policies. Without exception, an AS must 223 have only one routing policy. 225 It is essential that careful consideration and coordination be 226 applied during the creation of an AS. Using an AS merely for the sake 227 of having an AS is to be avoided, as is the worst-case scenario of 228 one AS per classful network (the IDEAL situation is to have one pre- 229 fix, containing many networks, per AS). This may mean that some re- 230 engineering may be required in order to apply the criteria and guide- 231 lines for creation and allocation of an AS that we list below; 232 nevertheless, doing so is probably the only way to implement the 233 desired routing policy. 235 If you are currently engineering an AS, careful thought should be 236 taken to register appropriately sized CIDR blocks with your registra- 237 tion authority in order to minimize the number of advertised prefixes 238 from your AS. In the perfect world that number can , and should, be 239 as low as one. 241 Some router implementations use an AS number as a form of tagging to 242 identify interior as well as exterior routing processes. This tag 243 does not need to be unique unless routing information is indeed 244 exchanged with other ASes. See ``IGP Issues''. 246 5. Criteria for the decision -- do I need an AS? 248 * Exchange of external routing information 250 An AS must be used for exchanging external routing information 251 with other ASes through an exterior routing protocol. The 252 current recommended exterior routing protocol is BGP, the Border 253 Gateway Protocol. However, the exchange of external routing 254 information alone does not constitute the need for an AS. See 255 ``Sample Cases'' below. 257 * Many prefixes, one AS 259 As a general rule, one should try to place as many prefixes as 260 possible within a given AS, provided all of them conform to the 261 same routing policy. 263 * Unique routing policy 265 As AS is only needed when you have a routing policy which is 266 different from that of your border gateway peers. Here routing 267 policy refers to how the rest of the Internet makes routing 268 decisions based on information from your AS. See ``Sample 269 Cases'' below to see exactly when this criteria will apply. 271 5.1 Sample Cases 273 * Single-homed site, single prefix 275 A separate AS is not needed; the prefix should be placed in an 276 AS of the provider. The site's prefix has exactly the same rout- 277 ing policy as the other customers of the site's service pro- 278 vider, and there is no need to make any distinction in routing 279 information. 281 This idea may at first seem slightly alien to some, but it 282 highlights the clear distinction in the use of the AS number as 283 a representation of routing policy as opposed to some form of 284 administrative use. 286 In some situations, a single site, or piece of a site, may find 287 it necessary to have a policy different from that of its pro- 288 vider, or the rest of the site. In such an instance, a separate 289 AS must be created for the affected prefixes. This situation is 290 rare and should almost never happen. Very few stub sites require 291 different routing policies than their parents. Because the AS is 292 the unit of policy, however, this sometimes occurs. 294 * Single-homed site, multiple prefixes 296 Again, a separate AS is not needed; the prefixes should be 297 placed in an AS of the site's provider. 299 * Multi-homed site 301 Here multi-homed is taken to mean a prefix or group of prefixes 302 which connects to more than one service provider (i.e. more than 303 one AS with its own routing policy). It does not mean a network 304 multi-homed running an IGP for the purposes of resilience. 306 An AS is required; the site's prefixes should be part of a 307 single AS, distinct from the ASes of its service providers. 308 This allows the customer the ability to have a different 309 representation of policy and preference among the different ser- 310 vice providers. 312 This is ALMOST THE ONLY case where a network operator should 313 create its own AS number. In this case, the site should ensure 314 that it has the necessary facilities to run appropriate routing 315 protocols, such as BGP4. 317 5.2 Other factors 319 * Topolgy 321 Routing policy decisions such as geography, AUP (Acceptable Use 322 Policy) compliance and network topology can influence decisions 323 of AS creation. However, all too often these are done without 324 consideration of whether or not an AS is needed in terms of 325 adding additional information for routing policy decisions by 326 the rest of the Internet. Careful consideration should be taken 327 when basing AS creation on these type of criteria. 329 * Transition / ``future-proofing'' 331 Often a site will be connected to a single service provider but 332 has plans to connect to another at some point in the future. 333 This is not enough of a reason to create an AS before you really 334 need it. The AS number space is finite and the limited amount 335 of re-engineering needed when you connect to another service 336 provider should be considered as a natural step in transition. 338 * History 340 AS number application forms have historically made no reference 341 to routing policy. All too often ASes have been created purely 342 because it was seen as ``part of the process'' of connecting to 343 the Internet. The document should act as reference to future 344 application forms to show clearly when an AS is needed. 346 6. Speculation 348 1) If provider A and provider B have a large presence in a 349 geographical area (or other routing domain), and many customers are 350 multi-homed between them, it makes sense for all of those customers 351 to be placed within the same AS. However, it is noted that case 352 should only be looked at if practical to do so and fully coordinated 353 between customers and service providers involved. 355 2) Sites should not be forced to place themselves in a separate AS 356 just so that someone else (externally) can make AS-based policy deci- 357 sions. Nevertheless, it may occasionally be necessary to split up an 358 AS or a prefix into two ASes for policy reasons. Those making exter- 359 nal policy may request the network operators make such AS changes, 360 but the final decision is up to those network operators who manage 361 the prefixes in question, as well as the ASes containing them. This 362 is, of course, a trade off -- it will not always be possible to 363 implement all desired routing policies. 365 7. One prefix, one origin AS 367 A prefix can and must belong to only one AS. This is a direct conse- 368 quence of the fact that at each point in the Internet there can be 369 exactly one routing policy for traffic destined to each prefix. In 370 the case of an prefix which is used in neighbor peering between two 371 ASes, a conscious decision must be made as to which AS this prefix 372 actually resides in. 374 With the introduction of aggregation it should be noted that an AS 375 can occasionally be represented as residing in more than one AS, how- 376 ever, this is very much the exception rather than the rule. This hap- 377 pens when aggregating using the AS_SET attribute in BGP, wherein the 378 concept of origin is lost. In some cases the origin AS is lost alto- 379 gether if there is a less specific aggregate announcement setting the 380 ATOMIC_AGGREGATE attribute. 382 8. IGP Issues 384 As stated above, many router vendors require an identifier for tag- 385 ging their IGP processes. However, this tag does not need to be glo- 386 bally unique. In practice this information is never seen by exterior 387 routing protocols. If already running an exterior routing protocol, 388 it is perfectly reasonable to use your AS number as an IGP tag; if 389 you do not, choosing a random value is acceptable. Merely running an 390 IGP is not grounds for registration of an AS number. 392 With the advent of BGP4 it becomes necessary to use an IGP that can 393 carry classless routes. Examples include OSPF [OSPF] and ISIS [ISIS]. 395 9. AS Space exhaustion 397 The AS number space is a finite amount of address space. It is 398 currently defined as a 16 bit integer and hence limited to 65535 399 unique AS numbers. At the time of writing some 3,700 ASes have been 400 allocated and a little under 400 ASes are actively routed in the glo- 401 bal Internet. It is clear that this growth needs to be continually 402 monitored. However, if the criteria applied above are adhered to, 403 then there is no immediate danger of AS space exhaustion. It is 404 expected that IDRP will be deployed before this becomes an issue. 405 IDRP does not have a fixed limit on the size of an RDI. 407 10. Security Considerations 409 There are few security concerns regarding the selection of ASes. 411 AS number to owner mappings are public knowledge (in WHOIS), and 412 attempting to change that would serve only to confuse those people 413 attempting to route IP traffic on the Internet. 415 11. Acknowledgments 417 This document is largely based on [RIPE-109], and is intended to have 418 a wider scope than purely the RIPE community; this document would not 419 exist without [RIPE-109]. 421 12. References 423 [RIPE-109] 424 Bates, T., Lord, A., "Autonomous System Number Application Form 425 & Supporting Notes", RIPE 109, RIPE NCC, 1 March 1994. 426 URL: ftp://ftp.ripe.net/ripe/docs/ripe-109.txt. 428 [BGP-4] 429 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 430 RFC 1654, T.J. Watson Research Center, cisco Systems, July 1994. 432 [EGP] 433 Mills, D. "Exterior Gateway Protocol formal specifications", RFC 434 904, STD 18, International Telegraph and Telephone Co., 1 April 435 1984. 437 [IDRP] 438 Kunzinger, C., Editor, "OSI Inter-Domain Routing Protocol 439 (IDRP)", ISO/IEC 10747, Work In Progress, October 1993. 441 [CIDR] 442 Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter- 443 Domain Routing (CIDR): an Address Assignment and Aggregation 444 Strategy", RFC 1519, BARRnet, cisco, MERIT, OARnet, September 445 1993. 447 [OSPF] 448 Moy, J., "OSPF Version 2", RFC 1583, March 1994. 450 [ISIS] 451 Callon, R., Gunner, C., "Use of OSI IS-IS for Routing in TCP/IP 452 and Multi-Protocol Environments", draft-ietf-isis-tcpip-01.txt, 453 WORK IN PROGRESS, July 1994. 455 13. Authors' Addresses 457 John Hawkinson 458 Panix 459 1200 Warburton Ave., Suite 57 460 Yonkers, NY 10701-1057 461 USA 463 phone: +1 617 253 7788 464 email: jhawk@panix.com 466 Tony Bates 467 MCI 468 2100 Reston Parkway 469 Reston, VA 22094 471 phone: +1 703 715 7521 472 email: Tony.Bates@mci.net