Summary

  • AFRINIC’s policy reserves separate IPv4 blocks for IXP peering and management, with adjacent space intended to let a peering LAN grow without renumbering.
  • Its AFRINIC-37 minutes record a request for reserve-consumption data, while its own public statistics guidance says reserved resources cannot be differentiated in the extended file.

Analysis

An address reserve can look generous on a balance sheet and scarce at a router. Those are not contradictory descriptions. A block may contain many addresses in total but still fail to supply the next exchange point with a contiguous prefix, or it may have ample adjacent space while its published inventory cannot show who can use it. The relevant question is not only how many addresses sit behind a policy label. It is whether the reserve remains usable for the purpose that justified it.

AFRINIC’s Consolidated Policy Manual makes that purpose unusually concrete. Section 11 separates the peering LAN, where exchange participants connect, from the management LAN used for services such as monitoring, statistics and ticketing. It calls for a dedicated block for peering and a different block for management. Each peering assignment should also retain an adjacent /24, allowing the exchange to grow to a /23 without moving to a new, non-contiguous block. The policy sets aside a /16 for future peering requirements and a separate /16 for management prefixes.

Contiguity is an operating property, not cosmetic tidiness. If an exchange must move its peering LAN to obtain a larger block, every participant may need to coordinate address changes, router configuration and service checks. The policy’s adjacent-prefix rule is meant to avoid that particular break in continuity. It does not guarantee that every future expansion can be accommodated; it specifies the shape of space the reserve is supposed to preserve.

At AFRINIC-37 on 24 June, staff returned to Section 11 during a report on policy implementation experience. They said the critical-infrastructure definition had been in the manual for more than fifteen years and asked whether it still reflected current IXP operations. The minutes note that some exchanges had reached the /23 threshold and that staff wanted clearer wording for fast-growing IXPs. They also describe members switching prefixes between peering and management use in ways staff regarded as nonconforming.

The same exchange raised a question about scale. One participant asked whether the continent-wide /16 peering reserve was sufficient or whether a /15 would be more suitable. AFRINIC staff replied that they would provide consumption statistics to help the community deliberate. Another participant asked for concrete figures, including how many members were affected by reserve limits, before committing to policy work. Those were questions in a meeting, not a finding that the existing block is exhausted.

The distinction matters because the public inventory has a blind spot. AFRINIC’s resource-management page says its extended statistics show available, reserved and allocated/assigned resources, but also says reserved resources cannot be differentiated in that file. The page lists examples of policy-reserved blocks in WHOIS, yet a public total marked “reserved” does not disclose the IXP pool’s remaining contiguous headroom, how much belongs to peering rather than management, or how many eligible requests could not be met. The page does not establish that AFRINIC lacks internal records.

It does show why a public aggregate is not enough to settle the question raised at the meeting.

The most useful next document would be a privacy-safe reserve ledger. For each policy reserve, it would identify the published block, its purpose, the amount assigned, the amount retained for adjacency, the largest contiguous free prefix, and the date of the snapshot. It would add aggregate counts of eligible requests, approvals, waits and denials, with reasons and broad location bands where those do not expose member-sensitive details. Peering and management must remain separate rows: combining them would make the total larger while hiding which function is creating pressure.

One operator’s account in the minutes gives the issue operational texture but cannot supply the missing regional denominator. A NAPafrica representative described two /23 blocks in Johannesburg, said the installation was approaching a /22 footprint, and said a renumbering effort had been difficult and long-running. That is an attributed account of one deployment. It does not show how many exchanges face the same constraint, the amount of unused space elsewhere, or whether current requests were refused.

The proper sequence is therefore modest. Publish the reserve ledger, explain how staff count an assignment and preserve adjacent space, then compare that evidence with the current policy’s /23 growth design. If demand and usable headroom point to a constraint, the community can debate whether to alter block size, eligibility or the way adjacent space is released. If the ledger shows a classification or allocation problem instead, a larger reserve could simply move the ambiguity into a larger block.

Sources

AFRINIC-37 Public Policy Meeting minutes · Consolidated Policy Manual, sections 11.0–11.5 · AFRINIC IP Resources Management and statistics guidance · AFRINIC-37 presentations