> MOOC>Contenu >[MOOC:Sequence_4|Séquence 4 ] > Document compagnon

---

Intégration d'IPv6 à l'Internet actuel

I/ Introduction

L'étape de standardisation des protocoles de base de IPv6 (core specs) est achevée, le développement de techniques assurant la transition devient un point clé dans le déploiement à grande échelle du protocole IPv6. Pour certaines catégories d'applications comme le mail, le web, le succès d'IPv6 est fortement lié à l'interopérabilité avec IPv4 puisque jusqu'à présent la majorité des informations et des utilisateurs ne sont accessibles qu'avec cette version du protocole. Il faut donc pouvoir amorcer un cercle vertueux qui permettra de passer à IPv6.

La phase de transition doit être simple, ou au minimum moins compliquée qu'une utilisation prolongée d'IPv4. Elle doit être également souple pour permettre un étalement dans le temps de la transition. Il n'y a pas de jour J pour le passage d'IPv4 à IPv6, il n'y a également pas d'échéance pour la disparition du protocole IPv4.

Généralement, l'identification d'une killer application est recherchée pour justifier un passage rapide vers IPv6. Ce fut le cas avec IPv4 quand le Web est apparu. Les sites sont massivement passés de protocoles propriétaires (IPX, NETBUI) vers IPv4 pour accéder aux informations par un navigateur, ce qui à conduit au concept d'intranet. On ne connaît pas actuellement d'applications particulières pouvant forcer massivement le passage vers IPv6. Les fonctionnalités sont les mêmes, puisqu'il ne s'agit que d'une nouvelle version du protocole IP. La qualité de service est souvent évoquée, mais il s'agit d'un leurre, car les mécanismes de réservation ou de différenciation se trouvent indifféremment dans les deux versions du protocole.

Les raisons qui vont nécessiter le passage à IPv6 vont être fortement liées à la pénurie d'adresses pour les nouveaux réseaux et aux fonctionnalités de configuration automatique que requièrent un grand espace d'adressage :

• le réveil des pays de la zone Asie Pacifique (en particulier la Chine et l'Inde) qui ont actuellement un taux d'adresses par habitant très faible,
• la téléphonie mobile avec GPRS puis les services de 3ème génération où chaque téléphone pourra se voir attribuer une adresse, voire un préfixe,
• les réseaux domotiques ou personnels, où la simplicité de configuration va être un critère important. Dans ces réseaux, on prévoit la généralisation de nouveaux types d'applications, qui sans être LES "killer applications" ne se contentent pas d'un fonctionnement en mode client/serveur :
• les applications de type peer-to-peer (comme la téléphonie sur IP, les jeux répartis,...) nécessitant des connexions entrantes, contrairement aux architectures clients/serveurs autorisées par l'emploi de l'adressage privé,
• les connexions permanentes où les mécanismes d'allocation d'adresses temporaires (PPP, DHCP,...) sont inefficaces.
• les grands parcs de machines où les mécanismes de configuration automatique vont simplifier la gestion du réseau. Avec IPv6, le réseau peut se gérer uniquement au niveau des routeurs, les stations construisant leur adresses automatiquement, alors qu'avec IPv4, chaque équipement doit être configuré.

A l'inverse, plusieurs autres facteurs vont freiner le déploiement d'IPv6 pour rester dans une situation de statu quo ou d'emploi d'autres mécanismes au-dessus d'IPv4. Ces facteurs limitant le déploiement d'IPv6 sont de plusieurs ordres :

• techniques :
  • la disponibilité du code IPv6 dans les équipements terminaux (PC, stations de travail, imprimantes,...) et dans les routeurs. Cette phase est achevée pour la plupart des équipementiers. Les fabricants d'équipements d'interconnexion ont intégré le code IPv6 dans leur nouveaux systèmes d'exploitation. Le monde Unix est également à la pointe pour la disponibilité d'une pile IPv6. Windows dispose aussi nativement d'une pile IPv6 aisément configurable pour les versions XP.
  • si les piles IPv6 commencent à se généraliser, nombre d'applications spécialisées ne sont pas encore prêtes (environnement de travail intégré, ...) surtout dans les environnements où le code source n'est pas disponible.
    Aujourd'hui , plus aucune application ne devrait être programmée sans pouvoir être utilisée dans un environnement IPv6. Cela implique, soit l'utilisation de l'API IPv6, soit tout simplement l'usage de règles de programmation, comme éviter de considérer l'adresse IP comme un entier, et de s'en servir comme d'un identificateur.
    C'est actuellement le facteur le plus bloquant pour un déploiement massif d'IPv6.
  • le problème lié à la phase de démarrage, dit de la poule et l'oeuf : les sites ne vont pas migrer vers IPv6 puisque les opérateurs n'offrent pas de connectivité IPv6 et les opérateurs ne vont pas offrir de réseaux IPv6 puisqu'il n'y a pas de client.
    En réalité il s'agit d'un faux problème. Un réseau IPv6 peut être déployé en intranet, les communications avec l'Internet restant en IPv4.
    De plus les opérateurs commencent à déployer des réseaux IPv6, les autorités régionales (RIPE-NCC, APNIC, ARIN,...) allouent des préfixes officiels, et les réseaux se mettent en place. Un site voulant acquérir une expérience en IPv6 peut se raccorder relativement facilement à un de ces réseaux. Si cette démarche est impossible, l'emploi de 6to4 permet de construire son propre préfixe IPv6 et de s'interconnecter au reste du monde IPv6, D'autres mécanismes, comme Tunnel Broker permettent de se connecter tres simplement à l'Internet IPv6. Ces mécanismes sont passés en revue au long de ce chapitre.
• psychologiques :
  • IPv6 peut sembler mystérieux au premier abord et la taille des adresses peut décourager un ingénieur réseau habitué à manipuler les netmasks et les adresses IPv4. En réalité, les principes sont très similaires, et après quelques heures d'entraînement, leur emploi est relativement simple. Par ailleurs, ce livre participe, nous l'espérons, à ce transfert de connaissance et à la "dédramatisation" de cette nouvelle version du protocole IP.
  • le risque de casser quelque chose qui fonctionne correctement en changeant le protocole. Cette possibilité peut exister, mais la migration en douceur du réseau, sans jour J, permet de se focaliser sur les nouveaux réseaux tout en laissant les anciens fonctionner sous IPv4.

La suite de ce chapitre va décrire quelques mécanismes de transition, leurs principes et leurs limites. Le choix repose sur l'expérience de ces mécanismes et l'intérêt qu'ils offrent. Il ne semble pas qu'il soit nécessaire, voire possible, de définir un mécanisme unique et universel de transition entre les deux mondes. Dans certains cas, comme par exemple l'utilisation d'adresses IPv6 au sein d'une entreprise, seules les connexions sortantes doivent être autorisées. Chaque mécanisme répond à un besoin particulier :

• la construction d'une infrastructure IPv6 même si les équipements d'interconnexion ne gèrent que le protocole IPv4. Ces mécanismes sont principalement à base du tunnels statiques où les paquets IPv6 sont encapsulés dans des paquets IPv4.
• l'accès à un réseau IPv6 existant. Ces mécanismes sont principalement axés autour de la création dynamique de tunnels (6to4, Tunnel Broker). Le chapitre Déploiement IPv6 des fournisseurs d'accès (ISP) décrit l'utilisation de ces mécanismes.
• les mécanismes de traduction permettant la communication entre les deux versions du protocole pour que des applications conçues pour IPv4 et celles pour IPv6 puissent échanger des données. Cette traduction peut se faire à différents niveaux de l'architecture réseau :
• au niveau applicatif avec des relais (ALG : Application Level Gateway) ou proxy. Si l'application est connue, comme pour le web, le DNS les serveurs d'impressions ou le web, la traduction est relativement simple à faire. Cette méthode de migration devrait permettre de traiter la majorité des flux.
• au niveau transport avec des relais UDP et TCP [RFC 3142],
• au niveau IP, avec la création d'une interface encapsulant des paquets IPv4 dans des paquets IPv6 et se voyant allouer de manière temporaire une adresse IPv4 (DSTM : Dual Stack Transition Mechanism),
• au niveau de l'équipement de sortie d'un site avec des mécanismes de traduction d'en-tête.
  Cette traduction peut se faire sans installer d'état dans le routeur d'un site avec SIIT (Stateless IP/ICMP Translation), le paquet IPv4 est construit à partir d'informations déjà contenues dans l'en-tête IPv6, en particulier un format d'adressage particulier permet de véhiculer une adresse IPv4 dans les adresses IPv6.
  Par contre NAT-PT utilise les mêmes mécanismes que pour le passage d'une adresse IPv4 privée vers une adresse IPv4 publique, un pool d'adresses IPv4 est alloué au boîtier traducteur.
• La difficulté d'assurer la compatibilité entre les deux mondes n'est pas symétrique. Avec les mécanismes comme NAT-PT, SIIT ou DSTM, il est beaucoup plus facile d'initier une session partant du monde IPv6 pour aller vers le monde IPv4. En effet, il est possible d'ajouter des fonctionnalités au monde IPv6 pour faciliter la cohabitation. De plus comme une adresse IPv6 est quatre fois plus grande, elle peut contenir une adresse IPv4.
  Dans le sens inverse, il est impossible de modifier l'existant en IPv4. Ces différents mécanismes de transition s'appuient sur le DNS pour déclencher l'établissement d'un contexte (NAT-PT) ou l'allocation d'adresses temporaires (SIIT, DSTM). Le nom de l'équipement devient la référence commune entre les mondes IPv4 et IPv6.

Le déploiement progressif de ces mécanismes permet d'introduire graduellement et indépendamment le protocole IPv6 dans tous les segments du réseau. Chaque mécanisme a une portée bien définie (terminal, site, réseau). Il apporte une pièce au puzzle que constitue le passage d'IPv4 à IPv6.

En contrepartie chaque mécanisme de transition introduit une complexité supplémentaire dans le réseau. Ces mécanismes dits de transition n'ont pas pour vocation d'exister durablement. Ils devraient décroître dans le temps en fonction du nombre d'équipements IPv6 présents sur le réseau. De plus, les mécanismes de cohabitation (SIIT, DSTM, NAT-PT), ne visent que les applications existantes. Les nouvelles applications en particulier pour la domotique pourraient directement démarrer en IPv6.

Etat de la standardisation à l'IETF

Working Group ngtrans : approche "boite à outils"

D'une façon générale, l'une des clés de l'adoption d'une nouvelle technologie repose sur la facilité avec laquelle il est possible d'abandonner l'ancienne au profit de la nouvelle. Aussi, le groupe de travail IETF ngtrans a été créé, dès l'origine et en parallèle du groupe de travail IETF ipng, pour traiter des aspects liés à la transition des réseaux et applications d'IPv4 vers IPv6. La principale contrainte à respecter étant qu'il ne doit pas y avoir de jour J pour le basculement de l'ensemble de l'Internet vers IPv6 (à l'image du passage à l'an 2000 par exemple), et qu'au contraire il doit être possible de passer graduellement et progressivement d'IPv4 à IPv6, à tout moment et indépendamment de l'infrastructure réseau considérée.

Ngtrans a donné le jour à nombre de mécanismes de transition, permettant chacun de résoudre une problématique de transition particulière (interconnexion de réseaux IPv6 isolés, communication entre applications IPv4 et IPv6, transport de flux IPv6 dans les réseaux IPv4, etc...). Finalement une boîte à outils très complète a été définie, apportant des solutions a un vaste ensemble problèmes liés à la transition, soit localement à un terminal, soit plus globalement à l'échelle d'un réseau ou même de l'Internet dans son ensemble.

Cette mission remplie pour sa majeure partie, le groupe de travail ngtrans a finalement été clos pour laisser la place à IPv6ops traitant plus globalement de l'ensemble des aspects opérationnels liés au déploiement d'IPv6. En outre, il a souvent été reproché à ngtrans d'avoir spécifié une large boîte à outils sans en avoir décrit le mode d'emploi, et sans discernement des cas de transition concrets ou théoriques. Ainsi l'adoption d'IPv6 aurait été rendue en apparence plus complexe, contrairement au but initialement recherché.

Working Group IPv6ops : de la transition à la coexistence (déploiement opérationnel)

Au-delà de la critique faite à ngtrans et qui est encore aujourd'hui matière à débats, le groupe de travail IPv6ops (IPv6 operations), créé en septembre 2002, s'inscrit dans une dynamique nouvelle visant à traiter de l'ensemble des problèmes opérationnels liés au déploiement d'IPv6. Fort du principe selon lequel le passage d'IPv4 à IPv6 ne peut se réaliser que progressivement selon les infrastructures concernées et graduellement dans le temps, et sur la base du constat de l'absence d'imminence véritable d'une pénurie d'adresses IPv4, la transition IPv4/IPv6 devient essentiellement une question de coexistence des deux versions du protocole IP. Entre autres, l'approche en scénarios d'intégration d'IPv6 à l'existant, initialisée par ngtrans, est reprise par IPv6ops et se trouve déclinée selon quatre grandes familles : les réseaux de "mobiles" (UMTS, 3G), les réseaux d'ISP, les réseaux d'entreprise et les réseaux SOHO/domestiques. Cette approche en scénarios, a été achevée fin 2004, selon les objectifs fixés actuellement par le groupe IPv6ops.

II Utilisation des mécanismes d'intégration d'IPv6

Les principaux mécanismes d'intégration d'IPv6 -aussi dénommés mécanismes de transition- spécifiés par l'IETF sont regroupés dans le tableau ci-dessous. Leur utilisation possible dans différents segments du réseau est mentionnée. La difficulté est de pouvoir distinguer les différents usages de ces mécanismes, par exemple la fonction de serveur du tunnel broker, installée dans le réseau de l'ISP, et la fonction client de ce service installée chez un usager -entreprise ou particulier. Cette distinction est détaillée dans le paragraphe où le mécanisme est décrit (cf. tableau Mécanismes de transition).

Mécanismes de transition

Mécanismes de transition	Coeur de réseau	ISP	Entreprises	Particuliers
Double pile	X	X	X	X
6PE (MPLS)	X	X	X
6to4		X	X	X
Tunnel Broker		X	X	X
Tunnels configurés	?	X	X	X
TSP		X	X	X
ISATAP			X
TEREDO		X	X	X
Relais applicatifs		X	X	X
NAT-PT		X	X	X
DSTM		X	X	X
SOCKS			X	X
VPN		X	X	X
L2TP		X	X	X

Plusieurs champs de déploiement d'IPv6 sont présentés dans la suite de ce chapitre : le déploiement d'IPv6 dans le coeur de réseau en premier lieu, dans les réseaux de fournisseurs d'accès ensuite, et pour finir, l'accès des réseaux d'entreprises et de particuliers à la connectivité IPv6.

III/ Déploiement d'IPv6 dans le coeur du réseau

Double pile

Le mécanisme de double pile IP consiste à doter chaque équipement du réseau d'une double pile protocolaire (Dual Stack) et d'affecter une adresse IPv4 et/ou IPv6 à chaque interface réseau. Il s'applique à tous les segments d'un réseau. En contrepartie, ce mécanisme ne prend pas en compte les problèmes de pénurie d'adresses IPv4.

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

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.

xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255
inet6 3ffe:305:1002:1:2b0:d0ff:fe5c:4aee/64
inet6 fe80::2b0:d0ff:fe5c:4aee/64
ether 00:b0:d0:5c:4a:ee
media: 10baseT/UTP <half-duplex>
supported media: autoselect 100baseTX

Reste le problème des applications. Une application écrite avec l'API socket IPv6 (L'interface de programmation "socket" IPv6), utilisant en particulier des struct sockaddr_storage et la fonction getaddrinfo, 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 adresses mappées, qui permettent à une application de voir l'espace d'adresses IPv4 comme une partie de l'espace d'adressage IPv6.

Comme le montre la figure Adresse IPv4 mappée, l'adresse IPv4 est contenue dans l'adresse IPv6.

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 PF_INET6), 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.

L'exemple suivant illustre ce fonctionnement. Le client telnet, compilé en IPv6 peut contacter les équipements IPv4 en utilisant l'adresse mappée.

>telnet rhadamanthe
Trying 3ffe:305:1002:1:2b0:d0ff:fe5c:4aee...
Connected to rhadamanthe.ipv6.rennes.enst-bretagne.fr.
Escape character is '^]'.
 
FreeBSD/i386 (rhadamanthe.ipv6.rennes.enst-br) (ttyp3)
 
login:^D
>telnet bloodmoney
Trying ::ffff:193.52.74.211...
Connected to bloodmoney.rennes.enst-bretagne.fr.
Escape character is '^]'.
 
 
SunOS UNIX (bloodmoney)
 
login:

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 :

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

6PE (MPLS)

Ce mécanisme profite de la commutation de MPLS (Multi Protocol Label Switching) selon l'étiquette insérée dans un paquet, pour rendre un réseau capable de transporter des paquets IPv6 sans avoir à en modifier tous les équipements. Le coeur du réseau MPLS (les équipements P : Provider) reste inchangé. 6PE permet à un opérateur / ISP, dont le coeur de réseau s'appuie sur la technologie MPLS pour acheminer le trafic IPv4, de ne faire évoluer que la partie périphérique de son réseau (les équipements de périphérie : PE : Provider Edge) pour pouvoir transporter aussi le trafic IPv6 de ses usagers. Le routage IPv6 est réalisé par les équipements de périphérie (PE) qui attribuent une étiquette à chaque paquet IPv6.

La commutation de paquets IPv6 à haut débit peut poser des problèmes si les composants électroniques chargés de la commutation ne prennent pas en compte le nouveau format de paquets. MPLS peut être une solution pour véhiculer le trafic dans un réseau ne connaissant pas IPv6 puisque la décision de commuter une trame MPLS est faite en fonction d'une étiquette placée avant le paquet.

6PE, (La technique 6PE), propose l'utilisation de BGP pour créer automatiquement des tunnels dans un système autonome. Nous allons présenter ici sommairement une des possibilités appliquée à MPLS.

La figure Architecture d'un réseau MPLS illustre succintement l'architecture d'un réseau MPLS avec les routeurs en bordure de réseau (PE) qui insèrent les étiquettes en fonction de la destination et les routeurs en coeur de réseau (P) qui commutent rapidement les trames MPLS en fonction de l'étiquette.

Si la commutation de trame ne pose pas de problème, il faut pouvoir assigner les étiquettes en fonction de leur destination dans le réseau de l'opérateur. Or, pour ce faire, il faut modifier le processus de signalisation et par conséquent les équipements du coeur de réseau.

Les routeurs de bordure doivent être capables de prendre en compte les spécificités d'IPv6 en particulier insérer l'étiquette MPLS en fonction de l'adresse IPv6 de destination. Par contre, il existe une possibilité de ne pas modifier les équipements du coeur de réseau en utilisant le protocole de routage iBGP. Le peering BGP est fait en utilisant IPv4 comme protocole de transport. Grâce aux extensions multi-protocole de BGP, il est possible de transporter des préfixes IPv6 et les étiquettes MPLS associées à ces préfixes. Le routeur de bordure en entrée du réseau peut donc associer le préfixe IPv6 et le champ Next Hop correspondant à l'adresse IPv4 du routeur ayant fait l'annonce iBGP (48).

Le protocole de routage interne et le protocole de distribution d'étiquette permettent de construire des chemins pour les préfixes IPv4 internes. Quand un routeur MPLS reçoit un paquet IPv6, il ajoute deux étiquettes :

• la première (L1 dans l'exemple figure Architecture d'un réseau MPLS) permet de joindre le routeur de sortie. Cette étiquette est déterminée à partir de la valeur du champ Next Hop associé au préfixe de l'adresse de destination du paquet.
• la seconde (L2) contient l'étiquette annoncée par iBGP correspondant au préfixe IPv6.

IV/ Déploiement IPv6 des fournisseurs d'accès (ISP)

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

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

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

= V/ Accès des entreprises et des particuliers à l'Internet IPv6 +

ISATAP

ISATAP (qui se prononce ice-a-tap) est en quelque sorte la déclinaison des principes de 6to4 à un réseau local, de façon à permettre un tunneling automatique et l'échanges de flux IPv6 entre terminaux double pile interconnectés via un réseau local IPv4 uniquement. ISATAP permet le déploiement de terminaux dual-stack et d'applications IPv6 sur une infrastructure locale IPv4, comme typiquement celle d'un réseau d'entreprise. ISATAP peut être déployé de plusieurs façons : soit simplement au sein des terminaux concernés afin de leur permettre d'échanger des flux IPv6 alors qu'ils sont connectés sur une infrastructure IPv4, soit en combinaison avec des routeurs 6to4 de façon à échanger des flux IPv6 localement et avec des sites distants.

ISATAP s'appuie sur un format d'adresse spécifique décrit ci-dessous, qui intègre dans la partie identifiant de terminal l'adresse IPv4 du terminal et donc la fonction d'encapsulation/désencapsulation associée.

ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) [Templin-id] permet de connecter des équipements terminaux IPv6 isolés dans un réseau IPv4, en gérant de manière automatique l'encapsulation des paquets IPv6 dans des paquets IPv4. Contrairement à 6to4, cette technique s'applique à l'intérieur d'un domaine.

ISATAP repose sur une particularité de construction des identifiants d'interface proposée par l'IEEE. La figure Identifiant d'interface pour ISATAP montre comment un identifiant d'interface est construit à partir d'une adresse MAC en ajoutant la valeur 0xFFFE. Or l'IEEE a prévu qu'un identifiant d'interface pouvait contenir une adresse IPv4, la valeur insérée étant alors 0xFE, comme le montre la figure . La partie sur trois octets indiquant le constructeur prend la valeur de l'OUI (Organisational Unit identifier) attribué à l'IANA, c'est-à-dire 00-00-5E.

Quand un routeur mettant en oeuvre ISATAP reçoit un paquet IPv6 dont l'identifiant d'interface commence par la séquence 00-00-5E-FE, il en déduit que le paquet est destiné à une machine isolée et encapsule le paquet IPv6 dans un paquet IPv4 dont l'adresse de destination est celle contenue dans la partie identifiant d'interface.

L'intérêt de cette méthode est de respecter la structure actuelle des adresses IPv6 actuellement en vigueur puisque l'identifiant d'interface a toujours une longueur de 64 octets. Les stations isolées appartiennent au même lien IPv6 et partagent en conséquence le même préfixe IPv6. Mais pour construire complètement l'adresse, il faut pouvoir connaître les préfixes utilisés. Le réseau IPv4 servant à connecter les équipements IPv6 isolés est un réseau NBMA (Non Broadcast Multiple Access). Neighbor Discovery possède un mode adapté pour ce type de réseaux : les routeurs ne peuvent donc pas émettre de messages Router Advertisement de manière spontanée. Ces messages ne seront émis qu'en réponse à des Router Sollication.

L'algorithme de configuration d'un équipement isolé qui utilise ISATAP est le suivant :

• dans un premier temps, l'équipement doit connaître l'adresse IPv4 du routeur gérant ISATAP. Cette adresse pourrait être apprise par le DNS, ou en utilisant une adresse anycast IPv4 pour joindre le routeur le plus proche.
• l'équipement envoie un message IPv6 Router Sollicitation au routeur en utilisant comme adresse de la source, son adresse lien-local (fe80::5e:fe:IPv4) et comme adresse de destination l'adresse de multicast des routeurs (FF02::02). Ce message est encapsulé dans un paquet IPv4 dont l'adresse destination est l'adresse IPv4 du routeur.
• le routeur répond au message IPv6 Router Sollicitation en renvoyant en point-à-point, toujours encapsulé dans un paquet IPv4, la liste des préfixes IPv6 utilisés pour joindre les équipements isolés (Router Advertisement).

Il est à noter que ISATAP est compatible avec 6to4. Le préfixe global peut contenir l'adresse IPv4 du routeur d'accès et la partie identifiant d'interface l'adresse IPv4 privée de l'équiment. Deux tunnels seront nécessaire (le premier entre le routeur 6to4 de la source et le routeur d'accès du site et le second entre le routeur d'accès et le destinataire). un équipement, même s'il ne possède qu'une adresse privée en IPv4, peut de cette manière disposer une adresse IPv6 globale. Malheureusement, cette solution ne peut pas être déployée quand le routeur d'accès n'est pas configuré pour le protocole IPv6, cas généralement rencontré dans les réseaux ADSL.

TEREDO

Le principal objectif de Teredo (RFC 4380) est de fournir automatiquement une connectivité IPv6 à un terminal situé derrière un NAT et ne disposant donc pas d'une adresse IPv4 globale. Ce mécanisme de type client/serveur s'appuie sur des serveurs et des relais de façon à optimiser le chemin parcouru par les paquets IPv6 encapsulés qui transiteront via le relais le plus "proche" en non plus sytématiquement par un point unique comme avec le mécanisme de Tunnel Broker. Cependant, l'optimisation du chemin parcouru par les paquets IPv6 encapsulés conduit à une certaine complexité dans les échanges client/serveur/relais, en particulier lors de chaque phase d'initialisation d'une communication. Teredo est un outil de dernier recours, destiné à être utilisé en l'absence de connectivité IPv6 native, ou de tunnel configuré, ou de la mise oeuvre de 6to4. Ce mécanisme concerne exclusivement des terminaux individuels ne disposant pas d'une adresse IPv4 publique ; il ne s'applique pas à des sous-réseaux.

Teredo s'appuie sur un format d'adresse particulier (cf. figure Format des adresse Teredo) qui intègre dans la partie préfixe l'adresse IPv4 du serveur Teredo, et dans la partie identifiant les adresse et numéro de port (en sortie de NAT) du terminal client Teredo. Cette dernière infomation est brouillée afin de ne pas être modifiée par certains NAT qui systématiquement modifient les séquences binaires ressemblant à une adresse.

L'objectif de Teredo est de rendre entièrement automatique la configuration de tunnels IPv6-dans-IPv4 pour des terminaux situés derrière un ou plusieurs NAT, et utilisant par conséquent des adresses IPv4 privées. Pour cela, Teredo met en ?uvre une encapsulation UDP. Teredo s'appuie sur un serveur et des relais externes au réseau auquel est connecté le client Teredo, de façon à optimiser autant que possible le routage IPv6, en évitant un point d'encapsulation unique tel qu'on peut le rencontrer par exemple avec une solution de type tunnel broker. De plus, Teredo utilise un format d'adresse IPv6 spécifique qui ne requiert aucune allocation de la part des organismes officiels.

Le préfixe Teredo de longueur 64 bits inclus l'adresse du serveur Teredo auquel le terminal est rattaché. A la date d'édition de cet ouvrage le préfixe Teredo a la valeur 3FFE:831F::/32 mais l'IANA pourrait assigner une valeur définitive.

L'architecture globale et les différents éléments mise en oeuvre dans Teredo sont décrits figure architecture Teredo. Le but recherché est que chaque client Teredo soit rattaché au serveur Teredo le plus proche, et que le trafic IPv6 transite par le relais Teredo lui aussi le plus proche au sens routage IPv6.

Cependant, il existe plusieurs types de NAT, selon la politique de traduction adoptée (en particulier pour le port UDP), qui peuvent être classés selon deux grandes familles :

• celle des "cone NATs" (qui regroupe en fait trois type différents NAT) et
• celle des "symmetric NATs".
• Il est important de noter que Teredo tel qu'il est défini actuellement, ne peut pas fonctionner au travers d'un "symmetric NAT". En effet, contrairement aux "cone NATs", un "symmetric NAT" associe un couple adresse/port externe différent selon l'adresse et l'application destinatrices du datagramme, lors de la traduction de ce dernier. Ainsi, les caractéristiques du tunnel UDP d'un terminal Teredo ne sont pas globalement uniques, alors que le mécanisme d'initialisation et de maintien de contexte de Teredo requiert cette unicité.

Globalement le fonctionnement de Teredo est plutôt complexe puisqu'il nécessite la coopération de trois types de noeuds réseau (client, serveur et relais Teredo), afin de :

• de déterminer le type de NAT traversé et d'assigner une adresse IPv6 au client Teredo
• de maintenir ouvert dans le NAT, l"association entre adresse/port internes et adresse/port externes

La phase d'initialisation d'un client Teredo a en particulier pour but de déterminer le type de NAT derrière lequel se trouve le client Teredo. A l'issue de cette initialisation, et dès lors qu'aucun "symmetric NAT" n'est traversé, il est alors nécessaire de maintenir l'association ouverte dans le NAT, par l'envoi périodique d'un message spécifique vers le serveur Teredo qui a pour effet de ré-initialiser le time-out d'inactivité du NAT.

De plus, l'initialisation d'une communication IPv6 sera différente, d'une part selon le type de cone NAT traversé, et d'autre part selon la destination : client Teredo sur le même lien, client Teredo sur un site différent, terminal IPv6 externe.

L'initialisation typique d'une communication entre un client Teredo et un terminal uniquement IPv6, est illustrée dans l'exemple figure exemple d'initialisation d'une communication.

VI Mécanismes d'interopérabilité

Relais applicatifs

Les relais applicatifs ou ALG (Application Level Gateway) représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure Exemple de relais applicatif pour le courrier électronique) configurées pour accéder aux deux versions du protocole. Les équipements IPv6 émettent leur requête vers le relais applicatif qui interprète le contenu de la requête et la retransmet en IPv4.

Un ou plusieurs relais peuvent être installés en fonction des services rendus disponibles sur le réseau (par exemple serveur d'impression, serveur de messagerie, relais http, ...). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces relais.

L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les relais applicatifs, par exemple telnet. Mais comme la liste précédente l'indique, les ALG concernent des applications courantes qui représentent une partie importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.

Les relais applicatifs regroupent :

• les proxies et les caches web,
• les spoolers d'impression,
• les serveurs de courrier électronique,
• les serveurs DNS,
• ...

Configuration d'un relais applicatif pour le Web

Le listing suivant donne un extrait de la configuration d'un serveur apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.

#cat /usr/local/etc/apache/httpd.conf
#
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
<IfModule mod_proxy.c>
ProxyRequests On
<Directory proxy:*>
Order deny,allow
Allow from all
</Directory>
#
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server ver.;"Block" removes all outgoing Via: headers)
# Set to one of: Off | On | Full | Block
#
ProxyVia On
</IfModule>
# End of proxy directives.

SOCKS

Cette technique est aussi issue des solutions pour passer d'un adressage privé à un adressage public. SOCKS ajoute un "canal de signalisation" aux données transportées, ce qui permet de piloter à distance l'ouverture de connexion. En IPv4, cette technique permet d'utiliser un adressage privé en interne pour atteindre un relais SOCKS qui se trouve dans une zone démilitarisée. Le relais SOCKS se charge d'ouvrir une connexion normale avec l'équipement distant. Le relais SOCKS se plaçant dans le modèle architectural en dessous de l'application, il est relativement indépendant de celle-ci, il n'est pas nécessaire de recourir à différents types de relais. De plus, SOCKS permet aussi bien les communications entrantes que sortantes.

SOCKS s'applique à tout type de réseau, ainsi qu'à des réseaux utilisant l'adressage privé IPv4.

Le RFC 3089 étend ce mécanisme en permettant les deux versions du protocole IP. Quatre scénarios sont possibles, comme l'indique la figure suivante :

• les protocoles X et Y sont IPv4. On est dans le cadre d'une utilisation classique de SOCKS telle qu'elle est prévue dans le RFC 1928 initial pour permettre à des équipements utilisant un plan d'adressage privé d'accéder aux ressources de l'Internet et de contrôler l'accès au réseau.
• le protocole X est IPv4 et le protocole Y est IPv6. Ce scénario permet de v6fier une application ne connaissant qu'IPv4.
• le protocole X est IPv6 et le protocole Y est IPv4. Ce scénario permet à une application IPv6 d'accéder à des ressources uniquement disponibles en IPv4
• les protocoles X et Y sont IPv6. Vu la taille des adresses IPv6, il est peu probable qu'il y ait toujours un plan d'adressage privé, non routable sur l'Internet. L'utilisation de SOCKS dans ce cas serait surtout pour contrôler l'usage des ressources réseau.

Le RFC 3089 prévoit aussi l'enchaînement de plusieurs relais SOCKS.

La principale difficulté introduite par l'utilisation de SOCKS pour la transition provient de l'interrogation du DNS. Dans le cas du deuxième scénario, où X vaut 4 et Y vaut 6, l'application ne peut que manipuler des adresses IPv4. En particulier les appels aux serveurs DNS pour la résolution de nom ne portent que sur des Resource Records de type A.

Le RFC 1928 prévoit que dans la partie "signalisation", le nom de l'équipement distant peut être envoyé de trois manières différentes :

• une adresse IPv4,
• un nom de machine,
• une adresse IPv6.

Si l'application utilise un nom de machine (FQDN : Fully Qualified Domain Name), SOCKS intercepte l'appel procédural pour la résolution et retourne à l'application une fausse adresse IP prise dans un poule. Quand l'application ouvre une connexion en utilisant cette adresse, le nom de la machine distante peut être retrouvé et est envoyé au relais SOCKS qui pourra, si le DNS retourne un enregistrement AAAA, ouvrir la connexion en utilisant le protocole IPv6.

DSTM

L'objectif de DSTM (Dual Stack Transition Mechanism) est de donner une connectivité IPv4 temporaire à un terminal dual-stack connecté à un réseau uniquement IPv6. La connectivité IPv4 n'est disponible que le temps nécessaire à une communication avec un terminal distant qui ne possède qu'une pile IPv4. Dans le principe, DSTM est en quelque sorte la réciproque du Tunnel Broker.

En général DSTM est identifié comme un mécanisme intervenant en fin de période de cohabitation IPv4/IPv6, lorsque les réseaux IPv6 sont dévenus majoritaires. Dans ce cas, DSTM peut typiquement s'appliquer soit à un réseau d'entreprise, soit à un réseau d'ISP.

DSTM se place dans la situation où une partie d'un site est passée en IPv6, mais où certaines applications continuent à utiliser IPv4. DSTM utilise une interface spéciale DTI (Dynamic Tunneling Interface) qui permet l'encapsulation des paquets IPv4 dans des paquets IPv6. Du point de vue de l'application, ce mécanisme est relativement transparent, puisque l'interface DTI est considérée comme une interface réseau classique.

Un routeur particulier appelé TEP (Tunnel End Point) possédant la connectivité entre le monde IPv4 et le monde IPv6 effectue l'encapsulation et la désencapsulation des données.

Initialement, les interfaces sont actives, mais ne disposent pas d'adresses IPv4, l'attribution d'une adresse n'est faite que lorsqu'un premier paquet est routé vers l'interface DTI. Dans ce cas, une demande d'allocation est envoyée par la machine à un serveur et une adresse IPv4 est allouée pendant la durée d'utilisation de l'interface DTI. Les paquets IPv4 sont envoyés à un TEP dont l'adresse IPv6 est généralement obtenue en même temps que l'adresse IPv4 temporaire. Le TEP garde en mémoire la correspondance entre les adresses sources IPv4 et IPv6 des paquets qu'il reçoit. De cette manière quand le destinataire sur le réseau IPv4 répond, le TEP peut déterminer vers quel équipement il peut tunneler les paquets.

L'usage de DSTM permet de ne configurer que la pile IPv6 d'un équipement. La pile IPv4 est configurée à la demande en fonction des besoins applicatifs. Le travail de configuation, de routage et de supervision de l'administrateur est donc simplifié.

Le fait d'utiliser des tunnels facilite l'allocation des adresses IPv4, car celles-ci perdent leur fonction de localisation, elles doivent juste conserver leur propriété d'unicité, ce qui est relativement facile à garantir.

NAT-PT

Le principe reste identique à celui de NAT pour IPv4. Il s'agit ici de traduire les en-têtes des datagrammes IPv6 en en-têtes de datagrammes IPv4. NAT-PT permet le déploiement de réseaux uniquement IPv6 et offrir une « compatibilité » avec le monde IPv4. Les boitiers NAT-PT sont des routeurs réalisant la traduction des paquets IPv6 en paquets IPv4 et servant de proxy DNS. Les autres équipements du réseau (derrière le boitier NAT-PT) n'ont besoin de rien de spécial pour que ce mécanisme puisse être utilisé.

• NAT-PT permet de s'affranchir d'IPv4 tout en permettant de continuer à bénéficier des services qui lui sont encore associés. Ce mécanisme introduit apres la phase de mise en œuvre (qui n'est pas très simple) un réel allègement de la tâche de l'administrateur.
• Le mécanisme NAT-PT est en discussion dans le groupe v6ops de l'IETF pour être classé historique, son usage semble devoir être limité (voire confiné) à des situations qui ne peuvent être gérées autrement. Un document de travail inventorie les scénarios qui en ont « absolument » besoin et tente de proposer des mécanismes de remplacement.

Le principe de fonctionnement de NAT-PT pour passer d'une version à l'autre du protocole IP est le même que pour passer d'un adressage privé à une adressage public, avec également les mêmes limitations, par exemple, si les paquets transportent des adresses. Par contre, ce mécanisme offre une certaine transparence au niveau du réseau.

Les paquets émis vers un équipement uniquement IPv4 utilisent l'adresse IPv4 mappée. Par contre, l'adresse source est une des adresses IPv6 globale que possède la machine émettrice. Le préfixe des adresses IPv4 mappées est routé vers un boîtier de traduction. Ce dernier dispose d'un poule d'adresses IPv4 officielles. Quand une nouvelle session est initiée par une machine IPv6, le boîtier alloue à la nouvelle adresse IPv6, une adresse IPv4 du poule, et construit un paquet IPv4 en extrayant de l'adresse IPv4, l'adresse IPv4 mappée de destination.