[arin-ppml] ARIN-2011-3: Better IPv6 Allocations for ISPs - Last Call

Tue Apr 19 17:32:23 EDT 2011

On Apr 19, 2011, at 2:49 PM, George, Wes E IV [NTK] wrote:

> I do not believe that this is ready for last call. Given the complexity of this policy, the significant amount of areas of NRPM that
> it is changing, and the fact that the text discussed in PR was not really the text that is being proposed in this last call version
> (there were significant changes), not to mention the lack of consensus that we should eliminate H-D ratio, I think that this needs
> to come before membership and be discussed in its current (final?) form at the next meeting.

I agree with this comment from Wes.  There are a number of good things being attempted by Draft Policy 2011-3, but it needs further development and discussion.

One suggestion for making it easier to discuss: please split 2011-3 into multiple Draft Policies, each focused on a single significant topic.  I cannot say that I "support" the proposal, given that I disagree with certain parts of it, despite the fact that I agree with other parts of it, etc.

Cheers,
-Benson

> The ARIN Advisory Council (AC) met on 13 April 2011 and decided to send a revised version of the following draft policy to last
> call:
> 
>   ARIN-2011-3: Better IPv6 Allocations for ISPs
> 
> Changes include:
> 1. Does not delete section 2.9 (request from staff, no impact on policy
> meaning)
> 2. Limits LIR recursion to a single level and limit subordinate LIRs to /32. (community concern) 3. Restores PAU to the calculation
> in 6.5.2.1(c) (from errata slide presented in meeting) 4. Preserves 2010-12 language in new 6.5.3.1 (from errata slide presented in
> meeting) 5. Preserves verbiage allowing ISPs to allocate to their own internal infrastructure in 6.5.4.1 (from errata slide
> presented in meeting) 6. Adds a statement to delete current NRPM 6.9 (from errata slide presented in meeting) 7. Adds language to
> limit initial allocations to no more than a /16
> (6.5.2.1(b)) and to limit subsequent allocations to no larger than a /12 (an organization may apply for additional /12s, but, no
> single allocation larger than a /12 can be made at one time) (6.5.2.1(e)) (community concern)
> 
> Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. Last call for
> 2011-3 will expire on 2 May 2011. After last call the AC will conduct their last call review.
> 
> The draft policy text is below and available at:
> https://www.arin.net/policy/proposals/
> 
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Draft Policy ARIN-2011-3
> Better IPv6 Allocations for ISPs
> 
> Version/Date: 18 April 2011
> 
> Policy Statement:
> 
> Amend section 2 as follows:
> 
> Replace section 2.10 with the following:
> 
> 2.10 The term End Site shall mean a single structure or service delivery address, or, in the case of a multi-tenant structure, a
> single tenant within said structure (a single customer location).
> 
> Add the following:
> 
> 2.12 When applied to IPv6 policies, the term serving site shall mean a location where an ISP terminates or aggregates customer
> connections, including, but, not limited to Points of Presence (POPs), Datacenters, Central or Local switching office or regional or
> local combinations thereof.
> 
> 2.13 When applied to IPv6 policies, the term "provider assignment unit" shall mean the prefix of the smallest block a given ISP
> assigns to end sites (recommended /48).
> 
> 2.14 The term utilized shall have the following definitions when applied to IPv6
> policies:
> 
> (i) A provider assignment unit shall be considered fully utilized when it is assigned to an end-site.
> 
> (ii) Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned from the
> containing block by the total number of provider assignment units. This ratio will often be expressed as a percentage (e.g. a/t*100,
> for a /36 3072/4096 * 100 = 75% utilization)
> 
> Replace sections 6.5.1 through 6.5.3 with the following:
> 6.5.1 Terminology
> 
> (a) The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both
> meanings.
> 
> (b) The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (in slash notation, /n, where n is evenly
> divisible by 4, allowing unit quantities of X such that 2^n=X where n is evenly divisible by 4, such as 16, 256, 4096, etc.)
> 
> 6.5.2 Initial Allocations to LIRs
> 6.5.2.1 Size
> 
> (a) All allocations shall be made on nibble boundaries.
> 
> (b) In no case shall an LIR receive smaller than a /32 unless they specifically request a /36. In no case shall an ISP receive more
> than a /16 initial allocation.
> 
> (c) The maximum allowable allocation shall be the smallest nibble-boundary aligned block that can provide an equally sized
> nibble-boundary aligned block to each of the requesters serving sites large enough to satisfy the needs of the requesters largest
> single serving site using no more than 75% of the available addresses.
> 
> This calculation can be summarized as /N where N = P-(X+Y) and P is the organization's Provider Allocation Unit X is a multiple of 4
> greater than 4/3*serving sites and Y is a multiple of 4 greater than 4/3*end sites served by largest serving site.
> 
> (d) For purposes of the calculation in (c), an end site which can justify more than a /48 under the end-user assignment criteria in
> 6.5.8 shall count as the appropriate number of /48s that would be assigned under that policy.
> 
> (e) For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same
> policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in
> determining the block sizing for the parent LIR.
> LIRs which do not receive resources directly from ARIN will not be able to make such allocations to subordinate LIRs and subordinate
> LIRs which need more than a /32 shall apply directly to ARIN.
> 
> (f) An LIR is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine
> the largest IP address block to which the LIR is entitled.
> 
> 6.5.2.2 Qualifications
> An organization qualifies for an allocation under this policy if they meet any of the following criteria:
> 
> (a) Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP
> allocation under current criteria.
> 
> (b) Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number.
> 
> In either case, they will be making reassignments from allocation(s) under this policy to other organizations.
> 
> (c) Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the
> intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification
> must also include a plan detailing anticipated assignments to other organizations or customers for one, two and five year periods,
> with a minimum of 50 assignments within 5 years.
> 
> 6.5.3 Subsequent Allocations to LIRs
> 
> (a) Where possible ARIN will make subsequent allocations by expanding the existing allocation.
> 
> (b) An LIR which can show utilization of 75% or more of their total address space, or more than 90% of any serving site shall be
> entitled to a subsequent 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 and return any allocations no
> longer in use.
> 
> (d) If an LIR has already reached a /12 or more, ARIN will allocate a single additional /12 rather than continue expanding nibble
> boundaries.
> 
> Renumber/move the second paragraph of existing section 6.5.2.1 to 6.5.3.1.
> 
> For reference, this would become:
> 6.5.3.1 Subsequent Allocations for Transition Subsequent allocations will also be considered for deployments that cannot be
> accommodated by, nor were accounted for, under the initial allocation. Justification for the subsequent subnet size will be based on
> the plan and technology provided with a /24 being the maximum allowed for a transition technology.
> Justification for transitional allocations will be reviewed every 3 years and reclaimed if they are no longer in use for
> transitional purposes. All such allocations for transitional technology will be made from a block designated for this purpose.
> 
> (This paragraph comes from 2010-12 which was adopted after this draft policy was written).
> 
> Replace section 6.5.4 with the following
> 
> 6.5.4 Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the
> requirements in 6.5.8.1 do not apply.
> 
> 6.5.4.1 An LIR may assign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure.
> 
> 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.
> 
> Delete section 6.9
> 