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

[Matthew Kaufman]

Totally oppose the below. There's no reason why we should ever be giving 
an ISP something smaller than a /32. Fix the silly fee schedule.

If charging $1000 instead of $500 is a disincentive (I certainly think 
it is) make the /32 be $500.

Matthew Kaufman

ps. Example as to why I think it is a disincentive: I run a microwave 
network linking multiple mountaintops serving the tiny needs of several 
different non-profit organizations, all paid for out of my own pocket. 
All of it is numbered out of legacy space I hold. Guess how much my wife 
thinks I should spend per year on an IPv6 allocation from ARIN so that I 
can add IPv6 to this network? I'll give you a hint: $500/year is too much.


On 4/4/2013 10:15 AM, 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.
>
> ---
>
> Draft Policy ARIN-2013-3
> Tiny IPv6 Allocations for ISPs
>
> Date: 4 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 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; assignments of /40s have 
> been limited to organizations that qualify as end sites or 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 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 non-contiguous 
> blocks held by the organization.
>
> b. Whole blocks are returned to the extent practicable.
>
> c. Partial block(s) retained must conform to applicable policies, as 
> to size, alignment, etc…
>
> d. Partial 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, perhaps even 
> reserving a block as large as the /28 that is reserved for /32s.  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 justification as a subsequent 
> allocation as driven by an ISP's business demands.
>
> 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 meet 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.
>
> Timetable for implementation: Immediate
>
>