Résumé

  • AFRINIC réserve des blocs IPv4 distincts au peering et à la gestion des IXP ; une plage adjacente doit permettre l’extension sans renumérotation.
  • Le compte rendu d’AFRINIC-37 mentionne des statistiques de consommation promises, tandis que la documentation publique d’AFRINIC précise que son fichier de statistiques étendues ne distingue pas les ressources réservées.

Analyse

Une réserve peut paraître ample dans un inventaire et devenir insuffisante au moment de raccorder un réseau. Il n’y a pas contradiction : le total peut encore être important sans contenir le prochain préfixe contigu dont un IXP a besoin. À l’inverse, de l’espace adjacent peut subsister sans que les données publiées indiquent qui peut l’utiliser. La bonne question n’est donc pas seulement le nombre d’adresses portant l’étiquette « réservé », mais leur aptitude à remplir la fonction prévue.

Le Consolidated Policy Manual d’AFRINIC distingue le réseau local de peering, où les participants échangent du trafic, du réseau de gestion, qui sert notamment à la supervision, aux statistiques et au traitement des demandes. La section 11 prévoit des blocs distincts. Elle demande aussi de conserver un /24 contigu à chaque attribution de peering afin que l’IXP puisse évoluer vers un /23 sans migrer vers un bloc disjoint. Le texte réserve un /16 aux besoins futurs du peering et un autre /16 aux préfixes de gestion.

La contiguïté a une conséquence opérationnelle. Si un IXP doit déplacer son réseau de peering pour obtenir une plage plus vaste, ses participants doivent coordonner les changements d’adresses, les configurations des routeurs et les vérifications de service. La réserve adjacente vise à éviter cette opération particulière. Elle ne garantit pas toute croissance future ; elle précise la forme de l’espace à préserver.

Lors de la réunion AFRINIC-37 du 24 juin, le personnel est revenu sur la section 11 dans son rapport d’expérience d’application des politiques. Il a indiqué que la définition des infrastructures critiques figurait dans le manuel depuis plus de quinze ans et demandé si elle correspondait encore aux pratiques actuelles des IXP. Le procès-verbal mentionne que certains échanges avaient atteint le seuil du /23 et qu’une formulation plus claire serait utile aux IXP en croissance rapide. Il signale aussi des changements d’usage entre préfixes de peering et de gestion jugés non conformes.

La réunion a ensuite abordé l’échelle de la réserve. Un participant a demandé si le /16 destiné au peering à l’échelle régionale suffisait ou si un /15 conviendrait mieux. AFRINIC a répondu que des statistiques de consommation seraient communiquées pour éclairer la discussion. Un autre participant a demandé des chiffres concrets, notamment le nombre de membres concernés par les limites de la réserve, avant d’engager un travail de politique. Ce sont des questions consignées dans un procès-verbal, pas la preuve que le bloc actuel est épuisé.

La documentation publique révèle une limite de mesure. La page de gestion des ressources d’AFRINIC indique que les statistiques étendues répartissent les ressources entre disponibles, réservées et attribuées, mais précise que les ressources réservées ne peuvent pas être différenciées dans ce fichier. Des blocs réservés par politique sont visibles dans WHOIS ; cela ne permet toutefois pas de déduire le reliquat contigu du pool IXP, la part du peering et celle de la gestion, ni le nombre de demandes éligibles auxquelles il n’a pas été possible de répondre. Cette limite ne prouve pas qu’AFRINIC ne tient aucun registre interne.

Elle montre qu’un total public ne suffit pas pour trancher la question posée.

La pièce utile serait un relevé agrégé qui protège les membres. Pour chaque réserve, il indiquerait le bloc publié, sa finalité, le volume attribué, l’espace adjacent conservé, le plus grand préfixe libre et la date d’arrêté. Il ajouterait le nombre de demandes admissibles, approuvées, en attente ou non satisfaites, ainsi que les motifs, avec une localisation assez large pour ne pas exposer d’informations sensibles. Les réserves de peering et de gestion doivent figurer séparément : leur fusion gonflerait le total tout en masquant l’origine d’une éventuelle pression.

Le témoignage d’un participant apporte un exemple, pas un dénominateur régional. Un représentant de NAPafrica a décrit deux /23 à Johannesburg, une installation proche d’un /22 et une renumérotation difficile et longue. Le procès-verbal attribue ces éléments à ce représentant. Ils ne démontrent ni une contrainte générale pour les IXP africains, ni l’occupation des autres blocs, ni le refus d’une demande précise.

L’ordre des travaux devrait rester simple : publier le relevé, expliquer comment le personnel compte les attributions et l’espace adjacent, puis confronter ces mesures à la croissance vers /23 prévue par la règle. Si la demande dépasse réellement l’espace contigu disponible, la communauté pourra discuter de la taille des blocs, des critères d’éligibilité ou de la libération des réserves adjacentes. Si le problème relève plutôt du classement ou de la procédure d’attribution, agrandir le pool ne ferait qu’étendre l’opacité.

Sources

Procès-verbal de la réunion AFRINIC-37 · Consolidated Policy Manual, sections 11.0–11.5 · Gestion des ressources et statistiques AFRINIC · Présentations AFRINIC-37