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

Tue Apr 19 17:03:08 EDT 2011

I have ISP customers who are right on the edge of a /32 being not enough for any kind of expansion. (~60,000 users, ~20 POPs, and plans to expand. They have tried to get larger than a /32 block, but have been denied. Some are putting off IPv6 deployment entirely, as they do not want to be in the same situation with IPv6 that they are in IPv4 (having multiple separate blocks)

Some change in policy needs to be done ASAP to encourage adoption. I would be happy with whatever is doable that would align on nibble boundaries, and allow for ISPs in this size category to get a /28 (which would almost certainly allow them to never need another allocation)

-Randy

--
| Randy Carpenter
| Vice President - IT Services
| Red Hat Certified Engineer
| First Network Group, Inc.
| (800)578-6381, Opt. 1
----

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