The LIR Account in 2026: A Standing Cost, Not a Resource Tap

A customer wrote to our support desk last month asking, in effect, how long the queue was. They had a product launch dated, a /22 budgeted, and an assumption that a Local Internet Registry account was the way to get the addresses. I had to tell them the awkward truth: 841 networks are already ahead of them on the IPv4 Waiting List, and the one at the front has been there 503 days. Their launch was eight weeks out. The LIR account they were about to open would not deliver a single routable address in time.

That gap, between what an LIR account once was and what it now does, is the whole story of the RIPE NCC's April 2026 figures. The registry now holds 20,751 LIR accounts (up 34) and 19,987 members (up 51), and in March alone 1,789,824 IPv4 addresses changed hands through transfers, a jump of 265,600 over the prior month (RIPE NCC). Membership keeps climbing while the free pool stays empty.

The account has quietly changed jobs. It is no longer a tap you open to receive address space; it is a standing legal and financial position you hold in order to operate, transfer, and secure routing in a region where new IPv4 comes almost exclusively from the secondary market. I work the support side of that market every day, and the question I get most is the one that misses the point. People ask "how do I get on the list faster." The question this update should force is "should I be on the list at all, and what am I actually paying to keep this account open."

What the account buys you now, and what it does not

Strip away the marketing and a 2026 LIR account is three things bundled together: a contractual relationship with the registry, the right to hold and manage number resources, and access to the tooling, RPKI and the RIPE Database, that makes those resources routable and defensible. What it conspicuously does not buy is fresh IPv4. The /22 from the waiting list is the only allocation channel left, and at 503 days for the lead applicant it is a channel in name only.

The cost side has hardened too. The annual contribution sits at €1,800, and the Executive Board's "Option A" proposal would lift the base fee to €1,894. Layered on top are per-event charges that catch people off guard: €1,000 one-time to sign up, €50 for every Autonomous System Number assignment, €75 for each independent Internet number resource such as an anycast or provider-independent block. None of these prorate.

The billing rule is explicit. An account closed mid-year still owes the full annual contribution unless the closure request landed before the prior 31 December. That single clause turns a dormant LIR into a recurring liability, and it is why I see operators keep paying for accounts attached to networks that no longer exist.

Compare that with the other regions and the RIPE model's character becomes clear. ARIN starts its smallest tier near $275 per year; APNIC hands out two free ASNs per account. RIPE NCC monetises each assignment event individually. For a network that multi-homes or runs several anycast deployments, those €50 and €75 line items compound into real money, and they are easy to forget when you model only the headline fee.

Option A or Option B: vote your resource shape, ignore the slogan

The General Meeting puts two charging schemes in front of members, and the framing invites a lazy reading. Option A is the familiar single-fee-per-account model, raised to €1,894. Option B distributes the charge across the specific resources an account holds. The slogan version is "flat versus fair," and it is useless for deciding how to vote.

Here is the practical test, and it is the one I give customers who ask. The schemes redistribute the same total budget; they do not lower it. So the only question that matters is where your account sits relative to the median resource holder. A small operator with one ASN and a single block is likely to do better under a resource-weighted scheme than under a flat fee that bakes in the cost of large holders.

A large holder with many blocks and assignments is likely to pay more. Neither is "fairer" in the abstract; each is cheaper for a different shape of member. The RIPE NCC's own LIR Portal calculator settles this in minutes by pricing your actual resources under both models, and any member voting without having run it is voting on a feeling.

From the desk, the vote is being treated as procedural, and it is not. Whatever passes sets the cost base for every one of the 20,751 accounts through 2027. Treat it as the budget decision it is.

The waiting list is a queue you may never reach

The structural shift hiding inside this update is that the RIPE NCC has become a net destination for IPv4 transfers rather than a source of allocations. March's 1.79 million transferred addresses against an 841-deep waiting list tells you which channel is load-bearing. Demand from AI and IoT deployments keeps routable IPv4 valuable, and that demand is satisfied through purchase and lease while the queue sits idle.

For a network architect this reframes the waiting list as a planning hazard rather than a plan. A queue position offers no fulfilment date inside a normal product cycle. If your roadmap needs address space on a calendar, the waiting list cannot serve it, and building a launch around "we should reach the front eventually" is how projects stall. Expansion plans freeze for exactly this reason: the addresses get treated as guaranteed because an LIR account is open, when the account guarantees nothing of the kind.

That leaves two real procurement paths, and they trade against each other cleanly. A permanent transfer gives you outright ownership but demands upfront capital and proper due diligence on the block's history. Leasing gives you addresses in days rather than years; published 2026 lease pricing sits in a range of roughly $0.38 to $0.50 per IP per month (CircleID 2026 trends), which is recurring operating cost rather than a one-time outlay.

The decision rule is duration. If you need the space longer than the breakeven horizon between recurring lease and one-time purchase for your own block size, buy. If the need is shorter or uncertain, lease. The waiting list belongs in neither column for anything time-sensitive.

RPKI coverage is a real gap, and it is asymmetric

The update's routing-security numbers deserve more attention than they usually get. Route Origin Authorizations now cover 76% of IPv4 address space but only 44% of IPv6. Operators tend to read the high IPv4 figure as reassurance. The IPv6 figure reads as a warning, because the asymmetry means traffic on your newer protocol travels less-protected paths than your legacy traffic does, the opposite of what most migration plans assume.

RPKI works by having each Regional Internet Registry sign certificates that bind a prefix to an authorised origin ASN; the holder publishes a ROA, and downstream routers performing Route Origin Validation can then reject announcements that contradict it. The January 2026 update to the Certification Practice Statement tightened how those origin claims are validated.

Two limits are worth stating plainly, because they trip people up. A ROA stops an unauthorised origin, but it does nothing about an authorised holder leaking a more-specific prefix, so treat validation as a baseline that still leaves room above it. The protection is also only as good as the maxLength you set: authorise a range wider than you actually announce and you hand an attacker room to originate a still-valid more-specific. For a single-origin block the safe setting is a maxLength equal to the prefix length, no wider.

So how do you decide whether to trust a given block's ROA before you rely on it? The reasoning runs through five questions, and the order matters because each one assumes the last. Start with identity: confirm the holder and contact objects in the RIPE Database actually resolve to someone reachable, because a ROA attached to an unreachable holder is a maintenance problem waiting to happen. From there, establish the legitimate origin set, which means enumerating every ASN that genuinely originates the prefix, including any customer or downstream you might otherwise forget.

With that set in hand, the ROA itself becomes checkable: it should name that exact origin set and carry a maxLength equal to the announced prefix length for single-origin blocks, so no slack is left for a more-specific. Then the announcement has to be acceptable to the wider filtering ecosystem, which is why a matching route object must exist for IRR-based filters to pass the legitimate route.

Finally, none of this is worth much unattended, so the prefix belongs in invalid-route and hijack alerting; a ROA is a tripwire, and a tripwire matters only when someone hears it fire. The RIPE NCC's own BGP Routing Security courses, running through May and June 2026 in Rome, Riga, Copenhagen, and Batumi, exist precisely to drill this rhythm into quarterly operations.