<?xml version="1.0" encoding="ISO-8859-1"?>

<rdf:RDF
 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 xmlns="http://purl.org/rss/1.0/"
 xmlns:content="http://purl.org/rss/1.0/modules/content/"
 xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/"
 xmlns:dc="http://purl.org/dc/elements/1.1/"
 xmlns:syn="http://purl.org/rss/1.0/modules/syndication/"
 xmlns:admin="http://webns.net/mvcb/"
>

<channel rdf:about="http://lists.arin.net/pipermail/info/2013-April/date.html">
<title>Info Archive</title>
<link>http://lists.arin.net/pipermail/info/2013-April/date.html</link>
<description>info-feed</description>
<items>
 <rdf:Seq>
  <rdf:li rdf:resource="http://lists.arin.net/pipermail/info/2013-April/000764.html" />
 </rdf:Seq>
</items>
</channel>
<item rdf:about="http://lists.arin.net/pipermail/info/2013-April/000764.html">
<title>Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs</title>
<link>http://lists.arin.net/pipermail/info/2013-April/000764.html</link>
<description>Draft Policy ARIN-2013-3
Tiny IPv6 Allocations for ISPs

The text has been revised.

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

This draft will be presented at ARIN 31.

The ARIN Policy Development Process (PDP) can be found at: [...]</description>
<dc:creator>ARIN</dc:creator>
<dc:date>2013-04-08T11:12:23Z</dc:date>
<dc:subject>Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs</dc:subject>
<content:encoded><![CDATA[Draft Policy ARIN-2013-3<br/>Tiny IPv6 Allocations for ISPs<br/><br/>The text has been revised.<br/><br/>Draft Policy ARIN-2013-3 is below and can be found at:<br/>https://www.arin.net/policy/proposals/2013_3.html<br/><br/>This draft will be presented at ARIN 31.<br/><br/>The ARIN Policy Development Process (PDP) can be found at:<br/>https://www.arin.net/policy/pdp.html<br/><br/>Draft Policies and Proposals under discussion can be found at:<br/>https://www.arin.net/policy/proposals/index.html<br/><br/>Regards,<br/><br/>Communications and Member Services<br/>American Registry for Internet Numbers (ARIN)<br/><br/><br/>## * ##<br/><br/><br/>Draft Policy ARIN-2013-3<br/>Tiny IPv6 Allocations for ISPs<br/><br/>Date: 8 April 2013<br/><br/>Problem Statement:<br/><br/>ARIN&#39;s fee structure provides a graduated system wherein organizations<br/>pay based on the amount of number resources they consume.<br/><br/>At the very bottom end of the scale, it is presently not possible to be<br/>an XX-Small ISP with an IPv6 allocation because the minimum allocation<br/>size of /36 automatically promotes one into X-Small ISP status,<br/>resulting in a doubling of annual fees.<br/><br/>While tiny in absolute terms, the extra costs incurred represent a<br/>disincentive to IPv6 deployment.<br/><br/>To the author&#39;s knowledge, it has never been possible for an LIR/ISP to<br/>get a /40 allocation direct from ARIN; such assignments have been<br/>limited to organizations that qualify as end sites or /48s for critical<br/>infrastructure.  It is understood there is an expected correction of the<br/>XX-Small fee category to &quot;/40 or smaller&quot;.<br/><br/>Policy statement:<br/><br/>Part 1: In subsection 6.5.2. Initial Allocation Size, insert &quot;or /40&quot; at<br/>the end of the first sentence of subsection 6.5.2.1 clause (b), and add<br/>a new clause (g), resulting in;<br/><br/>b. In no case shall an LIR receive smaller than a /32 unless they<br/>specifically request a /36 or /40.  In no case shall an ISP receive more<br/>than a /16 initial allocation.<br/><br/>...<br/><br/>g. An LIR that requests a smaller /36 or /40 allocation is entitled to<br/>expand the allocation to any nibble aligned size up to /32 at any time<br/>without renumbering or additional justification.  Such expansions are<br/>not considered subsequent allocations.  However, any expansions beyond<br/>/32 are considered subsequent allocations, and must conform to section<br/>6.5.3.<br/><br/>Part 2: Add a new subsection to section 6 &quot;IPv6&quot;;<br/><br/>6.12 Reduction or Return<br/><br/>ARIN will accept the return of whole or partial block(s) allowing an<br/>organization to reduce their holdings as long as:<br/><br/>a. The resulting number of retained aggregate blocks does not increase.<br/><br/>b. Whole blocks are returned to the extent practicable.<br/><br/>c. Partial block(s) retained must conform to current applicable<br/>allocation or assignment policies, as to size, alignment, etc&hellip;<br/><br/>d. Block(s) retained are within a single reserved space or aggregate set<br/>aside for the organization in the ARIN database to the extent practicable.<br/><br/>e. All block(s) returned are not in use by the organization or its<br/>customers.<br/><br/>Comments:<br/><br/>The author acknowledges the shortcomings of providing an ISP with an<br/>allocation of a size that is more traditionally associated with end<br/>sites. In order to avoid possible bad effects on the routing table, the<br/>author encourages ARIN staff to adopt the same sparse allocation<br/>practice as currently exists for larger allocations, ideally even<br/>reserving a block as large as the /28 that is reserved for /32s<br/>currently.  Note the policy intent of part 1 requires a minimum of a /32<br/>be reserved.<br/><br/>Part 1 brings ARIN&#39;s allocation policies in line with the upcoming fee<br/>schedule, with the addition of an expected correction of the XX-Small<br/>fee category to &quot;/40 or smaller&quot;.  This makes it possible to qualify for<br/>each ISP fee category while holding IPv6 number resources and allows<br/>expansion up to /32 without renumbering or additional justification as a<br/>subsequent allocation.  The selection of a /32, /36 or /40 allocation is<br/>only driven by an ISP&#39;s own internal business justifications.<br/><br/>Part 2 codifies and expands upon current practice for selective return<br/>in the manner described by John Curran on the arin-discuss mailing list<br/>(7-Mar-2013 in<br/>8DA1853CE466B041B104C1CAEE00B3748F9239EA at CHAXCH01.corp.arin.net ). It<br/>specifies the generic requirements that should be met for such returns.<br/><br/>A more practical approach might to figure out a way to apply graduated<br/>fees to ISPs at the very small end of the scale using some metric other<br/>than prefix size. Fee schedules are outside of the purview of the Policy<br/>Development Process; such responsibility lies with the Board should they<br/>choose to take it up.<br/><br/>Summary of community discussion:<br/><br/>The fundamental argument against this draft policy is that the primary<br/>problem being solved is a billing or fee structure issue and not a<br/>number resource policy issue in itself.  A significant minority are<br/>adamant on this issue to the extent they oppose this policy. The<br/>majority of the community recognizes this issue, and would prefer /32 be<br/>the sole minimum allocation size for ISPs and other LIRs.  However, the<br/>majority are willing to accept the tradeoffs incorporated into this<br/>policy.  As there are too many ISPs that fit into the /32 allocation<br/>category for the fee level associated with the XX-Small category to be<br/>fiscally responsible and sustainable for ARIN. Furthermore, there are no<br/>obvious solutions to this problem within the fee structure domain that<br/>are fiscally responsible and sustainable for ARIN, especially in the<br/>long-term.<br/><br/>Everyone agrees making /36 or /40 allocations to ISPs seems less than<br/>ideal from a number resource policy perspective.  However, this is<br/>mitigated by ensuring that all ISPs have a /32 available to them without<br/>renumbering or additional justification and from a number resource<br/>policy perspective the selection of /36 or /40 allocations is completely<br/>voluntary.  This allows each ISP to make the decision to select from a<br/>/32, /36 or /40 initial allocation based solely on their own internal<br/>business justifications, and eliminates structural disincentives in the<br/>fee schedule for IPv6 adoption.  This seems like the best balance<br/>available at this time of number resource policy, fiscal responsibility<br/>and sustainability for both ARIN and the ISPs that it serves.<br/><br/>Timetable for implementation: Immediate<br/><br/>]]></content:encoded>
</item>
</rdf:RDF>