Summary

  • AFPUB-2026-v6-001-DRAFT02 would make every initial or additional IPv4 request during AFRINIC’s Soft Landing depend on an IPv6 holding or simultaneous request, a deployment plan, and later traffic or hosting results. Its milestones reach 75% of qualifying traffic and 95% of hosted-service records by month 48.
  • The decisive defect is one of mandate, not drafting polish. AFRINIC may ration a remaining pool through narrow, prospective and objective application criteria. It may not punish an operator’s architecture choice, especially through outcomes affected by customers, upstreams, vendors and external content networks.
  • The draft calls a missed plan a policy violation without defining the denominator, evidence source, dependency relief, partial-compliance rule, cure, consequence or review standard. A valid scarce-pool condition must stay inside the applicant’s controlled surface and must never spill into existing resources or interrupt a running network.

On 14 June 2026, Jordi Palet Martinez of The IPv6 Company submitted the second version of an AFRINIC proposal with a deceptively simple premise: if an operator asks for scarce IPv4, make the operator demonstrate progress on IPv6. Draft 2 would apply to every initial or additional IPv4 request during exhaustion. An applicant without IPv6 space would have to request it at the same time, meet the relevant IPv6 criteria and present what the text calls a coherent deployment and addressing plan. The commitment would not end at paperwork.

A traffic-carrying network would have to meet IPv6 percentages for external destinations in its actual IPv4 top 25; a network hosting services, applications or content would have to meet rising targets for AAAA availability and Internet reachability. Failure against the plan would be a policy violation.

That final step is why the draft matters beyond a dispute over measurement vocabulary. The traffic milestones are 25% after 12 months, 50% after 24 and 75% after 48. The hosting milestones are 25%, 75% and 95% on the same timetable. Yet the proposal does not say what the traffic percentage counts, what a top-25 destination is, which evidence proves compliance, how an external dependency is separated from an applicant’s own conduct, or what happens after a miss. AFRINIC staff itself identified many of these gaps and warned of disproportionate effects on smaller operators and WISPs.

At AFRINIC-37 on 24 June, the objections remained unresolved; the chairs found no consensus and sent the proposal back to the mailing list. It remained under discussion at the 9 August evidence cutoff.

Readers should keep going because this is not a referendum on whether IPv6 works or whether deployment is desirable. It is a test of institutional boundaries. AFRINIC is a bookkeeper for unique number resources: it may maintain accurate records, require proof, give notice, permit correction and preserve operational continuity. It is not a sovereign with a mandate to choose an operator’s architecture.

If a missed traffic ratio can become a policy violation merely because an applicant requested IPv4, an allocation desk has become an architecture regulator without acquiring the authority, proof rules or independent review that such power would require.

What the draft would actually require

The amendment is aimed at section 5.4.4 of the Consolidated Policy Manual, which presently places no explicit limit on the number of additional requests an LIR or End User may make during exhaustion. Phase 2 already limits requests to between a /24 and a /22, looks over an eight-month needs horizon and, for additional IPv4, uses a 90% prior-utilisation rule. Those are scarce-pool rationing criteria.

Draft 2 would add a different kind of condition. An applicant without IPv6 would make a simultaneous request; an existing or simultaneous holder would satisfy the relevant allocation or assignment criteria. The cited criteria include a 12-month deployment or announcement horizon and baseline minimums of a /32 for an LIR and a /48 per End User site. One /32 contains 65,536 /48 units as address-plan scale, not proof of use or customer count.

Third, the applicant would submit a coherent IPv6 deployment and addressing plan. Fourth, if the network carries traffic, it would disclose its actual IPv4 top-25 traffic destinations and reach the required IPv6 percentages for those external destinations that are IPv6-enabled. Fifth, if it hosts services, applications or content, it would meet the separate AAAA-and-reachability milestones. Sixth, a failure against that plan would be treated as a policy violation.

This sequence mixes three distinct things. Holding or simultaneously requesting an IPv6 resource is a registry fact. Submitting a plan is applicant-supplied evidence at the application boundary. Achieving a traffic share or externally observed service result years later is an operating outcome. The first two can be framed as prospective conditions for a new allocation. The third reaches into how a network is run after the registry transaction and makes future eligibility turn on the behaviour of systems and counterparties that the applicant may not control.

The immediate scope is narrower than an audit of every holder: the text, author and staff all place the trigger at a new or additional IPv4 request. Yet staff reads an additional request from an existing IPv6 holder as triggering retrospective review of that holder’s IPv6 need and use. The drafting record is also inconsistent: the normative text names section 5.4.4, while the impact metadata lists several section 6 provisions but omits 5.4.4. The evidence does not establish which list is wrong.

A criterion becomes a mandate when the registry judges outcomes

A registry may set objective terms for distributing a resource that remains in its own unallocated pool. That administrative power is narrow. It exists because simultaneous claims to a finite pool need a queue discipline and because the ledger must not assign the same resource twice. It does not create an open-ended right to prescribe network design. Scarcity makes accurate bookkeeping more important; it does not transform a clerk into a landlord, a regulator or a sovereign.

The boundary is practical. A valid registry criterion asks for facts needed to decide the transaction in front of it: identity, proof of control, uniqueness, accurate registry data, demonstrated facts about the current request and evidence that the applicant itself can produce. A mandate tells the applicant what architecture it must operate, turns a later commercial or engineering choice into compliance status, and connects non-adoption to institutional punishment. Draft 2 crosses that boundary when it conditions IPv4 on multi-year IPv6 outcomes and labels a miss a violation.

The distinction survives even if every percentage is clarified. Suppose the draft defined traffic as bytes, fixed an observation window and identified a flow-data format. It would still be making an applicant’s right to seek IPv4 depend on the proportion of traffic that travels over a different protocol. Suppose it defined the hosted-service inventory and the reachability vantage points precisely. It would still be converting application architecture, DNS configuration and Internet reachability into registry compliance. Better measurement could make the command more consistent. It could not supply AFRINIC with a mandate to issue the command.

A dormant IPv6 allocation may disappoint transition advocates, but disappointment is not a registry invariant. Uniqueness, accurate records, proof of control, security assertions, auditable state changes and continuity are legitimate common concerns. Traffic share and hosted-service reachability are operator choices shaped by equipment, customers, contracts, applications and risk. By turning those choices into future standing, Draft 2 converts an application screen into continuing supervision: collect telemetry, classify destinations, preserve evidence, track milestones and explain misses.

A request for an operationally important input supplies the leverage; it does not legitimise the command.

The top 25 is not a metric until its objects are known

The traffic condition illustrates why the mandate is not self-executing. Draft 2 refers to an applicant’s actual IPv4 top-25 traffic destinations and percentages for the external destinations that are IPv6-enabled. It does not define destination. That could mean an IP address, a prefix, an ASN, a domain, a service, a content provider or another aggregation. Each choice produces a different list. Dynamic addressing, content distribution and multiple paths make the classification consequential. A rule that does not identify its objects cannot generate a stable result.

The denominator is equally unknown. The percentage might count bytes, packets, flows, sessions, users or destinations. The published draft and deliberative record leave that question open. A network can satisfy one denominator and miss another without changing a single packet. A few high-volume destinations could dominate bytes while many smaller destinations dominate a count of endpoints. A session-based view could produce another picture. Until the denominator is selected, 25%, 50% and 75% are numbers without a determinate proposition beneath them.

There is no observation interval, sampling method, minimum sample size, validation process, correction rule or acceptable proof. AFRINIC-37 discussion mentioned NetFlow or other tools, but participants warned that not every operator has NetFlow and that targets can invite manipulation. Nor does the draft say who establishes whether an external destination is IPv6-enabled, when or from which vantage point. Content networks, upstreams, customer devices and vendors can alter the result.

If the evidence depends on tools an applicant cannot afford or on parties it cannot command, the rule allocates policy risk by capacity and circumstance rather than controlled conduct.

The hosting condition has the same defects in another form. It asks for the share of AAAA records that are available and Internet-reachable over IPv6. But the draft does not define the inventory being counted, the protocols tested, the vantage points used, or the treatment of aliases, anycast, multiple addresses and partial reachability. A percentage cannot be translated into a service count without a defined inventory. “Internet-reachable” sounds objective until one asks whose Internet view supplies the answer and how temporary failures are handled.

There is also a data-governance question. A top-destination list and supporting flows may expose customer mix, content concentration, transit patterns or commercial dependencies. That is an inference from the evidence the draft seeks, not a report of any breach. Yet neither the draft nor the published staff assessment specifies minimisation, aggregation, retention, access or confidentiality controls. A registry that demands commercially sensitive evidence must at least specify why each field is necessary, who may see it, how long it is kept and how an applicant challenges an erroneous interpretation. Draft 2 does none of that.

Regional capability cannot prove applicant compliance

The proposal’s problem statement uses APNIC Labs data to describe an adoption gap. It gives rounded figures of 44% IPv6 capability worldwide and 6% in Africa. The sealed audit found that APNIC’s region series for 14 June 2026 reported raw capability of 43.822740% for the world and 5.869934% for Africa. Ordinary rounding reproduces the proposal’s headline. Ten-day, 30-day and 90-day series around that date also round in ways that leave the headline broadly plausible.

That reproducibility does not solve the sourcing gap. Draft 2 does not disclose 14 June as the observation date and does not state whether it used raw data or a 10-day, 30-day, 60-day or 90-day smoothing window. It also gives country buckets—8 countries above 20%, 15 between 10% and 19%, and 15 below 1%—without a dated country list, defined universe or exact query. Those bucket claims cannot be audited from the cited prose alone. A current map cannot be substituted for the missing historical parameters.

More important, APNIC’s metric does not measure what the policy would enforce. “IPv6 capable” is the share of sampled, weighted endpoints that can fetch an IPv6-only test object in an advertisement-based experiment. It is not the share of allocated IPv6 space, the number of networks holding IPv6, the number of configured networks, or the share of all Internet bytes or packets carried over IPv6. It is a population-level capability measure, not an applicant-level record of controlled effort.

A regional measurement can show an observed gap. It cannot identify which operator controls it, what equipment blocks a connection or whether an upstream or destination is responsible. Population evidence is useful context, not a proof chain for an applicant violation. Even a perfectly reproduced statistic answers how much capability APNIC observes, not what AFRINIC may command. Urgency is not authority.

The undefined violation is more serious than an undefined target

Draft 2’s sharpest phrase is “policy violation”. That label is not self-contained. It matters because AFRINIC’s Registration Service Agreement binds members to adopted policy and provides mechanisms for information requests, utilisation review and breach. The RSA says that failure to cooperate with certain reviews may lead to withholding, revocation, future-allocation consequences, LIR closure or termination. It also supplies process around termination for breach: written particulars, an invitation to show cause or cure, a 30-day response period and evidence of remedial action.

Its published appeal clause provides a further route in the contractual framework.

None of that means Draft 2 would automatically revoke resources. The evidence does not establish automatic revocation, and the consequence of a missed milestone is expressly unknown. The miss might affect only a pending IPv4 request. It might trigger a compliance investigation. It might lead to another response. The draft does not say. It also does not identify which appeal route, review standard, evidentiary record or interim treatment would apply to a disputed top-25 or hosting finding.

The RSA cannot supply definition later. The policy defines the alleged wrong; the contract provides general remedies. A notice cannot cure the absence of a denominator, proof protocol, controlled-surface rule or exception logic. Staff forecasts changes to MyAFRINIC, possible NetSuite integration changes and the number-resource process, but none to WHOIS, RDAP or RPKI. It anticipates Hostmaster training, possible recruitment and about six months for implementation after ratification, yet gives no cost estimate. The legal assessment is only “No legal issue”, and no contractual update is identified.

That sentence proves only what the institution wrote. It is not a reasoned analysis of the bridge from a multi-year architecture outcome to an RSA remedy. It does not reveal whether proof, confidentiality, reliance, cure, appeal or external dependency was considered. The staff assessment deserves weight as an account of expected operations and of staff’s own concerns. It does not confer legitimacy on power that falls outside the registry’s mandate.

This is also why the formal policy path matters without becoming a theory of sovereignty. At the cutoff, the proposal had not reached rough consensus, Last Call or Board ratification. The Policy Development Working Group can deliberate. Co-chairs can assess rough consensus. The Board has a ratification role under the published process. Staff can assess implementation. None of these steps turns a meeting room into a legislature or grants AFRINIC sovereign authority over operator architecture. Official material proves what the institution says, does and writes.

It does not prove that the institution owns the community, the region or the operating choices of every resource holder.

The cost lands where control is weakest

The draft does not quantify what compliance would cost, so no responsible analysis can invent a price. It does identify the components. Operators may need flow collection, retention, DNS inventory, reachability testing, plan preparation and evidence responses. AFRINIC may need linked application handling, retrospective review, reminders, audit trails, training and possible recruitment. Applicants may need to address CPE, upstream, hosting, DNS and application dependencies. A genuine IPv4 need may remain unmet while the applicant obtains IPv6, proves eligibility, resolves telemetry questions or disputes a miss.

These burdens are regressive because much of the overhead is fixed. A small WISP still needs a plan, measurement method and evidence response; a Hostmaster still needs review time. A large operator can spread the work across a wider base and may already have the tools. AFRINIC staff warned that device compatibility, commercial realities and technical readiness could make the impact disproportionate for smaller operators, including WISPs.

The public discussion supplied concrete versions of that concern. Dorothy Kwamboka argued that the proposal moved AFRINIC from resource coordination towards a migration mandate and shifted cost and complexity towards emerging-market operators. At AFRINIC-37, Saul Stein, Paul Hjul and Seun Ojedeji raised customer control, absent flow tooling, measurement manipulation and a possible grace period for early requests. After the meeting, Ben Roberts described a rural-startup case in which a new network connecting schools might lack traffic-analysis tools and already face substantial entry barriers.

These are attributed positions, not measured universal outcomes. They matter because they reveal exactly where an apparently equal percentage rule meets unequal capacity.

The proposal author disputed the cost case. He argued on the mailing list that IPv6 transition could reduce capital and operating expenditure relative to CGNAT, and at the meeting said 464XLAT could be cheaper and smaller networks easier to migrate. That is the strongest operational response to the burden objection. It is plausible that some networks will find a translated or IPv6-led architecture less expensive than expanding IPv4 workarounds. Draft 2, however, contains no cost study that resolves the comparison across operator types. The policy cannot convert one participant’s forecast into a violation standard.

The measured outcome may depend on customers, upstreams, content networks, vendors and application owners. Charging all of this to the IPv4 applicant makes one party carry the consequence while another controls the cause. It also encourages optimisation of the percentage rather than resilience—an incentive AFRINIC-37 participants raised directly. A policy should not create a game and leave its scoring rules unwritten.

The strongest case for linkage—and why it still fails

The proposal deserves its strongest defence, because scarce-pool administration is not the same as arbitrary punishment. AFRINIC is rationing the last general IPv4 supply under Soft Landing. An applicant asking for that benefit can reasonably be required to meet prospective, objective conditions. The current manual already tests need and prior utilisation for additional IPv4, and its IPv6 criteria already contemplate deployment or announcement within 12 months. The draft does not immediately audit holders that make no new request. It gives 12, 24 and 48 months rather than demanding an overnight change.

Its supporters want actual deployment, not a dormant allocation and a symbolic announcement.

There is also a bounded comparator. ARIN’s NRPM 4.10 reserves a dedicated /10 and issues a /24 for immediate IPv6-deployment needs. A registry can thus link specially reserved IPv4 to a specific IPv6 purpose. On the strongest account, the applicant receives a dwindling resource while undertaking work that may reduce later dependence on transfers or CGNAT.

That case supports a narrow application condition. It does not support Draft 2. ARIN’s comparator is a dedicated pool with /24 awards for immediate IPv6 needs; it is not a four-year performance obligation attached to every ordinary Soft Landing request. The existence of a 12-month plan criterion does not authorise AFRINIC to police the resulting traffic mix. Prospective timing does not cure an undefined denominator. A request trigger does not bring customer equipment and external destinations under applicant control. And an asserted benefit does not create a punitive mandate.

The distinction can be put plainly. AFRINIC may say: this remaining pool is available only to applicants that already hold or simultaneously request IPv6 and can show a credible, dated readiness plan using evidence they control. It may verify those facts before issuing new IPv4. It may deny the new request if the objective application criteria are not met, after written reasons and a fair correction opportunity. It may not say: because you accepted IPv4, we will judge the future percentage of your traffic, call a miss a violation and leave the consequence to an unspecified bridge into the RSA.

Nor may it use the new application as leverage over existing resources. A narrow condition can govern the incremental allocation being sought. It cannot retroactively change the status, service continuity or security treatment of resources already embedded in a running network. Existing IPv4 or IPv6 should not become collateral for a disagreement about a new request. Operational continuity is not a discretionary reward. The registry must preserve accurate records and running services while the application, correction or review is resolved.

This conclusion is not false balance. IPv6 deployment may be useful. Actual readiness may be more informative than passive holding. Some applicants may benefit economically from accelerating it. None of those propositions gives AFRINIC authority to punish architecture choice. The strongest defence therefore fails at the exact point where the draft moves from a transaction-specific eligibility rule to continuing supervision and violation.

A legitimate condition would be narrower by design

The correct response is not to repair the percentages and retain the mandate. It is to redraw the boundary of the rule.

A permissible scarce-pool condition would be prospective. It would apply only to the new IPv4 request and would be published before an applicant relies on it. It could require an existing IPv6 holding or simultaneous request and a coherent plan, provided “coherent” is replaced with objective elements. Those elements would concern assets, services and evidence within the applicant’s control. The policy could request an address plan, a documented architecture choice, a dated implementation schedule and proof that the applicant has taken defined preparatory steps.

It could accept equivalent readiness paths, including dual stack, an IPv6-led design with translation, customer-prefix enablement, service inventory or other technically documented approaches, without elevating one architecture into moral compliance.

An evidence schedule fixed before enforcement would say what may be requested, why it bears on the pending allocation, how information is minimised, who may access it, how long it is retained and how inaccuracies are corrected. If aggregate or less intrusive evidence establishes the relevant fact, AFRINIC has no mandate to demand granular traffic intelligence.

Most importantly, the rule would stop at applicant-controlled evidence. Outcomes caused by upstreams, customer devices, external destinations, content providers or procurement outside the applicant’s control would not become violations. If AFRINIC retained numerical milestones at all, they could only be non-punitive safe harbours or information for a later implementation review; they could not establish misconduct. A safe harbour may reduce proof for an applicant that meets it. It may not condemn an applicant that does not.

Any adverse finding would require written reasons identifying the criterion, the evidence, the controlled act the applicant failed to perform and the correction available. The applicant would receive notice, access to the evidence relied upon and a meaningful cure period. A named independent reviewer would examine the same defined record under a published standard. During review, the last verified registry state and all existing resources would remain operationally intact.

The maximum direct consequence of failing an application condition would be a decision on the incremental request, not punishment of an architecture and not impairment of existing resources.

AFRINIC could then publish aggregate results after 12 and 24 months without exposing member traffic intelligence: numbers of applicants, operator-size bands, evidence methods, correction and review outcomes, and observed change. Such reporting would show whether the condition affected deployment rather than assuming causality from a regional average. It would also expose whether a nominally equal rule systematically delays one class of applicant.

This design would be longer than a slogan and less satisfying to those who want a bright transition command. That is a virtue. The more consequential a registry condition becomes, the more narrowly it must be tied to the act the registry is entitled to perform. Proof, notice, correction, continuity and independent review are not ornamental safeguards. They are the difference between a bookkeeper deciding a new application and an institution governing a network.

No consensus was the correct result

Draft 1 was posted on 22 May and announced on 28 May. Discussion immediately asked how actual deployment would be distinguished from holding or announcing IPv6. The author then defended the 25%, 50% and 75% traffic milestones and said a breach could engage RSA terms. Draft 2 arrived on 14 June with top-25 traffic, hosting thresholds and the violation label; staff assessed it on 20 June and AFRINIC announced it on 22 June. At the 24 June meeting, customer control, flow tooling, manipulation and grace remained unresolved. The chairs found no consensus.

Post-meeting discussion on 8 July preserved both the rural-startup objection and the author’s insistence that IPv6 and basic monitoring should not be optional.

No consensus was therefore not a failure to choose between innovation and delay. It was recognition that the proposal had not established either a determinate rule or a legitimate institutional boundary. By 9 August, the current-proposals index still listed Draft 2 as under discussion. It may be revised, withdrawn or replaced; the evidence supplies no basis for predicting the outcome.

The test for the next version is not whether every missing noun receives a definition. It is whether the violation architecture disappears. A revision that defines bytes, destinations and reachability but continues to punish a network for failing a prescribed protocol outcome would remain outside AFRINIC’s mandate. A revision that confines itself to a narrow, prospective and objective condition on the incremental scarce-pool request—supported by applicant-controlled evidence, written reasons, correction, continuity and independent review—would return the institution to bookkeeping.

AFRINIC can encourage. It can publish measurements. It can explain application paths and make registry data accurate. It can offer education and record a simultaneous IPv6 request. It can administer the dwindling pool according to clear criteria. It cannot turn a preferred architecture into a condition of institutional obedience.