<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 13, 2020, at 08:55 , Andrew Dul <<a href="mailto:andrew.dul@quark.net" class="">andrew.dul@quark.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class="">
<div class="moz-cite-prefix">David, Thanks for your comments. <br class="">
</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">On 3/26/2020 4:08 PM, David Farmer
wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:CAN-Dau1LoHiXiwdbMqukUbO6pOvh9swK_1DBM2L-2rHRToy9Vg@mail.gmail.com" class="">
<meta http-equiv="content-type" content="text/html; charset=UTF-8" class="">
<div dir="ltr" class="">
<div class="">I support this policy as written. </div>
<div class=""><br class="">
</div>
<div class="">However, I recommend a minor editorial change and a small
change to the policy;</div>
<div class=""><br class="">
</div>
<div class="">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>
</blockquote>
Noted.<br class="">
<blockquote type="cite" cite="mid:CAN-Dau1LoHiXiwdbMqukUbO6pOvh9swK_1DBM2L-2rHRToy9Vg@mail.gmail.com" class="">
<div dir="ltr" class="">
<div class=""><br class="">
</div>
<div class="">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>
</blockquote><p class="">The goal of this policy is to create IPv6 allocation sizes such
that a current IPv4 organization which is currently 3X-small can
obtain an IPv6 allocation without their fees going up. Today this
issue only occurs with 3x-small. If we were to implement this
other change I believe this would cause the text to move beyond
the current problem statement. <br class=""></p></div></div></blockquote><div><br class=""></div>I don’t entirely agree. The goal of the /36 policy was very similar to the goal here for /40s. Prior to the implementation of the /36 policy, the situation was similar.</div><div><br class=""></div><div>As such, I do think it makes sense to extend the auto-bump language up to /32 as part of this policy. TBH, the only reason it isn’t already there for /36s IMHO is that we didn’t think of it at the time.</div><div><blockquote type="cite" class=""><div class=""><div class=""><p class="">
</p><p class="">I will also like to note, that this issue could also be remedied
by the board adopting a small change to the fee schedule such that
the 3x-small IPv6 holdings do not force a change in category for
3x-small organizations. This would cause 3x-small organization's
fees to be primarily determined by their IPv4 holdings not their
IPv6 holdings.</p></div></div></blockquote>Yep… And I hope they’ll finally do something about this, but let’s see what happens. I think this policy proposal is a good backstop to that.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">While the community doesn't have purview over fees we have input
into that process. If this is something that we would strongly
like to prefer as a solution to this problem. We can make this as
a strong suggestion to the board for their consideration.</p></div></div></blockquote>I believe this has been communicated to the board on more than one occasion.</div><div><br class=""></div><div>Owen</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">Andrew<br class="">
</p><p class=""><br class="">
</p>
<blockquote type="cite" cite="mid:CAN-Dau1LoHiXiwdbMqukUbO6pOvh9swK_1DBM2L-2rHRToy9Vg@mail.gmail.com" class="">
<div dir="ltr" class="">
<div class=""><br class="">
</div>
<div class="">Thanks</div>
<br class="">
<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" moz-do-not-send="true" class="">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 class="">
<br class="">
Problem Statement:<br class="">
<br class="">
ARIN's fee structure provides a graduated system wherein
organizations<br class="">
pay based on the amount of number resources they consume.<br class="">
<br class="">
In the case of the very smallest ISPs, if a 3X-Small ISP
(with a /24 or <br class="">
smaller of IPv4) gets the present minimal-sized IPv6
allocation (a /36), <br class="">
its annual fees will double from $250 to $500/year.<br class="">
<br class="">
According to a Policy Experience Report presented by
Registration <br class="">
Services to the AC at its annual workshop in January 2020,
this <br class="">
represents a disincentive to IPv6 adoption with a
substantial fraction <br class="">
of so-situated ISPs saying "no thanks" and abandoning their
request for <br class="">
IPv6 number resources when informed of the impact on their
annual fees.<br class="">
<br class="">
This can be addressed by rewriting subsection 6.5.2(b).
Initial <br class="">
Allocation Size to allow allocation of a /40 to only the
smallest ISPs <br class="">
upon request, and adding a new clause 6.5.2(g) to cause an
automatic <br class="">
upgrade to at least a /36 in the case where the ISP is no
longer 3X-Small.<br class="">
<br class="">
Reserving /40s only for organizations initially expanding
into IPv6 from <br class="">
an initial sliver of IPv4 space will help to narrowly
address the <br class="">
problem observed by Registration Services while avoiding
unintended <br class="">
consequences by accidentally giving a discount for
undersized allocations.<br class="">
<br class="">
Policy Statement:<br class="">
<br class="">
Replace the current 6.5.2(b) with the following:<br class="">
<br class="">
b. In no case shall an LIR receive smaller than a /32 unless
they<br class="">
specifically request a /36 or /40.<br class="">
<br class="">
In order to be eligible for a /40, an ISP must meet the
following <br class="">
requirements:<br class="">
* Hold IPv4 direct allocations totaling a /24 or less (to
include zero)<br class="">
* Hold IPv4 reassignments/reallocations totaling a /22 or
less (to <br class="">
include zero)<br class="">
<br class="">
In no case shall an ISP receive more than a /16 initial
allocation.<br class="">
<br class="">
Add 6.5.2(g) as follows:<br class="">
<br class="">
g. An LIR that requests a smaller /36 or /40 allocation is
entitled to <br class="">
expand the allocation to any nibble aligned size up to /32
at any time <br class="">
without renumbering or additional justification. /40
allocations shall <br class="">
be automatically upgraded to /36 if at any time said LIR's
IPv4 direct <br class="">
allocations exceed a /24. Expansions up to and including a
/32 are not <br class="">
considered subsequent allocations, however any expansions
beyond /32 are <br class="">
considered subsequent allocations and must conform to
section 6.5.3. <br class="">
Downgrades of any IPv6 allocation to less than a /36 are not
permitted <br class="">
regardless of the ISP's current or former IPv4 number
resource holdings.<br class="">
<br class="">
Comments:<br class="">
<br class="">
The intent of this policy proposal is to make IPv6 adoption
at the very <br class="">
bottom end expense-neutral for the ISP and revenue-neutral
for ARIN. The <br class="">
author looks forward to a future era wherein IPv6 is the
dominant <br class="">
technology and IPv4 is well in decline and considered
optional leading <br class="">
the Community to conclude that sunsetting this policy is
prudent in the <br class="">
interests of avoiding an incentive to request undersized
IPv6 allocations.<br class="">
<br class="">
Timetable for implementation: Immediate<br class="">
<br class="">
_______________________________________________<br class="">
ARIN-PPML<br class="">
You are receiving this message because you are subscribed to<br class="">
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" moz-do-not-send="true" class="">ARIN-PPML@arin.net</a>).<br class="">
Unsubscribe or manage your mailing list subscription at:<br class="">
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" moz-do-not-send="true" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">
Please contact <a href="mailto:info@arin.net" target="_blank" moz-do-not-send="true" class="">info@arin.net</a>
if you experience any issues.<br class="">
</blockquote>
</div>
<br clear="all" class="">
<div class=""><br class="">
</div>
-- <br class="">
<div dir="ltr" class="gmail_signature">===============================================<br class="">
David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank" moz-do-not-send="true" class="">Email:farmer@umn.edu</a><br class="">
Networking & Telecommunication Services<br class="">
Office of Information Technology<br class="">
University of Minnesota <br class="">
2218 University Ave SE Phone: 612-626-0815<br class="">
Minneapolis, MN 55414-3029 Cell: 612-812-9952<br class="">
=============================================== </div>
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote><p class=""><br class="">
</p>
</div>
_______________________________________________<br class="">ARIN-PPML<br class="">You are receiving this message because you are subscribed to<br class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">Unsubscribe or manage your mailing list subscription at:<br class=""><a href="https://lists.arin.net/mailman/listinfo/arin-ppml" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">Please contact info@arin.net if you experience any issues.<br class=""></div></blockquote></div><br class=""></body></html>