<div dir="ltr"><div class="gmail_default" style="font-size:small">+1 Leif's recommended wording.<br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>—<br>Brian <br></div><div><a href="mailto:bjones@vt.edu" target="_blank">bjones@vt.edu</a></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 21, 2020 at 12:34 PM Leif Sawyer <<a href="mailto:lsawyer@gci.com">lsawyer@gci.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div dir="ltr">
<div id="gmail-m_-1548850531146609251divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p>"Partial returns of any IPv6 allocation that results in less than a /36 of holding are not permitted, [...]"<br>
</p>
<p><br>
</p>
<p>This would seem to address Albert's issue, and remove the uncertainty of "downgrade" while allowing for a "complete return" of IPv6 space.</p>
<p><br>
</p>
<p><br>
</p>
<div id="gmail-m_-1548850531146609251Signature">
<div id="gmail-m_-1548850531146609251divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,"EmojiFont","Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div style="font-family:Tahoma;font-size:13px">
<div style="font-family:Tahoma;font-size:13px">
<div dir="auto"></div>
</div>
<span id="gmail-m_-1548850531146609251ms-rterangepaste-start"></span>
<div style="font-family:Calibri;font-size:14.6667px"><b>Leif Sawyer</b></div>
<div style="font-family:Calibri;font-size:14.6667px"><font color="#B71234"><b>GCI</b><font color="black"> | Enterprise Security Architect</font></font></div>
<div style="font-family:Calibri;font-size:14.6667px"><font size="2"><span style="font-size:10pt"><b>t:</b> <span id="gmail-m_-1548850531146609251gc-number-9" title="Call with Google Voice">907-868-0116</span> | <b>w:</b> <a href="https://www.gci.com" id="gmail-m_-1548850531146609251LPNoLP" target="_blank"><font color="blue"><u>www.gci.com</u></font></a></span></font></div>
<span id="gmail-m_-1548850531146609251ms-rterangepaste-end"></span>
<div style="font-family:Tahoma;font-size:13px"><br>
</div>
</div>
</div>
</div>
<br>
<br>
<div style="color:rgb(0,0,0)">
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-1548850531146609251divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> ARIN-PPML <<a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin.net</a>> on behalf of <a href="mailto:hostmaster@uneedus.com" target="_blank">hostmaster@uneedus.com</a> <<a href="mailto:hostmaster@uneedus.com" target="_blank">hostmaster@uneedus.com</a>><br>
<b>Sent:</b> Tuesday, July 21, 2020 8:10 AM<br>
<b>To:</b> Rob Seastrom<br>
<b>Cc:</b> <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br>
<b>Subject:</b> Re: [arin-ppml] Recommended Draft Policy ARIN-2020-3: IPv6 Nano-allocations</font>
<div> </div>
</div>
<div><font color="ff0000">[<b>EXTERNAL EMAIL</b> - CAUTION: Do not open unexpected attachments or links.]</font>
<br>
<br>
How about "Downgrades of any IPv6 allocation to less than a /36 OTHER THAN <br>
A RETURN OF ALL IPv6 RESOURCES are not permitted regardless of the ISP’s <br>
current or former IPv4 number resource holdings."<br>
<br>
At least this avoids the "Hotel California" issue.<br>
<br>
Albert Erdmann<br>
Network Administrator<br>
Paradise On Line Inc.<br>
<br>
<br>
On Tue, 21 Jul 2020, Rob Seastrom wrote:<br>
<br>
><br>
> Hi Albert,<br>
><br>
> As a practical matter, I don’t think the NRPM overrides your ability to terminate your contract with ARIN should that become a business requirement.<br>
><br>
> Do you have alternative language to suggest that is clear, concise, and preserves the intent of narrowly boxing in nano-allocations for the tiniest of providers with IPv4 rather than incenting undersizing IPv6 allocations? Remember that the whole reason for
 the default /32 allocation is that we wish for IPv6 allocations to be the polar opposite of IPv4 slow-start - a one-and-done approach that minimizes both unnecessary routing table growth and the need to come back to ARIN for more space.<br>
><br>
> Thanks,<br>
><br>
> -r<br>
><br>
><br>
><br>
><br>
>> On Jul 21, 2020, at 11:26 AM, <a href="mailto:hostmaster@uneedus.com" target="_blank">hostmaster@uneedus.com</a> wrote:<br>
>><br>
>> I have a problem with this language:<br>
>><br>
>> "Downgrades of any IPv6 allocation to less than a /36 are not permitted regardless of the ISP’s current or former IPv4 number resource holdings."<br>
>><br>
>> Downgrades include in my mind a return, and thus a downgrade to 0. This language seems to lock in anyone who has ever requested IPv6 space.<br>
>><br>
>> Does this make a request for IPv6 space from ARIN like the Hotel California, where you can never leave....<br>
>><br>
>> If I were one of those ISP's with a /24 of IPv4, and I took the minimum allocation of IPv6 which raised my fees to $500 from $250, does this language make me continue to pay $500/yr even if I decide to return all my IPv6 resources to ARIN, and either get
 IPv6 space from my upstream or forgo use of IPv6?<br>
>><br>
>> Albert Erdmann<br>
>> Network Administrator<br>
>> Paradise On Line Inc.<br>
>><br>
>><br>
>> On Tue, 21 Jul 2020, ARIN wrote:<br>
>><br>
>>> On 16 July 2020, the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status:<br>
>>><br>
>>> ARIN-2020-3: IPv6 Nano-allocations<br>
>>><br>
>>> The text of the Recommended Draft Policy is below, and may also be found at:<br>
>>><br>
>>> <a href="https://www.arin.net/participate/policy/drafts/2020_3" target="_blank">
https://www.arin.net/participate/policy/drafts/2020_3/</a><br>
>>><br>
>>> You are encouraged to discuss all Recommended Draft Policies on PPML prior to their presentation at the next ARIN Public Policy Consultation (PPC). PPML and PPC discussions are invaluable to the AC when determining community consensus.<br>
>>><br>
>>> The PDP can be found at:<br>
>>> <a href="https://www.arin.net/participate/policy/pdp" target="_blank">
https://www.arin.net/participate/policy/pdp/</a><br>
>>><br>
>>> Draft Policies and Proposals under discussion can be found at:<br>
>>> <a href="https://www.arin.net/participate/policy/drafts" target="_blank">
https://www.arin.net/participate/policy/drafts/</a><br>
>>><br>
>>> Regards,<br>
>>><br>
>>> Sean Hopkins<br>
>>> Policy Analyst<br>
>>> American Registry for Internet Numbers<br>
>>><br>
>>><br>
>>><br>
>>> Recommended Draft Policy ARIN-2020-3: IPv6 Nano-allocations<br>
>>><br>
>>> AC Assessment of Conformance with the Principles of Internet Number Resource Policy:<br>
>>><br>
>>> Recommended Draft Policy ARIN-2020-3 provides for small IPv6 allocations to ISPs. This policy would allow the smallest ISP organizations to obtain a /40 of IPv6 addresses. This recommended draft is technically sound, supported by the community and enables
 fair and impartial administration of number resources by providing the smallest organizations the opportunity to obtain an IPv6 allocation without a fee increase under the current fee schedule.<br>
>>><br>
>>> Problem Statement:<br>
>>><br>
>>> ARIN’s ISP registration services fee structure has graduated fee categories based upon the total amount of number resources held within the ARIN registry.<br>
>>><br>
>>> In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 or smaller of IPv4) gets the present minimal-sized IPv6 allocation (a /36), its annual fees will double from $250 to $500/year.<br>
>>><br>
>>> According to a Policy Experience Report presented by Registration Services to the AC at its annual workshop in January 2020, this represents a disincentive to IPv6 adoption with a substantial fraction of so-situated ISPs saying “no thanks” and abandoning
 their request for IPv6 number resources when informed of the impact on their annual fees.<br>
>>><br>
>>> This can be addressed by rewriting subsection 6.5.2.1(b). Initial Allocation Size to allow allocation of a /40 to only the smallest ISPs upon request, and adding a new clause 6.5.2.1(g) to cause an automatic 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 an initial sliver of IPv4 space will help to narrowly address the problem observed by Registration Services while avoiding unintended consequences by accidentally giving a discount
 for undersized allocations.<br>
>>><br>
>>> Policy Statement:<br>
>>><br>
>>> Replace the current 6.5.2.1(b) with the following:<br>
>>><br>
>>> b. In no case shall an LIR receive smaller than a /32 unless they specifically request a /36 or /40.<br>
>>><br>
>>> In order to be eligible for a /40, an ISP must meet the following requirements:<br>
>>><br>
>>> Hold IPv4 direct allocations totaling a /24 or less (to include zero)<br>
>>> Hold IPv4 reassignments/reallocations totaling a /22 or less (to include zero)<br>
>>> In no case shall an ISP receive more than a /16 initial allocation.<br>
>>><br>
>>> Add 6.5.2.1(g) as follows:<br>
>>><br>
>>> g. An LIR that requests a smaller /36 or /40 allocation is entitled to expand the allocation to any nibble aligned size up to /32 at any time without renumbering or additional justification. /40 allocations shall be automatically upgraded to /36 if at any
 time said LIR’s IPv4 direct allocations exceed a /24. Expansions up to and including a /32 are not considered subsequent allocations, however any expansions beyond /32 are considered subsequent allocations and must conform to section 6.5.3. Downgrades of any
 IPv6 allocation to less than a /36 are not permitted regardless of the ISP’s current or former IPv4 number resource holdings.<br>
>>><br>
>>> Timetable for Implementation: Immediate<br>
>>><br>
>>> Comments:<br>
>>><br>
>>> The intent of this policy proposal is to make IPv6 adoption at the very bottom end expense-neutral for the ISP and revenue-neutral for ARIN. The author looks forward to a future era wherein IPv6 is the dominant technology and IPv4 is well in decline and
 considered optional leading the Community to conclude that sunsetting this policy is prudent in the interests of avoiding an incentive to request undersized IPv6 allocations.<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" 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>
>> _______________________________________________<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" 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>
><br>
> </div>
</div>
</div>
</div>

_______________________________________________<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>