RFC 1930
Guidelines for creation, selection, and registration of an Autonomous System (AS)
Guidelines for creation, selection, and registration of an Autonomous System (AS) 🦋
Okay bestie, this is RFC 1930 🎀, a Best Current Practice (it's BCP 6 if we're being fancy), dated March 1996. It's filed under the Network Working Group with RFC number 1930. The authors are J. Hawkinson from BBN Planet and T. Bates from MCI 💅. The title block doesn't list any Obsoletes or Updates entries, so it doesn't claim to replace or amend anything else.
Quick heads-up: this RFC is from 1996, before the capitalised BCP 14 key words existed. Its must, should, and may are plain lowercase English, so I've kept them lowercase so nothing gets stronger or weaker 🫶
Status of This Memo 📮
This is a Best Current Practice for the Internet Community, and it's asking for discussion and suggestions for improvements 🌸 Distribution of this memo is unlimited, so it's totally shareable ✨
Abstract 🌈
This memo is all about when it makes sense to register and use an Autonomous System (AS), and it lists the criteria for making that call 💖 ASes are the unit of routing policy in today's exterior routing world, and they're especially relevant to protocols like EGP (Exterior Gateway Protocol, now at historical status; see [EGP]), BGP (Border Gateway Protocol, the current de facto standard for inter-AS routing; see [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the Internet is expected to adopt when BGP becomes obsolete; see [IDRP]). It should be noted that the IDRP equivalent of an AS is the RDI, or Routing Domain Identifier 🧚
Table of Contents 📑
1. Introduction ............................................ 2
2. Motivation .............................................. 2
3. Definitions ............................................. 2
4. Common errors in allocating ASes ........................ 5
5. Criteria for the decision -- do I need an AS? .......... 5
5.1 Sample Cases ........................................... 6
5.2 Other Factors .......................................... 7
6. Speculation ............................................. 7
7. One prefix, one origin AS ............................... 8
8. IGP issues .............................................. 8
9. AS Space exhaustion ..................................... 8
10. Reserved AS Numbers .................................... 9
11. Security Considerations ................................ 9
12. Acknowledgments ........................................ 9
13. References ............................................. 9
14. Authors' Addresses ..................................... 101. Introduction ✨
Let's get into it. This memo covers when it's appropriate to register and use an Autonomous System (AS), and it lays out criteria for that decision 🦋 ASes are the unit of routing policy in the modern exterior routing world, and they apply specifically to protocols like EGP (Exterior Gateway Protocol, now at historical status; see [EGP]), BGP (Border Gateway Protocol, the current de facto standard for inter-AS routing; see [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the Internet is expected to adopt when BGP becomes obsolete; see [IDRP]). It should be noted that the IDRP equivalent of an AS is the RDI, or Routing Domain Identifier 💅
2. Motivation 🎀
This memo is written for network operators and service providers who need to figure out in what circumstances they should make use of an AS 👑 It's assumed that the reader already knows routing protocols and is someone who configures and operates Internet networks. Honestly, there's a LOT of confusion about how ASes should be used today 🙈 This memo tries to clear up some of that mess and act as a simple guide to today's exterior routing.
3. Definitions 📚
This document uses the term "prefix" all the way through. In the current classless Internet (see [CIDR]), a block of class A, B, or C networks may be referred to by just a prefix and a mask, as long as that block begins and ends on a power-of-two boundary. For example, the networks:
192.168.0.0/24
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24can simply be referred to as:
192.168.0.0/22The term "prefix" as used here means the same thing as "CIDR block". Put simply, it's a group of one or more networks 🍓 We use the term "network" to mean classful network, or "A, B, C network".
The definition of AS has been unclear and ambiguous for some time 😭 [BGP-4] states:
The classic definition of an Autonomous System is a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASes. Since this classic definition was developed, it has become common for a single AS to use several interior gateway protocols and sometimes several sets of metrics within an AS. The use of the term Autonomous System here stresses the fact that, even when multiple IGPs and metrics are used, the administration of an AS appears to other ASes to have a single coherent interior routing plan and presents a consistent picture of what networks are reachable through it.
To put it more succinctly:
An AS is a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy. 💜
Routing policy here means how routing decisions are made on the Internet today 🌸 It's the exchange of routing information between ASes that is subject to routing policies. Let's look at two ASes, X and Y, swapping routing information:
NET1 ...... ASX <---> ASY ....... NET2ASX knows how to reach a prefix called NET1. It doesn't matter whether NET1 belongs to ASX or to some other AS that exchanges routing information with ASX, either directly or indirectly. We just assume that ASX knows how to direct packets towards NET1. Likewise, ASY knows how to reach NET2.
For traffic from NET2 to NET1 to flow between ASX and ASY, ASX has to announce NET1 to ASY using an exterior routing protocol. This means ASX is willing to accept traffic directed to NET1 from ASY. Policy comes into play when ASX decides to announce NET1 to ASY 🔥
For traffic to actually flow, ASY has to accept this routing information and use it. It's ASY's privilege to either use or disregard the information it receives from ASX about NET1's reachability ✨ ASY might decide not to use this information if it doesn't want to send traffic to NET1 at all, or if it considers another route more appropriate for reaching NET1.
For traffic in the direction of NET1 to flow between ASX and ASY, ASX must announce that route to ASY, and ASY must accept it from ASX:
resulting packet flow towards NET1
<<===================================
|
|
announce NET1 | accept NET1
--------------> + ------------->
|
AS X | AS Y
|
<------------- + <--------------
accept NET2 | announce NET2
|
|
resulting packet flow towards NET2
===================================>>Ideally (though seldom practically) the announcement and acceptance policies of ASX and ASY are symmetrical 🫶
For traffic towards NET2 to flow, announcement and acceptance of NET2 must be in place. It's the mirror image of NET1. For almost all applications, connectivity in just one direction is not useful at all 💀
It should be noted that in more complex topologies than this example, traffic from NET1 to NET2 may not necessarily take the same path as traffic from NET2 to NET1. This is called asymmetrical routing. Asymmetrical routing isn't inherently bad, but it can often cause performance problems for higher level protocols, such as TCP, so it should be used with caution and only when necessary 🌈 However, asymmetric routing may be a requirement for mobile hosts and for inherently asymmetric situations, such as a satellite download paired with a modem upload connection 🛰️
Policies aren't configured for each prefix separately. They're configured for groups of prefixes, and these groups of prefixes are ASes 🧚
An AS has a globally unique number (sometimes referred to as an ASN, or Autonomous System Number) associated with it. This number is used both in the exchange of exterior routing information (between neighboring ASes) and as an identifier for the AS itself 🎀
In routing terms, an AS will normally use one or more interior gateway protocols (IGPs) when exchanging reachability information within its own AS. See "IGP Issues".
4. Common errors in allocating ASes 🙈
The term AS is often confused, or even misused, as a convenient way to group together a set of prefixes that belong under the same administrative umbrella, even when that group contains various different routing policies. Without exception, an AS must have only one routing policy 🚫
It is essential that careful consideration and coordination be applied when creating an AS. Using an AS merely for the sake of having an AS is to be avoided. So is the worst-case scenario of one AS per classful network. The IDEAL situation is one prefix, containing many longer prefixes, per AS 💖 This may mean some re-engineering is required in order to apply the criteria and guidelines for creating and allocating an AS that we list below. Nevertheless, doing so is probably the only way to implement the desired routing policy.
If you're currently engineering an AS, careful thought should be taken to register appropriately sized CIDR blocks with your registration authority. The goal is to minimise the number of advertised prefixes from your AS 🍓 In the perfect world, that number can, and should, be as low as one 👑
Some router implementations use an AS number as a form of tagging to identify interior as well as exterior routing processes. This tag does not need to be unique unless routing information is actually exchanged with other ASes. See "IGP Issues".
5. Criteria for the decision -- do I need an AS? 🤔
Okay, the big question: do you actually need an AS? Here's the checklist 💅
- Exchange of external routing information: An AS must be used for exchanging external routing information with other ASes through an exterior routing protocol. The current recommended exterior routing protocol is BGP, the Border Gateway Protocol. However, the exchange of external routing information alone does not constitute the need for an AS. See "Sample Cases" below.
- Many prefixes, one AS: As a general rule, one should try to place as many prefixes as possible within a given AS, provided all of them conform to the same routing policy ✨
- Unique routing policy: An AS is only needed when you have a routing policy that is different from that of your border gateway peers. Here, routing policy refers to how the rest of the Internet makes routing decisions based on information from your AS. See "Sample Cases" below to see exactly when this criterion will apply 🦋
Part 1 ends here, bestie! Part 2 picks up with the Sample Cases and Other Factors (Sections 5.1 and 5.2) 💖🧚
5.1. Sample Cases 🎀
- Single-homed site, single prefix 🌸 A separate AS is not needed; the prefix should be placed in an AS of the provider. The site's prefix has exactly the same routing policy as the other customers of the site's service provider, and there is no need to make any distinction in routing information.
This idea might feel a little alien at first 👽, but it really highlights the clear difference between using an AS number to represent routing policy and using it for some form of administrative use. ✨
Sometimes a single site, or just a piece of one, needs a policy that's different from its provider's or from the rest of the site 🤔. When that happens, a separate AS must be created for the affected prefixes. This is rare and should almost never happen, because very few stub sites need different routing policies from their parents. BUT the AS is the unit of policy, so it sometimes does happen 💀.
- Single-homed site, multiple prefixes 🦋 Again, a separate AS is not needed; the prefixes should be placed in an AS of the site's provider.
- Multi-homed site 👑 Here, multi-homed means a prefix or group of prefixes that connects to more than one service provider (i.e. more than one AS with its own routing policy). It does not mean a network that is multi-homed by running an IGP for the purposes of resilience.
An AS is required; the site's prefixes should be part of a single AS, distinct from the ASes of its service providers. This gives the customer the ability to have a different representation of policy and preference among the different service providers. 💅
This is ALMOST THE ONLY case where a network operator should create its own AS number. In this case, the site should ensure that it has the necessary facilities to run appropriate routing protocols, such as BGP4. 🔥
5.2. Other factors ✨
- Topology 🗺️ Routing policy decisions such as geography, AUP (Acceptable Use Policy) compliance and network topology can influence decisions of AS creation. However, all too often these are made without considering whether or not an AS is needed in terms of adding information for routing policy decisions by the rest of the Internet. Careful consideration should be taken when basing AS creation on these kinds of criteria.
- Transition / "future-proofing" 🔮 Often a site will be connected to a single service provider but has plans to connect to another at some point in the future. That is not enough of a reason to create an AS before you really need it. The AS number space is finite, and the limited amount of re-engineering needed when you connect to another service provider should be considered a natural step in the transition. 🌈
- History 📜 AS number application forms have historically made no reference to routing policy. All too often ASes have been created purely because it was seen as "part of the process" of connecting to the Internet. This document should be used as a reference for future application forms to show clearly when an AS is needed. 🫶
6. Speculation 🔮
- If provider A and provider B have a large presence in a geographical area (or other routing domain), and many customers are multi-homed between them, it makes sense for all of those customers to be placed within the same AS. However, it is noted that this case should only be looked at if it is practical to do so and fully coordinated between the customers and the service providers involved. 🤝
- Sites should not be forced to place themselves in a separate AS just so that someone else (externally) can make AS-based policy decisions. Nevertheless, it may occasionally be necessary to split up an AS or a prefix into two ASes for policy reasons. Those making external policy may request that the network operators make such AS changes, but the final decision is up to those network operators who manage the prefixes in question, as well as the ASes containing them. This is, of course, a trade off -- it will not always be possible to implement all desired routing policies. 🙈
7. One prefix, one origin AS 👑
Generally, a prefix can should belong to only one AS. This is a direct consequence of the fact that at each point in the Internet there can be exactly one routing policy for traffic destined to each prefix. In the case of a prefix that is used in neighbor peering between two ASes, a conscious decision should be made as to which AS this prefix actually resides in. 🎯
With the introduction of aggregation, it should be noted that a prefix may be represented as residing in more than one AS. However, this is very much the exception rather than the rule. This happens when aggregating using the AS_SET attribute in BGP, wherein the concept of origin is lost. In some cases the origin AS is lost altogether if there is a less specific aggregate announcement setting the ATOMIC_AGGREGATE attribute. 💀
8. IGP Issues 🧚
As stated above, many router vendors require an identifier for tagging their IGP processes. However, this tag does not need to be globally unique. In practice, this information is never seen by exterior routing protocols. If you are already running an exterior routing protocol, it is perfectly reasonable to use your AS number as an IGP tag. If you do not, choosing from the private use range is also acceptable (see "Reserved AS Numbers"). Merely running an IGP is not grounds for registration of an AS number. 🌸
With the advent of BGP4, it becomes necessary to use an IGP that can carry classless routes. Examples include OSPF [OSPF] and ISIS [ISIS]. 💜
9. AS Space exhaustion ⭐
The AS number space is a finite amount of address space. It is currently defined as a 16 bit integer and hence limited to 65535 unique AS numbers. At the time of writing, some 5,100 ASes have been allocated and a little under 600 ASes are actively routed in the global Internet. It is clear that this growth needs to be continually monitored. However, if the criteria applied above are adhered to, then there is no immediate danger of AS space exhaustion. It is expected that IDRP will be deployed before this becomes an issue. IDRP does not have a fixed limit on the size of an RDI. 🌈
10. Reserved AS Numbers 🎀
The Internet Assigned Numbers Authority (IANA) has reserved the following block of AS numbers for private use (not to be advertised on the global Internet):
64512 through 6553511. Security Considerations 🔥
There are few security concerns regarding the selection of ASes. 😌
AS number to owner mappings are public knowledge (in WHOIS), and attempting to change that would serve only to confuse those people attempting to route IP traffic on the Internet. This is serious business, bestie 🚨
12. Acknowledgments 🫶
This document is largely based on [RIPE-109], and is intended to have a wider scope than purely the RIPE community. This document would not exist without [RIPE-109]. 💖
13. References 📚
[RIPE-109] Bates, T., Lord, A., "Autonomous System Number Application Form & Supporting Notes", RIPE 109, RIPE NCC, 1 March 1994. URL: ftp://ftp.ripe.net/ripe/docs/ripe-109.txt.
[BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1654, T.J. Watson Research Center, cisco Systems, July 1994.
[EGP] Mills, D., "Exterior Gateway Protocol Formal Specifications", STD 18, RFC 904, International Telegraph and Telephone Co., April 1984.
[IDRP] Kunzinger, C., Editor, "OSI Inter-Domain Routing Protocol (IDRP)", ISO/IEC 10747, Work In Progress, October 1993.
[CIDR] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, BARRnet, cisco, MERIT, OARnet, September 1993.
[OSPF] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
[ISIS] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Multi-Protocol Environments", RFC 1195, Digital Equipment Corporation, December 1990.
14. Authors' Addresses 💌
John Hawkinson BBN Planet Corporation 150 CambridgePark Drive Cambridge, MA 02139 Phone: +1 617 873 3180 EMail: jhawk@bbnplanet.com
Tony Bates MCI 2100 Reston Parkway Reston, VA 22094 Phone: +1 703 715 7521 EMail: Tony.Bates@mci.net
That's the whole RFC, bestie! 🌈💖
📦 where this page comes from
- ietf: rfc1930 1996-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms