Après avoir traité des approches hybrides (tunneling) puis compressives (mapping), ce dernier article va discuter du dernier type de options actuellement disponibles, sous la forme de solutions translatives allant faire la traduction entre les deux versions du protocole IP (protocol translation).

L’approche translative (protocol translation)

Les solutions se reposant sur cette approche vont, de manière similaire à ce que font les protocoles compressifs, utiliser un équipement similaire à un NAT (Network Address Translator) afin de fournir, dans le cas présent, une traduction entre IPv4 et IPv6.

La solution initiale se repose sur un constat relativement simple : en dépit des différences existant entre IPv4 et IPv6, il n’y a pas de changement fondamental entre les deux versions. Il est par conséquent possible de faire correspondre un paquet IPv6 avec un paquet IPv4 et inversement. Cette correspondance est possible en intégrant l’adresse IPv4 en fin du préfixe IPv6 spécifique ::FFFF:0:0 /96. Toutefois, cette méthode suppose que :

  • Les hôtes IPv6 dispose d’une vision totale sur le réseau IPv4.
  • Ils disposent chacun d’une adresse IPv4 publique (afin de pouvoir émettre leur requête).

NAT-PT (NAT-Protocol Translation) permet de s’affranchir de cette contrainte en utilisant une fonction similaire aux NAT traditionnels, mais appliqué à un changement de protocole. Cette méthode se repose non seulement sur une fonction de NAT, mais aussi sur un serveur DNS particulier, capable de renvoyer des enregistrements A (IPv4) à un hôte IPv6 en traduisant l’adresse IPv4 dans un format compréhensible : 

L’hôte IPv6, sur réception de cette réponse DNS, va être en mesure de transmettre sa requête vers la bonne destination, le NAT-PT, qui à son tour va pouvoir utiliser les informations connues localement (son adresse IPv4 publique, ainsi que l’adresse IPv4 de la destination), afin de transmettre la requête vers la bonne destination. De la même manière qu’un NAT traditionnel, et avec pour objectif de pouvoir acheminer les réponses correctement vers l’origine, un port est attribué pour chaque requête sortante.

Cette spécification a été classée historique en 2007, car il a été estimé à raison par l’IETF que beaucoup d’application auraient leur fonctionnement altéré au travers d’un tel environnement. La décision suit une logique simple : l’erreur a déjà été faite d’insérer les NAT au sein du réseau, et on en paie le prix à l’heure actuelle : évitons dès lors de refaire cette même erreur ici. Toutefois, cette réaction de l’IETF semble quelque peu exagérée puisque le NAT-PT n’est en aucun cas différent des NAT classiques et partage exactement les mêmes problèmes et limitations.

De plus, la situation actuelle ne pourra pas se résoudre efficacement sans compromis, et l’approche proposée par NAT-PT en est une parfaitement valide et efficace. C’est donc sans surprise que cette spécification a été remise au goût du jour récemment, sous un nouveau nom, NAT64 (pour le NAT) et DNS64 (pour le … serveur DNS modifié). Les mécanismes décrits sont en tous points similaires à ce que NAT-PT décrivait.

Il est intéressant de noter les similitudes existant entre cette approche et les Carrier Grade NATs (CGNs), qui proposent tous deux de partager une adresse IPv4 entre de multiples clients, mais qui ont par conséquent tous deux aussi les mêmes limitations et problèmes. L’avantage de NAT-PT/NAT64 sur les CGNs est de ne propose qu’un unique niveau de NAT au lieu de deux dans un réseau CGN/NAT444.

IVI

L’approche translative de NAT-PT affiche les mêmes problèmes qu’un NAT traditionnel, et sa nouvelle version (NAT64/DNS64) ne change au final pas grand-chose à la donne. Par rapport aux remarques effectuées par l’IETF dans la RFC 4966, de nouvelles réflexions ont été initiées, étudiant les différents cas de figure pouvant survenir dans le cadre d’une approche translative. Formant un framework de transition IPv4-IPv6, ces différentes spécifications posent les bases d’un protocole translatif complet, IVI (IPv4-IPv6 en chiffres romains).

A l’origine imaginé par le réseau chinois pour l’éducation et la recherche (CERNET ou Chinese Education and Research NETwork), équivalent du réseau RENATER français, ce protocole définit une série de mécanismes relativement complexes permettant une translation transparente entre les deux versions d’IP. Cette approche se place en opposition à la vision dual-stack du réseau, partant du constat qu’une telle solution s’avère bien souvent très coûteuse à implémenter et à maintenir pour l’opérateur, qui lui préfère des réseaux plus traditionnels, ne fonctionnant que sur une seule version du protocole.

La cohabitation envisagée ici offre une vision du problème sensiblement différent de ce qui a pu être fait jusqu’à présent, au travers de mécanismes qui, bien que complexes, s’avèrent très intéressants. Très récente, et malgré l’implémentation effectuée par les universités chinoises, la documentation à ce sujet s’avère très difficile à appréhender, et manque parfois de certains détails importants. Nous allons ici tenter d’éclaircir les concepts fondamentaux entourant cette technologie.

Au regard de cette figure générale, il est difficile de distinguer les différences fondamentales existants entre NAT-PT et IVI. IVI se repose pourtant sur des concepts qui auraient dû faire partie intégrante de nos réseaux depuis longtemps. La différence fondamentale ici, ayant l’impact le plus conséquent sur l’ensemble de la structure, concerne l’utilisation qui est faite des adresses, tant IPv4 qu’IPv6. En effet, à l’heure actuelle, nos réseaux sont fragmentés. Il devient en effet impossible par exemple de tracer un paquet, au travers des adresses IP, de manière transparente d’un bout à l’autre de la connexion.

Par extension, si IVI se repose aussi sur un translator, celui-ci va majoritairement fonctionner de manière stateless (mais basculera en mode stateful, partageant une adresse IPv4 pour de multiples hôtes IPv6 dans certains cas), c’est-à-dire que la translation se fait toujours de manière dynamique, mais selon un algorithme spécifique créant une équivalence 1:1 entre les adresses IPv4 et IPv6. Ce type d’équivalence avait été abandonné avec IPv4 pour cause de pénurie, mais il devient ici, au sein d’IPv6, possible à nouveau de créer ce type d’association. En particulier, il devient possible, pour chaque fournisseur d’accès, de réserver une plage d’adresses IPv6 afin de pouvoir traduire les adresses IPv4 en 1:1 (il est très facile d’accueillir l’ensemble de la plage publique IPv4 au sein d’IPv6 !).

Cette méthode permet de créer une « image » du réseau IPv4 sur le réseau IPv6, permettant à ce dernier de contacter tout hôte IPv4 sans aucun problème (il aura l’impression de discuter avec un hôte IPv6). Dans le sens contraire toutefois, d’un hôte IPv4 vers une entité IPv6, la problématique est tout autre. Il est en effet impossible d’appliquer le même mécanisme que pour IPv6, mais en réservant une partie de la plage IPv4 allouée à l’opérateur, il devient possible de créer ici aussi des « images » d’hôtes et serveurs IPv6.

Cette approche est sensiblement plus limitée, et il est impossible d’accéder à l’ensemble du réseau IPv6 depuis le réseau IPv4. Toutefois, à l’heure actuelle, IVI propose une des approches les plus complètes au niveau de l’interopérabilité des deux versions d’IP. Dans le cadre de cette cohabitation v4-v6, il est impossible de disposer d’une méthode ne faisant aucun compromis à un niveau ou à un autre (fonctionnalité, évolutivité, efficacité, connectivité, …). L’approche faite ici permet une utilisation optimale des infrastructures existantes, notamment au niveau d’IPv6 vers lequel l’ensemble du réseau IPv4 pourra migrer progressivement sans que cela ne change quoi que ce soit pour les utilisateurs.

Bien évidemment, ce protocole ne pourrait fonctionner sans un adressage et certains services spécifiquement adaptés à ses besoins. Au niveau adressage tout d’abord, il convient de noter que, parce que des plages spécifiques sont réservées, il devient impossible de se reposer sur un adressage automatique en IPv6. Il est ici essentiel d’avoir un plan d’adressage strict, afin d’éviter que la plage d’adresse réservée pour IPv4 ne soit utilisée de manière involontaire. Dès lors, l’usage de DHCPv6 pour configurer l’ensemble du réseau est impératif.

La figure ci-dessus décrit la plage IPv6 réservée pour chaque opérateur pour être utilisé comme réseau miroir d’IPv4. Il est intéressant de remarquer que cette plage est immense, mais que, au regard de la quantité d’adresses IPv6 disponibles par opérateur (tournant généralement sur des préfixes de taille /32), la place prise par IPv4 est relativement négligeable.

Vient ensuite le problème de la transition en elle-même. Pouvoir passer de manière transparente entre les deux réseaux, il est nécessaire de pouvoir effectuer une résolution de nom efficace entre les réseaux. De ce fait, l’usage d’un serveur DNS proxy, capable d’effectuer les transformations nécessaires sur les requêtes, est essentiel. Son approche est similaire à DNS64, la différence que le formatage de la réponse ne contient pas l’adresse du prochain saut, mais l’adresse traduite selon l’algorithme IVI. De plus, il ne faut pas omettre le fait que, puisqu’un NAT est encore utilisé, certaines applications ne peuvent pas encore s’affranchir totalement des solutions de traversées de NAT.

Tout comme 6rd (au travers de l’opérateur Free), ce protocole offre un avantage de taille par rapport aux autres solutions : il dispose d’une implémentation fonctionnelle en situation réelle au sein d’un réseau conséquent (CERNET). Ce type de solution part généralement avec une bonne longueur d’avance sur les approches purement théoriques et expérimentales : leur applicabilité à un réseau réel les rend attractifs pour un fournisseur d’accès cherchant à définir comment aborder le problème. En effet, il n’y a dans ce cas pas de surprises au niveau du protocole : il fonctionne et a été testé par quelqu’un d’autre !

Conclusion

Il n’y a ici réellement pas de solution claire, utilisable dans tous les cas de figure. Chacune dispose d’avantages, mais aucune n’est parfaite ou représenterait un choix « par défaut » idéal. Cette réponse en demi-teinte est due en grande partie au retard pris dans le déploiement d’IPv6, qui se voit maintenant couplé au problème de la pénurie d’adresses IPv4.

Le seul véritable point qui ressort de nos deux articles relatifs aux types et méthodes de déploiement IPv6 est que les fournisseurs d’accès n’ont plus le choix, et ne vont plus être en mesure d’externaliser la gestion du problème comme cela avait été le cas avec les NAT traditionnels. Nous l’avons vu, les déploiements accessibles aux clients ne propose pas de solution réellement valide, et leur utilité se résume à du cas par cas. Seuls les déploiements opérateurs sont actuellement en mesure d’apporter une solution définitive au problème.

Toutes les solutions décrites au travers du présent article s’avèrent intéressantes, il convient maintenant aux fournisseurs d’accès de faire les choix techniques et économiques correspondant à leur infrastructure et besoins, en sachant qu’il va souvent être nécessaire de coupler ces différentes solutions entre elles afin d’obtenir l’architecture la plus cohérente et efficace possible sur le long terme.