6to4

 

6to4 réalise 3 tâches :

1. Assigne un bloc d'adresses IPv6 à tout hôte ou réseau qui dispose d'une adresse IPv4
2. Encapsule les paquets IPv6 à l'intérieur de paquets IPv4 afin de permettre leur transition sur un réseau IPv4
3. Effectue le transit du trafic entre 6to4 et les réseaux IPv6 « natifs » (agit comme un routeur)

Pour toute adresse 32 bits IPv4 globale qui est assignée à un hôte ou à un réseau, un préfixe 48 bits 6to4 IPv6 peut être construit ou utilisé par cet hôte ou réseau en préfixant 2002 (hex) à son adresse IPv4. Donc pour l'adresse IPv4 globale 207.142.131.202, le préfixe 6to4 correspondant serait 2002:CF8E:83CA::/48 (les adresses IPv4 sont généralement notées en décimal tandis que les adresses IPv6 le sont en hexadécimal).

Étant donné que les adresses IPv6 sont sur 128 bits et que 6to4 fournit un préfixe de 48 bits, 6to4 autorise plus de 2⁸⁰ hôtes IPv6 sur un réseau pour communiquer avec d'autres hôtes IPv6, même si seule la connexion extérieure utilise IPv4 et qu'il n'y a qu'une seule adresse IPv4.

Toute adresse IPv6 qui débute avec 2002::/16 est donc reconnue comme une adresse 6to4, par opposition à une adresse native IPv6 qui n'utilisera pas ce préfixe.

 

6to4 encapsule un paquet IPv6 dans la zone de données (payload) d'un paquet IPv4 avec protocole de type 41. Pour envoyer un paquet IPv6 sur un réseau IPv4 vers une adresse de destination 6to4, un en-tête IPv4 avec type de protocole 41 est préfixé au paquet IPv6.

L'adresse de destination IPv4 pour l'en-tête de paquet préfixée est dérivée de l'adresse IPv6 de destination qui est à l'intérieur du paquet IPv6, en extrayant les 32 bits qui suivent immédiatement l'en-tête d'adresse de destination IPv6 (2002::/16). L'adresse source IPv4 dans l'en-tête de paquet IPv4 préfixée est l'adresse IPv4 de l'hôte ou routeur qui envoie le paquet sur le réseau IPv4.

Le paquet IPv4 résultant est dirigé vers sa destination IPv4 comme n'importe quel paquet IPv4.

Pour permettre aux hôtes et aux réseaux utilisant des adresses 6to4 d'échanger des données avec les hôtes utilisant nativement des adresses IPv6, des routeurs relais (relay routers) ont été mis en place. Un routeur relais se connecte à un réseau IPv4 et à un réseau IPv6. Les paquets 6to4 arrivant sur l'interface IPv4 auront leurs données IPv6 dirigées sur le réseau IPv6, tandis que les paquets IPv6 arrivants sur l'interface IPv6 avec une adresse de destination commençant par 2002::/16 seront encapsulés et retransmis sur le réseau IPv4.

Les paquets transitant de l'internet IPv6 à des systèmes 6to4 doivent être envoyés à un routeur relais 6to4 par des méthodes de routage IPv6 normales. La spécification établit que les routeurs relais ne doivent informer que des routes pour les 2002::/16 et non pour les subdivisions de manière à éviter que les routes IPv4 ne viennent polluer les tables des routeurs IPv6. À partir de quoi, ils peuvent être transmis au travers de l'internet IPv4 vers leur destination.

Pour permettre à un routeur 6to4 de communiquer avec l'internet IPv6 natif, il doit impérativement avoir son point d'accès par défaut pointant vers l'adresse IPv4 d'un routeur relais 6to4. Ceci doit être réalisé manuellement dans chaque réseau concerné.

Toutefois, afin d'éviter aux utilisateurs le besoin d'établir ceci manuellement, l'adresse anycast 192.88.99.1 avait été allouée par la RFC 3068^[2] pour l'envoi de paquets à un routeur relais. Pour des raisons de routage, la totalité de 192.88.99.0/24 a été allouée pour des routes conduisant vers des routeurs relais 6to4 qui utilisent des IP anycast. Les fournisseurs d'accès souhaitant fournir ce service à leurs clients ou pairs sur l'IP anycast 6to4 pouvaient annoncer le préfixe anycast comme tout préfixe IP dans BGP.

La RFC 7526^[3] a rendu obsolète cette fonctionnalité particulière (IPv4 Anycast pour relais 6to4), en raison des problèmes rencontrés (annonce de l'IP sans relais derrière, notamment).

• le routeur IPv6 doit disposer d'une adresse IP publique et de préférence fixe,
• le routage vers l'Internet IPv6 est asymétrique : pour l'aller on suit la route IPv4 du relais 6to4 (initialement, de l'adresse anycast 192.88.99.1), pour le retour la route vers 2002::/16.
• si l'adresse IPv4 publique varie, le réseau IPv6 dépendant devra être renuméroté.
• la qualité de l'accès dépend de la proximité des relais 6to4 et de leur état de congestion.

6to4 est en butte à des problèmes opérationnels :

• si un routeur d'Internet annonce les préfixes 192.88.99.0/24 ou 2002::/16 alors que la passerelle 6to4 n'est pas opérationnelle, cela crée une perte de connectivité pour des tiers (un trou noir), c'est un aspect corrigé par 6rd qui donne le contrôle de la passerelle au fournisseur d'accès à Internet. C'est pourquoi le préfixe 192.88.99.0/24 n'est plus associé à 6to4 depuis la RFC 7526^[3].
• s'il existe des pare-feux bloquant le protocole 41 et que la connectivité IPv6 est utilisée en priorité, une dégradation de la qualité de l'accès aux site Internet IPv6 dual-stack est observée. Des mesures effectuées sur le site du RIPE en 2010 ont indiqué que 15 à 20 % des requêtes IPv6 qui échouent sont le fait de connexions 6to4^[4], ce qui met en question l'utilité de 6to4 dans un scénario de transition. Comme le montrent les chiffres du RIPE Labs et d'autres travaux, le problème affecte particulièrement certaines versions de MacOS X utilisant un routeur Airport Extreme^[5]. Les versions récentes des systèmes d'exploitation sont configurés pour préférer une connexion IPv4 à une connexion IPv6 via 6to4.

De par le développement d'IPv6 natif d'une part, des problèmes rencontrés^[6] avec 6to4 d'autre part, 6to4 en lui-même paraît désormais^[7] dépassé^[8] et son utilisation a du reste décru^[9] continument dès le début des années 2010.

• B. Carpenter & K. Moore. Connection of IPv6 Domains via IPv4 Clouds. RFC 3056^[1], février 2001.
• R. Gilligan & E. Nordmark. Transition Mechanisms for IPv6 Hosts and Routers. RFC 2893^[10], août 2000.
• Christian Huitema. An Anycast Prefix for 6to4 Relay Routers. RFC 3068^[2], juin 2001.
• P. Savola & C. Patel. Security Considerations for 6to4. RFC 3964^[11], décembre 2004.

• 6rd
• Teredo
• Internet Protocol

•   Portail de l’informatique
•   Portail des télécommunications