[arin-ppml] ARIN 2-Byte ASN inventory and issuance
chris at semihuman.com
Mon Apr 11 18:05:19 EDT 2016
I’d argue that doing so ignores the fact that 2-byte vs 4-byte AS numbers (yes, I’m still using that terminology, so sue me) are handled fundamentally differently by the BGP protocol. As such, this isn’t a place where we can effectively boil the ocean and force providers to update their hardware via policy.
As such, I’d far prefer that *as available* we continue to keep 2-byte ASNs in reserve for providers who can document their reasons for not being able to support having a 4-byte ASNs. Obviously there will be a day where those are all gone and then we’ll have no choice but to force operators to run compliant hardware/software.
Note I’m making it clear that this isn’t just a matter of software; there’s quite a bit of gear out there on the internet that doesn’t have available software at all that supports 4-byte ASNs. And there are definitely operators that don’t have the budget to swap it out.
This isn’t a case of inefficiency, it’s simply the fact that many providers are stuck using old hardware. Given negligible cost to accommodate, I have no problem doing so.
> On Apr 11, 2016, at 2:53 PM, Owen DeLong <owen at delong.com> wrote:
>> On Apr 11, 2016, at 14:38 , John Curran <jcurran at arin.net <mailto:jcurran at arin.net>> wrote:
>> On Apr 11, 2016, at 5:06 PM, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
>>> On Apr 11, 2016, at 12:24 , John Curran <jcurran at arin.net <mailto:jcurran at arin.net>> wrote:
>>>> Since parties coming to ARIN are distinguishing between these classes of 4-byte ASNs
>>>> and come back explicitly asking for one ≤65535, are you suggesting that ARIN not hold
>>>> these lower ones to be able to satisfy such requests?
>>> I believe that we, more than any other region, have been lazy in our adoption of current internet technologies to the detriment of the internet at large.
>>> I believe that continuing to facilitate this is not providing a useful service to the internet as a whole.
>> Just to be clear, you feel that ARIN registry policy which rapidly depletes the
>> lower range of 4-byte ASNs would be technically sound and facilitate fair and
>> impartial number resource administration?
> No. I believe that ARIN registry policy which ignores any previous distinction
> between ASNs ≤65535 and ASNs ≥65536 is harmful. I believe that a policy which
> makes no distinction and hands them out as if they were a single pool of 32-bit
> numbers is in the best interests of the community.
> At some point there will no longer be available ASNs ≤65535. So be it. That
> date should neither be accelerated nor decelerated by ARIN policy.
>> It would be helpful if you could explain how in some detail, given that there
>> appears to be sufficient number of lower range 4-byte ASNs for those who
>> require such for their operations, and further that the supply appears to be
>> sufficient for quite some time (potentially till there is greater acceptance
>> and far fewer hurdles with the use of higher range 4-byte ASNs…)
> So far, I haven’t seen so much a requirement as a convenience request for those
> lower numbers.
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML