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

From Livre IPv6

(New page: =<div id="DeployerIPv6">Activer IPV6 dans son infrastructure </div>= <!-- ----------------------------------------- --> Successfully Deploying IPv6 https://www.nanog.org/sites/default/fi...)
 
(Pour aller plus loin)
 
(303 intermediate revisions by 5 users not shown)
Line 1: Line 1:
=<div id="DeployerIPv6">Activer IPV6 dans son infrastructure </div>=
+
<!--
 +
> [[MOOC:Accueil|MOOC]]>[[MOOC:Contenu|Contenu]]>[[MOOC:Document_Compagnon |Doc compagnon]] > [[MOOC:Compagnon_Act42-s7 |Activité 42]]
 +
 
 +
----
 +
-->
 +
__NOTOC__
 +
 
 +
<!-- ----------------------------------------- -->
 +
= <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>.
  
Successfully Deploying 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.
https://www.nanog.org/sites/default/files/ANOTR5-SuccessfullyDeployIPv6.pdf
+
  
== Obtenir un préfixe IPv6 ==
+
== 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.
  
==<div id="double pile">Installation en double pile</div>==
+
<center>
 +
[[Image:43-fig1-hd.png|300px|thumb|center|Figure 1 : Encapsulation pour un tunnel.]]
 +
</center>
 +
 +
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.
  
 +
<center>
 +
[[Image:43-fig2-2-hd.png|400px|thumb|center|Figure 2 : Tunnel entre des réseaux IPv6.]]
 +
</center>
  
Le mécanisme de double pile IP présenté par le RFC 4213 consiste à doter chaque équipement du réseau d'une double pile protocolaire (''Dual Stack'') et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau.
+
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.
Les noeuds sont capables de communiquer dans les deux versions du protocole IP. Ceci demande clairement un double travail, tout doit être fait en double. Tous les segments d'un réseau sont en double pile. En contrepartie, ce mécanisme ne prend pas en compte les problèmes de pénurie d'adresses IPv4. En effet, la double pile ne règle pas le problème de l'épuisement du plan d'adressage d'IPv4. Car chaque machine IPv6 a besoin d'une adresse IPv4.
+
  
 +
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.
  
Tous les équipementiers de coeur de réseaux supportent ce mécanisme, qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Le déploiement de ce mécanisme peut être progressif et ne concerner qu'une partie du coeur de réseau dans un premier temps. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé. Dans ce cas en effet, l'activation de fonctions permettant de gérer plusieurs topologies peut s'avérer nécessaire (cf. [[ISIS]]).
 
  
Pour les équipements terminaux, ce mécanisme de transition a été défini et a été très largement employé dès le début de la standardisation d'IPv6. De la même manière, il consiste à doter chaque équipement d'une double pile protocolaire et d'affecter une adresse IPv4 et/ou IPv6 à chaque inteface réseau. Cela ne résoud pas le problème de la pénurie d'adresses IPv4, mais permet dans un premier temps d'acheminer indifférement du trafic IPv4 ou IPv6 sur un équipement donné (station, routeur).
+
<center>
 +
[[Image:43-fig3-2.png|200px|thumb|center|Figure 3 : Architecture d'un routeur tunnelier.]]
 +
</center>
  
 +
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.
  
La figure Compatibilité grâce à la double pile illustre ce principe. La station B peut parler en IPv4 avec la station A et en IPv6 avec la station C. Le listing suivant donne un exemple de configuration d'une double pile dans un environnement Unix.
+
== Tunnel configuré ==
  
[[image:CS175.gif]]
+
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.  
  
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
+
<center>
inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255
+
[[Image:42-fig4-2.png|300px|thumb|center|Figure 4 : Cas d'un tunnel configuré.]]
inet6 3ffe:305:1002:1:2b0:d0ff:fe5c:4aee/64
+
</center>
inet6 fe80::2b0:d0ff:fe5c:4aee/64
+
ether 00:b0:d0:5c:4a:ee
+
media: 10baseT/UTP <half-duplex>
+
supported media: autoselect 100baseTX
+
  
 +
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.
  
<!-- Socket avec adress IPv4 mapped -->
+
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
  
QUelque soit la version de protocole utilisée au niveau de l'application cela ne doit rien changé.  Il faut cependant que l'application puisse exprimer l'adresse de son correspondant que ce soit en IPv4 ou en IPv6. Pour cela, les adresses doivent être codées sur 128 bits. Un type d'adresse IPv6 a été défini à cet usage à savoir comporter l'adresse IPv4 d'une communication IPv4. L'adresse IPv4 est imbriquée dans une adresse IPv6. Au niveau de l'interface pour la communication, l'application peut recevoir une connexion aussi bien en IPv4 ou en IPv6. Le format des adresses IPv4 mapped  est ::FFFF:<ipv4 address> comme par exemple ::FFFF:1.2.3.4
+
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''===
  
Reste le problème des applications. Une application écrite avec l'API socket IPv6 ([[L'interface de programmation "socket" IPv6]]), utilisant en particulier des <tt>struct sockaddr_storage</tt> et la fonction <tt>getaddrinfo</tt>, peut dialoguer indifférement en IPv4 et en IPv6. Simplement, pour un serveur, deux sockets sont nécessaires, l'une pour IPv4 et l'autre pour IPv6. La station B devrait, dans l'exemple de la figure ci-dessus, posséder des serveurs pour chacune des versions de IP, ou au moins des serveurs écoutant sur plusieurs ports en parallèle. Cela peut être évité en utilisant des [[Autres types d'adresses#mappee|adresses mappées]], qui permettent à une application de voir l'espace d'adresses IPv4 comme une partie de l'espace d'adressage IPv6.
+
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>
  
Comme le montre la figure Adresse IPv4 mappée, l'adresse IPv4 est contenue dans l'adresse IPv6.  
+
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.
  
[[image:CS176.gif]]
+
<center>
 +
[[image:42-fig6-2.png |350px|thumb|center|Figure 6 : Configuration d'un  ''Tunnel Broker'' avec TSP.]]
 +
</center>
  
Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application s'est enregistrée via une socket IPv6 (famille de protocoles <tt>PF_INET6</tt>), les adresses IPv4 mappée source et destination sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement quand une application IPv6 émet des paquets avec une adresse IPv4 mappée, ceux-ci sont aiguillés vers la pile IPv4.
+
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.
  
L'exemple suivant illustre ce fonctionnement. Le client telnet, compilé en IPv6 peut contacter les équipements IPv4 en utilisant l'adresse mappée.
+
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 :
  
  >'''telnet rhadamanthe'''
+
  -- Successful TCP Connection --
  Trying 3ffe:305:1002:1:2b0:d0ff:fe5c:4aee...
+
  C:VERSION=2.0.0 CR LF
  Connected to rhadamanthe.ipv6.rennes.enst-bretagne.fr.
+
S:CAPABILITY TUNNEL=V6V4 AUTH=ANONYMOUS CR LF
  Escape character is '^]'.
+
C:AUTHENTICATE ANONYMOUS CR LF
 
+
S:200 Authentication successful CR LF
  FreeBSD/i386 (rhadamanthe.ipv6.rennes.enst-br) (ttyp3)
+
C:Content-length: 123 CR LF
 
+
  <tunnel action="create" type="v6v4">
  login:^D
+
<client>
  >'''telnet bloodmoney'''
+
<address type="ipv4">1.1.1.1</address>
  Trying ::ffff:193.52.74.211...
+
  </client>
  Connected to bloodmoney.rennes.enst-bretagne.fr.
+
  </tunnel> CR LF
  Escape character is '^]'.
+
S: Content-length: 234 CR LF
 
+
200 OK CR LF
 
+
  <tunnel action="info" type="v6v4" lifetime="1440">
  SunOS UNIX (bloodmoney)
+
  <server>
 
+
  <address type="ipv4">206.123.31.114</address>
  login:
+
<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
  
Le mécanisme de double pile permet de résoudre tous les problèmes d'interopérabilité liés à l'introduction de la pile IPv6. Quand cela est possible, la communication se fait en utilisant la nouvelle version du protocole. Dès qu'un des éléments n'est pas compatible (réseau, système d'exploitation, application), le protocole IPv4 est utilisé. Le principal intérêt vient du fait qu'il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes. Pourtant ce mécanisme n'est pas suffisant :
+
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<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.
  
* Il ne résout pas le problème de la pénurie d'adresses puisque chaque machine doit disposer d'une adresse IPv4 et d'une adresse IPv6. Cela complique aussi les mécanismes de configuration automatique.
+
== Tunnel automatique ==
* Il implique que tous les routeurs soient aussi configurés pour router les deux types de paquets.
+
* Les applications doivent être compilées pour IPv6, ce qui implique la disponibilité du code source et un "effort" de reprogrammation.
+
  
Les applications recompilées avec l'API IPv6 ne fonctionnent que sur des équipements pourvus d'un système récent (et d'une pile IPv6 si on utilise les adresses IPv4 mappées), ce qui peut poser des problèmes de compatibilité entre les différentes versions d'un système.
+
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'').
  
===Implications au niveau du DNS===
+
<center>
 +
[[Image:43-fig7-3.png|300px|thumb|center|Figure 7 : Cas d'application d'un tunnel automatique.]]
 +
</center>
  
A résumer
 
  The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map
 
  between hostnames and IP addresses.  A new resource record type named
 
  "AAAA" has been defined for IPv6 addresses [RFC3596].  Since
 
  IPv6/IPv4 nodes must be able to interoperate directly with both IPv4
 
  and IPv6 nodes, they must provide resolver libraries capable of
 
  dealing with IPv4 "A" records as well as IPv6 "AAAA" records.  Note
 
  that the lookup of A versus AAAA records is independent of whether
 
  the DNS packets are carried in IPv4 or IPv6 packets and that there is
 
  no assumption that the DNS servers know the IPv4/IPv6 capabilities of
 
  the requesting node.
 
  
  The issues and operational guidelines for using IPv6 with DNS are
+
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
  described at more length in other documents, e.g., [DNSOPV6].
+
<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.  
  
  DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling
+
<center>
  both AAAA and A records.  However, when a query locates an AAAA
+
[[image:43-fig8-2-hd.png|300px|thumb|center|Figure 8 : Construction d'un préfixe IPv6 à partir de l'adresse IPv4 du tunnelier.]]
  record holding an IPv6 address, and an A record holding an IPv4
+
</center>
  address, the resolver library MAY order the results returned to the
+
  application in order to influence the version of IP packets used to
+
  communicate with that specific node -- IPv6 first, or IPv4 first.
+
  
  The applications SHOULD be able to specify whether they want IPv4,
+
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.
  IPv6, or both records [RFC3493]That defines which address families
+
  the resolver looks up. If there is not an application choice, or if
+
  the application has requested both, the resolver library MUST NOT
+
  filter out any records.
+
  
  Since most applications try the addresses in the order they are
+
<center>
  returned by the resolver, this can affect the IP version "preference"
+
[[image:43-fig6-hd.png|400px|thumb|center|Figure 9 : Format d'une adresse construite sur la base d'une connectivité par un tunnel.]]
  of applications.
+
</center>
  
  The actual ordering mechanisms are out of scope of this memo.
 
  Address selection is described at more length in [RFC3484].
 
  
  
===Précaution: Eviter led pbs pour les "eye balls" ===
+
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.
  
[[http://www.bortzmeyer.org/globes-oculaires-heureux.html Le bonheur des globes oculaires (IPv6 et IPv4) ]]
+
<center>
 +
[[image:43-fig10-3-hd.png|400px|thumb|center|Figure 10 : Envoi d'un paquet IPv6 en passant par un tunnel automatique.]]
 +
</center>
  
RFC 6555 Happy Eyeballs: Success with Dual-Stack Hosts http://www.bortzmeyer.org/6555.html
+
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é <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>.
 +
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>
 +
 
 +
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>
 +
 
 +
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.
 +
 
 +
<center>
 +
[[Image:43-fig14-hd.png|400px|thumb|center|Figure 13 : Exemple de construction d'un préfixe délégué ''6rd''.]]
 +
</center>
 +
 
 +
 
 +
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<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.
 +
 
 +
==  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<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.
 +
 
 +
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==
 +
<references />
 +
 
 +
== 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 [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