Résumé

  • Le projet actuel de V6OPS définit « IPv6 uniquement » par l’usage natif observé dans un périmètre nommé, et non par les protocoles installés ni par l’état uniforme de tout un réseau.
  • La traduction NAT64, DNS64 ou 464XLAT, un service IPv4aaS, un amont en double pile ou un plan de gestion IPv4 peuvent rester indispensables sans contredire une affirmation locale correctement formulée.
  • Un registre de périmètre et de dépendances doit relier le libellé à l’objet observé, à la méthode, aux exceptions, au responsable et à la condition qui autorisera sa révision.

Le mot « uniquement » ne suffit pas

Un opérateur annonce que son accès est « IPv6 uniquement ». L’information peut être techniquement précise : aucun paquet IPv4 n’est acheminé nativement sur cette liaison. Pourtant, l’abonné continue d’ouvrir un service hébergé seulement en IPv4. Une fonction CLAT dans l’équipement client et un traducteur NAT64 chez l’opérateur assurent le passage. Le protocole historique a quitté une portion du réseau ; le besoin qu’il satisfait n’a pas disparu.

Cette scène résume l’intérêt du projet de groupe de travail IPv6-Only and IPv6-Mostly Terminology Definitions. Sa révision 02 date du 11 septembre 2026 et l’annonce officielle la présente comme un document de travail de V6OPS. Le Datatracker l’indique actuellement en dernière lecture du groupe. Ce statut ne vaut ni publication en RFC ni consensus final. L’historique et le différentiel entre 01 et 02 rappellent qu’il s’agit encore d’un texte révisable.

Le texte de la révision 02 apporte une discipline simple : le qualificatif décrit la fonctionnalité réellement employée dans un périmètre donné, pas la capacité installée d’un nœud. Un appareil peut prendre en charge IPv4 et IPv6, mais n’utiliser nativement qu’IPv6 sur une interface. IPv4 peut néanmoins être encapsulé ou traduit au-dessus de cette liaison. Le fait contrôlable est donc « IPv6 est le seul protocole natif ici », pas « IPv4 a été éliminé de l’organisation ».

En gouvernance, la différence est décisive. La première proposition porte sur un objet limité et observable. La seconde emporte des affirmations sur les applications, les fournisseurs, les passerelles, les clients, les procédures de secours et les destinations extérieures. Lorsque le nom du périmètre disparaît dans un rapport de direction, une vérité locale se transforme sans débat en conclusion institutionnelle.

Natif, transporté, encore nécessaire

Le projet appelle IPv6-Only l’état où seul IPv6 est natif dans le périmètre déclaré. IPv4 n’y est ni configuré ni administré, mais il peut être transporté sur IPv6. La variante IPv6-Only-Strict ajoute une contrainte : IPv4 n’est plus transporté, encapsulé ou traduit dans ce même périmètre.

Ce mot « strict » évite de confondre deux étapes. La suppression d’IPv4 natif peut libérer des adresses, réduire certains états et simplifier l’accès. L’extinction de toute compatibilité IPv4 suppose en plus que les applications, les partenaires et les services distants n’en aient plus besoin. Les deux progrès sont réels ; leurs preuves ne sont pas interchangeables.

Les normes de transition montrent où passe la responsabilité. RFC 6877 définit 464XLAT, combinaison de traductions qui permet à des applications ou hôtes IPv4 de fonctionner sur un accès IPv6. RFC 6146 spécifie NAT64 avec état entre clients IPv6 et serveurs IPv4 ; RFC 6147 décrit la synthèse DNS64. RFC 8585 encadre les fonctions attendues d’un routeur client pour les mécanismes IPv4-as-a-Service.

Ces outils ne sont pas le signe automatique d’une transition ratée. Ils déplacent une fonction. Ce déplacement modifie les coûts, les points de panne et l’autorité opérationnelle : capacité du traducteur, comportement des applications, résolution de noms, journalisation, assistance client et responsabilité du fournisseur. Un indicateur qui ne conserve que le mot « IPv6 » rend cette nouvelle surface de contrôle invisible.

Dans un centre de données, RFC 7755 permet à des nœuds internes IPv6 de servir des clients IPv4 à travers des relais SIIT-DC. L’intérieur peut légitimement être qualifié d’IPv6 uniquement. Mais les mappages, les relais en bordure et la demande IPv4 entrante constituent encore des dépendances. L’architecture a concentré la compatibilité ; elle ne l’a pas abolie.

Le périmètre appartient à la proposition

Le projet distingue liaison d’accès, segment, hôte, service, API, plan de données, plan de contrôle et administration. Cette énumération n’est pas décorative. Un réseau mobile peut avoir un contexte de données IPv6 uniquement, offrir une expérience en double pile aux applications grâce à CLAT, et dépendre d’un NAT64 en amont. Une entreprise peut exploiter un VLAN IPv6 uniquement à côté de segments en double pile. Un plan de données peut être IPv6 tandis que le plan de contrôle ou la récupération hors bande conserve IPv4.

Dans chacun de ces cas, retirer le substantif renforce la phrase. « Accès IPv6 uniquement » devient « réseau IPv6 uniquement », puis « entreprise IPv6 uniquement ». Or aucune nouvelle observation n’a été produite entre ces formulations. Le périmètre n’est donc pas une note de bas de page : il fait partie du fait attesté.

Cette précision protège aussi les comparaisons. Deux organisations peuvent annoncer la même étiquette tout en poursuivant des objectifs différents. L’une retire IPv4 natif de l’accès résidentiel mais maintient NAT64. L’autre teste un segment strict sans aucune communication vers des destinations IPv4. Un classement unique effacerait leurs contraintes et leurs risques résiduels. Un enregistrement structuré permet de mesurer chaque choix contre sa propre frontière.

La charte de V6OPS insiste justement sur les pratiques de déploiement dans des environnements particuliers. La terminologie commune doit rendre ces expériences comparables sans imposer une architecture universelle. C’est également l’esprit de l’essai de Heng Lu, Minimum Initial Specification, Localized Future Decision, Voluntary Adoption : la couche partagée fixe un minimum, tandis que les décisions de déploiement et leur révision restent locales.

« Majoritairement » ne désigne pas une proportion

Le terme IPv6-Mostly pourrait suggérer un pourcentage de trafic. Le projet lui donne une signification fonctionnelle : un périmètre en double pile dispose de NAT64 et de l’option DHCPv4 108, avec DNS64 éventuellement, pour faire cohabiter clients IPv4, double pile et IPv6. IPv4 est attribué à la demande.

RFC 8925 décrit le mécanisme. Un client capable sollicite l’option 108. Si le serveur la renvoie correctement, le client peut renoncer à l’adresse IPv4 offerte pendant l’intervalle indiqué ou jusqu’à un nouvel événement de rattachement. La capacité est propre à l’interface ; le même appareil peut prendre une autre décision ailleurs.

Le nombre de baux IPv4 baisse alors sans que toutes les dépendances IPv4 disparaissent. Le traducteur reste nécessaire pour certaines destinations. Des hôtes anciens peuvent encore recevoir une adresse. Une reconnexion peut rouvrir la configuration. Compter les baux mesure l’allocation ; observer le trafic natif mesure la liaison ; inventorier les traducteurs mesure l’infrastructure ; tester les destinations mesure un résultat. Aucun chiffre isolé n’est une preuve de retrait complet.

Un registre de périmètre et de dépendances

Une preuve proportionnée n’exige ni topologie publique ni identifiants de clients. Elle exige que l’étiquette ne voyage pas seule. Pour chaque emploi, le registre devrait conserver :

  1. l’objet exact — interface, VLAN, service, cohorte d’applications, plan ou réseau complet ;
  2. la version du vocabulaire et l’étiquette choisie ;
  3. ce qui est nativement acheminé et la méthode d’observation ;
  4. la période ou la version de configuration concernée ;
  5. les transports, traductions, encapsulations et destinations IPv4 encore nécessaires ;
  6. les fonctions NAT64, DNS64, CLAT, SIIT-DC, mandataire ou CDN qui assurent la compatibilité ;
  7. les exceptions : terminaux anciens, outils de gestion, plans de secours ou contraintes de fournisseur ;
  8. le propriétaire de chaque dépendance et l’autorité qui peut changer l’étiquette ;
  9. le scénario de panne et la voie de retour ;
  10. la preuve attendue pour passer à l’état suivant et la décision qui remplacera l’enregistrement.

Le terme « registre » est préférable à « certificat ». Il conserve une décision datée, limitée et corrigeable. Il peut montrer une suite de retraits partiels sans promettre une finalité inexistante. Il peut aussi enregistrer un désaccord : l’équipe réseau voit une simplification, la sécurité une concentration de risque, la finance une économie d’adresses, et les applications une contrainte de compatibilité. La gouvernance n’a pas à fusionner ces lectures ; elle doit préserver les faits qui leur sont communs.

Dans The Policy Mirror, Heng Lu demande que la politique reflète les systèmes effectivement opérés et leurs incitations. Ici, cela signifie résister à la valeur symbolique d’une annonce de fin. Le libellé gagne en crédibilité lorsqu’il reste attaché au petit objet qu’il décrit.

Limites de l’enquête

Le dossier public ne démontre aucun étiquetage abusif par un opérateur. Il ne mesure ni l’adoption des mécanismes, ni leur performance, ni leur coût. La dernière lecture du groupe ne rend pas le texte définitif, et une future publication informative ne certifierait toujours aucune mise en œuvre.

L’analyse ne demande pas davantage la suppression précipitée des ponts IPv4. Ces ponts peuvent précisément permettre une adoption locale d’IPv6 sans exclure des utilisateurs. La question responsable est plus concrète : où se trouve la compatibilité, qui la contrôle, quel résultat rend-elle possible et quelle phrase reste vraie tant qu’elle existe ?

Une liaison IPv6 uniquement peut être un succès majeur. Elle reste une liaison. Conserver ces deux propositions ensemble transforme un slogan de transition en preuve gouvernable.

Sources