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

Tue Apr 19 12:11:58 EDT 2011

Unless I'm reading this wrong, I have an issue with the inconsistency in
renumbering requirements. In 6.5.3 section (c) LIRs are encouraged but not
required to renumber in the event of getting a subsequent allocation that
is not adjacent to their previous allocation.

But in section 6.5.7 it is required that an LIR renumber if receiving a
subsequent allocation to fill requirements not able to be filled by the
original. 

Section 6.5.3.c could stay as it is, and simply remove the words,
"...provided that they agree to renumber into that new allocation and
return their prior allocation(s) within 5 years" from section 6.5.7. I
would approve of this language being removed if the proposal is sent to
the BoT. 

-Dan Alexander

On 4/18/11 3:05 PM, "ARIN" <info at arin.net> wrote:

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