[LACNIC/Politicas] 32 bits ASN [EN]

[Ricardo Patara]

32 bits ASN

Introduction:

Since January 1st 2007 LACNIC, along with the other RIRs, is assigning to its members Autonomous System Numbers (ASNs) of 32 bits length.

Until that date, the ASNs assigned were of 16 bits length, which allowed a maximum of about 65000 ASNs.

With the possibility of a foreseen exhaustion of the 16 bits ASNs space, in 2001 the first studies and proposals to expand ASNs space to 32 bits were initiated.

That work was concluded in 2007 when the IETF (Internet Engineering Task Force) published the document named RFC 4893. This document indicates the new ASN format, its utilization in routing protocols like BGP and also its interaction with other systems with no support to it.

Since that date, IANA has allocated to the RIRs blocks of 32 bits ASN for further assignment inside each region.


Policy:

In 2006 the first policy proposals to assign 32 bits ASN started to be discussed inside each RIR. Those proposals kept the need of multihoming connexion or a unique routing policy as the criteria to justify an ASN assignment.
Such policy also includes criteria for the transition from 16 bits ASN assignment to 32 bits ASN assignment.

The policy adopted in the LACNIC region (which is similar to the one adopted in other regions), establishes that after January 1st 2007 32 bits ASN would only be assigned when clearly expressed in the request. Otherwise, 16 bits ASN would be assigned by default.

Also according to this policy, this criterion will change after January 1st 2009. When requests for ASN will by default qualify for the assignment of 32 bits ASNs. While 16 bits ASNs will only be assigned when clearly expressed in the request.


Current Situation:

It is important to highlight that even if there is availability of 16 bits ASNs, after January 2009, they will only be assigned when clearly requested.

Specially when it is known that there are systems and equipments with no support to 32 bits ASNs yet, what would affect organizations planning to adopt redundant routing policy, who will need ASNs, and in some cases, new routing equipments as well.

Therefore, even considering this is not an urgent problem as projections indicate there will 16 bits ASNs available for 2 or 3 more years, still this is something that requires special attention.

In this current scenario we believe its is important to recommend that during new networks projects and planning to take into consideration the need for a 32 bits ASN, what could impact in decisions for new network equipments or systems acquisition.

It is also recommended that administrators of already deployed networks verify with their network equipments and systems suppliers about the support for 32 bits ASN in future versions of their products.

Although the transition mechanisms allows old systems to work with new ASN format, without any update, it is still important to support new ASN version in order to count with tools that network administrators are familiar with.

And lastly, there are some important discussions in the global community about the 32 bits ASN representation schema. Until now the representation chosen is the one named “as-dot2” which represents a 32 bits ASN as the following: <high order 16 bits value in decimal>.<low order 16 bits value in decimal>. The utilization of this representation has been discussed due to difficulties this impose to work with regular expressions already implemented in several tools, and it is being promoted to change the  representation “as-plain” where the 32 bits ASN would be represented as decimal value in the range 0 -  4294967295.
As a way to contribute in this debate we believe it is important to receive comments from community in our region about this discussion.