Transition d'IPv4 vers IPv6 - Définition

Transition pour des hôtes individuels et les réseaux d'entreprise

Schéma de fonctionnement d'un tunnel statique.

Schéma de fonctionnement de 6to4.

Encodage d'une adresse IPv4 dans le préfixe 6to4.

La manière la plus simple d'accéder à IPv6 est lors de l'abonnement de choisir un FAI qui offre de l'IPv6 nativement, c'est-à-dire sans recours à des tunnels.

À défaut, et pendant une phase de transition, il est possible d'obtenir une connectivité IPv6 via un tunnel. Les paquets IPv6 sont alors encapsulés dans des paquets IPv4, qui peuvent traverser le réseau du FAI jusqu'à un serveur qui prend en charge IPv6 et IPv4, et où ils sont décapsulés. Le recours à des tunnels, et donc à un réseau overlay, est de nature à nuire aux performances. La RFC 1933 décrit les mécanismes de transition.

Tunnels configurés explicitement 

Plusieurs services du type « tunnel broker » sont disponibles, nécessitant en général une inscription. On peut citer SixXS, Freenet6, Hurricane Electric ou encore Renater.

Les protocoles utilisés peuvent être :

• 6in4 (RFC 4213) fait usage du numéro de protocole 41 d'IP et est donc parfois bloqué par des pare-feux et les NAT.
• AYIYA permet le transport sur UDP ou TCP et gère le changement d'adresse IP.
• GRE utilise le numéro de protocole 47.

Le Tunnel Setup Protocol (RFC 5572) facilite la création des tunnels et permet la mobilité et l'authentification. Le Tunnel Information and Control protocol, utilisé par AICCU (en), automatise la création des tunnels.

Tunnels automatiques 

• 6to4 (RFC 3056) si une adresse IPv4 publique (de préférence fixe) est disponible, 6to4 est simple à mettre en place. Pour l'accès aux adresses IPv6 hors du préfixe 2002::/16 (réservé pour 6to4), une adresse relais anycast est réservée, 192.88.99.1.
• 6over4 (en) (RFC 2529) permet la connexion à travers un réseau IPv4 qui prend en charge multicast
• ISATAP (RFC 5214), une amélioration du précédent qui ne requiert pas le support multicast.
• Teredo (RFC 4380) utilisable dans un réseau d'adresses IPv4 privées, relié à Internet via un routeur assurant une traduction d'adresses. Une implémentation de Teredo fait partie de la pile IPv6 des systèmes Windows, et une implémentation pour Linux et les systèmes BSD est miredo.

Traduction de protocole dans le réseau

• Stateless IP/ICMP Translation (SIIT, RFC 2765) est un mécanisme de traduction d'en-tête entre IPv6 et IPv4. Le RFC ne décrit pas de manière générale d'associer les adresses IPv6 et IPv4. Le fonctionnement de SIIT ne permet pas d'associer plus de deux adresses uniques de chaque protocole par hôte. Ceci signifie que chaque hôte IPv6 doit également disposer d'une adresses IPv4 publique.

• NAT-PT (RFC 2766) est semblable. Les routeurs intermédiaires entre IPv6 et IPv4 modifient les en-têtes. Un proxy DNS examine les requêtes provenant des hôtes et assigne des adresses IPv4 ou IPv6 fictives quand la réponse DNS indique qu'une famille manque. Le recours à la modification des RR DNS rend cependant DNSSEC inopérant.

• Dual-Stack Transition Mechanism (DSTM) permet également la traduction d'adresse IPv4 et IPv6.

Traduction de protocole dans l'hôte

Il n'est pas toujours possible de modifier les applications rapidement pour les rendre compatibles avec IPv6, quand le code source n'est pas disponible, par exemple.

Les techniques suivantes permettent à une application IPv4 de fonctionner sur un système doté d'une double pile et de communiquer avec des clients IPv6. Les techniques sont utilisées en combinaison avec le resolver DNS pour assigner des adresses IPv4 fictives automatiquement et les faire correspondre aux adresses IPv6 qui sont réellement utilisées dans le réseau.

• Bump in the Stack (BIS, RFC 2767) intervient à l'intérieur du noyau d'un système d'exploitation et permet aux applications IPv4 de fonctionner sans modification, une couche logicielle additionnelle assurant la communication entre les protocoles au niveau TCP ou UDP. Il utilise le mécanisme de SIIT pour traduire les protocole et hérite des limitations de SIIT.

• Bump in the API (BIA, RFC 3338) fait de même au niveau de l'interface de programmation. Comme il intervient à un niveau supérieur, il n'est pas nécessaire d'effectuer de la traduction d'en-tête.

• SOCKS (RFC 3089) est fonctionnellement semblable, il se base sur le protocole décrit dans la RFC 1928.

Passerelles applicatives

Il est possible de faire usage de serveurs qui disposent d'une double pile et qui font office de passerelle applicative (Application-Level gateway, ALG), un serveur proxy web par exemple.