Résumé

  • Le 4 septembre 2026, l’IESG a approuvé la révision du NAT64 avec état comme Internet Standard. Cette décision reconnaît une technique mûre et largement déployée ; elle ne certifie ni un produit, ni le dimensionnement d’un pool, ni la continuité d’une installation.
  • Le traducteur attribue à de nombreux clients IPv6 des droits temporaires sur des couples adresse-port IPv4 rares. Il faut conserver séparément associations, sessions, filtres, horloges, réplication et preuves applicatives pour établir capacité et responsabilité.

Le NAT64 avec état donne une apparence de continuité à deux mondes qui ne parlent pas la même version d’IP. Un client uniquement IPv6 contacte un serveur IPv4 ; le traducteur emprunte une adresse publique et un port, transforme les paquets et garde la mémoire nécessaire au retour. Avec DNS64, ni le client ni le serveur ne doivent être modifiés.

La simplicité est dans l’expérience des extrémités. La concentration est au milieu.

Dans son annonce officielle, l’IESG a approuvé le 4 septembre draft-ietf-v6ops-rfc6146-bis-16 comme Internet Standard. Le texte doit remplacer RFC 6146 et rejoindre STD 103. La fiche Datatracker indique que l’annonce d’approbation a été envoyée tandis que le travail IANA se poursuit. Le numéro définitif du futur RFC ne figurait pas encore dans les éléments examinés.

La décision est donc réelle, mais son objet est précis : la maturité d’un comportement commun. Elle n’est ni un certificat d’exploitation ni un constat de service rendu.

Ce qui a mûri, et ce qui demeure local

La version 16 approuvée résout deux errata sans modifier le comportement du protocole, clarifie la préservation de la parité des ports, actualise les références et ajoute une section non normative sur l’exploitation. Le socle reste RFC 6146, inscrit dans le cadre de traduction décrit par RFC 6144.

La longue liste d’implémentations explique en partie l’avancement. Elle nomme des fournisseurs, logiciels libres, plateformes et services. Le document ajoute toutefois une réserve décisive : ces indications viennent de sources publiques, ne valent pas aval de l’IETF et n’ont pas été formellement confirmées par des essais d’interopérabilité propres à cette publication. RFC 7942 conçoit d’ailleurs ces inventaires comme une aide aux travaux de normalisation, non comme une homologation.

Le raisonnement de Running-Code Primacy s’applique directement. Le statut indique où regarder. Seuls le code exécuté, la configuration et les observations disent ce qu’un service particulier accomplit.

Le pool ne prête pas des adresses, mais des adresses de transport

Le traducteur dispose d’un nombre limité d’adresses IPv4 publiques. Pour les partager, il attribue normalement un couple adresse-port UDP ou TCP, ou un couple adresse-identifiant ICMP. Ce couple est une adresse de transport IPv4. Il forme le droit temporaire utile.

Cette précision change l’audit. Une adresse publique seule peut représenter simultanément un grand nombre d’abonnés. Même un port ne suffit pas sans protocole, instant, précision d’horloge et génération du traducteur. À l’expiration, le même couple peut revenir à un autre client.

L’allocation cherche à préserver une plage et la parité du port lorsque les ressources le permettent. Si aucun couple approprié n’est disponible, le traducteur peut envoyer une erreur ICMPv6 ; la politique locale peut aussi supprimer ce message. Une expiration côté application ne révèle donc pas automatiquement un manque d’adresses. Elle peut provenir de l’allocation, d’un filtre, d’un message silencieux, d’une route, du serveur IPv4 ou de l’application.

Le partage économise IPv4, mais densifie l’état. RFC 6269 analyse les effets du partage d’adresses, notamment l’attribution et les hypothèses des applications. RFC 6888 précise les exigences courantes de journalisation des traducteurs à grande échelle. Le nouveau texte dit lui-même qu’une allocation dynamique maximisant les ports par adresse réduit le pool nécessaire tout en grossissant les journaux.

Une association n’est pas une session

Le protocole maintient trois bases d’associations, ou BIB : UDP, TCP et requêtes ICMP. Chaque ligne relie une adresse de transport IPv6 à une adresse de transport IPv4. Trois tables de sessions décrivent ensuite les paires effectivement en communication et leur état.

Cette distinction doit survivre aux tableaux de bord. Une association indépendante de la destination peut servir plusieurs sessions. Une association configurée manuellement peut exister sans session et n’être supprimée que par une action explicite. Une session TCP traverse des phases et des délais différents. Une requête ICMP emploie un identifiant, pas un port.

Le registre opérationnel doit donc relier deux identités sans les confondre : création et génération de la BIB, source du couple IPv4, sessions rattachées, paquet ayant rafraîchi l’échéance, motif de suppression et réutilisation ultérieure. Un compteur « traductions actives » ne peut pas raconter cette succession.

La méthode des couches de réalité empêche précisément cette compression. « NAT64 activé » décrit une configuration. Une BIB décrit un droit interne. Une session décrit une relation de protocole. Un paquet traduit est une observation. La transaction utilisateur appartient encore à une autre couche.

Le mappage n’est pas le filtrage

Le NAT64 avec état impose un mappage indépendant de la destination : dans la durée de l’association, la même adresse de transport externe peut être utilisée vers plusieurs destinations. Mais ce choix ne décide pas quels paquets IPv4 pourront revenir.

Le texte place la propriété de sécurité dans le filtrage. Sans filtre, toute source IPv4 qui atteint une association valide peut potentiellement la traverser. Avec un filtre dépendant de l’adresse, le retour peut être limité aux adresses contactées auparavant par le client IPv6. RFC 4787 fournit les notions pour UDP ; RFC 5382 couvre le comportement et les délais TCP.

Un dossier de conformité qui ne mentionne que le mappage laisse donc le choix de sécurité invisible. Il faut conserver le mode de mappage, le filtre, la politique par défaut, les exceptions, les associations statiques, la version de configuration et des essais de paquets autorisés et refusés.

Le sens « externe » est également une décision. Pour limiter la conservation hostile d’un état, l’opérateur peut décider que les paquets venant du côté Internet ne rafraîchissent pas l’échéance. Si ce côté est mal identifié, une règle raisonnable agit à l’envers. Le nom d’une interface ne suffit pas ; les routes et le comportement observé doivent confirmer la désignation.

Les délais arbitrent entre continuité et rareté

Chaque association dynamique vit sous une horloge. UDP et ICMP ont leur durée ; TCP possède des états transitoire, établi et fermeture ; les fragments utilisent une mémoire et une fenêtre bornées. À l’échéance, le système rend ports et mémoire au pool.

Une valeur courte peut casser une communication légitime restée silencieuse. Une valeur longue protège l’application mais immobilise davantage de ressources et laisse plus de prise à un maintien artificiel. Le texte rappelle que QUIC dépend de durées UDP raisonnables et qu’un identifiant de connexion QUIC ne doit pas devenir une clé d’état NAT.

L’autorité de l’horloge doit apparaître dans la preuve : règle active, instant de création, source du dernier rafraîchissement, échéance prévue, suppression anticipée et génération de politique. Une chute du nombre de sessions peut signifier une récupération de capacité ou une perte de continuité. Le graphique seul ne tranche pas.

Une concentration assumée doit être mesurée

La section de sécurité décrit des ressources finies : adresses et ports IPv4, mémoire, processeur et capacité de lien. Des sources IPv6 variées peuvent épuiser les couples disponibles ; fragments et SYN peuvent occuper la mémoire ; des paquets périodiques peuvent tenter de maintenir un état.

Ce sont des risques reconnus par le protocole, non la preuve d’une attaque actuelle. Aucun incident nommé n’est établi ici. Ils imposent cependant de mesurer séparément le pool libre, les ports par plage et protocole, les BIB, les sessions, la mémoire de fragments, la latence d’allocation, les rejets et les messages supprimés.

RFC 9693 fournit une méthode de banc d’essai pour les passerelles NAT avec état. Le résultat reste attaché au matériel, au logiciel, à la configuration, au profil de trafic et à la taille des paquets. Un chiffre de laboratoire n’est pas une capacité héritée par toute installation.

Le choix de ne pas imposer un dimensionnement universel est légitime. La doctrine de la spécification initiale minimale sépare utilement le mécanisme commun des décisions futures et locales. Cette liberté ne dispense pas l’opérateur de répondre de son pool, de ses filtres et de son seuil de surcharge.

Une haute disponibilité sans état n’est qu’une disponibilité de machine

Un nœud de secours peut répondre à une sonde tout en ignorant les droits créés par le nœud actif. RFC 7269 et RFC 8683 rassemblent l’expérience de déploiement et abordent la haute disponibilité. Ils n’imposent pas une réplication universelle.

L’essai décisif conserve avant la bascule les générations active et de secours, le dernier point répliqué, les BIB et sessions manquantes, l’écart des délais et la propriété du pool. Après bascule, il observe quelles communications UDP, TCP et ICMP continuent, lesquelles sont recréées et lesquelles échouent.

Deux nœuds vivants peuvent aussi constituer un partage de cerveau. S’ils allouent le même pool sans propriété réconciliée, ils risquent des droits contradictoires. Un secours prudent évite le conflit en rejetant l’état qu’il ne connaît pas, au prix de sessions perdues. Un produit ne peut choisir silencieusement ce compromis à la place du responsable de service.

L’attribution requiert des horloges et des générations

RFC 8158 définit des éléments IPFIX pour suivre les ressources NAT. Ces compteurs et événements peuvent éclairer consommation et seuils. Ils ne relient pas automatiquement l’adresse externe, la BIB, la session, l’identité d’abonné, le paquet et l’action applicative.

Une investigation doit fonctionner dans les deux sens. Depuis un couple externe et un instant, retrouver pool, traducteur, génération, BIB, session et contexte IPv6. Depuis un client, reconstruire le couple externe et son intervalle de validité. Chaque jointure doit porter le décalage d’horloge, l’incertitude et la politique de conservation. Un résultat ambigu doit rester ambigu.

Le statut Internet Standard ne confère aucune autorité probatoire automatique au journal de l’opérateur. Il ne décide pas du droit local, n’identifie pas une personne, ne démontre pas une commande applicative et ne répartit pas la responsabilité.

L’approbation est importante justement parce qu’elle est bornée. Elle offre une référence commune plus mûre pour la traduction. Elle ne retire ni l’état, ni la rareté, ni le point de concentration. Le déploiement devient crédible lorsque ces pouvoirs locaux laissent des traces attribuables.

Sources