Résumé

  • AFPUB-2026-v6-001-DRAFT02 conditionnerait toute nouvelle demande IPv4 à l’éligibilité IPv6, à un plan de déploiement et à des objectifs sur 12, 24 et 48 mois.
  • L’étude d’impact d’AFRINIC juge non définis la preuve attendue et le calcul des 25 premières destinations, et relève une charge potentiellement disproportionnée pour les petits opérateurs.
  • AFRINIC 37 n’a pas dégagé de consensus : le texte est retourné sur la liste de discussion et reste en débat, sans adoption ni mise en œuvre.

La rareté transforme l’incitation en condition d’accès

L’idée de départ est solide : une organisation qui sollicite un IPv4 rare ne devrait pas conserver un bloc IPv6 sans le déployer. Le projet imposerait une demande IPv6 simultanée à qui n’en possède pas. Les titulaires d’un espace IPv6 devraient eux aussi satisfaire les critères applicables et présenter un plan cohérent d’adressage et de déploiement.

Le texte associe ce plan à des pourcentages. Pour un réseau d’accès, il retient les 25 principales destinations du trafic IPv4 qui acceptent IPv6, avec 25 % au plus tard après 12 mois, 50 % après 24 mois et 75 % après 48 mois. Pour l’hébergement, il vise les enregistrements AAAA et l’accessibilité Internet : 25 %, 75 % puis 95 %. Le non-respect deviendrait une violation de politique.

La méthode de mesure devient donc une règle d’allocation. Une même valeur peut pourtant refléter un réseau non préparé, un client qui désactive IPv6 ou un service externe qui ne le propose pas.

Une réussite peut déplacer le dénominateur

La liste des 25 destinations IPv4 est mobile. Quand une grande plateforme passe effectivement en IPv6, son trafic sort du classement IPv4. Les destinations restantes sont alors précisément celles qui avancent moins vite. Le succès modifie le groupe servant à mesurer le succès suivant.

Dans un message RPD du 22 juillet, Jaco Kroon a décrit ce problème et proposé de mesurer plutôt la part des clients auxquels un IPv6 correctement routé est disponible, même s’ils ne l’activent pas. Il s’agit d’une proposition de participant, non d’une règle adoptée, mais elle révèle un principe utile : le dénominateur ne doit pas se dégrader parce que du trafic a quitté IPv4.

Un test stable pourrait figer une cohorte, une période d’observation et une méthode au début du plan. Il publierait séparément la capacité du réseau à fournir IPv6 et son utilisation réelle. La première dépend davantage de l’opérateur ; la seconde aussi des terminaux, des politiques clients, des applications et des contenus tiers.

Préparation, disponibilité et adoption ne sont pas synonymes

Un opérateur peut acheminer IPv6, déléguer des préfixes, configurer RA ou DHCPv6, prendre en charge le DNS et former son assistance. Un fournisseur d’accès de gros peut rester limité. Un client professionnel peut refuser IPv6. Une destination externe peut ne pas publier d’AAAA. Un terminal peut préférer IPv4.

Dans un commentaire archivé du 30 juin, Saul Stein a soutenu une meilleure adoption tout en rappelant que les politiques de sécurité des clients et la capacité du réseau d’accès échappent parfois au FAI. Il a aussi signalé le coût manuel pour les petits opérateurs. Ce sont des observations attribuées, pas des coûts mesurés, mais elles correspondent à la frontière de contrôle laissée ouverte par le projet.

Le registre de conformité devrait donc distinguer préparation, disponibilité et adoption. AFRINIC peut demander une infrastructure documentée et une offre réellement utilisable. Il doit être plus prudent avant de sanctionner un résultat que plusieurs acteurs déterminent.

L’étude d’impact confirme les lacunes

L’évaluation du 20 juin reconnaît que le projet peut favoriser un déploiement réel plutôt qu’une détention passive. Elle constate toutefois que la cohérence d’un plan n’est pas définie, que la méthode de mesure des destinations manque et que les preuves de conformité partielle ou de retard justifié ne sont pas précisées.

Elle relève aussi l’interaction avec la section 6.4.4 du CPM, qui permet déjà de justifier une demande IPv6 plus grande par la migration de clients IPv4 existants. AFRINIC recommande de placer les obligations de déploiement dans les sections IPv6, plutôt que de les introduire indirectement par l’atterrissage progressif IPv4.

L’empreinte opérationnelle serait large : MyAFRINIC, les processus Hostmaster et membres, l’outil de transfert, l’inscription, la facturation, les procédures et la formation devraient évoluer. Il faut donc définir le contrat de preuve avant d’y attacher une violation.

L’absence de consensus n’est pas une décision finale

La chronologie est brève et claire : la version 1 a été publiée le 22 mai 2026, la version 2 soumise le 14 juin, l’évaluation du personnel a suivi le 20 juin et AFRINIC 37 n’a pas dégagé de consensus le 24 juin.

Le procès-verbal d’AFRINIC 37 indique que toutes les préoccupations n’étaient pas résolues et que le consensus n’a pas été atteint. Le texte est retourné sur la liste. L’index officiel le classe toujours « Under Discussion ».

Une prochaine version peut préserver l’incitation IPv6 tout en fixant le dénominateur, la période, les preuves, les dépendances externes, le droit de corriger et les recours. Sans ces éléments, un pourcentage unique mélange action de l’opérateur, choix du client et progrès ayant déjà déplacé le trafic.

Conserver l’incitation, limiter le jugement

AFRINIC peut exiger un service IPv6 documenté, disponible sur un périmètre défini et mesuré honnêtement. L’adoption réelle mérite aussi d’être suivie, mais dans un registre de résultats distinct. Puisque l’accès à l’IPv4 rare donne à la règle une force économique, la sanction doit porter sur ce que le demandeur pouvait décider, construire et prouver.

Sources