Aller au contenu principal

7. Deployment Scenarios and Examples

Dans cette section, nous illustrons comment DNS64 se comporte dans différents scénarios qui devraient être courants. En particulier, nous considérerons les scénarios suivants définis dans [RFC6144]: le scénario "d'un réseau IPv6 vers Internet IPv4" (à la fois avec DNS64 en mode serveur DNS et en mode résolveur stub) et la configuration "Internet IPv6 vers un réseau IPv4" (avec DNS64 en mode serveur DNS uniquement).

Dans tous les exemples ci-dessous, il y a un traducteur IPv6/IPv4 connectant le domaine IPv6 au domaine IPv4. De plus, il y a un serveur de noms qui est un nœud dual-stack, il peut donc communiquer avec les hôtes IPv6 en utilisant IPv6 et avec les nœuds IPv4 en utilisant IPv4. De plus, nous supposons que dans les exemples, la fonction DNS64 apprend quel préfixe IPv6 elle doit utiliser pour mapper l'espace d'adressage IPv4 via la configuration manuelle.

7.1. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64 in DNS Server Mode​

Dans cet exemple, nous considérons un nœud IPv6 situé dans un site IPv6 uniquement qui initie une communication vers un nœud IPv4 situé dans Internet IPv4.

Le scénario pour ce cas est représenté dans la figure suivante:

            +---------------------+         +---------------+
            |IPv6 network         |         |    IPv4       |
            |           |  +-------------+  |  Internet     |
            |           |--| Name server |--|               |
            |           |  | with DNS64  |  |  +----+       |
            |  +----+   |  +-------------+  |  | H2 |       |
            |  | H1 |---|         |         |  +----+       |
            |  +----+   |   +------------+  |  192.0.2.1    |
            |           |---| IPv6/IPv4  |--|               |
            |           |   | Translator |  |               |
            |           |   +------------+  |               |
            |           |         |         |               |
            +---------------------+         +---------------+

         Figure 4:  "An IPv6 Network to the IPv4 Internet" Setup
                      with DNS64 in DNS Server Mode

La figure montre un nœud IPv6 H1 et un nœud IPv4 H2 avec l'adresse IPv4 192.0.2.1 et le FQDN h2.example.com.

Le traducteur IPv6/IPv4 a une adresse IPv4 203.0.113.1 assignée à son interface IPv4, et il utilise le préfixe bien connu 64:ff9b::/96 pour créer des représentations IPv6 d'adresses IPv4. Le même préfixe est configuré dans la fonction DNS64 du serveur de noms local.

Pour cet exemple, supposons la situation DNS typique où les hôtes IPv6 n'ont que des résolveurs stub, et ils sont configurés avec l'adresse IP d'un serveur de noms qu'ils doivent toujours interroger et qui effectue des recherches récursives (ci-après appelé "le serveur de noms récursif").

Les étapes par lesquelles H1 établit la communication avec H2 sont:

  1. H1 effectue une recherche DNS pour h2.example.com. H1 fait cela en envoyant une requête DNS pour un enregistrement AAAA pour H2 au serveur de noms récursif. Le serveur de noms récursif implémente la fonctionnalité DNS64.

  2. Le serveur de noms récursif résout la requête et découvre qu'il n'y a pas d'enregistrements AAAA pour H2.

  3. Le serveur de noms récursif effectue une requête d'enregistrement A pour H2 et obtient en retour un RRSet contenant un seul enregistrement A avec l'adresse IPv4 192.0.2.1. Le serveur de noms synthétise alors un enregistrement AAAA. L'adresse IPv6 dans l'enregistrement AAAA contient le préfixe assigné au traducteur IPv6/IPv4 dans les 96 bits supérieurs et l'adresse IPv4 reçue dans les 32 bits inférieurs; c'est-à-dire que l'adresse IPv6 résultante est 64:ff9b::192.0.2.1.

  4. H1 reçoit l'enregistrement AAAA synthétique et envoie un paquet vers H2. Le paquet est envoyé à l'adresse de destination 64:ff9b::192.0.2.1.

  5. Le paquet est routé vers l'interface IPv6 du traducteur IPv6/IPv4, et la communication ultérieure s'écoule au moyen des mécanismes du traducteur IPv6/IPv4.

7.2. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64 in Stub-Resolver Mode​

Ce cas est représenté dans la figure suivante:

            +---------------------+         +---------------+
            |IPv6 network         |         |    IPv4       |
            |           |     +--------+    |  Internet     |
            |           |-----| Name   |----|               |
            | +-----+   |     | server |    |  +----+       |
            | | H1  |   |     +--------+    |  | H2 |       |
            | |with |---|         |         |  +----+       |
            | |DNS64|   |   +------------+  |  192.0.2.1    |
            | +----+    |---| IPv6/IPv4  |--|               |
            |           |   | Translator |  |               |
            |           |   +------------+  |               |
            |           |         |         |               |
            +---------------------+         +---------------+

         Figure 5:  "An IPv6 Network to the IPv4 Internet" Setup
                      with DNS64 in Stub-Resolver Mode

La figure montre un nœud IPv6 H1 implémentant la fonction DNS64 et un nœud IPv4 H2 avec l'adresse IPv4 192.0.2.1 et le FQDN h2.example.com.

Le traducteur IPv6/IPv4 a une adresse IPv4 203.0.113.1 assignée à son interface IPv4, et il utilise le préfixe bien connu 64:ff9b::/96 pour créer des représentations IPv6 d'adresses IPv4. Le même préfixe est configuré dans la fonction DNS64 dans H1.

Pour cet exemple, supposons la situation DNS typique où les hôtes IPv6 n'ont que des résolveurs stub, et ils sont configurés avec l'adresse IP d'un serveur de noms qu'ils doivent toujours interroger et qui effectue des recherches récursives (ci-après appelé "le serveur de noms récursif"). Le serveur de noms récursif n'effectue pas la fonction DNS64.

Les étapes par lesquelles H1 établit la communication avec H2 sont:

  1. H1 effectue une recherche DNS pour h2.example.com. H1 fait cela en envoyant une requête DNS pour un enregistrement AAAA pour H2 au serveur de noms récursif.

  2. Le serveur DNS récursif résout la requête et retourne la réponse à H1. Parce qu'il n'y a pas d'enregistrements AAAA dans le DNS global pour H2, la réponse est vide.

  3. Le résolveur stub sur H1 interroge alors pour un enregistrement A pour H2 et obtient en retour un enregistrement A contenant l'adresse IPv4 192.0.2.1. La fonction DNS64 dans H1 synthétise alors un enregistrement AAAA. L'adresse IPv6 dans l'enregistrement AAAA contient le préfixe assigné au traducteur IPv6/IPv4 dans les 96 bits supérieurs, puis l'adresse IPv4 reçue dans les 32 bits inférieurs; l'adresse IPv6 résultante est 64:ff9b::192.0.2.1.

  4. H1 envoie un paquet vers H2. Le paquet est envoyé à l'adresse de destination 64:ff9b::192.0.2.1.

  5. Le paquet est routé vers l'interface IPv6 du traducteur IPv6/IPv4 et la communication ultérieure s'écoule en utilisant les mécanismes du traducteur IPv6/IPv4.

7.3. Example of "the IPv6 Internet to an IPv4 Network" Setup with DNS64 in DNS Server Mode​

Dans cet exemple, nous considérons un nœud IPv6 situé dans Internet IPv6 qui initie une communication vers un nœud IPv4 situé dans le site IPv4.

Dans certains cas, ce scénario peut être traité sans utiliser aucune forme de fonction DNS64. Cela est dû au fait qu'il est possible d'assigner une adresse IPv6 fixe à chacun des nœuds IPv4. Une telle adresse IPv6 serait construite en utilisant l'algorithme de transformation d'adresse défini dans [RFC6052] qui prend comme entrée le Pref64::/96 et l'adresse IPv4 du nœud IPv4. Notez que l'adresse IPv4 peut être une adresse publique ou privée; cette dernière ne présente aucune difficulté supplémentaire, puisqu'un NSP doit être utilisé comme Pref64::/96 (dans ce scénario, l'utilisation du préfixe bien connu n'est pas supportée comme discuté dans [RFC6052]). Une fois que ces adresses IPv6 ont été assignées pour représenter les nœuds IPv4 dans Internet IPv6, de véritables enregistrements RR AAAA contenant ces adresses peuvent être publiés dans le DNS sous le domaine du site. C'est l'approche recommandée pour gérer ce scénario, car elle n'implique pas de synthétiser des enregistrements AAAA au moment de la requête.

Cependant, il existe des scénarios plus dynamiques, où la synthèse d'enregistrements RR AAAA dans cette configuration peut être nécessaire. En particulier, lorsque DNS Update [RFC2136] est utilisé dans le site IPv4 pour mettre à jour les enregistrements RR A pour les nœuds IPv4, il y a deux options. Une option consiste à modifier le serveur DNS qui reçoit les mises à jour DNS dynamiques. Ce serait normalement le serveur faisant autorité pour la zone. Donc la zone faisant autorité aurait des enregistrements RR AAAA normaux qui sont synthétisés lorsque des mises à jour dynamiques se produisent. L'autre option consiste à modifier tous les serveurs faisant autorité pour générer des enregistrements AAAA synthétiques pour une zone, éventuellement basés sur des contraintes supplémentaires, lors de la réception d'une requête DNS pour l'enregistrement RR AAAA. La première option -- dans laquelle le AAAA est synthétisé lorsque le message de mise à jour DNS est reçu, et les données publiées dans la zone concernée -- est recommandée par rapport à la deuxième option (c'est-à-dire la synthèse lors de la réception de la requête DNS AAAA). Cela est dû au fait qu'il est généralement plus facile de résoudre les problèmes de mauvaise configuration lorsque les réponses DNS ne sont pas générées dynamiquement. Cependant, il peut arriver que le serveur primaire (qui reçoit toutes les mises à jour) ne puisse pas être mis à niveau pour quelque raison que ce soit, mais où un serveur secondaire peut être mis à niveau afin de gérer la (comparativement petite) quantité de requêtes AAAA. Dans un tel cas, il est possible d'utiliser DNS64 comme décrit ci-après. Le comportement DNS64 que nous décrivons dans cette section couvre le cas de la synthèse de l'enregistrement RR AAAA lorsque la requête DNS arrive.

Le scénario pour ce cas est représenté dans la figure suivante:

             +-----------+          +----------------------+
             |           |          |   IPv4 site          |
             |   IPv6    |    +------------+  |   +----+   |
             | Internet  |----| IPv6/IPv4  |--|---| H2 |   |
             |           |    | Translator |  |   +----+   |
             |           |    +------------+  |            |
             |           |          |         | 192.0.2.1  |
             |           |    +------------+  |            |
             |           |----| Name server|--|            |
             |           |    | with DNS64 |  |            |
             +-----------+    +------------+  |            |
               |                    |         |            |
             +----+                 |                      |
             | H1 |                 +----------------------+
             +----+

         Figure 6:  "The IPv6 Internet to an IPv4 Network" Setup
                      with DNS64 in DNS Server Mode

La figure montre un nœud IPv6 H1 et un nœud IPv4 H2 avec l'adresse IPv4 192.0.2.1 et le FQDN h2.example.com.

Le traducteur IPv6/IPv4 utilise un NSP 2001:db8::/96 pour créer des représentations IPv6 d'adresses IPv4. Le même préfixe est configuré dans la fonction DNS64 du serveur de noms local. Le serveur de noms qui implémente la fonction DNS64 est le serveur de noms faisant autorité pour le domaine local.

Les étapes par lesquelles H1 établit la communication avec H2 sont:

  1. H1 effectue une recherche DNS pour h2.example.com. H1 fait cela en envoyant une requête DNS pour un enregistrement AAAA pour H2. La requête est finalement transmise au serveur dans le site IPv4.

  2. Le serveur DNS local résout la requête (localement) et découvre qu'il n'y a pas d'enregistrements AAAA pour H2.

  3. Le serveur de noms vérifie que h2.example.com et son enregistrement RR A sont parmi ceux que la politique locale définit comme autorisés à générer un enregistrement RR AAAA. Si c'est le cas, le serveur de noms synthétise un enregistrement AAAA à partir de l'enregistrement RR A et du préfixe 2001:db8::/96. L'adresse IPv6 dans l'enregistrement AAAA est 2001:db8::192.0.2.1.

  4. H1 reçoit l'enregistrement AAAA synthétique et envoie un paquet vers H2. Le paquet est envoyé à l'adresse de destination 2001:db8::192.0.2.1.

  5. Le paquet est routé à travers Internet IPv6 vers l'interface IPv6 du traducteur IPv6/IPv4 et la communication s'écoule en utilisant les mécanismes du traducteur IPv6/IPv4.

📊 Traduction de qualité - Auto-vérification​

  • Alignement des paragraphes: Chapitre 7 complet avec 3 exemples
  • Format des liens: Références préservées
  • Terminologie bilingue: Termes appropriés
  • RFC 2119: N/A pour ce chapitre descriptif
  • Sécurité MDX: Diagrammes ASCII préservés
  • Préservation technique: Adresses IP et noms non traduits
  • Normes de ponctuation: Ponctuation française
  • Éléments supprimés: Headers nettoyés
  • Pureté linguistique: Français authentique
  • Répertoire correct: i18n/fr/

📍 Progression actuelle​

  • RFC: 6147
  • Langue cible: 🇫🇷 Français
  • Chapitres complétés: index.md, 1-7 (complet)
  • Chapitre actuel: Préparation de 8-11 et annexe
  • Progression globale: 85%
Dernière mise à jour le