841 LIRs Wait 536 Days: Read the RIPE Numbers Right

Every month operators read the waiting-list number the same wrong way: as a queue that is long and slow but one you can join and outlast. After eight years inside the RIPE and ARIN databases on behalf of clients, I have watched that reading park more builds than any technical failure. The figure is almost always quoted correctly. The conclusion drawn from it, "join early, be patient, your turn comes," is what quietly stalls a project for eighteen months on one small allocation.

The May 2026 update makes that misreading expensive in two directions. The waiting list says the registry can no longer supply you on any useful timeline. The routing-security split, 76% of IPv4 space covered by ROAs against 44% for IPv6, says the part of your network you are about to expand into is the part nobody has secured. The practical message is blunt: the registry stopped being your supplier, so act like it, and the IPv6 routing gap is the real exposure.

This piece walks the update in that order: the queue and what actually clears it, the security gap and what it costs you, the legacy and governance changes that quietly reshape the bill, and a short verification routine I run before trusting any of it. Source figures come from the RIPE NCC member update for May 2026; I have cut every market-size forecast that the original write-up leaned on.

The waiting list is a supply signal, not a queue you join

841 is not a backlog that drains. It is the visible edge of exhaustion. The RIPE region ran out of freely allocatable IPv4 years ago, and the list now recycles only what trickles back from closed members and recovered space. April alone saw 2,874,112 addresses transferred between members, up by more than a million on the previous month, while the queue barely moved. That contrast is the whole argument: addresses are flowing in volume, just not through the registry's free list.

So the planning question is not "how long until my turn?" That answer is "longer than your project can wait, with no guarantee." The question is which acquisition path fits the block size and the timeline you actually have. Three options sit on the table, and only two of them deliver this quarter.

The membership math matters here too. There are now 20,029 members across 76 countries, and the LIR fee is flat at €1,800 a year regardless of how much address space you hold. That flat structure means joining the registry to wait costs the same as joining it to actually use a large allocation. You just get nothing back from the list. For a network that needs a /24 next month, the LIR fee buys a queue position it cannot use. The transfer market and leasing exist precisely because that queue position is worthless on an operational timeline.

The ROA gap is the part of your build nobody secured

Here is where I take a position the original article ducked. The 76%-versus-44% ROA split is not a minor footnote about coverage. It means that as you push services onto IPv6, the addresses you grow into carry less than half the route-origin protection of the legacy space you are leaving. You are migrating toward the weaker security posture.

A Route Origin Authorization is a signed statement in the RIPE Database binding a prefix to the autonomous system allowed to announce it. Where it exists, networks running origin validation can tell a legitimate announcement from a hijack. The 44% figure means most IPv6 space has no such statement, so a bogus origin for those prefixes has nothing to contradict it. That is exactly the asymmetry an attacker looks for, and it is widest on the protocol everyone is told to adopt.

The danger for an operator is treating "sign everything" as the fix and rushing it. Origin validation is unforgiving in one specific way. The instant a ROA exists, any announcement of that prefix from an origin the ROA does not name becomes invalid, and validating networks drop it. Sign a block while a customer or an old downstream still announces it under a different AS and you have taken your own traffic offline.

The RIPE NCC's updated BGP Security course, built on RFC 9234 with a new lab on setting up BGP roles, exists because this configuration order is where operators hurt themselves. So the rule worth fixing in your head is plain: confirm every AS that legitimately originates a prefix before you authorize any of them. Doing it after the route disappears is too late.

The governance side moved this month too. At the General Meeting in Edinburgh on 20-22 May 2026, members adopted the Financial Report 2025 and selected Model A, "One LIR Account, One Fee," for the charging scheme. The flat €1,800 stays, with a proposed move to €1,894 floated for 2027 and a separate €75 charge per Provider Independent assignment. None of that buys you addresses faster. It only fixes what you pay to keep the door open.

Legacy blocks and the data that needs cleaning

Two quieter items in the update point at the same underlying problem: address space whose records nobody is maintaining. RIPE NCC staff looked at legacy space still outside any contract, the blocks "that still need to be brought under contract," to understand the behaviour coming from them. Separately, a 2026 operational review of Public ENUM under e164.arpa found that half of the current delegations show some form of DNS problem.

I would not file these as housekeeping. Both describe the registry's data drifting out of sync with reality, and stale registry data is the soil hijacks grow in. A legacy block with no current contract often has no maintained contact either, which means an incident on it cannot be reported to anyone.

A legacy holder can close that gap without a sign-up fee by registering through a sponsoring LIR, though standard annual service fees still apply. For half the ENUM delegations, the problem is broken delegation chains rather than money. The common thread, and the reason both made the same update, is that correct registration now functions as a security control in its own right. It has stopped being a purely administrative nicety.

A verification routine before you trust any of this

Treat the numbers in a member update as a starting point. They are no substitute for checking the balance sheet of your own space. Before I act on any of the figures above for a specific block, I run the same short checklist. None of it needs anything beyond public data.

1. Confirm the figure against the primary source rather than a summary. The waiting list is 841 and the wait is 536 days in the RIPE update itself; a secondary write-up that says otherwise is wrong, and this article exists partly because one did.
2. Check the registration status of the exact block you care about. A whois lookup on the prefix tells you whether it is allocated, legacy, or out of contract, and whether the maintainer is current.
3. Read the abuse contact and test that it reaches a human. A block whose abuse mailbox bounces is unowned for incident-response purposes, whatever the database nominally says.
4. Establish every AS that legitimately announces the prefix before creating a ROA. If that set is more than one, a ROA naming a single origin will break the others.
5. Decide acquisition by timeline rather than by hope. If you need addresses inside the quarter, drop the waiting list from consideration and price the transfer and the lease instead.

Run those five in order and the member update stops being a wall of statistics and becomes a set of decisions you can actually defend to a finance team.