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.gree...@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 <far...@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.gree...@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.gree...@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@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 <b...@herrin.us> wrote: >>> > > On Thu, Jun 27, 2024 at 2:46 PM David Farmer <far...@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:far...@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@arin.net). >>> > Unsubscribe or manage your mailing list subscription at: >>> > https://lists.arin.net/mailman/listinfo/arin-ppml >>> > Please contact i...@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@arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> https://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact i...@arin.net if you experience any issues. >>> >> > > -- > =============================================== > David Farmer Email:far...@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@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.