Revision as of 16:58, 31 March 2016

Activité 43: Etablir la connectivité IPv6

Problématique

Lorsqu'un réseau IPv6 veut joindre un autre réseau IPv6 séparé par un réseau en IPv4, le problème consiste à offrir une connectivité IPv6 entre ces 2 réseaux. La bonne solution serait de les interconnecter avec IPv6 uniquement, c'est à dire sans avoir recours à IPv4. Mais quand cela n'est pas possible, la connectivité s'établit par des mécanismes de niveau réseau reposant sur le principe du tunnel. Ainsi, le tunnel est la solution pour utiliser une infrastructure IPv4 existante pour acheminer du trafic IPv6.

Les tunnels peuvent s'utiliser aussi bien pour la connectivité d'un site IPv6 avec l'Internet v6 (si le FAI n'offre pas encore nativement cette connectivité) que pour l'intérieur d'un site en IPv4 si celui-ci comporte des parties en IPv6 non connexes. Par la suite nous allons décrire le fonctionnement d'un tunnel IPv6 sur IPv4 en montrant le principe du tunnel configuré et du tunnel automatique. De nombreuses techniques à base de tunnels existent comme le rappelle le RFC 7059, nous retiendrons la technique adaptée à une simple connectivité avec l'Internet v6 et celle pour établir des tunnels automatique à l'intérieur d'un site.

Principe du tunnel IPv6 sur IPv4

Le tunnel est un mécanisme bien connu dans le domaine des réseaux, qui consiste à faire qu’une unité de transfert d'un protocole (PDU Protocol Date Unit) d'une couche se trouve encapsulée dans la charge utile de l'unité de transfert (PDU) d’un autre protocole de la même couche. Ainsi, des protocoles « transportés » peuvent circuler dans un réseau construit sur un protocole encapsulant. Dans le cas d'IPv6, cette technique a été définie dans le RFC 4213 et porte le nom de 6in4. L'encapsulation du paquet IPv6 dans le paquet IPv4 s'effectue comme illustré par la figure 1. Le paquet IPv6 occupe le champ "données" du paquet IPv4. Le champ protocol de l'en-tête IPv4 prend alors la valeur 41 pour indiquer IPv6. Les extrémités du tunnel peuvent être des hôtes ou des routeurs. Les noeuds aux extrémités du tunnel sont appelés des tunneliers (tunnel end point) et peuvent être configurées manuellement ou avoir une configuration dynamique. Dans ce dernier cas, on parle aussi de tunnel automatique.

Figure 1: Encapsulation pour un tunnel.

Le notion de tunnel équivaut alors à un câble virtuel bi-directionnel permettant d’assurer une liaison point à point entre deux nœuds IPv6 ou entre deux réseaux IPv6 et fournir ainsi une connectivité comme l’illustre la figure 2.

Figure 2: Tunnel entre des réseaux IPv6.

Les tunneliers sont dans cet exemple des routeurs en double pile. L'architecture de protocoles peut se représenter par la figure 3. Cette figure montre la réception d'un paquet en IPv6 natif et son émission dans le tunnel. La réception d'un paquet IPv6 du tunnel et son émission en natif emprunte le même chemin mais en sens inverse. Le routeur tunnelier est un noeud qui comme tous les routeurs possède au moins 2 interfaces. Sa particularité est que l'interface constituée par IPv4 est une interface logique. Physiquement, ce noeud peut n'avoir qu'une seule carte réseau. Il convient à ce stade de rappeler que les systèmes de transmission comme Ethernet ou Wi-Fi sont multiprotocoles : ils sont capables de transmettre des trames contenant des paquets IPv4 comme IPv6.

Figure 3: Architecture d'un routeur tunnelier.

La différence avec un câble réel porte sur la taille de la MTU. En raison de l'encapsulation dans IPv4, un tunnel diminue la MTU effective d'une vingtaine d'octets. Normalement, la fragmentation et la découverte de la MTU du chemin servent à adapter la taille des paquets IPv6 à la MTU du tunnel. En pratique, des routeurs mal configurés peuvent filtrer les messages ICMP, dont le type utilisé pour la découverte de la MTU (message ICMP Packet Too Big). Ceci a pour effet d'empêcher la détermination de la MTU, et donc rend la fragmentation IPv6 inopérante. Cela génère des erreurs de transmission, comme un client qui parvient a communiquer avec un serveur tant qu'il envoie des petits paquets mais qui ne reçoit rien quand il demande un fichier, c'est à dire quand les paquets de taille importante sont émis. Pour rappel, les paquets IPv6, lorsqu'il ne peuvent être transmis par un routeur à cause de leur taille, sont supprimés par celui-ci. Conjointement à la destruction du paquet, le message ICMP Packet Too Big est envoyé à la source pour que celle-ci ajuste la taille du paquet.

Tunnel configuré

La configuration d'un tunnel consiste à créer une interface réseau représentant l'extrémité du tunnel, indiquer les adresses IPv4 des extrémités, allouer un préfixe IPv6 pour ce lien point à point virtuel et spécifier les routes pour suivre ce tunnel. Dans le cas d'un tunnel configuré, les informations de la réalisation du tunnel sont indiquées par un administrateur.

Pour illustrer la configuration d'un tunnel, la figure 4 montre le cas d'un tunnel reliant un hôte sous Linux avec un routeur. Dans cette situation, le fichier de configuration (ci-dessous) indique la création de l'interface nommée 6in4. Le point de sortie du tunnel est indiqué. Comme les paquets IPv6 sont encapsulés dans un paquet IPv4, celui-ci doit avoir une adresse source et une adresse de destination. L'adresse de destination est celle du point de sortie du tunnel, ici 192.0.3.1. L'interface 6in4 est configurée par l'adresse et le préfixe 2001:db8:caf:1::2/64. L'adresse IPv6 de l'interface 6in4 du coté du routeur ainsi que la route par défaut sont ensuite précisées. Ces instructions sont décrites dans la documentation en ligne de Linux dans la section 5 de interfaces.

auto 6in4
iface 6in4 inet6 v4tunnel
address 2001:db8:caf:1::2
netmask 64
endpoint 192.0.3.1
gateway 2001:db8:caf:1::1

post-up route -A inet6 add ::/0 dev 6in4

Figure 4: Cas d'un tunnel configuré.

Les performances d'un tunnel vont dépendre de sa longueur. Pour éviter d'avoir des délais trop importants, il convient de configurer un tunnel vers le point IPv6 le plus proche.

Tunnel automatique

Un tunnel configuré demande un travail de configuration, ce qui peut être vu comme un inconvénient. Des solutions d'automatisation ont été étudiées, qui ont comme principe de contenir l'adresse IPv4 du tunnelier de destination dans l'adresse IPv6. La technique de transition 6to4 décrite par le RFC 3056 suit ce principe. Elle vise à interconnecter entre eux des sites IPv6 isolés en créant des tunnels automatiques IPv6 dans IPv4 en fonction du destinataire des données. La figure 5 montre 2 réseaux IPv6 communiquant entre eux via un tunnel automatique 6to4. Le point fort du mécanisme présenté ici est l'automatisation, où l'intervention de l'administrateur est réduite à une phase de configuration/ initialisation du service et non à une phase de configuration des tunnels.

Figure 5 : 6to4.

Comme 6in4, l'encapsulation des paquets IPv6 s'effectue directement dans les paquets IPv4. 6to4 profite d'un préfixe IPv6 réservé 2002::/16. Le préfixe de l'adresse IPv6 d'un tunnelier est composé automatiquement en concaténant le préfixe réservé et l'adresse IPV4 unicast globale de ce tunnelier comme montré par la figure 6. Ainsi, un préfixe IPv6 de longueur 48 bits peut être aisément construit en utilisant l'adresse IPv4 du noeud en bordure des réseaux IPv4 et IPv6. Ce préfixe peut identifier un site IPv6. De cette manière, 6to4 se suffit à lui-même pour créer un préfixe IPv6 pour un site en toute autonomie. On peut remarquer que ce plan d'adressage est conforme au plan d'adressage global actuellement en vigueur, puisqu'il réserve 16 bits pour numéroter les réseaux du site (noté SID) et 64 bits pour les identifiants d'interface (noté IID).

Figure 6: Format d'une adresse 6to4.

Par exemple, la figure 7 illustre le mécanisme de construction d'un préfixe. Le routeur 6to4 se trouve en bordure du réseau. Il est connecté à la fois à l'Internet v4 et à un site IPv6. C'est un noeud en double pile, il possède obligatoirement une adresse IPv4, 192.0.2.1 dans l'exemple. Il va s'en servir pour construire le préfixe 2002:c000:201::/48 (0xc0 = 192) . Ce préfixe de 48 bits va être utilisé par l'ensemble des noeuds IPv6 du site.

Figure 7: Construction d'un préfixe 6to4.

Au niveau du routage, la figure 8 présente l'envoi d'un paquet IPv6 de l'hôte A vers l'hôte B. Il est important de noter ici que A et B sont des hôtes ayant une adresse IPv6 prise dans le plan d'adressage 6to4. Dans un premier temps, A interroge le DNS pour connaître l'adresse IPv6 de B. Dans notre exemple, la réponse est 2002:c000:301:1::8051. Dans un second temps, l'hôte A émet le paquet vers cette destination. Ce paquet IPv6 dont l'adresse de destination commence par le préfixe 2002::/16 doit passer par un tunnel 6to4. C'est au routeur 6to4 du site de A qu'il revient d'effectuer cette opération. Ainsi, le paquet doit suivre la route IPv6 2002::/16 pour atteindre ce routeur 6to4. Ce dernier analyse l'adresse IPv6 de destination et trouve l'adresse IPv4 de l'autre extrémité du tunnel (192.0.3.1 dans l'exemple). Il pourra alors effectuer la transmission en encapsulant le paquet IPv6 dans un paquet IPv4. C'est cette encapsulation qui forme le tunnel. Le routeur 6to4 du coté de B décapsule le paquet IPV6 et le route normalement vers sa destination finale B en utilisant le routage interne.

Figure 8: Acheminement d'un paquet IPv6 en 6to4.

Si 6to4 est une technique intéressante pour relier deux nuages IPv6 à travers un nuage IPv4, elle se complique et n'est pas optimale lorsqu'il s'agit de communiquer avec une machine dont l'adresse est issue d'un plan de numérotation globale. Car un site isolé utilisant 6to4 n'est pas directement connecté à l'Internet v6. Dans ce cas, le site 6to4 doit passer par un relais (ou routeur passerelle) qui est connecté à la fois à l'Internet v6 et à l'Internet v4. Dans le RFC 3068, il a été proposé d'utiliser une adresse anycast qui soit commune à tous ces relais à travers le monde. Une adresse anycast est définie pour chaque version du protocole IP. N'importe quel relais 6to4 de l'Internet est joignable ainsi à cette adresse. Aussi cette adresse est annoncée par les relais 6to4 et donc existe de multiples fois sur l'Internet. Il est du ressort du routage d'identifier le relais le plus proche de l'émetteur pour lui acheminer ses paquets.

Dans le contexte dérégulé de l'Internet actuel, aucun FAI n'a intérêt à offrir un tel service mutualisé, car il verra le trafic IPv6 des clients de ses concurrents charger son infrastructure au détriment de la qualité de service de ses propres clients. De plus, le relais pose aussi le problème de sa résistance au facteur d'échelle et de la qualité de sa connectivité. Comme il n'est pas possible de choisir le relais et que leur qualité varie fortement, ceci rend la communication passant par 6to4 très imprévisible. Enfin, le routage n'est pas optimal et presque assurément asymétrique :

• le site 6to4 peut avoir choisi un routeur passerelle loin du destinataire,
• le site ayant un plan d'adressage global envoie les paquets vers le routeur passerelle le plus proche au sens du routage IPv6.

Cette asymétrie, des trajets aller et retour vers l'Internetv6, peut se voir sur la figure 9. Le problème de l'asymétrie est qu'elle complique la tâche de recherche d'erreurs en cas de dysfonctionnement et surtout qu'elle introduit des délais de propagation élevés, dus à la longueur des tunnels.

Figure 9: Routage asymétrique.

L'analyse du service de connectivité en 6to4 montre une mauvaise qualité^[1]. En effet, le taux de panne des communications passant par 6to4 est significativement élevé. Ceci a eu pour effet de ralentir le déploiement d'IPv6. Bien que l'idée de tunnel automatique développée par 6to4 soit intéressante, sa mise en oeuvre est problématique. En mai 2015, par la publication du RFC 7526, l'IETF prône la dépréciation de l'annonce du préfixe anycast réservé aux relais 6to4, ce qui de fait officialise l'abandon de cette technique. Nous verrons par la suite que 6to4 est finalement supplanté par la technique de tunnel connue sous le nom de 6rd.

Connectivité d'un site isolé : Tunnel Broker

La croissance du réseau IPv6 a commencé en s'appuyant sur l'infrastructure de communication de IPv4. Les premiers tunnels étaient configurés manuellement et pouvaient être très longs (et donc peu performants). La longueur d'un tunnel s'apprécie par le nombre de sauts IPv4 et/ou la distance qui sépare les 2 extrémités du tunnel. Pour des personnes non qualifiées, ceci reste complexe tant du point de vue technique que du point de vue du choix du point de sortie du tunnel. La constitution d'un tunnel a été simplifiée par l'introduction du Tunnel Broker [RFC 3053]. Les Tunnel Brokers représentent une méthode pour connecter un réseau IPv6 à l’Internet v6. L'idée du Tunnel Broker consiste à mettre en oeuvre une interaction de type client/serveur. La partie cliente est localisée côté utilisateur tandis que la partie serveur traite les demandes de tunnels. Le modèle du Tunnel Broker est représenté par la figure 10.

Figure 10: Modèle du Tunnel Broker.

La création d'un tunnel à l'aide d'un Tunnel Broker fonctionne de la manière indiquée par la figure 11, à savoir :

1. Une machine double pile du réseau IPv6 (typiquement un routeur) négocie avec le Tunnel Broker afin de s'authentifier et d'obtenir les informations de configuration du tunnel ainsi qu'un préfixe délégué ;
2. Le Tunnel Broker configure le serveur de tunnel retenu ;
3. Le Tunnel Broker envoie le script de configuration à la machine double pile coté utilisateur ;
4. Cette dernière en exécutant le script reçu crée le tunnel. Elle va ensuite encapsuler ses paquets IPv6 dans des paquets IPv4 à destination du serveur de tunnels, qui sert également de routeur. Ainsi une communication en IPv6 peut s'effectuer entre des noeuds d'un réseau IPv6 isolé avec des noeuds de l'Internet v6.

Figure 11: Configuration d'un Tunnel Broker avec TSP.

La négociation est opérée à l'aide du protocole TSP (Tunnel Set Up Protocol) [RFC 5572]. En l'absence de TSP, la demande de connexion au Tunnel Broker est réalisée par une interface web dont l'URL est connue à l'avance. Par cette interface, les paramètres nécessaires à l'établissement du tunnel entre le noeud de l'utilisateur et le serveur de tunnels sont récupérés. Le protocole de négociation TSP automatise cet échange. Plus précisément, TSP traite les paramètres suivants :

• l'authentification de l'utilisateur ;
• le type de tunnel :
  • tunnel IPv6 sur IPv4 [RFC 4213] ;
  • tunnel IPv4 sur IPv6 [RFC 2473] ;
  • tunnel IPv6 sur UDP-IPv4 pour la traversée de NAT ;
• les adresses IPv4 pour les deux extrémités du tunnel ;
• l'adresse IPv6 assignée lorsque le client TSP est un terminal ;
• le préfixe IPv6 alloué lorsque le client TSP est un routeur.

TSP s'appuie sur l'échange de simples messages XML dont un exemple est donné ci-dessous. Cet exemple correspond à la demande de création d'un tunnel simple par un client TSP :

-- Successful TCP Connection --
C:VERSION=2.0.0 CR LF
S:CAPABILITY TUNNEL=V6V4 AUTH=ANONYMOUS CR LF
C:AUTHENTICATE ANONYMOUS CR LF
S:200 Authentication successful CR LF
C:Content-length: 123 CR LF
<tunnel action="create" type="v6v4">
<client>
<address type="ipv4">1.1.1.1</address>
</client>
</tunnel> CR LF
S: Content-length: 234 CR LF
200 OK CR LF
<tunnel action="info" type="v6v4" lifetime="1440">
<server>
<address type="ipv4">206.123.31.114</address>
<address type= "ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0000</address>
</server>
<client>
<address type="ipv4">1.1.1.1</address>
<address type= "ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
<address type="dn">userid.domain</address>
</client>
</tunnel> CR LF
C: Content-length: 35 CR LF
<tunnel action="accept"></tunnel> CR LF

La connectivité offerte par les Tunnel Brokers est en général fournie à titre provisoire (soit en attendant que l'offre des FAI soit disponible, soit pour faire des tests de validation, par exemple). Elle peut aussi être une première étape pour un prestataire de service pour procurer de la connectivité IPv6 à ses usagers. Afin de promouvoir le passage à IPv6, les Tunnel Brokers sont souvent gratuits^[2]. Lorsque le Tunnel Broker a une faible répartition géographique de ses serveurs de tunnel. Pour certains utilisateurs, la longueur des tunnels reste un problème.

Connectivité sur une infrastructure IPv4 : 6rd

Le mécanisme 6rd (IPv6 Rapid Deployment) proposé par le RFC 5569, après son déploiement par Free, a été étendu pour devenir un standard par le RFC 5969. 6rd reprend le principe des tunnels automatiques du 6to4 mais apporte des modifications pour éviter les défauts de performances et de fiabilité observés sur 6to4. 6rd est destiné à un opérateur pour offrir une connectivité IPv6 alors que son infrastructure repose sur IPv4. Cet opérateur peut être aussi bien public comme un FAI, ou privé comme une entreprise ou une administration.

6rd est une variante de 6to4 comme cela a été précisé. La différence majeure se situe sur l'utilisation du préfixe IPv6 propre à l'opérateur plutôt que le préfixe commun à tous employé par 6to4 (2002::/16). Il s'ensuit que l'opérateur doit installer ses propres relais pour offrir la connectivité avec l'Internet v6. Le relais est un routeur de bordure équipé en double pile. Dans la figure 12 qui schématise l'architecture de 6rd, le routeur de bordure est noté, selon la terminologie du RFC 5969, 6rd BR (Border Relays). Le préfixe IPv6 propre à cet opérateur est noté pref6rd. En contrepartie de l'installation des relais, l'opérateur contrôle les tunnels. Il peut ainsi garantir que la voie retour est symétrique à la voie aller. Autre conséquence, les tunnels sont plus courts: ils servent à passer la section IPv4 de l'opérateur. En contrôlant les tunnels, les principaux défauts du déploiement de 6to4, comme des délais importants ou l'asymétrie, sont corrigés. Avec 6rd, on se retrouve dans le cas classique où les routeurs internes (dont les relais) traitent le trafic des noeuds internes, ainsi ces relais ne servent que clients de l'opérateur (contrairement à 6to4 où les relais étaient mutualisés et publics). Comme 6to4, 6rd est sans état et les routeurs de bordures peuvent utiliser une même adresse IPv4 (que l'on qualifie d'anycast). En somme, l'idée de 6rd est de restreindre la technique 6to4 à un usage interne et local.

Figure 12: Architecture de 6rd.

Le format de l’adresse IPv6 utilise un préfixe 2000::/3 pris dans le plan d'adressage global unicast. Il devient alors difficile de différencier un trafic sortant d’un réseau 6rd d’un trafic IPv6 natif. Le préfixe IPv6 du domaine de l'opérateur est complété par tout ou partie de l'adresse IPv4 du routeur en double pile (appelé 6rd CE, Customer Edge, dans la figure 12) du réseau IPv6 à connecter pour former le préfixe IPv6 de ce réseau. L'adresse IPv4 du routeur 6rd CE est normalement publique, mais ce n’est pas obligatoire. L’organisation de l’adresse IPv6 est décrite par la figure 13. À noter que, au sein d'un même opérateur, si les adresses IPv4 s'agrègent sur un préfixe commun, il n'est pas nécessaire d'encoder les 32 bits de l'adresse IPv4 dans le préfixe IPv6, ce qui libère des bits pour laisser une numérotation des liens internes au réseau IPv6 à connecter. Il est laissé le soin à chaque opérateur de définir le nombre de bits de l'adresse IPv4 à conserver. La seule contrainte est que le préfixe réseau ne doit pas dépasser 64 bits.

Figure 13: Format d'une adresse 6rd.

Pour illustrer la figure 13, considérons tout d’abord que l’adresse IPv4 192.0.2.129 (c000:2f1 en hexadécimal) a été attribuée à l’interface d'un 6rd CE. L'opérateur dispose du préfixe l'IPv6 2001:DB8::/32 pour son domaine 6rd. Les adresses de tous les 6rd CE s'agrégent sur le préfixe 192.0.0.0/8. L'opérateur peut garder 24 bits comme partie significative. Le préfixe IPv6 de chaque 6rd CE aura donc une longueur de 56 bits correspondant à l'addition du préfixe du domaine avec la partie significative de l'adresse IPv4. Dans notre exemple, le préfixe IPv6 pour ce 6rd CE sera 2001:db8:0002:f100::/56. il restera 8 bits au titre du SID (Subnet Identifier) pour la numérotation des liens du site connecté par le 6rd CE. A l’extérieur du site, ces adresses apparaîtront comme des adresses IPv6 natives, mais au travers d’un tunnel entre les routeurs de bordures de l'opérateur et le 6rd CE.

Le transfert avec la technique 6rd s'organise selon 3 cas :

• Transfert inter-site. La figure 12 illustre ce cas lorsque les 2 hôtes souhaitent communiquer. La source de préfixe pref6rd:a4 envoie un paquet IPv6 à destination de l'hôte de préfixe pref6rd:b4. Le paquet IPv6 arrive en mode natif au 6rd CE de la source. Si l’adresse IPv6 de destination est incluse dans le préfixe du domaine 6rd configuré localement il sera transmis directement à un autre CE 6rd comme c'est le cas ici. Les adresses IPv4 des 6rd CE sont extraites des adresses IPv6 pour constituer le tunnel. Le paquet IPv4 d'adresse source a4 et d'adresse destination b4, encapsule le paquet IPv6. Ce paquet IPv4 est acheminé au 6rd CE de destination par l'infrastructure IPv4 de l'opérateur. Le routeur 6rd CE de destination reçoit le paquet IPv4. Il vérifie par mesure de sécurité, que l'adresse source de l'en-tête IPv4 correspond à celle intégrée dans l'adresse IPv6 source. Il désencapsule le paquet IPv6 et le transmet sur le lien local pour son acheminement à la destination IPv6.
• Transfert du site vers l'Internet v6. Le trafic IPv6 est reçu en mode natif sur le 6rd CE. L'adresse de destination IPv6 ne correspond pas à un préfixe IPv6 du domaine de l'opérateur, ce qui signifie que la destination est extérieure au domaine de 6rd local. Dans ce cas, le paquet IPv6 doit être transmis à un routeur de bordure 6rd. Comme dans le cas du transfert inter-site, le paquet IPv6 est encapsulé dans un paquet IPv4. Cependant, la différence est que l'adresse IPv4 du routeur de bordure est obtenue dans la table de routage. Le routeur de bordure reçoit le paquet IPv4 et supprime l'encapsulation IPv4. Après le contrôle de sécurité, le paquet IPv6 est transmis sur l'Internet v6.
• Transfert de l'Internet v6 vers le site. Si un routeur de bordure reçoit un paquet IPv6 à destination d’une adresse IPv4 incluse dans le préfixe 6rd du domaine, il transmet le paquet au routeur 6rd CE correspondant en utilisant le même principe que le cas précédent.

La technique 6rd est adaptée à une mise en œuvre locale d’IPv6 pour un opérateur dont l'infrastructure interne fonctionne encore en IPv4^[3]. Cette technique de tunnel répond à des questions de fiabilité et de délai dus au routage asymétrique de 6to4. A la différence de 6to4, 6rd ne peut pas être déployé par un utilisateur seul. Comme le relais avec l'Internet v6 est administré par et pour l'opérateur lui-même, le service de connectivité est de meilleure qualité. En cas de défaillance, la responsabilité de l'opérateur est directement engagée.

Conclusion

Dans la démarche d'intégration d'IPv6, la meilleure solution est d'utiliser IPv6 nativement, à savoir comme IPv4. La complexité supplémentaire induite par les tunnels, ainsi que la réduction de la MTU qu'ils imposent (entraînant des problèmes de connectivité "épisodique") sont épargnés. Mais il n'est pas toujours possible de maintenir la connectivité IPv6 ou de trouver un opérateur offrant la connectivité IPv6. Alors, dans ces situations, il faut se résoudre à utiliser des tunnels. Le RFC 7059 effectue un inventaire des techniques d'intégration reposant sur des tunnels. Toutes les techniques ne se valent pas du point de vue des performances et de la fiabilité. Les meilleures techniques sont celles qui établissent des tunnels locaux ou de courte distance et pour lesquelles les extrémités du tunnel sont gérées et offrent un service contractuel. Le choix d'une technique de tunnel doit se faire en fonction des besoins de connectivité du réseau dans lequel IPv6 doit être intégré.

Nous avons présenté dans cette activité les techniques les plus intéressantes pour établir une connectivité IPv6. Le tunnel broker représente une méthode pour tirer un simple tunnel entre un réseau IPv6 isolé et un point d'entrée de l'Internet v6. Les techniques 6to4 et 6rd utilisent des tunnels automatiques au sein du réseau IPv4 d'une organisation. Si l'idée de tunnel automatique de 6to4 est bonne, sa mise en oeuvre a été problématique. La variante 6rd corrige les défauts de 6to4.

6to4 et 6rd reposent tous deux sur l'encapsulation directe, à savoir que le paquet IPv6 est placé directement dans un paquet IPv4. Ce mode d'encapsulation ne traverse pas les NAT, car les NAT ont, pour la plupart, la capacité de traiter uniquement les protocoles de transport TCP et UDP. La technique de tunnel Teredo [RFC 4380] traite ce problème en encapsulant les paquets IPv6 dans UDP puis dans IPv4. Il a été reporté par l'article^[4] des performances et une fiabilité du service de connectivité qui était pire que ce qui est rendu par 6to4.

Pour conclure, nous rappelons la règle de connectivité d'IPv6 qui dit : Dual stack where you can ; tunnel where you must.

Références bibliographiques

1. ↑ Huston, G.(2010). The ISP Column. Flailing IPv6
2. ↑ Linux Review. Free IPv4 to IPv6 Tunnel Brokers
3. ↑ Cisco. (2011). White paper. IPv6 Rapid Deployment: Provide IPv6 Access to Customers over an IPv4-Only Network
4. ↑ Huston, G. (2011). The ISP Column. Testing Teredo

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer :

• RFC 2473 Generic Packet Tunneling in IPv6 Specification
• RFC 3053 IPv6 Tunnel Broker
• RFC 3056 Connection of IPv6 Domains via IPv4 Clouds
• RFC 3068 An Anycast Prefix for 6to4 Relay Routers
• RFC 4213 Basic IPv6 Transition Mechanisms Analyse
• RFC 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
• RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) Analyse
• RFC 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) Analyse
• RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) Analyse
• RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment Analyse
• RFC 6343 Advisory Guidelines for 6to4 Deployment
• RFC 6782 Wireline Incremental IPv6 Analyse
• RFC 7059 A Comparison of IPv6 over IPv4 Tunnel Mechanisms Analyse
• RFC 7381 Enterprise IPv6 Deployment Guidelines Analyse
• RFC 7526 Deprecating Anycast Prefix for 6to4 Relay Routers Analyse

Autres présentations

• Présentation de 6RD