<div dir="ltr">I wanted to summarize what I heard at the open mic and give the wider community a chance to comment.<div><br></div><div><div>Questions:</div><div><br></div><div>1. Is it in the best interest of the Internet for ARIN to give out 2-byte ASNs by default?</div>
<div><br></div><div>Should we use up the 2-byte ASNs, or try to conserve them for those who need them?</div><div><br></div><div>2. Should an RIR be forced to burn through 2-byte ASNs in order to qualify to get additional ASNs?</div>
<div><br></div><div>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?</div><div><br></div><div>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?</div>
<div><br></div><div>Answers:</div><div><br></div><div>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.</div>
<div><br></div><div>There was some support for giving each RIR (who wants it) an equal share of the remaining 2-byte ASNs.</div><div> <br></div><div><br></div><div>Background:</div><div><br>Global policy for the Allocation of ASN Blocks to Regional Internet Registries<div>
<br></div><div><a href="https://www.icann.org/en/resources/policy/global-addressing/global-policy-asn-blocks-21sep10-en.htm" target="_blank">https://www.icann.org/en/resources/policy/global-addressing/global-policy-asn-blocks-21sep10-en.htm</a></div>
<div><br></div><div>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. </div><div><br></div><div>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).</div>
<div><br></div><div>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.</div><div><br></div><div>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. </div>
<div> </div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>It is also possible that the next requestor could take all of the available 2-byte ASNs.</div><div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>Thanks,</div><div><br></div><div>__Jason<br clear="all"><div><br></div>-- <br><font color="#555555" face="'courier new', monospace"><div><span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">_______________________________________________________<br>
</font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br>
</font></div></span></div></font>
</div></div></div></div>