[rpd] New policy Proposal: Dynamic IPv4 Pools Exhaustion Management Framework

[Darwin Da Costa]

Dear Policy Authors,

We acknowledge receipt of the proposal titled Dynamic IPv4 Pools Exhaustion Management Framework, which seeks to amend Section 5.4 of the Consolidated Policy Manual on 8 June 2026. Please note that:

1. An existing proposal Soft Landing Recovered Space and Priority https://afrinic.net/policy/proposals/afpub-2026-ipv4-001-draft01#proposal is currently under discussion regarding the recovered IPv4 space after Softlanding Phase has been triggered at AFRINIC.

2. Furthermore, the timelines for submitting new proposals for the upcoming AFRINIC meeting was 23h59 UTC, 26 May 2026.
As a result, this proposal cannot be accepted as a new proposal for discussion at the upcoming PPM.

We recommend and encourage that you share your proposal text around the recovered space and its merits with the author of the above mentioned proposal and PDWG on the RPD Mailing List as an improvement/alternative to the solution that is currently being discussed.

We trust that the spirit of the consensus-driven bottom-up principle of the PDP will prevail and that the community would be forthcoming in improving the current policy proposal that is being discussed.

Kind Regards
Darwin da Costa
Vincent Ngundi
PDWG Chairs


> On 17 Jun 2026, at 01:47, ALAIN AINA via RPD <rpd at afrinic.net> wrote:
> 
> Hi PDWG,
> 
> This proposal was submitted a week ago.
> 
> Thanks
> 
> —Alain
> 
>> Begin forwarded message:
>> 
>> From: aalain at digitalintelligence.africa
>> Subject: New policy Proposal: Dynamic IPv4 Pools Exhaustion Management Framework
>> Date: 8 June 2026 at 10:11:47 GMT
>> To: pdwg-chairs at afrinic.net
>> Cc: policy-liaison at afrinic.net
>> 
>> Dear Co-chairs,
>> 
>> Please find below a new policy proposal. If all in order, please assign the ID and publish it as soon as possible.
>> 
>> https://docs.google.com/document/d/1vy6RRhw1YTSmJ5W9bZlllw6rzH86nzdLl03zeL2DZ5U/edit?usp=sharing
>> 
>> =====
>> 
>> Dynamic IPv4 Pools Exhaustion Management Framework
>> 
>> AFPUB‑2026‑GEN‑XXX  
>> Version 1.0
>> ID: Assigned by AFRINIC Staff
>> 
>> Date Submitted: 08  June 2026
>> 
>> Author(s):
>> Adeola A. P. AINA (aalain at digitalintelligence.africa), 
>> Co‑authors: Contact me if you want to be co-author
>> 
>> Obsoletes: Amends: The soft landing policy section 5.4 of the CPM
>> 
>> 
>> 1. Definitions
>>    • Delegation — IPv4 Allocation to LIRs or Assignment to End‑Users.
>>    • Recovered Space — Any IPv4 resources returned, revoked, reclaimed, or otherwise recovered by AFRINIC.
>>    • Legacy Space —  Delegations prior to the RIR system and tagged as Legacy by AFRINIC.
>>    • Soft‑Landing Pool — The IPv4 pool administered under CPM Section 5.4 (Soft‑Landing Phase 2).
>>    • Policy‑Reserved Pool — Dedicated IPv4 blocks reserved for specific sub‑policies (e.g., IXPs, Critical Infrastructure).
>>    • Pre‑Softlanding Pool — A reserve pool replenished exclusively by recovered space originating from pre-Soft-Landing delegations, allocations from IANA‑recovered space and unclaimed or un-registered Legacy space.
>>    • Recovered Pool — The initial administrative holding area for all recovered IPv4 space prior to classification.
>>    • Post‑Exhaustion Waiting List — A structured queue used once both primary pools are fully depleted.
>>    • Immediate Infrastructural Need — A documented requirement for IPv4 resources essential to maintain or activate operational network services.
>> 
>> 2. Problem Statement
>> 
>> 2.1 Summary of the Problem
>> 
>> AFRINIC entered Soft‑Landing Phase 2 in 2020 when the remaining non‑reserved IPv4 space fell below one /11. Current delegation rates indicate:
>>    • Approximately 2 years remain before depletion of the active Soft‑Landing Pool.
>>    • Approximately 3 additional years remain before depletion of the /12 block reserved for future use.
>>    • More than 3 million IPv4 addresses have been recovered and currently fall under  Soft-landing Phase 2 rules by default.
>> Operational data shows that several members have obtained more than 8 × /22 (/19) within a calendar year by submitting multiple sequential requests, revealing gaps in the current framework.
>> 
>> The existing CPM lacks:
>>    • A structured mechanism to classify and return recovered space to its appropriate pool.
>>    • A predictable replenishment pipeline for IPv4 resources.
>>    • A post‑exhaustion delegation framework.
>>    • Automated operational triggers that adjust delegation behaviour based on pool health.
>>    • Protections against gaming through repeated small requests.
>> 
>> 
>> 2.2 Summary of How This Proposal Addresses the Problem
>> 
>> This proposal introduces:
>>    • A multi‑pool IPv4 management architecture with clear replenishment rules.
>>    • A tiered delegation framework that prioritises pre Soft-landing recovered space.
>>    • A post‑exhaustion waiting list with strict rationing and fairness rules.
>>    • A trace‑back mechanism ensuring recovered space returns to its rightful pool.
>>    • Operational transparency and anti‑gaming protections.
>> 
>> 3. Proposed Solution
>> 3.1 IPv4 Pools
>> 
>> This policy establishes four distinct IPv4 management pools:
>>    • Soft‑Landing Pool — Administered under CPM 5.4 Phase 2 rules.
>>    • Policy‑Reserved Pools — Dedicated pools for sub‑policies such as IXPs and Critical Infrastructure.
>>    • Pre‑Softlanding Pool — Replenished exclusively by:
>>        • Unclaimed or Un-registered Legacy space
>>        • Delegations predating the soft‑landing era
>>        • Allocations from the IANA Recovered IPv4 Pool
>>    • Recovered Pool — Temporary holding area for all recovered space prior to classification.
>> 
>> Operational Requirements:
>>    • All pools must be tracked independently in AFRINIC’s inventory system.
>>    • Movements between pools must be auditable and publicly reportable.
>> 
>> 
>> 3.2 Operational Rules
>> 
>> Rule 1 — Classification of Recovered Space
>> 
>>    • All recovered space shall first enter the Recovered Pool.
>>    • AFRINIC staff shall trace each block to its original source pool category.
>>    • Space shall be returned to that source pool.
>>    • If the source cannot be determined with reasonable certainty, the space shall default to the Pre‑Softlanding Pool.
>>    • Partial blocks shall be classified proportionally based on their traceable origin.
>>    • Classification actions shall be documented and publicly announced
>>    • AFRINIC shall minimise fragmentation when reassigning recovered space.
>> 
>> Rule 2 — Delegation Rules for the Pre‑Softlanding Pool
>> 
>> The Pre‑Softlanding Pool serves as the primary evaluation layer.
>>    • Maximum delegation size: /18 per request.
>>    • Minimum delegation size: /24
>>    • Justification period: 12 months
>>    • Pre-use requirement:  Applicants must provide evidence of efficient utilisation of all prior delegations to 80%
>>    • Extended maximum: Up to /16  if the member provides:
>>        • Documented growth metrics
>>        • A verifiable deployment plan
>> 
>> Members may not submit multiple concurrent or sequential requests intended to aggregate beyond the maximum delegation size.
>> 
>> Rule 3 — Automatic Deferral to the Soft‑Landing Pool
>> 
>> If a request cannot be satisfied by available blocks in the Pre‑Softlanding Pool:
>>    • The request shall be automatically deferred to the Soft‑Landing Pool.
>>    • AFRINIC staff must document the deferral and notify the applicant.
>>    • Soft‑Landing Phase 2 conditions, as defined in CPM Section 5.4, shall apply to all delegations made under this deferral mechanism.
>> 
>> Rule 4 — Post‑Exhaustion Waiting List Framework
>> 
>> When both the Soft‑Landing Pool and Pre‑Softlanding Pool reach zero available space, all IPv4 delegations shall be managed exclusively through a Post‑Exhaustion Waiting List.
>> 
>> 4.1 Feeding Mechanism
>>    • The Recovered Pool becomes the sole source of IPv4 space for the waiting list.
>> 
>> 4.2 Queue Rules
>>    • Requests must demonstrate immediate infrastructural need.
>>    • Queue operates strictly first‑come, first‑served.
>>    • Only one active position per organisation or related entity.
>>    • Requests expire after 30 days if the member does not respond.
>>    • Mergers or acquisitions involving entities on the list shall result in consolidation to a single queue position.
>> 
>> 4.3 Delegation Sizes
>>    • Maximum: /23
>>    • Minimum: /24, unless global routing standards or internet community consensus officially shift the minimum universally routable prefix size below a /24, in which case AFRINIC shall align its minimum allocation floor to match the new global standard.
>>    • If a /23 is justified but only a /24 is available, the member may accept the /24 without losing queue position.
>> 
>> 4.4 Deployment Requirement
>>    • Delegated space must be fully deployed within 6 months.
>>    • After deployment, the member may re‑apply at the bottom of the queue.
>> 
>> 4.5 Transparency Requirements
>> AFRINIC shall publish monthly:
>>    • Queue length
>>    • Total addresses available
>>    • Average wait time
>>    • Total recovered space processed
>> 
>> Rule 5—  Transfer of  IPv4 addresses 
>> Address space delegated from the pre-softlanding pool and later on from the waiting list will not be eligible for transfer, with the exception of  Mergers, Acquisition and Takeovers  for a period of 24 months. Transfer restrictions on delegations from the soft landing pool shall apply. 
>> 
>> 5. Acknowledgements
>> The authors acknowledge community feedback and operational insights from AFRINIC staff that informed this revised framework.
>> 
>> 6. References
>>    • AFRINIC Policy Implementation Experience Report
>>    • AFRINIC Statistics Portal
>>    • IANA Recovered IPv4 Pool Procedures
>>    • Global RIR IPv4 Exhaustion Models
>> 
>> 7. Situation in other regions
>> 
>> 7.1 APNIC
>> APNIC managed its final /8 by limiting allocations to a strict maximum size per member. Initially set to a /22, it was later reduced to a /23. On 2 July 2019, APNIC implemented Prop-129, which completely abolished the waiting list for unmet IPv4 requests due to the lack of a predictable stream of recovered space. Instead, APNIC continues to delegate up to a strict total lifetime maximum of a /23 per member exclusively from its remaining 103/8 pool and a separate pool of recovered non-103 space. Allocations from these scarce resource pools are held from voluntary transfer for a period of 24 months. 
>> 
>> 7.2 LACNIC
>> LACNIC officially reached total exhaustion of its remaining non-recovered pools on August 19, 2020, triggering a permanent waiting list system funded strictly by returned, revoked, and recovered space after a mandatory 6-month quarantine. Under the LACNIC Waitlist Policy, approved organisations that have  assigned IPv6 are placed in a first-come, first-served queue with a maximum allocation cap of a 
>> /22. Space allocated from the LACNIC waiting list is restricted from voluntary transfer for a period of 36 months.
>> 
>> 7.3 RIPE NCC
>> Following complete depletion of its available free pools, RIPE NCC implemented a strict post-exhaustion waiting list. Under the current RIPE IPv4 Waiting List Policy, allocations are restricted to exactly one /24 per Local Internet Registry (LIR), provided the LIR has never received an IPv4 allocation from RIPE NCC before. Allocations from this waiting list are held from voluntary transfer for a period of 24 months. 
>> 
>> 7.4 ARIN
>> ARIN initially deployed an unrestricted waiting list. Because it lacked strong caps, the queue faced systemic gaming, forcing the ARIN Board to temporarily suspend the waiting list in 2019. ARIN subsequently reinstated the list with strict anti-gaming parameters: organisations holding more than a /20 equivalent in aggregate are entirely ineligible to apply, and the maximum allocation size is capped at a /22. Space distributed from the ARIN IPv4 Waiting List cannot be transferred to another organisation for 60 months, except in cases of corporate mergers, acquisitions, or takeovers. 
>> =====
>> 
>> 
>> Thanks
>> 
>> —Alain 
>> 
>> 
>> 
> 
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260618/5640b49b/attachment-0001.html>