Les mécanismes disponibles pour ce segment de réseau, contrairement à ceux décrits précédemment, mettent en oeuvre une architecture type client/serveur. Sauf exception ou cas particulier, la partie cliente est localisée côté utilisateur et la partie serveur côté ISP.

Le point fort des mécanismes présentés ici est de permettre une mise en ?uvre de solutions dites automatiques, où l'intervention de l'administrateur est réduite à une phase de configuration/ initialisation du service.

6to4

Le mécanisme 6to4 permet d'interconnecter entre eux des sites IPv6 isolés en créant des tunnels automatiques IPv6 dans IPv4 en fonction du destinataire des données. 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.

Le préfixe 2002::/16 a été alloué par l'IANA à ce type d'adressage (cf. figure Adresse 6to4). Le gestionnaire d'un site peut aisément créer un préfixe de longueur 48 en y concaténant l'adresse IPv4 (convertie en hexadécimal) d'un routeur en bordure des réseaux IPv4 et IPv6.

La figure Exemple de numérotation en utilisant le préfixe de 6to4 illustre le mécanisme d'attribution de préfixes. Le routeur RB se trouve en bordure du réseau. Il est connecté à la fois à l'Internet v4 et à un (ou des) réseau(x) IPv6. Le routeur possède obligatoirement une adresse IPv4 sur le réseau de l'ISP. 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 6to4 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.

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.

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 l'exemple 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 IPv4 anycast a été proposée pour automatiser 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 192.88.99.1. 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.

Tunnel Broker

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

TSP : tunnel setup protocol

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é See 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