Revision as of 05:50, 8 September 2015

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

IV-

Interopérabilité avec les services IPv4 par traduction

Contexte d'utilisation de la traduction des en-têtes IP

Le besoin de traduction d'un protocole vers un autre apparait si l'on souhaite faire communiquer 2 machines ne parlant chacune qu'un seul de ces 2 protocoles, le traducteur jouant alors un rôle d'intermédiaire (ou relais) dans la communication. Ce besoin de traduction est la conséquence de l'échec du plan de migration envisagé au début et reponsant sur la double pile. Les nouveaux noeuds ne peuvent plus avoir à la fois une adresse IPv4 et IPv6 du fait de l'épuisement des adresses IPv4. Cet état de fait conduit à l'apparition de noeuds avec IPv6 uniquement. Comme il y a des noeuds qui sont toujours en IPv4 uniquement car ils n'ont pas commencé à migrer. Ce pose alors le problème de la communication entre les noeuds uniquement IPv6 avec ceux uniquement IPv4. La traduction est la solution à ce problème et constitue le composant essentiel au nouveau plan de migration qui peut se décrire de manière synthétique suivante: "tout le monde en IPv4" -> "certains réseaux en v4 seul et certains en v6 seul" -> "tout le monde en IPv6".

Afin de respecter les modèles d'architectures en couches (OSI, TCP/IP), la traduction n'intervient qu'entre protocoles d'un même niveau. On pourra donc distinguer la traduction niveau applicatif, niveau transport et niveau réseau. Dans le cas du protocole IP (niveau réseau), il s'agit bien sûr de faire communiquer 2 machines, chacune n'utilisant qu'une version du protocole, IPv4 ou IPv6. Dans le cadre de communication client vers serveur, il y aura donc 2 cas :

1. le client ne parle qu'IPv6 et le serveur ne parle qu'IPv4,
2. le client ne parle qu'IPv4 et le serveur ne parle qu'IPv6.

Aujourd'hui, le cas le plus fréquent est le premier, les serveurs gardant majoritairement une connectivité IPv4. Il s'agit donc de mettre en place un dispositif pour offrir une connectivité IPv4 aux clients IPv6. Ainsi, ils pourront accéder à des serveurs qui n'ont toujours pas IPv6. Un moyen pour offrir cette connectivité est de traduire automatiquement les paquets IPv6 du client en IPv4 pour les envoyer au serveur, et de faire la traduction inverse au retour. Un tel dispositif devra naturellement se situer en coupure des communications entre le client et le serveur, afin d'en intercepter les paquets pour les traduire, et les ré-émettre sur le réseau du destinataire. Ce dispositif est comparable au traditionnel NAT (Network Address Translator) utilisé entre les réseaux IPv4 privés et publics. Mais dans notre cas, ce dispositif n'effectue pas une simple translation d'un espace d'adressage à un autre, mais une véritable traduction de l'en-tête IP. Le traducteur assurant le relais entre un réseau IPv6 (coté client) et un réseau IPv4 (coté serveur) est appelé NAT64. La figure 1 représente la topologie d'utilisation du NAT64.

Figure 1: Topologie d'utilisation du NAT64.

Le RFC 6144 détaille les cas d'utilisation de la traduction entre IPv6 et IPv4 en distinguant l'Internet et un réseau. Ainsi un réseau dont le plan d'adressage est administrable est distingué de celui qui ne l'est pas. Le RFC indique notamment que le cas du client IPv4 accédant à un serveur de l'Internet IPv6 n'est pas d'actualité et d'autres solutions que la traduction IP seront à envisager. Les cas d'utilisation communs de la traduction sont soit un client d'un réseau IPv6 accédant à un serveur de l'Internet IPv4 ou soit des clients de l'Internet IPv6 accédant à un serveur d'un réseau IPv4. Dans le premier cas, le traducteur est du coté du client IPv6 pour le rendre capable d'accéder à des contenus disponibles uniquement sur l'Internet IPv4. Dans le RFC 7269, ce type de NAT64 est appelé NAT64-CGN (Carrier-Grade NAT). Dans le second cas, le traducteur est du coté du serveur IPv4 pour rendre le service accessible aux clients de l'Internet IPv6. Le RFC 7269 qualifie ce NAT64 de NAT64-FE (Front End) dans la mesure où le NAT64 est devant les serveurs au sein d'un data center.
Quelque soit le cas, la traduction reste une solution temporaire et vise à faciliter le déploiement d'IPv6 dans l'Internet IPv4.

Un contexte pour lequel ce type de solution est pertinent est celui des réseaux mobiles 3GPP 3rd Generation Partnership Project) [1]. En effet, dans la norme 3GPP, les sessions PDP (Packet Data Protocol) mises en place pour la connexion de données ne peuvent être double pile que depuis la Release-9. Pour avoir un support double pile sur ces réseaux, il est nécessaire d'ouvrir 2 contextes, ce qui peut être préjudiciable pour le dimensionnement des équipements. Une solution est alors de ne déployer qu'une version du protocole sur le réseau mobile. Les équipements mobiles seront donc connectés à un réseau IPv6 et la compatibilité avec les services IPv4 sera assurée par la traduction d'en-tête IP.

Principe de la traduction entre protocoles IP

La traduction entre protocoles IP comporte essentiellement 2 composants: une transposition protocolaire et une traduction des adresses. Le premier composant transpose les champs de l'en-tête IP (à l'exception des adresses) en conservant la sémantique du champ original. Le second composant met en correspondance les adresses source et destination du paquet reçu dans une version du protocole IP dans leur équivalent dans l'autre version du protocole IP.

Les traductions peuvent être faites sans état (stateless) ou bien avec état (stateful). Dans le premier cas, le traducteur n'a aucune mémoire. Chaque paquet est traité isolément et contient toutes les informations nécessaires à la traduction. Avec la traduction sans état, les meilleures performances sont obtenues en terme de quantité de paquets traités et de passage à l'échelle. Dans le second cas, celui de la traduction avec état, le traducteur se souvient de la correspondance qu'il a effectué entre les 2 versions du protocole, par exemple parce que l'adresse IPv6 n'est pas en correspondance univoque (1:1) avec l'adresse IPv4. Nécessitant une table des correspondances en mémoire, la traduction avec état passe moins à l'échelle. Mais, dans certains cas, elle est la seule réaliste, puisqu'on ne peut pas stocker toutes les informations dans une seule adresse, surtout si elle est IPv4.
Si le composant de la transposition des champs de l'en-tête s'effectue sans état, le composant de traduction des adresses fonctionne avec ou sans état.

Transposition protocolaire des champs de l'en-tête (RFC 6145)

Il faut ici bien situer le problème : le traducteur qui reçoit un paquet avec un en-tête IPvX doit créer un nouvelle en-tête IPvY à partir des informations à sa disposition : les données de l'en-tête IPvX et des données de configuration.

Si l'on observe les en-têtes IPv4 et IPv6 comme dans l'activité 21, on remarque qu'il y a un certain nombre de champs qui ont une sémantique très proche (TTL/Hop limit, DiffServ, Payload Length). Pour ces derniers, la transposition est évidente. Les tableaux ci-dessous résument les informations qu'il faut utiliser pour renseigner les différents champs des en-têtes IPv4 ou IPv6 que doit créer le traducteur (Voir RFC6145 Section 4)

Création d'un en-tête IPv6 à partir d'un en-tête IPv4

Création d'un en-tête IPv4 à partir d'un en-tête IPv6

Traduction des adresses

La traduction d'adresse d'un protocole à un autre suit le même principe que celui appliqué dans les passerelles NAT traduisant des adresses IPv4 privées vers des adresses IPv4 publiques (appelé aussi NAT44). Le traducteur reçoit un paquet avec des adresses source et destination chacune dans un des espaces d'adressage, et doit traduire ces adresses dans l'autre espace d'adressage pour pouvoir ré-émettre le paquet.
Le traducteur doit donc décider d'une correspondance entre une adresse de l'espace d'adressage IPv6 et une adresse de l'espace d'adressage IPv4 et vice et versa à la fois pour l'adresse source et l'adresse de destination.
Afin de faire cette correspondance, le NAT64 dispose d'un ensemble d'adresses IPv6 et d'un ensemble d'adresses IPv4 comme le montre la figure 2. L'ensemble d'adresses IPv6 du NAT64 (notée N6) vont servir à représenter les adresses IPv4 (notée H4) dans le réseau IPv6. Et de manière similaire pour l'ensemble des adresses IPv4 du NAT64 (notée N4), elles vont représenter les adresses IPv6 (notée H6) dans le réseau IPv4.

Figure 2: Les adresses utilisées pour la traduction

La correspondance entre une adresse IPv4 avec une adresse IPv6 est évident lorsque l'adresse IPv6 comporte l'adresse IPv4. En effet, représenter une adresse IPv4 dans l’espace d’adressage IPv6 est simple car ce dernier est assez large pour contenir l’ensemble des adresses IPv4. Il est donc toujours possible de trouver une adresse IPv6 à faire correspondre avec une adresse IPv4. Le RFC 6052 décrit la méthode pour créer une adresse IPv6 à partir d’une adresse IPv4. La méthode consiste à inclure les 32 bits l'adresse IPv4 à la suite d'un préfixe IPv6. Selon la longueur du préfixe IPv6, le mécanisme d'inclusion de l'adresse IPv4 est différent, comme précisé dans le RFC 6052 section 2.2. Une adresse IPv6 embarquant une adresse IPv4 (IPv4-embedded IPv6 address) est qualifiée, soit traduisable en IPv4 (IPv4-translatable IPv6 address) si elle est unique globalement, routable et donc attribuée à un noeud IPv6, soit de IPv4 convertible (IPv4-converted IPv6 address) si elle ne fait que représenter une adresse IPv4 dans l'espace d'adressage IPv6. Selon la cas d'utilisation du NAT64, le préfixe d'une adresse IPv6 embarquant une adresse IPv4 (notée pref64 dans la représentation ci-dessous) peut être le préfixe dit Well-Known Prefix (WKP) ou un préfixe pris dans le plan d'adressage de l'organisation déployant le NAT64 dit "Network-Specific Prefix (NSP). Le WKP se définit par 64:ff9b::/96 et sert uniquement à constituer des adresses IPv6 embarquant une adresse IPv4 convertible. Ce préfixe n'est pas routable sur l'Internet v6, il doit être utilisé uniquement en routage interne à un réseau.
La traduction d'adresses utilisant une adresse IPv6 embarquant une adresse IPv4 est qualifiée de sans état. Le point essentiel dans ce mode de traduction est que le noeud IPv4 est identifié dans l'adressage IPv6 par une adresse IPv6 embarquant son adresse IPv4. La traduction peut se représenter de la manière suivante:

IPv4  <-------> IPv6
  H4            pref64:H4

où pref64 représente un préfixe IPv6 pour constituer une adresse IPv6 embarquant une adresse IPv4 (notée ici H4). L'adresse IPv6 ainsi constituée est notée pref64:H4. Le préfixe IPv6 utilisé sera un préfixe routé vers le traducteur, afin que celui-ci assure son rôle de relais. L'adresse IPv6 ainsi créée permet d'identifier un noeud IPv4 dans l'espace d'adressage IPv6.
L’intérêt de ce mécanisme est que les adresses peuvent être traduites indépendamment. Il est donc transparent pour l’utilisateur.

Lorsque l'adresse IPv6 n'embarque pas l'adresse IPv4 alors mettre en correspondance une adresse IPv6 avec une adresse IPv4 demande un traduction d'adresse avec état. En effet, comme il est impossible de représenter une adresse IPv6 dans l’espace d’adressage d'IPv4. La mise en correspondance de l'adresse IPv6 avec une adresse IPv4 est faite dynamiquement par le traducteur. Celui-ci utilise une de ses adresses IPv4. Il doit alors retenir cette association dans un état. Par exemple, dans le cas d'un traducteur entre un client IPv6 du réseau local et un serveur de l'Internet IPv4, le traducteur ne sait pas comment traduire l'adresse source du paquet IPv6 : il doit utiliser une de ses propres adresses IPv4. Le paquet retour contient alors cette adresse comme destination. Le traducteur a bien besoin ici d'un état : la correspondance choisie pour le paquet aller entre l'adresse source IPv6 et l'adresse source IPv4 . La traduction est alors dites à état car elle fait intervenir cette information. La traduction peut se représenter de la manière suivante:

IPv6  ----------> IPv4
  H6  (état  H6->H4)  H4 
IPv6  <---------  IPv4
  H6  (état  H6<-H4)  H4

Avec notée H6 l'adresse IPv6 et H4 l'adresse IPv4.

Mécanismes complémentaires

Traduction des paquets ICMP

Comme décrit dans l'activité 31, les messages ICMP servent au contrôle de la connectivité de bout en bout, ainsi qu'aux rapports d'erreurs d'acheminement des paquets. La présence d'un traducteur sur ce chemin ne doit pas perturber ce mécanisme, sous peine de grandement complexifier son fonctionnement. Celui-ci doit donc s'efforcer de traduire les messages ICMPv4 en messages ICMPv6, et inversement, pour être ainsi transparent dans ces échanges.

Le traducteur recevant un message ICMPv4 (resp. ICMPv6) doit donc interpréter le contenu de ce message pour créer un message ICMPv6 (resp. ICMPv4) à retransmettre. L'en-tête IP est traduit selon les mécanismes présentés plus haut. L'en-tête ICMPv4 (resp. ICMPv6) doit donc être transformé par le traducteur en en-tête ICMPv6 (resp. ICMPv4). Cette traduction est facilitée par le fait que les sémantiques des messages de ces 2 protocoles ne sont pas très éloignées : les fonctions supplémentaires de découverte de voisins intégrées dans ICMPv6 ne sont valides que sur le lien et ne seront pas traduites. De plus, les paquets ICMP n'ont pas besoin d'informations contextuelles pour être interprétés. La traduction des messages ICMP est dite sans état. Le RFC 6145 définit le mécanisme pour effectuer cette traduction.

Le champ ICMP type devra être ajusté dans certains cas lors de la traduction car les valeurs pour la même sémantique de messages peuvent être différentes entre les versions du protocole. Par exemple, les messages Echo Request et Reply sont identifiés par la valeur du champ ICMP type 8 et 0 en ICMPv4, 128 et 129 en ICMPv6. Certains messages ICMPv4 ne seront pas traduits car leur sémantique (obsolète) n'a pas été transposée dans ICMPv6.

La traduction de l'en-tête ICMP modifie les en-têtes des niveaux réseau et transport. Elle impacte donc la somme de contrôle calculée pour ces en-têtes. Le champ checksum doit donc être recalculé suite à la traduction.

Relais-Traducteur DNS auxiliaire (RFC 6147)

Les clients IPv6 ne pouvant pas initier une communication avec des serveurs n'ayant qu'une adresse IPv4, il est nécessaire de les «tromper» en fabriquant dynamiquement des adresses IPv6. Cette fabrication d'une adresse IPv6 pour le serveur IPv4 en revient au relais DNS auxiliaire (DNS Application Layer Gateway (DNS-ALG)). Celui-ci convertit l'adresse IPv4 obtenue par la résolution d'adresse en une adresse IPv6 imbriquant une adresse IPv4. En quelque sorte, le relais DNS auxiliaire ment en répondant au client par un enregistrement de type AAAA (adresse IPv6) à partir de l'enregistrement réel A (adresse IPv4) du serveur.
Du point de vue du client, le relais DNS auxiliaire se comporte comme n'importe quel serveur DNS de rattachement. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Mais ce DNS ment car il est capable de répondre positivement à la demande d'une ressource inexistante. Un relais DNS effecuant la résolution en IPv6 de nom de domaine enregistré uniquement en IPv4 est appelé DNS64.

La figure 3 montre un chronogramme des opérations de résolution d'adresses avec un DNS64. Le préfixe IPv6 utilisé dans cet exemple pour construire une adresse IPv6 IPv4 convertible est de type NSP de longueur 96 bits (2001:db8:cafe::/96). Les opérations sont les suivantes:

1. lorsqu'un client IPv6 formule une requête de type AAAA pour résoudre le nom d'un serveur,
2. le DNS64 la transfère au serveur DNS en charge du nom de domaine du serveur,
3. si la réponse est vide, le DNS64 renvoie une requête de type A pour le même nom de serveur au serveur DNS,
4. le DNS64 reçoit une réponse à sa requête de type A,
5. le DNS64 applique alors la traduction de l'adresse IPv4 obtenue en adresse IPv6, comme spécifiée dans le RFC 6052. Il combine le préfixe IPv6 aux 32 bits de chacune des adresses obtenues comme résultats. L'adresse IPv6 obtenue sera transmise au client en réponse à sa requête AAAA.

Figure 3: Opérations du DNS64

Les versions récentes du logiciel serveur DNS BIND/Named peuvent assurer le rôle de DNS64. Le logiciel Trick or Treat Deamon (TOTD) peut également être utilisé pour cet usage.

Pour aller plus loin : Limitations de la traduction

(MTU/Fragmentation, Sécurité, Compatibilité des applications)

Mécanisme de transition NAT64/DNS64

NAT64 et DNS64 constituent ensemble une technique de traduction de niveau réseau. Le fonctionnement du NAT64 fonctionne sans état ou avec état en fonction du mode de traduction de l'adresse source et de l'adresse de destination du paquet reçu par le traducteur.

Le NAT64 sans état signifie que les adresses IPv6 du paquet sont traduites chacune par une traduction sans état à l'aide de l'algorithme de correspondance défini dans le RFC 6052. Comme indiqué précédemment, le point essentiel dans ce mode de traduction est que l'adresse IPv4 est comprise dans l'adresse IPv6. Aussi un préfixe IPv6 spécifique est dédié pour représenter les systèmes IPv4 dans le monde IPv6. Dans le monde IPv4, tous les systèmes IPv6 ont une adresse IPv4. Ainsi qu'elle que soit le sens de la traduction, la correspondance d'adresse est unique: d'un coté il faut l'extraire de l'adresse IPv6, de l'autre coté il faut combiner l'adresse IPv4 avec le préfixe pour former une adresse IPv6. C'est à l'aide de cette correspondance directe qu'il n'est pas besoin de maintenir un état pour la traduction entre IPv6 et IPv4. Cependant cela requière que les systèmes IPv6 (devant communiquer avec le monde IPv4) soient configurés, manuellement ou via DHCPv6, avec les adresses IPv6 embarquant une adresse IPv4 [RFC 6052]. On voit là apparaître la principale faiblesse de ce mode de traduction: il consomme une adresse IPv4. Car les noeuds IPv6 ont besoin d'une adresse IPv4 qui leur est propre (de manière similaire aux noeuds en double pile). La figure 4 représente un transfert d'un paquet du noeud IPv6 vers le noeud IPv4. Dans cette figure H6 et H4 sont des adresses IPv4. Ces adresses trouvent leur correspondance dans l'espace d'adressage IPv6 en les préfixant par un préfixe IPv6 réservé à cet usage noté pref64. Du point du vue du routage, NAT64 annonce ce préfixe dans le réseau IPv6 pour recevoir le trafic à destination des noeuds IPv4. Il fait de même du coté IPv4 en annonçant une route pour les adresses IPv4 des noeuds IPv6.

Figure 4: Type des adressses utilisées pour un NAT64 sans état

Du fait de son caractère sans état, ce traducteur passe mieux à l'échelle et il n'introduit pas un point de faiblesse pour les communications en respectant l'indépendance du réseau vis à vis des hôtes. Lorsque le réseau est indépendant des hôtes, une panne dans le réseau n'entraîne pas la ré-initilisation des communications en cours. C'est un principe pour assurer la robustesse du système. Dans notre cas, la robustesse de la traduction dans le réseau peut être elle-même renforcée si plusieurs NAT64 sont déployés en parallèle. Cependant, le manque d'adresses IPv4 disponibles le rend difficilement utilisable voir inutile comme le remarque l'auteur de [Stateless NAT64 is useless]. Comme il va être nécessaire d'agréger plusieurs noeuds IPv6 sur une simple adresse IPv4, la solution s'oriente alors vers le traducteur avec état.

Décrit par le RFC 6146, le NAT64 avec état possède une adresse IPv4 qu'il partage entre plusieurs systèmes IPv6. Il s'ensuit que l'algorithme de correspondance des adresses reposant sur une adresse IPv6 embarquant une adresse IPv4 défini dans le RFC 6052 n'est plus applicable. A la place un état est crée pour chaque flot de paquets pour mettre en correspondance cette adresse IPv4 avec des adresses IPv6. Comme pour le NAT44, le numéro de port est utilisé pour identifier les noeuds IPv6. La différence majeure avec le traducteur sans état porte sur une des adresses du paquet IPv6, celle-ci n'est pas traduite en IPv4 par la méthode de traduction sans état. Comme le décrit la figure 6, le NAT64 avec état utilise à la fois une traduction avec état et une traduction sans état. Dans cette figure, l'hôte IPv6 d'adresse H6 émet un paquet à destination de l'hôte IPv4 d'adresse H4. N4 représente l'adresse IPv4 partagée que le traducteur utilise pour la représentation des adresses sources IPv6 dans le monde IPv4. Le NAT64 annonce une route de préfixe pref64 pour recevoir le trafic IPv6 a destination du réseau IPv4.

Figure 5: Type des adressses utilisées pour un NAT64 avec état

Pour illustrer le fonctionnement conjoint du NAT64 et du DNS64, nous allons prendre l'exemple d'un déploiement d'un NAT64 à état sur le réseau mobile. Comme décrit en début de l'activité, le déploiement d'un réseau seulement IPv6 peut s'avérer intéressant dans le cadre d'un réseau mobile type UMTS (3G). L'interopérabilité avec les services IPv4 peut alors être réalisée en traduisant les paquets IPv6 en paquets IPv4 à travers un dispositif NAT64, couplé à un relais-traducteur DNS64. L'intérêt d'un tel dispositif est qu'il est relativement simple à configurer côté équipement client : il suffit que celui-ci utilise l'adresse du DNS64 en tant que serveur de résolution de nom. La figure 6 montre la structure du réseau du point de vue IP. Le client est un mobile souvent un smartphone noté ME (Mobile Equipment) connecté à un réseau sans fil interconnecté avec l'infrastructure IP au moyen d'un routeur noté GGSN (Gateway GPRS Support Node).

Figure 6: Accès à un serveur en IPv6

Dans la figure 6, le client ME cherche ici à joindre le service hébergé sur le serveur IPv6 example.org.

1. Pour en connaître l'adresse IP, il interroge donc le serveur de résolution de nom, en l'occurrence le dispositif DNS64. L'interrogation du client concerne les enregistrements IPv6 (AAAA) car ceux-ci sont les seuls qui seront utilisables depuis le client connecté sur un réseau IPv6 seul (étape 1).
2. Ce nom de domaine possède une résolution en IPv6 (il possède un enregistrement AAAA). Le dispositif DNS64 se comporte alors comme un résolveur de nom normal et transfère cet enregistrement au client en guise de réponse (étape2).
3. Le client peut alors se connecter directement au service à partir de l'adresse IPv6 obtenue (étape 3).

Figure 7: Accès à un serveur en IPv4

Dans la figure 7, le client ME cherche maintenant à joindre un autre service, comme old.org. Or ce service ne possède pas de connectivité IPv6.

1. Comme précédemment, le client va interroger son résolveur de nom, le DNS64, sur la présence d'un enregistrement AAAA pour le service (étape1).
2. Le DNS64 interroge le service DNS (étape 2) sur les différentes adresses disponibles
3. Le DNS64 n'obtient que des adresses de type IPv4 (enregistrement A) (étape 3).
4. Ces enregistrements ne correspondent pas aux adresses attendues par le client. Le DNS64 va alors transformer les adresses IPv4 obtenues du service en adresses IPv6 afin de satisfaire la demande du client. Cette traduction d'adresse se fait conformément au RFC 6052 : dans notre exemple, le DNS64 complète le préfixe 64:ff9b::/96 avec l'adresse IPv4 obtenue (étape 4).
5. Le client utilise donc cette adresse IPv6 comme destinataire de la communication. Ici, le navigateur du client ouvre une connexion TCP à destination d'une adresse appartenant au préfixe 64:ff9b::/96. Ce préfixe est routé dans l'infrastructure du réseau mobile vers le dispositif NAT64. Celui-ci reçoit donc les paquets en provenance du client et à destination de l'adresse transformée par le DNS64 (étape 5).
6. Le NAT64 doit maintenant traduire ces paquets d'IPv6 vers IPv4. Il créé donc un en-tête IPv4 à partir des champs de l'en-tête IPv6, comme spécifié dans le RFC 6145. Pour l'adresse destination du paquet IPv4, le traducteur applique la transformation inverse de celle appliquée par le DNS64 : il extrait l'adresse IPv4 en soustrayant de l'adresse destination du paquet IPv6 le préfixe utilisé pour la traduction d'adresse dans l'infrastructure mobile, en l'occurrence 64:ff9b::/96. Ne pouvant représenter l'adresse IPv6 du client dans une adresse IPv4, le traducteur choisit une des adresses IPv4 à sa disposition comme adresse source (cette adresse devra être routée vers ce dispositif afin que le traducteur capte aussi les paquets retour à destination du client). Il conserve une trace en mémoire de la correspondance entre l'adresse du client et l'adresse IPv4 choisie, ainsi que des ports TCP source et destination utilisés comme informations contextuelles de la connexion afin de pouvoir effectuer la traduction inverse. Après avoir fait ces traitements, le NAT64 transmet des paquets IPv4 vers le service old.org fonctionnant encore avec le protocole archaïque (étape 6).

Conclusion

La traduction des paquets d'une version du protocole IP vers une autre version rend possible des communications entre deux hôtes utilisant chacun des versions différentes, et ce de façon quasi transparente. Aucune modification du client ou du serveur est demandée, tout est fait dans le traducteur. NAT64 effectue une traduction d'adresses de IPv6 vers IPv4 et l'inverse lorsque la réponse arrive.

Cette solution a les avantages et les inconvénients du NAT44. Si la configuration du NAT coté client est simple, ce mécanisme connait certaines limites comme la faible capacité à passer à l'échelle des traducteurs à état ainsi que l'impact sur les protocoles applicatifs (si ceux-ci transportent des adresses IP).
Il faut de plus noter, dans le cas d'un client IPv6 uniquement, que les applications et les protocoles utilisés par ce client devront être compatibles avec IPv6. Dans certains cas, ces conditions ne sont pas remplies et le client ne pourra pas alors profiter de l'interopérabilité rendue possible par le NAT64.

Malgré ces inconvénients, NAT64 se développe de plus en plus car il devient intéressant aujourd'hui de pouvoir déployer des réseaux seulement IPv6 à la place de réseaux IPv4 privés notamment quand l'espace d'adressage privé n'est plus suffisant pour adresser l'ensemble des noeuds. Certains opérateurs mobiles ont notamment fait ce choix pour leur réseau. De plus, ce mécanisme constitue le composant essentiel pour la migration vers IPv6 dans la situation actuelle de l' Internet (épuisement des adresses IPv4 disponibles et forte inertie pour la migration des noeuds IPv4). Les solutions de traduction comme NAT64 trouvent donc leur intérêt pour faire communiquer des machines utilisant des versions différentes du protocole IP.

Pour aller plus loin

NAT64/DNS64

• Bagnulo, M.; Garcia-Martinez, A. and Van Beijnum, I. (2012). IEEE Communications Magazine, Vol. 50, No. 7, July. The NAT64/DNS64 tool suite for IPv6 transition.
• Cisco White paper (2011). NAT64—Stateless versus Stateful
• Cisco White paper (2012). NAT64 Technology: Connecting IPv6 and IPv4 Networks
• Poly Introduction IPv6 (JL) 6.5.4 Les relais de niveau réseau (NAT64)
• Poly Medi6 Lab, 3.3 Mise en place d'un relai de niveau réseau : NAT64 (pages 32 - 43)

RFC et leur analyse par S. Bortzmeyer

• RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators Analyse
• RFC 6144 Framework for IPv4/IPv6 Translation Analyse
• RFC 6145 IP/ICMP Translation Algorithm Analyse
• RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers Analyse
• RFC 6147 DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers Analyse
• RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion Analyse
• RFC 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix
• RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis Analyse
• RFC 7269 NAT64 Deployment Options and Experience Analyse