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:remco.vanmook@gmail.com > To: "RIPE Address Policy Working Group"< mailto:address-policy-wg@ripe.net > Cc: "Angela Dall'Ara"< mailto:adallara@ripe.net > 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:adallara@ripe.net > 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:address-policy-wg@ripe.net 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/

Remco van Mook wrote on 25/08/2026 16:07:

Implementation cost:

Software, processes, documentation and training/exam material would need to be changed.

It's valid to raise implementation costs. In the RIPE community, we're within our rights to demand things in policy proposals, including unicorns, but the NCC is charged with execution and the NCC Board is charged with governance. Part of their jobs is to raise concerns if they feel that there are policy proposal issues that are problematic from their point of view, and that includes fiscal management. If they didn't do this, they wouldn't be doing the jobs we asked them to do.

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. There's a good deal of member scrutiny about RIPE NCC expenditure at the moment. You may not have meant to do this, but this is putting the board in a damned-if-you-do, damned-if-you-don't situation (but see next para below).

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.

There was apparently an update to the board provided by Mirjam on June 22:

https://www.ripe.net/about-us/executive-board/minutes/executive-board-minute...

I read their comment as: "we support the analysis of the NCC, for the reasons provided by the NCC", which is ok as a response from the board if that's what it was. Maybe someone from the board could confirm if this reading was wrong. Ignoring the other two substantial points (which I agree with):

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.

This is a fairly fundamental problem with the policy, which changes the terms of an address assignment from "may not be sub-assigned", to "it's ok for small amounts".

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.

This kinda gets into the meat of it, and I'm struggling with two things here: 1. this policy substantially changes the meaning of an IP number resource assignment from end-user-only to end-user-mostly. That might or might not be a reasonable thing to do, but it doesn't belong in a housekeeping policy like 2024-01. If it's the intention of the authors to change the semantics of this term, then this is a substantial policy change which needs to be handled as a standalone proposal. 2. If there's an appetite for changing the meaning of an "assignment" for ipv6, then something comparable needs to be applied to ipv4 assignments. Nick

Hi, Enforcement was never the point of registering assignments, and shouldn’t be seen as the driver. Assignments are registered because the data is needed and used for a variety of reasons such as uniqueness, reaching specific network operators, etc. It’s also the only public record of who operates PA space when it isn’t the holding LIR. Needs-based justification may not be in play today but the other reasons certainly are. Best, James From: Max Emig <ripe@emigm.ax> To: <address-policy-wg@ripe.net> Date: Mon, 31 Aug 2026 15:18:21 +0100 Subject: [address-policy-wg] Re: 2024-01 Review Phase (Revised IPv6 PI Assignment Policy)

Hi,

not really because in practice virtually no enforcement takes place, no needs-based justification anymore except for IXP, no new IPv4 PI from the RIPE NCC.

Thanks

Max

On 31.08.26 16:03, Nick Hilliard wrote:

...

2. If there's an appetite for changing the meaning of an "assignment" for ipv6, then something comparable needs to be applied to ipv4 assignments.

---

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/