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

[Tyler O'Meara]

Hi Michael,

I selected a /20 because I think that is the "happy medium" you refer to; it's
large enough that the vast vast majority of LIRs should fit in it (so that
ideally LIRs only need a single allocation, helping both the routing table and
not needing to inundate ARIN with tickets), while being small enough that, so
long as reasonable impediments to obtaining one exist, it should be sustainable
for the very long term.

I personally don't think this debate is about whether ARIN staff did their job
correctly. I at least have full confidence that the /16 request was handled in
full complaince with the NRPM, and if I didn't have that confidence then fixing
the NRPM wouldn't be a solution. I do not belive that one even needs a loophole
to obtain a /16; although Bill's suggestion is rather amusing. Per 6.5.2.1, if
an organization has a single serving site with 49,152 customers and 49,152
serving sites each with 3 customers, and they give all customers a /48 (a
reasonable choice, and one which many ISPs follow), then that LIR can justify a
/16 (/16 = 48 - (log2(4/3*49152)) + log2(4/3*49152)).

In general, 6.5.2.1 is quite wasteful of IPv6 space. However, this is in line
with the IPv6 policies specified in 6.3; given that we have an astronimcal
amount of IPv6 space, we should prefer to minimize overhead (6.3.7) and
aggregation (6.3.4) over conservation (6.3.5). As stated in the problem
statement, I am of the belief that once we get above a /20, we're talking about
such huge portions of IPv6 space that we can no longer afford to be so wasteful.

On Fri, 2024-06-28 at 11:53 -0500, Michael Greenup 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.