Summary

  • At AFRINIC-37, NAPafrica described a Johannesburg exchange outgrowing its existing address space while an earlier renumbering remained unfinished. That is one operator's experience, not a measure of demand across Africa.
  • AFRINIC already reserves neighbouring addresses for an exchange's first expansion. The reservation has a limit, however, and doubling the regional pool would not by itself provide a workable next move.

Eight years is a long time to change an address. At the AFRINIC-37 policy meeting on 24 June 2026, Andrew Owens of NAPafrica said the renumbering of its Johannesburg deployment had begun eight years earlier and was still not complete.

He was talking about an Internet exchange: shared infrastructure through which connected networks pass traffic to one another. Changing the addresses used there is not like correcting a single entry in an address book. The exchange and the networks connected to it can have changes to coordinate. A new block of numbers gives them somewhere to go; it does not arrange the move.

Owens also had a more immediate concern. Johannesburg already had two /23 blocks and was close to using a /22's worth of space. To reach the next size he described, a /21, it would need two more /23s. He wanted room held for that expansion. The meeting minutes record his request, not an award of those addresses.

The fractions are shorthand for address-block sizes, and they run in the opposite direction to what a newcomer might expect: a smaller number after the slash means a larger block. A /23 contains 512 addresses; four contain 2,048, as does a /21. But four separate /23s become one /21 only if they sit together and line up on the correct boundary. These are address counts, not counts of customers or participating networks.

That is why a generous stock of addresses can still leave an operator with an awkward expansion. The required amount may exist without the right neighbouring blocks being available.

The neighbour is reserved — for now

AFRINIC's policy already recognises the cost of moving. Section 11.4 of its Consolidated Policy Manual provides for an adjacent /24 to be held beside an exchange's peering allocation. Together, the two /24s can support growth to /23 without moving to a new block.

There is a condition. Those growth reservations last until the dedicated /16 pool can no longer make /23 assignments. New requests may then draw on space previously held for expansion. An empty neighbouring block is therefore not a promise to keep it empty indefinitely. The policy also has to leave room for exchanges that have not yet arrived.

The passage does not establish that the release condition has already been reached. Nor does the first growth step settle what should happen to an exchange that needs substantially more space. Staff raised precisely that concern at the meeting: some IXPs had reached /23 and needed rules that better accommodated further growth.

A separate provision, section 5.6.4.1, can be easy to misread. Its /24 limit is on prefix length, not a ceiling of 256 addresses. Shorter prefixes describe larger blocks; the provision also allows multiple assignments in some circumstances. It does not grant every applicant whatever size it asks for.

Two reserves, two jobs

The policy keeps one /16 for peering and the equivalent of another /16 for management. Peering addresses identify the connections through which member networks exchange traffic. Management addresses support work such as monitoring, publishing statistics and handling support tickets. Management space must not come from the peering block.

Staff told the meeting that members had been swapping the two uses contrary to policy and that they were working with them to put matters right. The minutes do not establish how many members were involved or why the swaps occurred. Giving the reserve more addresses would not necessarily correct a mistaken use or record.

There is also a difference between qualifying for space and planning its future. AFRINIC's IXP application criteria ask for evidence of legal presence in Africa, or representation by another organisation if the exchange is not registered; details of at least three BGP peers and/or their signed agreements; and evidence that the exchange is public and open. Those checks tell staff who is applying. They cannot predict how large that exchange will become.

A bigger pool still needs a plan

At the meeting, Paul Hjul asked whether a /15 would be more suitable than the /16 reserve. It would hold twice as many addresses. James Chirwa said the question was for the community and that staff would provide consumption figures. Gregoire Ehoumi also asked how many members were affected. This was a discussion about possible change, not a decision to enlarge the reserve.

The request for numbers matters because the remedies differ. A shortage of available assignments calls for a different response from an exchange unable to obtain adjacent space. Incorrect use of the two reserves is a third problem. One percentage showing “addresses used” would blur all three.

There was a technical alternative on the table too. Jordi Palet pointed to RFC 8950, which lets BGP advertise IPv4 routes using an IPv6 next hop. In plain terms, a network can announce where IPv4 traffic should go using an IPv6 address for the next step. The peers must support the relevant capability. A standard's existence is not evidence that every exchange participant can already use it.

The Johannesburg example gives the policy debate a practical consequence: an exchange can succeed at attracting networks and then face a difficult next expansion. It does not prove that all African exchanges face the same problem, or explain every year of NAPafrica's unfinished change. The figures promised in June would help distinguish the cases; this reporting has not established their subsequent publication status.

AFRINIC's community therefore has more to decide than the size of a reserve. It must decide how long to hold neighbouring space, how to accommodate newcomers, and what happens when a growing exchange has to move. More addresses could help. The worthwhile outcome is room that an exchange can actually grow into, rather than another change of address it cannot finish.

Correction, 21 October 2026: We have clarified that /24 in section 5.6.4.1 concerns prefix length, added the condition on retaining adjacent growth space, and removed a licensing requirement incorrectly attributed to the IXP criteria table. This does not imply exemption from national law. The original URL and publication date are unchanged.