> > Rightly or wrongly, the org expects they won’t qualify for a subsequent > allocation under 6.5.3, so they break best practices to make do with that > initial block. Or worse, they abandon the effort entirely.
+1 This is a very common problem, specially in regions where IPv6 has been > provided for free if you already have IPv4. Most of the LIRs or end-users > just request for the default, because they don’t do a previous addressing > plan. When they actually start the deployment, they realize they made a > mistake. > Agreed. I don't know why people dislike learning IPv6 subnetting as much as they learnt IPv4 in school/college, but this is the operational reality of IPv6 today. I've seen this across segments (enterprise, SP and DC), and many orgs think a /48 is a massive initial allocation until they start learning what IPv6 actually is. So, I feel like it would be reasonable for policy to allow for an > organization to have a “redo” of their initial allocation request. One > condition that may make sense is that this be on a request-then-return > basis, although that might be moot if original sparse allocation is still > sparse enough. Also agreed. Assuming I can get a /28 anytime I want via sparse allocation if my initial allocation prefix is between /29 and /48, I'd think the sparse allocation is sufficient. I'm handing out /48s (static/persistent/never changing unless the network ownership itself changed hands and had drastic re-architecture) to everyone in residential and enterprise as a default in ARIN land for some networks in the US and /60 on campuses via IA_PD to endpoints for 802.11 and wired Ethernet. /28s significantly simplify subnetting while allowing clean internal aggregation to keep routing tables small. No flooding of prefixes longer than a /48. *--* Best Regards Daryll Swer Website: daryllswer.com <https://l.shortlink.es/l/9eff358f193656f566483d7db407b1fd19acc97a?u=2153471> On Sat, 27 Jun 2026 at 14:36, jordi.palet--- via ARIN-PPML < [email protected]> wrote: > This is a very common problem, specially in regions where IPv6 has been > provided for free if you already have IPv4. Most of the LIRs or end-users > just request for the default, because they don’t do a previous addressing > plan. When they actually start the deployment, they realize they made a > mistake. > > Towards that, I’ve done policy proposals that achieved consensus in a > couple of RIRs, with the following text: > > > For IPv6 PA (ISPs/LIRS): > > *Rectifying the size of initial allocations* > > During IPv6 deployment, if an organization finds that the size of the > initial allocation it requested no longer satisfies its needs, the > organization may submit a new addressing plan to AFRINIC, without having to > wait until it can fulfil the requirements for a subsequent allocation, and > therefore the organization will not have to prove utilization thresholds, > but, instead of the desire to apply a different addressing plan that is > better suited to the reality of the deployment. > > The new size will be adjusted according to the new addressing plan as > specified in section 6.5.1.2., and will thus qualify for extending the > current prefix the necessary number of bits. > > In case is not possible to provide this prefix length because the adjacent > space is already being used by another organization, or if making the > allocation would not leave sufficient space for subsequent allocations, > AFRINIC will inform the applicant, who may choose to: > > 1. Receive a new prefix with the new requested size and renumber their > network and return the "original" initial allocation within 6 months, or > 2. Receive a complementary prefix to complete their addressing plan, > and announce both, the "original" initial prefix and the new prefix > resulting from the new allocation. For all intents and purposes, in the > case of subsequent allocations, both allocations shall be considered as if > they were a single allocation. > > Each organization may only use this procedure once, so for this "second > opportunity", they should carefully study the final medium and long-term > network addressing plans. > > and for the IPv6 PI (end-users) > > *Rectifying the size of an initial assignment* > > 1. An organization may submit a new addressing plan to AFRINIC if the > plan initially submitted to justify the initial assignment no longer > satisfies their current needs. > 2. The new assignment will be consistent with the new plan and comply > with 6.8.2 and 6.8.3. > 3. If possible, the same address block will be “upgraded” to the new > required prefix size. However, if the adjacent prefixes are already being > used by other organizations or if such assignment would not leave > sufficient space for subsequent assignments, AFRINIC will inform to the > requesting organization, which will have the following options: > 1. Receive a new block with the new requested prefix size, with the > agreement to utilize the new block for all future deployment and > deprecate > the old block through attrition, returning when empty. There is no > deadline > for return at this time; > 2. Receive a new block which, together with the block that has > already been assigned, covers the new justified need, and keep both > blocks. > This procedure can only be used once by each organization. > > > If folks believe this is useful here, I’m happy to submit the text in a > way that it is appropriate for ARIN NRPM. > > Regards, > Jordi > > @jordipalet > > El 27 jun 2026, a las 5:05, Chris Woodfield <[email protected]> > escribió: > > Speaking from personal experience, I’ve seen situations like this: > > 1. An organization knows they’ll need to adopt IPv6 eventually, and goes > ahead and requests/receives a block without much thought to their > allocation plan (/32 should be enough for anyone, right?) > > 2. Some time later, the org moves forward and starts building an address > plan, and in the process realizes that given best practices (/48 minimum to > end sites, aggregation on nibble boundaries, etc) that a /32 isn’t enough > space for them. > > 3. Rightly or wrongly, the org expects they won’t qualify for a subsequent > allocation under 6.5.3, so they break best practices to make do with that > initial block. Or worse, they abandon the effort entirely. > > So, I feel like it would be reasonable for policy to allow for an > organization to have a “redo” of their initial allocation request. One > condition that may make sense is that this be on a request-then-return > basis, although that might be moot if original sparse allocation is still > sparse enough. > > -C > > On Jun 25, 2026, at 15:16, William Herrin <[email protected]> wrote: > > Howdy, > > I didn't see any feedback on the draft policy rewriting section 6.5, > so I want to step back and solicit your opinions on what ARIN's IPv6 > policies should become. I'm going to ask some questions and break them > into separate message threads so that they can be followed separately > according to your interest. > > > The question for this thread is: How should ARIN handle second and > subsequent allocations of IPv6 addresses? > > Current policy says that your IPv6 addresses have to be employed and > in use according to somewhat complicated definitions of in-use in > order to qualify for additional addresses. ARIN will then try to > expand your netmask. If they can't because someone else's allocation > is in the way, they'll allocate a new, larger block and ask (but not > require) you to renumber out of the old one. > > This approach has a couple of odd artifacts. The amount of addresses > you're qualified for under the subsequent allocation criteria aren't > exactly the same as what you qualified for under the initial > allocation criteria. > > A different approach could be to have a single rule set to determine > how many addresses you're qualified for. If you want more addresses, > you apply the same rules you did originally to the current conditions > on your network. This would avoid inconsistencies but it would also > get rid of the "prove you're using IPv6 addresses efficiently" > requirement. > > Given that IPv6 addresses are plentiful and if we don't do anything > too silly they'll remain plentiful well into the foreseeable future, > do we need registrants to prove efficient use before resizing their > address allocation? That's a lot of paperwork for the registrant to > prepare and the analyst to examine, all of it blocking whatever > improvement the registrant wants to make to their IPv6 network. We > need it for IPv4 because folks have a financial motive to lie, but is > that true of IPv6? > > Anyway, what do you think? Continue to treat initial and subsequent > IPv6 allocations differently? Try to merge their criteria into > something more uniform? Your views are respectfully requested. > > Regards, > Bill Herrin > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > <https://l.shortlink.es/l/ee9e4e88e9e0a9a26ac31d0bfda82b88318718c3?u=2153471> > Please contact [email protected] if you experience any issues. > > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > <https://l.shortlink.es/l/1638280d33c94f8c9ee3616e59c7f7d2c38d21eb?u=2153471> > Please contact [email protected] if you experience any issues. > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > <https://l.shortlink.es/l/17e8607326ed697a6cf1b05756c2f8f385053a76?u=2153471> > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > <https://l.shortlink.es/l/89262af2ed4011eab1ba40dfa4a958d8b95b32d2?u=2153471> > Please contact [email protected] if you experience any issues. >
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
