<div dir="ltr"><div>I support this policy as written. </div><div><br></div><div>However, I recommend a minor editorial change and a small change to the policy;</div><div><br></div><div>1. I would prefer to not use "smaller" or "less" when referring to /24 or longer prefixes, such use is somewhat ambiguous, this has been discussed many times on PPML.</div><div><br></div><div>2. I really like the idea of automatically increasing the IPv6 allocation to /36 when the IPv4 allocation increases beyond /24. How about also automatically increasing the IPv6 allocation to /32 when the IPv4 allocation increases beyond /22?</div><div><br></div><div>Thanks</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 24, 2020 at 12:22 PM ARIN <<a href="mailto:info@arin.net">info@arin.net</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Draft Policy ARIN-2020-3: IPv6 Nano-allocations<br>
<br>
Problem Statement:<br>
<br>
ARIN's fee structure provides a graduated system wherein organizations<br>
pay based on the amount of number resources they consume.<br>
<br>
In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 or <br>
smaller of IPv4) gets the present minimal-sized IPv6 allocation (a /36), <br>
its annual fees will double from $250 to $500/year.<br>
<br>
According to a Policy Experience Report presented by Registration <br>
Services to the AC at its annual workshop in January 2020, this <br>
represents a disincentive to IPv6 adoption with a substantial fraction <br>
of so-situated ISPs saying "no thanks" and abandoning their request for <br>
IPv6 number resources when informed of the impact on their annual fees.<br>
<br>
This can be addressed by rewriting subsection 6.5.2(b). Initial <br>
Allocation Size to allow allocation of a /40 to only the smallest ISPs <br>
upon request, and adding a new clause 6.5.2(g) to cause an automatic <br>
upgrade to at least a /36 in the case where the ISP is no longer 3X-Small.<br>
<br>
Reserving /40s only for organizations initially expanding into IPv6 from <br>
an initial sliver of IPv4 space will help to narrowly address the <br>
problem observed by Registration Services while avoiding unintended <br>
consequences by accidentally giving a discount for undersized allocations.<br>
<br>
Policy Statement:<br>
<br>
Replace the current 6.5.2(b) with the following:<br>
<br>
b. In no case shall an LIR receive smaller than a /32 unless they<br>
specifically request a /36 or /40.<br>
<br>
In order to be eligible for a /40, an ISP must meet the following <br>
requirements:<br>
* Hold IPv4 direct allocations totaling a /24 or less (to include zero)<br>
* Hold IPv4 reassignments/reallocations totaling a /22 or less (to <br>
include zero)<br>
<br>
In no case shall an ISP receive more than a /16 initial allocation.<br>
<br>
Add 6.5.2(g) as follows:<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. /40 allocations shall <br>
be automatically upgraded to /36 if at any time said LIR's IPv4 direct <br>
allocations exceed a /24. Expansions up to and including a /32 are not <br>
considered subsequent allocations, however any expansions beyond /32 are <br>
considered subsequent allocations and must conform to section 6.5.3. <br>
Downgrades of any IPv6 allocation to less than a /36 are not permitted <br>
regardless of the ISP's current or former IPv4 number resource holdings.<br>
<br>
Comments:<br>
<br>
The intent of this policy proposal is to make IPv6 adoption at the very <br>
bottom end expense-neutral for the ISP and revenue-neutral for ARIN. The <br>
author looks forward to a future era wherein IPv6 is the dominant <br>
technology and IPv4 is well in decline and considered optional leading <br>
the Community to conclude that sunsetting this policy is prudent in the <br>
interests of avoiding an incentive to request undersized IPv6 allocations.<br>
<br>
Timetable for implementation: Immediate<br>
<br>
_______________________________________________<br>
ARIN-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="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/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>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>=============================================== </div></div>