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