Le risque de pénurie d’adresses IPv4 devient de plus en plus présent avec les mois qui s’écoulent. Des solutions temporaires avaient été apportées avec les NAT, mais il est désormais essentiel de préparer une migration la plus rapide possible vers IPv6 tout en devant gérer cette pénurie, ce qui ne facilite en rien le travail de transition IPv4-IPv6.

De (très) nombreuses solutions ont été imaginées et proposées ces dernières années afin de tenter d’apporter une solution efficace et (relativement) facile à mettre en œuvre afin d’assurer cette transition. Ce choix est une bonne nouvelle puisqu’il va permettre de choisir la méthode la plus appropriée au cas de figure considéré. Ce qui est malheureusement aussi une mauvaise nouvelle puisque cette débauche de solutions engendre un problème de taille : quelles sont les solutions optimales et pour quels cas de figure ?

Ces solutions peuvent être classées en deux écoles différentes : soit la transition est assurée majoritairement au niveau du client, soit cette transition est effectuée par le fournisseur d’accès. Nous commencerons par décrire les approches possibles au niveau des utilisateurs finaux (clients) avant d’aborder, dans un prochain article, les mécanismes offerts aux fournisseurs d’accès.

L’approche dual-stack

Si le fournisseur d’accès pour un client propose un réseau IPv4 et IPv6 simultanément, dit dual-stack, la méthode à utiliser est logique : le client se configurera en dual-stack lui aussi et bénéficiera d’une connectivité IPv4 et IPv6. Dans ce genre de cas de figure, idéal en pratique, le site de terminaison de l’utilisateur final reçoit un préfixe IPv6 dédié, dont la taille varie généralement entre un /48 et un /56, bien que des solutions existent et proposent des préfixes plus grands (/64). A l’aide de ce préfixe, le routeur frontalier du client (CPE ou Customer Premises Equipment) peut l’annoncer sur son réseau de manière à ce que les différents terminaux puissent se configurer selon la méthode choisie, généralement par configuration automatique, mais d’autres solutions existent [lien adressage IPv6].

Depuis IPv4, les CPE intègrent tous les mécanismes de NAT (Network Address Translation) afin de pouvoir partager une unique adresse IPv4 entre différents terminaux. Ces mécanismes servent généralement de fonction principale de sécurité sur ces équipements. Malheureusement, avec l’arrivée d’IPv6, les NAT vont perdre de leur utilité et cette sécurisation va bien souvent disparaître avec eux, ce qui pose un problème de taille puisque le CPE doit dès lors intégrer des fonctionnalités additionnelles (firewall dédié notamment) afin de combler ce manque.

Toutefois, à l’heure actuelle, rares sont les fournisseurs d’accès à proposer cette approche dual-stack (bien souvent trop coûteuse) et bon nombre d’entre eux n’utilise que de l’IPv4 au niveau du réseau reliant les sites de terminaison. Pour cette raison, des solutions ont été développées permettant d’apporter une connectivité IPv6 à ces terminaisons. Ces solutions se reposent majoritairement sur des « tunnels », encapsulant les paquets IPv6 au sein de paquets IPv4 afin qu’ils puissent transiter sur le réseau legacy (IPv4).

Tunnels 6to4

Il existe diverses approches différentes à cette question de tunneling. La première, 6to4, offre en théorie une solution valide et cohérente sur le long terme. En effet, elle propose, à partir de l’hôte ou de sa passerelle directement, d’encapsuler les requêtes IPv6 au sein de paquets IPv4. La version la plus efficace initie ses tunnels à partir de la passerelle, évitant du même fait de devoir configurer chaque terminal pour créer des tunnels spécifiques à chaque fois. Toutefois, cette approche présuppose que le site de terminaison soit configuré en dual-stack.

L’approche faite par 6to4 part du principe que le site de terminaison souhaite apporter une connectivité IPv6 à son réseau interne sans pour autant disposer d’un préfixe IPv6 par le biais de son fournisseur d’accès. De ce fait, l’IANA a réservé une plage de préfixes IPv6 dans ce cadre spécifique, 2002:: /16, afin de palier à ce problème. Dès le moment qu’un site dispose d’une adresse IPv4 publique globalement unique, il lui est possible de se confectionner un préfixe IPv6 lui-même globalement unique en se basant sur cette information :

Si cette technique permet de communiquer avec d’autres sites IPv6, elle ne permettrait pas, sans un mécanisme additionnel, de « sortir » du réseau global IPv4 afin d’atteindre des destinations IPv6. Des relais ont été introduits afin de palier à ce manque et fournir ainsi une meilleure évolutivité de la solution. Ces relais, afin d’éviter de devoir connaître leur adresse IPv4 spécifique, sont accessible via l’adresse IPv4 anycast 192.88.99.1. La requête IPv6 est encapsulée dans un paquet IPv4 lorsqu’elle traverse la passerelle, et est décapsulée lors du passage par le relai. Au retour, le serveur de destination transmet sa requête vers l’adresse 2002:: /16 qui est traitée comme une adresse anycast, et qui tentera de joindre le relai le plus « proche » du point de vue du protocole de routage.

Cette approche, si elle semble intéressante et parfaitement fonctionnelle en théorie, présente des désavantages majeurs. En effet, elle présume de l’existence des relais afin d’apporter cette connectivité 6to4 de bout en bout, qui doivent, de préférence pour des performances optimales, être situées au plus proche du point de terminaison, à l’allé, comme au retour. Puisque ce cheminement peut être différent, il n’est par conséquent exclu qu’il existe des black holes (trous noirs) dans les connexions, une requête pouvant atteindre sa destination sans jamais pouvoir recevoir de réponse (échec de routage, pas de relai connu, …).

Ces problèmes de connexions peuvent survenir car ces relais ne sont pas gérés par, par exemple, le fournisseur d’accès, mais sont des entités publiques en charge d’opérer cette transition. Leur disponibilité est donc sujette à fluctuations, rendant l’usage du protocole 6to4 difficile, voire impossible à grande échelle. De plus, l’usage de firewalls peut perturber, voire interrompre, le bon fonctionnement du protocole, seuls TCP et UDP étant généralement acceptés (6to4 se reposant sur le sous-protocole IP 41 correspondant à IPv6).

La RFC 4213 définit la dernière version du protocole 41, qui permet, à l’origine, de créer manuellement des tunnels IPv4 faisant transiter de l’IPv6. Cette approche, connue sous le nom 6in4 n’offre toutefois pas les mêmes fonctionnalités que 6to4. S’il permet de connecter des sites IPv6 ou dual-stack entre eux au travers d’un réseau IPv4, 6in4 s’avère incapable d’offrir une connectivité IPv6 globale. Sa configuration manuelle l’exclut également d’un déploiement à grande échelle, ce qui n’est pas le cas de sa déclinaison 6to4.

Teredo

Comme mentionné précédemment, 6to4 ne fonctionne de manière optimale que s’il émane de la passerelle et non de l’hôte. Toutefois, il est fort probable que bon nombre de passerelles actuelles faisant du NAT dans le cadre d’IPv4 ne soient pas en mesure de supporter le protocole 6to4. Dans ce cas de figure, la partie n’est pas terminée pour autant : le protocole Teredo tente d’apporter une solution permettant à des hôtes dans cette situation de pouvoir profiter tout de même d’une connectivité IPv6.

Au contraire de 6to4, Teredo ne propose donc qu’une gestion de la connectivité IPv6 au niveau des hôtes, individuellement, et ne peut pas être mis en place au niveau d’une passerelle. De ce fait, le protocole porte une attention toute particulière aux problèmes liés aux NAT. Les restrictions que ceux-ci, dans leur comportement, imposent au trafic, peut impliquer que seuls certains protocoles, et plus particulièrement TCP (protocole 6) et UDP (protocole 17). Si le NAT n’est pas en mesure de supporter 6to4, il y a peu de chances que le protocole associé (41, pour IPv6) soit également supporté. Dès lors, Teredo encapsule les requêtes IPv6 non pas dans un paquet IPv4 directement, comme le ferait 6to4, mais dans un datagramme UDP dans un paquet IPv4.

Une infrastructure Teredo complète se repose sur quatre entités différentes :

  • Le client, qui souhaite obtenir une connectivité IPv6 sur son réseau IPv4.
  • Un serveur, servant à établir la session entre le client et son destinataire.
  • Un relai, qui va être en charge de traduire toutes les communications de la session.
  • Le destinataire, fonctionnant uniquement en IPv6.

Afin de pouvoir communiquer correctement, un adressage particulier a été prévu. En effet, alors que 6to4 prévoyait un préfixe spécifique pour ses sites, Teredo, puisque la requête transite par une infrastructure de relai, va créer une adresse IPv6 globale contenant de nombreuses informations nécessaires au bon fonctionnement du protocole.

Les informations contenues dans cette adresse permettent de noter un point particulièrement important : le comportement du protocole va différer selon le type de NAT rencontré. Cette distinction va être gérée par le serveur Teredo afin de savoir comment transmettre la réponse au travers du NAT à l’initialisation de session faite par le client. Toutefois, le fonctionnement global reste similaire dans les deux cas.

Le client contact en effet, à l’aide de cette adresse, le serveur Teredo avec un ICMPv6. Le serveur transmet cette requête au destinataire, qui répond, par les informations fournies par le serveur, au travers du relai. La gestion du NAT intervient ici, puisqu’en cas de NAT restrictif (dépendant de l’adresse et éventuellement du port de destination), seul le serveur Teredo est en mesure de transmettre la réponse au client. Lorsque les informations ont été transmises correctement au client, celui-ci peut initier une connexion au travers du NAT pour le relai Teredo, permettant du même fait de pouvoir envoyer et recevoir les données via le relai directement.

En théorie, et malgré le fait que cette approche soit relativement lourde d’un point de vue architectural, ce protocole offre une solution parfaitement valable pour proposer une connectivité IPv6 à un hôte en particulier. Etant toutefois limité à un hôte, le déploiement à grande échelle de cette approche est à proscrire : trop complexe, peut efficace sur le long terme, … Elle est de plus entachée de problèmes relatifs à son environnement, puisque les firewalls et les NAT peuvent compromettre et restreindre le trafic ICMP, rendant dès lors ce protocole inutilisable.

Cette solution demeure donc une possibilité valide, mais dépendante d’un certain nombre de contraintes la réservant à des cas très particuliers. De plus, elle n’a jamais été pensée (et son auteur l’admet volontiers, cf. RFC 4380, section 3.2), comme une solution sur le long terme, et représente une approche temporaire au problème, dans le but de faciliter, dans certains cas, l’utilisation de ressources IPv6 pour certains hôtes.

En dépit de leurs avantages respectifs, les déploiements vus dans cet article présentent tous deux des inconvénients les maintenant dans un marché de niche. Les solutions qu’un site de terminaison est en mesure d’apporter sont limitées, et seuls les fournisseurs d’accès possèdent désormais les clés nécessaires à la migration rapide et efficace des réseaux en IPv6, comme nous le verrons ultérieurement dans un prochain article.