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

Fri Jun 28 12:53:29 EDT 2024

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20240628/0bedf754/attachment.htm>