Revision as of 12:17, 27 February 2006

Relais applicatifs

Un relais applicatif est une machine avec une double pile IP configurée pour accéder aux deux versions du protocole. Les équipements IPv6 émettent leurs requêtes vers un relais applicatif qui interprète le contenu de la requête et la retransmet en IPv4.

Un ou plusieurs relais peuvent être installés en fonction des services rendus disponibles sur le réseau (par exemple serveur d'impression, serveur de messagerie, relais http, ...). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces relais.

L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les relais applicatifs, par exemple telnet. Mais comme la liste précédente l'indique, les ALG (Application Level Gateway) concernent des applications courantes qui représentent une partie importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.

Les relais applicatifs ou ALG (Application Level Gateway) représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure Exemple de relais applicatif pour le courrier électronique) configurées pour accéder aux deux versions du protocole. Les équipements IPv6 émettent leur requête vers le relais applicatif qui interprète le contenu de la requête et la retransmet en IPv4.

Ils regroupent :

• les proxies et les caches web,
• les spoolers d'impression,
• les serveurs de courrier électronique,
• les serveurs DNS,
• ...

Configuration d'un relais applicatif pour le Web

Le listing suivant donne un extrait de la configuration d'un serveur apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.

#cat /usr/local/etc/apache/httpd.conf
#
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
<IfModule mod_proxy.c>
ProxyRequests On
<Directory proxy:*>
Order deny,allow
Allow from all
</Directory>
#
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server ver.;"Block" removes all outgoing Via: headers)
# Set to one of: Off | On | Full | Block
#
ProxyVia On
</IfModule>
# End of proxy directives.

SOCKS

Cette technique est aussi issue des solutions pour passer d'un adressage privé à un adressage public. SOCKS ajoute un "canal de signalisation" aux données transportées, ce qui permet de piloter à distance l'ouverture de connexion. En IPv4, cette technique permet d'utiliser un adressage privé en interne pour atteindre un relais SOCKS qui se trouve dans une zone démilitarisée. Le relais SOCKS se charge d'ouvrir une connexion normale avec l'équipement distant. Le relais SOCKS se plaçant dans le modèle architectural en dessous de l'application, il est relativement indépendant de celle-ci, il n'est pas nécessaire de recourir à différents types de relais. De plus, SOCKS permet aussi bien les communications entrantes que sortantes.

SOCKS s'applique à tout type de réseau, ainsi qu'à des réseaux utilisant l'adressage privé IPv4.

Le RFC 3089 étend ce mécanisme en permettant les deux versions du protocole IP. Quatre scénarios sont possibles, comme l'indique la figure suivante :

• les protocoles X et Y sont IPv4. On est dans le cadre d'une utilisation classique de SOCKS telle qu'elle est prévue dans le RFC 1928 initial pour permettre à des équipements utilisant un plan d'adressage privé d'accéder aux ressources de l'Internet et de contrôler l'accès au réseau.
• le protocole X est IPv4 et le protocole Y est IPv6. Ce scénario permet de v6fier une application ne connaissant qu'IPv4.
• le protocole X est IPv6 et le protocole Y est IPv4. Ce scénario permet à une application IPv6 d'accéder à des ressources uniquement disponibles en IPv4
• les protocoles X et Y sont IPv6. Vu la taille des adresses IPv6, il est peu probable qu'il y ait toujours un plan d'adressage privé, non routable sur l'Internet. L'utilisation de SOCKS dans ce cas serait surtout pour contrôler l'usage des ressources réseau.

Le RFC 3089 prévoit aussi l'enchaînement de plusieurs relais SOCKS.

La principale difficulté introduite par l'utilisation de SOCKS pour la transition provient de l'interrogation du DNS. Dans le cas du deuxième scénario, où X vaut 4 et Y vaut 6, l'application ne peut que manipuler des adresses IPv4. En particulier les appels aux serveurs DNS pour la résolution de nom ne portent que sur des Resource Records de type A.

Le RFC 1928 prévoit que dans la partie "signalisation", le nom de l'équipement distant peut être envoyé de trois manières différentes :

• une adresse IPv4,
• un nom de machine,
• une adresse IPv6.

Si l'application utilise un nom de machine (FQDN : Fully Qualified Domain Name), SOCKS intercepte l'appel procédural pour la résolution et retourne à l'application une fausse adresse IP prise dans un poule. Quand l'application ouvre une connexion en utilisant cette adresse, le nom de la machine distante peut être retrouvé et est envoyé au relais SOCKS qui pourra, si le DNS retourne un enregistrement AAAA, ouvrir la connexion en utilisant le protocole IPv6.

DSTM

L'objectif de DSTM (Dual Stack Transition Mechanism) est de donner une connectivité IPv4 temporaire à un terminal dual-stack connecté à un réseau uniquement IPv6. La connectivité IPv4 n'est disponible que le temps nécessaire à une communication avec un terminal distant qui ne possède qu'une pile IPv4. Dans le principe, DSTM est en quelque sorte la réciproque du Tunnel Broker.

En général DSTM est identifié comme un mécanisme intervenant en fin de période de cohabitation IPv4/IPv6, lorsque les réseaux IPv6 sont dévenus majoritaires. Dans ce cas, DSTM peut typiquement s'appliquer soit à un réseau d'entreprise, soit à un réseau d'ISP.

DSTM se place dans la situation où une partie d'un site est passée en IPv6, mais où certaines applications continuent à utiliser IPv4. DSTM utilise une interface spéciale DTI (Dynamic Tunneling Interface) qui permet l'encapsulation des paquets IPv4 dans des paquets IPv6. Du point de vue de l'application, ce mécanisme est relativement transparent, puisque l'interface DTI est considérée comme une interface réseau classique.

Un routeur particulier appelé TEP (Tunnel End Point) possédant la connectivité entre le monde IPv4 et le monde IPv6 effectue l'encapsulation et la désencapsulation des données.

Initialement, les interfaces sont actives, mais ne disposent pas d'adresses IPv4, l'attribution d'une adresse n'est faite que lorsqu'un premier paquet est routé vers l'interface DTI. Dans ce cas, une demande d'allocation est envoyée par la machine à un serveur et une adresse IPv4 est allouée pendant la durée d'utilisation de l'interface DTI. Les paquets IPv4 sont envoyés à un TEP dont l'adresse IPv6 est généralement obtenue en même temps que l'adresse IPv4 temporaire. Le TEP garde en mémoire la correspondance entre les adresses sources IPv4 et IPv6 des paquets qu'il reçoit. De cette manière quand le destinataire sur le réseau IPv4 répond, le TEP peut déterminer vers quel équipement il peut tunneler les paquets.

L'usage de DSTM permet de ne configurer que la pile IPv6 d'un équipement. La pile IPv4 est configurée à la demande en fonction des besoins applicatifs. Le travail de configuation, de routage et de supervision de l'administrateur est donc simplifié.

Le fait d'utiliser des tunnels facilite l'allocation des adresses IPv4, car celles-ci perdent leur fonction de localisation, elles doivent juste conserver leur propriété d'unicité, ce qui est relativement facile à garantir.

NAT-PT

Le principe reste identique à celui de NAT pour IPv4. Il s'agit ici de traduire les en-têtes des datagrammes IPv6 en en-têtes de datagrammes IPv4. NAT-PT permet le déploiement de réseaux uniquement IPv6 et offrir une « compatibilité » avec le monde IPv4. Les boitiers NAT-PT sont des routeurs réalisant la traduction des paquets IPv6 en paquets IPv4 et servant de proxy DNS. Les autres équipements du réseau (derrière le boitier NAT-PT) n'ont besoin de rien de spécial pour que ce mécanisme puisse être utilisé.

• NAT-PT permet de s'affranchir d'IPv4 tout en permettant de continuer à bénéficier des services qui lui sont encore associés. Ce mécanisme introduit apres la phase de mise en ?uvre (qui n'est pas très simple) un réel allègement de la tâche de l'administrateur.
• Le mécanisme NAT-PT est en discussion dans le groupe v6ops de l'IETF pour être classé historique, son usage semble devoir être limité (voire confiné) à des situations qui ne peuvent être gérées autrement. Un document de travail inventorie les scénarios qui en ont « absolument » besoin et tente de proposer des mécanismes de remplacement.

Le principe de fonctionnement de NAT-PT pour passer d'une version à l'autre du protocole IP est le même que pour passer d'un adressage privé à une adressage public, avec également les mêmes limitations, par exemple, si les paquets transportent des adresses. Par contre, ce mécanisme offre une certaine transparence au niveau du réseau.

Les paquets émis vers un équipement uniquement IPv4 utilisent l'adresse IPv4 mappée. Par contre, l'adresse source est une des adresses IPv6 globale que possède la machine émettrice. Le préfixe des adresses IPv4 mappées est routé vers un boîtier de traduction. Ce dernier dispose d'un poule d'adresses IPv4 officielles. Quand une nouvelle session est initiée par une machine IPv6, le boîtier alloue à la nouvelle adresse IPv6, une adresse IPv4 du poule, et construit un paquet IPv4 en extrayant de l'adresse IPv4, l'adresse IPv4 mappée de destination.