Résumé

  • La RFC 9872 recommande aux terminaux d’obtenir le préfixe de synthèse NAT64 via l’option PREF64 des annonces de routeur définie par la RFC 8781.
  • Le choix fixe aussi une portée opérationnelle : préfixe, durée de vie et chemin amont restent associés au réseau qui fournit le traducteur.

Le problème apparaît avant même le premier paquet traduit. Un terminal vient de rejoindre un réseau IPv6 seul et veut joindre une destination IPv4. Pour fabriquer l’adresse IPv6 correspondante, il lui faut un préfixe accepté par le traducteur NAT64 du réseau. Un préfixe syntaxiquement correct mais appris dans un autre contexte conduit à une destination qui ne mène nulle part.

La RFC 9872 place cette configuration au moment de l’attachement. Le terminal devrait d’abord lire PREF64 dans les annonces de routeur selon la RFC 8781, et l’opérateur NAT64 devrait l’y publier. La méthode DNS de la RFC 7050 subsiste lorsque l’option n’est pas annoncée ou ne peut pas être traitée, mais elle devient un repli explicite.

Une option qui lie valeur et contexte

La RFC 8781 attribue le type 38 de Neighbor Discovery à PREF64. L’option transporte les bits du préfixe, un code de longueur et une durée de vie exprimée par pas de huit secondes. Une durée nulle retire le préfixe. La spécification déconseille une durée PREF64 inférieure à celle du routeur par défaut : le préfixe pourrait expirer alors que le routeur paraît encore valable.

Le terminal doit considérer le préfixe comme propre au réseau où il l’a reçu. S’il gère les Provisioning Domains, il doit l’associer au PvD concerné. Plusieurs préfixes annoncés avec une durée non nulle peuvent être utilisés ; plusieurs méthodes de découverte ne devraient toutefois pas être mélangées au hasard.

Dans un système multihébergé, cette portée est essentielle. Le trafic synthétisé avec le préfixe d’un fournisseur doit emprunter un amont qui dispose du traducteur correspondant. La valeur ne peut être séparée de l’interface et du chemin qui lui donnent un sens.

Le DNS garde une place, mais pas toujours le bon point de vue

La RFC 7050 interroge un résolveur DNS64 pour un nom IPv4 spécialement défini, puis déduit PREF64 des réponses AAAA synthétisées. Or le résolveur effectif peut changer : DNS chiffré, VPN ou configuration manuelle peuvent placer la réponse hors du réseau d’accès. Ce résolveur distant ne connaît pas nécessairement le traducteur local.

Le cache complique aussi les changements. Une découverte DNS reste liée aux TTL. Une annonce de routeur peut au contraire transmettre immédiatement une nouvelle valeur ou une durée nulle, dans le même contexte de lien que l’information de routage.

La recommandation centrale se trouve dans la RFC 9872. Le format de l’option est défini par la RFC 8781, l’alternative DNS par la RFC 7050, et les formats et mécanismes de traduction par les RFC 6052 et 7915. Ces textes ne démontrent ni déploiement actuel ni disponibilité d’un traducteur.

La découverte ne prouve ni l’authenticité de l’annonce, ni l’accessibilité du traducteur, ni le déploiement, ni les performances. Elle ne rend pas non plus le Well-Known Prefix de la RFC 6052 valable sur tous les réseaux NAT64. Ces cinq affirmations exigent des preuves distinctes.