RIPE 92 Policy Proposals — Summary
May 11, 2026
RIPE NCC’s 92nd Regional Meeting runs from 18-22 May 2026 in Edinburgh, Scotland, with the Address Policy Working Group set to discuss two active policy proposals during the second Address Policy session on Thursday, 21 May. This round is narrower than some recent policy agendas, but it still touches two important areas for operators and address strategy teams: IPv6 PI assignment rules and ASN assignment criteria.
Neither proposal looks like a direct market shock. There is no sweeping transfer-policy rewrite, no immediate change to IPv4 trading mechanics, and no obvious disruption to address availability. But both proposals matter because they sit in the operational layer where policy language becomes request friction. For clients, the question is whether these proposals make future requests easier to predict, easier to justify, or more likely to trigger debate.
2024-01: Revised IPv6 PI Assignment Policy
Proposal 2024-01, Revised IPv6 PI Assignment Policy, was introduced to the RIPE community on 13 August 2024 and has now been presented multiple times without reaching consensus. The goal is straightforward enough: reduce the operational cost of IPv6 Provider Independent assignment requests by addressing ambiguity in the current policy text.
Ambiguous assignment guidance creates real costs for applicants, sponsoring LIRs, and the RIPE NCC. When organizations cannot easily tell what justification will be accepted, they over-prepare, under-prepare, or spend unnecessary time going back and forth during the request process. Clearer IPv6 PI rules would be useful, especially for smaller organizations and enterprises that do not live inside RIPE policy every day.
The common sentiment is that this proposal appears to be doing too much at once. Recurring feedback from the Address Policy Working Group Mailing List and from address policy session attendees say that the proposal contains multiple policy changes bundled together, making consensus harder. Even participants who agree that the current IPv6 PI assignment policy could be improved may object to the scope, structure, or complexity of the rewrite.
For clients, the practical takeaway is that 2024-01 is worth watching, but not yet something to plan around as a settled change. The community sentiment seems clear: simplify the work, separate the issues, and avoid making IPv6 policy harder to apply in the name of making it clearer. If the proposal is broken into smaller pieces, some parts may eventually have a better chance of moving forward. In its current form, continued pushback should not be surprising.
2025-01: ASN assignment criteria revisited
Proposal 2025-01, ASN assignment criteria revisited, was introduced to the RIPE community on 6 May 2025. The proposal would rewrite the requirements for receiving an ASN from the RIPE NCC by allowing LIRs and End Users to request a first ASN without justification. Additional ASNs would still require justification, including a unique external routing policy, a routing policy defined in the RIPE Database, peering with a third party, and, where the ASN is not visible in the global routing table, documentation of the non-visible use case. ASNs would also be expected to be in use within six months after issuance.
This is a cleaner and more direct proposal than 2024-01. Rather than trying to revise a broad section of address policy, it focuses on the threshold for a specific resource request. The policy question is simple: should a party be able to receive one ASN without having to prove the technical need in advance?
The community arguments in favor of the proposal focus on operational reality. Supporters argue that ASNs are no longer meaningfully scarce because of the full introduction and broad acceptance of 32-bit ASNs. The proposal materials note that IANA has assigned 402,332 ASNs to RIRs, about 0.01% of the available 32-bit ASN space, while RIRs have assigned roughly 88,400 ASNs to network operators, about 0.002% of that space. Supporters also argue that the existing requirements are difficult to enforce in practice: networks may qualify as multihomed when an ASN is issued, later become single-homed, or never become multihomed at all. The proposal materials state that roughly half of the ASNs allocated by the RIPE NCC do not meet the current requirements.
From a client-impact perspective, that argument is important. If the policy requirement is widely understood to be unenforceable, the process can become less about stewardship and more about paperwork. A more permissive first-ASN rule could make planning easier for organizations that have legitimate routing, BGP, RPSL, troubleshooting, or network-visibility reasons to operate an ASN, even if they do not fit neatly into the current multihoming model.
The community arguments against the proposal focus less on ASN exhaustion and more on routing-system impact. Opponents argue that easier ASN availability could increase the number of Autonomous Systems visible in the global routing table, potentially increasing routing complexity and the processing and memory requirements for network equipment. The proposal materials also identify a broader concern: if new technologies are built around easy ASN availability, the request rate for ASNs could grow significantly.
There are counterarguments in the community materials as well. One is that more ASNs may not increase hardware requirements as much as expected, because prefix announcements already consume routing-table resources even when announced through another AS. Another is that RIPE NCC’s per-ASN fee may help discourage excessive requests, although the proposal materials acknowledge that a €50 per-ASN fee may not be enough to prevent mass requests, while higher fees could negatively affect small and private ASN users.
For clients, the proposal’s practical effect would be reduced friction for the first ASN, not an unlimited path to ASN accumulation. The first ASN would become easier to obtain, while additional ASNs would still require a defined routing policy and justification. That makes 2025-01 a narrower test of whether the RIPE region is ready to move away from legacy conservation rules for first-time ASN assignments while still preserving controls against abuse, stockpiling, or unnecessary routing growth.
The key issue for the RIPE 92 discussion is therefore not whether ASNs are scarce in the same way IPv4 addresses are. The community appears to be debating a more practical question: whether the current ASN assignment criteria still serve a useful operational purpose, or whether they mainly add process friction to requests that the RIPE NCC cannot reliably police over time.
The co-chair election matters too
Before the second Address Policy session, the working group will hold its first Address Policy session on Thursday, 21 May, where participants will choose a new co-chair. That process matters because the chair team plays an important role in guiding policy discussion, judging consensus, and keeping proposals moving through the RIPE Policy Development Process.
With one proposal already struggling to find consensus and another raising a clean but important question about justification requirements, the working group’s leadership will have a meaningful influence on how these discussions are framed after RIPE 92.
What clients should really take away from RIPE 92
The core theme of RIPE 92 is policy friction, with one proposal trying to reduce friction in IPv6 PI assignment requests but may be too broad to win consensus in its current form. The other tries to reduce friction in single ASN requests by removing the justification requirement altogether. Both are worth following because small changes in request policy can have large effects on planning certainty.
For operators, LIRs, brokers, and address-strategy teams, this is not a meeting that appears likely to produce immediate disruption. It is more about watching where the RIPE community draws the line between simpler processes and careful stewardship.
To participate in the discussion, interested parties should register for RIPE 92, either onsite in Edinburgh for a fee or online for free.