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 [Huitéma-id] 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.