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: Receive a new prefix with the new requested size and renumber their network and return the "original" initial allocation within 6 months, or 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 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. The new assignment will be consistent with the new plan and comply with 6.8.2 and 6.8.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: 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; 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 >> 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. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com 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 Please contact [email protected] if you experience any issues.
