[arin-ppml] ARIN-prop-157 Section 8.3 Simplification

[Kevin Blumberg]

Owen,

Here's a starting point for me that estimates end of 2013 for 2-Byte exhaustion (http://www.potaroo.net/tools/asn16/) The most interesting aspect from the report is the number of unadvertised AS numbers. If those were available
in the STLS then you'd be looking at 2020. 


Kevin Blumberg
T 416.214.9473 x31
F 416.862.9473
kevinb at thewire.ca






-----Original Message-----
From: Owen DeLong [mailto:owen at delong.com] 
Sent: Thursday, September 22, 2011 1:19 AM
To: Kevin Blumberg
Cc: David Farmer; arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-prop-157 Section 8.3 Simplification


On Sep 21, 2011, at 7:03 PM, Kevin Blumberg wrote:

> Owen,
> 
> I think there is a need for 2-Byte ASN in 8.3. If someone from ARIN 
> could confirm the number of times in the past 12 months a 4-Byte was 
> returned when the member realized that there upstream or peer didn't support it yet. This was discussed at the last meeting. While I expect it to get better it isn't there yet and there is a finite number of 2-Byte AS numbers available.
> 

Kind of silly, actually. The upstream peer can just peer with them as AS23456 without any real issues.

Nonetheless, ARIN has plenty of 2-byte ASNs still available and any organization which has a 2-byte ASN they don't need can return it to ARIN to be restored to the free pool. There is still a significant IANA 2-byte ASN free pool as well.

Why do we specifically need to add these to 8.3 just because some people are having problems with 4-byte ASNs?

> I'm not convinced that IPV6 resources which are all covered under RSA and freely available need to be in the proposal.
> 

I am, indeed, very convinced that they should not be. I am somewhat less convinced that we should not make some provision for legacy ASNs to be transferred to an organization under an RSA once.

Owen

> Kevin Blumberg
> T 416.214.9473 x31
> F 416.862.9473
> kevinb at thewire.ca
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] 
> On Behalf Of Owen DeLong
> Sent: Wednesday, September 21, 2011 8:00 PM
> To: David Farmer
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN-prop-157 Section 8.3 Simplification
> 
> I would turn this around... I don't believe anyone has presented a strong argument for allowing ASN transfers and I do not believe that the community would benefit from such an action.
> 
> Owen
> 
> On Sep 21, 2011, at 4:48 PM, David Farmer wrote:
> 
>> I think you may have a valid argument for not allowing specified IPv6 transfers there, and even a stronger argument for not allowing inter-RIR specified IPv6 transfers.  However, is there an equally strong argument for not allowing ASN transfers, especially 2-Byate ASNs?
>> 
>> While we do have 4-Byte ASNs now and they are more or less compatible with 2-byte ASNs, much more compatible than IPv6 is with IPv4.  I'm not completely sure the transition to 4-Byte ASNs is actually going any more smoothly than the transition from IPv4 to IPv6 and there may be similar argument to allow the transfer to 2-Byte ASNs as for IPv4.
>> 
>> I'd be interested opinions regarding that issue too.
>> 
>> On 9/21/11 17:40 CDT, Michael Sinatra wrote:
>>> In addition, by allowing IPv6 space to transfer in this manner, the 
>>> careful and sparse allocation methods ARIN and the other RIRs have 
>>> been doing in order to maximize some semblance of aggregation will 
>>> become less effective. A good chunk of the fragmentation in IPv4 
>>> space is due to address blocks that have been acquired over the 
>>> course of time (sometimes through M&A) that are no longer aggregable.
>>> Keeping ARIN in control of IPv6 space can help ensure (or at least 
>>> it won't undermine) the goal of having a minimum number of 
>>> aggregable
>>> IPv6 prefixes announced per ASN. We know that transfer policies will 
>>> increase fragmentation in IPv4 but we think they're a necessary evil.
>>> They're not a necessary evil in IPv6.
>>> 
>>> michael
>>> 
>>> On 09/21/11 14:56, Owen DeLong wrote:
>>>> I disagree. While we did not feel it was appropriate to limit IPv4 
>>>> transfers to legacy space, the existence of legacy space really is 
>>>> the only reason we needed an 8.3 transfer policy. Space covered by 
>>>> RSA should be returned to ARIN and the recipient should get their 
>>>> space directly from ARIN without the need for directed transfers.
>>>> 
>>>> Owen
>>>> 
>>>> On Sep 21, 2011, at 9:01 AM, Matthew Kaufman wrote:
>>>> 
>>>>> Support. There is no reason for IPv4 to be special here. As IPv6 
>>>>> becomes more prevalent, we will undoubtedly see cases where 
>>>>> someone wants to transfer a block of IPv4 space *and* the 
>>>>> associated IPv6 space without selling a portion of their business along with it.
>>>>> 
>>>>> Matthew Kaufman
>> 
>> --
>> ===============================================
>> David Farmer               Email:farmer at umn.edu
>> Networking & Telecommunication Services Office of Information 
>> Technology
>> University of Minnesota	
>> 2218 University Ave SE	    Phone: 612-626-0815
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===============================================
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.