[arin-ppml] Draft Policy 2010-4: Rework of IPv6 allocation criteria - Last Call

David Farmer farmer at umn.edu
Mon May 3 19:36:42 EDT 2010


Member Services wrote:

> Draft Policy 2010-4
> Rework of IPv6 allocation criteria
> 
> Version/Date: 23 February 2010
> 
> Policy statement:
> 
> Delete section 6.4.3. Minimum Allocation.
> 
> Modify the following sections;
> 
> 6.5.1 Initial allocations for ISPs and LIRs
> 
> 6.5.1.1. Initial allocation size
> 
> Organizations that meet at least one of the following criteria are
> eligible to receive a minimum allocation of /32. Requests for larger
> allocations, reasonably justified with supporting documentation, will be
> evaluated based on the number of existing users and the extent of the
> organization's infrastructure.
> 
> 6.5.1.2. Criteria for initial allocation to ISPs
> 
> Organizations may justify an initial allocation for the purpose of
> assigning addresses to other organizations or customers that it will
> provide IPv6 Internet connectivity to, with an intent to provide global
> reachability for the allocation within 12 months, by meeting one of the
> following additional criteria:
> 
> a. Having a previously justified IPv4 ISP allocation from ARIN or one of
> its predecessor registries, or;
> 
> b. Currently being IPv6 Multihomed or immediately becoming IPv6
> Multihomed and using an assigned valid global AS number, or;
> 
> c. By providing a reasonable plan detailing assignments to other
> organizations or customers for one, two and five year periods, with a
> minimum of 50 assignments within 5 years.
> 
> 6.5.1.3. Criteria for initial allocation to other LIRs
> 
> Organizations may justify an initial allocation for the purpose of
> assigning addresses to other organizations or customers that it will
> provide IPv6 based network connectivity services to, not necessarily
> Internet connected, by meeting one of the following additional criteria:
> 
> a. Having a previously justified IPv4 ISP allocation from ARIN or one of
> its predecessor registries, or;
> 
> b. By providing a reasonable technical justification, indicating why an
> allocation is necessary, including the intended purposes for the
> allocation, and describing the network infrastructure the allocation
> will be used to support. Justification must include a plan detailing
> assignments to other organizations or customers for one, two and five
> year periods, with a minimum of 50 assignments within 5 years.
> 
> Rationale:
> 
> This proposal provides a complete rework of the IPv6 allocation criteria
> while maintaining many of the basic concepts contained in the current
> policies. The order of the subsections of 6.5.1 are rearranged moving
> the initial allocation size to 6.5.1.1. This will facilitate adding
> future criteria without additional renumbering the current policies.
> 
> The initial allocation criteria include the following general concepts:
> 
> • The need for an allocation is only justified by the need to assign
> resource to customers, either internal or external.
> • When the need to provide Internet connectivity is use to justify
> resources it is implied the resources should be advertised to the
> Internet, within some reasonable time frame after they are received.
> • IPv4 resources may be use to justify the need for IPv6 resources.
> • An ISP may justify independent resource by being Multihomed or
> planning to assign IPv6 resource to some minimum number of customers.
> • It should be possible to justify an IPv6 allocation for more than just
> classical ISPs, such as non-connected networks or other types of LIRs.
> But additional justification should be required, describing the purpose
> and network infrastructure the allocation will be supporting.
> 
> Finally, section 6.4.3 Minimum Allocation, is deleted as it is
> incomplete and redundant anyway.
> 
> Timetable for implementation: immediate

 From the Staff Assessment for 2010-4

• Since 6.5.1.3b does not specify whether “other organizations or 
customers” must be external, it seems likely that this policy will open 
up allocation policy to enterprise customers (who presently receive 
assignments under the End-user policies). Currently the larger 
enterprise businesses we see typically define their operating divisions 
and departments as 'customers'.

---

I believe this is an issue for the entirety of both 6.5.1.2 and 6.5.1.3, 
and not only for 6.5.1.3b.  Both 6.5.1.2 and 6.5.1.3 contain the phrase 
"for the purpose of assigning addresses to other organizations or 
customers." My intent for that language was that an ISP or LIR had to 
make assignments to other (external) organization or customers, but that 
it could also include internal customers too.  Classical ISPs make 
assignments for external customers and internal customers, like their 
content distribution network, their infrastructure, and/or their 
internal business units, etc...  To put it another way, I didn't think 
you can simply exclude all internal customers.  So, I guess my intent 
was that assignments, or a plan for such assignments, must include to at 
least some external customers, but not require exclusively external 
customers.

Looking at this more closely, I agree with staff that isn't entirely 
clear. However, I believe that the current policy has much the same 
ambiguity, so I don't think this policy is making things any worse than 
they are now.

There was at least some comments from the floor of the ARIN XXV meeting 
that this should be clarified now.  However, there seemed to be 
sufficient support for moving this policy forward without tackling this 
ambiguity now. So what should we do, should we fix this now, or fix it 
in a subsequent policy?

Originally, I had included language explicitly allowing only internal 
customers, as long as the organization made assignments to these 
internal customers as if they were external customers, and otherwise 
functioned as if it were an ISP, following associated policies, etc... 
I was advised by some reviewers of the text to remove that section for 
now and to take that up as a separate policy in the future.  So I 
removed that text, but I guess I didn't go far enough in making it clear 
that there had to be at least some external customers.

How about this language; "for the purpose of assigning addresses to some 
other external organizations or customers"  Does that provide sufficient 
clarification without adding an entire paragraph on the issue?

Should we wait and see if we can come to a consensus on allowing 
internal only providers?

Should we just continue to live with the ambiguity?

Please provide the AC feedback on this Draft Policy 2010-4 and on the 
other two draft policies in Last Call, 2010-2 and 2010-6.  It is much 
easier for the AC, and the BOT following Last Call, to do our jobs when 
there is actually feed back during the Last Call process.  Even if your 
feedback is that simply that you support, or not, the Draft Policy as 
written, it is still useful in the task of judging the Last Call outcome.

Thank you.

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