[arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses

David Farmer farmer at umn.edu
Mon Feb 14 20:53:58 EST 2011

On 2/14/11 15:03 CST, Martin Hannigan wrote:
> On Mon, Feb 14, 2011 at 3:32 PM, Benson Schliesser
> <bensons at queuefull.net>  wrote:
> [ snip ]
>> Legacy and other addresses returned should be treated the same.
>> Once an address is returned to ARIN, it is no longer a legacy address.
>> This policy does not make sense so long as it singles out legacy addresses.
>> I agree with Owen on this.
>> ARIN should only accept returned legacy addresses from holders in the ARIN
>> region.  But, once accepted, that address space has been effectively
>> transferred to ARIN.
> Here's what the text actually says:
> "5.1 Returned Legacy Addresses
> Legacy IPv4 addresses returned to or recovered by ARIN will be made
> available for registration and distribution in the ARIN region within
> thirty days of their receipt."
> There's no argument here that once an address is added to ARIN's
> inventory it's a done deal. The proposal doesn't seek to do otherwise
> nor does the language imply that it would.
>> It is up to ARIN policy to decide whether to return
>> that block to IANA, reallocate to new requests, etc.  And there are no
>> technical reasons to treat address blocks differently, as far as I'm aware.
> All that this proposal does is codify the instruction to return these
> addresses to ARIN inventory and use them. The current situation is
> ambiguous and open to interpretation. This has nothing to do with the
> IANA at all. In fact, in the absence of a global policy, this simply
> makes the instruction "use the addresses".
> With regards to accepting legacy addresses from entities "only" in the
> ARIN region, I think that's a fair point and will put it on the list
> of final modifications.

By my interpretation your text does one additional thing than what you 
state above, it specifics that ARIN does this within 30 days, where I 
believe the current operational practice is 6 months.  Do I interpret 
your intention correctly?  If you believe I'm interpreting that wrong, 
please explain.

It is this apparent change in operational practice that I believe has 
many people concerned, and asking why this policy should only apply to 
Legacy space.

If you remove the clause "within thirty days of their receipt," then I 
believe the text only does what you describe above.

As I said before, I find the 30 day clause an interesting change in and 
of itself, but I cannot support that change applied to Legacy address 
space only.  If only because it would seem if someone voluntarily 
returned non-legacy space one could interpret the policy as intending 
current operational practice of 6 month be applied in that case, I'd 
kind of like to see that be 30 days too.

So, I believe that leaves two choices;

1.  Remove to 30 day clause from this policy text, or;
2.  Add text that applies the 30 day clause to all address space 
returned to ARIN

#1 is I believe clean and simple and what you state your intentions are 

#2 is much more complicated, because it will conflict with the RSA and 
LRSA in some situations, and is probably to short for non-voluntary 
returns anyway.  Therefore, option #2 is probably not a good idea if you 
want to keep things simple.

By the way, I believe the text above, with the 30 day clause only 
applied to Legacy addresses, conflicts with the LRSA.  I believe, the 30 
day clause could not be applied to any addresses which ARIN would 
reclaim for non-payment from anyone who has signed an LRSA, since the 
clauses in the LRSA would have precedence.  Since in the LRSA the LRSA 
is given legal precedence over policy changes that would conflict with 
it, the main risk is that this will create confusion and 
misunderstandings within the community, which it would be nice to avoid.

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

More information about the ARIN-PPML mailing list