Summary

  • Le 2 novembre, l’IESG a lancé la dernière consultation sur draft-ietf-v6ops-nat64-wkp-1918-10; les commentaires sont attendus avant le 23 novembre.
  • Le texte propose d’autoriser des destinations IPv4 privées sous 64:ff9b::/96. La révision 10 ajoute une recommandation pour rendre visible la conduite par défaut des traducteurs administrés.

Le préfixe connaissait déjà la réponse

Dans la RFC 6052, le préfixe bien connu de NAT64, 64:ff9b::/96, ne peut représenter une adresse IPv4 non joignable globalement. Le traducteur doit jeter le paquet. Cette règle transforme l’accès d’un poste uniquement IPv6 à un service IPv4 interne en problème d’architecture réseau.

L’appel à commentaires du 2 novembre porte sur une autre répartition des décisions. La révision 10 autoriserait le préfixe pour les adresses privées de la RFC 1918 et l’espace partagé de la RFC 6598. Les CLAT non administrés traduiraient ces paquets par défaut. Les PLAT administrés les traduiraient sauf réglage contraire et devraient offrir un moyen de désactiver cette fonction. L’exploitant récupère ainsi une décision que la règle commune avait prise pour lui.

Les auteurs expliquent pourquoi deux préfixes ne règlent pas simplement le problème. Les mécanismes largement déployés de découverte NAT64 n’indiquent pas au client quelle partie de l’espace IPv4 correspond à chacun. Un client qui découvre deux préfixes peut en fabriquer deux adresses même pour une destination publique. Le projet signale aussi des CLAT existants aux comportements divergents, certains rejetant et d’autres traduisant. Il ne chiffre pas leur répartition.

Le nouvel article 4.3 veut voir l’état réel

La permission de traduire et le bouton de désactivation figuraient déjà dans la révision 09. La révision 10 introduit une recommandation plus intéressante pour l’exploitation : les traducteurs administrés devraient exposer leur valeur initiale pour les adresses non globales. Les exploitants devraient contrôler l’accord entre le réglage et la politique voulue, par configuration explicite ou observation. La transmission dépend également des routes présentes autour du traducteur.

Le chapitre consacré à la sécurité protège une autre réalité : les PLAT déjà conformes à la RFC 6052, qui rejettent ces paquets par défaut, devraient garder cette valeur lors d’une mise à jour. Un même parc peut donc mêler de nouveaux comportements et d’anciens réglages conservés. Une fiche portant « compatible NAT64 » ne dit pas lequel des deux reçoit le paquet.

La preuve utile tient dans une série courte : version du logiciel, valeur initiale, modification explicite, route, règle de filtrage et essai de paquet vers une destination privée. Les sources publiques ne donnent pas la configuration ni les essais d’un réseau nommé; ces éléments trancheraient son cas.

Sources