7. Support des Réseaux IPv6 Uniquement avec NAT64 et DNS64 (Supporting IPv6-Only Networks with NAT64 and DNS64)

Bien que de nombreux protocoles de transition IPv6 aient été normalisés et déployés, la plupart sont transparents pour les appareils clients. L'utilisation combinée de NAT64 [RFC6146] et DNS64 [RFC6147] est une solution populaire qui est déployée et nécessite des modifications dans les appareils clients. Une façon possible de gérer ces réseaux est que la pile réseau de l'appareil client implémente 464XLAT [RFC6877]. 464XLAT a l'avantage de ne pas nécessiter de modifications des logiciels en espace utilisateur; cependant, il nécessite une traduction par paquet si l'application utilise des littéraux IPv4 et n'encourage pas les logiciels d'application client à prendre en charge l'IPv6 natif. Sur les plateformes qui ne prennent pas en charge 464XLAT, le moteur Happy Eyeballs SHOULD suivre les recommandations de cette section pour prendre en charge correctement les réseaux IPv6 uniquement avec NAT64 et DNS64.

Les fonctionnalités décrites dans cette section SHOULD être activées uniquement lorsque l'hôte détecte l'un de ces réseaux. Une heuristique simple pour y parvenir consiste à vérifier si le réseau offre un adressage IPv6 routable, n'offre pas d'adressage IPv4 routable et offre une adresse de résolveur DNS.

7.1. Littéraux d'Adresses IPv4 (IPv4 Address Literals)

Si les applications clientes ou les utilisateurs souhaitent se connecter à des littéraux d'adresses IPv4, le moteur Happy Eyeballs devra effectuer une synthèse d'adresse NAT64 pour eux. La solution est similaire à "Bump-in-the-Host" [RFC6535] mais est implémentée à l'intérieur de la bibliothèque Happy Eyeballs.

Lorsqu'une adresse IPv4 est transmise à la bibliothèque au lieu d'un nom d'hôte, l'appareil interroge le réseau pour le préfixe NAT64 en utilisant "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" (Découverte du Préfixe IPv6 Utilisé pour la Synthèse d'Adresse IPv6) [RFC7050] puis synthétise une adresse IPv6 appropriée (ou plusieurs) en utilisant l'encodage décrit dans "IPv6 Addressing of IPv4/IPv6 Translators" (Adressage IPv6 des Traducteurs IPv4/IPv6) [RFC6052]. Les adresses synthétisées sont ensuite insérées dans la liste des adresses comme si elles étaient des résultats de requêtes DNS; les tentatives de connexion suivent l'algorithme décrit ci-dessus (voir Section 5).

7.2. Noms d'Hôtes avec Enregistrements AAAA Défectueux (Hostnames with Broken AAAA Records)

Au moment de la rédaction, il existe un nombre faible mais non négligeable de noms d'hôtes qui se résolvent en enregistrements A valides et en enregistrements AAAA défectueux, que nous définissons comme des enregistrements AAAA qui contiennent des adresses IPv6 apparemment valides mais ces adresses ne répondent jamais lorsqu'elles sont contactées sur les ports habituels. Ceux-ci peuvent être, par exemple, causés par:

• Faute de frappe de l'adresse IPv6 dans la configuration de la zone DNS

• Trous noirs de routage

• Pannes de service

Bien qu'un algorithme conforme aux autres sections de ce document gère correctement de tels noms d'hôtes sur un réseau à double pile, ils ne fonctionneront pas nécessairement correctement sur les réseaux IPv6 uniquement avec NAT64 et DNS64. Étant donné que les résolveurs récursifs DNS64 s'appuient sur les serveurs de noms faisant autorité envoyant des réponses négatives ("pas d'erreur pas de réponse") pour les enregistrements AAAA afin de synthétiser, ils ne synthétiseront pas d'enregistrements pour ces noms d'hôtes particuliers et transmettront plutôt l'enregistrement AAAA défectueux.

Afin de prendre en charge ces scénarios, l'appareil client doit interroger le DNS pour l'enregistrement A puis effectuer une synthèse locale. Étant donné que ces types de noms d'hôtes sont rares et, afin de minimiser la charge sur les serveurs DNS, cette requête A ne devrait être effectuée que lorsque le client a abandonné les enregistrements AAAA qu'il a initialement reçus. Cela peut être réalisé en utilisant un délai d'attente plus long, appelé "Last Resort Local Synthesis Delay" (Délai de Synthèse Locale de Dernier Recours); le délai est recommandé à 2 secondes. Le minuteur est démarré lorsque la dernière tentative de connexion est lancée. Si aucune tentative de connexion n'a réussi lorsque ce minuteur se déclenche, l'appareil interroge le DNS pour l'adresse IPv4 et, lors de la réception d'un enregistrement A valide, le traite comme s'il avait été fourni par l'application (voir Section 7.1).

7.3. Réseaux Privés Virtuels (Virtual Private Networks)

Certains réseaux privés virtuels (Virtual Private Network, VPN) peuvent être configurés pour gérer les requêtes DNS de l'appareil. La configuration pourrait englober toutes les requêtes ou un sous-ensemble tel que "*.internal.example.com". Ces VPN peuvent également être configurés pour router uniquement une partie de l'espace d'adressage IPv4, comme 192.0.2.0/24. Cependant, si un nom d'hôte interne se résout en une adresse IPv4 externe, ceux-ci peuvent causer des problèmes si le réseau sous-jacent est IPv6 uniquement. À titre d'exemple, supposons que "www.internal.example.com" a exactement un enregistrement A, 198.51.100.42, et aucun enregistrement AAAA. Le client enverra la requête DNS au résolveur récursif de l'entreprise et ce résolveur répondra avec ces enregistrements. L'appareil n'a maintenant qu'une adresse IPv4 à laquelle se connecter et aucune route vers cette adresse. Étant donné que le résolveur de l'entreprise ne connaît pas le préfixe NAT64 du réseau sous-jacent, il ne peut pas synthétiser l'adresse. De même, le résolveur récursif DNS64 du réseau sous-jacent ne connaît pas les adresses internes de l'entreprise, il ne peut donc pas résoudre le nom d'hôte. En raison de cela, l'appareil client doit résoudre l'enregistrement A en utilisant le résolveur de l'entreprise, puis synthétiser localement une adresse IPv6, comme si l'adresse IPv4 résolue était fournie par l'application (Section 7.1).