<div dir="ltr"><div class="gmail_default" style="font-family:monospace">Greetings to the list!</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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. <br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Based on Tyler's answers to my question I agree a /20 is perfectly reasonable and I support this proposal.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I apologize if I stepped on any toes in coming to this decision.<br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Respectfully,</div><div class="gmail_default" style="font-family:monospace"><br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><font face="monospace">Michael Greenup</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">Network Engineer</font></div><div><font face="monospace">Wide Area Network</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">IONOS Inc. | 10950 Strang Line Road | KS 66215 Lenexa | USA</font></div><div><font face="monospace">Phone: +1 913 660 7664 | Mobile: +1 484 557 1331</font></div><div><font face="monospace">E-Mail: <a href="mailto:michael.greenup@ionos.com" target="_blank">michael.greenup@ionos.com</a></font></div><div><font face="monospace"><br></font></div><div><font face="monospace">Member of United Internet</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">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.</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">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.</font></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 28, 2024 at 12:18 PM David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Thanks</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 28, 2024 at 11:53 AM Michael Greenup <<a href="mailto:michael.greenup@ionos.com" target="_blank">michael.greenup@ionos.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:monospace">Greetings to the List!</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">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). <br></div><div style="font-family:monospace"><br></div><div style="font-family:monospace">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. </div><div style="font-family:monospace"><br></div><div style="font-family:monospace">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.<br></div><div style="font-family:monospace"><br></div><div style="font-family:monospace">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. <br></div><div style="font-family:monospace"><br></div><div style="font-family:monospace">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.</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">Respectfully,</div><div style="font-family:monospace"><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><font face="monospace">Michael Greenup</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">Network Engineer</font></div><div><font face="monospace">Wide Area Network</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">IONOS Inc. | 10950 Strang Line Road | KS 66215 Lenexa | USA</font></div><div><font face="monospace">Phone: +1 913 660 7664 | Mobile: +1 484 557 1331</font></div><div><font face="monospace">E-Mail: <a href="mailto:michael.greenup@ionos.com" target="_blank">michael.greenup@ionos.com</a></font></div><div><font face="monospace"><br></font></div><div><font face="monospace">Member of United Internet</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">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.</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">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.</font></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 27, 2024 at 11:00 PM Tyler O'Meara via ARIN-PPML <<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
As the author of this policy I just wanted to chime in with a few responses:<br>
<br>
First, as has been mentioned before, this change only applies to the amount of<br>
space that may be given in a single allocation. If an organization is using its<br>
IPv6 space efficiently (as defined later in Section 6), they're more than<br>
welcome to get more allocations. I will note that the standard to obtain these<br>
subsequent blocks is considerably higher than to get the first block. It is<br>
easily conceivable that an organization that would qualify for a /16 under<br>
today's NRPM could not even meet the utilization requirements for a /20 in order<br>
to get a second /20, let alone a /16.<br>
<br>
When it comes to smallish blocks, the desire to enable aggregation and smaller<br>
routing tables outweighs concerns about address conservation. However, I believe<br>
that once we're talking about blocks larger than a /20, conservation concerns<br>
outweigh routing table concerns.<br>
<br>
Second, it's been mentioned that it is not believed that many organizations<br>
could qualify for a /16 block. It is very difficult to come up with a good<br>
metric to determine the size of an organization, but I think an organization's<br>
v4 allocations are probably a reasonable proxy for this use case. <br>
<br>
The organization that received the /16 block has v4 allocations totaling 50<br>
/24s[1]. Under the current ARIN fee schedule, this would make them a "Small"<br>
organization. According to the presentation made by Nancy Carter at ARIN 53[2],<br>
there are currently (as of April 2024) 1,864 Small ARIN organizations, and a<br>
further 1,559 ARIN organization larger than Small. Given the context of the<br>
numbers, I believe this is only counting RSA members and *not* LRSA members, so<br>
the actual number of ARIN orgs of this size is likely substantially higher.<br>
<br>
Given that the number of organizations which could reasonably request a /16 is<br>
on the same order of magnitude as the number of IANA-allocatable /16s, I<br>
personally belive the current policy is too liberal in giving out massively<br>
sized IPv6 allocations.<br>
<br>
Tyler<br>
<br>
<br>
[1] <a href="https://bgp.tools/rir-owner/ARIN-CAPITA-120" rel="noreferrer" target="_blank">https://bgp.tools/rir-owner/ARIN-CAPITA-120</a><br>
[2]<br>
<a href="https://www.arin.net/participate/meetings/ARIN53/materials/monday/arin53_treasurer.pdf" rel="noreferrer" target="_blank">https://www.arin.net/participate/meetings/ARIN53/materials/monday/arin53_treasurer.pdf</a><br>
<br>
On Thu, 2024-06-27 at 18:17 -0500, David Farmer via ARIN-PPML wrote:<br>
> <br>
> <br>
> On Thu, Jun 27, 2024 at 5:04 PM William Herrin <<a href="mailto:bill@herrin.us" target="_blank">bill@herrin.us</a>> wrote:<br>
> > On Thu, Jun 27, 2024 at 2:46 PM David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:<br>
> > > As I said, the current policy seems to be functioning as intended.<br>
> > <br>
> > Hi David,<br>
> > <br>
> > I can't prove a negative, so let me turn the question around on you:<br>
> > we know a /16 has been allocated. We can't know how they justified it<br>
> > because that information is private. Can you produce a -notional-<br>
> > justification for a /16 that we all agree is -reasonable-? If you<br>
> > cannot, then what purpose is served by allowing such consumptive<br>
> > registrations?<br>
> > <br>
> <br>
> <br>
> The current policy has been in effect since ARIN-2011-3 was implemented in<br>
> January 2012. One /16 allocated in over a decade doesn't represent a problem.<br>
> Instead, it indicates a successful policy that balances the need for<br>
> justification with the ability to provide substantial allocations. The data<br>
> provided in the proposal doesn't demonstrate a problem. If we see a rash of<br>
> /16 allocations, I might change my mind, but until then, I don't support a<br>
> change at this time.<br>
> <br>
> 1 16<br>
> 8 20<br>
> 22 22<br>
> 39 24<br>
> <br>
> Thanks.<br>
> <br>
> -- <br>
> ===============================================<br>
> David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>
> Networking & Telecommunication Services<br>
> Office of Information Technology<br>
> University of Minnesota <br>
> 2218 University Ave SE Phone: 612-626-0815<br>
> Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>
> =============================================== <br>
> _______________________________________________<br>
> ARIN-PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
<br>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>=============================================== </div></div>
</blockquote></div>