[ppml] Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification

Andrew Dul andrew.dul at quark.net
Fri Jan 26 12:15:42 EST 2007


At 03:27 PM 1/26/2007 +0100, Leo Vegoda wrote:
>On Jan 25, 2007, at 11:38 PM, Andrew Dul wrote:
>
>[on deleting 6.5.4.2]
>
>> While most LIRs are usually reasonable, to me it seems important to  
>> include
>> defined and somewhat rigorous criteria for the assignment of  
>> multiple /48s
>> and a requirement for the LIR to record this justification for later
>> auditing by the RIR when an LIR returns to the RIR for an additional
>> allocation.
>>
>>> Rationale:
>>>
>>> The current text requires the LIR to justify to the RIR/NIR when
>>> assigning multiple /48s to a single end site. It seems that the  
>>> reason
>>> for this requirement is the lack of experience, which seems  
>>> unreasonable
>>> after a few years this policy has been implemented, even if may  
>>> not have
>>> been specific cases which used this policy section.
>>>
>>
>> I think the section was reasonably written as a throttle to  
>> excessive IPv6
>> assignments to endsites by LIRs.
>
>While I appreciate the explanation that 6.5.4.2 was intended to  
>throttle excessive IPv6 assignments to end sites, it has always been  
>possible to work around it using section (6.5.3 LIR-to-ISP  
>allocation). It specifically states that there "is no specific policy  
>for an organization (LIR) to allocate address space to subordinate  
>ISPs. Each LIR organization may develop its own policy for  
>subordinate ISPs to encourage optimum utilization of the total  
>address block allocated to the LIR."
>
>This has always allowed any ISP with an IPv6 allocation to define any  
>downstream customer as an ISP and sub-allocate rather than assign space.
>

Sounds like we need to work on section 6.2 and try to define an ISP and
also define some guidelines for LIR-to-ISP allocations.  I know that is
hard, but if we don't we leave open the option for LIRs to allocate huge
blocks to "ISPs"





More information about the ARIN-PPML mailing list