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

[Brian Jones]

I agree that you have summarized group discussion accurately.

--
Brian


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.
>>
>> 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 8DA1853CE466B041B104C1CAEE00B3**
> 748F9239EA at CHAXCH01.corp.arin.**net<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
> ==============================**==================
> ______________________________**_________________
> PPML
> 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:
> http://lists.arin.net/mailman/**listinfo/arin-ppml<http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130405/65834223/attachment.htm>