Summary

  • Draft 1, initially posted on 20 March 2018 after a 14 March submission, exempted a unique address or unique /64 supplied non-permanently to a third party on a link operated by the original receiver. On 9 May, AFRINIC-28 recorded “More discussion needed”, not consensus.
  • Draft 2—correctly identified as AFPUB-2018-V6-002-DRAFT02, version 2.0—was published on 22 August with the status Under Discussion. It split permitted use into third-party-device addressing and non-permanent third-party addressing inside a network managed and operated by the assignment holder, while adding semi-permanent connectivity to the prohibited side.
  • The revision therefore moved in both directions. It recognised contractor equipment and removed Draft 1’s address-size and point-to-point constraints, but tightened the duration language. It did not add a registration trigger, aggregation test, routing rule, contact rule, remedy or appeal.
  • The missing question was the one an operator and a truthful registry actually need answered: has an independently controlled downstream network changed the holder, responsible contact, routing or security authority, conflict state, or another fact that the shared number-resource record must show?

L3 — The redline that moved in both directions

The documentary trail begins with two dates that must not be collapsed. The details panel for Draft 1 records a submission on 14 March 2018. AFRINIC’s later revision history records the initial draft as posted to the resource-policy discussion list on 20 March. For a comparison between successive published drafts, 20 March is the baseline date; 14 March remains the distinct submission date. The proposal belonged to the “Clarification on IPv6 Sub-Assignments” family and sought to amend article 6.8 of the Consolidated Policy Manual.

At AFRINIC-28 in Dakar on 9 May, Draft 1 was discussed rather than settled. The official meeting summary records a practical staff question: would the temporary uses described by the proposal need to be registered in WHOIS? The author, Jordi Palet Martinez, answered that they were temporary and did not require registration. The co-chairs’ recorded disposition was “More discussion needed”, and the proposal returned for refinement. That exchange matters because it exposes the recordkeeping question early. It does not turn the answer into a clause, establish consensus or prove what motivated each later edit.

Draft 2 arrived on 22 August 2018. The correct identifier is AFPUB-2018-V6-002-DRAFT02, not AFPUB-2018-V6-001-DRAFT02; V6-001 belonged to the separate IPv6 Policy and References Update family. AFRINIC displayed the new instrument as version 2.0, authored by Martinez, submitted on 22 August and Under Discussion. The later proposal index and revision history confirm the date and identity. Those are exact status boundaries: publication is not adoption, and “Under Discussion” is not a synonym for consensus, ratification, implementation, application or enforcement.

The revision history offers only a terse explanation: the problem statement and proposed wording were updated for clarity. It does not identify a participant who demanded a particular change. It does not attribute the redline to leasing, fragmentation, aggregation or registration. It cannot support an invented story about bargaining among stakeholder blocs. The reliable way to understand Draft 2 is therefore to compare the words that changed and then test what those words would classify.

Draft 1’s compact safe harbour

Draft 1 began from a concrete unit and a temporary relationship. A unique IPv6 address, or even a unique /64, supplied non-permanently to third parties would not count as a sub-assignment when it was used on a link operated by the original receiver. The proposal gave recognisable examples: guests, employees, devices or servers, hotspots, point-to-point links and VPNs. The list made the intended safe harbour legible to an engineer. An address used by a visitor’s handset, an employee’s endpoint or a server attached to the holder’s link did not necessarily mean that the holder had transferred a slice of its assignment to another network.

There was a firm other side. Permanent connectivity or broadband service remained within the proposed sub-assignment prohibition. Draft 1 also created an unusual qualification for point-to-point links. Only the addressing for such a link could be permanent, and the assigned addressing could not be used, directly or indirectly, for the actual communication. That wording tried to distinguish link addressing from an address used as an endpoint of the substantive exchange, but it made a routine engineering pattern depend on a difficult textual fiction.

An address exists to support communication; a rule that exempts it only if it is not used for the actual communication invites false positives and interpretive games.

Draft 1’s shape can be stated simply. Its centre of gravity was a unique address or /64, supplied for a non-permanent period, on a link still operated by the original receiver. Its examples illuminated local or attached use. Its prohibition focused on permanent connectivity and broadband. Its point-to-point proviso was a narrow exception to the non-permanence condition, coupled with the special actual-communication restriction.

That clarity was incomplete. “Non-permanently” had no stated duration. “Original receiver” and “link operated” did not settle what happened where management was outsourced, where a contractor installed and supported an appliance, or where more than one party touched the infrastructure. The safe harbour explained several common cases but did not state the underlying record condition that made them safe. At the May meeting, the WHOIS question therefore surfaced naturally: if these cases were outside sub-assignment because they were temporary, what, if anything, should the registry know?

Draft 2’s two-pronged exception

Draft 2 altered both the problem it described and the operative boundary it proposed. Its problem statement added the case of an end user engaging a third party whose equipment needed addressing from the end user’s space. The examples were operationally specific: cameras, a recording system, a firewall, a router or equipment supporting a dedicated VPN. That addition recognised a common fact of contemporary networks. Organisations frequently own or control a network while specialists supply, install or operate devices within it. The mere presence of third-party equipment does not itself create a downstream network.

The proposed wording then used two prongs joined by “and/or”. First came the provision of addressing space to third-party devices, including addresses for point-to-point links. Second came the non-permanent provision of addressing space to third parties. Both were sheltered when the addresses were used on a network managed and operated by the assignment holder. Permanent or semi-permanent connectivity, such as broadband services, remained classified as a sub-assignment.

Each substitution matters. “Original receiver” became “assignment holder”. “A link operated” by that receiver became “a network managed and operated” by the holder. A single address or /64 ceased to be the stated unit. The named guests, employees, hotspots and VPNs disappeared from the operative paragraph, although the surrounding problem statement retained much of the context. Point-to-point addresses moved into the first prong, while Draft 1’s special rule about permanence and actual communication disappeared. On the prohibited side, “semi-permanent” was inserted alongside “permanent”.

These are not changes in one direction. The new semi-permanent language tightens the service-duration boundary: a relationship cannot escape merely because someone declines to call it permanent. The managed-and-operated-network condition may also sound more demanding than Draft 1’s reference to a link operated by the original receiver, because Draft 2 expressly invokes both management and operation at network scale. Yet other edits widen or clarify the safe side. Third-party devices receive their own prong. Contractor-operated cameras, routers and VPN equipment are now part of the stated problem. The one-address-or-/64 ceiling vanishes. So does the peculiar requirement that permanent point-to-point addressing not be used for the actual communication.

The grammar adds a consequential uncertainty. In the sequence “third-party devices … and/or non-permanently providing addressing space to third parties”, the adverb applies expressly to the second prong. The text does not expressly place the first prong under the same non-permanence limit. A camera or firewall can be installed for years while remaining a device inside the holder’s network. Draft 2 can reasonably be read as sheltering that use because the holder continues to manage and operate the network, even though the device’s presence is durable. That is a more operational distinction than a universal time limit.

But “and/or” does not supply a complete theory. It does not say whether the two prongs are fully independent in every case. Nor does it define when a device ceases to be merely a device inside the holder’s infrastructure and becomes the visible edge of an independently controlled network. Equipment ownership is not conclusive. A third party may own a router while the assignment holder determines configuration, routing, security and access. Conversely, a holder may own hardware that a customer controls as part of a distinct downstream network. The physical box is evidence. It is not the state the registry ultimately needs to record.

The shift from a “link” to a “network” creates a similar tension. It sensibly recognises that modern services may span many links and devices. Yet “managed and operated by the assignment holder” is undefined for mixed-management environments. A security contractor may monitor a firewall. A managed-service provider may push configurations. A building operator may control the cabling while a tenant controls endpoints. A camera vendor may maintain its appliance through a dedicated VPN. Draft 2 supplies examples of these arrangements but no test for how much external management changes the classification.

What disappeared, and what never appeared

The deletion of the unique-address-or-/64 unit deserves more than a passing note. Draft 1’s numerical formulation tied the exception to a narrow quantum, which might make sense for a guest endpoint or a point-to-point link but could misclassify a technically sound design. IPv6 networks commonly use prefixes rather than treating each device as a single-address object. RFC 8273, published in December 2017 as an Informational document, describes a unique IPv6 prefix per host on provider-managed shared-access networks. It is not Standards Track, not an AFRINIC policy and not a source of institutional authority. It does, however, demonstrate why a rigid address-or-/64 vocabulary may fit some deployments badly. Removing that unit avoided making one allocation pattern the legalistic definition of local use.

The disappearance of named examples from the operative paragraph is more ambiguous. Examples help readers but can harden into accidental exhaustive lists. Removing “guests”, “employees”, “hotspots” and “VPNs” may make the rule more general. At the same time, it transfers more weight to the abstract terms “third-party devices”, “third parties” and “managed and operated”. The problem statement preserves context, but an operator applying the clause has less direct assurance that an employee endpoint or hotspot still falls on the sheltered side.

The outcome depends on the structure rather than the label: the addresses must be used on the holder-managed and holder-operated network.

Draft 2’s treatment of point-to-point links is a clearer repair. It includes their addresses within third-party-device addressing and drops the rule that they may be permanent only if they are not used for the actual communication. The new wording no longer asks an engineer to distinguish an addressing function from communication in that strained way. Yet the deletion also leaves the first-prong grammar to do more work. If point-to-point addresses connect a third-party device, the first prong appears to shelter them without an express non-permanence condition, provided the network remains managed and operated by the holder.

Adding “semi-permanent” attacks a different form of evasiveness. A durable customer service could be written as a sequence of short agreements or given a nominal end date. If permanence alone were decisive, the relationship’s label might defeat the boundary. “Semi-permanent” signals that substance should matter. But Draft 2 supplies no duration, renewal count, control condition or technical characteristic that makes connectivity semi-permanent. A month, a year and an indefinitely renewable day-to-day arrangement are not classified. Nor does the word distinguish a long-lived contractor appliance from a durable downstream connectivity product.

Indeed, the first may be years old and sheltered, while the second may be contractually brief and prohibited.

Most important is what neither draft added. There is no clause saying when a temporary use must enter WHOIS or another database. There is no trigger based on responsible contacts, independent control or routing authority. There is no aggregation test and no instruction for preserving routing transparency. There is no definition of the relevant duration. There is no remedy for an inaccurate record and no appeal from a classification. Draft 2 improved and tightened parts of the vocabulary, but it did not answer the recordkeeping question raised publicly in May.

AFRINIC’s wider policy manual treats aggregation as an IPv6 policy goal and contains registration obligations elsewhere. That context establishes that record accuracy and routing structure were genuine registry concerns. It cannot be imported into the redline as if Draft 2 itself created a registration or aggregation safeguard. Nor can later Draft 3 wording or the later implementation history be projected backwards into 22 August. The event here is the publication of a version 2.0 proposal marked Under Discussion. Nothing in the record examined here proves a Draft 2 consensus, ratification, implementation, enforcement decision, denial, outage, routing effect or measured cost.

The exact redline therefore yields a disciplined conclusion. Draft 2 made contractor devices visible, expanded the abstraction from a link to a holder-managed network, split the shelter into two grammatical prongs, removed a numerical ceiling and eliminated an awkward point-to-point restriction. It also added semi-permanent connectivity to the prohibited side. Calling that simply a narrowing erases half the edit. Calling it a liberalisation erases the other half.

It was a mixed attempt to distinguish attached use from downstream service, still missing the fact-based trigger that could make the distinction legitimate and consistently administrable.