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

Tue Apr 19 20:29:17 EDT 2011

I support the policy proposal as written, though not opposed to further discussion of verbiage.

On 4/18/11 12:05 PM, ARIN 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.

-- 
Charles O'Hern
Network Operations

TCSN - The Computer Shop Netlink
1306 Pine St. Paso Robles CA 93446
1-(805) 227-7000  1-(800) 974-DISK
http://www.tcsn.net  abuse at tcsn.net