[arin-ppml] Support for ARIN Proposal 2011-3

David Farmer farmer at umn.edu
Thu Apr 7 02:27:54 EDT 2011


Personally would prefer optional renumbering, but mandatory return of 
any unused blocks,
similar to what is in 6.5.8.4 from Policy 2010-8;

-----
6.5.8.4. Consolidation and return of separate assignments

Organizations with multiple separate assignments should consolidate into 
a single aggregate, if feasible. If an organization stops using one or 
more of its separate assignments, any unused assignments must be 
returned to ARIN.
-----

And that is incorporated in 6.5.6(c) from this Draft Policy 2011-3.

-----
If ARIN can not expand one or more existing allocations, ARIN shall make 
a new allocation based on the initial allocation criteria above. The LIR 
is encouraged, but not required to renumber into the new allocation over 
time and return any allocations no longer in use.
-----

So I believe the text in question is;

-----
Add the following to 6.5.7

LIRs which received an allocation under previous policies which is 
smaller than what they are entitled to under this policy may receive a 
new initial allocation under this policy provided that they agree to 
renumber into that new allocation and return their prior allocation(s) 
within 5 years. If possible, ARIN will simply expand their existing 
allocation rather than requiring renumber and return.
-----

Which is added to 6.5.7 from the current NRPM;

------
6.5.7. Existing IPv6 address space holders

Organizations that received /35 IPv6 allocations under the previous IPv6 
address policy (RIRv6-Policies) are immediately entitled to have their 
allocation expanded to a /32 address block, without providing 
justification, so long as they satisfy the criteria in Section 6.5.1.1. 
The /32 address block will contain the already allocated smaller address 
block (one or multiple /35 address blocks in many cases) that was 
already reserved by the RIR for a subsequent allocation to the 
organization. Requests for additional space beyond the minimum /32 size 
will be evaluated as discussed elsewhere in the document.
-----

Is there any reason we need to keep the old 6.5.7 text with the 
references to the old /35s?

Couldn't we completely replace and rename 6.5.7 with something like the 
following?

------
6.5.7 Existing IPv6 Allocations

(a) LIRs that received an IPv6 allocation under a previous version of 
policy that is smaller than what they are entitled to under the current 
policy may receive a new initial allocation under the current policy.

(b) Where possible ARIN will make subsequent allocations by expanding 
the existing allocation.

(c) If ARIN can not expand one or more existing allocations, ARIN shall 
make a new allocation based on the initial allocation criteria above. 
The LIR is encouraged, but not required to renumber into the new 
allocation over time, but must return any allocations no longer in use.
-----

This would cover the old /35s, if there are any left, and any /32s or 
larger from the current policy.  This removes old crufty language, 
removes the renumbering requirement, while harmonizing the language with 
that used in section 6.5.6 Subsequent Allocations to LIRs from this 
Draft Policy.

What to you think?

On 4/6/11 23:44 CDT, Owen DeLong wrote:
> As the author of the proposal, I am all for removing that clause.
>
> Full disclosure, my day job stands to benefit substantially from
> removing that clause.
>
> The clause was placed there to parallel previous policies based on
> community opposition in the past to duplicate assignments without
> requirement for return. I think this is more applicable in IPv4 than
> in IPv6.
>
> In short, I support Dan's recommended change.
>
> Owen
>
> On Apr 6, 2011, at 7:27 PM, Alexander, Daniel wrote:
>
>>
>> There is a discussion on the AC list regarding 2011-3 that I would like to
>> bring to this mailing list. Please let me know your thoughts.
>>
>> In the proposed language for section 6.5.7 there is a renumbering clause,
>> "...provided that they agree to renumber into that new allocation and
>> return their prior allocation(s) within 5 years."
>>
>> Does anyone take issue if this condition were missing from the proposal
>> since it applies to a limited set of cases. ARIN's method of assignment
>> should allow for most organizations, who already have allocations, to
>> expand into the new policy without a renumber requirement.
>>
>> Should those providers that would like to utilize this new approach, but
>> are bound because their existing allocations are adjacent to other ARIN
>> assignments, incur the renumbering costs and obligations simply because
>> they deployed IPv6 earlier in the policy evolution?
>>
>> Sincerely,
>> Dan Alexander
>>
>>
>> On 4/4/11 2:24 PM, "Steve Howard"<showard at paulbunyan.net>  wrote:
>>
>>> I cannot attend ARIN XXVII, but would like to publicly state my support
>>> for ARIN proposal 2011-3.
>>>
>>> This proposal addresses issues that we have encountered in planning our
>>> IPv6 deployment. We have about 50 POPs (mostly rural) ranging in size
>>> from a few customers to several thousand. A /32 is too small for us to
>>> use and leave room for future expansion without re-numbering later.
>>> Renumbering seems like it would be easier with IPv6 than IPv4, but it is
>>> still a hassle for our customers that we would rather avoid. We have
>>> delayed our deployment of IPv6 while we wait to see what happens with
>>> proposal 2011-3.  It makes more sense for us to deploy IPv6 right the
>>> first time!
>>>
>>> My hope is that 2011-3 moves forward and we can get a new assignment in
>>> time to have IPv6 available to several thousand customers prior to World
>>> IPv6 day!
>>>
>>> Thanks,
>>>   Steve
>>>
>>>
>>> ---
>>> Steve Howard
>>> Paul Bunyan Communications
>>> http://paulbunyan.net

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