[arin-ppml] 2-byte and 4-byte ASNs
jschiller at google.com
Fri Apr 18 16:21:26 EDT 2014
I wanted to summarize what I heard at the open mic and give the wider
community a chance to comment.
1. Is it in the best interest of the Internet for ARIN to give out 2-byte
ASNs by default?
Should we use up the 2-byte ASNs, or try to conserve them for those who
2. Should an RIR be forced to burn through 2-byte ASNs in order to qualify
to get additional ASNs?
Should an RIR that has used all the 2-byte ASN be prevented from getting
more ASNs until their total utilization is higher from giving out more
3. There are just under 500 2-byte ASNs left in the IANA pool. Should the
RIRs each get 99 of these? Or should the next requestor take all of the
2-byte ASNs and the balance of the block of 1024 in four-byte ASNs?
The ARIN community continues to suggest there is no hardware reason that
would prevent support of 4-byte ASNs. The community desires that we use up
the 2-byte ASNs and continue to send a message that code upgrades to
support 4-byte ASNs are now required.
There was some support for giving each RIR (who wants it) an equal share of
the remaining 2-byte ASNs.
Global policy for the Allocation of ASN Blocks to Regional Internet
Starting in 2011, this policy requires IANA and the RIRs to maintain a
single 32-bit ASN pool and not differentiate between ASN below or above
ARIN practice is to suggest organizations that request an ASN to choose a
four byte ASN if practical and will otherwise get a 2-byte ASN. (There was
a brief period where ARIN reversed the default giving out 4-byte ASNs
unless a 2-byte was specifically requested).
Leslie has thrice advised the community that 4-byte ASNs continue to get
returned due to the inability for the requester or their upstream to
support 4-byte ASNs.
Each time the ARIN community has responded that there is no hardware based
technical issue why 4-byte ASNs cannot be supported, and that the community
wants to send the message that everyone needs to complete the appropriate
code upgrades and support 4-byte ASNs.
This means in the ARIN region, we will likely deplete 2-byte ASNs and still
have available 4-byte ASNs. If the number of available 4-byte ASNs is
large enough, the total ASN utilization will be below 80% and ARIN will not
qualify to get additional ASNs from the IANA, until more 4-byte ASNs are
In regions where 4-byte ASN usage is greater then 2-byte ASN usage, these
RIRs may find they have assigned all of their available 4-byte ASN and due
to under utilized 2-byte ASNs may not qualify to get additional 4-bye ASNs.
In this case they may be forced to assign 2-byte ASNs to organizations who
could otherwise use a 4-byte ASN.
It is also possible that the next requestor could take all of the available
The ASO AC provided advice that a block of 1024 could consist of a
non-contiguous rage of ASNs below the value of 65525 and above the value of
65525. This was based on community input, a desire to not strand 2-byte
ASNs in the IANA, and the understanding that there is no aggregation
benefit from round numbers. This advice was provided in the context of
using up the 2-byte ASNs. LACNIC asked for half of their block to be
2-byte and half to be 4-byte, and IANA complied.
It is now possible the same advice will be leveraged to allow the RIR to
request only 99 2-byte ASNs and the balance in 4-byte ASNs, allowing IANA
to hold back one last round of 2-byte ASNs for each RIR upon their next
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML