Résumé

  • RFC 9872 recommande l'option PREF64 des Router Advertisements de RFC 8781 lorsqu'elle est disponible ; la découverte DNS de RFC 7050 reste un repli pour l'absence de l'option et les anciens terminaux.
  • En multihoming, le préfixe seul ne suffit pas : il faut conserver son routeur annonceur, l'adresse source, le prochain saut, la durée de validité et le résultat auprès du traducteur.

Le terminal n'a pas reçu un faux préfixe. Il a perdu le contexte qui rendait ce préfixe vrai. Après une réponse DNS64 correcte, il synthétise une destination IPv6, choisit l'adresse source de l'autre fournisseur et expédie le paquet vers un accès où aucun traducteur correspondant n'est joignable.

RFC 9872 répond à cette panne de composition. Ce document de consensus IETF, publié en septembre 2025, demande aux terminaux d'essayer l'option de Router Advertisement définie par RFC 8781. Les opérateurs NAT64 devraient l'annoncer. La méthode DNS de RFC 7050 ne disparaît pas : elle peut servir si l'option manque ou si un ancien système ne la comprend pas.

Le PREF64 est le préfixe IPv6 utilisé pour fabriquer une adresse destinée à la traduction vers IPv4. RFC 6052 en fixe les formats. Il permet le DNS64 local de RFC 6147, le CLAT de RFC 6877 et la conversion de littéraux IPv4 abordée par RFC 8305. Ces fonctions ne prouvent ni le bon accès, ni la présence du traducteur.

RFC 7050 déduit le préfixe des réponses AAAA synthétiques pour ipv4only.arpa. ; RFC 8880 organise le traitement particulier de ce nom. La dépendance devient fragile si une application choisit un autre résolveur, si un résolveur local ignore l'exception ou si un VPN en tunnel partagé remplace le DNS tout en laissant une partie du trafic sur le lien local.

Avec deux fournisseurs, des DNS64 différents peuvent présenter des PREF64 différents. La réponse DNS ne fournit aucun rattachement fiable entre chaque préfixe, l'amont concerné, le préfixe source IPv6 et la passerelle par défaut. Le terminal peut donc connaître toutes les valeurs nécessaires et fabriquer une combinaison impossible. La donnée existe ; la relation a disparu.

Une Router Advertisement conserve mieux cette relation. RFC 4861 emploie déjà ces annonces pour la présence des routeurs et les paramètres du lien. RFC 8781 y ajoute un préfixe et une durée de vie. Le terminal peut mémoriser quel routeur a annoncé quel PREF64 ; une durée nulle permet d'en demander le retrait. Il ne s'agit pourtant pas d'un certificat : une RA peut être usurpée et un traducteur peut tomber.

Le contrôle du temps change aussi. La découverte DNS exige un aller-retour après la configuration de la pile. Son résultat reste en cache jusqu'à expiration du TTL, parfois fixé par un DNS64 externe. Une nouvelle RA peut diffuser immédiatement une valeur ou son retrait. L'enjeu est la capacité de corriger l'état du terminal, pas seulement la rapidité de connexion.

Déplacer le signal hors du DNS réduit les attaques par fausse réponse DNS, mais concentre l'attention sur le premier saut. RFC 6105 décrit RA-Guard ; il ne rend pas toute annonce légitime. RFC 9463 annonce des résolveurs désignés et leurs transports chiffrés, sans prouver qu'un PREF64 appartient à l'accès qui portera le paquet.

La coexistence est donc intentionnelle. Les terminaux conformes qui savent lire RFC 8781 la préfèrent ; les anciens peuvent encore exiger RFC 7050. RFC 9872 signale aussi que des systèmes mobiles modernes comprennent l'option alors que certains équipements de réseau mobile ne peuvent pas l'insérer. La fiche officielle prouve la publication, non le déploiement d'un opérateur particulier.

La primauté du code en fonctionnement de Heng Lu demande une preuve reproductible au bord du réseau. Sa spécification initiale minimale justifie un signal commun étroit et des décisions locales. Sa critique de la taxe dual-stack permanente oblige enfin à attribuer les coûts du résolveur, du routeur, du traducteur et de leur coexistence.

La leçon de RFC 9872 est sobre : découvrir une valeur n'autorise pas encore un chemin. Le terminal doit garder la provenance qui relie cette valeur à un routeur, puis observer si le paquet et l'application aboutissent réellement.

Sources