MOOC:Compagnon Act42-s7

From Livre IPv6

Revision as of 05:22, 28 January 2022 by Panelli (Talk | contribs) (→‎Connectivité d'un site isolé : Tunnel Broker)

> 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, 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 de destination. Ce principe d'embarquer l'adresse du tunnelier dans l'adresse IPv6 peut se nommer 6to4 comme décrit par le RFC 3056. Lorsque les tunnels automatiques sont retenues, le tunnelier est un routeur. Ce type de tunnel est donc destiné à relier deux réseaux IPv6 lorsqu'il n'y a pas de connectivité directe possible en IPv6 comme le montre la figure 5. Avec l'automatisation, l'intervention de l'administrateur est réduite à une phase de "configuration/initialisation" du service, et non à une phase de configuration des tunnels.

File:43-fig5-2.png
Figure 5 : Tunnel automatique.

Comme pour 6in4, l'encapsulation des paquets IPv6 s'effectue directement dans les paquets IPv4. Avec les tunnels automatiques, il faut définir un préfixe spécifique qui indique qu'une adresse IPv4 est embarqué. Par exemple, prenons le préfixe 2002::/16 pour embarquer une adresse IPv4. Le préfixe de l'adresse IPv6 d'un tunnelier est composé automatiquement en concaténant le préfixe spécifique et l'adresse IPV4 "unicast globale" de ce tunnelier, comme montré par la figure 6. Ainsi, un préfixe IPv6 de longueur 48 bits est construit en utilisant l'adresse IPv4 du nœud en bordure des réseaux IPv4 et IPv6. Ce préfixe laisse 16 bits pour numéroter des sous-réseaux ou liens dans le réseau IPv6.

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 nœud 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 nœuds 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ésencapsule 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 (selon le principe du routage anycast) 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'Internet v6 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é[3]. 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. Le principe de 6to4 a évolué pour être adapté pour un FAI et cette nouvelle technique de tunnel est connue sous le nom de 6rd .


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". 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 nœuds internes. Ainsi, ces relais ne servent que les 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.

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[4]. 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[5] 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. ↑ Huston, G.(2010). The ISP Column. Flailing IPv6
  4. ↑ Cisco. (2011). White paper. IPv6 Rapid Deployment: Provide IPv6 Access to Customers over an IPv4-Only Network
  5. ↑ Huston, G. (2011). The ISP Column. Testing Teredo

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer :

Retrieved from "http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act42-s7&oldid=19739"
Personal tools