[arin-ppml] 2-byte and 4-byte ASNs

[Jason Schiller]

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|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140418/3071fcd5/attachment.htm>