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

[ARIN]

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

The text has been revised.

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

This draft will be presented at ARIN 31.

The ARIN Policy Development Process (PDP) 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,

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


## * ##


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

Date: 8 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 any nibble aligned size up to /32 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 resulting number of retained aggregate blocks does not increase.

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 block(s) returned are not 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 are
adamant on this issue to the extent they oppose this policy. The
majority of the community recognizes this issue, and would prefer /32 be
the sole minimum allocation size for ISPs and other LIRs.  However, the
majority are willing to accept the tradeoffs incorporated into this
policy.  As there are too 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 ISP to make the decision to select from a
/32, /36 or /40 initial allocation based solely on their own internal
business justifications, and eliminates 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 serves.

Timetable for implementation: Immediate