The internet growth is awesome, day by day people recognizes how internet is important in their daily personal and business life and even for their culture, so the internet has a good bit of newbie everyday which depleted some internet resources such as IPv4 address space and the BGP AS numbers (IPv4 exhaustion dilemma is more severe than the BGP ASN dilemma).
The BGP AS number space is a finite amount of address space. It is defined as a 16 bit integer and hence limited to 65535 unique AS numbers.
Not all can be used!! Out of the AS number space there are 1023 numbers are reserved for local or private use, and 3 are reserved for special use. The remaining range which is 64510 numbers are available for publicly use on the internet, today there are 56318 AS numbers already allocated (according to http://www.potaroo.net/tools/asns ).
The 4-byte ASN
In 2007 IETF standardized the BGP support for 4-octet AS number space in RFC4893, following the IETF standards, IANA has extended the AS number field to 32 bits which increasing the pool size from 65535 to 4294967295.
(The 4-byte AS number space is just an extension so it covers the old range and provides more.)
RIR ASN allocation policy
1/1/2007 – 31/12/2008 LIRs can ask for an ASN16 or ASN32 RIRs will give an ASN16 by default, ASN32 on request
1/1/2009 – 31/12/2009 LIRs can ask for an ASN16 or ASN32 RIRs will give an ASN32 by default, ASN16 on request
After 1/1/2010 RIRs will always give an ASN32
The 32-bit ASN range is 0- 4294967295 which is covering the 16-bit numbers, so currently assigned 16-bit AS numbers are converted into 32-bit ASN by setting the two high-order octets of the 32-bit field to zero (2018=0.2018) And Such a 4-octet (16-bit after convergence) AS numbers are said to be mappable to a 2-octet AS number.
2-byte and 4-byte ASN range and naming
- AS numbers in range 0-65535 are called 16-bit ASNs
- AS numbers in range 0- 4294967295 are called 32-bit ASNs
- AS numbers in range 65536 – 4294967295 are called 32-bit-only ASNs
- AS number 23456: AS_TRANS
The AS_Trans used to hide the 4-byte ASN in the AS_Path and Aggregator attributes when a 4-byte aware BGP speakers (New Speaker) sending updates to unaware BGP speaker(Old speaker), also this AS number is used by the OLD BGP speakers when configuring a BGP session with NEW BGP speakers.
RFC 5396 standardized two formats with three concepts (Each vendor uses its preferred format but they are often support all)
Representing all ASN numbers using decimal integer notation , easy and simple, using this format all ASNs displayed as they are in simple notation format (1=1, 65535= 65535, 75535=75535, 11000000 = 11000000)
Representing all AS numbers using notation of two integer values high-order 16bit and low-order 16bit separated by dot”.”, this might seems more readable than the AS-Plain format but decimal to binary conversation is needed, the high-order bit of all mappable AS numbers started with 0.xxxx, ex ASN 65535 = 0.65535 but ASN 65539 = 1.3 likewise ASN 131080 = 2.8
Representing all AS numbers equal or less than 65535 in AS-Plain 65526 = 65526 whereas any ASN equal or greater than 65536 represented in AS-Do+ format 65550 = 1.14.
What is new in BGP?
All BGP parts those are relevant to the ASN need some extension, such extension should comprises (1)How peers will confirm their support of the 4-byte, (2)How if one of them doesn’t support it, (3)How the update message will carry the 4byte-ASN?
BGP carries the ASN in the “My Autonomous System” field of the OPEN message, in the AS_PATH attribute, AGGREGATOR attribute, and Communities attribute of the update message, Some modifications need to be done on those fields to accommodate the 4-byte AS number with a solid backward compatibility to be used during transition.
After a TCP session is established the first message sent by each side is an open message if the open message is accepted a keepalive message confirming the open message is sent back, the keepalive message doesn’t carry BGP information (Message header only) but Open Message does.
In the open message the My AS field carry the ASN but it’s 16bit only so how could it carry 4byte ASN? meanwhile the Open message can’t be changed to allow backward compatibility with 2-byte peers, So a new 4-byte Capability advertisement had added to decently negotiates the 4byte support and carry the 4byte ASN, the peer who supports the 4byte AS sends this capability ADV in its open message along with it’s 4byte ASN if one of the peers doesn’t accept it, they will ignore the Capability and proceed with ordinary open message.
The path attribute field is variable, so AS_Path and Aggregator attributes are capable to convey the 4-byte ASN, But OLD BGP speakers won’t understand the 4-byte ASNs in the AS_Path attribute , so we need to preserve the AS-Path numbers information when either peering or passing across BGP speakers that aren’t able to understand 4-byte AS information.
So a new attributes had generated to preserve the AS_Path information with OLD BGP speakers “4-byte unaware” (Only if a 4byte ASN in the AS_Path attribute)
Well does this mean that the AS_path attribute will convey the 2-byte ASNs and the AS4_Path will convey the 4-byte ASNs?
NO if it is true the internet will be having routing loops, IANA had reserved ASN 23456 to preserve the 4-byte ASN information in the AS_Path which alerts 4byte capable router to instructs and augments both the AS4_Path and AS_Path attributes to construct the whole AS path.
The aggregator attribute is optional transitive attribute that consistis some information about the bgp hop formed the aggregation, The BGP speaker who performs route aggregation may add the aggregator attribute which shall contain its own IP address and AS number.
When a New BGP speaker performs aggregation it will add its own IP address and 4-byte ASN in the aggregator attribute, if the ASN is mappable one an ordinary aggregator attribute will be send to both New and OLD speakers, but if the ASN of the speaker is 4-byte so when the new speaker forming an update for OLD BGP speaker the aggregator attribute will be send with ASN 234556 (AS_Trans) along with a new attribute called AS4_aggregator that carries the actual 4-byte AS number and IP address.
Extended Community Attribute
A new 2 4-byte BGP extended communities had been generated, one for 40-byte RT and another one for 4-byte SOO, An AS domain that uses a 2-octet AS number could use either 2-octet or 4-octet AS specific extended communities. This is undesirable, as both communities would be treated as different, even if they had the same Sub-Type and Local Administrator values.
It is recommended to avoid inconsistencies between 2-octet and 4-octet specific extended communities, the AS domain that use 2-octet AS numbers should use 2-octet AS specific extended communities rather than 4-octet AS specific extended communities.
IOS and JUNOS 40byte aware Releases
Cisco IOS Cisco IOS (15.1XB, 15.0M, 12.4T, 12.2XNE, 12.2SXI, 12.2SRE, 12.0SY, 12.0S)
Juniper JUNOS (9.1 onward)
I hope it was informative post.
Mounir Mohamed, CCIE No.19573