Cohabitation IPv4-IPv6

Objectifs du chapitre

L’objectif de ce chapitre est de faire le point sur les principales méthodes pouvant permettre de faire communiquer des réseaux basés sur des protocoles différents. Il est en effet inévitable d’envisager une période, probablement assez longue, pendant laquelle subsisteront des réseaux IPv4 alors qu’une partie des communications utiliseront des réseaux IPv6. Nos opérateurs n’offrant pas encore tous le support d’IPv6, nous serons également amenés à faire transiter sur des réseaux IPv4 des communications entre réseaux IPv6.

Il faut donc prévoir des mécanismes susceptibles de répondre à plusieurs besoins :

C’est pourquoi il nous faut aborder les pistes les plus susceptibles de répondre à ces problématiques, pistes qui ne sont pas concurrentes mais complémentaires car elles ne s’appliquent pas aux mêmes situations :

Dual-stack IPv4-IPv6

Rappelons que les connexions réseau se font au travers d’une pile de couches réseau, d’où le terme stack en anglais que nous conservons ici pour être cohérents avec les documentations anglophones qui sont légion dans ce domaine.

Cette solution, basée sur le RFC 4213 d’octobre 2005, permet surtout de faire cohabiter les deux technologies de réseaux sur un même lien. Elle sera donc particulièrement utile pour mettre en œuvre en douceur IPv6 sur un réseau local sans en altérer (en principe) le fonctionnement en IPv4.

Elle consiste simplement à installer IPv4 et IPv6 sur un même nœud (poste ou routeur) et à les activer (et/ou à les paramétrer). Cette étape d’activation et de paramétrage est fondamentale puisque nous pouvons parfaitement disposer de systèmes d’exploitation dotés d’IPv4 et d’IPv6 sans pour autant pouvoir les utiliser simultanément tant que nous n’avons pas fait le nécessaire.

A contrario, il est parfois mais de moins en moins souhaitable, pour éviter tout trafic inutile ou toute dégradation de performance liée à un paramétrage incomplet, de désactiver IPv6 quand nous n’avons pas l’usage alors que l’OS est livré avec les deux activés (cas typique des systèmes Windows récents par exemple).

Cette technique est également utilisée par un certain...

Tunnels IPv6-IPv4

Nous abordons maintenant un domaine nettement plus vaste avec les différentes techniques permettant de faire communiquer des réseaux IPv6 au travers de réseaux IPv4. Il existe pour cela plusieurs méthodes utilisant le principe des tunnels.

Certaines établissent des tunnels directs entre les sites, d’autres passent par des intermédiaires (souvent appelé brokers) pour remplir cette fonction.

Nous allons en voir les grands principes ainsi que quelques exemples simples de mise en œuvre. Nous n’entrerons pas dans le détail de tous les protocoles, ce qui pourrait occuper des centaines de pages vu le nombre de RFC traitant du sujet, mais nous viserons à donner suffisamment d’informations pour comprendre ces techniques, choisir la plus pertinente selon le cas et l’implémenter dans des configurations basiques.

Translations d’adresse

En plus du dual-stack et du tunneling, il existe donc une troisième grande famille de techniques pour faire cohabiter IPv6 et IPv4 : la translation d’adresses.

Celle-ci est principalement utilisée pour permettre à des postes uniquement IPv6 de contacter sur Internet des postes en IPv4. Dans ce cas, nous pouvons recourir à une des techniques disponibles pour translater les adresses entre IPv6 et IPv4 lors des connexions intervenant entre le LAN et Internet.

Cette translation peut intervenir à différents niveaux des couches protocolaires utilisées par TCP/IP. Voici les protocoles les plus connus :

Faisons rapidement le tour de ces protocoles.

ALG (Application Layer Gateway ou passerelle applicative)

Dans ce type de technique, le dispositif consiste à recourir à un proxy doté à la fois d’une connexion IPv4 et d’une connexion IPv6.

Le principe est assez simple : un hôte IPv4 souhaitant par exemple envoyer un mail va se connecter en SMTP sur une passerelle SMTP qui va décoder son envoi en termes de protocole (récupération des données de l’enveloppe, du contenu du message, des pièces jointes), puis le recoder en IPv6 à destination du serveur SMTP du destinataire en IPv6. Nous pourrions imaginer la transmission inverse entre un client IPv6 vers un serveur SMTP IPv4.

Le même principe peut s’appliquer à un navigateur web en IPv4 cherchant à se connecter à un serveur en IPv6, ou bien encore à un client FTP ou à un client SIP.

La technique sera donc réservée à une liste assez limitée de protocoles faisant l’objet d’un décodage applicatif. Parmi les plus courants, nous pouvons citer :

Ces passerelles applicatives sont assez simples à mettre en œuvre. Par contre, elles ne peuvent pas concerner tous les protocoles mais une petite partie d’entre eux (reconnaissons que ce sont néanmoins les plus utilisés). De plus, elles nécessitent généralement de faire...

Comment faire un choix ?

Il est évidemment très difficile de réaliser un classement définitif des différentes solutions et les avis divergent assez fréquemment sur l’avenir et la pertinence des différents protocoles envisagés.

Nous essayons de les répartir ici par type de "client". Le choix entre les protocoles eux-mêmes se fera en fonction du but à atteindre et des contraintes posées par les réseaux/postes à relier.

Par contre, nous pouvons raisonnablement donner un ordre de préférence parmi les types de techniques :

1. Dual-stack : à préférer lorsque c’est possible puisqu’elle apporte une grande souplesse dans les communications et une connexion IPv6 native. Par contre, elle impose d’une part une double configuration de tous les matériels ou systèmes concernés, et d’autre part elle implique une bonne gestion de la sécurité.

2. Tunnel : c’est la deuxième possibilité à mettre en œuvre, notamment quand une partie des réseaux ne peuvent pas être placés en dual-stack. Elle présente par contre l’inconvénient de diminuer le MTU, de ne pas toujours bien traverser les NAT et de compliquer un peu le diagnostic des problèmes de transmission.

3. Translations : solution de repli quand les autres...

Pour le futur : tunnels IPv4-IPv6