<div dir="ltr"><div class="gmail_default" style="font-size:small">I agree that you have summarized group discussion accurately.</div></div><div class="gmail_extra"><br clear="all"><div>--<br>Brian</div>
<br><br><div class="gmail_quote">On Fri, Apr 5, 2013 at 8:23 AM, David Farmer <span dir="ltr"><<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 4/4/13 12:15 , David Farmer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here is the update that I propose to submit tomorrow to meet the<br>
publication deadline for the Barbados meeting. I believe it accurately<br>
reflects the changes discussed so for. Any comments are appreciated.<br>
<br>
Thanks.<br>
</blockquote>
<br></div>
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.<br>
<br>
Any additional comments are appreciated before I submit it to staff mid-day for publication in the Barbados meeting materials.<br>
<br>
Thanks<br>
<br>
--<div class="im"><br>
<br>
Draft Policy ARIN-2013-3<br>
Tiny IPv6 Allocations for ISPs<br>
<br></div><div class="im">
Date: 5 April 2013<br>
<br>
Problem Statement:<br>
<br>
ARIN's fee structure provides a graduated system wherein organizations pay based on the amount of number resources they consume.<br>
<br></div>
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.<div class="im">
<br>
<br>
While tiny in absolute terms, the extra costs incurred represent a disincentive to IPv6 deployment.<br>
<br></div>
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".<div class="im">
<br>
<br>
Policy statement:<br>
<br>
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;<br>
<br>
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.<br>
<br>
...<br>
<br></div>
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.<div class="im">
<br>
<br>
Part 2: Add a new subsection to section 6 "IPv6";<br>
<br>
6.12 Reduction or Return<br>
<br>
ARIN will accept the return of whole or partial block(s) allowing an organization to reduce their holdings as long as:<br>
<br></div>
a. The end result is not an increase in the number of aggregatable blocks held by the organization.<div class="im"><br>
<br>
b. Whole blocks are returned to the extent practicable.<br>
<br></div>
c. Partial block(s) retained must conform to current applicable allocation or assignment policies, as to size, alignment, etc…<br>
<br>
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.<div class="im"><br>
<br>
e. All returned block(s) must not be in use by the organization or its customers.<br>
<br>
Comments:<br>
<br></div>
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.<br>
<br>
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.<br>
<br>
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 <a href="mailto:8DA1853CE466B041B104C1CAEE00B3748F9239EA@CHAXCH01.corp.arin.net" target="_blank">8DA1853CE466B041B104C1CAEE00B3<u></u>748F9239EA@CHAXCH01.corp.arin.<u></u>net</a> ). It specifies the generic requirements that should be met for such returns.<div class="im">
<br>
<br>
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.<br>
<br></div>
Summary of community discussion:<br>
<br>
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.<br>
<br>
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.<br>
<br>
Timetable for implementation: Immediate<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
==============================<u></u>==================<br>
David Farmer Email: <a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a><br>
Office of Information Technology<br>
University of Minnesota<br>
2218 University Ave SE Phone: <a href="tel:1-612-626-0815" value="+16126260815" target="_blank">1-612-626-0815</a><br>
Minneapolis, MN 55414-3029 Cell: <a href="tel:1-612-812-9952" value="+16128129952" target="_blank">1-612-812-9952</a><br>
==============================<u></u>==================<br>
______________________________<u></u>_________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/<u></u>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</div></div></blockquote></div><br></div>