Résumé

  • L’IESG a approuvé la version 16 de la spécification NAT64 avec état comme Internet Standard, tout en maintenant une séparation explicite entre association et filtrage.
  • Un contrôle sérieux doit prouver séparément le couple réutilisé, la règle d’admission entrante et le résultat observé pour chaque protocole et chaque interface.

Dans une recette de changement, quatre voyants passent au vert. Le même client IPv6 contacte quatre destinations IPv4 ; le traducteur lui attribue à chaque fois le même couple adresse-port public pendant la durée de l’association. L’équipe conclut correctement que le comportement d’association est indépendant de l’extrémité distante.

Le cinquième voyant est trompeur. Il porte le nom « sécurité entrante » et devient vert par héritage du test précédent. Aucun paquet issu d’une adresse IPv4 jamais contactée n’a pourtant été injecté. La configuration des filtres n’a pas été lue. Le sens de l’interface n’est pas consigné. Une preuve d’interopérabilité s’est transformée, par commodité de tableau, en attestation d’accès.

La normalisation récente rend cette confusion plus visible. Le 4 septembre 2026, l’IESG a approuvé la version 16 de Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers comme Internet Standard et a demandé son inscription dans STD 103. L’annonce indique que le texte doit remplacer la RFC 6146, que NAT64 avec état est largement implémenté et déployé, et qu’aucune controverse majeure n’a été identifiée.

Il faut néanmoins respecter la chronologie. À la date de cette analyse, la fiche Datatracker place encore le document dans la file du RFC Editor, avec une attente de réponse des auteurs. L’historique officiel retrace l’approbation, mais aucun numéro de RFC successeur n’est encore publié.

Le texte ne crée pas soudainement un nouveau pare-feu. L’annonce qualifie les errata 4756 et 8416 de corrections explicatives ou éditoriales, sans modification du comportement du protocole. L’annexe A de la version 16 dit la même chose. La RFC 6146 reste la référence historique que le futur texte remplacera. L’enjeu n’est donc pas d’attribuer à l’IETF une décision locale, mais d’identifier celle que l’opérateur a réellement prise.

L’association répond à la question « quel couple ? »

NAT64 avec état conserve des tables pour relier un couple de transport IPv6 à un couple IPv4. Pour TCP et UDP, il s’agit de l’adresse et du port. Quand un même couple interne reçoit le même couple externe pour des destinations différentes pendant la vie de l’association, le comportement est dit indépendant de l’extrémité.

Cette propriété aide les applications et les mécanismes de traversée. Un pair peut apprendre un couple public et le réutiliser. Mais elle ne désigne aucune source entrante autorisée. La RFC 4787 formule déjà cette limite pour UDP : les choix d’association ne changent pas les propriétés de sécurité du NAT, qui dépendent des paquets admis par le filtrage. La RFC 5382 reprend la distinction pour TCP et précise qu’un pair externe ne profite de l’association que sous réserve de la politique de sécurité.

La version 16 impose au traducteur d’offrir l’association indépendante de l’extrémité. Elle autorise aussi la prise en charge d’associations dépendantes de l’adresse. Aucune de ces capacités ne révèle le mode de filtrage actif sur une interface donnée. Le mot « indépendant » qualifie ici la réutilisation du couple, pas une permission universelle d’entrer.

Le filtre répond à la question « qui passe ? »

Une association existe. Sans filtrage, explique le projet approuvé, tout nœud IPv4 qui vise le couple public peut traverser la fonction NAT64 vers le couple IPv6 correspondant. Ce résultat ne vient pas du seul mode d’association : il vient de l’association plus l’absence de filtre.

À association identique, un filtre dynamique dépendant de l’adresse peut n’accepter que les adresses IPv4 précédemment contactées par l’hôte IPv6. Une interdiction explicite ou une règle de refus par défaut écarte les autres sources. La sécurité naît de cette règle et de son installation, pas du nom donné à l’allocation du port.

Le choix comporte un arbitrage. La RFC 4787 recommande le filtrage indépendant de l’extrémité lorsque la transparence applicative prime, et le filtrage dépendant de l’adresse lorsque la rigueur prime. Elle permet à l’administrateur de configurer le comportement. Pour TCP, la RFC 5382 ajoute que la politique peut différer de celle d’UDP. Un audit qui ne note qu’une propriété globale du boîtier efface donc une décision par protocole.

ICMP refuse encore davantage les raccourcis. La RFC 5508 s’appuie sur un identifiant de requête plutôt que sur un port. La correction de l’erratum 4756 précise qu’il n’existe pas, à l’étape concernée, de règle de filtrage dépendante de l’adresse analogue à TCP ou UDP. Copier le résultat d’un essai UDP dans la ligne ICMP ne simplifie pas la preuve ; cela change l’objet mesuré.

Les associations statiques révèlent le défaut du raccourci

Le chapitre de sécurité avertit qu’un filtrage limité au quintuplet peut être devinable dans certains cas d’association statique. Le traducteur peut suivre les numéros de séquence TCP afin de mieux vérifier SYN et FIN. Cette défense est facultative. Une traduction réussie ne dit ni si elle est active, ni si la politique prévue a effectivement été chargée.

Le traducteur gère aussi des ressources finies : couples IPv4, tables d’association et de session, mémoire de fragments et capacité des liens. Le texte décrit des limites de mémoire et l’importance de définir quelle interface fait face à Internet pour certains mécanismes de durée de vie. Sans le sens, le protocole, l’origine de l’association et les temporisations, un résultat « conforme » reste impossible à interpréter.

Les retours d’expérience de la RFC 7269 abordent notamment la haute disponibilité et la sécurité ; la RFC 8683 complète les recommandations de déploiement NAT64/464XLAT. Ces textes replacent la fonction dans un système exploité. Ils ne font jamais de la réutilisation d’un couple une preuve de pare-feu.

Produire une quittance à deux colonnes

Une quittance de décision association-filtrage permettrait de conserver la séparation. Elle identifierait le traducteur, sa version logicielle, le sens de l’interface et le protocole. Elle noterait ensuite le mode d’association, le mode de filtrage, l’action par défaut, l’origine statique, dynamique ou PCP de l’état, les temporisations, la version de politique, l’autorité d’approbation, les plafonds de ressources et l’échéance des exceptions.

La preuve d’exécution resterait elle aussi dédoublée. Un premier jeu d’essais vérifierait la réutilisation du couple externe face à plusieurs destinations. D’autres paquets, positifs et négatifs, montreraient les sources acceptées ou rejetées. L’état des règles installées, les compteurs et les alarmes fermeraient l’écart entre intention et fonctionnement.

La quittance ne certifie ni un produit entier ni un déploiement éternel. Elle affirme seulement qu’à une date donnée, pour ce protocole et cette interface, l’association et le filtre ont produit ces résultats. Une bascule, une mise à niveau, une nouvelle association statique ou une modification de temporisation périme la partie concernée.

The Policy Mirror invite à chercher le point où une règle devient effective : l’allocation pour l’association, le chemin entrant pour le filtre. Running-Code Primacy demande un résultat observable pour chacune. Reality, Not Advocacy interdit enfin de transformer les options du standard en jugement sur un opérateur qui n’a pas été audité.

Sources