Summary

  • RIPE NCC’s 27 August member update reports 757 LIRs on the IPv4 Waiting List and says the first LIR in the queue had waited 467 days.
  • The 467 days describe the queue head at one dated snapshot. They are not an average, median, service promise or predicted wait for every applicant.
  • RIPE NCC’s public history exposes only queue length and first-position age. A fall in either series cannot reveal how many /24s were allocated, how many requests arrived, or how many LIRs withdrew or ceased to qualify.
  • A privacy-safe monthly flow ledger could reconcile opening stock, eligible entries, withdrawals, eligibility exits, completed allocations and closing stock, alongside wait-age percentiles and quarantine releases.

The oldest wait is not the queue

One line in the RIPE NCC Member Update for August 2026 compresses an unusually long operational process into two figures. There were 757 LIRs on the IPv4 Waiting List. The first LIR in the queue had been waiting for 467 days.

The numbers are precise, but their meaning is narrower than the likely headline. The 467 days belong to the LIR at the front on the date of the update. They do not say that a typical LIR waits 467 days. They do not show the median, the 90th percentile or the range. They do not promise that a new request submitted today will wait the same time. RIPE policy expressly says there is no guarantee about waiting time.

The unit also matters. The same member update lists 20,687 LIR accounts and 19,977 members. Those totals are different because an LIR account is not automatically a unique member, person or network. The waiting-list figure is 757 LIRs. It must not be silently rewritten as 757 companies, 757 operators or 757 future recipients.

That discipline is not pedantry. A queue is a stock observed at a point in time. What readers want to understand is the flow through it: who entered in aggregate, why entries left in aggregate, how much recovered address space became allocatable, and what the wait looks like away from the single oldest position.

A two-line chart cannot balance the movements

RIPE NCC already maintains a useful public waiting-list page. It labels the two visible measures as LIRs in queue and Days that first LIR in queue has been waiting. The page says its table and graph are updated every three hours.

The underlying public JSON history is unusually valuable because it preserves daily observations back to November 2019. In the frozen research copy for this article, the 30 August 2026 row records 759 LIRs and 470 days. That later live reading does not correct the member update’s 757 and 467. It is a different snapshot of a changing queue.

The history makes movement visible. It does not make the causes visible. If the queue falls by 100, at least four stories could be hiding inside the same net change. RIPE NCC may have allocated recovered /24s. LIRs may have withdrawn. Membership closures or eligibility checks may have removed requests. New eligible requests may have arrived while an even larger number left. The public series cannot separate those paths.

The same problem applies to queue-head age. It may fall because the first LIR received a /24. It may fall because that LIR withdrew or ceased to qualify. It may rise while many allocations occur behind a discontinuity in the underlying cohort. Without gross flows and a distribution, a change in the line is evidence that state changed, not evidence of one particular cause.

This is why the frozen series’ extremes should be handled carefully. It reaches a queue-length high of 1,249 on 6 March 2023 and a first-position-age high of 616 days on 22 June 2025. Those maxima occurred on different dates. Combining them into one imaginary worst day would be false. More important, neither maximum reveals how quickly the middle of the queue moved.

The policy rations a recovered and uncertain supply

The current published IPv4 policy, RIPE-826, makes the basic rule easy to state. Allocation requests enter a first-come-first-served waiting list. No guarantee is given about waiting time. A qualifying LIR can receive exactly one /24, equal to 256 IPv4 addresses, and the sum of allocations under this rule to one LIR is limited to that /24.

If RIPE NCC cannot form a contiguous /24, the policy says no allocation is made until enough address space has been recovered to do so again. This is not a normal inventory queue with a known replenishment schedule. Its supply comes from address space returned or recovered after closure and other administrative events.

The operational explainer adds two useful boundaries. Requests are submitted through the LIR Portal and added automatically to the list. Members can inspect their own place in the queue privately. Recovered addresses enter a quarantine process before being treated as new space and allocated in list order.

RIPE NCC also says it is impossible to predict how much address space it will recover in coming years and that it does not expect the volume to be large. That uncertainty should remain central. A better public record could document past movements; it could not manufacture supply or produce an honest delivery date for a named applicant.

RIPE NCC has published richer aggregates before

The current public dashboard is not the full limit of what the registry can disclose safely. In 2023, a RIPE Labs analysis of the waiting list reported that 5,572 /24 allocations had been made when its data was pulled on 7 July. It also gave a privacy-safe composition of the 1,025 LIRs then waiting, distinguishing LIRs held by members with one account from those split among members with several.

Those figures are historical. They must not be projected onto the 2026 queue. Their importance is institutional rather than current: RIPE NCC has already shown that an aggregate account/member analysis can be published without naming the organizations in line.

The 2023 article was a one-off analytical view. The recurring dashboard still gives only the closing stock and queue-head age. A reader cannot reconstruct monthly allocations from the daily difference because a net change combines every entry and exit. Nor can a reader determine the current account/member composition from an old study.

The missing disclosure is therefore not a public list of applicants. It is a repeatable accounting identity.

Publish the queue as a stock-and-flow receipt

A monthly receipt could begin with one equation:

opening LIRs + new eligible entries − withdrawals − eligibility or membership exits − completed allocations = closing LIRs

Each component would need a definition. New eligible entries should mean requests admitted to the queue, not all enquiries or incomplete submissions. Completed allocations should mean /24s actually allocated, not addresses merely recovered or still in quarantine. Eligibility exits should be separate from voluntary withdrawals when the numbers are large enough to publish safely.

The supply side needs its own clock. RIPE NCC could report the number of /24-equivalents recovered and entering quarantine during the month, the number released from quarantine, and the number allocated. A recovered block is not yet an allocation; a released block is not necessarily evidence of routing or use. Keeping those stages separate would stop one event borrowing the meaning of another.

The stock should be paired with a distribution. Age buckets—under 90 days, 90–179, 180–364, 365–499 and 500 days or more, for example—would show whether the 467-day head is representative or exceptional. Median, 75th and 90th percentile wait ages would make changes in the middle visible. Buckets can be broadened and small cells suppressed if a narrow band risks identifying an applicant.

Finally, the receipt needs a timestamp, the current policy-document identifier, a method version and a revision log. If a late withdrawal or corrected classification changes a prior month, the old figure should not disappear without a trace.

None of this requires LIR names, exact private positions, contacts, request narratives or organization-level outcomes. RIPE NCC can keep the individual queue in the portal while publishing aggregate movements on the public site.

A shorter queue is not automatically better news

The operational value of the receipt appears when the same net number can mean different things. A queue that falls after many /24 allocations is evidence of recovered space moving through quarantine and into the policy process. A queue that falls mainly through withdrawals may reflect applicants revising plans, leaving membership or deciding that the wait no longer serves them. A queue that remains flat while gross entries and allocations are both high is active, not static.

Those explanations carry different implications for members. An operator planning around scarce IPv4 needs to know whether supply is flowing, not merely whether the closing stock changed. A RIPE community participant evaluating policy needs to know whether the rule is serving a recurring group of new entrants or mostly retaining an ageing cohort. A Board or budget reviewer needs to distinguish the cost of processing new requests from the work of recovery, quarantine and allocation.

The receipt would not answer whether first-come-first-served is the best policy. That is a community decision. It would give the community a cleaner record on which to argue about it.

Scarcity deserves accounting, not false precision

The 467-day number is useful precisely because it signals the age at one edge of the system. Trouble begins when an edge measure is allowed to stand in for a distribution, or when a net stock is allowed to stand in for gross movement.

RIPE NCC has not claimed more than its numbers show. Its public page names the first LIR, not the average LIR, and its policy refuses to promise a wait. The necessary response is not to soften those caveats. It is to make them operationally legible.

An opening-to-closing flow ledger would let the 757-LIR snapshot travel with its own explanation. Readers could see how many requests entered, how many left for each aggregate reason, how many allocations completed and how the age profile changed. The registry would preserve confidentiality. The community would gain a record that can be compared from month to month without reverse-engineering a line chart.

IPv4 scarcity cannot be solved by better reporting. But a scarce public resource should leave a public accounting trail as it moves.

Sources