I wanted to summarize what I heard at the open mic and give the wider community a chance to comment.
Questions: 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 need them? 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 4-byte ASNs? 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? Answers: 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. Background: Global policy for the Allocation of ASN Blocks to Regional Internet Registries https://www.icann.org/en/resources/policy/global-addressing/global-policy-asn-blocks-21sep10-en.htm 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 65535. 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 utilized. 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 2-byte ASNs. 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 request. Thanks, __Jason -- _______________________________________________________ Jason Schiller|NetOps|[email protected]|571-266-0006
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
