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

[Member Services]

Hi Andrew-

ARIN has not registered a large number of IPv6 reassignments.  However, 
of those that we have registered, many of them are for initial 
reassignments of multiple /48s to the same organization.  In fact, out 
of a total of 115 reassignment registrations, 56 of them are larger than 
a /48.

To date, we have not seen requests for additional reassignments of /48s 
to the same organization. Our registration software however, is 
programmed to flag additional reassignments of this type.

Currently, ARIN is not asking for justification for these larger initial 
reassignments.  The policy text as written is unclear and contains no 
criteria for the RIR to use to assess justification.

Regards,
Leslie Nobile
Director, Registration Services
American Registry for Internet Numbers



Andrew Dul wrote:
>>Policy Proposal Name: Changes to IPv6 policy - removal of "multiple /48"
>>justification
>>
>>Author: Jordi Palet Martinez
>>Proposal Version: 1
>>Proposal type: delete
>>Policy term: permanent
>>Policy statement:
>>
>>Delete section 6.5.4.2. of NRMP.
>>
> 
> 
> When you delete section 6.5.4.2 of the NRPM you are left with only the
> following phrase as a guideline in determining the assignment of multiple
> /48s.  
> 
> "...except in cases of extra large end sites where a larger assignment can
> be justified.",  section 6.5.2.1.  
> 
> If the goal of this policy change is to remove the requirement for the RIR
> to check a multiple /48 assignment to an endsite, then this policy should
> define the criteria for an LIR to determine if a larger than /48 assignment
> is needed.  Without a criteria in policy an LIR could choose to assign any
> size block to an endsite.  Under the wording of section 6.5.2.1 only the
> word "justified" can be labeled as a criteria for determining the
> assignment size.   How is "justified" defined for an endsite in this context?
> 
> 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. 
> 
> 
>>It seems useless, now that there is already deployment experience, to
>>require a justification from the LIR to ARIN for assigning multiple /48s
>>(or a shorter prefix, such as for example a /47). It is up to the LIR to
>>require the justification to its own customers and decide according to
>>it. The LIR will be already responsible to justify to ARIN the usage of
>>any allocated
>>block(s) when requesting for more, and this will already implicate an
>>implicit justification of this kind of assignments.
> 
> 
> That is not the way I read section 6.5.4.1
> 
>    "RIRs/NIRs are not concerned about which address size an LIR/ISP
> actually assigns. Accordingly, RIRs/NIRs will not request the detailed
> information on IPv6 user networks as they did in IPv4, except for the cases
> described in Section 6.4.4 and for the purposes of measuring utilization as
> defined in this document."
> 
> I read section 6.5.4.1 to allow an LIR to keep no records about the
> justification for assignments to endsites.
> 
> 
> 
>>With this policy change, both ARIN and LIR staff will save resources in
>>a justification, which seems unnecessary and should be completely on the
>>hands of the LIR itself.
>>
> 
> 
> How many times have ARIN staff had to evaluate the assignment of multiple
> /48s to endsites so far?  Is this really an issue?
> 
> 
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>