Transition d'IPv4 vers IPv6

Les adresses IPv4 et IPv6 ne sont pas compatibles, la communication entre un hôte ne disposant que d'adresses IPv6 et un hôte ne disposant que d'adresses IPv4 constitue donc un problème.

Deux approches sont possibles pour permettre la communication :

• les traducteurs de protocoles,
• la double pile.

La traduction de protocole peut avoir lieu à plusieurs niveaux : réseau (NAT-PT, NAT64), transport (TRT, RFC 3142) ou applicatif (DNS-ALG, RFC 2766). Si elle peut servir à procurer la connectivité pour un nombre d'hôte ou d'applications limitées, la traduction se heurte à des problèmes d'échelle (RFC 4966).

Dans l'approche double pile, la première phase de la transition consiste à doter les hôtes IPv4, et les serveurs en particulier, à la fois d'adresses IPv6 et IPv4 de façon à leur permettre de communiquer aussi bien avec les hôtes IPv4 et IPv6. Les îles IPv6 sont interconnectées par des tunnels IPv6 sur IPv4.

La seconde phase voit se généraliser la double pile à la plus grande partie d'Internet. Le recours à des tunnels IPv6 sur IPv4 est donc de moins en moins nécessaire.

Une dernière phase voit l'abandon progressif d'IPv4 sur Internet. Certains réseaux privés continuent à s'en servir, dans la mesure où la connectivité Internet ne leur est pas nécessaire.

La première phase de cette transition est en cours depuis le début du XXI^e siècle, le déploiement d'IPv6 étant plus lent qu'initialement escompté. Comme les deux premières phases ne contribuent pas à diminuer la demande en adresses IPv4, l'épuisement imminent des adresses IPv4 publiques conduit à la mise au point de mécanismes de partage des adresses.

Schéma de fonctionnement d'un tunnel statique.

Schéma de fonctionnement de 6to4.

Encodage d'une adresse IPv4 dans le préfixe 6to4.

La manière la plus simple d'accéder à IPv6 est lors de l'abonnement de choisir un FAI qui offre de l'IPv6 nativement, c'est-à-dire sans recours à des tunnels.

À défaut, et pendant une phase de transition, il est possible d'obtenir une connectivité IPv6 via un tunnel. Les paquets IPv6 sont alors encapsulés dans des paquets IPv4, qui peuvent traverser le réseau du FAI jusqu'à un serveur qui prend en charge IPv6 et IPv4, et où ils sont décapsulés. Le recours à des tunnels, et donc à un réseau overlay, est de nature à nuire aux performances. La RFC 4213 décrit les mécanismes de transition.

Tunnels configurés explicitement

Plusieurs services du type « tunnel broker » sont disponibles, nécessitant en général une inscription. On peut citer SixXS[1], Freenet6[2] ou Hurricane Electric[3].

Les protocoles utilisés peuvent être :

• 6in4 (RFC 4213) fait usage du numéro de protocole 41 d'IP et est donc parfois bloqué par des pare-feux et les NAT.
• AYIYA permet le transport sur UDP ou TCP et gère le changement d'adresse IP.
• GRE utilise le numéro de protocole 47.

Le Tunnel Setup Protocol (RFC 5572) facilite la création des tunnels et permet la mobilité et l'authentification. Le Tunnel Information and Control protocol, utilisé par AICCU (en), automatise la création des tunnels.

Tunnels automatiques

• 6to4 (RFC 3056) si une adresse IPv4 publique (de préférence fixe) est disponible, 6to4 était en principe simple à mettre en place. Pour l'accès aux adresses IPv6 hors du préfixe 2002::/16 (réservé pour 6to4), une adresse relais anycast était réservée, 192.88.99.1[4], mais a ensuite été rendue obsolète[5] en raison de problème opérationnels insolubles (ce qui a fait sortir 6to4 de la catégorie des tunnels automatiques ; une utilisation administrée restant possible mais déconseillée[6])
• 6over4 (RFC 2529) permet la connexion à travers un réseau IPv4 qui prend en charge multicast
• ISATAP (RFC 5214), une amélioration du précédent qui ne requiert pas le support multicast.
• Teredo (RFC 4380) utilisable dans un réseau d'adresses IPv4 privées, relié à Internet via un routeur assurant une traduction d'adresses. Une implémentation de Teredo fait partie de la pile IPv6 des systèmes Windows, et une implémentation pour Linux et les systèmes BSD est miredo[7].

Traduction de protocole dans le réseau

• Stateless IP/ICMP Translation (SIIT, RFC 2765) est un mécanisme de traduction d'en-tête entre IPv6 et IPv4. Le RFC ne décrit pas de manière générale d'associer les adresses IPv6 et IPv4. Le fonctionnement de SIIT ne permet pas d'associer plus de deux adresses uniques de chaque protocole par hôte. Ceci signifie que chaque hôte IPv6 doit également disposer d'une adresses IPv4 publique.

• NAT-PT (RFC 2766) est semblable. Les routeurs intermédiaires entre IPv6 et IPv4 modifient les en-têtes. Un proxy DNS examine les requêtes provenant des hôtes et assigne des adresses IPv4 ou IPv6 fictives quand la réponse DNS indique qu'une famille manque. Le recours à la modification des RR DNS rend cependant DNSSEC inopérant.
  Cependant, le RFC NAT-PT est classifié de historique et n'est donc plus recommandé. Les raisons de cette classification sont détaillées dans le RFC 4966.

• Dual-Stack Transition Mechanism (DSTM)[8] permet également la traduction d'adresse IPv4 et IPv6.

Traduction de protocole dans l'hôte

Il n'est pas toujours possible de modifier les applications rapidement pour les rendre compatibles avec IPv6, quand le code source n'est pas disponible, par exemple.

Les techniques suivantes permettent à une application IPv4 de fonctionner sur un système doté d'une double pile et de communiquer avec des clients IPv6. Les techniques sont utilisées en combinaison avec le resolver DNS pour assigner des adresses IPv4 fictives automatiquement et les faire correspondre aux adresses IPv6 qui sont réellement utilisées dans le réseau.

• Bump in the Stack (BIS, RFC 2767) intervient à l'intérieur du noyau d'un système d'exploitation et permet aux applications IPv4 de fonctionner sans modification, une couche logicielle additionnelle assurant la communication entre les protocoles au niveau TCP ou UDP. Il utilise le mécanisme de SIIT pour traduire les protocoles et hérite des limitations de SIIT.

• Bump in the API (BIA, RFC 3338) fait de même au niveau de l'interface de programmation. Comme il intervient à un niveau supérieur, il n'est pas nécessaire d'effectuer de la traduction d'en-tête. L'outil IPv6 CARE implémente ce principe (dans son mode 'patch').

• SOCKS (RFC 3089) est fonctionnellement semblable, il se base sur le protocole décrit dans la RFC 1928.

Passerelles applicatives

Il est possible de faire usage de serveurs qui disposent d'une double pile et qui font office de passerelle applicative (Application-Level gateway, ALG), un serveur proxy web par exemple.

NAT64 et DNS64

NAT64 et DNS64.

Les RFC 6146 et RFC 6147 décrivent un traducteur de protocole qui permet à des hôtes IPv6 d'accéder à des serveurs IPv4.

Le DNS64 opère une manipulation des noms de domaines et fournit, dans sa réponse au client, une adresse IPv6 (AAAA) à un nom d'hôte qui dispose d'une adresse IPv4 (A) mais pas d'adresse IPv6. Celle-ci est construite avec le préfixe réservé 64:ff9b::/96 auquel on ajoute les 32 bits de l'adresse IPv4 (d'autres méthodes sont possibles, tant que l'encapsulation de l'adresse IPv4 est cohérente entre le NAT64 et le DNS64). Quand le NAT64 reçoit une connexion avec une adresse de type 64:ff9b::/96 comme destination, il crée une entrée dans une table d'états et assigne un numéro de port de sortie à ce flux (traduction de port) ou une adresse IPv4 provenant d'un groupe (traduction d'adresse) qui sera prise comme source du flux IPv4. NAT64 fonctionne avec TCP, UDP et ICMP.

Le NAT64 et le DNS64 n'ont pas besoin de communiquer. Si le client fait usage de DNSSEC et qu'il valide lui-même la réponse, alors DNS64 ne peut pas fonctionner correctement. De même, si AH d'IPsec est actif et protège l'en-tête, le NAT64 ne fonctionnera pas correctement.

464XLAT (RFC 6877[9]) est une technique qui consiste à modifier le système d'exploitation pour que les applications disposent en apparence d'une adresse IPv4 fonctionnelle, alors que la traduction d'adresse est active sur un hôte ne disposant que d'adresses IPv6.

Devant l'épuisement des adresses IPv4 et la nécessité de fournir un service IPv6 à leurs clients, les opérateurs adaptent leur réseau IP. Les préoccupations principales de ceux-ci sont les suivantes :

• mettre à disposition des clients un service de transit IPv6 du même niveau que le transit IPv4,
• assurer la continuité du service de transit vers l'Internet IPv4 en dépit de l'épuisement des adresses IPv4.

Il existe un certain nombre de scénarios en cours d'étude et qui font l'objet d'Internet drafts. Ceux-ci varient dans la progressivité du déploiement et la durabilité de la solution.

Carrier Grade NAT

Carrier Grade NAT en IPv4. Le CGN sert également de passerelle vers IPv6.

L'utilisation d'un NAT à grande échelle (Carrier Grade NAT, Large Scale NAT ou NAT44) permet de surmonter le problème du manque d'adresse IPv4 à assigner aux clients. Il consiste à distribuer des adresses privées à la passerelle des nouveaux clients au lieu d'adresse publique et à traduire ces adresses en adresses publiques vers Internet.

Le CGN utilise la traduction de port, de sorte qu'une seule adresse publique est utilisée par de nombreux clients. Un certain nombre de portes TCP et UDP sont réservées dans les adresses publiques pour chacun des clients. Compte tenu du fait qu'il existe 65535 numéros de ports, et en supposant qu'une adresse publique est utilisée par 100 clients, chaque client dispose d'environ 650 numéros de port, c'est-à-dire autant de connexions simultanées possibles. Il n'existe pas de consensus sur le nombre de ports minimal à assigner à chaque client. Certaines applications qui établissent de nombreuses connexions en parallèle peuvent être négativement affectées si ce nombre est trop faible.

Bien qu'il réduise fortement le besoin d'adresse IPv4, le CGN n'est pas un système de transition à proprement parler, mais il est utilisé en combinaison avec d'autres approches pour assurer la continuité de la connectivité avec l'Internet IPv4.

Traducteur de protocole

NAT64 ou Address Family Translation.

Le NAT-PT (Protocol Translation), NAT64, NAT46 ou AFT (Address Family Translation) permet de traduire IPv4 et IPv6. S'il est sans état, on l'appelle aussi IVI.

Ceci permet d'attribuer des adresses IPv6 aux clients tout en préservant la connectivité avec l'Internet IPv4.

Il doit cependant exister une façon d'associer certaines adresses IPv4 et IPv6 connue du NAT64, par exemple via le Domain Name System.

Le NAT-PT est associé au DNS la RFC 2766 mais a été rendu obsolète par la RFC 4966 en raison de problèmes causés.

6rd

6rd.

6rd (rd pour rapid deployment, RFC 5569) est une variante de 6to4 qui implique le fournisseur de service Internet plutôt que de passerelles d'Internet. Il n'est pas fait usage du préfixe 2002::/16 réservé pour 6to4 mais de l'espace d'adressage IPv6 du fournisseur d'accès. Le routeur du client (home gateway, HG) encapsule le trafic IPv6 dans un tunnel à destination de l'adresse bien connue de la passerelle 6rd du FAI.

Il peut être utilisé en combinaison avec le CGN.

6rd a été déployé par le fournisseur Free en 2007.

Dual-Stack Lite

Dual-Stack Lite.

Dual-Stack Lite[12] est une approche dans laquelle le réseau du fournisseur d'accès est initialement migré vers IPv6. Le trafic IPv4 de la passerelle du client est encapsulé dans un tunnel IPv6 appelé softwire et il aboutit à la passerelle DS-Lite du FAI. Celle-ci fait office de CGN pour IPv4. Ceci évite de devoir attribuer des adresses IPv4 publiques aux routeurs des clients.

6PE

Utilisation de 6PE.

Dans un réseau MPLS, la technique 6PE (RFC 4798) permet d'interconnecter des clients IPv6 aux routeurs PE, tout en conservant le cœur du réseau (P) en IPv4.

Les routeurs P du cœur échangent des labels et n'ont pas connaissance d'IPv6. Le control-plane MPLS reste en IPv4 (les interconnexions des routeurs MPLS, l'IGP, le LDP et/ou le RSVP, et le transport du MP-BGP).

Les préfixes IPv6 sont échangés via MP-BGP entre les 6PE, le next-hop étant une adresse IPv6 mappant IPv4 de la forme ::ffff:0:0/96 suivi par les 32 bits de l'adresse IPv4 du PE. Cependant, les préfixes sont inclus dans la GRF et non dans un VPRN IPv6.

Le Penultimate Hop Popping (PHP) au niveau du dernier routeur P découvrirait le paquet IPv6 avant sa transmission vers le PE eLER (egress Label Edge Router), alors même que le routeur P n'est pas censé avoir connaissance d'IPv6. Par conséquent en 6PE un label additionnel (par exemple le label Explicit-Null IPv6)[13] est toujours ajouté par le routeur PE iLER (ingress Label Edge Router), afin qu'il soit toujours fait usage d'Ultimate Hop Popping (UHP)[14] - [15].

Cette technologie est plus efficace qu'un tunnel IPv6 sur IPv4 et permet un déploiement progressif. Cependant, l'absence d'une réelle VPRN IPv6 peut être une limitation.

En France, l'ARCEP a émis un rapport relatif à la transition d'IPv4 vers IPv6 en octobre 2016. Ce rapport[18] aborde au travers d'actions les questions suivantes : l'engagement de l'État à rendre accessibles en IPv6 tous les sites web et services en ligne de l’État, l’enseignement d’IPv6, la mise en place d'échanges sur les bonnes pratiques et les expériences, la coordination des parties par publication des intentions des acteurs de la transition, l'information de l'utilisateur sur la pérennité des terminaux et les dysfonctionnements liés aux mécanismes de rationnement des adresses IPv4 et la préparation de la fin d’IPv4.

En 2016, la pénurie d'adresses IPv4 a conduit à l'existence d'un marché opaque où les adresses IPv4 se négocient à un tarif d'environ 10 € par adresse[18].

Le RIPE-NCC dont dépend la France prévoit la fin globale de disponibilité des adresses IPv4 pour 2021[18]. Toutefois, de nombreux acteurs sont déjà privés de la capacité d'acquérir de nouvelles adresses IPv4[18].

En France, des contournements sont mis en place, par exemple au travers de NAT, mais ces rustines présentent des inconvénients variés : dysfonctionnement de certaines applications, manque de résilience, coût de mise en œuvre et de maintenance notamment[18].

En France, la part des serveurs DNS faisant autorité sur des domaines en « .fr » et compatibles IPv6 est de l'ordre de 63 %, fin 2014[18].

Les serveurs de l’AFNIC ne sont sollicités qu'à hauteur de 18 % pour un transport en IPv6[18].

Un fournisseur de contenus ne voit en France que 10,5 % d'utilisateurs recourant à la technologie IPv6[18] du point de vue de Google, et entre 10 et 12 du point de vue d'Akamai, à la date du rapport.

Pour Cisco, 50 % des contenus en ligne sont disponibles en IPv6[18], mais certains sites web gouvernementaux à plus forte fréquentation ne peuvent pas être consultés en IPv6[18], de même que pour certains sites de service public, comme ceux qui servent à l’assurance maladie ou à la caisse d’allocation familiale[18].

D'après Cisco, la proportion de réseaux de transit utilisés par les fournisseurs d'accès et de contenu situés sur le territoire français est d'environ 70 % pour la compatibilité IPv6[18].

L'ARCEP envisage également la mise en place d'un observatoire national capable de publier annuellement un statut sur l'évolution de ces métriques[18].

• France Telecom IPv6 Strategy, novembre 2009
• AFTR une implementation de CGN / DS-Lite.