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

[David Farmer]

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
===============================================