Summary

  • On 9 May 2018, discussion at AFRINIC-28 produced a concrete correction to Draft 1: the author agreed to remove a condition that would have required the allocated block to be announced within twelve months with the minimum possible disaggregation. Draft 2, published on 11 May, omitted that routing gate while retaining a twelve-month plan for /48 assignments.
  • Draft 2 kept /32 as the minimum initial allocation, but let an LIR justify a larger block through evidence about client space, user numbers, infrastructure, hierarchy or geography, security or other segmentation, and the expected longevity of the allocation. It also recognised services to end users and to self-owned or related departments, entities and sites.
  • An organisation whose first allocation no longer fitted deployment reality could, once, submit a new addressing plan without first meeting the usual utilisation threshold for a subsequent allocation. Depending on adjacency and inventory, the result could be an extension, a larger replacement followed by return of the old prefix within six months, or a complementary prefix.
  • The benign case is strong: a mechanically assigned /32 can be a poor architectural fit, and a correctly sized aggregate may reduce fragmentation and future renumbering. The change acknowledged that forecasts fail and that routing practice should not be an entry condition.
  • Yet the public record supplies no applicant-level or anonymised outcome data showing how the planning factors were interpreted. A useful private intake rule needs published definitions, repeatable evidence, written reasons and factual review. AFRINIC could decide access to previously unallocated inventory; it had no sovereign or regulatory authority over an operator’s network or existing resources.

Within two days in May 2018, a proposal about entry to the IPv6 allocation registry acquired its decisive form. Draft 1 had been posted on 28 March. At AFRINIC-28 in Dakar on 9 May, a participant asked for the proposed routing-announcement requirement to be removed, and the author agreed. Draft 2 appeared on 11 May without that requirement. It retained an LIR eligibility gate, a minimum initial allocation of /32, and a requirement for a reasonable plan to make /48 assignments to end sites in the AFRINIC region within twelve months. It also widened the eligible service model beyond connectivity for other organisations, allowing services to end users and to self-owned or related departments, entities and sites.

The draft mattered because an operator seeking more than /32 now had to turn the intended architecture into evidence. Client address space, user count, infrastructure extent, hierarchy or geography, security or other segmentation, and expected longevity could support a larger allocation. If the initial forecast later failed, a one-time rectification route could avoid the ordinary subsequent-allocation utilisation threshold. But correction could still mean renumbering, a second prefix, or reliance on adjacent inventory. The Board ratified the text on 8 August; AFRINIC implemented it on 23 November. For an operator, this was not address arithmetic in the abstract. It was a decision about whether a network could begin with a coherent aggregate, how much commercial and technical detail had to be disclosed, and who bore the cost when forecast and reality diverged.

L3 — The two-day redline after Dakar

The most revealing way to read Draft 2 is as a redline at the registry door. It did not decide how IPv6 should work globally. It did not alter the routing system, guarantee that any prefix would be visible everywhere, or establish how many customers a block could support. It revised the terms on which AFRINIC, acting as a private allocation service, would accept an LIR into one part of its IPv6 registry process and decide the initial size recorded for that applicant. That narrower description is not pedantry. It separates a consequential service rule from the mythology that can gather around technical institutions.

Before the proposal, the relevant eligibility language required an applicant to be an LIR, not be an end site, provide a detailed plan for IPv6 connectivity to organisations in the AFRINIC region, and show a reasonable plan for /48 assignments to end sites in the region within twelve months. That wording carried a recognisable picture of an LIR: an intermediary handing connectivity to other organisations. The problem identified by Draft 2 was that actual organisational structures do not always follow that picture. A network may be operated centrally while serving its own departments, related entities, remote facilities or end users. A formal boundary between “the applicant” and “the organisations it connects” can therefore be a poor proxy for the operational boundaries visible in an addressing plan.

Draft 2 retained the requirement that the applicant be an LIR, but broadened the activity that could satisfy the service test. The applicant could plan to provide IPv6 connectivity or services to other organisations or end users, and it could include self-owned or related departments, entities and sites in the AFRINIC region. The significance was practical. The text no longer insisted that an applicant’s legitimate plan be described only as service to an external organisation. It allowed the registry record to follow a network whose administrative, corporate and technical contours did not collapse into the old end-site exclusion.

That change should not be inflated. It did not erase the LIR gate, and the public record does not establish how many organisations entered because of the widened wording. It did not convert every internal network into an eligible applicant or prove that implementation became effortless. It did, however, remove an obvious mismatch between a thin institutional category and the variety of networks an LIR might actually operate. Where a registry must classify an application, choosing language capable of describing reality is an improvement.

The second change concerned size. Draft 2 kept /32 as the minimum initial allocation. That is a policy default, not a finding about the inherent adequacy of /32 for every network. Prefix notation describes the length of the network prefix; comparing the numerical address space beneath two prefixes says nothing by itself about customer capacity, traffic, business viability, active use or the correctness of a deployment. An apparently capacious block in raw arithmetic may still fit badly if the operator’s allocation hierarchy, geography, security boundaries or expected lifetime require a different top-level structure.

Draft 2 therefore made documentation the bridge from the /32 minimum to a larger initial block. Its proposed factors were client address space, number of users, extent of infrastructure, hierarchical or geographic structure, security or other segmentation, and the anticipated longevity of the initial allocation. These are not absurd considerations. They map to real design questions. A network divided across regions may need a plan that delegates cleanly. A hierarchy of operating units may need room at several levels. Security zones can require separation that is meaningful operationally even when it is not captured by a simple user count. A long-lived allocation should leave room for credible growth because renumbering a mature network is not a costless clerical exercise.

The twelve-month /48 plan remained part of entry. It asked the applicant to show a reasonable plan for assignments to end sites in the AFRINIC region within the following year. The important distinction is between that assignment plan and the routing-announcement condition that disappeared. An address plan tells the registry how the applicant expects to structure assignments. A routing announcement is an operational act in the interdomain routing system. The two may be related in a particular deployment, but they are not the same obligation and should not be treated as though one inevitably proves the other.

Draft 1, published on 28 March, had proposed an additional criterion: the allocated block would have to be announced within twelve months with the minimum possible disaggregation. At the 9 May AFRINIC-28 meeting, a participant asked for that requirement to be removed. The author agreed. Draft 2, published two days later, omitted it. This was more than tidy drafting. As a bounded inference from the deletion, participants distinguished qualification for an allocation from a prescribed routing practice. The registry had a reason to assess whether the request described a plausible deployment.

It did not need to turn one announcement pattern and deadline into the price of entry.

The official minutes also record a suggestion that allocations should align on a nibble boundary. The author declined to add that feature to this proposal, explaining that doing so would make it more complex, while staff said that some such cases were already handled operationally and welcomed policy text. The episode matters here chiefly as a boundary around Draft 2. The proposal was not an attempt to codify every possible design preference. It addressed eligibility, initial sizing, subsequent sizing factors and a correction path, while leaving this further issue outside its text.

At the close of the discussion, the co-chairs recorded strong support, no opposition, an agreement to update the text and advancement to last call. Those statements prove what happened in the private policy-development process. They do not turn the result into legislation. “Consensus” records a procedural conclusion by private process chairs; it does not confer a public mandate over networks, customers or assets. Nor does the later Board action change that character. On 8 August, the Board adopted Resolution 201808.447, recording that the proposal had passed the PDP, reached consensus and been referred by the co-chairs.

That was a corporate ratification of an allocation-service rule, not the birth of a regulator.

The third substantive change was the rectification route. Draft 2 acknowledged that an initial addressing plan can stop matching deployment needs. Under new clause 6.5.1.3, an organisation could submit a new plan without first satisfying the ordinary utilisation threshold that otherwise governed access to a subsequent allocation. This exception matters because a strict rule that demanded high use of a poorly sized first block could trap an operator between two bad choices: distort the network to consume the old allocation, or accept fragmentation while it waited to qualify through ordinary utilisation.

Rectification was not an unlimited reset. Each organisation could use the procedure only once. The available result depended on registry inventory and whether adjacent space existed. If adjacency and stock permitted, AFRINIC could extend the original prefix. If that was not available, the applicant could receive a new, larger prefix and return the original no later than six months after completing renumbering. Alternatively, it could receive a complementary prefix, with the two blocks treated together for later allocation purposes. These branches reveal both the value and the limits of the correction valve.

Extension would ordinarily be the cleanest of the stated outcomes because it could preserve the original space inside a larger aggregate. But the text could not promise adjacency: previously unallocated inventory is finite in its arrangement even when the protocol’s total address space is large. Replacement offered a larger block at the price of renumbering and a six-month return obligation after that process. A complementary prefix avoided forced replacement of the original but left the operator managing more than one block. Draft 2 did not abolish the consequences of a sizing mistake; it created a controlled way to choose among them.

Renumbering deserves to be treated as an operational project rather than a line in an allocation policy. Addresses appear in configurations, customer change procedures, security rules, monitoring systems, documentation and reverse DNS. Moving them creates coordination work and a risk of human error. The proposal’s own rectification structure implicitly acknowledges that the first forecast can be wrong and that ordinary utilisation sequencing may impose avoidable costs. It would be unsupported to claim a quantified saving, however.

The public record supplies no measure of how many renumbering exercises the rule prevented, how many replacement prefixes were issued, or how frequently a complementary allocation was selected.

The planning factors also carried into the rule for the size of subsequent allocations. That continuity makes internal sense: if geography, hierarchy, segmentation and longevity describe the architecture at the beginning, they do not cease to matter when the network grows. But it also extended the reach of interpretive judgement. A factor list can improve the conversation between applicant and evaluator while still leaving open what counts as enough proof, how conflicting indicators are weighed, and how uncertain growth should be represented.

Implementation completed the chronology but not the evaluation. AFRINIC reported that the proposal took effect on 23 November 2018 in version 1.3 of the Consolidated Policy Manual, amending sections 6.5.1.1, 6.5.1.2, 6.5.1.3 and 6.5.2.3. A 29 November implementation notice identified those sections, and the AFRINIC-29 report described the policy as active. The archived Draft 2 page’s stale status language cannot override that later official record. Equally, implementation proves only that the text entered the operating manual.

It does not prove that larger allocations were granted consistently, that rectification was prompt, or that IPv6 deployment improved because of the change.

The strongest benign case for Draft 2 can therefore be stated without reserve. A rigid /32 default could underfit a large or structurally complicated deployment. Geography, hierarchy, security segmentation and infrastructure extent are genuine design considerations. Recognising self-owned and related sites corrected a service-provider model that could exclude legitimate operational reality. A suitably sized aggregate may reduce fragmentation and the chance of later renumbering. The one-time correction procedure acknowledged uncertainty rather than pretending a twelve-month plan could foresee an allocation’s entire life. Removing the routing-announcement gate kept an operational choice from becoming an intake condition. On its face, this was a serious attempt to make the registry more useful.

That fair account is essential because the problem is not that AFRINIC considered evidence. A uniqueness coordinator cannot distribute the same unallocated number space twice, and a private allocation service needs criteria for deciding what part of its available inventory to register to an applicant. Documentation can protect consistency, distinguish a reasoned plan from an arbitrary request and help select an aggregate that fits the described architecture. The problem begins when useful evidence is left sufficiently elastic that the evaluator’s preferred network model can decide the case without transparent constraint.