Summary

  • AFPUB-2018-V6-001-DRAFT01 corrected an obsolete technical reference, removed the old single-device /128 recommendation, redefined utilisation by prefixes assigned, repaired an internal cross-reference and deleted a stale multiple-/48 review provision. It was not the separate V6-002 sub-assignments proposal.
  • These were narrow changes, but not inconsequential ones. A registry manual influences network planning, justification, evidence requests and the cost of later renumbering. An error in that manual can therefore change behaviour even when staff describes the correction as having no operational impact.
  • The best reading of the episode is also the most restrained: public redlines and technical correction are useful private bookkeeping. AFRINIC remains only a private technical bookkeeper and coordinator, with no sovereign, regulatory, police, punitive, confiscatory or adjudicative authority.
  • Future corrections should carry an inspectable chain of responsibility: a dependency register, a visible before-and-after delta, interpretation records, a dated implementation receipt and a scope firewall preventing maintenance from becoming an excuse for authority inflation.

L3 — The obsolete reference hidden inside the rulebook

In March 2018, the IPv6 section of AFRINIC’s Consolidated Policy Manual contained a small time capsule. It still referred readers to RFC 3177, a document published in 2001. The old text carried a compact assignment formula: a /48 in the general case, a /64 where a single subnet was known to be sufficient, and a /128 where a single device was known to be sufficient. That formula had the appeal of administrative neatness. It could be copied into a manual, applied by category and remembered without much difficulty. Yet its simplicity concealed the fact that IPv6 end-site design is not reducible to one timeless allocation table.

RFC 6177 had already obsoleted RFC 3177 in March 2011. It rejected the idea that every end site should receive the same default /48, but it also warned against reducing an end site to only a /128. The exact size was to remain a matter of operational judgement within the relevant architectural guidance. By the time AFRINIC’s correction was proposed, the manual’s cited foundation had therefore been out of date for seven years. The problem was not that every recommendation associated with the older document had suddenly become technically absurd.

The problem was that the manual presented a superseded source and its fixed categories as if they remained the current basis for action.

That distinction matters. An obsolete reference is not evidence of a malicious rule, nor does the sealed record establish negligence, deception or an actual injury. Manuals age for ordinary reasons: inherited wording survives a consolidation, external documents change, internal numbering moves, and familiar phrases cease to attract attention. But benign origins do not make the error immaterial. Once a manual is the common working surface between a private registry and its members, stale wording can organise conduct. A member may design a request around it.

A member’s engineer may interpret it as a signal about an acceptable customer assignment. Staff may use it to frame a question. Lawyers or managers may treat the wording as an account of the service. A reference can be obsolete without being harmless.

The corrective instrument was submitted by Jordi Palet Martinez on 11 March 2018, and its revision history records the first draft being posted to the rpd list on 14 March. Its proved identifier is AFPUB-2018-V6-001-DRAFT01. That precision is worth preserving because V6-002 denoted a different proposal, concerning IPv6 sub-assignments. Confusing the two would defeat the very lesson at issue: identifiers, references and version history are not decorative matter in a system whose users must be able to establish which text changed and why. The catalogue mismatch deserves correction, not elevation into a separate controversy.

The proposal described its purpose as clarification and error correction after IPv6 deployment and earlier policy changes had left inconsistencies and wrong references in the manual. Its method was unusually helpful. Instead of offering only a clean replacement whose changes readers would have to reconstruct, it displayed current and proposed wording. That visible delta allowed a member to ask a more exact question than “is the new version better?” The reader could see which noun changed, which recommendation disappeared, which definition moved and which procedural burden was withdrawn.

The first change was both terminological and technical. In section 6.0, “ISP” became “LIR”, aligning the rulebook’s description with the registry relationship it was addressing. The proposal retained /48 and /64 examples, but removed the recommendation of a /128 for a known single device. It replaced the reference to RFC 3177 with RFC 6177. Read superficially, this was a citation update plus a vocabulary tidying. Read operationally, it removed a misleading endpoint from the decision tree and restored room for need-based judgement.

That did not create a new rule that every end site must receive a /48. Such a reading would merely exchange one rigid formula for another. RFC 6177’s significance was precisely that it resisted a single default for all end sites while discouraging the false economy of assigning only one address where a site might need subnetting, growth or architectural flexibility. A /64 could still be appropriate in context. A /48 could still be a sensible recommendation for simpler infrastructure.

The repair was not a declaration that one prefix length was universally correct; it was an instruction to stop treating an obsolete three-box formula as the whole answer.

The proposed wording also incorporated operator-facing practices reflected in RIPE-690. It made assignment size a need-based operational choice, recommended a /48 for simpler infrastructure, favoured persistent prefixes and recommended /64 global unicast addresses for point-to-point links. These details belong together. Sizing is not only about the number of addresses notionally available. It affects subnet plans, the ability to change providers or equipment, the stability of access-control and logging arrangements, and the likelihood that a customer will later have to renumber.

Persistence matters because even an abundant address space can be made expensive through needless churn.

The second important delta concerned utilisation. The old definition measured /48s assigned to end sites. The proposal instead defined utilisation by the number of prefixes assigned, rather than by prefix size or by counting individual addresses in use. This was a deceptively consequential clarification. If an operator makes context-sensitive assignments of different lengths, a fixed-/48 denominator can obscure what has actually been delegated. Conversely, counting active addresses would import an IPv4-like intuition into a vast IPv6 space where address occupancy is not the relevant measure of responsible assignment.

Prefix-count utilisation describes the registry-facing act: how many distinct prefixes have been assigned.

This did not prove that previous requests had been decided differently, and no numerical record in the available evidence establishes how many members changed their planning because of the old definition. The proposal’s author said there would be no change in application. That claim should be recorded accurately. Yet “no change in application” cannot mean “no effect on interpretation”. A clarified metric can cause two people who believed they were following the same policy to discover that they were calculating different things. It can help an LIR forecast when it will need more space.

It can change which supporting table appears sensible in a request. It can give staff a firmer basis for asking a relevant question and less excuse for asking an irrelevant one.

The third repair addressed an internal path through the document. The manual’s exception cross-reference pointed to section 6.3.3. The proposal redirected it to section 6.5.2, while retaining the statement that detailed information about a user network would not ordinarily be requested. A wrong section number is the purest example of a governance defect masquerading as copy-editing trivia. The sentence may be grammatically perfect; the destination may still be dead. A member following it may arrive at a provision that does not answer the question. Staff may rely on memory instead.

Two readers can then produce two practical manuals from the same published text.

Correcting the link had a limiting function as well as a navigational one. The retained assurance about detailed user-network information set an expectation about evidence. It did not prevent every justified question, and the sealed record does not establish any prior abuse. It did, however, locate the exception within the right part of the policy architecture. That matters because a private registry should request only information connected to the narrow technical task it is performing. A working cross-reference helps a member test whether a request belongs to that task or has drifted beyond it.

The fourth change deleted the existing section 6.5.4.2, which had governed multiple /48s to a single end site. That provision imposed an AFRINIC-level documentation and review step. Its deletion removed a blanket layer of review that no longer fitted the updated approach to assignment size. This was more than punctuation, yet it remained within the proposal’s coherent purpose: if assignments were to be evaluated by operational need rather than a rigid hierarchy of standard blocks and exceptional multiple blocks, the obsolete exception machinery should not linger as a second, contradictory policy.

Deletion also made renumbering within the manual visible. Once the old 6.5.4.2 disappeared, the previous 6.5.4.3 occupied that number in the implemented text. Anyone citing the manual across versions therefore needed a date or version, not merely a section number. This is why implementation records matter. Without a version anchor, a perfectly accurate reference written before the change can look wrong afterwards, while a reference written afterwards can be misapplied to the earlier text. A consolidated manual makes current reading easier, but only a version trail preserves institutional memory.

The proposal also shortened introductory wording in section 6.8 concerning provider-independent space. It did not replace the separate architecture governing PI eligibility. A neighbouring proposal, V6-004, addressed the broader PI update. This boundary is essential because the temptation to turn a narrow editorial analysis into a general IPv6 policy history is strong. V6-001 owned the accuracy of references, definitions and connected wording. It did not settle every contested or evolving question about initial allocations, sub-assignments or PI policy.

At AFRINIC-28 on 9 May 2018, the author said the proposal did not affect issuance or the justification information supplied. AFRINIC staff said it could be implemented as written without operational impact. The meeting outcome advanced it to Last Call. Later official records show that the changes reached implementation: CPM 1.3 recorded updates to sections 6.0, 6.1 and 6.5.4.1, and deletion of the former 6.5.4.2. AFRINIC’s announcement of 29 November 2018 presented the Policy and References Update as implemented.

The lifecycle is clear in outline but should not be embellished. The archived proposal page still carries an “Under Discussion” status, despite the meeting, annual and implementation records showing later progress. The complete Last Call correspondence, the Board ratification minute and the precise ratification date are not established here. It would be wrong to invent them merely to make the timeline look administratively complete.

The discrepancy instead illustrates why lifecycle status needs a reliable ledger: an archived page that freezes at an earlier state can confuse later readers even when the substantive history can be reconstructed elsewhere.

Nor should the staff phrase “no operational impact” be stretched beyond its proper use. It was a feasibility judgement about AFRINIC’s ability to implement the text, not a measured finding that no operator would rethink a design, change a worksheet or avoid a future cost. Similarly, the author’s statement that application would not change described the proposal’s intent. It does not erase the possibility that the old wording had supported divergent interpretations.

The defensible conclusion is modest: the correction made the manual more internally coherent and technically current; the record does not quantify how often that coherence altered a real-world outcome.

That modest conclusion is enough. Governance is often easiest to observe not in a dramatic decision but in the repair of an ordinary dependency. The 2018 draft showed a private registry doing what a competent technical bookkeeper should do: identify a stale reference, expose the delta, align definitions, remove a redundant review and publish the resulting version. The episode becomes misleading only if routine competence is inflated into a claim that the manual is public law or that the process creates powers a private organisation does not possess.