Revision as of 10:20, 28 January 2022

> MOOC>Contenu>Doc compagnon > Activité 42

Activité 42 : Établir 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 deux 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^[1].

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 celui 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 automatiques à 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 Data 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 nœuds, aux extrémités du tunnel, sont appelés des tunneliers (tunnel end point) et peuvent être configurés 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 à un câble virtuel bidirectionnel 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 empruntent le même chemin, mais en sens opposés. Le routeur tunnelier est un nœud qui, comme tous les routeurs, possède au moins 2 interfaces, une sur le réseau IPv4 et une sur le réseau IPv6. Cela peut être deux interfaces physiques distinctes, ou deux interfaces virtuelles sur la même interface physique. 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.

La particularité d'un tunnelier est qu'il dispose en plus d'une interface logique interne, extrémité du tunnel sur laquelle s'opère l'encapsulation / décapsulation des paquets IPv6 dans le champ "données" des paquets IPv4. Cette interface dispose d'une adresse IPv4 et d'une adresse IPv6 (GUA, ULA, ou d'une adresse, à préfixe nul "IPv4 compatible" ou "IPv4 mapped" étant donné qu'il s'agit d'une interface logique interne au routeur). Cette adresse IP sera l'adresse de « prochain saut » pour les routes vers les préfixes IPv6 à atteindre à l'autre extrémité du tunnel. Cela peut également être la route par défaut s'il s'agit d'un tunnel reliant un îlot IPv6 à l'Internet v6.

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'ils 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.

Figure 4 : Cas d'un tunnel configuré.

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, les commandes de configuration à appliquer pour l'hôte sont celles indiquées ci-dessous. La première commande crée l'interface du tunnel nommée 6in4 et y associe les adresses des extrémités du tunnel. Ces adresses sont l'adresse "source" et l'adresse "destination"du paquet IPv4,qui encapsulera le paquet IPv6. Ensuite l'interface du tunnel est activée. Enfin il ne reste plus qu'à configurer l'interface réseau du tunnel comme toutes les interfaces réseau d'un hôte à savoir:

• attribuer une adresse IPv6 et indiquer le préfixe réseau du lien (ici le tunnel),
• indiquer la route par défaut passant par le routeur local.

ip tunnel add 6in4 mode sit remote 192.0.3.1 local 192.0.2.1
ip link set dev 6in4 up

ip -6 addr add 2001:db8:caf:1::2/64 dev 6in4
ip -6 route  add ::/0  via 2001:db8:caf:1::1 dev 6in4

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.

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 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 œuvre 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 5.

Figure 5 : 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 6 ; à 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 nœuds d'un réseau IPv6 isolé avec des nœuds de l'Internet v6.

Figure 6 : 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 nœud 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 services 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 tunnels, pour certains utilisateurs, la longueur des tunnels reste un problème.

Tunnel automatique

Un tunnel configuré demande un travail de configuration pour chaque tunnel, ce qui peut être vu comme un inconvénient. Avec l'automatisation, l'intervention de l'administrateur est réduite à une phase de "configuration/initialisation" du service, à la place de celle de configuration des tunnels. Ainsi, 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 de destination. Ce principe d'embarquer l'adresse du tunnelier dans l'adresse IPv6 au niveau du préfixe est présenté par le RFC 3056 et connu sous le nom de 6to4. La figure 7 montre le cas d'application du tunnel automatique selon le principe 6to4. Il s'agit de relier un réseau IPv6 qui n'a pas de lien en IPv6 à l'Internet IPv6. La connectivité va être effectuée au moyen d'un tunnel automatique à l'aide d'un réseau IPv4 auquel le réseau IPv6 est relié via un routeur en double pile. Ce routeur se situe en bordure des réseaux IPv4 et IPv6. On appellera un tel routeur, tunnelier (Tunnel end point).

Figure 7 : Cas d'application d'un tunnel automatique.

Comme pour 6in4, l'encapsulation des paquets IPv6 avec un tunnel automatique s'effectue dans les paquets IPv4. Par contre, au niveau de l'adressage, avec les tunnels automatiques, il faut définir un préfixe IPv6 spécifique qui indique qu'une adresse IPv4 est embarquée. La figure 8 illustre le mécanisme de construction d'un préfixe. Comme indiqué précédemment, le tunnelier se trouve en bordure du réseau. Il est connecté à la fois à l'Internet v4 et à un réseau IPv6. C'est un nœud en double pile ; il possède obligatoirement une adresse IPv4 "unicast globale", comme 192.0.2.1 dans l'exemple. Retenons, le préfixe spécifique 2002::/16. Le préfixe du réseau IPv6 va être composé en concaténant le préfixe spécifique et l'adresse IPv4 "unicast globale" du tunnelier de ce réseau IPv6. Le préfixe du réseau IPv6 embarquant l'adresse IPv4 aura une longueur de 48 bits dans notre exemple et aura la valeur 2002:c000:201::/48 (0xc0 = 192). Il a noter qu'il a la même longueur que la partie publique d'un préfixe IPv6 GUA.

Figure 8 : Construction d'un préfixe IPv6 à partir de l'adresse IPv4 du tunnelier.

Aussi comme le montre la figure 9, le préfixe de 48 bits laisse un champ SID de 16 bits pour numéroter des sous-réseaux ou liens dans le réseau IPv6. Il est alors possible d'attribuer des adresses au différents noeuds du réseau IPv6. Ils auront en comment d'avoir l'adresse IPv4 de leur tunnelier dans la partie préfixe de leur adresse.

Figure 9 : Format d'une adresse construite sur la base d'une connectivité par un tunnel.

La figure 10 présente l'envoi d'un paquet IPv6 de l'hôte A vers l'hôte B. 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:201: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, est acheminé vers un tunnelier de l'Internet v6. Lorsque le paquet est reçu par le tunnelier. 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 effectue alors la transmission du paquet IPv6 en l'encapsulant dans un paquet IPv4. C'est cette encapsulation qui forme le tunnel. Le tunnelier du coté de B désencapsule le paquet IPv6 et le route normalement vers sa destination finale B en utilisant le routage interne.

Figure 10 : Envoi d'un paquet IPv6 en passant par un tunnel automatique.

Le principe des tunnels automatique de type 6to4 est intéressant en théorie mas en pratique, il reste le problème des tunneliers du coté de l'Internet v6. En effet, à qui incombe la responsabilité d'installer ces tunneliers ? Une réponse a été le fournisseur d'accès Internet pour ses clients. C'est dans ce contexte que la technique 6rd a été proposée et que nous allons voir dans la section suivante.

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 en ciblant son application à un opérateur offrant une connectivité IPv6 et dont l'infrastructure repose sur IPv4. Cet opérateur peut être aussi bien public, comme un FAI, ou privé, comme une entreprise ou une administration.

L'idée de 6rd porte sur l'utilisation d'un préfixe IPv6 propre à l'opérateur. Sa mise en oeuvre oblige l'opérateur à avoir le contrôle des 2 extrémités du tunneI. Autrement dit, il appartient à l'opérateur d'installer le tunnelier donnant la connectivité à l'Internet v6. Il s'ensuit que les tunnels utilisés dans le contexte de 6rd sont de longueur limitées à la taille du réseau IPv4 de l'opérateur. Il sont de fait court et ne sont pas sensés traverser l'Internet. Les tunnels automatiques 6rd ne servent qu'à passer la section IPv4 de l'opérateur. Avec 6rd, on se retrouve dans le cas classique où les routeurs internes (dont les tunneliers) traitent le trafic produit et destiné aux hôtes connectés à l'opérateur. En fait, l'idée de 6rd est de limiter la technique des tunnels automatiques pour un usage interne et local.

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). L'infrastructure centrale est en IPv4 tandis que les réseaux de distribution offrent une connectivité en IPv6. L'interconnexion entre un réseau de distribution et l'infrastructure est faite à l'aide d'un routeur en "double pile", appelé "6rd CE" (Customer Edge). Chacun de ces routeurs possèdent une adresse IPv4 sur l'interface du réseau d'infrastructure notée par exemple a4 pour le réseau A. De manière similaire au principe utilisé dans 6to4, le préfixe du réseau de distribution IPv6 est constitué en embarquant l'adresse IPv4 dans le préfixe propre à cet opérateur noté "pref6rd". Le préfixe du réseau de distribution est noté dans la figure pour le réseau A pref6rd:a4::. La figure 12 montre que la connectivité en IPv6 peut être établie entre 2 hôtes du même opérateur ou servir à un hôte pour accéder à l'Internet v6 en passant par le routeur de bordure. Dans les deux cas, un tunnel automatique est établi pour passer l'infrastructure centrale fonctionnant en IPv4.

Figure 12 : Architecture de 6rd.

Le format de l’adresse IPv6 6rd dérive d'un préfixe 2000::/3 pris dans le plan d'adressage global unicast. Il utilise le préfixe propre alloué au FAI par son registre régional (RIR). Il devient difficile de différencier un trafic sortant d’un réseau 6rd d’un trafic IPv6 natif car les deux partagent le même préfixe. Le préfixe IPv6 du domaine de l'opérateur est complété par tout ou partie de l'adresse IPv4 alloué au 6rd CE", pour former le préfixe 6rd. Le "6rd CE" est l'extrémité du tunnel coté client (dans la figure 12) et connue comme la box fournie par le FAI. 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 la totalité des 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 (SID) 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 autrement dit n + i + s bits = 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:281 en hexadécimal) a été attribuée à l’interface du"6rd CE" du réseau de distribution A de la figure 12. L'opérateur dispose du préfixe 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. Les 24 bits de poids faible de l'adresse IPv4 suffisent, en effet, à distinguer chacun des "6rd CE" de son réseau. Les 8 bits du préfixe IPv4 (valeur décimale 192 dans notre exemple) peuvent être omis. Le préfixe IPv6 de chaque "6rd CE" aura donc une longueur de 56 bits, correspondant à l'addition du préfixe du domaine (32 bits) avec la partie significative de l'adresse IPv4 (24 bits). Dans le cas de l'exemple, la figure 14 illustre cet assemblage entre le préfixe de l'opérateur et l'adresse IPv4. Pour plus de lisibilité, la partie significative de l'adresse IPv4 a été laissée en notation décimale pointée sur la figure. En notation de l'adresse IPv6, le 6rd delegated prefix pour le "6rd CE" d'adresse 192.0.2.129 sera 2001:db8:2:8100::/56. Il restera alors 8 bits, au titre du SID (Subnet Identifier), pour la numérotation des sous-réseaux internes du réseau connecté par le "6rd CE". À l’extérieur de l'opérateur, les adresses IPv6 apparaîtront comme des adresses IPv6 natives. À l'intérieur de l'opérateur, les adresses seront interprétées pour établir un tunnel entre les routeurs de bordures de l'infrastructure IPv4 de l'opérateur.

Figure 14 : Exemple de construction d'un préfixe délégué 6rd.

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 à l'autre "6rd CE" 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 du "6rd CE". 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. Dans le cas du trafic retour, d'un flux initialisé par une machine 6rd, comme l'adresse de destination est issue du préfixe global de l'opérateur, la voie retour passera par le même relais. Ainsi, la communication s'effectuera en empruntant la même route à l'aller et au retour.

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. À 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, 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é "épisodiques") sont épargnées. 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 le principe de tunnel automatique de 6to4 est pertinent, sa mise en œuvre a été problématique. La dépréciation récente du préfixe anycast réservé à son usage entraîne, de fait, son déclin. La variante 6rd, en corrigeant les défauts de 6to4, se positionne comme une alternative.

6to4 et 6rd reposent tous deux sur l'encapsulation directe : 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 habituelle de connectivité d'IPv6 qui dit : « double-pile où tu peux, tunnel où tu dois » (Dual stack where you can; tunnel where you must). La double-pile (IPv4 et IPv6 sur tous les équipements) est la solution la plus simple pour la gestion du réseau. Le tunnel est plus fragile et fait dépendre IPv6 d'IPv4. Il sert dans les situations où des routeurs antédiluviens ne peuvent être mis à jour et être utilisé pour traiter des paquets IPv6.

Références bibliographiques

1. ↑ Cui Y., Dong J., Wu P., et al. (2012) IEEE Internet Computing. April. Tunnel-based IPv6 Transition.
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