By Andree Toonk | August 17, 2008
Last week I was verifying the 32bit AS number support on our new MX480 Junipers. After reading some RFC, to understand it better I decided to write down my understanding of it. Because it might be useful for others as well, I decided to post it on my Blog.
As of January 2009, that is 3 months from now, when you go to your RIR (Ripe, Arin, Apnic. Etc) for an autonomous system number, you will receive a 4 bytes AS number. So it’s very likely that in the very near future we will be connecting customers with 4bytes AS numbers to our network. Time to find out what exactly that means, what are the implications and what do we as an ISP need to do, to be able to support that.
AS numbers as we know them today are 16bits, or 2 bytes numbers and used by networks to identity them on the “Internet”. As we are running out of free ASnumbers, it was time to increase the amount of AS numbers from 2bytes (0-65535) to 4 bytes (0-4294967295).
A change like this would normally require changes on all the routers which are participating in the Internet routing (DFZ) or are using BGP to connect to their ISP. This is because their software would now need to support 4 bytes numbers instead of 2 bytes. If not all them would support this the Internet routing system would be divided in 2 separate incompatible camps, a 2 bytes side and the 4 bytes side. This, of course is unacceptable and fortunately they came up with a transition mechanism that eliminates the need for a ‘flag day’.
How does this transition mechanism work? Well it’s probably best to explain this by looking at a real live example on our BCNET router in Vancouver. There are some ISP’s that already announce a prefix with a 4 bytes ASnumber:
email@example.com> show route aspath-regex ".* [65536-4294967295] .*" < SNIP > 2403:2000::/32 *[BGP/170] 2w4d 03:31:53, localpref 500 AS path: 6509 11537 22388 7660 2500 18146 131081 I > to 2001:410:1001:7::2 via xe-4/0/0.3906
Here we see the IPv6 prefix 2403:2000::/32 announced by the AS 131081, this is a 4 byte AS number (because it’s higher then 65535).
The output above is from a router with software support for 4 bytes AS. Now let’s take a look at how this prefix looks like from a router without 4bytes AS support.
atoonk@Gigapop> show route aspath-regex ".* 23456 .*" < SNIP > 2403:2000::/32 *[BGP/170] 2w4d 03:20:15, localpref 500 AS path: 6509 11537 22388 7660 2500 18146 23456 I > to 2001:410:101:b::1 via ge-0/0/0.25
As you can see above, according to the output the same prefix is now being announced by AS23456. This is a special reserved prefix, called AS_TRANS and an important part in the transition mechanism.
I guess by now you can already kind of guess how the transition mechanism works, basically the 4 bytes ASnumber is being replaced by the special 2bytes AS, AS_TRANS i.e. AS23456. The AS path in the bgp packets, only show 2 bytes AS numbers, however there is a new field defined used to represent the 4bytes AS path. This is a transitive optional attribute called AS4_PATH. It’s only understood by routers with 4 bytes AS support and they will use it the reconstruct the 4bytes AS path as seen in the first example. All routers that do not understand this field (which is ok, it’s optional) should not alter it and sent it to the next peer (transitive).
So in the Old BGP world (2bytes) New BGP speakers (4byte capable) will be represented as AS_TRANS, I,e, AS23456. So expect to see that AS more and more in the BGP tables
So basically you don’t need to be afraid to fall of the Internet if your BGP router doesn’t support 4bytes AS numbers. That’s good to know right!? . (Having said that, understand that it means you’ll loose AS-path filtering capability, and it’s harder to see which AS is actually announcing the prefix)
Direct peering between Old BGP speaker and New BGP speaker
So what happens if one of your customers has a 4bytes AS and your router only supports 2 bytes autonomous system number . In this case you would configure a direct peering between a 2bytes AS and a 4byte AS using AS_TRANS (AS23456). The 4 bytes AS will detect that ISP doesn’t support 4 bytes AS, because of the capability code. The only way to setup a peering between a Old BGP speaker and a New BGP speaker is to define this as a peering with AS23456 (which is 2bytes). This will work fine, also if you have multiple peerings with AS23456 and these are actually different autonomous systems. Although it will work, it probably gets confusing if you have multiple of these peerings.
Representation of 32bit AS numbers
Then there seems to be a discussion going on of how to represent the 4 bytes AS number?
Just as a plain number? Maybe as a dotted decimal? Some people suggested to use 2 decimals separated by a colon. However that looks a lot like how we use communities nowadays, so that’s to confusing. The common agreement seems to be to use the ASdot representation, this represent the current 2 bytes AS numbers (less then 65536) just the way we are used to, as a decimal, such as AS271, or AS1103. 4bytes AS numbers will be represented as for example 1.10
ASdot refers to a syntax scheme of representing AS number values less than 65536 using asplain notation and representing AS number values equal to or greater than 65536 using asdot+ notation. Using asdot notation, an AS number of value 65526 would be represented as the string “65526” and as AS number of value 65546 would be represented as the string “1.10”.
If we look at the examples I showed in the beginning that came from our Juniper routers, it seems that Juniper doesn’t implement this representation, instead it uses ASplain.
The above is a simple explanation of the implications of using 4bytes AS numbers. If you would like to know the details, about the impact for loop detection risks, aggregation, communities I suggest you’d read RFC 4893.
How about vendor support? Juniper supports 4 bytes AS numbers as of release 9.1. Also see the release notes (look for: BGP support for 4-byte autonomous system numbers)
Cisco is a bit behind, but it’s my understanding that at the time of writing it’s supported in the current IOS-XR release as well as NX-OS (Nexus). Cisco IOS: Target is 12.0(32)S12 and 12.0(32)SY8, that’s the target, It’s going to be in a 12.0(33)S rebuild for sure.
For those of you who use software BGP routers, there are patches available for Quaga as well as OpenBGPd.
Autonomous System numbers assignments
IANA is the organization responsible for assigning AS numbers to the RIRs. Below you’ll find a list of ranges assigned to the RIR’s by IANA. The nice thing is that it’s really easy now by just looking at the AS number by which RIR the ASnumber was assigned:
3.0-3.1023 RIPE NCC
If you’d like to read more, visit the 4-byte AS number information pages of APNIC at
 Canonical Textual Representation of Four-octet AS Numbers