Revision as of 16:32, 30 May 2015

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

Le cadre général de la traduction d'adresse est précisé par la RFC 6052.

La traduction d'une adresse IPv4 en IPv6 est assez simple car l'espace d'adressage IPv6 est assez large pour définir une correspondance avec une adresse IPv4. Plusieurs techniques sont possibles :

• Inclure l'adresse IPv4 dans une adresse IPv6 (on parle alors d'adresses IPv4-embedded IPv6)
• Traduire l'adresse IPv4

IPv6 vers IPv4

• Adresse IPv6 source du client changée en adresse IPv4 du traducteur
• Adresse IPv4 destination construite à partir de l'adresse IPv6 destination

IPv4 vers IPv6

• Adresse IPv6 source reconstruite à partir de l'adresse IPv4
• Adresse IPv6 destination (du client) retrouvée à partir du contexte

Statefull / Stateless ?

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).