Revision as of 23:54, 6 June 2015

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

Contexte d'utilisation de la traduction d'entête 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 :

• le client ne parle qu'IPv6 et le serveur ne parle qu'IPv4
• 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 encore une connectivité IPv4. Il s'agit donc de mettre en place un dispositif permettant la traduction bi-directionnelle entre IPv4 et IPv6 pour permettre à ces machines communiquer.

Un contexte pour lequel ce type de solution est pertinent est celui des réseaux mobiles 3GPP. En effet dans la norme 3GPP, les sessions PDP 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.

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

Besoin de continuité dans messages ICMP

Problématiques de cette traduction

DNS64 : Relai 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 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.Lorsque le 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, il combine un préfixe conforme au RFC 6052 aux 32 bits de chacune des adresses obtenues comme résultats. Les datagrammes du client ayant une adresse destination avec ce préfixe seront routés par le réseau vers le relai NAT64. Le préfixe réservé pour cet usage par le RFC 6052 (et enregistré auprès de l'IANA) est 64:ff9b::/96 (96+32=128). On peut également utiliser un préfixe non-utilisé dans son plan d'adressage en respectant le format défini par le RFC 6052.

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)

Architecture d'un déploiement NAT64/DNS64

Positionnement des 2 dispositifs dans l'architecture réseau

Routage et adressage nécessaire

Exemples de fonctionnement

Reprise du réseau mobile.

Conclusion

• Avantages et inconvénients de ce mécanisme
• Cas d'usage où ce mécanisme est pertinent (et où il ne l'est pas).