Summary

  • Le projet IETF, révision 10, examiné en Last Call jusqu’au 23 novembre 2026, propose d’utiliser 64:ff9b::/96 pour des destinations IPv4 privées ou partagées.
  • Les traducteurs côté client non administrés devraient accepter ces paquets par défaut. Les traducteurs administrés devraient offrir un interrupteur de désactivation et conserver, lors d’une mise à jour, le blocage préexistant.
  • La promesse d’un préfixe unique déplace le contrôle réel vers les routes, les listes d’accès et l’inventaire des espaces d’adressage locaux.

Un paquet destiné à un serveur interne peut aujourd’hui disparaître avant même de rencontrer le pare-feu. La raison se trouve dans RFC 6052 : le préfixe NAT64 bien connu ne doit pas représenter une adresse IPv4 non globale. Le traducteur doit jeter le paquet. Pendant seize ans, cette phrase a servi de vigile gratuit à des réseaux qui n’avaient peut-être jamais consigné la décision d’accès correspondante.

La révision 10 d’un projet du groupe v6ops veut changer le contrat. Le préfixe pourrait porter des adresses privées définies par RFC 1918 et des adresses partagées décrites dans RFC 6598. Un poste IPv6 seul pourrait ainsi joindre un service IPv4 interne par la même infrastructure de traduction qu’il utilise pour l’Internet. Le gain est concret pour une entreprise dont l’application de production conserve une adresse IPv4 littérale. La question décisive devient : quel poste, dans quel réseau, est autorisé à lui parler ?

Deux préfixes, trop de réponses

On pourrait réserver 64:ff9b::/96 aux destinations publiques et choisir un préfixe propre au réseau pour les autres. Cette division fonctionne mieux lorsque DNS64 fabrique la réponse et connaît la destination. Elle se complique quand un CLAT, traducteur côté client, construit l’adresse IPv6 à partir d’une adresse IPv4 sans consulter DNS. RFC 7050 et RFC 8781 annoncent des préfixes de traduction ; ils ne distribuent pas une table disant « tel bloc IPv4 passe par tel préfixe ».

Si le poste apprend les deux, il peut fabriquer deux adresses IPv6 pour une même destination publique. Les règles de sécurité, les journaux et les diagnostics doivent ensuite suivre les deux chemins. Même le préfixe local de RFC 8215 ne résout pas cette question de sélection lorsqu’il cohabite avec le préfixe connu. Le projet préfère donc lever l’interdiction d’origine et laisser un préfixe couvrir les deux familles de destinations IPv4.

Le changement de verbes normatifs compte davantage que la commodité. Le texte actuel de RFC 6052 impose le rejet. Le projet autorise la représentation d’une adresse non globale ; il demande au CLAT non administré de traduire par défaut et au traducteur côté fournisseur de traduire sauf configuration contraire. Ce dernier doit exposer la possibilité de refuser. Le pouvoir de dire oui ou non sort de l’interdit général et entre dans la configuration locale.

La frontière à nommer

Le projet reconnaît que des exploitants se reposent sur le rejet automatique comme barrière autour de leurs réseaux privés. Il recommande aux équipements administrés déjà conformes de garder leur comportement de rejet lors d’une mise à niveau. Une mise à jour logicielle ne doit pas devenir une autorisation d’accès improvisée. Pour ouvrir le passage, il faut une route correcte, puis une règle de pare-feu, une ACL ou un filtrage NAT qui lie source, destination et service.

L’adresse 10.0.0.1 fournit un test impitoyable. Deux filiales peuvent l’utiliser légalement pour deux machines différentes. La traduction rend le numéro transportable ; elle ne choisit pas la filiale. Une route par défaut mal pensée peut faire parvenir un trafic parfaitement traduit au mauvais système. La capacité technique et l’autorité d’accès ne se confondent pas. La première appartient au traducteur ; la seconde exige un responsable qui puisse expliquer le chemin et la permission.

Le document relève des comportements CLAT divergents : certains appareils rejettent déjà ces destinations, d’autres les traduisent. Il ne chiffre pas ces groupes. L’exploitant doit donc établir ses propres faits : quels clients synthétisent une adresse, quels traducteurs la rejettent, quels services privés correspondent à chaque numéro et dans quel domaine de routage ils résident. Sans cet inventaire, « activer NAT64 » ressemble trop à « ouvrir une porte dont personne n’a vérifié la pièce derrière ».

Le projet est encore en Last Call ; il n’a pas été publié comme RFC. Sa décision proposée est pourtant très lisible. L’interdiction générale cesserait de masquer les choix locaux. Ceux qui bénéficient d’un réseau IPv6 plus simple hériteraient aussi de la responsabilité de prouver que chaque passage vers l’IPv4 privé est voulu.

Projet IETF · RFC 6052 · RFC 1918 · RFC 6598