idnits 2.17.1 draft-ietf-idr-autosys-guide-03.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-20) 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. ** 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: ---------------------------------------------------------------------------- == Line 445 has weird spacing: '...rotocol forma...' -- 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 (May 1995) is 10568 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'RIPE-109' ** Obsolete normative reference: RFC 1654 (ref. 'BGP-4') (Obsoleted by RFC 1771) ** Downref: Normative reference to an Historic RFC: RFC 904 (ref. 'EGP') -- Possible downref: Non-RFC (?) normative reference: ref. 'IDRP' ** Obsolete normative reference: RFC 1519 (ref. 'CIDR') (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1583 (ref. 'OSPF') (Obsoleted by RFC 2178) -- Possible downref: Normative reference to a draft: ref. 'ISIS' Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 5 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: Standards Track T. Bates 4 MCI 5 May 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. Common 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 .......................................... 8 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. Reserved AS Numbers .................................... 10 67 11. Security Considerations ................................ 10 69 12. Acknowledgments ........................................ 10 71 13. References ............................................. 10 73 14. Authors' Addresses ..................................... 12 75 1. Introduction 77 This memo discusses when it is appropriate to register and util- 78 ize an Autonomous System (AS), and lists criteria for such. ASes 79 are the unit of routing policy in the modern world of exterior 80 routing, and are specifically applicable to protocols like EGP 81 (Exterior Gateway Protocol, now at historical status; see [EGP]), 82 BGP (Border Gateway Protocol, the current de facto standard for 83 inter-AS routing; see [BGP-4]), and IDRP (The OSI Inter-Domain 84 Routing Protocol, which the Internet will eventually adopt when 85 BGP becomes obsolete; see [IDRP]). It should be noted that the 86 IDRP equivalent of an AS is the RDI, or Routing Domain Identif- 87 ier. 89 2. Motivation 91 This memo is aimed at network operators and service providers who 92 need to understand under what circumstances they should make use 93 of an AS. It is expected that the reader is familiar with routing 94 protocols and will be someone who configures and operates Inter- 95 net networks. Unfortunately, there is a great deal of confusion 96 in how ASes should be used today; this memo attempts to clear up 97 some of this confusion, as well as acting as a simple guide to 98 today's exterior routing. 100 3. Definitions 102 This document refers to the term ``prefix'' throughout. In the 103 current classless Internet (see [CIDR]), a block of class A, B, 104 or C networks may be referred to by merely a prefix and a mask, 105 so long as such a block of networks begins and ends on a power- 106 of-two boundary. For example, the networks: 108 192.168.0.0/24 109 192.168.1.0/24 110 192.168.2.0/24 111 192.168.3.0/24 113 can be simply referred to as: 115 192.168.0.0/22 117 The term ``prefix'' as it is used here is equivalent to ``CIDR 118 block'', and in simple terms may be thought of as a group of one 119 or more networks. We use the term ``network'' to mean classful 120 network, or ``A, B, C network''. 122 The definition of AS has been unclear and ambiguous for some 123 time. [BGP-4] states: 125 The classic definition of an Autonomous System is a set of 126 routers under a single technical administration, using an inte- 127 rior gateway protocol and common metrics to route packets within 128 the AS, and using an exterior gateway protocol to route packets 129 to other ASes. Since this classic definition was developed, it 130 has become common for a single AS to use several interior 131 gateway protocols and sometimes several sets of metrics within 132 an AS. The use of the term Autonomous System here stresses the 133 fact that, even when multiple IGPs and metrics are used, the 134 administration of an AS appears to other ASes to have a single 135 coherent interior routing plan and presents a consistent picture 136 of what networks are reachable through it. 138 To rephrase succinctly: 140 An AS is a connected group of IP networks run by one or more 141 network operators which has a SINGLE and CLEARLY DEFINED routing 142 policy. 144 Routing policy here is defined as how routing decisions are made in 145 the Internet today. It is the exchange of routing information 146 between ASes that is subject to routing policies. Consider the case 147 of two ASes, X and Y exchanging routing information: 149 NET1 ...... ASX <---> ASY ....... NET2 151 ASX knows how to reach a prefix called NET1. It does not matter 152 whether NET1 belongs to ASX or to some other AS which exchanges rout- 153 ing information with ASX, either directly or indirectly; we just 154 assume that ASX knows how to direct packets towards NET1. Likewise 155 ASY knows how to reach NET2. 157 In order for traffic from NET2 to NET1 to flow between ASX and ASY, 158 ASX has to announce NET1 to ASY using an exterior routing protocol; 159 this means that ASX is willing to accept traffic directed to NET1 160 from ASY. Policy comes into play when ASX decides to announce NET1 to 161 ASY. 163 For traffic to flow, ASY has to accept this routing information and 164 use it. It is ASY's privilege to either use or disregard the infor- 165 mation that it receives from ASX about NET1's reachability. ASY might 166 decide not to use this information if it does not want to send 167 traffic to NET1 at all or if it considers another route more 168 appropriate to reach NET1. 170 In order for traffic in the direction of NET1 to flow between ASX and 171 ASY, ASX must announce that route to ASY and ASY must accept it from 172 ASX: 174 resulting packet flow towards NET1 175 <<=================================== 176 | 177 | 178 announce NET1 | accept NET1 179 --------------> + -------------> 180 | 181 AS X | AS Y 182 | 183 <------------- + <-------------- 184 accept NET2 | announce NET2 185 | 186 | 187 resulting packet flow towards NET2 188 ===================================>> 190 Ideally, though seldom practically, the announcement and acceptance 191 policies of ASX and ASY are identical. 193 In order for traffic towards NET2 to flow, announcement and accep- 194 tance of NET2 must be in place (mirror image of NET1). For almost all 195 applications connectivity in just one direction is not useful at all. 197 It should be noted that, in more complex topologies than this exam- 198 ple, traffic from NET1 to NET2 may not necessarily take the same path 199 as traffic from NET2 to NET1; this is called asymmetrical routing. 200 Asymmetrical routing is not inherently bad, but can often cause per- 201 formance problems for higher level protocols, such as TCP, and should 202 be used with caution. 204 It is important to realise that with current destination based for- 205 warding technology routing policies must eventually be expressed in 206 these terms. 208 Policies are not configured for each prefix separately but for groups 209 of prefixes. These groups of prefixes are ASes. 211 An AS has a globally unique number (sometimes referred to as an ASN, 212 or Autonomous System Number) associated with it; this number is used 213 in both the exchange of exterior routing information (between neigh- 214 boring ASes), and as an identifier of the AS itself. 216 In routing terms, an AS will normally use one or more interior gate- 217 way protocols (IGPs) when exchanging reachability information within 218 its own AS. See ``IGP Issues''. 220 4. Common errors in allocating ASes 222 The term AS is often confused or even misused as a convenient way of 223 grouping together a set of prefixes which belong under the same 224 administrative umbrella, even if within that group of prefixes there 225 are various different routing policies. Without exception, an AS must 226 have only one routing policy. 228 It is essential that careful consideration and coordination be 229 applied during the creation of an AS. Using an AS merely for the sake 230 of having an AS is to be avoided, as is the worst-case scenario of 231 one AS per classful network (the IDEAL situation is to have one pre- 232 fix, containing many networks, per AS). This may mean that some re- 233 engineering may be required in order to apply the criteria and guide- 234 lines for creation and allocation of an AS that we list below; 235 nevertheless, doing so is probably the only way to implement the 236 desired routing policy. 238 If you are currently engineering an AS, careful thought should be 239 taken to register appropriately sized CIDR blocks with your registra- 240 tion authority in order to minimize the number of advertised prefixes 241 from your AS. In the perfect world that number can, and should, be 242 as low as one. 244 Some router implementations use an AS number as a form of tagging to 245 identify interior as well as exterior routing processes. This tag 246 does not need to be unique unless routing information is indeed 247 exchanged with other ASes. See ``IGP Issues''. 249 5. Criteria for the decision -- do I need an AS? 251 * Exchange of external routing information 253 An AS must be used for exchanging external routing information 254 with other ASes through an exterior routing protocol. The 255 current recommended exterior routing protocol is BGP, the Border 256 Gateway Protocol. However, the exchange of external routing 257 information alone does not constitute the need for an AS. See 258 ``Sample Cases'' below. 260 * Many prefixes, one AS 262 As a general rule, one should try to place as many prefixes as 263 possible within a given AS, provided all of them conform to the 264 same routing policy. 266 * Unique routing policy 268 An AS is only needed when you have a routing policy which is 269 different from that of your border gateway peers. Here routing 270 policy refers to how the rest of the Internet makes routing 271 decisions based on information from your AS. See ``Sample 272 Cases'' below to see exactly when this criteria will apply. 274 5.1 Sample Cases 276 * Single-homed site, single prefix 278 A separate AS is not needed; the prefix should be placed in an 279 AS of the provider. The site's prefix has exactly the same rout- 280 ing policy as the other customers of the site's service pro- 281 vider, and there is no need to make any distinction in routing 282 information. 284 This idea may at first seem slightly alien to some, but it 285 highlights the clear distinction in the use of the AS number as 286 a representation of routing policy as opposed to some form of 287 administrative use. 289 In some situations, a single site, or piece of a site, may find 290 it necessary to have a policy different from that of its pro- 291 vider, or the rest of the site. In such an instance, a separate 292 AS must be created for the affected prefixes. This situation is 293 rare and should almost never happen. Very few stub sites require 294 different routing policies than their parents. Because the AS is 295 the unit of policy, however, this sometimes occurs. 297 * Single-homed site, multiple prefixes 299 Again, a separate AS is not needed; the prefixes should be 300 placed in an AS of the site's provider. 302 * Multi-homed site 304 Here multi-homed is taken to mean a prefix or group of prefixes 305 which connects to more than one service provider (i.e. more than 306 one AS with its own routing policy). It does not mean a network 307 multi-homed running an IGP for the purposes of resilience. 309 An AS is required; the site's prefixes should be part of a 310 single AS, distinct from the ASes of its service providers. 311 This allows the customer the ability to have a different 312 representation of policy and preference among the different ser- 313 vice providers. 315 This is ALMOST THE ONLY case where a network operator should 316 create its own AS number. In this case, the site should ensure 317 that it has the necessary facilities to run appropriate routing 318 protocols, such as BGP4. 320 5.2 Other factors 322 * Topology 324 Routing policy decisions such as geography, AUP (Acceptable Use 325 Policy) compliance and network topology can influence decisions 326 of AS creation. However, all too often these are done without 327 consideration of whether or not an AS is needed in terms of 328 adding additional information for routing policy decisions by 329 the rest of the Internet. Careful consideration should be taken 330 when basing AS creation on these type of criteria. 332 * Transition / ``future-proofing'' 334 Often a site will be connected to a single service provider but 335 has plans to connect to another at some point in the future. 336 This is not enough of a reason to create an AS before you really 337 need it. The AS number space is finite and the limited amount 338 of re-engineering needed when you connect to another service 339 provider should be considered as a natural step in transition. 341 * History 343 AS number application forms have historically made no reference 344 to routing policy. All too often ASes have been created purely 345 because it was seen as ``part of the process'' of connecting to 346 the Internet. The document should act as reference to future 347 application forms to show clearly when an AS is needed. 349 6. Speculation 351 1) If provider A and provider B have a large presence in a 352 geographical area (or other routing domain), and many customers are 353 multi-homed between them, it makes sense for all of those customers 354 to be placed within the same AS. However, it is noted that case 355 should only be looked at if practical to do so and fully coordinated 356 between customers and service providers involved. 358 2) Sites should not be forced to place themselves in a separate AS 359 just so that someone else (externally) can make AS-based policy deci- 360 sions. Nevertheless, it may occasionally be necessary to split up an 361 AS or a prefix into two ASes for policy reasons. Those making exter- 362 nal policy may request the network operators make such AS changes, 363 but the final decision is up to those network operators who manage 364 the prefixes in question, as well as the ASes containing them. This 365 is, of course, a trade off -- it will not always be possible to 366 implement all desired routing policies. 368 7. One prefix, one origin AS 370 Generally, a prefix can should belong to only one AS. This is a 371 direct consequence of the fact that at each point in the Internet 372 there can be exactly one routing policy for traffic destined to each 373 prefix. In the case of an prefix which is used in neighbor peering 374 between two ASes, a conscious decision should be made as to which AS 375 this prefix actually resides in. 377 With the introduction of aggregation it should be noted that an AS 378 can occasionally be represented as residing in more than one AS, how- 379 ever, this is very much the exception rather than the rule. This hap- 380 pens when aggregating using the AS_SET attribute in BGP, wherein the 381 concept of origin is lost. In some cases the origin AS is lost alto- 382 gether if there is a less specific aggregate announcement setting the 383 ATOMIC_AGGREGATE attribute. 385 8. IGP Issues 387 As stated above, many router vendors require an identifier for tag- 388 ging their IGP processes. However, this tag does not need to be glo- 389 bally unique. In practice this information is never seen by exterior 390 routing protocols. If already running an exterior routing protocol, 391 it is perfectly reasonable to use your AS number as an IGP tag; if 392 you do not, choosing from the reserved range is also acceptable (see 393 ``Reserved AS Numbers''). Merely running an IGP is not grounds for 394 registration of an AS number. 396 With the advent of BGP4 it becomes necessary to use an IGP that can 397 carry classless routes. Examples include OSPF [OSPF] and ISIS [ISIS]. 399 9. AS Space exhaustion 401 The AS number space is a finite amount of address space. It is 402 currently defined as a 16 bit integer and hence limited to 65535 403 unique AS numbers. At the time of writing some 5,100 ASes have been 404 allocated and a little under 600 ASes are actively routed in the glo- 405 bal Internet. It is clear that this growth needs to be continually 406 monitored. However, if the criteria applied above are adhered to, 407 then there is no immediate danger of AS space exhaustion. It is 408 expected that IDRP will be deployed before this becomes an issue. 409 IDRP does not have a fixed limit on the size of an RDI. 411 10. Reserved AS Numbers 413 The Internet Assigned Numbers Authority (IANA) has reserved the fol- 414 lowing block of AS numbers for private use (not to be advertised on 415 the global Internet): 417 64512 through 65535 419 11. Security Considerations 421 There are few security concerns regarding the selection of ASes. 423 AS number to owner mappings are public knowledge (in WHOIS), and 424 attempting to change that would serve only to confuse those people 425 attempting to route IP traffic on the Internet. 427 12. Acknowledgments 429 This document is largely based on [RIPE-109], and is intended to have 430 a wider scope than purely the RIPE community; this document would not 431 exist without [RIPE-109]. 433 13. References 435 [RIPE-109] 436 Bates, T., Lord, A., "Autonomous System Number Application Form 437 & Supporting Notes", RIPE 109, RIPE NCC, 1 March 1994. 438 URL: ftp://ftp.ripe.net/ripe/docs/ripe-109.txt. 440 [BGP-4] 441 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 442 1654, T.J. Watson Research Center, cisco Systems, July 1994. 444 [EGP] 445 Mills, D. "Exterior Gateway Protocol formal specifications", RFC 446 904, STD 18, International Telegraph and Telephone Co., 1 April 447 1984. 449 [IDRP] 450 Kunzinger, C., Editor, "OSI Inter-Domain Routing Protocol (IDRP)", 451 ISO/IEC 10747, Work In Progress, October 1993. 453 [CIDR] 454 Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter-Domain 455 Routing (CIDR): an Address Assignment and Aggregation Strategy", 456 RFC 1519, BARRnet, cisco, MERIT, OARnet, September 1993. 458 [OSPF] 459 Moy, J., "OSPF Version 2", RFC 1583, March 1994. 461 [ISIS] 462 Callon, R., Gunner, C., "Use of OSI IS-IS for Routing in TCP/IP and 463 Multi-Protocol Environments", draft-ietf-isis-tcpip-01.txt, WORK IN 464 PROGRESS, July 1994. 466 14. Authors' Addresses 468 John Hawkinson 469 Panix 470 1200 Warburton Ave., Suite 57 471 Yonkers, NY 10701-1057 473 phone: +1 617 253 7788 474 email: jhawk@panix.com 476 Tony Bates 477 MCI 478 2100 Reston Parkway 479 Reston, VA 22094 481 phone: +1 703 715 7521 482 email: Tony.Bates@mci.net