Résumé

  • AFPUB-2026-v6-001-DRAFT02 est toujours en discussion et a été renvoyée à la liste RPD après AFRINIC-37 ; ce n’est pas encore une règle appliquée.
  • Le texte fixe des objectifs à 12, 24 et 48 mois, sans définir le dossier de mesure reproductible nécessaire à leur contrôle.
  • Le trafic vers des destinations externes et la joignabilité de services hébergés constituent deux branches distinctes.
  • Un reçu de mesure peut rendre une décision vérifiable sans publier de flux bruts, d’identités de clients ou de topologie.

Le meilleur argument de bonne foi est simple : l’accès futur à une ressource IPv4 rare pourrait être lié à un plan de transition IPv6 graduel, plutôt qu’à une exigence de migration immédiate à 100 %. Pour un demandeur sans espace IPv6, le projet prévoit d’accompagner la demande IPv4 d’une demande IPv6 et d’un plan cohérent de déploiement et d’adressage. Cela encadrerait l’éligibilité dans un processus privé de ressources numériques ; ce n’est ni une loi, ni une décision judiciaire, ni une modification de routage, ni une autorité sur l’architecture d’un opérateur.

La première branche concerne les destinations externes. Le projet vise les 25 principales destinations IPv4 réelles du demandeur qui sont compatibles IPv6, avec des minimums de 25 % à 12 mois, 50 % à 24 mois et 75 % à 48 mois. La seconde concerne les services, applications ou contenus hébergés : elle regarde la part des enregistrements AAAA disponibles et joignables en IPv6, avec des cibles de 25 %, 75 % et 95 %. Ces deux calculs ne mesurent pas la même relation et ne devraient pas être fondus en un score unique.

Le personnel de l’AFRINIC a relevé que le texte ne précise ni l’identification des 25 principales destinations, ni la validation de leur compatibilité IPv6, ni l’évaluation des pourcentages. Les preuves acceptables pour la conformité partielle ou pour un retard justifié ne sont pas davantage définies. À AFRINIC-37, l’auteur a cité NetFlow ou des outils similaires comme moyen simple d’observer les destinations majeures et a indiqué qu’un réseau comptant moins de 25 destinations pourrait utiliser l’ensemble disponible. Il s’agit d’une position attribuée, pas d’une preuve que NetFlow serait obligatoire, universellement disponible ou suffisant.

Le dénominateur est décisif. Inclure le transit, le peering, la sortie cloud, certains points d’accès ou seulement des interfaces échantillonnées peut modifier le résultat. Une semaine chargée, un mois saisonnier et une période de douze mois ne produiront pas forcément les mêmes principales destinations. Le classement par octets, flux, sessions, clients ou destinations distinctes crée également des listes différentes. Il faut préciser si les destinations sont choisies avant ou après le test IPv6 : sinon la sélection peut favoriser mécaniquement le résultat.

« Compatible IPv6 » doit aussi être défini : présence d’un enregistrement AAAA, visibilité d’une route, connexion réussie depuis un point d’observation déterminé, ou trafic IPv6 effectivement observé. Pour les services hébergés, il faut décider si les alias, les CDN, les échecs temporaires et les réessais entrent dans le calcul, et si le dénominateur est constitué d’enregistrements, de services, de noms ou de points joignables. La pondération peut favoriser un gros service, un petit client ou chaque enregistrement de manière égale.

Les exclusions sont tout aussi importantes : maintenance, panne, protections contre l’abus, données chiffrées, collecteurs absents, destinations privées et restrictions de conservation. Les taux d’échantillonnage, horloges, versions logicielles et configurations des collecteurs peuvent changer un pourcentage apparent. Sans ces paramètres, deux opérateurs peuvent produire le même chiffre à partir d’univers différents, sans pouvoir reconstruire ensuite la divergence. C’est une inférence limitée tirée du manque de spécification, non une accusation de manipulation, de discrimination ou de dommage.

La solution proportionnée serait un reçu de mesure, et non la publication de traces. Il devrait conserver l’identité du demandeur auprès du réviseur autorisé, la version du projet, la classe de mesure, les dates de début et de fin, l’univers admissible, la règle de sélection et le nombre de destinations, le test de compatibilité ou de joignabilité, la pondération ou le dénominateur des enregistrements hébergés, les exclusions et leurs codes, les outils et versions de configuration, le seuil applicable, le pourcentage observé et une empreinte de calcul.

Le dépositaire, le réviseur, les explications de conformité partielle ou de délai externe, ainsi que la décision, ses motifs, la voie de recours et l’historique des corrections devraient également être consignés.

La partie publique pourrait montrer les définitions, les dates, la classe du dénominateur, des hachages, le résultat et les corrections. Les flux bruts, identités, détails de destinations sensibles, configurations et topologie resteraient protégés. Aucun élément du dossier actuel ne permet de parler de mise en œuvre, de demande refusée, de violation ou de sanction. La proposition n’a pas obtenu le rough consensus à AFRINIC-37 et a été renvoyée à la liste ; elle demeure en discussion.

Sources

https://www.afrinic.net/afpub-2026-v6-001-draft02.html https://www.afrinic.net/policy-proposals.html https://www.afrinic.net/ppm-afrinic-37.html