Résumé

  • À AFRINIC-37, NAPafrica a raconté un changement d'adresses toujours inachevé après huit ans. Préparer la prochaine extension, c'est aussi éviter de remettre les équipes au travail sur un nouveau déménagement.
  • AFRINIC garde des adresses voisines pour une première croissance, mais cette place peut ensuite revenir à de nouveaux demandeurs. Il faut arbitrer entre ceux qui s'agrandissent et ceux qui commencent.

Huit ans après le début du changement, il restait encore du travail. Le 24 juin 2026, Andrew Owens de NAPafrica a raconté à AFRINIC-37 que la renumérotation de son déploiement de Johannesburg n'était toujours pas terminée. Dans une discussion sur les réserves d'adresses, cette durée donnait une raison très concrète de vouloir éviter le prochain déménagement.

Un point d'échange est un lieu de rencontre entre réseaux : ils s'y raccordent à des équipements communs pour se transmettre directement des données. Chaque réseau reste pourtant exploité par sa propre organisation. Les connexions utilisent des adresses ; les remplacer peut donc demander à plusieurs équipes de modifier leurs réglages.

Le responsable du point d'échange peut avoir préparé son changement sans que tous les participants soient prêts. Il faut alors convenir des étapes, vérifier les nouvelles connexions et garder le service en fonctionnement pendant la transition. Ce sont les tâches possibles d'une migration, pas le récit d'un incident chez NAPafrica.

Voilà le travail que peut éviter une extension sur place. Le bénéfice ne se lit pas seulement dans un stock de numéros : il peut se traduire par une modification de moins à préparer chez les participants. Le compte rendu ne chiffre pas cette charge et n'explique pas chaque année du cas de Johannesburg. Il montre en revanche pourquoi Owens s'intéressait déjà à l'étape suivante.

Agrandir sans recommencer le déménagement

Owens signalait aussi un besoin de croissance. Johannesburg disposait déjà de deux /23 et approchait l'utilisation d'un /22. Pour atteindre /21, il lui faudrait deux /23 supplémentaires. Il souhaitait les voir réservés. Les minutes de la réunion consignent cette demande, pas son approbation.

Un /23 contient 512 adresses ; quatre en contiennent 2 048, comme un /21. Encore faut-il que les quatre blocs soient contigus et correctement alignés pour former un seul /21. Ce sont des nombres d'adresses, non des capacités d'accueil exprimées en opérateurs. Un stock suffisant, mais dispersé, ne répond pas nécessairement au besoin du bloc voisin.

La section 11.4 du manuel de politique consolidé ménage déjà une première extension sur place. Elle garde un /24 voisin pour permettre de grandir jusqu'à /23 sans changer de bloc. Les nombres après la barre désignent des tailles d'ensembles d'adresses : plus le nombre est petit, plus l'ensemble est grand.

Cette réservation n'est pas éternelle. Elle tient tant que le pool /16 dédié peut encore attribuer des /23. Ensuite, les nouvelles demandes peuvent puiser dans l'espace conservé pour la croissance. Il faut aussi laisser entrer les échanges qui commencent. Le texte ne dit pas que ce seuil est aujourd'hui atteint, mais il précise la limite de la promesse faite aux opérateurs déjà présents.

Ce que l'on réserve compte autant que la quantité

AFRINIC sépare deux usages. Un /16 est réservé au réseau de peering, celui où les participants échangent leur trafic ; l'équivalent d'un autre /16 sert à la gestion, notamment à la supervision, aux statistiques, au courrier et aux tickets d'assistance. Les adresses de gestion ne doivent pas provenir du bloc de peering.

À la réunion, les équipes ont signalé des échanges de préfixes entre ces deux usages, contraires à la politique, et indiqué travailler avec les membres pour les corriger. Le passage ne précise ni leur nombre ni les raisons de ces pratiques. Agrandir le stock ne suffirait pas forcément à remettre un usage ou un registre en ordre.

Une autre nuance concerne la section 5.6.4.1. La limite /24 porte sur la longueur du préfixe, pas sur un maximum de 256 adresses : un préfixe plus court désigne un bloc plus grand. Plusieurs attributions restent possibles dans certains cas. Cette disposition n'accorde pas pour autant automatiquement la taille demandée.

Quant aux critères de candidature des IXP, ils vérifient notamment la présence juridique en Afrique — éventuellement par l'intermédiaire d'une organisation représentante —, les ASN et coordonnées d'au moins trois pairs BGP et/ou leurs accords signés, ainsi que le caractère public et ouvert de l'échange. Établir qui peut recevoir des adresses n'est pas prévoir combien il en faudra ensuite.

Doubler le stock, ou mieux préparer la suite ?

Paul Hjul a posé la question d'une réserve /15 plutôt que /16, soit deux fois plus d'adresses. James Chirwa a renvoyé le choix à la communauté et annoncé des statistiques de consommation. Gregoire Ehoumi a demandé le nombre de membres concernés. Cet échange ne vaut pas adoption d'une nouvelle taille.

Les chiffres permettraient de distinguer une pénurie globale, un manque de blocs voisins et un problème d'affectation entre usages. Un même pourcentage d'occupation peut masquer des situations qui appellent des réponses différentes. La présente vérification n'a pas établi quand les statistiques annoncées ont ensuite été publiées ; elle ne permet pas d'affirmer qu'elles ne l'ont pas été.

Jordi Palet a également proposé d'examiner la RFC 8950. Elle permet d'annoncer des routes IPv4 avec un prochain saut en IPv6 : l'adresse qui indique l'étape suivante peut donc relever d'un autre protocole. Les pairs BGP doivent toutefois prendre en charge la capacité requise. Cela ouvre une option technique, sans démontrer que tous les participants et serveurs de routes d'un échange sont prêts à l'utiliser.

Deux demandes légitimes peuvent donc se rencontrer devant le même espace libre. L'échange déjà installé veut éviter un nouveau chantier ; celui qui arrive veut commencer à raccorder ses réseaux. La réponse ne peut être de réserver tout, pour toujours, ni de supposer que déplacer les autres ne leur demande aucun travail.

Le cas de Johannesburg ne mesure pas la demande africaine. Il rappelle ce qu'une décision de réserve finit par devenir : des équipes qui peuvent agrandir leurs connexions sur place, ou qui doivent préparer ensemble un changement d'adresses. La question pour AFRINIC est de rendre ce choix prévisible avant que le prochain bloc soit nécessaire.

Rectification du 21 octobre 2026 : nous précisons le sens de /24 dans la section 5.6.4.1 et la condition de maintien des blocs voisins. Nous retirons aussi l'obligation de licence attribuée à tort au tableau des critères IXP, sans suggérer une exemption des lois nationales applicables. L'URL et la date de publication initiales restent inchangées.