Summary

  • AFRINIC's board index records Resolution 200605.27 as ratifying a move from two-byte to four-byte AS numbers and instructing staff to implement it. Yet the AFRINIC-4 meeting report records consensus to move forward on 17 May 2006, the policy archive records a last call from 13 to 28 November, the board index separately records Resolution 200611.34 as a ratification, and the AFRINIC-5 report places board approval only days before that later meeting. The honest account is a conflicted or two-stage documentary trail, not a single frictionless approval date.
  • The transition changed issuance conventions in stages: from 1 January 2007, a four-byte-only ASN was available on specific request while a two-byte-only ASN remained the default; from 1 January 2009, four-byte issuance became the default while a two-byte-only ASN required a specific request; from 1 January 2010, allocation was to come from an undifferentiated four-byte pool. These were registry defaults and request rules, not commands capable of upgrading an operator's equipment.
  • Gradual interoperability depended on capability signalling, the AS_TRANS stand-in and additional path-preservation attributes, as well as compatible databases, textual notation, filters, monitoring tools and peer equipment. Later form changes, implementation announcements and reported ASN swaps show progress, but also show why a policy milestone cannot prove universal readiness.
  • The transition's strongest justification was that predictable sequencing conserved a narrowing pool, gave operators and vendors notice and avoided a network-wide flag day. Its strongest contrary case is that a private coordinator's timetable could shift upgrade costs and failure risk onto networks whose running systems were not ready. The answer is measurable readiness, documented exceptions, reversible adoption and portable audit evidence—not an assertion of authority.
  • AFRINIC's legitimate role was narrow but useful: keep a unique ledger, reconcile upstream inventory, change assignment defaults, maintain public records and publish evidence. Neither the resolution nor successful technical coordination made AFRINIC an owner of ASNs or a sovereign, legislature, regulator, police force, prosecutor, court, punitive authority or confiscating power.

The approval date is an audit finding, not a tidy anniversary

The first difficulty in reading Resolution 200605.27 is not technical. It is documentary. AFRINIC's public board index presents the resolution as an act that ratified four policies, including the proposed change from two-byte to four-byte ASNs, and instructed staff to implement them. Read alone, that entry invites a neat account: the board approved the transition in May 2006, after which implementation followed.

The rest of the surviving record does not permit that simplicity. The report of the AFRINIC-4 meeting on 17 May lists the four-byte proposal as a matter still under discussion. It describes discussion as limited but favourable and says consensus was reached to move forward. The policy archive also records consensus at AFRINIC-4, but then gives a last-call period of 13 to 28 November 2006. The same board index that contains the May entry separately records Resolution 200611.34 as ratifying the four-byte ASN policy.

The AFRINIC-5 report supplies further corroboration for the later timing: it says that the board had approved the policy a few days before the late-November and early-December meeting, and that four-byte ASNs would be available from 1 January 2007.

No supplied record explains why May and November both carry ratification language. It would therefore be wrong to demote one entry merely because the other makes a cleaner narrative. It would be equally wrong to invent a hidden procedural distinction—provisional approval in May and final approval in November, for example—unless a source actually records that distinction. The defensible conclusion is narrower. Resolution 200605.27 is evidence of a board-recorded May approval and implementation instruction.

The public procedural trail nevertheless continued through meeting consensus, a recorded November last call and a distinct late-November ratification. This is a documentary inconsistency, or at most a two-stage approval trail whose precise reconciliation remains unknown.

Even the policy archive's starting metadata resists overconfident harmonisation. Its top-level date is 22 September 2005, while its history says the proposal was first posted to the policy list on 9 December 2005. Those are two recorded pieces of metadata. Neither should be silently rewritten to make the other disappear. A trustworthy ledger preserves the field, the date, the source and the documentary status of each act. If a later authoritative reconciliation emerges, it should be added as another dated record rather than used to overwrite the earlier conflict.

This matters beyond historical neatness. An implementation audit must distinguish proposal publication, discussion, meeting consensus, last call, board action, staff instruction and operational release. Each act answers a different question. A board record proves that a board act was recorded. A meeting report proves what the meeting report says occurred. A policy archive proves the text and history it retains. None, by itself, proves that a request form accepted a wider value, that an allocation engine drew from the right inventory, that WHOIS rendered the result correctly, or that a router could establish and preserve a valid path.

That separation is the key to the entire episode. Policy approval can authorise staff work inside a private coordination body. It cannot manufacture interoperability by declaration. If the chronology of approval itself cannot be reconstructed from a single date, implementation certainly should not be inferred from the date printed beside a resolution.

What the staged schedule actually changed

The policy concerned representable ASN number space and the defaults by which AFRINIC would issue identifiers from it. A two-octet field represents values from 0 through 65,535. The full four-octet field represents values from 0 through 4,294,967,295, with the policy describing 65,536 through 4,294,967,295 as the four-byte-only range. These are numeric ranges, not a claim that every value was freely assignable: protocol and registry reservations still applied. Nor did the larger field turn a number into property, title, a licence or a sovereign grant.

The schedule was deliberately asymmetrical. From 1 January 2007, an applicant could specifically request a four-byte-only ASN, but AFRINIC's ordinary default remained a two-byte-only value. This made early use opt-in. It allowed willing operators to test the new range while networks with legacy constraints could remain on the narrower path without needing an exception from the default.

From 1 January 2009, the preference flipped. A four-byte ASN became the ordinary default, and an applicant seeking a two-byte-only ASN had to make a specific request. This was the transition's pressure point. The registry would begin conserving the more constrained space by treating compatibility with the wider range as the normal case, while still leaving a documented route for operators that could not safely use it.

From 1 January 2010, the policy timetable ended the allocation distinction and called for allocation from an undifferentiated four-byte pool. The policy expressly said that it implied no other change in ASN allocation policy. The milestone therefore described how the registry would select numbers; it did not silently rewrite the other rules governing requests, and it did not certify every router, form, database, filter or network-management system on the continent.

Calling these phases “defaults” is not semantic caution for its own sake. It identifies the actual control surface. AFRINIC could configure its forms and allocation process, communicate a preference, record a request, choose a unique value from available inventory and publish the assignment. It could not reach into an operator's routers and widen a field. It could not make a vendor release usable software, make a peer accept new attributes, or make a monitoring system stop truncating an integer. The timetable organised the registry side of a distributed transition. Adoption occurred connection by connection and system by system.

The schedule nevertheless had real coordination value. Without a published sequence, vendors and operators would have had less notice, the narrower pool would have faced more pressure, and late migrations could have become a scramble. An immediate switch in 2006 would have created the opposite problem: artificial exclusion for networks whose equipment or peers could not yet handle the wider value. The three stages placed voluntary introduction first, reversed the default after two years and removed the pool distinction a year later. In design, this was a practical attempt to move without a flag day.

It was also a distribution of costs. Router upgrades, laboratory work, maintenance windows and engineering time fell on operators. So did revisions to filters, communities, provisioning, monitoring, ticketing, customer records and reports that assumed 16-bit values. A failed peering or reachability event could impose costs far beyond the registry office. Smaller or more constrained networks were particularly exposed to the difference between a calendar assumption and an actual vendor or peer capability. A responsible schedule therefore needed an exception path and evidence of readiness, not merely advance notice.

Four compatibility surfaces stood between policy and operation

The move cannot be understood as a single database migration. It crossed at least four distinct compatibility surfaces: protocol exchange between BGP speakers; the internal systems and equipment of each operator; registry and public-record infrastructure; and identity reconciliation across textual forms and dependent business tools. A weakness on any one surface could turn a correctly issued number into a deployment problem.

1. Protocol compatibility was negotiated, not proclaimed

The technical design available when the policy was discussed was still an IETF Internet-Draft. The November 2005 draft described an incremental mechanism rather than a simultaneous conversion of the Internet. A BGP speaker could advertise through a capability that it understood four-octet AS numbers. Peers could then use an encoding appropriate to their shared capability. This was the foundation for avoiding a flag day: upgraded speakers did not have to assume that every neighbour had upgraded at the same time.

When a four-octet-capable speaker communicated with an older two-octet speaker, a non-mappable ASN could be represented in the legacy AS_PATH by AS_TRANS, whose numeric value is 23,456. Additional path information travelled in an optional transitive attribute so that a later four-octet-capable speaker could reconstruct more of the original path. The terminology has to remain dated. The November 2005 draft called the additional attributes NEW_AS_PATH and NEW_AGGREGATOR. RFC 4893, published in May 2007 after the AFRINIC decision, standardised the mechanism using the names AS4_PATH and AS4_AGGREGATOR.

It is inaccurate to project those later RFC names backwards as though the 2005 draft necessarily used them.

The mechanism made mixed operation possible, not perfect. RFC 4893 assumed that BGP speakers within an autonomous system would be upgraded before that system began using a four-octet ASN. Registry issuance could not perform that internal upgrade. An older speaker performing aggregation could also discard information needed for exact path reconstruction. Inconsistent legacy and four-octet path attributes could create loop-detection or security risk. The transition design therefore made compatibility a state to observe.

AS_TRANS appearances, capability results, path reconstruction and attribute consistency all had to be monitored in realistic mixed-speaker topologies.

Related conventions needed attention too. Filtering and community practices often embedded assumptions about the size of an ASN. A router's ability to establish a session was not enough if policy tools, extended-community handling or operational scripts still parsed only the older width. RFC 4893 pointed to four-octet AS-specific extended communities for comparable use. That was a design route, not proof that every local configuration adopted it correctly.

2. Operator readiness was local and peer-dependent

The second surface sat inside and around each operator. Hardware, operating systems, routing daemons, configuration generators, network-management platforms, route collectors, alerting systems and customer portals could mature at different speeds. A laboratory test against one software release did not prove compatibility with every peer or every production path. An operator needed to know not just whether its router accepted a four-octet ASN, but whether route policy, logging, telemetry, backups, disaster-recovery configuration and support procedures preserved it without truncation or substitution.

Readiness was also relational. One network might be fully upgraded and still face an incompatible peer, transit supplier or managed-service platform. Capability signalling allowed a compatible conversation across a legacy boundary, but it did not eliminate every loss of information or every tool-chain assumption. The practical unit of adoption was therefore not “Africa is ready” or even “this operator is ready”. It was a tested set of systems and peer relationships, with a rollback that remained viable if real traffic exposed a defect.

This is why subsequent reports of incompatibility are not surprising footnotes. They are evidence about the operating surface that a resolution could not control. They also do not prove that the staged policy as a whole failed. A transition can be broadly useful and still generate exceptions. What matters is whether those exceptions were visible, traceable and handled without coercing an unsafe deployment.

3. Registry systems had to implement the policy as data and process

The third surface was AFRINIC's own implementation chain: upstream inventory, request forms, ticket workflows, allocation logic, database schemas, WHOIS, delegated statistics, public documentation and support practice. A board instruction did not demonstrate that any of these components had changed. Each needed a dated work order, test result or change record.

The IANA ASN registry supplies one early checkpoint. It records the block 327680–328703 as assigned to AFRINIC on 29 November 2006, shortly before the first policy phase. That entry proves that an upstream block and date were recorded. It does not prove when AFRINIC made its first downstream assignment, when a route first appeared, whether the local inventory reconciled, or whether anyone acquired ownership of the values.

A 2008 AFRINIC transition briefing provides another checkpoint. It described the pool mapping and reminded participants of the 2009 default change. This shows how AFRINIC later communicated its implementation plan. It does not certify every dependent operator system. Similarly, AFRINIC's 2012 annual report says the option to choose between 16-bit and 32-bit ASNs was removed from the form in 2011, after which allocation came from a common 32-bit pool.

That is a concrete reported implementation change, but its 2011 timing is also a reason not to assume that the 2010 policy milestone automatically transformed every visible interface on the date the timetable turned.

On 11 May 2012, a public RPD announcement said that AFRINIC's systems supported an undifferentiated pool and the asplain representation selected by RFC 5396. The announcement dates a public implementation claim. It is not evidence that 11 May was the first moment of support, nor that every external tool or operator was compatible. An institutional statement is most useful when treated as a testable assertion, not a certificate that closes the audit.

4. One number needed one identity across every notation and record

The fourth surface was less visible but equally dangerous: the same ASN had to remain the same identity when represented by different systems. The initial policy used asdot examples. In that notation, decimal 65,546 could appear as 1.10. RFC 5396 later chose asplain—one decimal representation for all ASNs—because mixed notation had created operational confusion. RFC 5396 dates from 2008; its later choice should not be projected back onto the wording or presentation of the 2006 decision.

A safe record design stores the canonical 32-bit integer separately from its display form. It preserves an original asdot string where that string is historical evidence, but search, WHOIS, route collectors, tickets, filters, billing and customer systems must reconcile 1.10 and 65,546 as one value. Otherwise one resource becomes two apparent identities: a lookup misses the assignment, a ticket appears unrelated, a filter targets the wrong text, or a public record seems to disagree with a routing observation when the disagreement is only notation.

Field width is another identity control. A legacy database or API may reject a value above 65,535, wrap it, truncate it or accept a lossy conversion silently. Boundary testing must cover storage, serialisation, search, exports, user interfaces and downstream integrations. Lossy writes should fail visibly. Migration logs should show which record changed, which representation was retained and how a round trip was verified. An allocation system that can select a wide value is not “ready” if a CRM, network-management system or support export later corrupts it.

These four surfaces explain why registry policy, technical specification and running operation are different kinds of evidence. A policy page can describe intended defaults. A technical draft or RFC can describe an interoperable mechanism and its limits. A registry announcement can claim system support. Only observed, reconciled implementation evidence shows what happened across a particular assignment and deployment.

The later audit trail records progress and friction together

The strongest implementation account does not look for one decisive completion date. It follows a chain of checkpoints. The November 2006 upstream block precedes the January 2007 request-only phase. The May 2007 RFC standardises transition mechanisms that had existed in draft form while the policy was being discussed. The 2008 briefing prepares operators for the January 2009 reversal of the default. The January 2010 milestone ends the policy distinction. The reported 2011 form change and 2012 system announcement show later registry work. The 2012 annual report and a 2014 NRO account then preserve evidence that some incompatibility remained.

AFRINIC reported assigning 145 ASNs in 2012, six of them 32-bit. The same annual report says that equipment incompatibility led to case-by-case swaps of higher-bit 32-bit ASNs for lower-bit 32-bit ASNs. That report proves what AFRINIC said about its assignments and exceptions. It does not independently establish the completeness of the count or turn a self-report into proof about every operator. Yet the swaps are important. They demonstrate that exception handling was not merely theoretical after the timetable had reached an undifferentiated pool.

The NRO later reported, across the RIR environment, that incompatible routers had caused some customers to return or exchange four-byte ASNs for two-byte ASNs. The account does not identify every exchange as AFRINIC-specific, and it does not confer public authority on the NRO or any registry. Its evidentiary value is narrower: operational friction persisted across the wider transition, and compatibility problems could reverse an assignment choice even after formal milestones had passed.

This trail cuts both ways. The existence of later swaps is not proof that staging was misguided. Without staging, incompatibilities might have appeared abruptly under greater scarcity pressure and with less notice. But the same evidence defeats any claim that the calendar by itself completed the transition. A mature evaluation can hold both propositions at once: sequencing reduced coordination risk, and continuing exceptions showed that readiness remained uneven.

The 2011 and 2012 records also illuminate a governance risk. When an institution controls the request form and public ledger, its interface can make an internal default feel compulsory. An operator faced with an incompatible value may experience genuine continuity risk even though the registry has no regulatory power. That practical leverage increases the duty to publish compatibility facts, preserve an exception route and document swaps. It does not transform operational impact into sovereign jurisdiction.

LARUS's operator-facing analysis is useful at precisely this boundary: a registry coordination decision can alter upgrade plans, records and infrastructure continuity without acquiring the character of public regulation. The practical effect should be measured rather than minimised. The authority claim should still be refused. Real dependency is a reason for stronger continuity controls and portable evidence, not a shortcut from technical influence to jurisdiction.

A reconstructable evidence chain is the difference between implementation and assertion

An independent reviewer should be able to follow an ASN through the transition without having to accept any institution's conclusion. The chain begins with the exact policy proposal: reference, version, publication metadata, dated copy and retained hash. It then preserves the AFRINIC-4 report, the consensus account, the last-call dates, both board resolutions and an explicit note that the public chronology conflicts. Silence about the conflict is itself a record weakness.

Next come the implementation records. Change tickets should show when request forms, the allocation engine, database fields, WHOIS schemas, delegated-statistics output, public guidance and support procedures were altered. The block 327680–328703 and its 29 November 2006 upstream date should reconcile against local totals for available, assigned, reserved and exceptional values. Adjustments should be explicit; a total that balances only after unexplained manual edits does not pass an inventory test.

For each assignment, the evidence should retain the requester's stated preference, the default phase in force on that date, the canonical decimal value, any historical display form, ticket timestamps and the responsible operational role. This allows a reviewer to explain why a two-byte-only or four-byte value was selected without turning the explanation into an ownership claim. The policy itself said the schedule implied no other change in allocation policy, so the width decision should not be allowed to smuggle in an unrelated conclusion.

Operator-readiness evidence should identify router and software versions, capability tests, laboratory or limited-deployment results, filter and community reviews, tooling checks, peer compatibility and the rollback plan. A generic declaration that equipment is “compliant” is weaker than a dated result against a specific topology. Raw BGP observations matter where path reconstruction is at issue. They should show capability exchange, occurrences of AS_TRANS, the relevant path attributes and any inconsistency or aggregation loss encountered.

The internal ticket, allocation database, public WHOIS or aut-num object, delegated-statistics entry and observed routing evidence should then be reconciled by value and relevant date. These sources do not have to say the same thing about every moment. A number can be correctly assigned before it is visible in routing, and absence from a collector is not automatic proof of invalidity. The test is whether differences are explained, time-bounded and linked to their evidentiary role.

Every return or swap needs a durable two-sided record. It should link the old ASN and the replacement, state the reason, identify affected systems, retain authorisation, show updates to public records, document route migration and record closure. The earlier value should not vanish merely because the current object now shows the replacement. A silent swap damages operational continuity and makes later accountability impossible.

Finally, the chain must be portable. Dated copies of current registry data should be saved, then compared for organisation, dates and contacts over time. The request-to-evaluation-to-decision-to-inventory-to-public-record path should be exportable in a form an operator, auditor or replacement coordinator can verify without dependence on one private interface. Portability is not a claim that a downloaded record creates title. It is a continuity control against institutional failure, interface change, memory loss or contested history.

Two first-class methods make this discipline concrete. NRS's continuity method asks infrastructure operators to verify current registry data, retain dated copies and compare organisation, dates and contacts, while treating every result as time-bounded. NRS advocates, researches, convenes and represents explicitly authorised members; it does not operate a registry, RPKI, WHOIS/RDAP, appeals, settlement, elections, custody or continuity. BTW's allocation-file method supplies the second half of the chain: preserve the path from request through evaluation and decision to inventory and the public record.

Applied to this transition, that method tests implementation without importing unrelated controversies or treating the ledger as proof of ownership.

Several compact tests follow from this method. The chronology test asks whether May and November both remain visible. The inventory test asks whether the upstream block reconciles with local states. The identity test asks whether asdot and asplain resolve to one canonical integer and one current registry object. The phase test asks whether the applicable default and any explicit request explain the issued width. The protocol test compares capability and path behaviour with the deployment plan. The public-record test reconciles internal, registry and routing observations. The exception test prevents a swap from erasing its predecessor.

The authority test ensures that none of these technical records is misrepresented as a court order, title instrument, licence or sovereign command.

The strongest case for staging—and the strongest warning against it

The case for the decision is substantial. The two-octet space imposed a predictable coordination constraint. Waiting without a schedule would have deprived vendors and operators of a shared horizon and increased the risk of rushed change. The 2007 opt-in phase created a practical learning period. The 2009 default reversal encouraged ordinary use of the wider range while retaining a request path for compatibility needs. The 2010 undifferentiated pool removed an increasingly artificial distinction.

Capability negotiation, AS_TRANS and path-preservation attributes allowed upgraded and legacy speakers to coexist without one global conversion moment. This is exactly the kind of work a thin common coordination layer can usefully perform.

The strongest case against overconfidence begins with the same facts. At AFRINIC-4, some participants considered the issue not yet relevant. The procedural record continued into November despite the May ratification entry. Later AFRINIC and NRO material records incompatible equipment, returns and swaps. A registry default can transfer upgrade and testing costs onto operators, including smaller networks with less bargaining power or older equipment. A timetable can become de facto pressure when a private coordinator controls scarce inventory, even though it lacks lawful coercive authority.

If an operator is pushed into a configuration its running systems and peers cannot safely sustain, coordination has exceeded its defensible purpose.

Neither case should be resolved by rhetoric. The answer is to retain the staged default while binding each phase to component-level readiness evidence, disclosed exception counts, open compatibility tests, notation and inventory reconciliation, and reversible operator adoption. The coordinator should publish what is known, what failed and what remains exceptional. Operators should decide when deployment is safe within their real interconnection constraints. The common layer supplies stable semantics and portable proof; it does not substitute an institutional calendar for operational judgement.

Four counterfactuals clarify the choice. With no schedule, notice shrinks and continuity costs rise as the narrower pool becomes more constrained. With an immediate mandatory switch in 2006, incompatible networks face avoidable exclusion. With staging but no evidence trail, the transition may appear complete while forms, WHOIS, routing and customer systems diverge. With staging, portable audit and adoption grounded in running code, the pool transition can proceed while incompatibilities are tested, exceptions are recorded and operator choice is preserved.

This resolution also answers the question of institutional status. Under Heng Lu's controlling doctrine of uniqueness coordination, AFRINIC could coordinate a unique ledger, receive inventory, change request defaults, record assignments, maintain public data and facilitate testing. Those are consequential technical functions. They do not make AFRINIC the author or owner of a network, route or identifier. They confer no sovereign, legislative, regulatory, police, prosecutorial, judicial, punitive or confiscatory power. The word “consensus” in an internal process does not create public-law legitimacy.

An RFC specifies a mechanism; it does not make the IETF a state. An IANA entry records inventory; it does not convey title. Operational dependence is not jurisdiction.

The controlling rule is therefore the private-bookkeeper limit. Heng Lu's running-code principle places actual compatible implementation ahead of institutional declaration, while the minimum-common-layer principle leaves future choices local and adoption voluntary except where real interoperability requires agreement. The keeper of the address book may preserve uniqueness and coordinate compatible records, but must not confuse recording with rulership.

The effective four-byte transition existed where implementations exchanged capabilities, paths survived mixed operation, databases retained the value, and willing operators deployed it successfully. Resolution 200605.27 mattered because it set work in motion. It could never make old running code understand a larger ASN by itself.