[arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)

[ARIN]

Policy Proposal 121: Sensible IPv6 Allocation for ISPs

ARIN acknowledges receipt of the policy proposal that can be found below.

The ARIN Advisory Council (AC) will review the proposal at their next
regularly scheduled meeting (if the period before the next regularly
scheduled meeting is less than 10 days, then the period may be extended
to the subsequent regularly scheduled meeting). The AC will decide how
to utilize the proposal and announce the decision to the PPML.

The AC invites everyone to comment on the proposal on the PPML,
particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


> -----Original Message-----

> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On

> Behalf Of Owen DeLong

> Sent: Tuesday, November 16, 2010 9:10 AM

> To: policy; ppml at arin.net PPML

> Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8

>

>  Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0

>    1. Policy Proposal Name: Sensible IPv6 Allocation for ISPs

>    2. Proposal Originators

>          1. name: Owen DeLong

>          2. e-mail: owen at delong.com

>          3. telephone: 408-890-7992

>          4. organization: Hurricane Electric

>          1. name: David Farmer

>          2. e-mail: farmer at umn.edu

>          3. telephone: 612-812-9952

>          4. organization: University of Minnesota

>          1. name: Andrew Dul

>          2. e-mail: andrew.dul at quark.net

>          3. telephone: 206-395-4004

>          4. organization: Cascadeo Corp.

>          1. name: Chris Grundemann

>          2. e-mail: christopher.grundemann at twtelecom.com

>          3. telephone: 303.542.6524

>          4. organization: TW Telecom

> 3. Proposal Version: 0.8

> 4. Date: 16 November, 2010 5. Proposal type: M 6. Policy term:

> Permanent 7. Policy statement:

> Amend section 2 as follows:

> Delete section 2.9 (Obsolete)

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

>           (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 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 (a number 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.

>     (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 = 48-(X+Y)

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

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

>     (c)   Provide ARIN a reasonable technical justification,

> indicating why an allocation is necessary, including the intended

> purposes for the allocation, and describing the network infrastructure

> the allocation will be used to support. Justification must include a

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

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

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

>    8. Rationale:

> The current ISP policy for IPv6 allocations is both short-sighted and

> insufficient for rational deployments by most ISPs. We have gained

> significant operational experience with IPv6 in the time since it was

> written and it is clear that current policy is driving many ISPs to

> choices of excess conservatism that will eventually harm innovation in

> the consumer space.

> Under the proposed policy, the entirety of the ARIN region can still be

> numbered in no more than 2 /12s (quite probably 1). There are still 506

> /12s free within the current /3. It is unreasonable to shoot ourselves

> in the foot with address scarcity thinking so early into the IPv6

> deployment. This policy seeks to strike a more reasonable and

> harmonious balance of the goals stated in NRPM 6.3.

> The lower bound of /36 is intended to facilitate extremely small ISPs

> getting a smaller block if they do not need to support more than ~4000

> customers. It is hoped that the board will take subsequent action to

> adjust the fee structure to eliminate the $1,000/year price hike for

> those extremely small ISPs. These ISPs can, of course, get a /32 if

> they wish.

> The intent of section 6.5.4 is to create and preserve parity between

> the requirements for LIR->End User and ARIN->End User policies. This

> section presumes that 6.5.8 has already been modified as described in

> draft policy 2010-8.

> Some examples of determining the size of block for which an

> organization is eligible:

> Bill's Bait, Sushi, and IP Transit:

>     Largest serving site:         200 end sites

>     Number of serving sites:      5

>     200 rounds up to 256 (nibble boundary, 8 bits). 200 > 192 (256 *

> 0.75), so, round up to 4096 (12 bits)

>     5 rounds up to 16 (nibble boundary, 4 bits). 5 < 12 (16 * 0.75),

> so, no further round up. 16 (4 bits)

>     48 - (12+4) = 32 -- This organization could receive up to a /32.

> Lee's Rural Internet, Inc.

>     Largest serving site:         1024 end sites

>     Number of serving sites:      30

>     1024 rounds up to 4096 (nibble boundary, 12 bits) 1024 < 3072

> (4096 * 0.75), so 4096 (12 bits)

>     30 rounds up to 256 (nibble boundary, 8 bits). 30 < 192 (256 *

> 0.75), so, 256 (8 bits)

>     48 - (12+8) = 28 -- This organization could receive up to a /28.

> Paul's Mega Metro ISP, LLC

>     Largest serving site:         3,500 end sites

>     Number of serving sites:      140

>     3,500 rounds up to 4096 (nibble boundary, 12 bits). 3500 > 3072

> (4096 * 0.75), so, round up to 65,536 (16 bits)

>     140 rounds up to 256 (nibble boundary, 8 bits) 140 < 192 (256 *

> 0.75), so, 256 (8 bits)

>     48 - (16+8) = 24 -- This organization could receive up to a /24

> PON's CMTS mega DSL Corp.

>     Largest serving site:         30,000 end sites

>     Number of serving sites:      700

>     30,000 rounds up to 65,536 (nibble boundary, 16 bits). 30,000 <

> 49,152 (65536 * 0.75), so, 65,536 (16 bits)

>     700 rounds up to 4,096 (nibble boundary, 12 bits). 700 < 3072

> (4096 * 0.75), so, 4,096 (12 bits)

>     48 - (16+12) = 20 -- This organization could receive up to a /20.

> Sizing table:

> Units           Round-up    Bits

> 0-11            16          4

> 13-191          256         8

> 192-3,071 4,096       12

> 3,072-49,151    65,536            16

> 49,152-786,431  1,048,576   20

>    9. Timetable for implementation: Immediate

>

> END OF TEMPLATE

>

>

>

>