Revision as of 11:32, 15 June 2015

> MOOC>Contenu>Séquence 4 > Activité 43

III/ Etablir la connectivité IPv6

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 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 le principe des 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 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 avoir une configuration dynamique.

Figure 1: Encapsulation pour un tunnel

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

Figure 2: Tunnel entre ilôts IPv6

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.

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

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

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

Figure 3: Cas d'un tunnel configuré

Un tunnel configuré demande un travail de configuration, cela peut être vu comme un inconvénient. Des solutions d'automatisation ont été étudiées qui ont comme principe de contenir l'adresse IPv4 du tunnelier de destination dans l'adresse IPv6. Le technique de transition 6to4 décrite par le RFC 3056 suit ce principe. Elle vise à interconnecter entre eux des sites IPv6 isolés en créant des tunnels automatiques IPv6 dans IPv4 en fonction du destinataire des données.

Figure 4: 6to4

Comme 6in4, l'encapsulation des paquets IPv6 s'effectue directement dans les paquets IPv4. 6to4 profite d'un préfixe IPv6 2002::/ 16 réservé. Le préfixe IPv6 d'une adresse IPv6 d'un tunnelier est composée automatiquement en le préfixant par le préfixe réservé suivie par l'adresse IPV4 unicast globale de ce tunnelier comme montré par la figure 5. Ainsi un préfixe IPv6 de longueur 48 bits peut être aisément construit en utilisant l'adresse IPv4 du noeud en bordure des réseaux IPv4 et IPv6.

Figure 5: Format d'une adresse 6to4

Par exemple, la figure 6 illustre le mécanisme de construction d'un préfixe. Le noeud A se trouve en bordure du réseau. Il est connecté à la fois à l'Internet v4 et à un (ou des) réseau(x) IPv6. C'est un noeud en double pile, il possède obligatoirement une adresse IPv4. Il va s'en servir pour construire les 48 premiers bits de l'adresse IPv6. C'est ce préfixe de 48 bits qui va être utilisé par l'ensemble des équipements IPv6 du site. Ce préfixe identifie un site donné. On peut remarquer que ce plan d'adressage est conforme aux plans d'adressage globaux actuellement en vigueur, puisqu'il réserve 16 bits pour numéroter les réseaux du site et 64 bits pour les identifiants d'interface.

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.

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.

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.

La figure Exemple de routage des paquets explique comment les paquets sont routés quand l'équipement A veut envoyer un paquet IPv6 à l'équipement B. Dans un premier temps, A interroge le DNS pour connaître l'adresse IPv6 de B. La réponse est une adresse du type 2002:C0C0:C0C0:.... La machine A émet un paquet vers cette destination. Les paquets dont l'adresse destination commence par le préfixe 2002::/16, correspondant au plan d'adressage 6to4, sont routés vers un routeur tunnelier pour 6to4. Ce dernier analyse l'adresse IPv6 de destination et trouve l'adresse IPv4 de l'autre extrémité du tunnel (192.192.192.192 dans l'exemple). Le paquet est reçu par le routeur RB qui retire l'encapsulation IPv4 et le route normalement vers la destination 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.

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.

Figure 5:

Le mécanisme définit plusieurs composants:

• la machine terminale 6to4 (dépendante de l'implantation dans le système d'exploitation)
• le routeur de bordure (ou gateway), qui doit encapsuler les paquets IPv6 dans des paquets IPv4, est connecté à IPv4 et IPv6
• le relais 6to4 est un équipement réseau dont l'adresse est bien connue (adresse anycast). Il assure la connexion à l'Internetv6.

6to4 permet à un ISP de fournir de la connectivité IPv6 à ses usagers en installant une machine unique connectée aux deux mondes IP. Il peut aussi permettre à un usager de router du trafic IPv6 même si son prestataire ne fournit qu'une connectivité et des adresses IPv4. Il faut noter que le routage entre les machines distantes a de bonnes probabilités d'être asymétrique notamment si le routeur de bordure utilise un relais 6to4 et que l'utilisation des tunnels peut conduire à des délais de propagation élevés.

On peut envisager l'usage de la technique 6to4 de deux manières :

• Comme un moyen de pression envers les ISP. Un site dont le fournisseur de service refuse d'offrir un service IPv6, n'est pas bloqué. Il dispose d'une méthode simple pour construire ses adresses IPv6 et la création de tunnels. Il suffit de trouver l'adresse IPv4 d'un routeur passerelle qui traitera les paquets.
  Cette approche conduit à un routage sous-optimal, comme indiqué précédemment, et à une anarchie dans le réseau en terme d'administration.
• Pour permettre aux ISP d'offrir un service IPv6 minimum à leurs clients. Cette approche est acceptable dans la période de déploiement d'IPv6. Le fournisseur de services met en place un routeur passerelle uniquement pour ses clients et le place par exemple dans un point d'interconnexion. D'une part, la charge administrative et technique est réduite puisque l'ISP n'a pas à gérer un nouveau plan d'adressage ou la création de nombreux tunnels. D'autre part, le routage est plus optimal puisque le relais est proche des clients et du réseau IPv6 auquel l'ISP est relié.

On pourrait envisager l'installation de relais 6to4 sur les points d'échange de l'Internet pour accélérer le déploiement et l'usage d'IPv6 par les ISP. Mais il n'y a pas de demande dans ce sens actuellement et ce mécanisme est actuellement peu déployé par les ISP. La question de sa résistance au facteur d'échelle, et des aspect liés à la sécurité, sont posées depuis longtemps. Ils n'ont pas encore trouvé de réponse.

On peut remarquer dans cet exemple que l'adresse de la source peut être aussi bien une adresse IPv6 6to4 qu'une adresse IPv6 globale. Mais le dialogue dans le sens opposé est plus complexe et montre les limites de cette technique.

Un site utilisant 6to4 n'est pas, par définition, connecté à l'Internet v6. Il doit donc exister dans l'Internet v4 des routeurs servant de passerelle vers le réseau Internet IPv6. Un routeur de bordure faisant l'encapsulation des paquets IPv6 dans des paquets IPv4 peut être configuré de la manière suivante :

• si l'adresse du destinataire commence par le préfixe 2002::/16, effectuer l'encapsulation du paquet vers le destinataire IPv4 dont l'adresse est incluse dans l'adresse IPv6 de destination,
• sinon, il s'agit d'une adresse IPv6 globale et le paquet doit être tunnelé à l'adresse IPv4 d'un routeur servant de passerelle vers le réseau IPv6.

De même, dans la figure Exemple de routage des paquets, nous avons supposé que le routeur faisant l'encapsulation était situé en bordure du réseau du site où se trouve la machine A. C'est probable si le site utilise également un plan d'adressage 6to4. Par contre si le site n'utilise que des adresses globales, voire n'a pas de connexion IPv4, l'encapsulation peut être déléguée à un routeur passerelle. Ce routeur passerelle peut en utilisant les protocoles de routage interne et externe annoncer aux équipements IPv6 cette fonctionnalité.

Le danger est d'engorger les tables de routage IPv6 avec une complexité lié à l'adressage IPv4. Pour éviter cet écueil, un routeur passerelle ne doit pas annoncer un préfixe IPv6 autre que 2002::/16. En conséquence, les paquets émis à destination d'une adresse 6to4 seront traités par le routeur le plus proche au sens des protocoles de routage.

Il est important de respecter cette règle au niveau des annonces BGP, comme le montre l'exemple de configuration des routeurs See Règles d'annonce et d'agrégation.

Si 6to4 est une technique intéressante pour relier deux nuages IPv6 à travers un nuage IPv4, elle se complique et n'est pas optimale lorsqu'il s'agit de communiquer avec une machine dont l'adresse est issue d'un plan de numérotation global. Le routage n'est pas toujours optimal et presque assurément asymétrique :

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

Pour réduire la taille des tunnels, une adresse IP anycast a été proposée pour automatiser et simplifier la phase de configuration de l'adresse du relais. Le préfixe 192.88.99.0/24 a été attribué à ce propos [RFC 3068] et le relais prend l'adresse 2002:c058:6301::, ou 192.88.99.1 en utilisant l'adresse IPv4. Un site offrant ce service peut annoncer ce préfixe dans le routage global de l'Internetv4 et les paquets à destination d'un relais iront vers l'équipement le plus proche.

Connectivité d'un sité isolé : Tunnel Broker

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.

RFC 3053

Un serveur de tunnels (IPv6 dans IPv4) permet de connecter à l'Internetv6 une machine double pile isolée dans l'Internetv4. Dans certaines versions de ce service un réseau local peut être ainsi connecté, quel que soit le nombre de machines qu'il comporte. La configuration du tunnel entre le serveur et la machine cliente est automatique et repose sur le protocole TSP. La demande de connexion au serveur est réalisée par une page HTML dont l'URL est connue à l'avance.

Ce mécanisme/service permet de fournir de la connectivité IPv6 à des équipements/réseaux locaux isolés dans l'Internetv4. Cette connectivité est en générale fournie à titre provisoire (soit en attendant que l'offre des ISP soit disponible soit pour faire des tests de validation, par exemple). Elle peut aussi être une première étape pour un prestataire de service pour procurer de la connectivité IPv6 à ses usagers.

Le service Tunnel Broker repose sur une architecture à base de client/serveur. Côté usager l'installation d'un simple client permet de faire la demande de tunnels au serveur. Ce client est en général authentifié. Pour le prestataire, il faut mettre en oeuvre un serveur qui a plusieurs fonctions : l'interface HTML pour accueillir les demandes de tunnels des usagers et la « comptabilité » qui peut l'accompagner, le configurateur de tunnels qui envoie les paramètres d'extrémité du tunnel entre l'équipement de concentration et celui de l'usager d'une part et le concentrateur de tunnels d'autre part.

De nombreuses évolutions de ce mécanisme sont en cours :

• L'authentification du client demandant à [r]établir une connexion au serveur de tunnels permet de disposer d'une fonction VPN quel que soit le lieu où se trouve l'usager dans l'Internet.
• Les implantations s'appuyant sur des tunnels UDP permettent la traversée de NAT, fonction indispensable aux terminaux (ou réseaux) situés dans un plan d'adressage privé.
• Le découpage de l'espace d'adresse pour numéroter les extrémités de tunnels et les réseaux d'interconnexion, nécessite un peu de doigté. Là aussi des évolutions sont en cours pour simplifier les implantations actuelles et mieux coller à l'expérience de déploiement des réseaux IPv6 acquise ces dernières années.

Automatisation par TSP (Tunnel Setup Protocol)

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

Le tunnel setup protocole [BP-id] a été défini en complément du Tunnel Broker afin de permettre une négociation automatisée des différents paramètres entrant en jeu lors de l'établissement d'un tunnel. En effet, nombre d'implémentations de Tunnel Broker sont basées aujourd'hui sur une interface Web qui permet de saisir ou de récupérer implicitement les paramètres nécessaires à l'établissement du tunnel entre le terminal et le Tunnel serveur. L'architecture d'un Tunnel broker implémentant TSP est donné figure Configuration d'un Tunnel Broker avec TSP.

TSP permet la négociation automatique et transparente à l'utilisateur de tout ou partie des paramètres suivants :

• le mécanisme d'authentification utilisateur utilisé,
• le type d'encapsulation utilisée : IPv4 dans IPv6, IPv6 dans IPv4, IPv6 dans UDP IPv4
• 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'enregistrement DNS dans le cas d'un terminal
• la résolution DNS inverse dans le cas d'un routeur

La disponibilité du type d'encapsulation IPv6 dans UDP IPv4, permet d'offrir une solution de traversée de NAT, alternative à celle proposée par exemple par Teredo. Dans ce cas, le client TSP met en oeuvre un processus de découverte de NAT qui consiste simplement à envoyer au TSP serveur du Broker, un message UDP contenant l'adresse IP du terminal. Le serveur TSP serveur compare simplement l'adresse contenue dans le message avec l'adresse source du paquet UDP. Si elles sont différentes alors le terminal est situé derrière un NAT.

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

Connectivité sur une infrastructure IPv4

La construction d'une infrastructure IPv6 même si les équipements d'interconnexion ne gèrent que le protocole IPv4 reposent sur des tunnels. Le point fort du mécanisme présenté ici est l'automatisation, où l'intervention de l'administrateur est réduite à une phase de configuration/ initialisation du service.

6to4

6rd

6rd signifie "IPv6 Rapid Deployment". 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 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. 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

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

Figure 6:.

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. L’organisation de l’adresse IPv6 est décrite par la figure 7.

Figure 7: Format d'une adresse 6-RD

Dans le cas d’une adresse IPv4 publique 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.

Sans adresse IPv4 publique 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).

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

• 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.
  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.
  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.
• 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.
  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.
  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.
• 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

6rd est adaptée à une mise en œuvre simplifiée d’IPv6 pour des FAI