Summary

  • AFPUB-2026-v6-001-DRAFT02 would tie any new IPv4 request to IPv6 eligibility, a deployment plan and percentage targets over 12, 24 and 48 months.
  • AFRINIC's impact assessment says the evidence standard and top-25 measurement method are not defined and warns that smaller operators may face disproportionate burdens.
  • AFRINIC 37 did not reach consensus, so the proposal returned to the mailing list and remains under discussion rather than adopted or implemented.

Scarcity turns an incentive into an eligibility test

AFRINIC's draft starts from an intuitively strong proposition: organisations asking for scarce IPv4 space should not treat IPv6 as a decorative allocation. If an applicant does not already hold IPv6 space, the proposed rule would require a simultaneous IPv6 request. Applicants that already hold IPv6 would still have to meet the relevant allocation or assignment criteria and present a coherent deployment and addressing plan.

That is more than a request for readiness. The draft attaches scheduled percentages to the plan. For access networks, it looks at the operator's actual top 25 IPv4 traffic destinations that are IPv6-enabled and sets minimum IPv6 shares of 25% within 12 months, 50% within 24 months and 75% within 48 months. For networks hosting services, applications or content, it sets targets for AAAA records and Internet reachability: 25% within 12 months, 75% within 24 months and 95% within 48 months. Failure to comply would constitute a policy violation.

The incentive and the sanction therefore arrive together. An operator is not merely encouraged to deploy IPv6; continued eligibility for IPv4 would depend on how AFRINIC interprets and measures progress. In a region where remaining IPv4 is rationed, measurement design becomes allocation policy.

The denominator can move when the policy succeeds

The access-network metric has a built-in paradox. As popular destinations successfully shift traffic to IPv6, they can disappear from the network's top-25 IPv4 destination list. The remaining IPv4 ranking then becomes more concentrated in destinations that have not enabled IPv6. Progress changes the comparison set against which further progress is judged.

Jaco Kroon raised this problem in an archived 22 July RPD message. He argued that the proposed ranking is a moving target and suggested a different test: measure the share of downstream customers or networks that can obtain well-connected IPv6 if they choose, without requiring them to switch it on. That is a participant's proposal, not adopted policy, but it identifies a useful design principle. A compliance denominator should not deteriorate because successful traffic has left it.

A stable test could record a baseline cohort, observation window and traffic method at the start of the plan. It could then report two separate values: how much of the operator's access surface is IPv6-capable, and how much traffic or customer activity actually uses IPv6. The first is closer to operator control. The second is an outcome influenced by devices, customer policy, applications and external content.

Availability, activation and use are different facts

The proposal's enforcement logic risks compressing several stages into one number. An operator can allocate IPv6 prefixes, configure routing, provide router advertisements or DHCPv6, support DNS and train its help desk. A wholesale access provider may still lack IPv6 support. A business customer may disable it. An external destination may not publish AAAA records or accept IPv6 traffic. A user's device may prefer IPv4.

Saul Stein's archived 30 June comment made the commercial version of this point. He supported better uptake but argued that business customers control their own security and addressing policies, while fibre-network support can also sit outside the ISP's control. He warned that the proposed approach could load additional manual work and cost onto smaller operators. Those are attributed views, not measured cost findings, but they match the control-boundary problem in the text.

Good compliance evidence would keep at least three columns. Readiness asks whether the operator has built and documented the IPv6 service. Availability asks whether an eligible customer or hosted service can use it. Adoption records whether customers, applications and traffic actually do so. A policy can reasonably demand readiness and truthful availability from the requester. It should be more careful when attaching sanctions to adoption outcomes controlled by several parties.

AFRINIC staff identified the same unresolved mechanics

AFRINIC's impact assessment, dated 20 June, does not dismiss the proposal's aim. It says the draft could promote concrete deployment rather than passive IPv6 holdings. But it also records substantial ambiguity: the standard for a “coherent” plan is undefined; the method for identifying and validating top-25 destinations is unspecified; and the evidence for compliance, partial compliance or justified delay is not stated.

Staff also noted an interaction with existing CPM section 6.4.4, which already allows present IPv4 customer bases to support justification for larger IPv6 requests during transition. The assessment recommended putting deployment-compliance detail in the IPv6 sections of the policy manual instead of introducing it indirectly through IPv4 soft landing. That would align the obligation with the resource and evidence it governs.

The operational footprint would not be small. Staff anticipated changes to MyAFRINIC, Hostmaster and member workflows, transfer tooling, new-member registration, billing integration, evaluation procedures and internal notifications. It also expected training needs and possibly additional staffing. This is another reason to define the evidence contract before attaching a violation label.

No consensus is a current state, not a final verdict

The chronology is short and clear: draft 1 was posted on 22 May 2026, draft 2 was submitted on 14 June, the staff assessment followed on 20 June, and AFRINIC 37 reached no consensus on 24 June.

AFRINIC 37 minutes record extensive discussion of smaller operators, implementation cost and alternative grace periods. The co-chairs concluded that the authors had not addressed all concerns, that consensus had not been reached and that the proposal should return to the mailing list. AFRINIC's current index still labels draft 2 Under Discussion.

Those two records are consistent. The meeting decision did not adopt the text, but it also did not end the policy work or prove final rejection on the merits. A later draft could keep the IPv6 incentive while replacing the moving denominator, defining evidence and introducing proportional treatment for justified delays.

The next version should answer five mechanical questions. Who fixes the baseline? Which observation period applies? What evidence proves readiness and reachability? Which dependencies are outside the requester’s control? What notice, cure, appeal and proportional remedy applies when a target is missed? Without those answers, the same percentage can describe infrastructure failure, customer choice or success that moved traffic off IPv4.

Preserve the incentive; narrow the judgement

AFRINIC does not need to choose between demanding IPv6 progress and recognising operational reality. It can require applicants to build a documented IPv6 service, make it available across a defined customer or hosting surface, keep measurement evidence and report outcomes. It can separately monitor actual adoption without automatically treating every shortfall as the applicant's violation.

The durable control is attribution. Scarce IPv4 access gives the rule real economic force, so the evidence must show what the requester could decide, build and verify. Customer activation and external content support still matter, but they belong in the outcome ledger, not silently inside the same enforcement score.

Sources