Summary

  • AFPUB-2026-IPv4-003-DRAFT01 proposes four IPv4 pools, provenance tracing for recovered blocks, request-size controls and a post-exhaustion waiting list.
  • AFRINIC currently lists the draft as under discussion, while a dated PDWG-chair response said its June submission missed the cut-off for presentation as a new proposal at the upcoming policy meeting.
  • The operational lesson is to join two public records: one for every address movement and another for the procedural authority of every rule governing it.

Exact numbers do not make a rule operative

The draft is full of numbers that look ready for an operations manual. A normal request from its proposed Pre-Softlanding Pool could range from a /24 to a /18. A documented-growth exception could extend that ceiling to a /16. Applicants would show 80% efficient use of prior delegations over a 12-month justification period. After both primary pools reached zero, a waiting list would normally distribute /23 to /24 blocks, expire an unanswered request after 30 days and impose a 24-month restriction on voluntary transfer.

None of those numbers is a current operating instruction merely because AFRINIC publishes the draft. The official proposal index lists version 1.0, submitted on 8 June 2026, as under discussion. It is not identified there as having reached consensus, ratification or implementation.

That distinction matters early, not only at the final vote. Network operators plan capacity, acquisitions and address requests around expectations. A precise but unsettled threshold can influence behaviour before anyone has authority to enforce it.

Four pools create a provenance problem

The proposal would separate IPv4 resources into a Soft-Landing Pool, Policy-Reserved Pools, a Pre-Softlanding Pool and a temporary Recovered Pool. Recovered space would first enter the holding pool. AFRINIC staff would trace the block to its original category and return it there; if origin could not be established with reasonable certainty, the block would default to the Pre-Softlanding Pool. Partial blocks would be classified proportionally, and each action would be documented and announced.

This is more than inventory housekeeping. Pool origin would determine which eligibility, size and deferral rules apply. A classification error could therefore change who receives scarce space, how much they may receive and whether a later transfer is restricted.

The proposal says pool movements must be auditable and publicly reportable. A workable ledger would need to show the block, its prior status, the evidence used to classify it, the rule applied, the approving role, the timestamp, the destination pool and any later delegation. Aggregate pool totals alone would not let members reconstruct a disputed decision.

The operational figures in the draft require separate care. Its problem statement estimates roughly two years before depletion of the active Soft-Landing Pool, another three years for a reserved /12, more than three million recovered addresses and examples of members receiving more than eight /22 blocks through sequential requests. Those are claims made by the proposal authors. The frozen evidence packet does not independently audit the underlying data, so the figures should remain attributed rather than reported as settled measurements.

The policy process has its own queue

A second ledger is visible in the proposal's procedural history. In an archived message dated 18 June, the PDWG chairs acknowledged the 8 June submission but said the cut-off for new proposals for the upcoming AFRINIC meeting had been 26 May at 23:59 UTC. They also pointed to an existing proposal about recovered IPv4 space. Their conclusion was that this draft could not be accepted as a new proposal for discussion at that upcoming meeting.

That response was not a rejection of the ideas on their merits. The chairs encouraged the author to share the text with the author of the existing proposal and the wider working group as an improvement or alternative. AFRINIC's current index now lists the draft as under discussion.

The two records describe different states and should not be collapsed. “Under discussion” can describe an idea circulating in the policy process; it does not by itself prove eligibility for a particular meeting agenda. Missing a meeting cut-off does not prove that a proposal has been withdrawn, rejected by consensus or barred from later revision. Operators need dates, actors and transitions, not a single status label asked to carry every meaning.

A waiting list needs more than first-come, first-served

When both named primary pools are empty, the proposal would make recovered space the sole feed for a post-exhaustion waiting list. It calls for one active position per organisation or related entity, consolidation after mergers or acquisitions, and a requirement to demonstrate immediate infrastructural need. A member accepting a /24 when a justified /23 is unavailable could keep its place for the remainder.

These controls aim to prevent aggregation and queue gaming. But each depends on definitions and evidence that will be hard to apply under scarcity. “Related entity” needs a consistent ownership test. “Immediate infrastructural need” needs an evidentiary standard. First-come, first-served needs a trustworthy receipt time and rules for incomplete applications. Keeping a queue position after a partial delegation requires a visible method for calculating the remaining entitlement.

The draft would have AFRINIC publish queue length, total addresses available, average wait time and recovered space processed every month. Those metrics are useful, but they do not explain individual priority changes or classification decisions. The public aggregate should sit above an auditable decision record with privacy-preserving identifiers and published rules for corrections.

Put rule status beside resource state

The cleanest implementation design is a dual ledger. The resource side would record every block entering, moving between and leaving a pool. The authority side would record the proposal version, discussion state, meeting eligibility, consensus outcome, Board action, implementation date and the exact CPM text in force when each movement occurred.

The join between them is the important control. A recovered block should never be classified under a draft rule without a record showing that the rule had become effective. A later policy change should not silently rewrite the historical basis of an earlier delegation. A disputed queue decision should be reviewable against both the inventory facts and the rule version that governed it.

This structure would also help the community compare overlapping proposals. Instead of arguing from titles, participants could see which draft controls provenance, replenishment, utilisation, request size, waiting-list priority, transfers and disclosure—and where two drafts prescribe incompatible outcomes.

What to watch next

The next meaningful signal is not another estimate of the exhaustion date. Watch whether the draft is merged with, distinguished from or superseded by the earlier recovered-space proposal; whether a later meeting formally accepts it for discussion; whether operational impact analysis tests the proposed tracing and proportional-classification rules; and whether monthly metrics are paired with decision-level auditability.

AFRINIC cannot make IPv4 plentiful again. It can make scarcity decisions legible. That requires more than a pool dashboard and more than a proposal status badge. Every address movement should point to its evidence and every governing rule should point to the procedure that made it authoritative.

Sources