Hello,
Thank you to the RIPE NCC for a thorough impact analysis, and thanks again to
the authors for their work.
I do not support the proposal in its current form. My reasons below, along with
a suggested amendment.
1. The renumbering mechanism punishes IPv6 growth
This is the concern I raised in Edinburgh, and the IA confirms: considering
current reservations, a request for additional PI space “will require
renumbering in almost all cases” and “might be highly impactful and
time-consuming for network operators”. Basic maths make this inevitable - the
RIPE NCC usually reserves 2 bits of headroom around a PI assignment (e.g. /46
for a /48), while nibble boundaries require 4. A holder whose IPv6 operations
are growing is a success story that we want more of. Policy should make genuine
IPv6 growth requests frictionless, not disruptive.
Please keep in mind in all this that PI is the affordable route to provider
independence for smaller organisations and operators in lower-income economies
across our service region. These holders are least equipped to absorb a forced
renumbering exercise.
2. The mandatory return fails its own purpose
If I understood correctly, the purpose of the proposed return obligation is to
prevent transfers of the previous assignment. But the new assignment could be
transferred, immediately. Also as per the IA, newly assigned blocks are
expected to be partially transferred. That fragments each new block, and once
pieces sit under different holders it can no longer grow into its reserved
space. And the obligation deters the wrong party. Stockpiled space carries
little or no live network, so renumbering costs its holder next to nothing.
They trade their old block for a larger, immediately transferable one and come
out with a win. The holders it actually punishes are operators running real
networks on the space.
3. Suggestion to amend 7.1.2
Replace the final sentence of 7.1.2 with:
“If the requested extension to the next nibble boundary cannot be made, the
assignment holder may request a new Assignment as per ‘7.1.1. PI Assignment at
the Nibble Boundary’. Return of the previous assignment(s) is voluntary.
Retained previous assignment(s) are excluded from transfer under the transfer
policy until they are returned to the RIPE NCC or consolidated into the new
assignment.”
This addresses both problems above. It removes the forced renumbering penalty
on growing operators, and it achieves the anti-stockpiling objective directly:
a retained block can be held but not sold. Changes of holder through M&As are
unaffected, as these fall outside the transfer policy. It also removes the
six-month enforcement problem, e.g. the IA notes the consequences of incomplete
renumbering within six months are unclear.
4. Proportionality
The Charging Scheme Task Force 2024 report noted there are “relatively few IPv6
PI assignments”. The IA adds that there is “a negligible number of requests for
additional IPv6 PI space”, that no significant long-term workload reduction is
expected, and that this policy itself would increase short-term ticket volume.
So the operational burden this proposal sets out to reduce for holders and the
RIPE NCC is small, while the renumbering burden it introduces falls on almost
every holder who grows, and adds work for the RIPE NCC to chase the return of
previous assignments.
If actual evidence of IPv6 PI stockpiling emerges in future, I would suggest
the transfer policy is the proportionate instrument to address it.
5. Scope - PI only, or also PA?
The proposal’s title, summary, and motivation address PI. The operative text of
2.6, however, changes the definition of “assign” for every IPv6 assignment in
the region, including assignments from PA allocations. The IA’s legal analysis
confirms the consequences: connecting remote End Sites of separate entities
from assigned space would become prohibited unless dynamic routing is used, and
potentially large volumes of existing assignments across the RIPE region (and
beyond) would become non-compliant. Yet the rationale says nothing about these
PA assignments and holders. The authors should either scope 2.6 explicitly to
PI, or argue openly for changing the rules for all IPv6 assignments, clarifying
what becomes non-compliant and what holders are expected to do about it. The
End Site definition was rightly decoupled from this proposal. The scope of 2.6
might require similar.
The IA also flags a contradiction within the proposal. Its own 2.6 says
assignments are made for specific, documented purposes. The proposed nibble
mechanism would assign more than the documented need - e.g. justify two /48s,
receive sixteen - and the surplus has no documented purpose at all. That is how
allocations work, not assignments. And Remco’s third point, the clash between
the new 2.6 and the untouched section 7 text, is real but just drafting. The
authors should fix that either way.
In short, the case for changing the rules for all IPv6 assignments has not yet
been made, let alone addressed.
6. Way forward
For clarity, I’m not against everything here. A clearer separation of PI rules
from PA assignment rules is useful, and so is clarifying what PI can and cannot
be used for. But the nibble boundary and mandatory return mechanism is not
workable in its current form, and that’s the core of the proposal. Splitting
off the useful parts, as already done with the End Site definition, may be the
best way forward.
Best,
James Kennedy,
KIPA.global
From: Remco van Mook < mailto:[email protected] >
To: "RIPE Address Policy Working Group"< mailto:[email protected] >
Cc: "Angela Dall'Ara"< mailto:[email protected] >
Date: Tue, 25 Aug 2026 16:07:43 +0100
Subject: [address-policy-wg] Re: 2024-01 Review Phase (Revised IPv6 PI
Assignment Policy)
Dear colleagues,
I very much support the direction of the proposal, and I would like to thank
Tobias and Clara for their persistence.
Reading the impact analysis, it strikes me that there are two different
categories of concern raised by the NCC:
Implementation cost:
Software, processes, documentation and training/exam material would need to be
changed. If "We would have to change things and that costs money" becomes a
sufficient argument against a proposed policy change we might as well stop
doing them. Nothing in this line of reasoning tells me anything about the
substance of the proposal, and the merits of it.
I am also somewhat disappointed that the Executive board thought it fitting to
advise revision in a single sentence without any stated reasoning - and I'm not
going to dig through the board minutes to find the reasoning, if it exists. I
would very much like to hear the board's reasoning; both for the comment itself
and the way they decided to present it.
Actual substance:
There are I think 3 findings that this proposal will need to address before we
can proceed.
1 - Transition mathematics. Existing /48 assignments sit in /46 reservations.
The entire installed base is therefore impossible to extend in place to 'the
next nibble' or a /44. With that, grow in place becomes a mandatory
renumber-and-return exercise for everyone who wants additional space.
2 - The transfer gap. The return obligation only applies to the previous
assignment - the new block can immediately be (partly) transferred. This
creates the exact fragmentation this proposal seeks to avoid.
3 - Internal consistency. Proposed 2.6 permits conditional sub-assignment and
the untouched text of article 7 still states that PI cannot be further
sub-assigned, and the interaction with 7.2 would put an End User who later
becomes a member/LIR themselves in automatic violation.
On the NCC's enforcement dilemma: this is the permanent shape of every
needs-based policy we've ever had, going back all the way to the original IPv4
policy. The same goes for the ambiguity of the term 'end site': I see that that
will become a policy proposal in its own right and I'm very much looking
forward to reading it - it is overdue by decades, in my opinion.
Neither of these problems is introduced by this proposal, and I don't see why
these arguments should be used as an implementation blocker.
To summarise: I support the intent, but we should find language that addresses
my points above. Those are the actual substance, not the training courses.
Kind regards
Remco
> On 25 Aug 2026, at 14:56, Angela Dall'Ara < mailto:[email protected] > wrote:
>
>
>
> Dear colleagues,
>
>
>
> Policy proposal 2024-01, "Revised IPv6 PI Assignment Policy", is now in the
> Review Phase.
>
>
>
> The RIPE NCC has prepared an impact analysis on this proposal to support the
> community’s discussion.
>
>
>
> You can find the proposal and impact analysis at:
>
> https://www.ripe.net/community/policies/proposals/2024-01/
> https://www.ripe.net/community/policies/proposals/2024-01/#impact-analysis
> And the draft document at:
>
> https://www.ripe.net/community/policies/proposals/2024-01/draft/
>
>
> As per the RIPE Policy Development Process (PDP), the purpose of this
> four-week Review Phase is to continue the discussion of the proposal taking
> the impact analysis into consideration, and to review the full draft RIPE
> Policy Document.
>
>
>
> At the end of the Review Phase, the Working Group (WG) Chairs will determine
> whether the WG has reached rough consensus.
>
>
> It is therefore important to provide your opinion, even if it is simply a
> restatement of your input from the previous phase.
>
>
>
> We encourage you to read the proposal, impact analysis and draft document and
> to send any comments to mailto:[email protected] before 23
> September 2026.
>
>
> Kind regards,
> Angela Dall'Ara
> Policy Officer
> RIPE NCC
> -----
> To unsubscribe from this mailing list or change your subscription options,
> please visit:
> https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/
> As we have migrated to Mailman 3, you will need to create an account with the
> email matching your subscription before you can change your settings. More
> details at: https://www.ripe.net/membership/mail/mailman-3-migration/
-----
To unsubscribe from this mailing list or change your subscription options,
please visit:
https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the
email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
-----
To unsubscribe from this mailing list or change your subscription options,
please visit:
https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the
email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
