> MOOC>Contenu>Séquence 4 > Activité 44

Interopérabilité avec les services de l'Internet IPv4

• Rappel du principe de la traduction
• Pour les opérateurs : NAT64

Objectifs pédagogiques

Niveau 1

• La translation d'adresse entre IPv6 et IPv4
• Les adresses IPv6 contenant une adresse IPv4
• DNS64, le relai DNS auxilliaire
• NAT64 avec / sans état
• Modèle d'interaction client-serveur sur réseau multi-protocole IP

Niveau 2

• Comprendre les principes de fonctionnement de l'association DNS64 / NAT64
• Identifier les cas d'utilisation de la solution de traduction de niveau réseau

Texte de référence

Chapitre associé à la vidéo

Quizz

Exercice

Le service d'un serveur IPv4 est rendu accessible à l'Internet v6 au moyen d'un NAT64. Le NAT64 est opéré sur le réseau du serveur. La figure ci-dessous montre la topologie de la communication. On note C6 l'adresse IPv6 du client, N6 l'adresse IPv6 utilisée pour joindre le serveur, N4 l'adresse représentant un client IPv6 sur le réseau IPv4 du serveur et S4 l'adresse IPv4 du serveur. Répondre aux questions suivantes:

Figure : Cas d'utilisation du NAT64.

Quel est le mode de fonctionnement du NAT64 (avec ou sans état) ? Justifier votre réponse

Quelle est l'adresse de destination du paquet contenant une requête du client ?

La traduction d'adresse sans état appliqué par le NAT64 porte sur quelle adresse (source ou destination) d'un paquet contenant une requête du client ?

Quel est le type de préfixe utilisé par l'adresse IPv6 embarquant une adresse IPv4 notée N6 ? Justifier votre réponse.

L'adresse N6 est une adresse IPv6 embarquant une adresse IPv4. Quelle est cette adresse IPv4 ?

Comment est qualifiée l'adresse N6 : convertible ou traduisible en IPv4 ? Justifier votre réponse.

Un traducteur NAT64 sans état est déployé dans un réseau de site. Les noeuds IPv6 ont leur adresse déterminée par l'auto-configuration sans état. Un bloc d'adresses IPv4 est alloué au traducteur. Celui-ci fera la correspondance entre adresse IPv6 et IPv4 dynamiquement. Ce traducteur reprend le principe de la traduction sans état dans la mesure où il maintient une correspondance 1:1. Cependant, il utilise un état pour mémoriser cette correspondance entre les 2 adresses.

Oui, mais lorsque que le pool d'adresses IPv4 correspondant aux adresses IPv6 est géré par l'appareil (appliance) NAT64, quand bien même on fait du 1:1, ce n'est pas véritablement du sans état. Dans ce cas, le principal avantage du "sans état", à savoir la  passage  à l'échelle avec la possibilité de répartir la charge sur 'n' boitiers distincts indépendants ne tient plus, puisqu'il faut synchoniser la table de correspondance @ IPv4 <-> @ IPv6 entre tous les boitiers NAT64. 

Inversement le fait de devoir gérer et router, en plus des adresses natives ULA/GUA, une adresse unicast supplémentaire "IPv4-converted" conforme RFC 6052 sur chaque interface sur ton réseau pour bénéficier d'un veritable NAT64 "sans-état" alourdit la charge administrative (allocation des adresses DHCP + routage de ce préfixe spécifique RFC6052). C'était le principal reproche qui était fait à SIIT où en plus les adresses "converted" au format ::ffff:0:a.b.c.d n'étaient pas faciles à agréger et router (cela revenait de fait à router les ::ffff:0:a.b.c.d au dela du 96ieme bit sur le préfixe IPv4, donc finalement à router de l'IPv4 sur ton réseau purement V6).