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.

Mécanisme dérivé des tunnels 6to4, celui – ci est orienté mécanisme pour l’accès au réseau. Ainsi le CPE client (RG) dispose d’une adresse spécifique pour créer un tunnel entre le site du client et une passerelle de translation (BR) présente dans le réseau du client.

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

Il existe donc toutes sortes de méthodes permettant d’interconnecter, transporter les mondes IPv6 et IPv4. Il est vrai que longtemps la technologie a fait peur par sa complexité mais un travail important a été fait pour fournir toujours plus de simplicité dans les méthodes de migration. Il est maintenant possible de faire cohabiter les 2 environnements et de lancer une migration de son SI en douceur. Il est certain que certains points de la migration vers IPv6 resteront complexes : Il n’existe pas de solution réseau qui puisse réécrire les codes à la volée pour modifier une adresse IPv4 en dure dans une page web permettant de la convertir en IPv6. Hier les migrations vers IPv6 étaient complexes : il fallait tout migrer vers v6 pour obtenir une solution viable : SI et réseau. Aujourd’hui, il est possible de déployer des bulles de conversion ou un transport simple jusqu’à la ressource souhaitée et ça sans nécessairement reprendre le design complet de son réseau. Bref, le sujet est vaste et particulièrement intéressant. Nous serons donc ravi de pouvoir en discuter avec vous autour d'un café ou d'une maquette et voir comment lancer cette migration facilement...