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

Fri Jun 28 13:28:09 EDT 2024

Greetings to the list!

David, you incorrectly assume this is IPv4 thinking instead of what it
really is - a desire to streamline the process while providing reasonable
limits. It is true these limits were based on my own observations and
belief a maximum of a /28 initial allocation with _1 Million_! /48s would
be anything but a slow start but I also realize your and my experience
mileage will vary. I also have no issue admitting I might be wrong given my
experience does not encompass all possible experiences. This is why I am
thankful for this community to guide us all toward the truth.

Based on Tyler's answers to my question I agree a /20 is perfectly
reasonable and I support this proposal.

I apologize if I stepped on any toes in coming to this decision.

Respectfully,

Michael Greenup

Network Engineer
Wide Area Network

IONOS Inc. | 10950 Strang Line Road | KS 66215 Lenexa | USA
Phone: +1 913 660 7664 | Mobile: +1 484 557 1331
E-Mail: michael.greenup at ionos.com

Member of United Internet

Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen
enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese
E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und
vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten
ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt
auf welche Weise auch immer zu verwenden.

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient of this e-mail, you are hereby notified that
saving, distribution or use of the content of this e-mail in any way is
prohibited. If you have received this e-mail in error, please notify the
sender and delete the e-mail.

On Fri, Jun 28, 2024 at 12:18 PM David Farmer <farmer at umn.edu> wrote:

> This is not IPv4; please stop the IPv4 thinking. We don't need an IPv6
> version of slow start, where you get only a /32 and justify more only by
> immediate need or growth over time. At the same time, we can't ignore the
> conservation of IPv6 address space. However, the conservation of routing
> slots through route aggregation and overall operational simplicity are much
> more important issues for IPv6.
>
> For IPv6, there is enough address space that most organizations should get
> an initial allocation large enough to cover 5 to 10 years of normal linear
> growth. Organizations that grow exponentially, which can rarely occur, will
> need to return sooner. Other organizations may never have to return, which
> is fine, too.
>
> Thanks
>
> On Fri, Jun 28, 2024 at 11:53 AM Michael Greenup <
> michael.greenup at ionos.com> wrote:
>
>> Greetings to the List!
>>
>> Thank you Tyler for your clarifications, though I am curious why /20 was
>> chosen and not /24 (16 million /48s) or even /28 (1 million /48s).
>>
>> I wonder if stating an initial maximum allocation is really necessary.
>> The minimum allocation is a /32 (64 thousand /48s) according to 6.5.2.1(b)
>> and it could easily be changed to be the initial allocation for every
>> initial request unless a smaller allocation is requested as provided by the
>> rules in the same section. I wonder if it would not be better to completely
>> remove the maximum allocation language as there are already mechanisms in
>> place to request subsequent needs-based IPv6 allocations within the NRPM. I
>> also see nothing in the NRPM which would prevent an initial allocation
>> request of two /32s which would also prevent the potential over-allocation
>> of a /28 (128K /48s versus 1M /48s). I realize this would affect the
>> routing table and possibly reduce aggregation but perhaps there is a "happy
>> medium" in here somewhere.
>>
>> I would submit for consideration the policy should instead be something
>> similar to allowing an initial allocation of a /32 up to a /28 without a
>> requirement for needs-based documentation. This would provide fewer hoops
>> for requesters to jump through and the concerns of an over-allocation are
>> mitigated while making the policy almost ridiculously easy to understand
>> and implement. If more IPv6 allocations are necessary, they are no longer
>> considered an initial request and are covered by the procedures stated
>> within other subsequent sections of the NRPM.
>>
>> Also, while the ensuing debate has been interesting reading, it seems the
>> debate is focused more on whether the needs-based criteria is being
>> correctly implemented by ARIN staff as there is clearly a single /16 which
>> has been allocated at some point in the past and therefore it seemingly
>> means the needs-based decision must not have been properly decided. As this
>> is a closed process, I do not know if anybody will be able to answer this
>> question and we will have to decide if we as a community will have faith
>> and trust in the efforts of ARIN employees to determine whether or not the
>> need for a larger IPv6 allocation actually exists.
>>
>> Perhaps what the debate is really showing us is a need to focus more on
>> the defined needs-based methodology and fine tune it based on our current
>> knowledge of IPv6 networking instead of attempting to find perceived
>> loopholes in the policy in an attempt to justify a hypothetical larger
>> allocation under this section.
>>
>> Respectfully,
>>
>> Michael Greenup
>>
>> Network Engineer
>> Wide Area Network
>>
>> IONOS Inc. | 10950 Strang Line Road | KS 66215 Lenexa | USA
>> Phone: +1 913 660 7664 | Mobile: +1 484 557 1331
>> E-Mail: michael.greenup at ionos.com
>>
>> Member of United Internet
>>
>> Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte
>> Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind
>> oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den
>> Absender und vernichten Sie diese E-Mail. Anderen als dem
>> bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern,
>> weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden.
>>
>> This e-mail may contain confidential and/or privileged information. If
>> you are not the intended recipient of this e-mail, you are hereby notified
>> that saving, distribution or use of the content of this e-mail in any way
>> is prohibited. If you have received this e-mail in error, please notify the
>> sender and delete the e-mail.
>>
>>
>> On Thu, Jun 27, 2024 at 11:00 PM Tyler O'Meara via ARIN-PPML <
>> arin-ppml at arin.net> wrote:
>>
>>> Hi all,
>>>
>>> As the author of this policy I just wanted to chime in with a few
>>> responses:
>>>
>>> First, as has been mentioned before, this change only applies to the
>>> amount of
>>> space that may be given in a single allocation. If an organization is
>>> using its
>>> IPv6 space efficiently (as defined later in Section 6), they're more than
>>> welcome to get more allocations. I will note that the standard to obtain
>>> these
>>> subsequent blocks is considerably higher than to get the first block. It
>>> is
>>> easily conceivable that an organization that would qualify for a /16
>>> under
>>> today's NRPM could not even meet the utilization requirements for a /20
>>> in order
>>> to get a second /20, let alone a /16.
>>>
>>> When it comes to smallish blocks, the desire to enable aggregation and
>>> smaller
>>> routing tables outweighs concerns about address conservation. However, I
>>> believe
>>> that once we're talking about blocks larger than a /20, conservation
>>> concerns
>>> outweigh routing table concerns.
>>>
>>> Second, it's been mentioned that it is not believed that many
>>> organizations
>>> could qualify for a /16 block. It is very difficult to come up with a
>>> good
>>> metric to determine the size of an organization, but I think an
>>> organization's
>>> v4 allocations are probably a reasonable proxy for this use case.
>>>
>>> The organization that received the /16 block has v4 allocations totaling
>>> 50
>>> /24s[1]. Under the current ARIN fee schedule, this would make them a
>>> "Small"
>>> organization. According to the presentation made by Nancy Carter at ARIN
>>> 53[2],
>>> there are currently (as of April 2024) 1,864 Small ARIN organizations,
>>> and a
>>> further 1,559 ARIN organization larger than Small. Given the context of
>>> the
>>> numbers, I believe this is only counting RSA members and *not* LRSA
>>> members, so
>>> the actual number of ARIN orgs of this size is likely substantially
>>> higher.
>>>
>>> Given that the number of organizations which could reasonably request a
>>> /16 is
>>> on the same order of magnitude as the number of IANA-allocatable /16s, I
>>> personally belive the current policy is too liberal in giving out
>>> massively
>>> sized IPv6 allocations.
>>>
>>> Tyler
>>>
>>>
>>> [1] https://bgp.tools/rir-owner/ARIN-CAPITA-120
>>> [2]
>>>
>>> https://www.arin.net/participate/meetings/ARIN53/materials/monday/arin53_treasurer.pdf
>>>
>>> On Thu, 2024-06-27 at 18:17 -0500, David Farmer via ARIN-PPML wrote:
>>> >
>>> >
>>> > On Thu, Jun 27, 2024 at 5:04 PM William Herrin <bill at herrin.us> wrote:
>>> > > On Thu, Jun 27, 2024 at 2:46 PM David Farmer <farmer at umn.edu> wrote:
>>> > > >   As I said, the current policy seems to be functioning as
>>> intended.
>>> > >
>>> > > Hi David,
>>> > >
>>> > > I can't prove a negative, so let me turn the question around on you:
>>> > > we know a /16 has been allocated. We can't know how they justified it
>>> > > because that information is private. Can you produce a -notional-
>>> > > justification for a /16 that we all agree is -reasonable-? If you
>>> > > cannot, then what purpose is served by allowing such consumptive
>>> > > registrations?
>>> > >
>>> >
>>> >
>>> > The current policy has been in effect since ARIN-2011-3 was
>>> implemented in
>>> > January 2012. One /16 allocated in over a decade doesn't represent a
>>> problem.
>>> > Instead, it indicates a successful policy that balances the need for
>>> > justification with the ability to provide substantial allocations. The
>>> data
>>> > provided in the proposal doesn't demonstrate a problem. If we see a
>>> rash of
>>> > /16 allocations, I might change my mind, but until then, I don't
>>> support a
>>> > change at this time.
>>> >
>>> > 1 16
>>> > 8 20
>>> > 22 22
>>> > 39 24
>>> >
>>> > Thanks.
>>> >
>>> > --
>>> > ===============================================
>>> > David Farmer               Email:farmer at umn.edu
>>> > Networking & Telecommunication Services
>>> > Office of Information Technology
>>> > University of Minnesota
>>> > 2218 University Ave SE        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.
>>>
>>> _______________________________________________
>>> 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        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20240628/fa536e5c/attachment-0001.htm>