Revision as of 00:35, 18 June 2015

Mécanime de traduction des entêtes IP

Contexte d'utilisation de la traduction des entê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 relai) dans la communication.

Afin de respecter les modèles, 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 qui nous concerne 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 de traduction entre ces 2 protocoles pour permettre à ces machines de communiquer.

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ée 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 connecter à un réseau IPv6 et la compatibilité avec les services IPv4 sera assurer par la traduction d'entête IP.

Un tel dispositif devra naturellement se situer en coupure des communications entre les 2 machines, afin d'en intercepter les paquets pour les traduire, et les ré-émettre sur le réseau vers le destinataire, en utilisant le bon protocole. C'est pour cela que ce dispositif est comparable au traditionnel NAT (Network Address Translator) utilisé entre les réseaux IPv4 privés et public. 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'entête.

Les traducteurs assurant le relai entre un réseau IPv6 et l'Internet IPv4 sont appelés NAT64. Les traducteurs assurant le relai entre un réseau IPv4 et l'Internet IPv6 sont appelés NAT46. Ce dernier cas d'usage est moins fréquent aujourd'hui mais pourra être d'actualité dans le contexte d'un déploiement majoritaire d'IPv6.

Principe de la traduction entre protocoles IP

Transposition des champs de l'entête

Il faut ici bien situé le problème : le traducteur reçoit un paquet avec une entête IPvX doit créer une nouvelle entête IPvY à partir des informations à sa disposition (les données de l'entête IPvX + données de configuration).

Si l'on observe les entê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 entêtes IPv4 ou IPv6 que doit créer le traducteur (Voir RFC6145 Section 4)

Création d'une entête IPv6 à partir d'une entête IPv4

Création d'une entête IPv4 à partir d'une entê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 IPv4 privées vers des adresses IPv4 publiques (appelé aussi NAT44). Le traducteur reçoit un paquet avec une adresse source et destination chacune dans un des espaces d'adressages et doit traduire ces adresses dans un autre espace d'adressage pour pouvoir le ré-émettre.

Un NAT44 reçoit du réseau privé des paquets avec une adresse IPv4 source dans l'espace d'adressage public. Pour pouvoir émettre ce paquet vers l'Internet IPv4, le mécanisme de NAT remplace cette adresse source par une adresse IPv4 de l'espace d'adressage public, adresse étant une de celles routées vers lui.

La traduction de l'entête IP d'un paquet d'une version à une autre du protocole nécessite la traduction des deux champs IP source et destination. Le traducteur doit donc décider d'une correspondance routable entre une adresse de l'espace d'adressage IPv4 vers une adresse de l'espace d'adressage IPv6. Le cadre général de cette traduction d'adresse est précisé par la RFC 6052.

La traduction d'une adresse IPv4 en IPv6 est simple car l'espace d'adressage IPv6 est assez large pour y trouver une adresse IPv6 à faire correspondre avec une adresse IPv4. La technique pour créer une adresse IPv6 à partir d'une adresse IPv4 est d'inclure les 32 bits de cette adresse à la suite d'un préfixe IPv6. Selon la taille du préfixe à utiliser, le mécanisme d'inclusion est différent, comme précisé dans le RFC 6052 section 2.2. Le préfixe utilisé sera un préfixe routé vers le traducteur, afin que celui-ci assure son rôle de relai. L'adresse ainsi créée permet d'adresser un noeud IPv4 dans l'espace d'adressage IPv6. La traduction effectuée par le relai est alors sans état.

La traduction d'une adresse IPv6 en adresse IPv4 est plus complexe car il est impossible de représenter l'espace d'adressage IPv6 dans celui d'IPv4. Le traducteur aura besoin d'une information supplémentaire, obtenue au préalable, afin de pouvoir désigner l'adresse IPv6 pertinente dans le contexte du paquet IPv4 à traduire. Par exemple dans le cas d'un traducteur entre un réseau local IPv6 et l'Internet IPv4, le traducteur ne sait pas comment traduire l'adresse source du paquet sortant. Il doit utiliser une de ces propres adresses. Le paquet retour contient alors cette adresse comme destination. Le traducteur a besoin ici d'une information contextuelle : la correspondance choisie entre les adresses source IPv6 et IPv4 du paquet sortant (plus des informations de niveau transport pour distinguer les flux). La traduction effectuée par le relai est dans ce cas avec état.

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'au rapports d'erreur d'acheminement sur le chemin du paquet. 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 message ICMPv6 et inversement pour être ainsi transparent dans ces échanges.

Le traducteur recevant donc un message ICMPv4 (resp. ICMPv6) doit donc interpréter le contenu de ce message pour créer un message ICMPv6 (resp. ICMPv4) à émettre. L'entête IP est traduite selon les mécanismes présentés plus haut. L'entête ICMPv4 (resp. ICMPv6) doit donc être transformée par le traducteur en entê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écouvertes 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 dites sans état. La 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 n'a pas été transposée dans ICMPv6 (parce qu'obsolète).

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

Relai-Traducteur DNS auxiliaire

Afin d'assurer la transparence aux protocoles applicatifs et aux utilisateurs, les mécanismes de traduction s'appuyer sur les services d'un relais DNS auxiliaire (DNS-ALG DNS Application Layer Gateway). Celui ci permet de convertir les résolution d'adresses IPv4 en adresses IPv6 ou inversement avec un préfixe particulier qui sera routé vers le relais transport ou réseau.

Du point de vue du client, il 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 déjà pas de l'information dans son cache local. Mais ce DNS est dit menteur car il est capable de répondre positivement à la demande d'une ressource inexistante.

Par exemple, lorsqu'un client IPv6 formule une requête AAAA, le relais DNS la transfère au serveur DNS. Si la réponse est une réponse de type A uniquement, le relai DNS applique alors la traduction de l'adresse IPv4 obtenue en adresse IPv6, comme spécifié dans la RFC 6052. Il combine un 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. Un DNS permettant la résolution en IPv6 de nom de domaine enregistré uniquement en IPv4 est appelé 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)

Exemple d'un déploiement de NAT64 sur le réseau mobile

Comme décrit en début de chapitre, 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é en traduisant les paquets IPv6 en paquets IPv4 à travers un dispositif NAT64, couplé à un relai-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.

Le client cherche ici à joindre le service hébergé sur le serveur g6.asso.fr. Pour en connaitre 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.

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 transfert cet enregistrement au client en guise de réponse. Le client peut alors se connecter directement au service à partir de l'adresse IPv6 obtenue.

Le client cherche maintenant à joindre un autre service, comme lemonde.fr. Or ce service ne possède pas de connectivité IPv4 (à l'heure de la rédaction de ce texte). 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.

Le DNS64 interroge le service sur les différentes adresses disponibles mais n'obtient que des adresses de type IPv4 (enregistrement A).

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 du service lemonde.fr.

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.

Le NAT64 doit maintenant traduire ces paquets d'IPv6 vers IPv4. Il créé donc une entête IPv4 à partir des champs de l'entête IPv6, comme spécifié dans le RFC 6144. Pour l'adresse destination du paquet, 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ésenté 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é 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 contextuelle de la connexion afin de pouvoir effectuer la traduction inverse.

Conclusion

La traduction des paquet d'une version du protocole IP vers une autre version rend possible des communications entre 2 réseaux utilisants chacune des versions différentes de façon quasi transparente pour les extrémités. La traduction d'adresses permet d'adresser une machine IPv4 dans l'espace d'adressage IPv6. La traduction inverse nécessite quant à elle des informations contextuelles propres à la communication.

Cette solution a donc les avantages et les inconvénients du NAT44 : si la configuration des clients est simple, ce mécanisme connait certaines limites comme la faible capacité à passer à l'échelle des traducteurs ainsi que l'impact sur les protocoles applicatifs (si ceux-ci transportent aussi des adresses IP).

Il faut de plus noter, dans le cas d'un client IPv6 seul, que le système, les applications et les protocoles utilisés par de 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é rendu possible par le NAT64.

Malgré ces inconvénients, ce mécanisme se déploie 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 clients). Certains opérateurs mobiles ont notamment fait ce choix pour leur réseau.