Résumé

  • Le manuel actuel de l’AFRINIC sépare les adresses de peering des adresses de gestion, prévoit un bloc réservé aux IXP et décrit un /24 adjacent pour faciliter une extension jusqu’au /23. À l’AFRINIC-37, le personnel a également signalé que certains membres permutaient ces préfixes, en contradiction avec la politique.
  • Andrew Owens, de NAPafrica, a décrit le cas de Johannesburg : deux blocs /23, une utilisation proche d’un /22 et, si la croissance se poursuivait, le besoin possible de deux /23 supplémentaires pour atteindre un /21. Il a indiqué qu’une renumérotation commencée huit ans auparavant n’était toujours pas achevée. C’est le témoignage d’un opérateur, pas une statistique régionale ni une durée type.
  • Avant de faire passer la réserve de /16 à /15, la communauté a besoin de données sur la consommation et les membres concernés, ainsi que d’un plan de croissance contiguë et de transition. Un pool plus grand peut réduire le risque de pénurie ; il ne garantit pas, à lui seul, que le bloc suivant sera utilisable là où l’IXP en a besoin.

Analyse

« Quelle taille ? » n’est qu’une des questions

La page actuelle du Consolidated Policy Manual présente la version 1.6 comme la version en vigueur et indique une publication le 17 novembre 2020. La section 11 de ce texte ne traite pas seulement d’un chiffre global. Elle distingue le LAN de peering, bloc contigu où les membres échangent du trafic, du LAN de gestion utilisé pour la supervision, les statistiques, la messagerie et d’autres services. Elle demande que les adresses de gestion proviennent d’un autre bloc. Elle décrit un bloc de peering dédié et publié, puis un /24 adjacent réservé afin de permettre à un échange de grandir jusqu’au /23 sans obtenir un nouveau bloc et renuméroter son réseau. La proposition prévoit un /16 pour le peering et un autre /16 équivalent pour la gestion. Le manuel

Pendant la réunion, un participant a demandé si le /16 réservé suffisait à l’ensemble de la région ou si un /15 serait plus adapté. Un /15 contient deux fois plus d’adresses qu’un /16 ; cette arithmétique ne dit toutefois ni combien d’assignations contiguës restent disponibles, ni à quel rythme le pool se remplit, ni quels demandeurs pourraient être bloqués. Le personnel de l’AFRINIC a annoncé des statistiques de consommation pour éclairer la délibération. Un autre participant a demandé le nombre de membres touchés avant que la communauté évalue l’urgence. Le procès-verbal de l’AFRINIC-37

Cette demande de données n’est pas un détail de procédure. La réserve est à la fois une règle d’inventaire et une règle d’attribution. Sa taille indique la quantité immobilisée. Les unités d’attribution et la règle d’adjacence déterminent si un opérateur peut agrandir son réseau. Les registres qui montrent qui a reçu quoi, pour quel usage et avec quelle marge constituent une troisième question. Une décision limitée au premier point peut augmenter le stock tout en laissant incertain le prochain palier de croissance.

Le non-respect décrit ne suffit pas à en expliquer la cause

Le compte rendu rapporte que des membres permutaient les préfixes de peering et de gestion, en dehors des paramètres de la politique, et que le personnel cherchait à les remettre en conformité. C’est un problème d’application. Le texte n’indique ni pourquoi ces échanges ont eu lieu, ni combien de membres sont concernés, ni si la règle, la tenue des dossiers, la procédure administrative ou les pratiques opérationnelles expliquent principalement la situation. Cette différence compte : réécrire la politique avant d’avoir identifié le mode de défaillance pourrait déplacer les mots sans modifier les usages.

Les sections 5.6.4 et 11 du manuel portent sur des sujets liés, mais distincts. La première décrit les assignations d’adresses aux infrastructures critiques, généralement limitées à /24 tout en permettant plusieurs assignations dans certaines situations. La seconde concerne les pools de peering et de gestion réservés aux IXP ; son /24 adjacent doit permettre un passage au /23 sans renumérotation. Le texte définit également un IXP comme une infrastructure physique de couche 2 exploitée par une entité unique, reliée à au moins trois fournisseurs d’accès et dotée d’une politique d’adhésion ouverte. Les critères publics de demande de l’AFRINIC ajoutent une preuve de présence légale, les AS et contacts des pairs — ou leurs protocoles d’accord signés —, le caractère public et ouvert du point d’échange, ainsi qu’une licence lorsque le pays l’exige. Les critères de l’AFRINIC

Ces tests d’éligibilité ne quantifient pas la demande future et ne garantissent pas que les blocs disponibles épousent la trajectoire de croissance d’un échange. De même, l’existence de préfixes utilisés pour un autre but ne permet pas de savoir si le personnel dispose des informations et des outils nécessaires pour repérer cette dérive avant qu’elle ne devienne une dépendance opérationnelle.

Le cas de Johannesburg révèle la géométrie, pas la demande continentale

Andrew Owens a déclaré que NAPafrica détenait deux /23 à Johannesburg, utilisait presque un /22 et aurait besoin de deux /23 supplémentaires pour atteindre un /21 si elle devait obtenir davantage d’espace. Il a aussi indiqué que la renumérotation de son installation de Johannesburg, commencée huit ans plus tôt, n’était pas terminée. Le compte rendu présente son expérience comme un cas particulier. Il ne donne ni dénominateur, ni série comparable d’IXP, ni estimation indépendante des coûts, ni chronologie expliquant la durée.

L’exemple reste instructif parce qu’il montre ce qu’un total de préfixes ne révèle pas. Quatre /23 ne forment un /21 que si les blocs sont contigus et correctement alignés. Un IXP qui s’est développé au moyen d’assignations séparées peut avoir besoin de davantage qu’un nombre d’adresses : il lui faut une suite praticable de blocs adjacents, une façon de maintenir les services pendant le déplacement et un délai suffisant pour coordonner les participants. Le mécanisme actuel du /24 adjacent vise explicitement une première extension jusqu’au /23.

Le témoignage d’Owens pose une question ultérieure : comment un échange qui a réussi cette étape peut-il aller au-delà ? Il ne démontre pas l’échec de la politique, mais invite à concevoir le palier suivant au lieu de le tenir pour acquis.

La réunion a également entendu une suggestion fondée sur la RFC 8950. Cette norme de l’IETF permet d’annoncer des routes IPv4 avec un next-hop IPv6 quand les pairs BGP ont négocié la capacité correspondante. C’est une option d’ingénierie, pas la preuve que tous les routeurs de service et tous les participants peuvent déjà s’y fier, ni que le LAN de peering IPv4 réservé est devenu superflu. RFC 8950

Publier les éléments avant de choisir le chiffre supérieur

Le procès-verbal établit que la communauté a posé deux questions différentes : de combien d’espace le pool régional a-t-il besoin, et comment un échange peut-il grandir sans renumérotations répétées ? Le personnel a reconnu la demande de chiffres sur la consommation et les membres touchés, puis s’est engagé à partager des statistiques pertinentes sur la liste de diffusion. Les documents publics examinés pour cet article ne permettent pas d’établir si, ni quand, cet engagement a été tenu. C’est une limite de l’enquête, pas la preuve que ces chiffres n’ont jamais circulé.

Le prochain document utile pourrait présenter les questions ensemble sans les confondre : pour les pools de peering et de gestion, la taille initiale, les assignations, les retours et l’espace restant ; le nombre de demandes contraintes ; la taille des blocs attribués ; et leur contiguïté. Il faudrait distinguer les assignations approuvées de la demande prévisionnelle, et préciser si « utilisation » signifie attribuée, déployée, annoncée en routage ou simplement détenue. Un tableau daté et documenté en dirait plus qu’un seul pourcentage.

À cet inventaire devrait s’ajouter un plan de transition : quels paliers de croissance la règle permet, comment les blocs adjacents sont maintenus, que faire lorsqu’un bloc ne peut plus être contigu, qui coordonne une renumérotation, et quelles garanties opérationnelles ou dérogations existent. Il ne s’agit pas de promettre qu’un bloc adjacent sera disponible pour toute demande. Il s’agit de rendre visible l’arbitrage entre conservation et migration évitable avant qu’il ne se joue dossier après dossier.

Si les données montrent que le /16 dédié approche de l’épuisement pour les assignations /23, un pool plus important peut se justifier. Si la demande se concentre sur quelques échanges qui ont besoin de paliers contigus plus grands, les mêmes données peuvent plutôt plaider pour une autre géométrie de réserve ou une transition progressive. Si les permutations de catégories dominent, un meilleur enregistrement et un soutien à la conformité peuvent être plus utiles qu’un doublement du stock. Le compte rendu, seul, ne permet pas de trancher.

L’ordre responsable est donc clair : publier ce qui reste dans le pool, indiquer les demandes qu’il ne peut satisfaire et montrer les trajectoires de croissance et de migration permises par la règle. La communauté pourra alors décider s’il faut davantage d’IPv4, une réserve de forme différente, de meilleurs registres ou une combinaison de ces réponses. Le cas de NAPafrica donne une idée du coût possible d’un mauvais ordre. Seules des données publiques plus larges diront à l’AFRINIC à quelle fréquence ce coût risque de se reproduire.

Sources