From: Andrew de la Haye <noreply@ripe.net>
Subject: 32-bit AS Numbers: A Change Is Coming!

Dear Colleagues,

As of 1 January 2009, the RIPE NCC will begin assigning 32-bit (or four-byte) ASN Numbers (ASNs) by default. This is in accordance with a global
policy agreed on in all Regional Internet Registry (RIR) communities.

When requesting an ASN after 1 January, LIR staff should ensure that 32-bit ASNs will be compatible with their existing networks. Some network
operators may experience difficulties configuring BGP sessions if their or their upstream providers' equipment is not compliant with the new
32-bit standard.

If you believe your network will encounter problems with 32-bit ASNs, it will be possible to specifically request a 16-bit ASN.

For more information, please see, "32-bit Autonomous System Numbers: A Guide for LIRs":
http://www.ripe.net/news/asn-32-guide.html

If you have any questions regarding 32-bit ASNs, please send an email to <contact@ripe.net>.

Regards,
Andrew de la Haye
Chief Operations Officer, RIPE NCC

Один знакомый бросил ссылочку на интересную статейку и мы решили запостить и у нас:

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 2³² 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.

Neighbor Interoperability

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.

When advertising routes to a New_BGP neighbor, the AS_PATH attribute is simply modified to carry 4-byte ASNs. But when advertising routes to an Old-BGP neighbor, the AS_PATH must be kept in its legacy format, as a list of 2-byte ASNs; an Old_BGP neighbor would not otherwise know how to interpret the list. Rather than adding its own 4-byte ASN to the AS_PATH, the New_BGP speaker adds the AS_TRANS (again, AS23456) to the AS_PATH as a placeholder for its own and any other 4-byte ASNs appearing on the path. The router also adds a new attribute, AS4_PATH, to the route. This attribute carries the list of real ASNs, both 4-byte and 2-byte. Unlike AS_PATH, which is a mandatory attribute for all routes, AS4_PATH is optional transitive: “Optional” meaning it is only used when needed (and in fact a New_BGP speaker will not use this attribute if the AS_PATH is all 2-byte ASNs), and “transitive” meaning any BGP speaker passes the attribute along to other neighbors even if it doesn’t understand the attribute. Thus, the real autonomous system path can be passed transparently through one or more Old_BGP speakers.

When an Old_BGP speaker advertises a route with both AS_PATH and AS4_PATH attributes to a New_BGP speaker, the New_BGP speaker uses both attributes to reconstruct the path: AS4_PATH to find 4-byte ASNs on the path, and AS_PATH to find any 2-byte ASNs Old_BGP speakers will have added since the path last passed through a New_BGP speaker.

By adding AS_TRANS to the AS_PATH as a placeholder for any 4-byte ASNs along the route, the AS_PATH continues to accurately indicate the number of AS hops along the path, and therefore preserves its role in the BGP decision process. And although the AS_TRANS might wind up appearing multiple times in the AS_PATH, that ASN only has meaning to a New_BGP speaker – which will also use the AS4_PATH to reconstruct the path – so the loop avoidance function is also preserved: If a loop occurs, the New_BGP speaker using a 4-byte ASN will find its ASN in the AS4_PATH and drop the route.

The AGGREGATOR attribute, when it is needed, is modified similarly. A New_BGP speaker advertising a route to a New_BGP neighbor simply uses a modified version of the attribute that can carry a 4-byte ASN. If a New_BGP speaker advertises a route with the attribute to an Old_BGP speaker, and if the attribute contains a 4-byte ASN, the New_BGP speaker replaces the ASN with AS_TRANS and puts the real ASN in a new optional transitive attribute called AS4_AGREGATOR.

A New_BGP speaker receiving a route with AGGREGATOR and AS4_AGGREGATOR attributes from an Old_BGP neighbor replaces the AS_TRANS in the AGGREGATOR with the real 4-byte ASN in the AS4_AGGREGATOR.

BGP communities are supported in 4-byte ASN environments by using a new Extended Community attribute called the 4-Octet AS Specific BGP Extended Community (EXT_COMM). This Extended Community consists of a 4-byte ASN and a 2-byte arbitrary number; that is, the format is the same as the legacy COMMUNITIES attribute except the ASN part is 4 bytes instead of 2 bytes.

Preparing Your Network (Or Not)

All this interoperability that I’ve spent so many paragraphs describing to you means that New_BGP is backwards compatible with Old_BGP. This is good news if you currently run a network with a 2-byte ASN: You don’t need to do very much, at least in the near term, to get ready for 4-byte ASNs. Your AS will continue running just fine, even when New_BGP neighbors start peering with it.

If you will be acquiring a new ASN any time after the end of 2008 – and especially after the end of 2009 – there are a few things you will need to do to get your network ready for 4-byte ASNs.

First, of course, you need to insure that your router operating system supports New_BGP. Right now (the end of November 2008) the best information I can find is that the following OSs have New_BGP:

· Cisco Systems IOS-XR 3.4 and later (CRS only)

· Cisco Systems IOS-NX (“Nexus”)

· Cisco Systems IOS 12.2SRD for 7200 and 7600

· Cisco Systems IOS 12.5T for 1800/2800/3800, 7200, 7300

· Cisco Systems 12.2SB-Rel6 for 7200, 7300, 10000

· Cisco Systems 12.2SX for 6500

· Force 10 Networks FTOS 7.7.1.0 and later

· Juniper Networks’ JUNOS 9.1 and later

· Juniper Networks’ JUNOSe 4.1.0 and later

· OpenBGPD 3.9 and later

· Quagga 0.99.6 and later

· Redback SEOS (all versions)

Finding specifics of feature support on most any vendor’s website is like a hunt for buried treasure but seldom with a reward at the end, so if you know of other operating systems supporting New_BGP – or have corrections to my list here – please do post a comment. If unsure about your own network, check with your vendor representative.

The biggest challenge with upgrading to New_BGP is that by far the largest installed base of router operating systems is Cisco IOS, and as you can see from the list above the current IOS support is all in early technology (T) or service provider (S) releases, and restricted to certain platforms. Hopefully New_BGP finds its way into mainstream IOS code in early 2009.

Other aspects of your network operations that should be assessed for support of the new ASNs are:

· Any address management applications that reference the ASN

· Any BGP analysis or traffic engineering applications

· Potential effects on MPLS-based VPNs that use Route Distinguishers

· Applications that use Internet Route Registries (IRRs) to set or publish policies

· Routing policies that reference ASNs such as AS path filters and community lists

Do Autonomous Systems with 2-Byte ASNs Need to Do Anything?

As I said, if you currently run a network with a 2-byte ASN your network will continue running with no problems. But there is one thing you should do in the short term to prepare: You will see more and more instances of AS_TRANS making their appearance in AS_PATHs, and if you are a service provider multiple customers might begin peering with you using AS_TRANS. You need to be sure that your operators and troubleshooters know what this special ASN is, and that multiple instances of it in a single AS_PATH or multiple customers peering to you using it are not indicative of a problem.

For the longer term, it is a good idea to put New_BGP capability on your list of requirements as you plan for router operating system upgrades. You can upgrade to New_BGP router by router without effecting your network. Once all of your routers support 4-byte ASNs, you should convert your 2-byte ASN to the 4-byte 0.XX format.

Taking these steps will save you some future headaches by eliminating potential confusions caused by AS_TRANS, giving you clearer visibility to newer peers and across AS paths, improving your routing policy capabilities, and preventing roadblocks when you need to exchange EXT_COMM attributes with New_BGP peers.

Like IPv6, 4-byte ASNs are the future of the Internet. Although all 2-byte ASNs allocated before 2010 will continue to exist, they will eventually be just a part of the new 32-bit format rather than a separate type of autonomous system number.

Everyone should give some thought now to what you need to do to be prepared for this.

Оригинал статьи