[arin-ppml] Request for Feedback: Draft Policy ARIN-2024-8 Restrict the Largest Initial IPv6 Allocation to /20

Tue Aug 13 11:46:49 EDT 2024

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 <merculiani at gmail.com> 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 <fhfrediani at gmail.com <mailto:fhfrediani at gmail.com>> 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, <arin-ppml at arin.net <mailto:arin-ppml at arin.net>> 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 <arin-ppml at arin.net <mailto:arin-ppml at arin.net>> 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 <elizabeth.goodson at gmail.com <mailto:elizabeth.goodson at gmail.com>> 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 (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>>>> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
>>>> 
>>>> 
>>>> --
>>>> ===============================================
>>>> David Farmer               Email:farmer at umn.edu <mailto:Email%3Afarmer at umn.edu>
>>>> 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 (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net <mailto:info at arin.net> 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 (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
>>> Unsubscribe or manage your mailing list subscription at:
>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
>> _______________________________________________
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20240813/02ce2ad5/attachment-0001.htm>