[arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs

[David Farmer]

On 4/4/13 12:15 , David Farmer wrote:
> Here is the update that I propose to submit tomorrow to meet the
> publication deadline for the Barbados meeting.  I believe it accurately
> reflects the changes discussed so for.  Any comments are appreciated.
>
> Thanks.

Ok, here is another update that includes the changes discussed 
yesterday, and few others I found.  I've also included a new section 
summarizing the community's discussion to this point, including the 
primary objection to the policy and how the policy attempts to mitigate it.

Any additional comments are appreciated before I submit it to staff 
mid-day for publication in the Barbados meeting materials.

Thanks

--

Draft Policy ARIN-2013-3
Tiny IPv6 Allocations for ISPs

Date: 5 April 2013

Problem Statement:

ARIN's fee structure provides a graduated system wherein organizations 
pay based on the amount of number resources they consume.

At the very bottom end of the scale, it is presently not possible to be 
an XX-Small ISP with an IPv6 allocation because the minimum allocation 
size of /36 automatically promotes one into X-Small ISP status, 
resulting in a doubling of annual fees.

While tiny in absolute terms, the extra costs incurred represent a 
disincentive to IPv6 deployment.

To the author's knowledge, it has never been possible for an LIR/ISP to 
get a /40 allocation direct from ARIN; such assignments have been 
limited to organizations that qualify as end sites or /48s for critical 
infrastructure.  It is understood there is an expected correction of the 
XX-Small fee category to "/40 or smaller".

Policy statement:

Part 1: In subsection 6.5.2. Initial Allocation Size, insert "or /40" at 
the end of the first sentence of subsection 6.5.2.1 clause (b), and add 
a new clause (g), resulting in;

b. In no case shall an LIR receive smaller than a /32 unless they 
specifically request a /36 or /40.  In no case shall an ISP receive more 
than a /16 initial allocation.

...

g. An LIR that requests a smaller /36 or /40 allocation is entitled to 
expand the allocation to /32 or /36 at any time without renumbering or 
additional justification.  Such expansions are not considered subsequent 
allocations.  However, any expansions beyond /32 are considered 
subsequent allocations, and must conform to section 6.5.3.

Part 2: Add a new subsection to section 6 "IPv6";

6.12 Reduction or Return

ARIN will accept the return of whole or partial block(s) allowing an 
organization to reduce their holdings as long as:

a. The end result is not an increase in the number of aggregatable 
blocks held by the organization.

b. Whole blocks are returned to the extent practicable.

c. Partial block(s) retained must conform to current applicable 
allocation or assignment policies, as to size, alignment, etc…

d. Block(s) retained are within a single reserved space or aggregate set 
aside for the organization in the ARIN database to the extent practicable.

e. All returned block(s) must not be in use by the organization or its 
customers.

Comments:

The author acknowledges the shortcomings of providing an ISP with an 
allocation of a size that is more traditionally associated with end 
sites. In order to avoid possible bad effects on the routing table, the 
author encourages ARIN staff to adopt the same sparse allocation 
practice as currently exists for larger allocations, ideally even 
reserving a block as large as the /28 that is reserved for /32s 
currently.  Note the policy intent of part 1 requires a minimum of a /32 
be reserved.

Part 1 brings ARIN's allocation policies in line with the upcoming fee 
schedule, with the addition of an expected correction of the XX-Small 
fee category to "/40 or smaller".  This makes it possible to qualify for 
each ISP fee category while holding IPv6 number resources and allows 
expansion up to /32 without renumbering or additional justification as a 
subsequent allocation.  The selection of a /32, /36 or /40 allocation is 
only driven by an ISP's own internal business justifications.

Part 2 codifies and expands upon current practice for selective return 
in the manner described by John Curran on the arin-discuss mailing list 
(7-Mar-2013 in 
8DA1853CE466B041B104C1CAEE00B3748F9239EA at CHAXCH01.corp.arin.net ). It 
specifies the generic requirements that should be met for such returns.

A more practical approach might to figure out a way to apply graduated 
fees to ISPs at the very small end of the scale using some metric other 
than prefix size. Fee schedules are outside of the purview of the Policy 
Development Process; such responsibility lies with the Board should they 
choose to take it up.

Summary of community discussion:

The fundamental argument against this draft policy is that the primary 
problem being solved is a billing or fee structure issue and not a 
number resource policy issue in itself.  A significant minority of the 
community would prefer /32 be the sole minimum allocation size for ISPs 
and other LIRs, and they feel there is no need for smaller /36 or /40 
allocations.  They would prefer to solve the problem with changes in the 
fee structure rather than contorting number resource policy to solve the 
problem.  However, there are to many ISPs that fit into the /32 
allocation category for the fee level associated with the XX-Small 
category to be fiscally responsible and sustainable for ARIN. 
Furthermore, there are no obvious solutions to this problem within the 
fee structure domain that are fiscally responsible and sustainable for 
ARIN, especially in the long-term.

Everyone agrees making /36 or /40 allocations to ISPs seems less than 
ideal from a number resource policy perspective.  However, this is 
mitigated by ensuring that all ISPs have a /32 available to them without 
renumbering or additional justification and from a number resource 
policy perspective the selection of /36 or /40 allocations is completely 
voluntary.  This allows each ISPs to make the decision to select from a 
/32, /36 or /40 initial allocation based solely on their own internal 
business justifications, and eliminating structural disincentives in the 
fee schedule for IPv6 adoption.  This seems like the best balance 
available at this time of number resource policy, fiscal responsibility 
and sustainability for both ARIN and the ISPs that it servers.

Timetable for implementation: Immediate

-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================