Summary

  • AFRINIC’s current manual separates IXP peering addresses from management addresses, sets aside a dedicated peering pool and describes an adjacent /24 that can support growth to a /23. At AFRINIC-37, staff also reported that some members were swapping prefixes across the two uses in nonconformance with the policy.
  • NAPafrica’s Andrew Owens described a Johannesburg deployment with two /23s, close to using a /22, and a possible need for two more /23s to reach a /21. He said a renumbering begun eight years earlier was still incomplete. Those are his reported facts about one deployment, not a census of African IXP demand or a typical migration time.
  • Before changing a /16 reserve to a /15, the community needs evidence about pool consumption and affected members, plus a design for contiguous growth and transition. A larger pool can address scarcity; by itself, it cannot guarantee that the next block will sit where an exchange can use it.

Analysis

“How large?” is only one reserve question

The live Consolidated Policy Manual identifies version 1.6 as current and gives 17 November 2020 as its publication date. Its IXP rules address more than a headline pool size. Section 11 distinguishes a peering LAN—a contiguous block used by participants to exchange traffic—from the management network that supports monitoring, statistics, mail and other services. It says management addresses should not come from the peering block. It describes a dedicated, published peering pool and an adjacent /24 held so an exchange can grow to a /23 without taking a new block and renumbering. The section proposes a /16 peering reserve and a separate, equivalent /16 for management. The manual

At the meeting, a participant asked whether the /16 reserve was enough for the region or whether a /15 would be more appropriate. A /15 contains twice the address count of a /16, but that arithmetic does not say how many usable, contiguous assignments remain, how quickly they are being consumed or which applicants might be constrained. AFRINIC staff said it would provide consumption statistics so members could deliberate with a better picture. Another participant specifically asked for the number of affected members before the community judged urgency. The AFRINIC-37 minutes

That request is not a procedural footnote. A reserve is an inventory rule and an allocation rule. The proposed size says how much space is held back. The assignment unit and adjacency rule say whether an operator can use it to expand. The records needed to show who has drawn on the pool, for what purpose and with what remaining headroom are a third question. A decision based only on the first can enlarge the inventory while leaving the next growth step uncertain.

A nonconforming use is not yet a diagnosis

The minutes also record AFRINIC staff saying that members were swapping peering and management prefixes, contrary to the policy, and that staff was working with them to align usage. That statement points to an implementation problem. It does not establish why the swaps happened, how many members were involved, or whether the rule, member records, administrative process or operational practice was the main cause. The distinction matters: rewriting policy before identifying the failure mode could move the text without fixing the behavior.

The current manual’s section 5.6.4 and section 11 are related but not identical surfaces. Section 5.6.4 describes critical-infrastructure assignments, generally no longer than /24 while allowing multiple assignments in some circumstances. Section 11 concerns reserved IXP peering and management pools, and its adjacent-/24 provision is meant to enable a step to /23 without renumbering. The manual also defines an IXP through physical layer-2 infrastructure, a single operator, at least three connected ISPs and an open policy for others to join. AFRINIC’s public request criteria ask for evidence of legal presence, peer ASNs and contacts or signed MoUs, public openness and a licence where the country requires one. AFRINIC’s criteria

Those are concrete tests, but they do not answer the reserve debate on their own. Eligibility tells staff who may request resources; it does not quantify future demand or resolve whether the available blocks fit an exchange’s growth path. Nor does the observation that some prefixes are being used across categories tell readers whether staff has the information and tools to catch a swap before it becomes an operational dependency.

The Johannesburg example is a geometry problem, not a regional estimate

Andrew Owens said NAPafrica had two /23 blocks in Johannesburg, was close to full utilization of a /22, and would need two additional /23s to get to a /21 if it needed more space. He also said renumbering its Johannesburg deployment had started eight years earlier and was not complete. The minutes frame this as one operator’s experience. They do not provide a denominator, a set of comparable exchanges, an independent cost estimate or a timeline showing why that migration took as long as it did.

The example is still useful because it reveals what a pool total leaves out. Four /23s can form a /21 only when the assigned blocks align contiguously on the relevant boundary. An IXP that has grown through separated assignments may need more than an address count; it needs a workable sequence of adjacent blocks, a way to preserve current service while moving, and enough notice to coordinate participants. The manual’s adjacent /24 mechanism is explicitly designed for an initial expansion to /23. Owens’s reported example raises a later-stage question about how a successful exchange moves beyond that increment.

It does not prove that the policy failed, but it makes the next increment worth designing rather than assuming.

The same meeting included a suggestion to consider RFC 8950 in a dual-stack operating model. The IETF standard permits IPv4 route advertisements to use an IPv6 next hop when BGP peers negotiate the relevant capability. That is a possible engineering option, not evidence that all route servers and participants in every exchange are ready to rely on it, and not proof that a reserved IPv4 peering LAN is unnecessary. RFC 8950

Publish the evidence before choosing the larger number

The meeting record establishes that the community raised two different sizing questions: how much space the regional reserve needs and how an individual exchange can grow without repeated renumbering. Staff also acknowledged a request for consumption and affected-member statistics and committed to share relevant figures on the mailing list. The public materials reviewed for this article did not establish whether or when that commitment was fulfilled; that is a limit of this reporting, not proof that no figures were later circulated.

The next useful record would put the questions on one page without collapsing them. It could show the peering and management pools separately; their starting size, allocations, returns and remaining space; how many requests were constrained; the sizes of assignments; and whether growth blocks were contiguous. It should distinguish approved allocations from forecast demand and make clear whether “use” means assigned, deployed, routed or simply held. A compact table with dates and methods would be more informative than a single utilization percentage.

Alongside the inventory, the community needs a transition map: the growth increments the policy can support, how adjacent space is reserved, what happens when a block cannot be made contiguous, which party coordinates any renumbering, and what operational safeguards or exception process applies. The goal is not to guarantee that every requested block will always be adjacent. It is to make the trade-off between conservation and avoidable migration visible before staff and operators face it one application at a time.

If the evidence shows that the dedicated /16 is running out of usable /23 assignments, a larger pool may be justified. If demand is concentrated in a small number of exchanges that need larger contiguous growth steps, the same evidence may point toward a different reservation geometry or a staged transition rule. If category swapping dominates, improved registration and compliance support may do more than doubling a reserve. None of those outcomes follows from the minutes alone.

The responsible order is therefore simple: report the pool, report the requests it cannot meet, and show the growth and migration paths the policy enables. Then the community can decide whether the right answer is more IPv4, a different shape of reserve, stronger records, or a mix. The NAPafrica example makes the cost of getting that order wrong imaginable. Only broader, published evidence can tell AFRINIC how often that cost is likely to recur.

Sources