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

Thu Aug 15 14:26:05 EDT 2024

Speaking simply and purely for myself.

I agree with the assertions that this *_may_* be premature, due to the vast
address space that IPv6 offers.  However, we do have past experience with
IPv4 and address exhaustion or even address "hoarding".  Yes, it is
required to provide sufficient justification for such a request, though,
and this provides some guardrails in the interim.  This allows some support
for a "wait and see" approach.

On the other hand, being proactive with hindsight and the IPv4 exhaustion
experience, I think that there is some merit in Chris' suggestion to remove
the limits based on nibble boundaries.

 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.

- Chris Woodfield

This would allow us to be proactive, not actually remove the option of
issuing a /16 if there is a need (and sufficient justification), while also
lowering the threshold for organizations who may need, say, two /20s, to
receive a /19 and not needing to then provide justification for a /16,
which is not actually needed.

As such, this presents a commonsense approach to addressing a
"not-yet-there" problem, without negatively impacting any current potential
beneficiaries.

*Gerry E. George*
ICT Consultant & Business Solutions Architect; Open Source Evangelist
*DigiSolv, Inc.* [P.O. Box 1677, Castries, Saint Lucia]

On Tue, Aug 13, 2024 at 4:06 PM Matthew Wilder via ARIN-PPML <
arin-ppml at arin.net> wrote:

> Hi PPML,
>
> Similar disclaimer to what Chris has shared, this opinion I am sharing is
> my own, and not that of the AC.
>
> 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.
>
> How many years do we hope IPv6 will last?
>
>
> 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.
>
> 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.
>
> 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.
>
> Opposed for now.
>
> Matthew Wilder
>
>
> On Tue, Aug 13, 2024 at 8:47 AM Chris Woodfield <chris at semihuman.com>
> wrote:
>
>> 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>
>> 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> 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> 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> 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).
>>>>> 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.
>>>>>
>>>>
>>>>
>>>> --
>>>> ===============================================
>>>> David Farmer               Email:farmer 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).
>>>> 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.
>>>>
>>>>
>>>>
>>>> **********************************************
>>>> IPv4 is over
>>>> Are you ready for the new Internet ?
>>>> 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).
>>>> 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/20240815/24779a1e/attachment-0001.htm>