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

[Owen DeLong]

There were two people who spoke in opposition to eliminating HD ratio, IIRC. OTOH, the number
of people speaking in favor of doing so was much larger.

As to the changes, while there are several changes, none of them changes the general intent
of the policy and all of them incorporate fine tuning requested on the list or at the PR meeting,
so, each and every one of them was discussed in PR.

Finally, while there was not overwhelming support for the text discussed in San Juan, there
was overwhelming support for the general intent of the proposal expressed in the show of hands.
It is unfortunate that we did not get a show of hands for the number of people who would support
the proposal with the errata discussed in the meeting corrected.

A number of the people who voted no in the room approached me at the break stating that
they could not support it as written because they believed that the errata corrections were
necessary, but, that they did want to see this implemented as soon as possible.

Owen

On Apr 19, 2011, at 12: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.
> 
> Wes George
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
> Sent: Monday, April 18, 2011 3:06 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] ARIN-2011-3: Better IPv6 Allocations for ISPs - Last Call
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.