Name of Proposal	IPv6 as a criteria in IPv4 Soft Landing		Status: Under Discussion
ID:	AFPUB-2026-v6-001-DRAFT02	Date Submitted:	14/06/2026
Author(s):	Jordi Palet Martinez jordi.palet[at]theipv6company.com The IPv6 Company	Version:	2.0
Obsoletes:		Amends:	CPM

 

 

1. Summary of the problem being addressed by this proposal
 

Current deployment of IPv6 in AFRINIC service region is very low compared with other parts of the world, despite the continuous efforts undertaken by AFRINIC.

 

Data from APNIC Labs:

• Average IPv6 World capability 44% (including Africa)
  • 37%-51% depending on the region, about 50 countries exceed 50%)
• Africa IPv6 World capability 6%
  • Only 8 co`untries exceed 20%, 15 countries 10-19%, 15 countries below 1%
     

 

At the same time, AFRINIC is under the Soft Landing policy, Phase 2 since 2020 and since then, 3 million IPv4 addresses have been recovered.

 

The Soft Landing policy restricts the requests of IPv4 addresses, and despite that, it has not clearly proven an increase of the IPv6 deployment, so it looks like further measures need to be enforced towards giving a strong push on that direction, aligned with the Soft Landing policy.

 

Community discussions often come back to the same question: Should we mandate IPv6 deployment for new IPv4 requests? It seems there is no plausible reason for not doing so.

 

2. Summary of how this proposal addresses the problem

 
This proposal adds a paragraph to the existing Soft Landing policy in order to enforce IPv6 deployment for those requesting new IPv4 resources, regardless of being an initial or subsequent request. 

 

3. Proposal

 

Amend article 5.4.4 of the CPM, as follows:

 

Current

Proposed

5.4.4 For any LIR or End User requesting IPv4 address space during the Exhaustion   There is no explicit limit on the number of times an organization may request additional IPv4 address space during the Exhaustion Period.

5.4.4 For any LIR or End User requesting IPv4 address space during the Exhaustion   There is no explicit limit on the number of times an organization may request additional IPv4 address space during the Exhaustion Period.   Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space.   Regardless of if the IPv6 requests was already done previously or simultaneously with the IPv4 request, the relevant allocation/assignment criteria conditions must be met.   In addition, a coherent IPv6 deployment and addressing plan, must be presented clearly showing how will be met: 6.5.1.1.3 and 6.5.1.1.4, in the case of LIRs. 6.8.2.2.d, in the case of end-users.   The IPv6 deployment plan must show the actual IPv4 top-25 traffic destinations of that network. For each of those external destinations that are IPv6-enabled, the following minimum IPv6 % will be considered as compliant: 25% in a maximum of 12 months. 50% in a maximum of 24 months. 75% in a maximum of 48 months.   In case of networks hosting any kind of services, applications or contents, will be considered as compliant when matching the following % of AAAA RRs available and IPv6 reachable from Internet: 25% in a maximum of 12 months. 75% in a maximum of 24 months. 95% in a maximum of 48 months.   Failure to comply with the IPv6 deployment plan according to the relevant criteria, constitutes a policy violation.

 

4. References

In other regions, all IPv4 addresses have been exhausted and it seems that the equivalent to the soft-landing is not any more an issue, because most of the existing members only can access IPv4 addresses via transfers. Some of them have waiting lists,

 

ARIN has a dedicated IPv4 pool (NRPM 4.10.) to facilitate IPv6 deployment, which only can be used for specific IPv6 deployment needs.

 

In LACNIC, a request for IPv4 must be accompanied by an IPv6 request (if it was not already done for that member). This was already part of the IPv4 policy even before the equivalent to the “Soft Landing” policy.

 

There are some other exceptions, like for example the mandatory deployment of IPv6 in IXPs.

 

 

Revision History

Date	Details
22/05/2026	Version 1: AFPUB-2026-v6-001-DRAFT01 Initial Draft Posted to RPD
14/06/2026	Version 2: AFPUB-2026-v6-001-DRAFT02 Updated following RPD discussion

 

 

1. DPP Details

2. Previous Versions — Impact Assessments

3. AFRINIC Staff Assessment

3.1 References

The proposal keeps the current soft-landing approach that still allows IPv4 requests during the exhaustion period, but adds new eligibility conditions tied to IPv6 adoption. In practice, a new member requesting IPv4 would also need to request and justify IPv6. An existing member without IPv6 would need to do the same before qualifying for IPv4. The proposal further requires the requester to satisfy the relevant IPv6 allocation or assignment criteria and to submit a coherent IPv6 deployment and addressing plan. For existing members that already hold IPv6, any additional IPv4 request would trigger a retrospective review of the member’s IPv6 needs and use. The text also introduces measurable deployment expectations based on the organisation’s top 25 IPv4 traffic destinations that are IPv6-enabled, with minimum IPv6 compliance thresholds of 25% within 12 months, 50% within 24 months, and 75% within 48 months. Failure to meet IPv6 eligibility or to follow through on the deployment plan would make the organisation ineligible for IPv4 and could be treated as a breach of the Soft Landing Policy.

 

Benefit to AFRINIC: The proposal aims to encourage concrete IPv6 deployment rather than passive IPv6 holdings, and introduces stronger accountability for organisations seeking scarce IPv4 resources during exhaustion. It may support AFRINIC’s broader policy and stewardship objectives by linking remaining IPv4 access to demonstrated IPv6 transition intent.

 

Impact on Resource Members: Members without immediate IPv6 deployment plans would be required to justify IPv6 resources and provide additional operational evidence before receiving IPv4. This creates a more demanding request process, especially for members with limited IPv6 capability, limited expertise, or infrastructure constraints. The policy may disproportionately affect smaller operators, including WISPs, whose device compatibility, commercial realities, or technical readiness could delay IPv6 deployment even where the need for IPv4 remains operationally genuine. Staff considers that this may create tension with CPM fairness objectives, particularly where otherwise justified applicants are denied IPv4 because of practical barriers to IPv6 rollout.

 

3.3 Clarity of Policy Text

The proposal introduces meaningful implementation expectations, but several parts require clarification before reliable and consistent operational enforcement is possible.

• It is unclear whether the retrospective evaluation of already-issued IPv6 should assess both the original stated need and actual deployment progress over the initial 12-month period.

• The policy requires requesters to satisfy IPv6 eligibility criteria under sections 6.5.1.1.3, 6.5.1.1.4, and 6.8.2.2.d, but it does not clearly address the interaction with CPM section 6.4.4, which explicitly allows existing IPv4 service providers to justify larger IPv6 requests based on present IPv4 customers transitioning to IPv6.

• The phrase requiring a “coherent IPv6 deployment and addressing plan” is operationally significant, but the standard for coherence is not defined.

• The mechanism for measuring the top 25 IPv4 traffic destinations, validating which are IPv6-enabled, and assessing progress against the percentage thresholds is not specified.

• The proposal does not state what evidence is acceptable to demonstrate compliance, partial compliance, or justified delay in deployment.

• Specific CPM and procedural touchpoints requiring clarification include section 6.4.4 and the IPv6 eligibility provisions in sections 6.5.1.1.1 through 6.5.1.1.4 and 6.8.2.2.d.

 

3.4 Areas of Impact

3.4.1 Interaction with Existing CPM

• CPM 6.4.4: The proposal appears to overlook the existing provision that allows current IPv4 customer bases to support justification for larger IPv6 requests in transition scenarios.

• CPM 6.5.1.1.1 to 6.5.1.1.4: These LIR-related IPv6 qualification clauses become directly relevant to IPv4 eligibility under the proposal, creating a tighter policy coupling between IPv4 exhaustion handling and IPv6 allocation conditions.

• CPM 6.8.2.2.d: End-user IPv6 qualification also becomes a gating condition for IPv4, expanding the operational scope of IPv6 evaluation.

This interaction materially changes how staff would assess IPv4 requests during exhaustion by making IPv6 readiness and deployment evidence part of the decision path.

 

3.4.2 Interaction with Other DPPs Under Discussion

No direct interaction with other DPPs under discussion has been identified at this stage.

 

3.4.3 Impact on IP Numbers Registry Systems

3.4.4 Member Services Operations

• Procedures: The Member Services IPv4 and IPv6 resource evaluation procedures will require revision. Retrospective evaluation of previously allocated or assigned IPv6 resources, together with review of deployment plans and compliance evidence, will add significant workload and complexity.

• Contractual Agreements: No contractual updates have been identified from the current text.

• Website & Communications: Public web content, process guidance, FAQs, and implementation communications will need updates. Members will need clear explanations of new evidence requirements, review triggers, and the consequences of non-compliance.

3.4.5 IT

IT changes are expected primarily in MyAFRINIC and related internal workflow tooling. The request flow would need to support simultaneous or linked IPv4 and IPv6 submissions, structured capture of deployment-plan information, review checkpoints, and internal status tracking. Depending on implementation choices, IT may also need to support reminder notifications, compliance milestone tracking, and auditable decision records.

 

3.4.6 HR

The proposal is likely to require additional staff capacity and targeted training, particularly for Hostmasters involved in evaluating request justification and deployment evidence. Training would need to cover the new policy logic, interpretation standards, evidence assessment, and consistent handling of retrospective reviews. If the expected case volume increases materially, additional recruitment may be required.

 

3.4.7 Legal

No legal issue.

 

3.4.8 Finance

Financial impact is expected from staff training, and potentially increased operational headcount. Ongoing costs may include additional review time per request, and member support effort. A detailed cost estimate would depend on the final policy wording and the level of automation required.

 

4. Recommendations on Policy Wording

Staff recommends that the deployment-plan compliance details be moved to the relevant IPv6 sections of the CPM rather than being introduced indirectly through the IPv4 soft-landing context. This would improve structural clarity, reduce ambiguity during evaluation, and better align the operational obligations with the policy sections that already govern IPv6 qualification.

Additional wording improvements should explicitly define:

• what constitutes a coherent IPv6 deployment plan;

• how retrospective review is to be conducted for existing IPv6 holders;

• what evidence is required to show progress against the 12-, 24-, and 48-month thresholds;

• how section 6.4.4 should be applied when existing IPv4 infrastructure is part of the IPv6 justification; and

• what operational consequence follows from partial compliance, justified delay, or non-compliance.

 

5. Staff Clarification Requests

The following clarification is requested from the DPP authors :

• Current IPv6 demand is generally assessed over a 12-month period, with a minimum allocation of /32 and minimum assignment of /48. In many cases, these minimum amounts are already sufficient for operators in the region. How should AFRINIC staff assess the coherence of a member’s position when only a minimal amount of initially issued IPv6 space has been used after 12 months, but the member is requesting additional IPv4?

• Should retrospective review test both the original IPv6 justification and the member’s actual deployment performance against the stated plan?

• What evidence source should be used to determine the requester’s top 25 IPv4 traffic destinations and whether each destination is IPv6-enabled?

• How should AFRINIC treat cases where deployment delays are caused by upstream dependencies, customer equipment limitations, or market constraints outside the member’s direct control?

 

6. Implementation Plan

 

6.1 Timeline

A high-level implementation period of approximately 6 months is anticipated from ratification to production readiness.