Les récents développements de l'Internet ont conduit à de nouvelles technologies dans le secteur de l'informatique. Un des développements majeurs en matière de réseau est le protocole IPv6, conçu dans les années 1990 pour pallier les inconvénients ci-après d'IPv4, couramment utilisé aujourd'hui : le manque d'adresses IP, le protocole IPsec propriétaire et la configuration de n½uds à l'aide du protocole DHCP. Pour éviter ces inconvénients et inclure de nouvelles fonctionnalités, choisissons le protocole IPv6. Ce dernier offre des fonctionnalités supplémentaires comme l'extensibilité, un espace d'adressage plus important, un nouveau format d'en-tête, un adressage hiérarchique et une sécurité intégrée.
Il n'est pas possible de migrer le réseau global vers IPv6 du jour au lendemain : l'opération demande du temps et a un coût. En attendant, IPv6 et IPv4 devront interagir. Pour ce faire, nous disposons de différents mécanismes :
Double pile : hôtes et routeurs à la fois implémentent une pile de protocole IPv4 et IPv6.
Tunnelisation : les paquets IPv6 sont tunnelisés via un réseau IPv4.
Traduction : une passerelle traduit les paquets IPv6 en paquets IPv4.
Ce rapport se concentre sur un des mécanismes de traduction, le TRT (Transport Relay Translator, relais traducteur de transport). Il spécifie le fonctionnement et l'architecture de conception du TRT.
Les nouveaux hôtes qui entrent dans l'Internet ont la capacité d'utiliser IPv6. Mais s'ils sont configurés uniquement avec IPv6, ils ne peuvent communiquer qu'avec un autre n½ud via IPv6. Ils ne peuvent donc pas communiquer avec les n½uds IPv4 à présent couramment employés sur l'Internet.
Quand vous déployez un réseau IPv6 seul, vous pouvez toujours être amené à devoir accéder à un réseau IPv4 seul. Pour prendre en charge une telle configuration, une des technologies de traduction IPv6 vers IPv4 appelée Transport Relay Translator (TRT) et basée sur la RFC 3142 a été proposée. Un traducteur situé au niveau de la couche transport est dénommé TRT. Le relais se trouve quelque part entre les hôtes communicants et permet à des hôtes IPv6 seuls d'échanger du trafic avec des hôtes IPv4 seuls. Si deux n½uds, par exemple un client et un serveur d'applications font appel à une pile de protocole différente, ils ne peuvent pas communiquer directement l'un avec l'autre, et le trafic devra passer par un TRT.
Un TRT, qui s'exécute sur un n½ud à double pile, peut utiliser un protocole pour communiquer avec le client et un autre pour communiquer avec le serveur d'applications.
Le système est configuré avec des adresses IPv6. Il ne peut communiquer qu'avec d'autres systèmes IPv6, mais pas avec des systèmes IPv4. Il envoie ici ses paquets via une connexion TCP/IPv6.
Les hôtes IPv6 utilisent le serveur de noms pour résoudre leurs requêtes DNS. Quand le système IPv6 demande à son serveur de noms l'enregistrement IPv6 (AAAA) d'un hôte IPv4 seul, il reçoit du DNS un enregistrement d'adresse IPv6 spécialement construit à partir de l'adresse IPv4 (A), au lieu de la réponse d'erreur indiquant qu'aucune adresse IPv6 n'a été trouvée pour cet hôte. L'adresse construite se compose d'un préfixe de réseau spécial associé au relais de transport et à l'identificateur de l'hôte (les 64 bits de poids faible) qui encapsule l'adresse IPv4 de l'hôte distant. Pour des installations à petite échelle, un mappage statique est recommandé, tandis que pour une installation de grande envergure, un serveur DNS dédié est nécessaire.
Le routeur est configuré de telle sorte que les paquets destinés à l'adresse dotée du préfixe de réseau spécial soient routés vers le n½ud de relais TRT.
Le TRT effectue la conversion d'une adresse IPv6 en adresse IPv4 et crée une connexion TCP/IPv4 vers l'hôte cible. Le routeur route les paquets vers le TRT. Ce dernier intercepte alors des sessions de transport et agit envers le n½ud client comme un point final de destination d'une session IPv6. Il agit envers le n½ud serveur comme la source d'une session IPv4, copiant toutes les données qu'il reçoit d'une session à l'autre.
Le système est configuré avec une adresse IPv4. Il peut communiquer uniquement avec d'autres systèmes IPv4 et ne peut pas communiquer avec des systèmes IPv6.
La section précédente décrit une vue d'ensemble du TRT. Cependant, la véritable fonctionnalité réside dans le TRT : il effectue la conversion d'un paquet IPv6 en paquet IPv4.
L'IPC crée une file d'attente de messages et un sémaphore. La file d'attente des messages sert à envoyer le message au processus suivant. Le sémaphore sert à synchroniser l'accès à la file d'attente des messages.
Deux threads sont créés. L'un gère la connexion TCP/IPv6 et l'autre la connexion TCP/IPv4.
Cette primitive sert à recevoir le paquet provenant de l'hôte source. Elle utilise des sockets pour gérer la connexion. Les adresses et les données sont inscrites dans une structure qui est envoyée dans la file d'attente des messages.
Le programme serveur IPv6 s'exécute ici.
Le programme serveur IPv4 s'exécute ici.
La structure est reçue depuis la file d'attente des messages. Les données et l'adresse enregistrées sont extraites de la structure pour construire un paquet qui sera envoyé à l'hôte de destination IPv4.
Après avoir construit le paquet, nous l'envoyons à l'hôte de destination IPv4 à l'aide de l'adresse IPv4. Il utilise les APIs ( Application Programming Interface, interface de programmation d'application) socket.
FAITH étant un relais TCP IPv6 vers IPv4, seul un sous-ensemble des spécifications du TRT est implémenté. Il réalise un relais TCP exactement comme le fait une passerelle orientée pare-feu, mais entre IPv6 et IPv4 avec traduction d'adresses. Les connexions TCP initiées depuis un n½ud IPv6 sont relayées vers le n½ud IPv4. FAITH ne peut pas relayer les connexions dans le sens inverse : pour réaliser des relais, le démon FAITH doit être exécuté sur un routeur à double pile entre le site IPv6 local et le réseau IPv4 externe. Le démon est invoqué pour chaque service TCP (numéro de port TCP).
UDP n'est pas pris en charge.
Le pTRTd (Portable Transport Relay Translator Daemon, démon portable du relais traducteur de transport) fournit une méthode à des hôtes IPv6 pour communiquer avec des hôtes IPv4 comme le spécifie la RFC 3142, de la même manière que le paquetage FAITH implémenté par le projet KAME. Toutefois, contrairement à FAITH, il ne dépend pas d'un support spécial dans la pile IPv6 du noyau et devrait par conséquent être assez aisé à porter sous la plupart des divers systèmes d'exploitation de type Unix.
Ne fonctionne pas avec les protocoles hostiles à la NAT (Network Adress Translation, traduction d'adresses réseau) (FTP et H.323).
UDP est pris en charge.
Le projet de TRT proposé résoudra certains inconvénients des systèmes existants, tels que les protocoles hostiles à la NAT et à l'UDP (User Datagram Protocol, protocole datagramme utilisateur).
Copyright © 2004, P. Shanmugaraja.
Copying license http://www.linuxgazette.com/copying.html.
Paru dans le n°101 de la Linux Gazette d'Avril 2004.
Traduction française par Sylvain Baron
<sb CHEZ sylvain TIRET baron POINT net>.
Relecture de la traduction française par Joëlle Cornavin
<jcornavi CHEZ club TIRET internet POINT fr>.