Summary

  • AFRINIC proposal AFPUB-2026-IPv4-003-DRAFT01 would classify recovered IPv4 space into four pools and return each block to the pool tied to its history.
  • The draft would cap ordinary pre-Soft-Landing requests, stop serial requests from evading the cap, and open a first-come queue only after both main pools are empty.

The address gets a file before it gets a new owner

An IPv4 block comes back to AFRINIC. What happens next? In the current draft, it first enters a temporary Recovered Pool. Staff trace its origin, then return it to the matching pool. If the trail cannot be established with reasonable certainty, the draft sends it to the Pre-Softlanding Pool. Partial blocks are classified in proportion to their traceable origins. Each move should be auditable and publicly reportable.

That is more than tidying an inventory. The proposal makes an address block’s administrative past decide which allocation rules apply to its future. The drawer is part of the rule.

AFPUB-2026-IPv4-003-DRAFT01, submitted on 8 June 2026 by Adeola A. P. AINA, is listed by AFRINIC as Under Discussion. It proposes four pools: Soft-Landing, Policy-Reserved, Pre-Softlanding and Recovered. It would keep separate inventories, publish movements and minimise fragmentation when space is reassigned. These are draft rules, not adopted policy.

For the Pre-Softlanding Pool, the draft sets a normal range from /24 to /18 and asks for a 12-month justification. Applicants would have to show 80% efficient use of prior delegations. A request could reach /16 with documented growth metrics and a verifiable deployment plan. Members could not stack concurrent or sequential requests to get around the cap. If that pool could not satisfy a request, AFRINIC would document the shortfall and defer it automatically to the Soft-Landing Pool under that pool’s existing Phase 2 conditions.

The queue is not the first stop. It appears only after both the Soft-Landing and Pre-Softlanding pools reach zero. Then the Recovered Pool becomes its sole source. Applicants would need to show immediate infrastructural need; the queue would run first-come, first-served, with one active place per organisation or related entity. A request expires after 30 days without a response. A justified /23 could be accepted as a /24 if only that smaller block were available, without losing queue position.

Recipients would have six months to deploy the space. They could apply again only at the back of the queue. AFRINIC would publish monthly queue length, available addresses, average wait and recovered space processed. Pre-Softlanding and waiting-list delegations would face a 24-month transfer restriction, except for mergers, acquisitions and takeovers; Soft-Landing transfers would keep their existing rules.

The architecture is unusually legible on paper: provenance, eligibility, queue position, deadline, deployment and transfer all have named fields. Its harder test is whether the ledger can keep those promises when recovered space is messy, a block crosses historical categories, or the queue becomes the only door left.

Sources