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

ARIN info at arin.net
Wed Mar 27 14:20:46 EDT 2013


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

On 21 March 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-185 
Tiny IPv6 Allocations for ISPs" as a Draft Policy.

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

You are encouraged to discuss the merits and your concerns of Draft 
Policy 2013-3 on the Public Policy Mailing List. 2013-3 will also be on 
the agenda at the upcoming ARIN Public Policy Meeting in Barbados. The 
AC will evaluate the discussion in order to assess the conformance of 
this draft policy with ARIN's Principles of Internet Number Resource 
Policy as stated in the PDP. Specifically, these principles are:

  * Enabling Fair and Impartial Number Resource Administration
  * Technically Sound
  * Supported by the Community

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: 27 March 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 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 /48 allocation direct from ARIN; assignments of /48s have been 
limited to organizations that qualify as end sites or critical 
infrastructure.

Policy statement:

Part 1: In the NRPM, change 6.5.2.1(b) from:

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.

to:

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

Part 2: In the NRPM, append a subsection to 6.5:

An LIR may return all or part of an allocation to ARIN, however if the 
LIR retains a portion, the aggregate retained must be either the first 
(lowest numbered) subnet of that prefix or the largest (highest 
numbered) subnet of the returned block. The smallest prefix that may be 
retained by the LIR shall be no smaller than the smallest prefix that 
may be allocated under current policy at the time of the address space 
return.

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, perhaps even 
reserving a block as large as the /28 that is reserved for /32s.

Part 1 brings ARIN's allocation policies in line with the upcoming fee 
schedule so that it is possible to qualify as every level of ISP while 
holding IPv6 number resources.

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 )

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 Public 
Policy Process; such responsibility lies with the Board should they 
choose to take it up.

Timetable for implementation: Immediate



More information about the ARIN-PPML mailing list