Introduction
The Policy Implementation Experience Report (PIER) is a presentation delivered by AFRINIC staff during AFRINIC Public Policy Meetings. Its objective is to provide feedback to AFRINIC Resource Members and the wider community on:
- Recently ratified policies and their implementation timelines
- Ratified policies that have already been implemented
- Real‑time experiences and challenges faced by Hostmasters while handling requests governed by current policies
- Sections of the Consolidated Policy Manual (CPM) that:
- are ambiguous
- lack clarity
- or conflict with other sections
By sharing these experiences, the AFRINIC community, including Resource Members, is able to:
- Request clarification on policy interpretation
- Propose new policy changes to address the identified issues via the AFRINIC Policy Development Process (PDP)
This continuous refinement and optimisation of number resource policies helps ensure they remain:
- Relevant
- Fair
- Aligned with the evolving needs of our stakeholders
Areas of the Policy Manual That Can Be Improved
All implemented policies are documented in a single reference document: the Consolidated Policy Manual (CPM).
To support future policy proposals, we have consolidated below a list of challenges that were presented to the community in past AFRINIC Public Policy Meetings and that remain unaddressed in the CPM.
To support future policy proposals, we have consolidated below a list of challenges that were presented to the community in past AFRINIC Public Policy Meetings and that remain unaddressed in the CPM.
1. IPv4
With the implementation of the IPv4 Soft Landing Policy, the text in Section 5 of the CPM needs to be revisited to remove ambiguities, repetitions, and inconsistencies.
In particular, Sections 5.5 and 5.6 require review to provide clear guiding principles on how AFRINIC should manage its IPv4 address pool, taking into account that:
In particular, Sections 5.5 and 5.6 require review to provide clear guiding principles on how AFRINIC should manage its IPv4 address pool, taking into account that:
- Soft Landing Phase 1 was reached in 2017
- Soft Landing Phase 2 was reached in January 2020
- Phase 2 continues until:
- no IPv4 addresses remain in the available pool, and
- the /12 space reserved for future use is fully utilised (as per Section 5.4.7.2)
1.1 Obsolete Criteria for Additional Allocations and Assignments
The following sections of the CPM are now obsolete and cause confusion for Resource Members regarding their eligibility to receive additional IPv4 resources:
Section 5.5.1.4.1
An LIR may receive an additional allocation when about 80% of all the address space currently allocated to it has been used in valid assignments and/or sub‑allocations. A new allocation can also be made if a single assignment or sub‑allocation requires more addresses than those currently held by the LIR.
Section 5.6.3 – Additional PI Assignment
*Utilization rate of address space is a key factor in justifying a new assignment of IP address space. Requestors must show exactly how previous address assignments have been utilized and must provide appropriate details to verify their one‑year growth projection. The basic criteria that must be met are: A 25% immediate utilization rate, and A 50% utilization rate within one year.*
However, additional resource requests are currently evaluated in accordance with Section 5.4.6.1 of the CPM, which states:
5.4.6.1
*Utilization rate of address space is a key factor in justifying a new assignment of IP address space. Requestors must show exactly how previous address assignments have been utilized and must provide appropriate details to verify their one‑year growth projection. The basic criteria that must be met are: A 25% immediate utilization rate, and A 50% utilization rate within one year.*
In practice:
- Section 5.4.6.1 supersedes Sections 5.5.1.4.1 and 5.6.3, but
- The older text remains in the CPM and continues to confuse members
Presented at: AFRINIC‑29, AFRINIC‑30, AFRINIC‑31, AFRINIC‑32
1.2 Minimum Allocation Size
Section 5.5.1.2.1 currently states:
Section 5.5.1.2.1 currently states:
AFRINIC's minimum allocation is /22 or 1024 IPv4 addresses.
This is obsolete and causes confusion for LIRs regarding the minimum allocation they can receive. Under the current exhaustion policy, AFRINIC applies Section 5.4.3.2:
5.4.3.2 – Exhaustion Phase 2
During this phase, a minimum allocation/assignment size will be /24, and the maximum will be /22 per allocation/assignment.
1.3 Sub‑Allocation Window (SAW) Period vs. Soft Landing Needs
Section 5.1.13.3.1 states:
The LIR cannot make any sub‑allocation to the End‑User above their SAW in a 12‑month period (1 year). At the end of a calendar year from the approval of a SAW, the SAW is refreshed for one more year. In case the LIR's SAW is exhausted for a particular End‑User, approval must be sought from AFRINIC for any other sub‑allocation to the same End‑User.
Challenge:
- The Soft Landing Policy reduced the planning horizon for IPv4 needs to 8 months, whereas the SAW text still references a 12‑month period.
- This 12‑month period remains in force in the absence of a new policy
- The misalignment between 8‑month needs assessment and 12‑month SAW can create operational confusion
Presented at: AFRINIC‑30
1.4 90% Utilisation Requirement vs. Redundancy / High‑Availability Needs
As noted above, Section 5.4.6.1 requires that:
The LIR or End User must have used at least 90% of all previous allocations or assignments during the Exhaustion Phase.
Challenge (example):
- An End‑User member requests an additional /24 IPv4 block for data centre redundancy
- The member’s current usage is less than 90%
- Under the current Soft Landing policy, the member is not eligible for additional resources
- As a result, they cannot deploy the second data centre, even though the request is for redundancy / resilience rather than pure growth
Policy question: Should the policy explicitly allow exceptions or alternate criteria for: Redundancy, High availability, or Technical limitations?
Presented at: AFRINIC‑29, AFRINIC‑30
2. Transfers
Current CPM text: Section 5.7.1 currently allows IPv4 transfers for Intra‑RIR transfers only.
Challenges / Gaps: Members have expressed interest in:
- Transferring ASNs
- Transferring IPv6 resources
- Mergers & Acquisitions (M&A): Transfers of all relevant resources (IPv4, IPv6, ASNs) are presently accepted based on existing guidelines (non‑policy). There is no explicit, comprehensive policy text covering all transfer scenarios.
Request to the community: Should the CPM be updated to:
- Cover transfers of all number resources (IPv4, IPv6, ASNs)
- Explicitly address Mergers & Acquisitions in policy text rather than only in guidelines?
Update – April 2026
The ratified “AFRINIC Number Resources Transfer Policy”, once implemented, will allow ASNs to be transferred within the AFRINIC service region.
Presented at: AFRINIC‑29, AFRINIC‑30
3. Additional IPv4 Exhaustion‑Phase Parameters
3.1 Allocation/Assignment Period
Section 5.4.5 changes the allocation and assignment period from 12 months to 8 months. This has downstream effects on:
Section 5.6.3 – Additional PI Assignment (repeated here for context) expects:
Challenge: There is a misalignment between projections based on a 12‑month horizon, and the 8‑month timeframe introduced by Soft Landing in Section 5.4.5.
Section 5.4.5 changes the allocation and assignment period from 12 months to 8 months. This has downstream effects on:
- How utilisation is evaluated
- How projections are made in other sections (e.g. PI assignments in 5.6.3)
Section 5.6.3 – Additional PI Assignment (repeated here for context) expects:
- 25% immediate utilisation
- 50% utilisation within one year
Challenge: There is a misalignment between projections based on a 12‑month horizon, and the 8‑month timeframe introduced by Soft Landing in Section 5.4.5.
Presented at: AFRINIC‑31, AFRINIC‑32
4. IPv4 Soft Landing Policy – Recovered Space
AFRINIC entered Soft Landing Phase 2 in 2020 when it had no more than one /11 of non‑reserved IPv4 space remaining in the final /8. Subsequently, AFRINIC also recovered more than 4 million IPv4 addresses.
Experience: At the current delegation rate:
- Approximately 2 years are estimated to deplete the 783,872 IPv4 addresses currently available
- An additional ~3 years are estimated to deplete the /12 block (around 1 million addresses) reserved by policy for future use
- Several Resource Members have received more than 8 × /22 within a calendar year by submitting multiple requests up to the maximum /22 prefix size.
Key policy question to the community: Should the recovered 4+ million IPv4 addresses:
- Automatically fall under the existing Soft Landing Phase 2 conditions? OR
- Be subject to a new policy governing how recovered IPv4 space is handled?

