Difference between revisions of "MOOC:Compagnon Act42-s7"

From Livre IPv6

(Connectivité d'un sité isolé)
(Pour aller plus loin)
 
(282 intermediate revisions by 5 users not shown)
Line 1: Line 1:
> [[MOOC:Accueil|MOOC]]>[[MOOC:Contenu|Contenu]]>[[MOOC:Semaine_4|Séquence 4]] > [[MOOC:Activité_43|Activité 43]]
+
<!--
 +
> [[MOOC:Accueil|MOOC]]>[[MOOC:Contenu|Contenu]]>[[MOOC:Document_Compagnon |Doc compagnon]] > [[MOOC:Compagnon_Act42-s7 |Activité 42]]
 +
 
 
----
 
----
 +
-->
 +
__NOTOC__
  
 
<!-- ----------------------------------------- -->
 
<!-- ----------------------------------------- -->
== <div id="connectivité">III/ Etablir la connectivité IPv6 </div> ==
+
= <div id="connectivité">Activité 42 : Établir la connectivité en IPv6 </div> =
 
<!-- ----------------------------------------- -->
 
<!-- ----------------------------------------- -->
 +
<!-- {{Approfondissement}} -->
 +
==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<ref>Cui Y., Dong J., Wu P., et al. (2012) IEEE Internet Computing. April. Tunnel-based IPv6 Transition.</ref>.
  
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 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 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.
  
Les tunnels peuvent s'utiliser aussi bien pour  la connectivité d'un site IPv6 avec l'Internet v6 (si le FAI n'offre pas cette connectivité) que pour l'intérieur d'un site en IPv4 si celui-ci comporte des parties en IPv6 non connexes. Dans ce  dernier cas, l'interconnexion des ilots IPv6 peut nécessité beaucoup de tunnels. Nous verrons dans la suite de ce document les solutions pour assurer une connectivité IPv6 dans ces 2 types de situation.
+
== 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 <tt>données</tt> du paquet IPv4. Le champ <tt>protocol</tt> de l'en-tête du paquet IPv4 prend la valeur 41 (en décimal) pour indiquer qu'il encapsule un paquet 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.
  
=== Rappel de la technique du tunnel===
+
<center>
 
+
[[Image:43-fig1-hd.png|300px|thumb|center|Figure 1 : Encapsulation pour un tunnel.]]
Le tunnel est un mécanisme bien connu dans le domaine des réseaux qui consiste à faire qu’une unite de transfert d'un protocole d'une couche se trouve encapsulé dans la charge utile de l'unité de transfert 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 champ protocol de l'en-tête IPv4 prend alors la valeur 41 pour indiquer IPv6. Les extrémités du tunnel peuvent être soient des hôtes ou soient des routeurs. Les extrémités du tunnel appelés des tunneliers peuvent configurées manuellement ou automatiquement. La modalité de la configuration indique en fait le mode d'apprentissage de l'adresse IPv4 du tunnelier désencapsuleur.
+
</center>
 
+
[[Image:43fig1.png|300px]]<br>
+
Figure 1: Encapsulation pour un tunnel
+
 
   
 
   
Le notion de tunnel équivaut alors à un câble virtuel permettant d’assurer une liaison point à point entre deux nœuds IPv6 ou encore des ilôts IPv6 et fournir ainsi une connectivité de base  comme l’illustre la figure 2.
+
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.  
  
[[Image:43fig2.png|300px]]<br>
+
<center>
Figure 2: Tunnel entre ilôts IPv6
+
[[Image:43-fig2-2-hd.png|400px|thumb|center|Figure 2 : Tunnel entre des réseaux IPv6.]]
 +
</center>
  
=== Connectivité d'un sité isolé ===
+
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.
  
L'accès à d'un ilot  IPv6 à l'Internetv6  s'effectue  à l'aide d'un tunnel que celui-ci soit configuré manuellement ou soit que ses paramètres de configuration  sont obtenus par un protocole.  
+
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.
  
  
 +
<center>
 +
[[Image:43-fig3-2.png|200px|thumb|center|Figure 3 : Architecture d'un routeur tunnelier.]]
 +
</center>
  
====Tunnels Manuel====
+
La différence avec un lien réel porte sur la taille de la MTU. En raison de l'encapsulation dans IPv4, un tunnel se caractérise par une  MTU diminuée d'une vingtaine d'octets. Ainsi, la taille du paquet IPv6  se verra limitée par rapport à la MTU du lien réel. Par exemple, si la MTU du support est de 2000 octets, alors le paquet IPv4 pourra avoir une taille maximale de 2000 octets. Si le paquet doit emprunter un tunnel sur ce réseau, du fait d'une taille minimale de 20 octets pour l'en-tête IPv4, la MTU utilisable par le paquet IPv6 sera de 1980 octets comme l'illustre la figure 1.
 +
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.
  
Un tunnel statique nécessite une configuration manuelle des extrémités du tunnel. Dans un tunnel statique, les adresses IPv4 des extrémités du tunnel ne sont pas codées dans la source ou la destination des adresses IPv6 , ni dans l'adresse de saut suivant l' itinéraire correspondant . Typiquement, les configurations de tunnel routeur à routeur et l'hôte à routeur sont configurés manuellement. La configuration de l'interface de tunnel, comprenant les adresses IPv4 des extrémités du tunnel, doit être spécifiée manuellement avec des routes statiques qui utilisent l'interface de tunnel.
+
== Tunnel configuré ==
  
[[Image:43fig3.png|300px]]<br>
+
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 3:
+
  
 +
<center>
 +
[[Image:42-fig4-2.png|300px|thumb|center|Figure 4 : Cas d'un tunnel configuré.]]
 +
</center>
  
Exemple :
+
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:
  auto 6in4
+
* attribuer une adresse IPv6 et indiquer le préfixe réseau du lien (ici le tunnel),
  iface 6in4 inet6 v4tunnel
+
* indiquer la route par défaut passant par le routeur local.
endpoint 192.0.3.1
+
 
address 3FFE:B00 :1 ::1
+
  ip tunnel add 6in4 mode sit remote 192.0.3.1 local 192.0.2.1
  netmask 64
+
  ip link set dev 6in4 up
gateway 3FFE:B00 :1 ::2
+
 
   
 
   
  up route -A inet6 add ::/0 dev 6in4
+
  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.
 +
<center>
 +
[[image: 42-fig5-2.png |250px|thumb|center|Figure 5 : Modèle du ''Tunnel Broker''.]]
 +
</center>
 +
 
 +
La création d'un tunnel à l'aide d'un ''Tunnel Broker'' fonctionne de la manière indiquée par la figure 6 ; à savoir :
 +
# 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é.
 +
# Le ''Tunnel Broker'' configure le serveur de tunnel retenu.
 +
# Le ''Tunnel Broker'' envoie le script de configuration à la machine "double pile" coté utilisateur.
 +
# 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.
  
====Tunnels automatqiue ====
+
<center>
 +
[[image:42-fig6-2.png |350px|thumb|center|Figure 6 : Configuration d'un  ''Tunnel Broker'' avec TSP.]]
 +
</center>
  
Un tunnel automatique ne nécessite pas de configuration manuelle. Les extrémités du tunnel sont déterminées par l'utilisation d'interfaces logiques de tunnels , les routes et la source et les adresses IPv6 de destination . Comme défini dans la RFC 2893 , IPv6 automatique Tunneling est le tunnel qui se produit lorsque les adresses compatibles IPv4 ( :: wxyz où wxyz est une adresse IPv4 publique ) sont utilisés .
+
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 :
IPv6 automatique Tunneling est un tunnel hôte à hôte entre deux hôtes IPv6 / IPv4 en utilisant des adresses compatibles IPv4 . Par exemple , l'hôte A (avec l'adresse IPv4 publique de 157.60.91.123 et adresse compatible IPv4 correspondante :: 157.60.91.123 ) envoie le trafic à l'hôte B ( avec l'adresse IPv4 de 131.107.210.49 et compatibles IPv4 adresse du correspondant : : 131.107.210.49 ) . Les adresses dans les en-têtes IPv6 et IPv4 sont énumérées dans le tableau ci dessous.
+
* 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.
  
IPv6 Source Address ::199.194.100.111
+
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 :
IPv6 Destination Address ::192.122.210.23
+
IPv4 Source Address 199.194.100.111
+
IPv4 Destination Address 131.122.210.23
+
  
TSP (''tunnel setup protocol'')
+
-- 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
  
Les tunnels broker représentent une méthode pour connecter un ilot IPv6 à l’Internet IPv6 même lorsque les réseaux sur le trajet sont purement IPv4.
+
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.
Le principe du tunnel broker est le suivant : un routeur IPv6 du réseau local négocie avec un serveur de tunnels qui indique le préfixe délégué et d'autres caractéristiques du tunnel. Ledit routeur va ensuite encapsuler ses paquets IPv6 dans de l'IPv4 à destination dudit serveur de tunnels, qui sert également de routeur.
+
Afin de promouvoir le passage à IPv6, les ''Tunnel Brokers'' sont souvent gratuits<ref>Linux Review.  [http://en.linuxreviews.org/Free_IPv4_to_IPv6_Tunnel_Brokers Free IPv4 to IPv6 Tunnel Brokers]</ref>. 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.
Le protocole de négociation des paramètres du tunnel est le protocole TSP (Tunnel Setup Protocol)
+
Le protocole de négociation de TSP effectue les paramètres suivants: 
+
* L'authentification de l'utilisateur en utilisant l' authentification SASL protocole ( RFC 4422 ) les caractéristiques du Tunnel:  
+
** Tunnels IPv6 sur IPv4 ( RFC 4213 )
+
** IPv4 sur IPv6 Tunnels ( RFC 2473 )
+
** Tunnels IPv6 sur UDP / IPv4 pour la traversée du NAT
+
* L’attribution d'adresse IP pour les deux extrémités du tunnel
+
* Le Domain Name System ( DNS ) l'enregistrement des adresses de point d'extrémité et le DNS inverse
+
* Le mécanisme de keep-alive du Tunnel au besoin
+
* L’assignation des adresses IPv6 au routeur
+
* La mise en œuvre des protocoles de routage
+
  
===Connectivité sur une infrastructure IPv4===
+
== Tunnel automatique ==
  
<!-- le principe du 6to4 et sa mise en oeuvre 6rd -->
+
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''). 
  
====6to4====
+
<center>
 +
[[Image:43-fig7-3.png|300px|thumb|center|Figure 7 : Cas d'application d'un tunnel automatique.]]
 +
</center>
  
  
Le tunnel 6to4 est un mécanisme de transition IPv6 décrit dans le RFC 3056. Comme les autres mécanismes de transition présentés dans cette partie, il s’appuie aussi sur l'encapsulation des paquets IPv6 dans IPv4 pour le transport à travers un réseau IPv4 . 6to4 permet la traduction automatique des adresses IPv6 vers des adresses IPv4, et traite l’architecture et le réseau IPv4 sous-jacent comme une architecture NBMA (''Non Boradcast Multiple Access'') plutôt que d'une collection de liens indépendants de point à point .
+
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 <tt>192.0.2.1</tt> dans l'exemple. Retenons le préfixe spécifique '''<tt>2002::/16</tt>'''. 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
 +
<tt>2002:c000:201::/48</tt> (0xc0 = 192). Il est à noter qu'il a la même longueur que la partie publique d'un préfixe IPv6 GUA.  
  
6to4 profite d'un préfixe IPv6 réservé 2002 :: / 16 . Une interface tunnel 6to4 convertit automatiquement les 32 bits dans son adresse IPv6 suivant ce préfixe à une adresse IPv4 unicast globale pour le transport à travers un réseau IPv4 tels que l'Internet public .  
+
<center>
 +
[[image:43-fig8-2-hd.png|300px|thumb|center|Figure 8 : Construction d'un préfixe IPv6 à partir de l'adresse IPv4 du tunnelier.]]
 +
</center>
  
[[Image:43fig4.png|300px]]<br>
+
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 nœuds du réseau IPv6. Ils auront en commun d'avoir l'adresse IPv4 de leur tunnelier dans la partie préfixe de leur adresse.
Figure 4:
+
  
 +
<center>
 +
[[image:43-fig6-hd.png|400px|thumb|center|Figure 9 : Format d'une adresse construite sur la base d'une connectivité par un tunnel.]]
 +
</center>
  
Tout paquet IPv6 dont l'adresse de destination commence par 2002: doit passer par le tunnel 6to4. Dans ce cas, les bits 16 à 47 de l'adresse IPv6 destination déterminent à quelle adresse IPv4 le paquet doit être remis. Cette adresse est celle d'un routeur 6to4. <br>
 
  
Par exemple, si la destination d'un paquet IPv6 est2002:8ac3:802d:1242:20d:60ff:fe38:6d16, , le paquet sera transmis par IPv4 au routeur 6to4 dont l'adresse IP est 138.195.128.45 (0x8a = 138, 0xc3 = 195, 0x80 = 128, 0x2d = 45). C'est ensuite au routeur 6to4 de transmettre le paquet IPv6 à sa destination finale.<br>
 
  
Avec cette technique, si un fournisseur d'accès à Internet vous attribue une adresse IPv4, vous disposez automatiquement d'un jeu de 2^80 adresses IPv6 que vous pouvez librement utiliser : toutes les adresses IPv6 commençant par 2002:8ac3:802d: dans notre exemple. C'est amplement suffisant pour que toutes les machines de votre réseau local obtiennent leur propre adresse IPv6. <br>
+
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 <tt>2002:c000:201:1::8051</tt>. 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 <tt>2002::/16</tt>, 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 (<tt>192.0.2.1</tt> 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.
  
Pour que les utilisateurs d'adresses IPv6 commençant par 2002: puissent communiquer avec les autres, des relais entre le monde 6to4 et l'Internet-IPv6 ont été mis-en-place sur Internet. Par une astuce ingénieuse, l'adresse du relais le plus proche est toujours 192.99.88.1 en IPv4. <br>
+
<center>
 +
[[image:43-fig10-3-hd.png|400px|thumb|center|Figure 10 : Envoi d'un paquet IPv6 en passant par un tunnel automatique.]]
 +
</center>
  
Ainsi, si vous utilisez 6to4 pour vous connecter à Internet, et que vous souhaitez contacter une machine n'utilisant pas 6to4, par exemple, 2001:200:0:8002:203:47ff:fea5:3085, vous pouvez transmettre les paquets par le tunnel 6to4 au relais le plus proche.
+
Le principe  des tunnels automatique de type ''6to4'' est intéressant en théorie mais 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.
  
[[Image:43fig5.png|300px]]<br>
 
Figure 5:
 
  
 +
=== Connectivité sur une infrastructure IPv4 : ''6rd'' ===
  
  
====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.
  
6rd signifie "IPv6 Rapid Deployment".
+
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 lui appartient d'installer un routeur de bordure connecté à 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.
Ce mécanisme d’encapsulation se fonde sur 6to4. La différence se situe sur le fait que 6rd utilise directement le préfixe IPv6 d’un fournisseur d’accès plutôt que le préfixe 2002 ::/16 employé par 6to4. De plus 6rd permet au fournisseur de restreindre les utilisateurs à utiliser les routeurs qui sont contrôlés par le FAI comme relais, par opposition à ceux choisis au hasard dans 6to4. Cela répond à certaines des questions de fiabilité et de sécurité ainsi qu’aux problèmes de délais et de déconnexion dus au routage asymétrique de 6to4.
+
En fait, l'idée de ''6rd'' est de limiter la technique des tunnels automatiques pour un usage interne et local.  
  
En effet, 6to4 ne permet pas de contacter directement une adresse IPv6 qui ne débute pas par 2002::/16 et nécessite le passage par un routeur relais. Ces relais sont joignables par l’adresse IPv4 anycast 6to4 (192.88.99.1) pour atteindre le routeur relais 6to4 le plus proche et ainsi rediriger le trafic vers l’Internet IPv6.
+
Dans la figure 11, qui schématise l'architecture de ''6rd'', le routeur de bordure est noté, selon la terminologie du RFC 5969, "''6rd'' BR"(''Border Relays''). Ce routeur est  un tunnelier  connecté en IPv4 du coté du l'infrastructure de communication de l'opérateur et connecté en IPv6 du coté de l'internet v6. Le réseau local IPv6 du coté de l'abonné est connecté à l'infrastructure de communication de l'opérateur à l'aide d'un tunnelier. Ce dernier appelé "''6rd'' CE" (''Customer Edge''), est également un routeur en "double pile". Concrètement, on le trouve sous la forme de la "box" dans l'installation des abonnés de l'opérateur. Chacun  de ces tunneliers possèdent  une adresse IPv4 sur l'interface réseau de l'infrastructure notée par exemple a4 pour le réseau local A.  De manière similaire au principe utilisé dans ''6to4'', le préfixe IPv6 du réseau local est constitué en embarquant l'adresse IPv4 dans le préfixe IPv6 propre à cet opérateur noté <tt>pref6rd</tt>.  Le préfixe IPv6 du réseau local est noté dans la figure 11 pour le réseau A <tt>pref6rd:a4::</tt>.  
Pour le chemin retour, la route 2002::/16 sera annoncée dans le domaine de routage extérieur IPv6 natif. Les sites IPv6 qui utilisent encore l’adresse anycast dépendront donc de la disponibilité des routeurs relais 6to4, lesquels vont encapsuler tout le trafic IPv6 du préfixe 2002::/16 et le rediriger sur l’Internet IPv4. Le routage pouvant être asymétrique entre la redirection et le chemin retour, il n’est pas certain qu’un noeud IPv6 natif trouve une route en retour pour acheminer le paquet vers le noeud 6to4 créant ainsi des déconnexions
+
La figure 12 montre que la connectivité en IPv6 peut être établie entre 2 hôtes par un tunnel entre 2 ''box'' ou  entre une box et le routeur de bordure afin qu'un hôte puisse accéder à l'internet v6.  Dans les deux cas, un tunnel automatique est établi pour passer l'infrastructure de communication centrale fonctionnant en IPv4.
  
 +
<center>
 +
[[Image:43-fig12a-hd.png|350px|thumb|center|Figure 11 : Architecture de ''6rd''.]]
 +
</center>
  
Pour palier à cela 6rd prévoit donc que tous les paquets en provenance de l’Internet IPv6 arrivent obligatoirement sur les routeurs relais (routeurs de bordure) de l’opérateur et uniquement à destination des sites de leurs clients. Tous les paquets IPv6 qui ne proviennent pas de l’Internet IPv6 et à destination des sites des clients 6rd traversent uniquement les passerelles de l’opérateur.
+
Le format de l’adresse IPv6 ''6rd'' dérive d'un préfixe <tt>2000::/3</tt> pris dans le plan d'adressage global unicast (''GUA''). 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 11) 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
 +
<center>
 +
[[Image:43-fig13-hd.png|400px|thumb|center|Figure 12 : Format d'une adresse ''6rd''.]]
 +
</center>
  
Le format de l’adresse IPv6 utilise un préfixe 2000::/3 (au lieu du 2002::/16 propre à 6to4). Il devient alors difficile de différencier un trafic sortant d’un réseau 6rd d’un trafic IPv6 natif. Chaque préfixe va correspondre à un domaine 6rd ou encore à un préfixe par FAI. Ce domaine est composé de l’ensemble des routeurs relais et des routeurs de bordure sur un même lien virtuel 6rd. Chaque fournisseur peut utiliser un ou domaines 6rd.
+
Pour illustrer la figure 12, considérons tout d’abord que l’adresse IPv4 <tt>192.0.2.129</tt> (c000:281 en hexadécimal) a été attribuée à l’interface du"''6rd'' CE" du réseau local A de la figure 11. L'opérateur dispose du préfixe IPv6 <tt>2001:db8::/32</tt> pour son domaine ''6rd''. Les adresses de tous les "''6rd'' CE" s'agrègent sur le préfixe <tt>192.0.0.0/8</tt>. 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 13 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  <tt>192.0.2.129</tt> sera <tt>2001:db8:2:8100::/56</tt>. 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.
  
[[Image:43fig6.png|200px]]<br>
+
<center>
Figure 6:.
+
[[Image:43-fig14-hd.png|400px|thumb|center|Figure 13 : Exemple de construction d'un préfixe délégué ''6rd''.]]
 +
</center>
  
  
Comme 6to4, les tunnels sont créés automatiquement. Le client du FAI a une adresse IPv4 externe. Cette adresse est celle attribuée à l'interface WAN du 6rdCE. Normalement, c’est une adresse IPv4 publique, mais ce n’est pas obligatoire avec 6rd.
+
Le transfert avec la technique ''6rd'' s'organise selon 3 cas :
L’organisation de l’adresse IPv6 est décrite par la figure 7.
+
  
[[Image:43fig7.png|200px]]<br>
+
* transfert inter-réseau IPv6 local. 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 réseau local pour son acheminement à la destination IPv6 ;
Figure 7: Format d'une adresse 6-RD
+
* transfert du réseau local IPv6 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<ref>Cisco.  (2011). White paper. [http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/whitepaper_c11-665758.html IPv6 Rapid Deployment: Provide IPv6 Access to Customers over an IPv4-Only Network]</ref>. Cette technique de tunnel répond à des questions de fiabilité et de délai. Comme le relais avec l'internet v6 est administré par, et pour, l'opérateur lui-même, le service de connectivité peut être de bonne qualité. En cas de défaillance, la responsabilité de l'opérateur est directement engagée.
  
'''Dans le cas d’une adresse IPv4 publique'''
+
==  Conclusion==
Pour illustrer cette figure considérons tout d’abord que l’adresse IPv4 145.253.100.48 ((0x91fd6430 en hexadécimal) a été attribuée à l’interface WAN du 6rdCE et que le FAI a un bloc /28 d’adresses l'IPv6 pour ce domaine 6rd, qui est 2A00:380::/28.
+
  
Concaténé au préfixe 6rd /28 du FAI, ce sont 16 blocs d’adresses de longueur /64 (2a00:389:1fd6:4300::/60) qui seront “routés” vers le site du client. Le client contrôle les 4 bits restant du préfixe IPv6 pour ses sous-réseaux. A l’intérieur de chaque sous-réseau, les 64 bits restants seront attribués à l’identifiant EUI 64 de l’interface. Le 6rdCE du client annonce par un RA (Router Advertisement), un des /64 pour chaque sous-réseau. 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 du FAI et l’interface WAN du 6rdCE.
+
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é.
  
'''Sans adresse IPv4 publique'''
+
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.
Considérons qu’un FAI n'a plus assez d'adresses IPv4 publiques pour donner à chaque client une seule adresse publique. Le FAI peut utiliser CGN pour fournir à chaque client une adresse dans l’espace 100.64/10 (cela consiste de toutes les adresses de 100.64.0.1 à 100.255.255.254). Cette plage d’adresse a été réservée pour s’affranchir des adresses privées (RFC1918) utilisées par les clients. Il est donc prudent de ne pas l'utilisez dans réseau client.  
+
Si le FAI utilise l'ensemble du bloc d’adresses 100.64/10, il y a 22 « bits d'adresse uniques» pour les adresses WAN des clients. Si le FAI attribue un /60 à chaque client il convient d’ajouter les 4 bits complémentaires (64-60) aux 22 bits d’adresse unique, ce qui correspond à 26 bits uniques à chaque client. Le FAI aurait alors besoin d'un préfixe /38 (64-28) pour ce domaine 6rd. Si le FAI alloue un / 56 à chaque client (8 bits au lieu de 4), il ya 22 + 8 = 30 bits d’adresse uniques à chaque client. Le FAI aurait alors besoin d'un préfixe /34 pour le domaine 6rd.
+
  
Le bloc 100.64/10 contient 4194302 adresses utilisables. Si le FAI dispose de 10 millions de clients. Il aurait besoin de trois domaines 6rd, et un CGN pour chacun. Chaque domaine 6rd exigerait un / 38 bloc séparé de IPv6 (fournissant 16 sous-réseaux par client) ou un bloc / 34 de l'IPv6 (fournissant 256 sous-réseaux par client).
+
''6rd'' repose 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<ref>Huston, G. (2011).  The ISP Column. [http://www.potaroo.net/ispcol/2011-04/teredo.html Testing Teredo]</ref> des performances et une fiabilité du service de connectivité de très mauvaise qualité. Cette solution comme  ''6to4'' ont négligé la mise en oeuvre opérationnelle et ne sont plus utilisées de nos jours.
  
Le transfert avec la technologie 6rd s'organise selon 3 cas :
+
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 pour traiter des paquets IPv6. Le tunnel est solution d'attente avant le remplacement par un équipement moderne.
  
* Client à Client: Le trafic IPv6 arrive en mode natif sur une interface LAN du 6rdCE. Si l’adresse IPv6 de destination est incluse dans le préfixe du domaine 6rd configuré localement il sera transmis directement à un autre routeur CE 6rd.<br>On extrait alors les adresses IPv4 des interfaces WAN des 6rdCE pour monter le tunnel.  Le paquet IPv4, encapsulant le paquet IPv6, champ type de protocole est réglé sur 41 (IPv6 dans IPv4) est transmis au routeur 6rdCE de destination à travers le domaine IPv4 grâce au routage IPv4.<br> Le routeur 6rdCE de destination reçoit le paquet IPv4 encapsulant, et l'en-tête IPv4 est retiré. Par mesure de sécurité, l'adresse source d'en-tête IPv4 est comparée à l'adresse IPv4 intégrée dans l'adresse IPv6 source. Le paquet est éliminé si il n'y a pas de correspondance sinon, le paquet IPv6 est transmis comme un paquet IPv6 natif à l'adresse de destination IPv6 sur le réseau local du client.
+
==Références bibliographiques==
* Client à l'Internet IPv6 : Dans cette situation, le trafic IPv6 est reçue en mode natif sur le 6rdCE. L'adresse de destination IPv6 ne tombe pas dans la gamme du préfixe 6rd configurée localement, ce qui signifie qu'il ne vise pas à une destination à l'intérieur du domaine 6rd locale. Dans ce cas, le paquet doit être transmis à un routeur de bordure 6rd.<br> Comme dans le scénario Client à CLient, le paquet IPv6 est encapsulé dans un paquet IPv4, Cependant, la différence est que l'adresse IPv4 du routeur de bordure (configurée localement dans le 6rdCE) est utilisée comme adresse de destination IPv4. En outre, la source de tunnel correspond à l’adresse IPv4 de l’interface Wan du 6rdCE. Le champ de protocole est réglé sur 41 (IPv6 dans IPv4) et le paquet encapsulé est ensuite transmis au routeur BR à travers le domaine IPv4.<br> Le routeur de bordure reçoit le paquet IPv4 et supprime l'encapsulation IPv4. L'adresse de source d'en-tête IPv4 est comparée à l'adresse IPv4 intégrée dans l'adresse IPv6 source. Le paquet est supprimé si les adresses ne correspondent pas. Sinon, le paquet IPv6 est transmis nativement à l'adresse de destination IPv6.
+
<references />
* Internet IPv6 au CE: Si un routeur de bordure reçoit un paquet IPv6 natif à destination d’une adresse incluse dans le prefixe 6rd du domaine il transmet le paquet au routeur 6rdCE correspondant en utlisant le même principe que précédemment.
+
  
=== Conclusion===
+
== Pour aller plus loin ==
  
6rd est adaptée à une mise en œuvre simplifiée d’IPv6 pour des FAI
+
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 4213 Basic IPv6 Transition Mechanisms [http://www.bortzmeyer.org/4213.html Analyse]
 +
* RFC 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
 +
* RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [http://www.bortzmeyer.org/5569.html Analyse]
 +
* RFC 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) [http://www.bortzmeyer.org/5572.html Analyse]
 +
* RFC 5969  IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification [http://www.bortzmeyer.org/5969.html Analyse]
 +
* RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment  [http://www.bortzmeyer.org/6180.html Analyse]
 +
* RFC 6343 Advisory Guidelines for 6to4 Deployment
 +
* RFC 6782 Wireline Incremental IPv6 [http://www.bortzmeyer.org/6782.html Analyse]
 +
* RFC 7059 A Comparison of IPv6 over IPv4 Tunnel Mechanisms [http://www.bortzmeyer.org/7059.html Analyse]
 +
* RFC 7381 Enterprise IPv6 Deployment Guidelines  [http://www.bortzmeyer.org/7381.html Analyse]
 +
* RFC 7526 Deprecating Anycast Prefix for 6to4 Relay Routers [http://www.bortzmeyer.org/7526.html Analyse]

Latest revision as of 10:56, 21 January 2024


Activité 42 : Établir la connectivité en 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 du paquet IPv4 prend la valeur 41 (en décimal) pour indiquer qu'il encapsule un paquet 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 lien réel porte sur la taille de la MTU. En raison de l'encapsulation dans IPv4, un tunnel se caractérise par une MTU diminuée d'une vingtaine d'octets. Ainsi, la taille du paquet IPv6 se verra limitée par rapport à la MTU du lien réel. Par exemple, si la MTU du support est de 2000 octets, alors le paquet IPv4 pourra avoir une taille maximale de 2000 octets. Si le paquet doit emprunter un tunnel sur ce réseau, du fait d'une taille minimale de 20 octets pour l'en-tête IPv4, la MTU utilisable par le paquet IPv6 sera de 1980 octets comme l'illustre la figure 1. 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 est à 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 nœuds du réseau IPv6. Ils auront en commun 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.2.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 mais 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 lui appartient d'installer un routeur de bordure connecté à 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 11, qui schématise l'architecture de 6rd, le routeur de bordure est noté, selon la terminologie du RFC 5969, "6rd BR"(Border Relays). Ce routeur est un tunnelier connecté en IPv4 du coté du l'infrastructure de communication de l'opérateur et connecté en IPv6 du coté de l'internet v6. Le réseau local IPv6 du coté de l'abonné est connecté à l'infrastructure de communication de l'opérateur à l'aide d'un tunnelier. Ce dernier appelé "6rd CE" (Customer Edge), est également un routeur en "double pile". Concrètement, on le trouve sous la forme de la "box" dans l'installation des abonnés de l'opérateur. Chacun de ces tunneliers possèdent une adresse IPv4 sur l'interface réseau de l'infrastructure notée par exemple a4 pour le réseau local A. De manière similaire au principe utilisé dans 6to4, le préfixe IPv6 du réseau local est constitué en embarquant l'adresse IPv4 dans le préfixe IPv6 propre à cet opérateur noté pref6rd. Le préfixe IPv6 du réseau local est noté dans la figure 11 pour le réseau A pref6rd:a4::. La figure 12 montre que la connectivité en IPv6 peut être établie entre 2 hôtes par un tunnel entre 2 box ou entre une box et le routeur de bordure afin qu'un hôte puisse accéder à l'internet v6. Dans les deux cas, un tunnel automatique est établi pour passer l'infrastructure de communication centrale fonctionnant en IPv4.

Figure 11 : 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 (GUA). 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 11) 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 12 : Format d'une adresse 6rd.

Pour illustrer la figure 12, 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 local A de la figure 11. 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 13 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 13 : Exemple de construction d'un préfixe délégué 6rd.


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

  • transfert inter-réseau IPv6 local. 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 réseau local pour son acheminement à la destination IPv6 ;
  • transfert du réseau local IPv6 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. Comme le relais avec l'internet v6 est administré par, et pour, l'opérateur lui-même, le service de connectivité peut être de bonne 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.

6rd repose 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é de très mauvaise qualité. Cette solution comme 6to4 ont négligé la mise en oeuvre opérationnelle et ne sont plus utilisées de nos jours.

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 pour traiter des paquets IPv6. Le tunnel est solution d'attente avant le remplacement par un équipement moderne.

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 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) -- Protocol Specification 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
Personal tools