[arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
bjones at vt.edu
Fri Apr 5 09:22:33 EDT 2013
I agree that you have summarized group discussion accurately.
On Fri, Apr 5, 2013 at 8:23 AM, David Farmer <farmer at umn.edu> wrote:
> 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.
> 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.
> 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 220.127.116.11 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
> 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 8DA1853CE466B041B104C1CAEE00B3**
> 748F9239EA at CHAXCH01.corp.arin.**net<8DA1853CE466B041B104C1CAEE00B3748F9239EA at CHAXCH01.corp.arin.net>). It specifies the generic requirements that should be met for such
> 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
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML