Dual-stack IPv4-IPv6

Cette solution, basée sur la RFC 4213, permet de faire cohabiter les deux technologies réseaux sur un même lien.

Elle consiste à installer IPv4 et IPv6 sur un même nœud (poste ou routeur) et à les activer et de les paramétrer. Cette étape d’activation et de paramétrage est essentielle car elle permet l’utilisation simultanée des deux technologies tant que le réseau n’est pas totalement passé à l’IPv6.

Choix du protocole de communication

Lorsqu’un équipement est en dual-stack, un mécanisme simple permet de déterminer s’il emploiera IPv4 ou IPv6 pour communiquer avec un autre équipement :

• Si l’adresse de destination spécifiée est en IPv6, alors la communication se fait en IPv6.
• Si l’adresse de destination spécifiée est en IPv4, alors la communication se fait en IPv4.

Dans le cas où ce sont des noms d’hôtes et non des adresses IP qui sont utilisés, cela dépend de la réponse du serveur DNS. Ce dernier, peut répondre soit avec une IPv4, avec une IPv6 ou encore avec les deux.

Dans le cas d’une double réponse, un mécanisme entre en œuvre (cf. RFC 3484). Le principe est simple : les équipements privilégieront toujours l’IPv6 à partir du moment où la portée des adresses IPv4 et IPv6 proposées ont la même portée.

La portée (« scope » en anglais) spécifie sur une adresse à une vocation purement locale (adresses link-local unicast), une vocation sur un réseau local (adresses unique local unicast) ou sur des réseaux étendus type Internet (adresses global unicast).

Si l’équipement devait choisir entre une adresse 188.73.10.2 et FE80::1, il choisirait l’adresse IPv4 car sa portée est supérieure à l’adresse IPv6 qui a, dans cet exemple, une portée purement locale.

Lorsque la portée des deux adresses est égale, le choix se basera sur notamment sur la longueur du préfixe ainsi que plusieurs autres paramètres (cf. RFC 3484).

Tunnels avec encapsulation dans IP – Protocole 41

Principes de l’encapsulation

Cette méthode est utilisée lorsque des équipements ou des sites en IPv6 sont obligés de communiquer ensembles par le biais d’un réseau en IPv4.

Pour que la communication soit effective, les paquets IPv6 vont être encapsulés dans des paquets IPv4 (cf. RFC 2473). Cette opération est effectuée directement sur la couche IP avec un identifiant de protocole 41 (ex: 6 étant pour TCP, 17 pour UDP ou encore 47 pour GRE).

La mise en tunnel étant considérée comme un franchissement de routeur, le paquet voit la valeur de son champ « Hop Limit » décrémentée de 1.

Un en-tête IPv4 est alors ajouté au paquet IPv6 pour permettre de l’acheminer en IPV4 d’un bout à l’autre du tunnel.

Une fois arrivé à l’autre extrémité du tunnel, l’opération inverse est effectuée et la partie ipv6 du paquet IPv4 est extraite.

Tunnel statique

Il s’agit de la méthode la plus basique avec un paramétrage de tous les éléments du tunnel sur les deux routeurs d’extrémités.

Le principe est que les routeurs sont tous les deux en IPv6 (voir en dual-stack) sur leurs interfaces internes et en IPv4 sur l’interface d’interconnexion.

Contraintes liées à la solution

• Les deux routeurs doivent supporter IPv4 et IPv6
• Les deux routeurs doivent avec une adresse IPv4 publique fixe
• L’encapsulation « rajoute » des octets et nécessite éventuellement de fragmenter les paquets IPv6 d’origine pour respecter la MTU d’origine
• Le mécanisme peut avoir des dysfonctionnements si des translations interviennent sur le chemin puisque nous sommes dans un mode de connexion sans notion de port
• Une configuration manuelle doit intervenir sur chacune des extrémités et pour chaque tunnel, ce qui augmente la charge d’administration

Tunnel Hôte – Routeur

Dans certains cas, c’est le poste client lui-même qui procède à la mise en place du tunnel avec l’extrémité distante.

Tunnel 6 to 4 (6to4)

Ce mécanisme permet de supprimer les contraintes liées à la configuration préalable des tunnels (cf. RFC 3056).

Le principe c’est que lorsqu’un site A veut communiquer avec un site B, une seule adresse IP publique de type IPv4 est nécessaire.

A partir de cette adresse, le mécanisme 6to4 va utiliser un préfixe IPv6 particulier qui va devenir le préfixe « officiel » du site A. Ce préfixe est un sous-ensemble du préfixe 2002::/16 réservé par l’IANA pour ce mécanisme.

Avantages et limitations

• La mise en place d’une interconnexion directe est simple et profite d’une route directe entre les deux correspondants, ce qui est plus efficace que de passer par un relais.
• Les adresses IPv6 obtenues peuvent être statiques uniquement si les adresses IPv4 des routeurs le sont également.
• Ce mécanisme permet d’interconnecter tout un site et non un seul client.
• La création d’un tunnel diminue le MTU et donc peut entraîner un risque de fragmentation des paquets d’origines.
• Si les relais sont utilisés, cela rend le système plus faillible aux attaques et aux pertes de performances si le relais utilisé n’est pas fiable.

ISATAP (Intra-Site Automatic Tunnel Protocol)

Ce protocole est essentiellement utilisé pour l’établissement de tunnels à l’intérieur d’un site. Il est destiné à relier des nœuds dual-stack aux travers d’un lien IPv4. L’encapsulation est effectuée avec le protocole 41.

L’identifiant d’interface utilisé pour ISATAP prend la forme suivante :

• Un préfixe réservé sur 3 octets : 00:00:5e si l’adresse IPv4 est de type privée et 02:00:5e si elle est de type publique.
• Une valeur arbitraire sur un octet : FE pour signaler que l’adresse IPv6 contient en réalité une adresse IPv4.
• 4 octets contenant l’adresse IPv4 publique ou privée.

Le protocole de couche 2 utilisé n’est pas Ethernet mais un lien local NBMA non-broadcast Multiple-Access (comme pour le 6rd) : le non-broadcast rend inopérant le multicast. Puisque le passage des paquets sur le réseau se fait intégralement en IPv4, le NDP n’est pas nécessaire pour la résolution des adresses MAC.

La RFC 5214 prévoit également un mécanisme de passerelle ISATAP pour communiquer avec le monde IPv6 extérieur. Un serveur DNS est utilisé pour gérer la découverte des routeurs ISATAP, ce qui ressemble à un viol des concepts fondamentaux de conception des réseaux, avec un étrange mélange des couches.

En fonctionnant ainsi en couche 2 et en n’ayant besoin d’aucune intervention sur les équipements réseaux (qui doivent tout de même autoriser le transport du protocole 41), ISATAP est un très bon moyen de virtualiser une connexion ad-hoc en IPv6, entre deux machines séparées par un réseau IPv4 qui supportent le protocole. Passé ce cas d’utilisation, les contraintes imposées et les moyens à déployer pour faire plus, le laissent sans avenir face au 6to4/6rd.

Avantages et limitations

• Le protocole est disponible sous Windows, Linux et Cisco
• Il nécessite que tous les postes IPv6 soient en dual-stack et disposent d’ISATAP, cette dernière condition est rarement remplie par les matériels de type imprimantes ou webcams
• Un routeur doté d’ISATAP est indispensable pour communiquer avec l’extérieur
• Les translations d’adresses (NAT) ne sont pas possibles

6rd (IPv6 Rapid Deployment)

Il s’agit d’une variante du 6to4 définie dans la RFC 5969 connue, notamment, pour avoir été implémentée sur le réseau de l’opérateur français FREE. Le nom « 6rd » vient du principe qu’il s’agit d’un moyen rapide afin de déployer une connectivité IPv6 sur une infrastructure encore massivement en IPv4. Le 6rd est essentiellement destiné aux opérateurs télécoms et aux sociétés possédant des réseaux complexes (à l’échelle nationale voir internationale).

Le format d’adresse est basé sur un préfixe 2000::/3 (à la place du préfixe 2002::/16 caractéristique du 6to4). Cette adresse est considérée comme une adresse IPv6 native ce qui lui permet de présenter les caractéristiques suivantes :

• Un préfixe délégué et créé en concaténant le préfixe 6rd (créé pour le client) et l’adresse IPv4
• Un numéro de sous-réseau
• L’identifiant d’interface

Avantages et limitations

Le 6rd est une application du 6to4, à ces différences près

• Les préfixes IPv6 utilisés sont issus des préfixes qui appartiennent au FAI, plutôt que des sous-ensembles du préfixe normalisé 2002::/16 du 6to4.
• Il est donc impossible de différencier du trafic sorti d’un réseau 6rd d’un trafic IPv6 natif.
• Il peut y avoir plusieurs préfixes IPv6 différents, chacun correspondant à un domaine 6rd.
• La taille du préfixe IPv6 est libre.
• La taille allouée à l’adresse IPv4 incorporée est libre aussi : si l’ensemble des adresses IPv4 du domaine peuvent être agrégées en un sous réseau, le préfixe de celui-ci n’a pas besoin d’être renseigné (par exemple, si toutes les adresses appartiennent à 10.0.0.0/8, seuls les 24 derniers bits sont utiles).

Ces différences ont fait le succès du 6rd

• En utilisant ses propres préfixes, le FAI contrôle tous les relais, ce qui annihile la plupart des défauts du 6to4.
• Les paquets encapsulés étiquetés protocole 41 ne sortent donc pas de l’infrastructure du FAI.
• Ainsi la MTU des paquets IPv4 peut être augmentée (ou celle des IPv6 diminuée) pour empêcher la fragmentation liée aux doubles entêtes.
• Les relais peuvent être joignables avec des adresses anycast propres au FAI (une par domaine 6rd), offrant ainsi des possibilités de redondance automatique.
• L’IANA a ajouté une option OPTION_6RD (section 7.1.1 de la RFC 5969) pour configurer automatiquement un routeur pour un domaine 6rd précis.
• Les routeurs des abonnés peuvent facilement ajouter un support 6to4 (avec des adresses supplémentaires qui utilisent le préfixe 6to4) qui sera utilisé pour contacter toutes les machines en 2002::/16 sans passer par les relais.

Contraintes à respecter

• La taille du préfixe IPv6 plus le nombre de bits nécessaires pour représenter l’IPv4 incluse ne doit pas dépasser 64 bits pour permettre l’autoconfiguration à partir des adresses MAC sur les réseaux des abonnés.
• À cause des adresses anycast utilisées pour les relais, les paquets IPv4 utilisant le protocole 41 ne doivent pas subir de fragmentation (il n’y a pas de garantie que deux relais partageant la même adresse anycast n’utilisent pas le même identifiant de fragmentation, ce qui entraînerait des recompositions hasardeuses).
• Il doit y avoir un domaine 6rd (donc un préfixe IPv6) interne si le FAI utilise du NAT en sortie.

Inconvénients

• Pour respecter la contrainte des 64 bits maximum, les préfixes IPv6 des domaines 6rd doivent être relativement petits, ce qui implique une consommation assez importante du préfixe total alloué au FAI (qui peut aussi nécessiter des préfixes pour de l’IPv6 natif).
• Comme pour le 6to4, les adresses IPv4 devraient être fixes pour faciliter la traçabilité.

L’abonné devra bénéficier d’une double pile pour pouvoir continuer à accéder à l’Internet IPv4. Du côté du FAI, cette solution lui permet de proposer une connectivité IPv6 à ses abonnés en un temps record, mais ne lui permet pas d’être prêt pour l’avenir : si un sniffer était placé entre le boîtier ADSL de l’abonné et la prise murale, il n’y verrait pas un seul paquet IPv6, puisque tout est encapsulé et que le réseau du FAI est resté entièrement en IPv4.

6rd et DHCP

La nouvelle option de DHCPv4 (option-code) OPTION_6rd permet d’ajouter les champs suivants aux annonces DHCP :

• IPv4MaskLen : Valeur entre 0 et 32 qui représente le nombre de bits de poids fort qui sont commun à toutes les IPv4 du domaine 6rd (donc la représentation des IPv4 dans les IPv6 se fera sur 32 – IPv4MaskLen bits).
• 6rdPrefixLen : Le préfixe IPv6 dédié au domaine 6rd annoncé (32 – IPv4MaskLen + 6rdPrefixLen doit donc être inférieur ou égal à 128 et idéalement à 64).
• 6rdBRIPv4Address : Une ou plusieurs adresses IPv4 (éventuellement anycast) qui permettent de contacter les relais pour le domaine 6rd.

Tunnels avec encapsulation dans UDP IPv4

Principe

Dans ce cas, l’IPv6 n’est pas encapsulé dans le protocole 41 sous IPv4 mais par le biais du protocole UDP. Cette utilisation possède l’avantage de traverser beaucoup plus facilement les équipements effectuant de la NAT.

TEREDO

Ce protocole est défini dans le RFC 4380. Ce protocole est implémenté sur beaucoup d’OS et est basé sur 3 composants :

• Un client Teredo sur un réseau connecté à Internet uniquement en IPv4
• Un serveur Teredo connecté au réseau Internet en IPv4
• Un relais Teredo qui est un serveur doté d’une connexion IPv4 pour accueillir les demandes de connexion en provenance des clients Teredo ainsi qu’une connexion native en IPv6

Cas de connexions

Connexion entre un client Teredo et un hôte nativement en IPv6

• Le poste doté du client Teredo est paramétré avec l’adresse IPv4 du serveur Teredo.
• Le serveur Teredo attribue à l’hôte une adresse IPv6 sous le préfixe 2001:0000::/32, cette adresse est calculée à partir de l’adresse IPv4 publique avec laquelle l’hôte arrive sur le serveur ainsi que le port UDP utilisé.
• Le client cherche un relais (ou ce relais est paramétré en statique sur le client) par une connexion sur l’adresse anycast.
• A partir de ce moment, le poste client peut bâtir un tunnel avec le relais et ainsi atteindre la destination en IPv6.

Connexion entre deux clients Teredo

Le mécanisme est simplifié car le relais Teredo n’est pas nécessaire.

• Les deux clients obtiennent leurs adresses IPv6 de la part du serveur Teredo comme dans l’exemple précédent.
• Ils établissent alors directement un tunnel entre eux.

Avantages et limitations

• Le protocole est disponible sous Windows (client natif sous Windows à partir de la version XP), Linux, Mac OS X, BSD.
• Il permet de fonctionner à travers des NAT (excepté pour la NAT symétrique).
• Le recours éventuel aux relais fait peser une charge importante sur ceux-ci et rend le dispositif sensible à une panne éventuelle de ces derniers.
• L’adresse IPv6 attribuée au client est provisoire.
• Il n’est pas possible de connecter tout un réseau avec une seule connexion Teredo.
• Des attaques sont possibles au travers des tunnels ainsi créés.

Tunnels brokers

Les tunnels brokers (RFC 3053) proposent une approche différente, en utilisant un tunnel IPv4 permanent, à l’instar d’un VPN. Une fois le client connecté au tunnel serveur, les échanges en IPv6 se font au travers de la nouvelle interface virtuelle, qui utilise le mode d’encapsulation qu’elle désire.

Pour enregistrer les nouveaux utilisateurs et leur donner accès aux tunnels serveurs, des nœuds connus de type broker sont utilisés. Ceux-ci seront éventuellement payants, et se chargeront en plus d’attribuer les adresses IPv6 (tirées d’un préfixe lui appartenant, formatées comme bon lui semble) et d’indiquer au client comment établir le tunnel avec le tunnel serveur indiqué. Les clients doivent donc posséder le logiciel spécifique au tunnel broker, qui lui permettra d’établir la liaison avec le tunnel serveur.

Cette solution très sécurisée (les tunnels peuvent être aussi chiffrés) nécessite plus de ressources que les autres, et n’est destinée qu’aux particuliers isolés.

Faire de l’IPv4 sur un réseau IPv6

Généralités

Toutes les solutions abordées ci-avant nécessitent une double pile pour faire cohabiter l’IPv4 et l’IPv6.

Cette section présente les solutions pour bénéficier d’un réseau entièrement IPv6 (comme dans un 6to4 sans IPv4), tout en laissant la possibilité aux usagers de contacter des machines restées en IPv4 (sans double pile). Cette façon de faire permet de réellement passer son réseau en IPv6, sans doubler sa charge de travail en conservant un double adressage avec un double jeu de règles pour le pare-feu, et sans encapsulation. Il s’agit donc aussi de la meilleure façon de se préparer pour l’avenir.

Ces solutions se basent sur un mécanisme de translation d’adresses.

NAT-PT et NATPT-PT

Ces deux technologies détaillées dans le RFC 2766, ont été rendues obsolètes par le RFC 4966 et ne doivent plus être employées. Elles ne seront pas conséquent plus supportées. Ces technologies sont remplacées par le NAT64.

NAT64/DNS64

Cette méthode permet à des postes en IPv6 de se connecter à des serveurs ou d’autres systèmes restés en IPv4 et ne possède pas encore de RFC dédié.

Le principe est le suivant :

• Le client tente de se connecter sur une adresse IPv6 correspondant à une adresse IPv6 virtuelle attribuée au serveur de destination (par le biais du DNS64).
• Le routeur ou le pare-feu reliant le réseau local du client à Internet IPv4 translate les en-têtes de paquets IP ou ICMP d’IPv6 en IPv4.
• Le routeur envoie les paquets à destination en utilisant comme adresse source sa propre adresse IPv4 (cas le plus général).
• Le serveur de destination répond en IPv4 à destination du routeur.
• Celui-ci décode la réponse et la remet au réseau IPv6 après avoir retranslaté les adresses en sens inverse.

Récapitulatif cohabitation IPv4-IPv6

Solution	Double pile	Lien IPv6	Encapsulation	Configuration	Transparent	IP natives	Universelle
6to4	Oui	Oui (relais)	Oui (41)	Réseau	Oui	Non	Oui
6rd	Oui	Oui	Oui (41)	Réseau	Oui	Oui	Oui
NAT64	Non	Oui/Non	Non	Réseau	Oui	Oui	Oui
ISATAP	Oui	Non	Oui (41)	Utilisateur	Non	Oui	Oui
Teredo	Oui	Oui (relais)	Oui (UDP)	Utilisateur	Oui (+NAT)	Non	Oui
Brokers	Non	Non	Oui (TCP)	Utilisateur	Non	Oui	Oui