ARIN-PPML Message

[arin-ppml] Draft Policy 2011-3: Better IPv6 Allocations for ISPs

Draft Policy ARIN-2011-3
Better IPv6 Allocations for ISPs

On 28 January 2011 the ARIN Advisory Council (AC) selected "Better IPv6
Allocations for ISPs" as a  draft policy for adoption discussion on the
PPML and at the Public Policy Meeting in San Juan, Puerto Rico in April.

The draft was developed by the AC from policy proposal "ARIN-prop-121.
Better IPv6 Allocation for ISPs". Per the Policy Development Process the
AC submitted text to ARIN for a staff and legal assessment prior to its
selection as a draft policy. Below the draft policy is the ARIN staff
and legal assessment, followed by the text that was submitted by the AC.

Draft Policy ARIN-2011-3 is below and can be found at:
https://www.arin.net/policy/proposals/2011_3.html

You are encouraged to discuss Draft Policy 2011-3 on the PPML prior to
the April Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy ARIN-2011-3
Better IPv6 Allocations for ISPs

Version/Date: 30 January 2011

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

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

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.

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.


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

Clarifications in response to Staff and Legal Assessment

In the Proposal Summary (Staff understanding) staff states "This policy
will lower the current minimum allocation size from a /32 to a /36 as it
allows ISPs to request a /36". It should be noted that this policy still
allows any ISP to receive at least a /32. However, the /36 is provided
as an option specifically to allow very small ISPs currently in the
x-small IPv4 category a reduced option. It is the intent that by
allowing this, the board may reconsider the minimum IPv6 ISP fee table
and allow these particularly small organizations to obtain IPv6 without
increasing their annual subscription fees from ARIN. Since Fees are not
a policy matter, the fee request must be considered elsewhere, but, the
enabling policy language contained in this policy is a precursor to that
discussion. The author has submitted a request that the board consider
this fee structure through the ACSP.


#####


STAFF ASSESSMENT

Proposal:  “Better IPv6 Allocations for ISPs” (pp 121)
Policy Version (Date): 16 December 2010
Date of Assessment:  26 January 2011

1. Proposal Summary (Staff Understanding)

   • This policy allows an ISP to receive an initial allocation large
enough to give each site in its network the block size required for its
largest single site. Site block size and overall block size would be
based on a less than 75% used threshold. ISPs will be eligible to obtain
an additional allocation when they have either allocated 75% of their
existing allocation to sites or have a serving site that has allocated
at least 90% of its existing block. ISP customers of ISPs will be
eligible to obtain an allocation based on the same methodology. All
allocations (including those to customer ISPs and to ISP serving sites)
will be made on nibble boundaries. This policy will lower the current
minimum allocation size from a /32 to a /36 as it allows ISPs to request
a /36.

2. Comments

  A. ARIN Staff Comments

   • The proposed addition of 2.14, a definition of "utilized" is meant
to only refer to IPv6 and the application of this policy. The word
"utilized" is very important to IPv4 policy, and this new definition
could introduce unnecessary ambiguity.  Perhaps the proposed definition
could have a qualifier noting that it's only applicable to IPv6 addressing.

   • The proposed additions of 2.12 and 2.13 suffer the same problem as
in comment #1, albeit without the same wide-ranging effect of the
proposed 2.14. They, too, should probably be qualified as only relating
to IPv6 policy.

   • 6.5.2.2.b has both an OR and an AND clause that is unclear and
ambiguous.  We believe the OR refers to the two possibilities for
qualifying, and the AND refers to only the second possibility.  The text
should be re-written to remove the ambiguity.

   • 6.5.2.2.b needs editing for grammar. The clause shifts between tenses.

   • 6.5.2.2.c needs editing for punctuation and grammar.

  B. ARIN General Counsel

No comments

3. Resource Impact

This policy would have moderate resource impact from an implementation
aspect.  It is estimated that implementation would occur within 6 - 9
months after ratification by the ARIN Board of Trustees. The
implementation of this policy will require staff to develop new sparse
allocation methods and software.

The following would be needed in order to implement:
   • Updated documentation/guidelines on the ARIN website
   • Staff training
   • Engineering labor to modify our sparse allocation tools


4. Proposal Text

Policy Proposal: Better IPv6 Allocations for ISPs

Version/Date: 16 December 2010

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 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.
             (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 and will be making reassignments
             to other organizations.
         (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.

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
12-191         256         8
192-3,071     4,096         12
3,072-49,151     65,536         16
49,152-786,431     1,048,576     20