[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