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

Fri Jun 28 13:17:53 EDT 2024

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/4d8d2a2b/attachment-0001.htm>