BGP 4-byte ASNs

BGP ASN Overview

ASes are the unit of routing policy in the modern world of exterior routing, according to RFC1930. However, the classical definition of an AS is a set of routers that all exist within a single technical administrative domain. When it comes to BGP, this ASN is the numerical identifier for unique presence for an organization, on the Internet.

The diagram below gives a good logical idea of how ASNs are utilized to provide unique presence within the Internet.


Traditional 2-byte ASN

This ASN is represented in a 16 bit number unsigned integer. It being 16 bits, the maximum number of ASes that can be assigned is limited to 65535. As with RFC1918, and private IPv4 address space – there is a reserved range for ASNs. ASNs 64512 through 65535 are reserved for private use and are not globally routable. Meaning they cannot be advertised across the internet to other potential peers that you’re organization connects to.

New 4-byte ASN

As I’d addressed previously, the fact that RFC1918 has left us at a choke point in terms of IPv4 public addressing, it has been decided that 64512 public AS numbers will not be enough and will eventually run out. So, the powers at be have decided that it is time to address this problem now and nip it in the bud instead of waiting for the same problems we’re now having with IPv4/v6 conversion.

Just as the 2-byte AS number is notated in decimal notation, so is the new 4-byte ASN. However, the notation is known as ASDOT notation. Specifically, the 32 bits will be split into two ‘words’ of 16 bits a piece and notated with a ‘.’ or dot in the middle. An example being 65000.65000. However, should the higher order 16-bits be set to represent the value of decimal 0, traditional 2-byte notation can be used.

With the advent of this idea, RFC4893 was created. This RFC explains the two major attributes that have been added to BGP to support the incremental migration from support from a 2-byte ASN to a 4-byte ASN structure. The first being AS4_PATH which now supports the new 32 bit length, and AS4_AGGREGATE. With this post we’ll be focusing on the AS4_PATH attribute.

It also introduced a new AS_TRANS attribute that is used to substitute a 4-byte ASN when peering with a BGP speaker that has only 2-byte ASN support. More on that below.

4-byte BGP Peering

When BGP is starts the process of forming an adjacency between two BGP speakers, the OPEN message is sent between the two devices. Within this OPEN message the “My Autonomous System” field houses the administratively defined ASN. The OPEN message format can be seen below :

        0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |    Version    |
       |     My Autonomous System      |
       |           Hold Time           |
       |                         BGP Identifier                        |
       | Opt Parm Len  |
       |                                                               |
       |                       Optional Parameters                     |
       |                                                               |

As shown above, the traditional BGP “My AS” field is 16 bits, or 2-bytes.

Before we get into the specifics behind how a BGP speaker advertises its 4-byte ASN to another BGP speaker, we have to address a limitation that was built into BGP from its inception. BGP was designed to terminate the peering with a neighbor should it receive an OPEN message with an Optional Parameter that isn’t supported. This seriously inhibits the introduction of future capabilities being incorporated into the BGP protocol as a whole. Limiting the future extensibility of the protocol.

With this, RFC2842 was created that defines a new “Capabilities” Optional Parameter that will be advertised in the OPEN messages. Allowing for some extensibility to be built into BGP. BGP peers will then list supported Optional Capabilities and peer accordingly. The 4-byte ASN Capability code has been assigned as number 65 by the IANA. The rest of the Capability codes can be found here. With the advent of this new Capability code, we’re able to now use 4-byte ASNs within a BGP topology.

We are then able to peer as traditional 2-byte BGP peers would. Simply configuring the neighbor addressing and what AS they’re a part of.

2 and 4-byte Support and Interconnection

Things get interesting when having to deploy both 2-byte and 4-byte ASNs. RFC4893 provides the explanation for how this process takes place.

As is defined within RFC4893, for the remainder of this post we’re going to refer to BGP speakers that only support 2-byte ASN’s as OLD BGP speakers, and devices that are configured for 4-byte support as NEW BGP speakers.

RFC4893 states that when a NEW BGP speaker is peered with an OLD BGP speaker it is to advertise the AS_PATH attribute in the old 2-byte ASN form. This is where the AS_TRANS substitution will occur. The NEW BGP speaker knows the limitation of the OLD BGP speaker and will swap the 4-byte ASNs in the advertisement with the AS_TRANS attribute, or as defined within RFC4893, the reserved ASN 23456 . The NEW BGP speaker is also required to send the AS4_PATH attribute at the same time. This AS4_PATH attribute will only consist of the 4-byte ASNs that are advertised from upstream NEW BGP speakers.

NEW BGP speakers are to be prepared to receive both an AS_PATH and AS4_PATH attribute from an OLD BGP speaker. Upon receiving both the AS_PATH and AS4_PATH attribute, the NEW BGP speaker will then merge the AS_PATH and AS4_PATH attribute.

This process allows OLD BGP speakers to co-habitate with NEW BGP speakers and still preserve the new 4-byte ASN between NEW BGP speakers.

An example of the process can be seen below :

BGP 4-Byte ASN