<div dir="ltr">Hi PPML,<div><br></div><div>Similar disclaimer to what Chris has shared, this opinion I am sharing is my own, and not that of the AC.</div><div><br></div><div>Although I am not in favor of the policy right now, one question I think we should bear in mind for this discussion is the following. </div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>How many years do we hope IPv6 will last? </div></blockquote><div><br></div>I sincerely hope that our preference as a community and individually is on the order of centuries, not decades. With the Internet poised to go inter-planetary soon (and who knows where in 100 years) I have hopes of a long-lasting durability to IPv6. I do think we should prefer to see very few organizations get up to or more than a /16 as a means of achieving that end.<div><br></div><div>With that said, I don't take a single instance as reason for alarm. As others have said, it would be worth monitoring and being prepared to revisit this question if a large number of very large allocations are given. But for now it seems to be quite exceptional.<br><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br></div><div>My personal conclusion for the time being is that I am opposed to the policy and prefer the wait and see approach to discover how many others (if any) will seek to justify a /16.</div><div><br></div><div>Opposed for now.</div><div><br></div><div dir="ltr">Matthew Wilder</div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 13, 2024 at 8:47 AM Chris Woodfield <<a href="mailto:chris@semihuman.com">chris@semihuman.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>Disclaimer - AC Member speaking in my own capacity with no other affiliations. For the record, I do not support this policy as written.<div><br></div><div>I think we’ve got two competing interests, both a bit speculative IMO.</div><div><br></div><div>On one side, opposition to this policy is based on a trust that the number of organizations that justify a /16 are few and far between, and will not represent a threat to the IPv6 address supply at any point in time where IPv6 is in common use.</div><div><br></div><div>One the other, support for the policy seems to be based on two major concerns: 1. The worry that over time, large numbers of organizations will request and justify /16 blocks to the point that those allocations *do* represent an exhaustion threat for IPv6, and 2. A not-unreasonable sense of wastefulness that the nibble boundary allocation policy imposes when allocations get to this size. An organization receiving a /16 when they only need two or three /20s winds up wasting an order of magnitude more address space than, say, an organization getting a /20 because they need two /24s. And at these sizes, I can understand people getting uneasy…particularly if there’s a lingering concern that (like IPv4 /8s mentioned below) there might be some point where IPv6 exhaustion makes those huge blocks monetizable.</div><div><br></div><div>TBH I share the sense of wastefulness that these allocations represent, but I know that’s not based on data, and as such, I’m not going to throw my support behind this policy based on a feeling. That said, if that’s something the community agrees we should address, I do not believe that the solution is to place a lower cap on allocations; I’d argue that a more reasonable approach to this would be to eliminate the nibble boundary allocation policy at a certain threshold - (i.e. an organization needing two /20s gets a /19, not a /16). This would allow organizations that demonstrate that need to still get their allocations, while avoiding large amounts of stranded resources that the current policy would impose. </div><div><br></div><div>Thanks,</div><div><br></div><div>-Chris</div><div><br></div><div><div><blockquote type="cite"><div>On Aug 13, 2024, at 08:17, Matt Erculiani <<a href="mailto:merculiani@gmail.com" target="_blank">merculiani@gmail.com</a>> wrote:</div><br><div><div dir="auto">I’m in the wait and see camp. Opposed for now.</div><div dir="auto"><br></div><div dir="auto">I think staff has proven to be vigilant about IP space overallocation with all the practice they’ve had with v4. If they’re even half as strict with v6 then there’s no actual problem here.</div><div dir="auto"><br></div><div dir="auto">That said, a /16 is a REALLY big slice of the pie and it might be best to put some additional parameters around what justifies that large of an allocation.</div><div dir="auto"><br></div><div dir="auto">Is /16 the new /8? </div><div dir="auto"><br></div><div dir="auto">-Matt</div><div dir="auto"><br></div><div dir="auto"><div dir="auto"><div dir="ltr" class="gmail_signature"><div dir="ltr">Matt Erculiani<br></div></div></div></div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 13, 2024 at 08:17 Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" target="_blank">fhfrediani@gmail.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="auto">If in practice no organizations can justify that size of block I don't think restricting is pramature really. And no one can.<div dir="auto">At least doesn't give any ideas to one that may think about creating a unexistant need.</div></div><div dir="auto"><div dir="auto"><br></div><div dir="auto">Fernando</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 13 Aug 2024, 05:26 jordi.palet--- via ARIN-PPML, <<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</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>+1<div><br></div><div>If any organization can justify the need for a /16, should be able to get it.</div><div><br></div><div>Even I will say, if any organization can justify, for example, a /12 (I doubt it), should be able to get it.</div><div><br></div><div>Limiting IPv6 deployments is a non-sense.<br><div><br id="m_6229951301101695021m_-6747283402562771862m_-5789179287356288477lineBreakAtBeginningOfMessage"><div>
<div>Regards,<br>Jordi<br><br>@jordipalet<br><br></div>
</div>
<div><br><blockquote type="cite"><div>El 12 ago 2024, a las 23:33, David Farmer via ARIN-PPML <<a href="mailto:arin-ppml@arin.net" rel="noreferrer" target="_blank">arin-ppml@arin.net</a>> escribió:</div><br><div><div dir="ltr"><div dir="ltr">/16 is a reasonable limit; keep the current NRPM. One /16 allocation in nearly a decade does not concern me. /16 allocations were intended to be rare but possible; in fact, I believe the policy is functioning as intended. If we see several additional /16 allocations in the next couple of years, I could be convinced to reconsider my position. But at this point, I think this policy is premature.</div><div dir="ltr"><br></div><div>Thanks</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 12, 2024 at 2:12 PM Elizabeth Goodson <<a href="mailto:elizabeth.goodson@gmail.com" rel="noreferrer" target="_blank">elizabeth.goodson@gmail.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>Hello PPML,</div><div><br></div><div>As lead shepherd on ARIN-2024-8, I'm reaching out for additional feedback from the community on this policy following the robust discussion here in June.</div><div><br></div><div>The previous discussion did not come to a clear community consensus with opinions falling in multiple categories (in no particular order):</div><div>- /20 is a reasonable limit, support the Draft Policy as written</div><div>- /16 is a reasonable limit, keep current NRPM</div><div>- Allow initial allocations above a certain size that are not on a nibble boundary (e.g. /19, /18, /17)</div><div>- Add clarification about what designs would not justify a certain size initial allocation (e.g. 6RD)</div><div><br></div><div>Questions for the community:</div><div>- Do you support the draft policy as written?</div><div>- If not, can the policy be changed so you would support it? What change(s) do you support?</div><div>- Should the community continue to work on the policy or abandon it?</div><div><br></div><div>Thanks,</div><div>Liz Goodson</div><div><br><div>===============</div><div>Problem Statement:<br>In order to promote aggregation, the NRPM currently allows initial allocations up to a /16. However, the entire IPv6 address space only contains 65536 /16s, and the space allocated to IANA for globally routable purposes only contains 8192 /16s. Therefore, a /16 is a sufficiently large portion of the IPv6 address space that the goal of conservation starts to outweigh the goal of aggregation.<br><br>Policy Statement:<br>6.5.2.1b: Replace "In no case shall an ISP receive more than a /16 initial allocation." with "In no case shall a LIR receive more than a /20 initial allocation."<br></div></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" rel="noreferrer" 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 noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" rel="noreferrer" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" rel="noreferrer" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br><a href="https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g" target="_blank">2218 University Ave SE</a> Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>=============================================== </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" rel="noreferrer" 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" rel="noreferrer" target="_blank">info@arin.net</a> if you experience any issues.<br></div></blockquote></div><br></div></div><br>**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
<a href="http://www.theipv6company.com/" rel="noreferrer" target="_blank">http://www.theipv6company.com</a><br>
The IPv6 Company<br>
<br>
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.<br>
<br>
</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" rel="noreferrer" 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 noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" rel="noreferrer" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></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></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" 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></div></blockquote></div><br></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>