[arin-ppml] IPv6 policy: subsequent allocations?

[Daryll Swer]

>
> 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 <
arin-ppml at arin.net> 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 <chris at woodfield.tech>
> 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 <bill at herrin.us> 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 (ARIN-PPML at arin.net).
> 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 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
> <https://l.shortlink.es/l/1638280d33c94f8c9ee3616e59c7f7d2c38d21eb?u=2153471>
> Please contact info at arin.net 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 (ARIN-PPML at arin.net).
> 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 info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20260723/a2417a62/attachment-0001.htm>