Disclaimer - AC Member speaking in my own capacity with no other affiliations. For the record, I do not support this policy as written.
I think we’ve got two competing interests, both a bit speculative IMO. 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. 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. 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. Thanks, -Chris > On Aug 13, 2024, at 08:17, Matt Erculiani <[email protected]> wrote: > > I’m in the wait and see camp. Opposed for now. > > 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. > > 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. > > Is /16 the new /8? > > -Matt > > Matt Erculiani > > > On Tue, Aug 13, 2024 at 08:17 Fernando Frediani <[email protected] > <mailto:[email protected]>> wrote: >> If in practice no organizations can justify that size of block I don't think >> restricting is pramature really. And no one can. >> At least doesn't give any ideas to one that may think about creating a >> unexistant need. >> >> Fernando >> >> On Tue, 13 Aug 2024, 05:26 jordi.palet--- via ARIN-PPML, <[email protected] >> <mailto:[email protected]>> wrote: >>> +1 >>> >>> If any organization can justify the need for a /16, should be able to get >>> it. >>> >>> Even I will say, if any organization can justify, for example, a /12 (I >>> doubt it), should be able to get it. >>> >>> Limiting IPv6 deployments is a non-sense. >>> >>> Regards, >>> Jordi >>> >>> @jordipalet >>> >>> >>>> El 12 ago 2024, a las 23:33, David Farmer via ARIN-PPML >>>> <[email protected] <mailto:[email protected]>> escribió: >>>> >>>> /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. >>>> >>>> Thanks >>>> >>>> On Mon, Aug 12, 2024 at 2:12 PM Elizabeth Goodson >>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> Hello PPML, >>>>> >>>>> 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. >>>>> >>>>> The previous discussion did not come to a clear community consensus with >>>>> opinions falling in multiple categories (in no particular order): >>>>> - /20 is a reasonable limit, support the Draft Policy as written >>>>> - /16 is a reasonable limit, keep current NRPM >>>>> - Allow initial allocations above a certain size that are not on a nibble >>>>> boundary (e.g. /19, /18, /17) >>>>> - Add clarification about what designs would not justify a certain size >>>>> initial allocation (e.g. 6RD) >>>>> >>>>> Questions for the community: >>>>> - Do you support the draft policy as written? >>>>> - If not, can the policy be changed so you would support it? What >>>>> change(s) do you support? >>>>> - Should the community continue to work on the policy or abandon it? >>>>> >>>>> Thanks, >>>>> Liz Goodson >>>>> >>>>> =============== >>>>> Problem Statement: >>>>> 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. >>>>> >>>>> Policy Statement: >>>>> 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." >>>>> ================== >>>>> _______________________________________________ >>>>> ARIN-PPML >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Public Policy Mailing List ([email protected] >>>>> <mailto:[email protected]>). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> https://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact [email protected] <mailto:[email protected]> if you experience any >>>>> issues. >>>> >>>> >>>> -- >>>> =============================================== >>>> David Farmer Email:[email protected] >>>> <mailto:email%[email protected]> >>>> Networking & Telecommunication Services >>>> Office of Information Technology >>>> University of Minnesota >>>> 2218 University Ave SE >>>> <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g> >>>> Phone: 612-626-0815 >>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>>> =============================================== >>>> _______________________________________________ >>>> ARIN-PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List ([email protected] >>>> <mailto:[email protected]>). >>>> Unsubscribe or manage your mailing list subscription at: >>>> https://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact [email protected] <mailto:[email protected]> if you experience any >>>> issues. >>> >>> >>> ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> http://www.theipv6company.com <http://www.theipv6company.com/> >>> The IPv6 Company >>> >>> 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. >>> >>> _______________________________________________ >>> ARIN-PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List ([email protected] >>> <mailto:[email protected]>). >>> Unsubscribe or manage your mailing list subscription at: >>> https://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact [email protected] <mailto:[email protected]> if you experience any >>> issues. >> _______________________________________________ >> ARIN-PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ([email protected] >> <mailto:[email protected]>). >> Unsubscribe or manage your mailing list subscription at: >> https://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected] <mailto:[email protected]> if you experience any >> issues. > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues.
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
