Et si on migrait à IPv6 en douceur ?

Un an après l'IPv6 Day et 9 mois après l'annonce du RIPE NCC concernant l'attribution du dernier préfixe /8, il est temps de revenir sur le buzz IPv6 à tête reposer. Nous n'allons pas chercher à faire du sensationnalisme, le Net regorge de sites ayant cette orientation (mais nous ne dénoncerons personne), mais nous allons essayer de décrire les impacts de l'annonce du RIPE et décrire les conséquences dans la vie des réseaux. Ensuite, nous discuterons des différentes méthodes permettant de faire cohabiter les environnements IPv4 et IPv6 pour se simplifier la phase de transition.

14 Septembre 2012 : Annonce de la fin du monde ?

Le 14 Septembre dernier, le RIPE NCC qui est l'organisme en charge des attributions des plages IP pour la zone Europe, annonce que les attributions IPv4 se feront sur le dernier préfixe disponible. On est donc rentré dans la phase du plan de gestion des IPv4. La mise en place de cette phase implique une modification des règles d'attribution des scopes IPv4. Ces règles permettent à chaque LIR (Local Internet Registry) d'obtenir un dernier bloc IP en /22. Un LIR est typiquement un hébergeur ou un opérateur télécom qui peut ainsi fournir des adresses IP à ces clients. Les entreprises utilisent 2 méthodes qui sont soit Provider Agregatable (PA)ouProvider Independant (PI). La partie Provider Agregatable implique que l'attribution des IP est dépendante de l'opérateur. Il n'y a donc pas de problème pour obtenir une nouvelle IP tant que votre opérateur en dispose. En revanche, en cas de changement d'ISP, il faudra changer les IPs Internet des sites. Par contre, les entreprises voulants utiliser du BGP pour maitriser leur WAN doivent utiliser une plan d'adressage indépendant de l'opérateur ce qui est le cas du PI. Or, avec la pénurie d'allocation, le RIPE ne peut plus fournir d'adresse dans ces cas-là.

Il faut donc relativiser cette annonce, cela impact les entreprises voulants mettre en place du BGP, par contre, pour l'usage courant du monde entreprise, cela n'a que peu d'impact. En revanche, il est important de préparer la suite car nous sommes quand même à la fin des disponibilités d'IPv4 sur Internet et les ressources PA sont comptées.

La suite OK! Mais comment faire ?

Les mondes IPv4 et IPv6 sont par nature indépendant l'un de l'autre et il n'est pas possible de communiquer nativement du monde IPv4 vers IPv6 et inversement. Ceci dit, la disparition progressive d'IPv4 ne se produit pas à la même vitesse sur l'ensemble de la planète. La partie APAC a été la première plaque régionale a manquer d'adresses et l'IPv6 est plus largement déployées chez eux que sur la plaque du RIPE. Et portant, on remarque bien la présence de flux venant d'Asie vers les ressources IPv4 : il n'y a qu'à observer les logs SSH pour s'en convaincre. Afin de permettre ces communications, différents groupes de travail ont publiés plusieurs méthodes permettant de faire des passerelles entre les 2 mondes ou de transporter le monde IPv6 par-dessus le monde IPv4.

Les tunnels

Ces méthodes permettent en général de relier des ilots IPv6 entre eux à travers une infrastructure IPv4. Ainsi, on va retrouver des mécanismes tels que 6in4, 6to4, GRE, TEREDO, ISATAP… Tous ces mécanismes ne permettent pas de passer d’un monde à l’autre mais bel et bien de relier des environnements IPv6 entre eux bien que ceux – ci soient séparés par le monde IPv4. La mise en place est soit automatique, soit manuelle. Dans tous les cas, cette méthode permet d’obtenir une connectivité IPv6 même si l’ISP ne le fournit pas nativement.

Le 6rd (IPv6 Rapid Deployment)

Le 6rd (IPv6 Rapid Deployment) est un mécanisme dérivé des tunnels 6to4, conçu pour faciliter l'accès au réseau IPv6 via des infrastructures IPv4 existantes. Contrairement au 6to4, qui est un mécanisme général de transition entre IPv4 et IPv6, le 6rd est spécifiquement orienté vers l'accès au réseau et vise à simplifier et accélérer le déploiement d'IPv6 pour les fournisseurs d'accès Internet (FAI).

Fonctionnement du 6rd

Dans le mécanisme 6rd, le Customer Premises Equipment (CPE) du client, souvent appelé Residential Gateway (RG), dispose d'une adresse IPv6 spécifique. Cette adresse permet de créer un tunnel entre le site du client et une passerelle de translation appelée Border Relay (BR), qui est située dans le réseau de l'opérateur. Le tunnel est utilisé pour encapsuler les paquets IPv6 dans des paquets IPv4, permettant ainsi la transmission de données IPv6 sur une infrastructure IPv4 sans nécessiter de modifications importantes du réseau existant.

Étapes de la Mise en Œuvre

1. Configuration de l'Adresse IPv6: Le CPE du client est configuré avec une adresse IPv6 dérivée de son adresse IPv4 et du préfixe IPv6 alloué par le FAI. Cette configuration peut être réalisée automatiquement via DHCPv6 ou statiquement par l'utilisateur.
2. Établissement du Tunnel: Le CPE utilise cette adresse IPv6 pour créer un tunnel vers la passerelle BR du FAI. Les paquets IPv6 sont encapsulés dans des paquets IPv4 pour le transport sur le réseau existant.
3. Translation et Routage: À la passerelle BR, les paquets sont décapsulés, et les données IPv6 sont routées vers leur destination finale sur le réseau IPv6. De manière similaire, les paquets IPv6 en provenance du réseau sont encapsulés dans des paquets IPv4 pour être renvoyés au CPE du client.

Avantages du 6rd

• Simplicité de Déploiement: Le 6rd permet aux FAI de déployer IPv6 rapidement et avec peu d'efforts, en utilisant leur infrastructure IPv4 existante.
• Compatibilité avec IPv4: Le mécanisme ne nécessite pas de modifications majeures du réseau et fonctionne avec les équipements IPv4 actuels.
• Amélioration de la Performance: En réduisant la complexité du routage et de la gestion des adresses, le 6rd peut améliorer les performances du réseau.

Comparaison avec 6to4

Bien que le 6rd soit basé sur le même principe d'encapsulation que le 6to4, il présente plusieurs améliorations significatives:

• Contrôle et Gestion: Le 6rd est géré par le FAI, ce qui permet un meilleur contrôle et une gestion plus fiable des adresses et des tunnels.
• Stabilité et Fiabilité: Étant donné que le 6rd utilise des passerelles spécifiques dans le réseau du FAI, il offre une solution plus stable et fiable que le 6to4, qui dépend de la disponibilité de passerelles publiques.

Le 6rd est un mécanisme efficace pour les FAI cherchant à déployer rapidement IPv6 sur leurs réseaux existants sans investissements majeurs en infrastructure. En facilitant la transition vers IPv6 tout en assurant la compatibilité avec les infrastructures IPv4, le 6rd joue un rôle crucial dans l'adoption généralisée d'IPv6, contribuant à la pérennité et à l'évolutivité des réseaux Internet modernes.

Cette méthode impose que le BR est une connectivité dual stack IPv4 et IPv6 afin de terminer le tunnel 6rd et adresser les ressources IPv6 directement. Cette connexion IPv6 peut être native, basée sur un 6PE/VPE, via du tunnel, … Compte tenu que la technologie 6rd est stateless, il est possible de se baser sur la notion Anycast pour multiplier facilement les BR et ainsi assurer débit et redondance aux abonnés. 6rd présente de nombreux avantages pour les opérateurs comparé à la technologie 6to4. On note notamment le fait que le BR est localisé dans le réseau opérateur et donc maitrisé, l’adressage des clients est fourni par l’ISP

DS Lite

DS Lite pour Dual Stack lite est une technologie standardisée elle aussi sous le doux nom de RFC 6333 et permet de donner l’accès à des ressources IPv4 depuis un réseau full IPv6. Le scénario du DS Lite est de fournir un préfixe global au CPE qui se charge d’encapsuler les données IPv4 vers une plateforme de NAT v6 vers v4. Le mécanisme est en fait assez proche du mécanisme de 6rd.

Il faut quand même noter l’exception liée au fait que le 6rd gère les données d’un monde 32 bits vers un monde 128 bits là où DS Lite doit pérenniser les conversions d’un monde 128 bits vers un monde 32 bits en pénurie d’adresse. Il existe donc un mécanisme de NAT à grande échelle afin de masquer les clients derrière un bloc d’adresse IP portées par l’opérateur directement. Pour cela, on s’appuie sur la technologie CGN pour permettre du NAT à grande échelle.

Les solutions MPLS .

Sur ce principe, on retrouve aussi les VPN de type MPLS qui permettent de faire transiter des flux IPv6 sur une infrastructure IPv4. Ces mécanismes sont couramment appelés 6PE (RFC4798) et 6VPE (RFC4659) et permettent de déployer de manière simple de l’IPv6 dans des réseaux IPv4 sans devoir tout casser.

La différence principale entre 6PE et 6VPE est la portée de la configuration IPv6. Dans le cas de 6PE les informations IPv6 ne sont pas liées à un VPN précis mais uniquement diffusées comme des préfixes, là où la partie 6VPE utilise un NLRI spécifique pour l’usage de la notion de VPN. Le lien suivant présente un article intéressant sur la mise en place de ces mécanismes : 6PE and 6VPE over IPv4 BGP-LU

Les mécanismes de traduction et de translation.

On vient de voir qu’il était possible de créer des liens à travers les différents univers, mais il n’est toujours pas possible de fournir un accès depuis un univers à un autre de manière automatique. C’est l’objectif des mécanismes de traduction qui vont permettre de mettre en place des passerelles. Certains mécanismes se font directement au niveau des hôtes et d’autres interviennent dans le réseau. Pour les premiers, s’agissant principalement d’applicatif et de développement, nous ne rentrerons pas dans les détails. En revanche, les solutions de traductions installées dans le réseau permettent de fournir une connectivité IPv4 à des ressources IPv6 et inversement.

NAT-PT

Il s’agit d’une méthode permettant d’interconnecter les mondes v6 et v4 dans les 2 sens, celle – ci n’est plus considérée comme la meilleure qu’il soit. L’IETF le décrit dans sa RFC 2766 publié en 2000 preuve s’il en faut que l’IPv6 n’est pas un sujet nouveau.

En effet, cette technologie soulève de nombreux problèmes :

• Installation d’ALG dans les DNS pour gérer les translations v4 / v6.
• Nécessité de faire passer l’ensemble du trafic à translater par la passerelle NAT-PT
• La conversion des IP d’un monde 128bits vers un monde 32bits.

Il est donc recommandé (RFC4966) déployer cette méthode uniquement dans le cas où les autres solutions ne permettent pas de répondre à vos problématiques.

NAT64 et DNS64

Ce mécanisme de traduction, décrit dans les RFC 6146 et 6147, permet de donner de la connectivité depuis le monde IPv6 vers le monde IPv4. La passerelle NAT64 est un équipement qui dispose à minima d’une interface connectée au monde IPv4 et un préfixe de 32 bits en IPv6. De cette manière, le client IPv6 voulant joindre un serveur IPv4 encapsule l’adresse IPv4 dans le préfixe IPv6, ce paquet étant ensuite converti vers IPv4 par notre passerelle NAT64. Le serveur DNS64 quant à lui permet de traduire les réponses A en réponse AAAA pointant vers la passerelle IPv6.

Cette méthode présente en revanche des désagréments :

• Nécessite l’utilisation du DNS64 : Si les applications sont codées avec des adresses IPv4 en dure, cette méthode ne permet pas de capter correctement les flux.
• Certains protocoles ne supportent pas ce mécanisme de traduction tels que Skype / MSN / SIP / …
• La mise en place du DNSSEC ne pourra pas fonctionner sur ces adresses translatées.

Conclusion

Interconnexion et Migration entre IPv6 et IPv4

Il existe diverses méthodes pour interconnecter et transporter les mondes IPv6 et IPv4, répondant ainsi aux besoins de la transition progressive entre ces deux protocoles. Bien que cette technologie ait longtemps été perçue comme complexe, des efforts considérables ont été faits pour simplifier les méthodes de migration, rendant désormais possible la coexistence des deux environnements et permettant une transition en douceur des systèmes d'information (SI).

Simplification des Méthodes de Migration

Les techniques de migration ont évolué, offrant des solutions plus accessibles et moins perturbatrices. Parmi ces méthodes, on trouve :

• Tunnels 6to4 et 6rd: Ces mécanismes permettent de transporter le trafic IPv6 sur des infrastructures IPv4 existantes sans nécessiter de modifications majeures.
• Dual-Stack: Une approche où les dispositifs réseau et les applications supportent à la fois IPv4 et IPv6, facilitant une transition progressive.
• NAT64/DNS64: Ces technologies permettent aux clients IPv6 de communiquer avec les serveurs IPv4 en traduisant les adresses et les paquets.

Défis et Solutions pour la Migration

Malgré les avancées, certains aspects de la migration vers IPv6 restent complexes. Par exemple, il n'existe pas de solution réseau capable de réécrire dynamiquement les adresses IPv4 codées en dur dans une page web pour les convertir en IPv6. Hier, les migrations vers IPv6 étaient ardues car elles nécessitaient une conversion complète du SI et du réseau vers IPv6 pour obtenir une solution viable.

Aujourd'hui, des solutions plus flexibles existent :

• Bulles de Conversion: Il est possible de créer des "bulles" de conversion où le trafic IPv4 est converti en IPv6 et vice versa, sans besoin de remanier l'architecture réseau complète.
• Transport Simple: Des mécanismes permettent de transporter le trafic IPv6 jusqu'à la ressource souhaitée via des infrastructures IPv4, réduisant ainsi la nécessité de revoir le design réseau initial.

Perspectives et Discussion

Le sujet de la migration vers IPv6 est vaste et en constante évolution, rendant la discussion d'autant plus intéressante. Les entreprises peuvent désormais envisager une migration progressive, minimisant les disruptions et les coûts. Nous serions ravis de discuter plus en détail de ces solutions autour d'un café ou lors d'une démonstration, et d'explorer comment lancer cette migration de manière simple et efficace pour votre organisation.