<div dir="ltr"><div dir="ltr">No, thank you for the effort in writing the proposal, while I think it goes too far by eliminating 6.5.8.1 altogether, it has been about 10 years since 6.5.8.1.c & d were put in place with ARIN-2010-8 and about 5 years since 6.5.8.1.e was put in place with ARIN-2015-1. It wouldn't hurt at all to review those criteria and make sure they meet the community's needs today. Furthermore, if you think we need to clarify "active use" that is perfectly appropriate, we could have easily oversimplified the criteria to the point people new to policy don't really understand what we mean. If that is the case, that is really good feedback. </div><div dir="ltr"><br></div><div>My suggestion is to work with the AC Shepherds and focus on reviewing 6.5.8.1.c-e. If it was me, I would propose cutting the number in "c" and "d" in half as a starting point for the discussion, the IPv4 initial allocation criteria have changed significantly since ARIN-2010-8. I think "e" is probably about right but if you have other ideas let's hear them, and if you have ideas for better wording let's hear that too. There is nothing sacred about those numbers or those criteria, but I think there is strong agreement that there needs to be some kind of criteria that single-homed end-users need to meat</div><div><br></div><div>Thanks.</div><div dir="ltr"> </div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 13, 2021 at 2:05 PM Larry R. Dockery <<a href="mailto:lrdocker@co.douglas.or.us">lrdocker@co.douglas.or.us</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 lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_2814450204554966879WordSection1">
<p class="MsoNormal">Thank you for your time in providing this information. This is the best argument against the proposal.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">If this is a significant issue and holds true, then 1) most organizations do not and should not qualify for PI space. And 2) These orgs should, per the design recommendation in “IPv6 Address Planning”, use NTPv6 with ULA internally to avoid
ISP lock-in inherent with IPV6 PA space. <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">This is far better than IPv4 NAT + RFC1918 in that it is stateless, but is an unfortunate workaround that somewhat inhibits the end-to-end principle.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">That would be an unfortunate end-state for IPv6 that most SMB’s are still behind NAT, but may be the best technical way forward.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> <br>
<b>Sent:</b> Monday, September 13, 2021 10:32 AM<br>
<b>To:</b> Larry R. Dockery <<a href="mailto:lrdocker@co.douglas.or.us" target="_blank">lrdocker@co.douglas.or.us</a>><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] Proposal - Remove Initial Small Assignment Requirements for IPv6<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">The intent behind section 6.5.8.1 is not to conserve IPv6 address space but to conserve slots in the IPv6 route table, AKA the default-free zone. The abundance of /48s and /44s, or /40s, /36s, /32s for that matter, are irrelevant, there
is only a finite number of routing slots available. BGP multihomed end-users will use a routing slot regardless of the source of the address space they use, so it is best if it comes from an RIR. However, single-homed end-users can be aggregated by their provider,
yes this comes at a cost of renumbering for those end-users, but eliminating renumbering for those end-users comes at a cost of an IPv6 routing slot for the entire Internet. Therefore the cost of renumbering born by the end-user has to be balanced against
the cost of a routing slot born by the entire Internet.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The IPv6 route table is currently growing quite quickly, see the following;<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><a href="https://blog.apnic.net/2021/03/03/what-will-happen-when-the-routing-table-hits-1024k/" target="_blank">https://blog.apnic.net/2021/03/03/what-will-happen-when-the-routing-table-hits-1024k/</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="https://blog.apnic.net/2021/01/05/bgp-in-2020-the-bgp-table/" target="_blank">https://blog.apnic.net/2021/01/05/bgp-in-2020-the-bgp-table/</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="https://blog.apnic.net/2020/01/14/bgp-in-2019-the-bgp-table/" target="_blank">https://blog.apnic.net/2020/01/14/bgp-in-2019-the-bgp-table/</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="https://labs.ripe.net/author/stephen_strowes/visibility-of-ipv4-and-ipv6-prefix-lengths-in-2019/" target="_blank">https://labs.ripe.net/author/stephen_strowes/visibility-of-ipv4-and-ipv6-prefix-lengths-in-2019/</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="https://bgp.potaroo.net/v6/as2.0/index.html" target="_blank">https://bgp.potaroo.net/v6/as2.0/index.html</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="https://www.space.net/~gert/RIPE/weekly/2021/37/" target="_blank">https://www.space.net/~gert/RIPE/weekly/2021/37/</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The current 6.5.8.1.c was adapted from the IPv4 requirements when Draft Policy 2010-8: Rework of IPv6 assignment criteria was adopted. At that time IPv4 slow-start was still in effect, and there was still an IPv4 free pool. When the IPv4
transfer market became the primary source of IPv4 address space, slow-start was no longer practical or functional, and the initial allocation for IPv4 was changed. However, for IPv4 there is now the additional cost of obtaining the IPv4 block on the transfer
market which somewhat offsets the removal to slow-start at least to some extent.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">So, while I do not support the wholesale removal of section 6.5.8.1, I would support relaxing, possibly significantly relaxing, or otherwise modifying 6.5.8.1.c-e which are the current technical qualification for non-multihomed end-users.
Fundamentally, it is not practical to have every business that could afford to pay ARIN's fees to avoid renumbering and to receive an IPv6 routing slot. It is not even entirely clear, there will be sufficient IPv6 routing slots for every end-user that is willing
to BGP multi-home.<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Therefore, I believe there needs some kind of technical criteria that a non-multihomed end-user needs to meet to qualify to receive a Provider Independent IPv6 Allocation, and it needs to be more than just the ability to pay ARIN's fees.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">And for clarity, I do not support the proposal as written.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Sep 13, 2021 at 9:51 AM Larry R. Dockery <<a href="mailto:lrdocker@co.douglas.or.us" target="_blank">lrdocker@co.douglas.or.us</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><a href="https://www.arin.net/participate/policy/proposals/2021/ARIN_prop_301_orig/" target="_blank">https://www.arin.net/participate/policy/proposals/2021/ARIN_prop_301_orig/</a><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">I would like to hear community feedback on this proposal. Thank you.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<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.<u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<p class="MsoNormal">===============================================<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>
=============================================== <u></u><u></u></p>
</div>
</div>
</div>
</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>