Impression / IPv6 (7) : Déploiements – par le fournisseur d’accès (partie 2) / Nexcom

Au cours de la première partie, nous avions commencé à aborder les différentes options de déploiement IPv6 disponibles pour les opérateurs avec les méthodes de type hybride/tunneling. Dans le présent article, nous allons poursuivre cette étude en observant une approche quelque peu différente, puisque tentant ici de rationaliser l’usage des adresses IPv4 afin de limiter l’hémorragie et de pouvoir continuer à fournir un service IPv4 dans les années à venir tout en migrant progressivement vers IPv6.

Certaines de ces solutions, nous allons le voir, essaient de coupler l’aspect préservation avec l’aspect migration, mais il est souvent nécessaire de combiner ces approches avec d’autres protocoles de transition afin d’avoir et une solution de migration vers IPv6, et une solution de préservation d’adresses IPv4

L’approche compressive (mapping)

Lorsque les premiers signes d’une potentielle pénurie d’adresses IPv4 sont apparus au début des années 1990, une majorité du monde des nouvelles technologies imaginait, naïvement, que la migration vers IPv6 serait progressivement engagée par les différents acteurs de l’industrie. En effet, ceux-ci auraient pu investir progressivement dans ces nouvelles technologies, que ce soit par souci d’assurer le futur du protocole (et par conséquent, le futur de leurs services) ou par intérêt compétitif. Cette approche aurait dû permettre un déploiement d’IPv6 avant même qu’il soit question d’assigner la dernière adresse IPv4.

Mais rien ne s’est déroulé comme escompté : les fournisseurs d’accès ont continués à distribuer massivement les adresses IPv4, sans se soucier d’un quelconque risque de pénurie, ce qui entraîne désormais une charge supplémentaire à l’heure où la migration à IPv6 devient impossible à éviter. En effet, il faut désormais prévoir non plus seulement la migration (ce dont nous avons discuté jusqu’à maintenant), mais aussi assurer la continuité du service alors que les adresses IPv4 sont toutes utilisées et qu’IPv6 est toujours loin, très loin d’être déployé – des données de 2010 estiment que seuls 8% de l’ensemble du réseau dispose d’une connectivité IPv6.

Que ce soit les méthodes hybrides vues précédemment ou les solutions accessibles aux clients, chacune nécessite une connectivité IPv4 afin de pouvoir fonctionner. Il devient dès lors essentiel de prévoir des solutions permettant d’étendre encore un peu la survie d’IPv4 au sein du réseau. A noter que nous ne faisons pas ici de jugement sur qui serait éventuellement responsable de la situation actuelle : chaque partie de cet environnement complexe, du fournisseur d’accès au client en passant par les intégrateurs et les entreprises, ont leur part de responsabilité dans le chaos actuel, avec des cercles vicieux retardant toujours plus la prise de décision (par exemple, le client ne passe pas à IPv6 car son fournisseur d’accès ne propose pas ce service sur son réseau, fournisseur qui ne propose pas ce service car aucune demande réelle n’existe, etc.).

Carrier Grade NATs (CGN)

La première des solutions consiste à utiliser more of the same : les NAT ont permis de maintenir IPv4 pendant près de 20 ans, pourquoi ne pourrait-on pas rajouter un niveau au sein du réseau afin de limiter encore l’utilisation des adresses IPv4. Cette approche propose par conséquent d’ajouter un NAT non plus au niveau du CPE, mais au cœur même du réseau de l’opérateur. Si les NAT « classiques » sont parfois connus sous le nom de NAT44 (4to4, soit deux réseaux IPv4 séparé par un NAT), les CGN peuvent être nommées dans un style similaire comme étant des NAT444 (4to4to4, soit trois réseaux IPv4 distinct, séparés par des NAT).

Du point de vue du client derrières le CPE, rien ne change réellement : une requête doit originellement émaner du client afin de créer les associations nécessaires au niveau de son NAT, mais aussi du CGN. De ce fait, et cela représente un avantage conséquent aux yeux de certains opérateurs, il n’est pas nécessaire de mettre à jour les CPE.

A l’heure actuelle, le réseau des opérateurs partageraient les mêmes adresses privées que le réseau des clients (selon RFC 1918). Le fait de partager cet espace d’adresse peut poser des problèmes de routage si par exemple l’opérateur et le site de terminaison partage la même plage d’adresse (10.0.0.0 /8 par exemple). Une nouvelle spécification est actuellement discutée afin d’assigner une plage d’adresse IPv4 spécifiquement pour les réseaux derrières des CGNs.

Les CGNs sont par ailleurs confrontés à d’autres problèmes opérationnels majeurs pouvant entacher leur fonctionnement. Puisque ces équipements partagent le même comportement que des NAT classiques intégrés aux CPE, ils partagent aussi leurs limitations :

Il est impossible de migrer le trafic d’une application d’un CGN à l’autre sans interrompre la session (ce qui peut être dramatique dans le cadre par exemple de communications en temps réel).
Un terminal vérolé peut engendrer d’autres problèmes, en générant par exemple des requêtes vers de très nombreuses destinations, consommant rapidement la plage de ports disponible au niveau du CGN. Seuls des mécanismes limitant le nombre d’association par source pourrait canaliser ce type de comportement.
Il n’y a aucune garantie que les durées d’association soient cohérentes entre le CGN et les NAT, pouvant dès lors porter préjudice aux différentes applications si une association n’est pas renouvelée à temps. Ce double niveau de NAT rend ce problème encore plus présent, tout en étant plus complexe à diagnostiquer.

D’autres interrogations se posent dans le cas des CGN, notamment liées à l’évolutivité de la solution lorsque de nombreux utilisateurs sont connectés simultanément. En effet, se comportant comme des NAT traditionnels, un CGN ne dispose « que » de 65535 ports disponibles au maximum. Dès lors, il convient de limiter autant que possible le nombre d’utilisateurs – éviter que des millions d’utilisateurs tentent d’utiliser le même CGN simultanément – dépendant d’un même CGN en créant un plan d’adressage plus restreint, évitant de saturer le NAT de requêtes simultanées. Ces « sous-réseaux » du fournisseur d’accès sont par la suite raccordés par un réseau de transit traditionnel.

Ces divers problèmes, et en particulier celui lié à l’adressage du réseau CGN, diminue l’utilité que cette solution pourrait avoir afin de maintenir IPv4 à flot pendant quelques temps. Malheureusement, cette approche a une contrepartie vicieuse aussi, la même qu’on eut les NAT à leur époque : si elle s’avère efficace et rentable pour les fournisseurs d’accès, il y a à nouveau le risque que le déploiement IPv6 soit retardé une fois de plus.

L’approche A+P

Nous avons rappelé ci-dessus que les NAT engendrent de nombreux problèmes, et que nos réseaux se porteraient sensiblement mieux sans ces équipements, qu’ils soient sur un niveau (NAT classiques), ou pire encore sur deux ou plus (NAT et CGNs). Une question a été soulevée en rapport avec l’approche du NAT444 : serait-il possible de trouver une solution qui permettrait de fusionner le NAT et le CGN, en partageant dès lors une adresse IPv4 avec de multiples sites de terminaison ? Une telle solution a été imaginée et est décrite dans la RFC expérimentale 6346.

Sans entrer dans les détails de ses mécanismes, cette spécification propose d’utiliser une adresse IPv4 publique pour de multiples sites différents en opérant une distinction non plus au niveau des adresses uniquement, mais aussi au niveau des ports, d’où son nom Address plus Port. Un port est codé sur un maximum de 16 bits, permettant d’allouer 65536 ports différents pour une unique adresse. Ici, cette plage de port serait subdivisée en plus petites parts, par exemple de 14 bits au lieu de 16, permettant effectivement de créer 4 blocs séparés utilisant chacun la même adresse IPv4, mais sur des ports différents.

La fonction du NAT est pratiquement inchangée : son adresse IPv4 publique lui est attribuée dynamiquement. La principale différence à ce niveau concerne le fait qu’une plage de ports lui est aussi attribuée, ce qui nécessite une mise à jour des NAT. Il ne pourra par la suite pas utiliser d’autres ports que ceux qui lui auront été assignés.

Il est nécessaire, pour que cette approche fonctionne correctement, en particulier pour tout trafic entrant, qu’un équipement soit en mesure de redistribuer les requêtes non plus seulement en fonction de l’adresse, mais aussi des plages de ports. Cet équipement, connu sous le nom de passerelle A+P (A+P Gateway) doit par conséquent être fourni par l’opérateur, et est placé en marge de son réseau afin d’intercepter et transférer le trafic correctement entre les CPE et le reste du réseau. La communication entre le CPE et la va essentiellement dépendre de la version d’IP utilisée sur le réseau du fournisseur d’accès.

Sur un réseau IPv4 ou dual-stack, le problème ne se pose pas, les requêtes peuvent transiter directement.
Sur un réseau IPv6, il devient nécessaire d’encapsuler la requête IPv4 au sein d’IPv6 (4in6 et non plus 6in4) avant de la transmettre.

Il devient par conséquent possible de garder ici la même approche sur un réseau IPv4 qu’IPv6, rendant cette solution durable dans le temps. Toutefois, l’utilisation des ports dans le cadre d’un partage d’adresse s’avère particulière peu optimisé puisqu’une plage de ports allouée à un client devient immédiatement inutilisable pour les autres. La distribution de ces plages dépend donc d’une décision subjective d’allouer par exemple 1024 ports par site, basé sur des estimations hasardeuses d’utilisation et ne représentant peut-être pas les besoins de tous les clients. Que ce soit les CGN ou DS-Lite ci-après, aucune de ces deux méthodes ne s’avère aussi contraignante à l’usage en proposant une allocation dynamique.

Il est intéressant de noter aussi que cette approche peut rapidement s’avérer relativement coûteuse, tant pour les clients, qui devra avoir un CPE compatible avec ce principe d’allocation de ports, que de l’opérateur qui devra s’équiper en conséquence pour pouvoir fournir ce service. Il n’y a dès lors que peu de chances que cette méthode soit retenue par beaucoup de fournisseurs d’accès de par le monde.

Dual-Stack Lite

Les mécanismes proposés par DS-Lite, petit nom donné au protocole, reposent sur une approche légèrement différentes de ce que nous avons pu voir jusqu’à maintenant. Alors qu’une majorité des solutions se focalisent sur le déploiement d’IPv6, DS-Lite permet d’envisager l’inverse : maintenir IPv4 sur des réseaux purs IPv6.

DS-Lite requière donc un réseau IPv6 déployé et fonctionnel. Par réseau IPv6, il n’est ici pas question d’un réseau dual-stack, mais bien d’un réseau single stack IPv6. Le protocole va permettre de faire transiter de l’IPv4 sur ce réseau en appliquant la même technique qui ressort majoritairement : le tunneling, à la différence que cette encapsulation va être ici inversée : en lieu et place d’IPv6 encapsulé dans de l’IPv4 (utilisé au sein de 6rd notamment), nous avons ici de l’IPv4 encapsulé dans de l’IPv6 (sous-protocole 4 IP-in-IP).

Dans une configuration de ce type, la fonction de NAT est gérée non plus par le CPE, mais par le fournisseur d’accès directement. Les sites de terminaison restent dans une configuration dual-stack, utilisant des adresses IPv4 privées, qui sont transmises dans des tunnels IPv6 vers le CGN de l’opérateur qui opérera la traduction vers le réseau IPv4. Cette approche offre de grandes similarités avec les CGN classiques puisque la différence majeure ici se situe dans le protocole utilisé par l’opérateur (IPv6 en lieu et place d’IPv4).

Le protocole se repose sur une association complexe au niveau du NAT. Un NAT traditionnel se repose sur les informations d’adresse IPv4, de port et de protocole « interne » d’un côté, et les mêmes informations du côté « externe » (public). D’une manière similaire, le CGN DS-Lite va réutiliser les mêmes informations, mais puisque ces informations traversent un réseau IPv6, leur usage se trouve renforcé via l’ajout de l’adresse IPv6 de la passerelle du client, soit le préfixe qui lui a été fourni. Grâce à cette information supplémentaire, identifiant effectivement chaque tunnel de manière unique, il devient possible pour les clients d’utiliser de manière concurrente des plages IPv4 identiques (par exemple 10.0.0.0 /8) sans que cela ne pose de problème au CGN.

Grâce à toutes ces informations, le CGN est en mesure d’effectuer une traduction d’adresse IPv4 vers IPv4 de manière transparente pour l’utilisateur. De plus, il ne demeure qu’un unique NAT sur l’ensemble du réseau, ce qui évite les problèmes d’interfonctionnement entre le CGN et les NAT traditionnels. Toutefois, cette approche, si elle offre une solution bien réfléchie du problème, n’est pas épargnée par des problèmes et limitations.

En premier lieu, les CPE nécessitent d’être mis à jour afin de supporter de nouvelles fonctions. Ils doivent en effet être en mesure d’accepter des adresses IPv6 du côté « externe », tout en étant capable de créer le tunnel 4in6 nécessaire au bon fonctionnement du protocole. Le second problème tient au fait que ce type d’architecture est entaché par une faiblesse non négligeable, le CGN, qui représente un unique point d’échec (single point of failure ou SPOF) qui peut rapidement exclure toute une partie du réseau de connectivité IPv4. Quel que soit le problème rencontré par celui-ci, tout le réseau IPv4 se retrouve interrompu.

Il paraît incongru de placer un tel équipement, unique et faillible, au sein d’un réseau aussi efficace et solide. Pourtant, à l’heure actuelle, il semble difficile de s’en passer. Il n’en demeure pas moins qu’avec une redondance suffisante, l’interruption de service en cas de panne ou d’échec de l’équipement peut être rapidement compensée.

Les déploiements IPv6 ne vont pas se faire sans devoir accorder des compromis : en l’état actuel, il semble désormais impossible de proposer une infrastructure offrant son plein potentiel lorsque des protocoles similaires mais suffisamment disparates doivent réussir à cohabiter. Cette notion de cohabitation va devenir le principal sujet de notre prochain et dernier article relatif aux options de déploiement proposées aux fournisseurs d’accès, au travers de solution translative, qui vont tenter de faire vivre les deux versions d’IP côte à côte.