For all the harping I do on this blog about IPv4 address depletion and the need to prepare yourselves for IPv6, there is another number resource that is also being quickly depleted, and that I haven’t written about before: the 2-byte autonomous system numbers (ASNs).
A 16-bit number space gives you 65,536 possible numbers (AS numbers 0 – 65535). Out of these, the IANA reserves 1,026 of them: 64512 – 65534 for private, reusable ASNs (similar to private RFC1918 IPv4 addresses) and a few others such as 0 and 65535 and one that is important to this article, 23456. Presently 49,150 ASNs have been allocated out of the public pool, so there are 15,360 available ASNs remaining: About 23.8 percent of the public pool.
An analysis of the allocation rate of 2-byte ASNs shows that the available pool will run out in mid-2011. Eerily close to the date that we will run out of IPv4 addresses.
Fortunately there is much less cause for concern about ASN depletion than about IPv4 depletion, for two reasons:
Unlike IP addresses, which are necessary for anyone that wants to connect to an IP network, autonomous system numbers matter only to networks that are running BGP.
- Just as IPv6 was created to solve the IPv4 problem by offering an address size four times as large, 4-byte ASNs have been created to solve the 2-byte ASN depletion problem. But where transition to IPv6 can be complicated because of lack of interoperability between IPv4 and IPv6, the transition to 4-byte ASNs is far simpler.
This post describes the format of the 4-byte ASN, how it interoperates with 2-byte ASNs, and what you need to do (if anything) to prepare your network for them.
The 4-Byte ASN Format
4-byte ASNs provide 232 or 4,294,967,296 autonomous system numbers ranging from 0 to 4294967295. The first thing to notice about these numbers is that they include all of the older 2-byte ASNs, 0 through 65535. That greatly helps with interoperability between autonomous systems using 2-byte ASNs and those using 4-byte ASNs. (An oft-heard complaint about IPv6 is that interoperability with IPv4 could have been more easily supported if 4.3 billion IPv6 addresses had been reserved as representative of the existing IPv4 addresses, but that’s another story.)
A 4-byte ASN between 0 and 65535 is called a mappable ASN, because it can be represented in just 2 bytes; the first 16 bits are in every case all zeroes.
Stemming from a concern that 32-bit ASNs might be difficult to write and manage, there are three ways of representing 4-byte ASNs:
· asplain is a simple decimal representation of the ASN, from 0 to 4294967295.
· asdot+ breaks the number up into low-order and high-order 16-bit values, separated by a dot. All of the older 2-byte ASNs can be represented in the low-order value, with the high-order value set to 0. So for example, 65535 is 0.65535. One more than that, 65536, is outside the value that can be represented in the low-order range alone, and is therefore represented as 1.0. 65537 would be 1.1, 65680 is 1.144, and so on. You can figure the low- and high-order values by subtracting multiples of 65,536 from the asplain representation of the ASN, with the high-order value representing the multiples of 65536. The ASN 327700, then, is 5.20: Five times 65536 plus 20 more. The largest ASN, 4294967295, is 65535.65535: 65,535 times 65535, plus 65535 more.
· asdot is a mixture of asplain and asdot+. Any ASN in the 2-byte range of 0 – 65535 is written in asplain (so 65535 is written “65535”) and any ASN above that range is written in asdot+ (so 65536 is written “1.0”).
Asplain is obviously the most straightforward method of understanding the new ASNs, although the larger numbers might become unwieldy to write and therefore prone to typographical mistakes in written documentation or router configurations.
Asdot+ is much simpler to write, but harder to calculate from its simple decimal equivalent. If you work in this format regularly, it’s probably worth your time to write a simple script that does the conversions for you to prevent calculation errors.
Asdot might appear to have limited usefulness. After all, it’s not any harder to write “0.3657” than to write “3657”, and the need to do some calculations come in when you go above 65535; asdot does nothing to help you there. There is, however, a subtlety to this. The regional number assignment authorities – the Regional Internet Registries, or RIRs – differentiate a 16-bit number that is an older 2-byte ASN and a mappable 4-byte ASN (again, the set of 32-bit ASNs in which the first 16 bits are all 0). So “3657” is a 2-byte ASN, and “0.3657” is a 4-byte ASN.
This, of course, leads us to look briefly at just what the RIRs’ policies are for assigning 4-byte ASNs.
ASN Allocation Policies
All five of the RIRs (AfriNIC, APNIC, ARIN, LACNIC, and RIPE NCC) have the same assignment policies for 4-byte ASNs:
· 4-byte ASNs have been available since 1 January 2007. The default assignment, if you request an ASN, is to give you a 2-byte ASN and only assign a 4-byte ASN if you specifically request it.
· Beginning on 1 January 2009 (yes, about a month from now!) that policy reverses: A 4-byte ASN will be the default. You can still get a 2-byte ASN, but only if you specifically request it.
· A year later, on 1 January 2010, all ASN assignments will be 4-byte. The ASN you receive might be of the form 0.XX (where the high-order 16 bits are all 0 and the low-order 16 bits are not), but the RIRs will make no distinction between those numbers and any other 4-byte ASN. And although it won't effect your network in any way, the 16-bit ASN you've had maybe for years will, in the eyes of the RIRs, be a mapable 32-bit ASN. For instance, Level3 Communications' AS3356 becomes in the eyes of the RIRs, at the beginning of 2010, 0.3356.
These policies raise several questions:
· If you plan to request a new ASN assignment starting in 2009, what do you need to do to prepare for it?
· How do the new 4-byte ASNs interoperate with older autonomous systems using 2-byte ASNs?
· If you have an existing 2-byte ASN, does anything change?
The ASN’s Role in BGP
A brief review of how BGP uses autonomous system numbers will help in understanding how the new format might impact BGP networks. Most of you already know the basics of BGP; if you do, feel free to skip ahead.
The purpose of BGP, unlike any IGP (OSPF, IS-IS, EIGRP and RIP), is to route between domains under separate administrative control – that is, systems that are autonomous from each other. If you’re going to route between (and among) these autonomous routing domains, you need some way of identifying individual ASs. That identifier is the autonomous system number.
The ASN has two essential functions in BGP:
First, it helps BGP determine the shortest path to a destination. When BGP advertises a route to a neighbor in an Update message, it attaches several path attributes to the route. When a router learns more than one BGP route to the same destination, the BGP decision process evaluates the routes’ path attributes in a prioritized order to decide which of the routes is most preferable. (BGP path attributes can be added, removed, or changed in all sorts of ways to influence the BGP decision process. This is the basis for BGP routing policies.) One of these attributes, attached to every BGP route, is called AS_PATH. When a router advertises a destination within its own AS to a neighbor in another AS, it puts its local ASN in the AS_PATH. As the route is advertised to subsequent autonomous systems, each AS border router adds its own ASN to the attribute. The AS_PATH, then, becomes a list of ASNs that describes the path back to the destination. A router can choose a shortest path by choosing the route with the fewest ASNs listed in its AS_PATH.
The second ASN function is a very simple loop avoidance mechanism. Because a router adds its ASN to the AS_PATH before advertising a route to a neighbor in another AS, a route that loops – that is, exits an AS and is subsequently advertised back to the same AS – is easily detected by examining the AS_PATH. If a router sees its own ASN listed in the AS_PATH of a route advertised to it by a neighbor, it drops the route.
The ASN also appears in a path attribute called the AGGREGATOR. When a number of routes are summarized (aggregated), route details can be lost. The AGGREGATOR attribute can be added to an aggregate route to indicate the Router ID and ASN of the router performing the aggregation. This attribute does not influence the BGP decision process, but it can be useful for tracing back problems with aggregate routes.
A third attribute that uses the ASN is COMMUNITIES. This optional attribute helps you manage routing polices when they apply to a large number of routes; using a number of methods you can assign one or more COMMUNITIES attributes to prefixes, and then apply a routing policy to a community rather than individual routes. For example, you might define a COMMUNITES attribute named Cust_Routes and then add that attribute to all routes advertised into your AS by all your customers. Then anywhere in your network that you need to apply a policy to all of your customer routes, you can apply the policy to routes having the Customer_Routes attribute rather than having to identify each prefix (and possibly change all your prefix lists any time a customer route is added or removed).
The COMMUNITES attribute is a 32-bit value in which the first 16 bits are an ASN and the last 16 bits are arbitrarily assigned by you to have whatever meaning you want.
The important point here is not so much the functions of AGGREGATOR or COMMUNITES, however, but that they, like AS_PATH, are formatted to carry 2-byte ASNs; the formats of these attributes must therefore be adapted to carry the larger 32-bit ASNs.
In addition to these three path attributes the BGP Open message also references the ASN, in a 16-bit field called My Autonomous System. BGP runs on top of a TCP session between neighbors; after the TCP session is established, the neighbors use Open messages to negotiate the BGP session. Each neighbor indicates its Router ID, ASN, the BGP version it is running (always version 4 in modern networks), its hold time (the time it expects to wait for a Keepalive from the neighbor before closing the session) and possibly some optional parameters.
There is alot more to BGP than what has been described here. What is important for this discussion is that there are four BGP data entities that carry ASNs:
· The AS_PATH attribute;
· The AGGREGATOR attribute;
· The COMUNITES attribute; and
· The Open message
Consideration must be given to each of these entities not only in terms of adapting them to 4-byte ASNs but also making the adaptations interoperable with older BGP implementations that only understand 2-byte ASNs.
For simplicity, we’ll call BGP implementations supporting 4-byte ASNs New_BGP, and legacy BGP implementations that only support 2-byte ASNs Old_BGP.
The first requirement for a New_BGP implementation is to discover whether a neighbor is New_BGP or Old_BGP. It does this by using the BGP Capability Advertisement when opening a BGP session. In addition to advertising itself as New_BGP, it includes its 4-byte ASN in the Capability advertisement.
If a neighbor responds that it also is a NEW_BGP speaker, the neighbor includes its 4-byte ASN in its own Capability advertisement. Thus two New_BGP neighbors can inform each other of their 4-byte ASNs without using the 2-byte My Autonomous System field in the Open message. (If the neighbors are NEW_BGP but have 2-byte ASNs or mappable 4-byte ASNs, they can still put the ASN in the My Autonomous System field in addition to the Capability advertisement.)
If a neighbor is Old-BGP, it either responds that it does not support the 4-byte ASN capability or does not respond to the Capability advertisement at all. In this case, the New_BGP neighbor can still bring up a session with the Old-BGP neighbor, but cannot advertise its 4-byte ASN. The neighbor wouldn’t understand it. Instead, New_BGP uses a reserved 2-byte ASN, 23456, called AS_TRANS (AS_TRANS is easily remembered because of its 2-3-4-5-6 sequence). This AS number is added to the My Autonomous System field of the Open message. Because AS_TRANS is reserved, no Old_BGP speaker can use it as its own ASN; only New_BGP speakers can use it.
Interoperable peering, then, is achieved because the New_BGP speaker “knows” its neighbor is an Old_BGP speaker and adapts to it; the Old-BGP speaker simply continues using legacy BGP rules.
Path Attribute Interoperability
Because the New_BGP speaker knows whether its neighbor is New_BGP or Old_BGP, it knows what rules to follow when advertising routes to the neighbor.