idnits 2.17.1 draft-ietf-idr-autosys-guide-02.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-27) 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 (February 1995) is 10664 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. -------------------------------------------------------------------------------- 2 Network Working Group J. Hawkinson 3 INTERNET-DRAFT Panix 4 Category: Informational T. Bates 5 MCI 6 February 1995 8 Guidelines for creation, selection, and registration 9 of an Autonomous System (AS) 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 Abstract 31 This draft discusses when it is appropriate to register and utilize 32 an Autonomous System (AS), and lists criteria for such. ASes are the 33 unit of routing policy in the modern world of exterior routing, and 34 are specifically applicable to protocols like EGP (Exterior Gateway 35 Protocol, now at historical status; see [EGP]), BGP (Border Gateway 36 Protocol, the current de facto standard for inter-AS routing; see 37 [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the 38 Internet will eventually adopt when BGP becomes obsolete; see 39 [IDRP]). It should be noted that the IDRP equivalent of an AS is the 40 RDI, or Routing Domain Identifier. 42 Table of Contents 44 1. Introduction ............................................ 2 46 2. Motivation .............................................. 3 48 3. Definitions ............................................. 3 50 4. Commom errors in allocating ASes ........................ 6 52 5. Criteria for the decision -- do I need an AS? .......... 6 54 5.1 Sample Cases ........................................... 7 56 5.2 Other Factors .......................................... 7 58 6. Speculation ............................................. 8 60 7. One prefix, one origin AS ............................... 9 62 8. IGP issues .............................................. 9 64 9. AS Space exhaustion ..................................... 10 66 10. Security Considerations ................................ 10 68 11. Acknowledgments ........................................ 10 70 12. References ............................................. 11 72 13. Authors' Addresses ..................................... 12 74 1. Introduction 76 This memo discusses when it is appropriate to register and utilize an 77 Autonomous System (AS), and lists criteria for such. ASes are the 78 unit of routing policy in the modern world of exterior routing, and 79 are specifically applicable to protocols like EGP (Exterior Gateway 80 Protocol, now at historical status; see [EGP]), BGP (Border Gateway 81 Protocol, the current de facto standard for inter-AS routing; see 82 [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the 83 Internet will eventually adopt when BGP becomes obsolete; see 84 [IDRP]). It should be noted that the IDRP equivalent of an AS is the 85 RDI, or Routing Domain Identifier. 87 2. Motivation 89 This memo is aimed at network operators and service providers who need 90 to understand under what circumstances they should make use of an 91 AS. It is expected that the reader is familiar with routing protocols 92 and will be someone who configures and operates Internet 93 networks. Unfortunately, there is a great deal of confusion in how 94 ASes should be used today; this memo attempts to clear up some of this 95 confusion, as well as acting as a simple guide to today's exterior 96 routing. 98 3. Definitions 100 This document refers to the term ``prefix'' throughout. In the current 101 classless Internet (see [CIDR]), a block of class A, B, or C networks 102 may be referred to by merely a prefix and a mask, so long as such a 103 block of networks begins and ends on a power-of-two boundary. For 104 example, the networks: 106 192.168.0.0/24 107 192.168.1.0/24 108 192.168.2.0/24 109 192.168.3.0/24 111 can be simply referred to as: 113 192.168.0.0/22 115 The term ``prefix'' as it is used here is equivalent to ``CIDR 116 block'', and in simple terms may be thought of as a group of one 117 or more networks. We use the term ``network'' to mean classful 118 network, or ``A, B, C network''. 120 The definition of AS has been unclear and ambiguous for some 121 time. [BGP-4] states: 123 The classic definition of an Autonomous System is a set of 124 routers under a single technical administration, using an inte- 125 rior gateway protocol and common metrics to route packets within 126 the AS, and using an exterior gateway protocol to route packets 127 to other ASes. Since this classic definition was developed, it 128 has become common for a single AS to use several interior gate- 129 way protocols and sometimes several sets of metrics within an 130 AS. The use of the term Autonomous System here stresses the 131 fact that, even when multiple IGPs and metrics are used, the 132 administration of an AS appears to other ASes to have a single 133 coherent interior routing plan and presents a consistent picture 134 of what networks are reachable through it. 136 To rephrase succinctly: 138 An AS is a connected group of IP networks run by one or more 139 network operators which has a SINGLE and CLEARLY DEFINED routing 140 policy. 142 Routing policy here is defined as how routing decisions are made in 143 the Internet today. It is the exchange of routing information 144 between ASes that is subject to routing policies. Consider the case 145 of two ASes, X and Y exchanging routing information: 147 NET1 ...... ASX <---> ASY ....... NET2 149 ASX knows how to reach a prefix called NET1. It does not matter 150 whether NET1 belongs to ASX or to some other AS which exchanges rout- 151 ing information with ASX, either directly or indirectly; we just 152 assume that ASX knows how to direct packets towards NET1. Likewise 153 ASY knows how to reach NET2. 155 In order for traffic from NET2 to NET1 to flow between ASX and ASY, 156 ASX has to announce NET1 to ASY using an exterior routing protocol; 157 this means that ASX is willing to accept traffic directed to NET1 158 from ASY. Policy comes into play when ASX decides to announce NET1 to 159 ASY. 161 For traffic to flow, ASY has to accept this routing information and 162 use it. It is ASY's privilege to either use or disregard the infor- 163 mation that it receives from ASX about NET1's reachability. ASY might 164 decide not to use this information if it does not want to send 165 traffic to NET1 at all or if it considers another route more 166 appropriate to reach NET1. 168 In order for traffic in the direction of NET1 to flow between ASX and 169 ASY, ASX must announce that route to ASY and ASY must accept it from 170 ASX: 172 resulting packet flow towards NET1 173 <<=================================== 174 | 175 | 176 announce NET1 | accept NET1 177 --------------> + -------------> 178 | 179 AS X | AS Y 180 | 181 <------------- + <-------------- 182 accept NET2 | announce NET2 183 | 184 | 185 resulting packet flow towards NET2 186 ===================================>> 188 Ideally, and seldom practically, the announcement and acceptance pol- 189 icies of ASX and ASY are identical. 191 In order for traffic towards NET2 to flow, announcement and accep- 192 tance of NET2 must be in place (mirror image of NET1). For almost all 193 applications connectivity in just one direction is not useful at all. 195 It should be noted that, in more complex topologies than this exam- 196 ple, traffic from NET1 to NET2 may not necessarily take the same path 197 as traffic from NET2 to NET1; this is called asymmetrical routing. 198 Asymmetrical routing is not inherently bad, but can often cause per- 199 formance problems for higher level protocols, such as TCP, and should 200 be used with caution. 202 It is important to realise that with current destination based for- 203 warding technology routing policies must eventually be expressed in 204 these terms. 206 Policies are not configured for each prefix separately but for groups 207 of prefixes. These groups of prefixes are ASes. 209 An AS has a globally unique number (sometimes referred to as an ASN, 210 or Autonomous System Number) associated with it; this number is used 211 in both the exchange of exterior routing information (between neigh- 212 boring ASes), and as an identifier of the AS itself. 214 In routing terms, an AS will normally use one or more interior gate- 215 way protocols (IGPs) when exchanging reachability information within 216 its own AS. See ``IGP Issues''. 218 4. Common errors in allocating ASes 220 The term AS is often confused or even misused as a convenient way of 221 grouping together a set of prefixes which belong under the same 222 administrative umbrella, even if within that group of prefixes there 223 are various different routing policies. Without exception, an AS must 224 have only one routing policy. 226 It is essential that careful consideration and coordination be 227 applied during the creation of an AS. Using an AS merely for the sake 228 of having an AS is to be avoided, as is the worst-case scenario of 229 one AS per classful network (the IDEAL situation is to have one pre- 230 fix, containing many networks, per AS). This may mean that some re- 231 engineering may be required in order to apply the criteria and guide- 232 lines for creation and allocation of an AS that we list below; 233 nevertheless, doing so is probably the only way to implement the 234 desired routing policy. 236 If you are currently engineering an AS, careful thought should be 237 taken to register appropriately sized CIDR blocks with your registra- 238 tion authority in order to minimize the number of advertised prefixes 239 from your AS. In the perfect world that number can , and should, be 240 as low as one. 242 Some router implementations use an AS number as a form of tagging to 243 identify interior as well as exterior routing processes. This tag 244 does not need to be unique unless routing information is indeed 245 exchanged with other ASes. See ``IGP Issues''. 247 5. Criteria for the decision -- do I need an AS? 249 * Exchange of external routing information 251 An AS must be used for exchanging external routing information 252 with other ASes through an exterior routing protocol. The 253 current recommended exterior routing protocol is BGP, the Border 254 Gateway Protocol. However, the exchange of external routing 255 information alone does not constitute the need for an AS. See 256 ``Sample Cases'' below. 258 * Many prefixes, one AS 260 As a general rule, one should try to place as many prefixes as 261 possible within a given AS, provided all of them conform to the 262 same routing policy. 264 * Unique routing policy 266 As AS is only needed when you have a routing policy which is 267 different from that of your border gateway peers. Here routing 268 policy refers to how the rest of the Internet makes routing 269 decisions based on information from your AS. See ``Sample 270 Cases'' below to see exactly when this criteria will apply. 272 5.1 Sample Cases 274 * Single-homed site, single prefix 276 A separate AS is not needed; the prefix should be placed in an 277 AS of the provider. The site's prefix has exactly the same rout- 278 ing policy as the other customers of the site's service pro- 279 vider, and there is no need to make any distinction in routing 280 information. 282 This idea may at first seem slightly alien to some, but it 283 highlights the clear distinction in the use of the AS number as 284 a representation of routing policy as opposed to some form of 285 administrative use. 287 In some situations, a single site, or piece of a site, may find 288 it necessary to have a policy different from that of its pro- 289 vider, or the rest of the site. In such an instance, a separate 290 AS must be created for the affected prefixes. This situation is 291 rare and should almost never happen. Very few stub sites require 292 different routing policies than their parents. Because the AS is 293 the unit of policy, however, this sometimes occurs. 295 * Single-homed site, multiple prefixes 297 Again, a separate AS is not needed; the prefixes should be 298 placed in an AS of the site's provider. 300 * Multi-homed site 302 Here multi-homed is taken to mean a prefix or group of prefixes 303 which connects to more than one service provider (i.e. more than 304 one AS with its own routing policy). It does not mean a network 305 multi-homed running an IGP for the purposes of resilience. 307 An AS is required; the site's prefixes should be part of a 308 single AS, distinct from the ASes of its service providers. 309 This allows the customer the ability to have a different 310 representation of policy and preference among the different ser- 311 vice providers. 313 This is ALMOST THE ONLY case where a network operator should 314 create its own AS number. In this case, the site should ensure 315 that it has the necessary facilities to run appropriate routing 316 protocols, such as BGP4. 318 5.2 Other factors 320 * Topolgy 322 Routing policy decisions such as geography, AUP (Acceptable Use 323 Policy) compliance and network topology can influence decisions 324 of AS creation. However, all too often these are done without 325 consideration of whether or not an AS is needed in terms of 326 adding additional information for routing policy decisions by 327 the rest of the Internet. Careful consideration should be taken 328 when basing AS creation on these type of criteria. 330 * Transition / ``future-proofing'' 332 Often a site will be connected to a single service provider but 333 has plans to connect to another at some point in the future. 334 This is not enough of a reason to create an AS before you really 335 need it. The AS number space is finite and the limited amount 336 of re-engineering needed when you connect to another service 337 provider should be considered as a natural step in transition. 339 * History 341 AS number application forms have historically made no reference 342 to routing policy. All too often ASes have been created purely 343 because it was seen as ``part of the process'' of connecting to 344 the Internet. The document should act as reference to future 345 application forms to show clearly when an AS is needed. 347 6. Speculation 349 1) If provider A and provider B have a large presence in a 350 geographical area (or other routing domain), and many customers are 351 multi-homed between them, it makes sense for all of those customers 352 to be placed within the same AS. However, it is noted that case 353 should only be looked at if practical to do so and fully coordinated 354 between customers and service providers involved. 356 2) Sites should not be forced to place themselves in a separate AS 357 just so that someone else (externally) can make AS-based policy deci- 358 sions. Nevertheless, it may occasionally be necessary to split up an 359 AS or a prefix into two ASes for policy reasons. Those making exter- 360 nal policy may request the network operators make such AS changes, 361 but the final decision is up to those network operators who manage 362 the prefixes in question, as well as the ASes containing them. This 363 is, of course, a trade off -- it will not always be possible to 364 implement all desired routing policies. 366 7. One prefix, one origin AS 368 Generally, a prefix can should belong to only one AS. This is a 369 direct consequence of the fact that at each point in the Internet 370 there can be exactly one routing policy for traffic destined to each 371 prefix. In the case of an prefix which is used in neighbor peering 372 between two ASes, a conscious decision should be made as to which AS 373 this prefix actually resides in. 375 With the introduction of aggregation it should be noted that an AS 376 can occasionally be represented as residing in more than one AS, how- 377 ever, this is very much the exception rather than the rule. This hap- 378 pens when aggregating using the AS_SET attribute in BGP, wherein the 379 concept of origin is lost. In some cases the origin AS is lost alto- 380 gether if there is a less specific aggregate announcement setting the 381 ATOMIC_AGGREGATE attribute. 383 8. IGP Issues 385 As stated above, many router vendors require an identifier for tag- 386 ging their IGP processes. However, this tag does not need to be glo- 387 bally unique. In practice this information is never seen by exterior 388 routing protocols. If already running an exterior routing protocol, 389 it is perfectly reasonable to use your AS number as an IGP tag; if 390 you do not, choosing a random value is acceptable. Merely running an 391 IGP is not grounds for registration of an AS number. 393 With the advent of BGP4 it becomes necessary to use an IGP that can 394 carry classless routes. Examples include OSPF [OSPF] and ISIS [ISIS]. 396 9. AS Space exhaustion 398 The AS number space is a finite amount of address space. It is 399 currently defined as a 16 bit integer and hence limited to 65535 400 unique AS numbers. At the time of writing some 3,700 ASes have been 401 allocated and a little under 400 ASes are actively routed in the glo- 402 bal Internet. It is clear that this growth needs to be continually 403 monitored. However, if the criteria applied above are adhered to, 404 then there is no immediate danger of AS space exhaustion. It is 405 expected that IDRP will be deployed before this becomes an issue. 406 IDRP does not have a fixed limit on the size of an RDI. 408 10. Security Considerations 410 There are few security concerns regarding the selection of ASes. 412 AS number to owner mappings are public knowledge (in WHOIS), and 413 attempting to change that would serve only to confuse those people 414 attempting to route IP traffic on the Internet. 416 11. Acknowledgments 418 This document is largely based on [RIPE-109], and is intended to have 419 a wider scope than purely the RIPE community; this document would not 420 exist without [RIPE-109]. 422 12. References 424 [RIPE-109] 425 Bates, T., Lord, A., "Autonomous System Number Application Form 426 & Supporting Notes", RIPE 109, RIPE NCC, 1 March 1994. 427 URL: ftp://ftp.ripe.net/ripe/docs/ripe-109.txt. 429 [BGP-4] 430 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 431 RFC 1654, T.J. Watson Research Center, cisco Systems, July 1994. 433 [EGP] 434 Mills, D. "Exterior Gateway Protocol formal specifications", RFC 435 904, STD 18, International Telegraph and Telephone Co., 1 April 436 1984. 438 [IDRP] 439 Kunzinger, C., Editor, "OSI Inter-Domain Routing Protocol 440 (IDRP)", ISO/IEC 10747, Work In Progress, October 1993. 442 [CIDR] 443 Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter- 444 Domain Routing (CIDR): an Address Assignment and Aggregation 445 Strategy", RFC 1519, BARRnet, cisco, MERIT, OARnet, September 446 1993. 448 [OSPF] 449 Moy, J., "OSPF Version 2", RFC 1583, March 1994. 451 [ISIS] 452 Callon, R., Gunner, C., "Use of OSI IS-IS for Routing in TCP/IP 453 and Multi-Protocol Environments", draft-ietf-isis-tcpip-01.txt, 454 WORK IN PROGRESS, July 1994. 456 13. Authors' Addresses 458 John Hawkinson 459 Panix 460 1200 Warburton Ave., Suite 57 461 Yonkers, NY 10701-1057 462 USA 464 phone: +1 617 253 7788 465 email: jhawk@panix.com 467 Tony Bates 468 MCI 469 2100 Reston Parkway 470 Reston, VA 22094 472 phone: +1 703 715 7521 473 email: Tony.Bates@mci.net