Quand et comment migrer vers IPv6 ? Quels scénarios ?

Cloud
Congrès V6 World_Paris

Lors du congrès V6 World, qui vient de s’achever à Paris, la question d’actualité aura été : trop tard pour IPv6 ?

Y a-t-il vraiment urgence à migrer vers les adresses IPv6 ? Le sujet, qui résonne comme une Arlésienne depuis une décennie, est-il reconnu comme critique ? Quelques grands comptes tels qu’Airbus, le CERN, Continental Automation, Generali ou encore l’éditeur allemand Heise Netz, ont apporté de précieux témoignages dans ce sens, lors du congrès V6 World (concomitant du congrès MPLS & Ethernet World, tenu à Paris du 7 au 10 février dernier).

Pour Alain Fiocco, expert IPv6 chez Cisco (software group), le marché a effectivement compris le caractère impératif du passage à IPV6 : « Le pool central d’adresses IPv4 – IANA – est épuisé depuis le 3 février 2011. En Europe, au début de cette année 2012, le registre RIPE d’adresses IPv4 ne comptait plus que 200.000 adresses encore disponibles. Pour être plus précis : le nombre de préfixes ‘/24’ (adresses minimales utiles) restants disponibles au RIPE était de 155.275 mi-février. À ce rythme, l’épuisement pourrait être total à la mi-2012. »

La conséquence immédiate est que les fournisseurs d’accès Internet, fixe ou mobile, subissent cette pénurie d’adresses IPv4. Ils vont devoir choisir une de ces deux options :
– soit installer un mécanisme de partage d’adresses publiques (connu sous le nom de CGNAT pour Carrier Grade Network Address Translators (*),
– soit passer à l’IPv6 natif.

L’utilisation massive de CGNAT (*) demeure malheureusement un mal nécessaire du fait du retard de déploiement d’IPv6. Mais cette solution peut avoir un effet très néfaste sur le rendu applicatif, disons l’expérience utilisateur et la performance, en particulier lors des pics d’utilisation.

Rien que du sparadrap numérique ?

Le cas pourrait devenir particulièrement critique pour les fournisseurs qui développent leur portefeuille B2C, les acteurs de l’e-Business. Car, pour eux, l’expérience utilisateur est particulièrement importante face à la fidélisation des clients. Pourtant force est de constater que la migration est lente. Pourquoi ?

Alain Fiocco, expert IPv6, Cisco Corp
Alain Fiocco, expert IPv6, Cisco Corp

« Le trafic sur les moteurs de recherche provenant d’adresses IPv6 représente seulement 0,5 % du trafic. Les solutions palliatives de traduction d’adresse (NAT), et d’encapsulation par défaut (IPv6 dans IPv4) ont perduré, trop longtemps. Mais nous sommes maintenant à court de sparadrap numérique ! Ces solutions ne peuvent que disparaître, car ces sparadraps ont leurs limites et les fournisseurs de contenu, tels Facebook, Google ou Yahoo, font campagne pour qu’aussi bien le NAT que les tunnels soient limités au maximum voire éliminés le plus tôt possible. Ainsi, par exemple à cause de l’encapsulation, le trafic est promené d’un nœud du réseau à un autre, donc c’est très pénalisant en temps de réponse, ou bien des solutions de translation engendrent des dégradations des applicatifs », explique Alain Fiocco.

L’effet Free et la date du 6 juin 2012

Dans les statistiques mondiales du déploiement d’IPv6, la France est en très bonne position. Pourquoi ? C’est que Free a installé des adresses IPV6, par défaut, dans sa Freebox Revolution.

La France n’est pas inerte, pour autant.  Elle se mobilise déjà pour la date du 6 juin 2012, date retenue au niveau mondial pour une nouvelle méga-campagne d’information (comme celle du 8 juin 2011) auprès des ISP , des fournisseurs de contenus et d’applications Internet et des constructeurs d’équipements.

« Si les opérateurs fournissent IPv6 par défaut aux consommateurs, ceux-ci vont donc ouvrir des sessions ‘end-to-end’ par défaut (tous les OS du marché en sont capables aujourd’hui) vers les sites applicatifs ou de contenu, contournant automatiquement les amas de sparadrap que constituent le CGNAT.  Et ceci sans que l’utilisateur ne le sache ou fasse quelque action que ce soit. C’est ce qui se passe pour 2,5 millions utilisateurs Free lorsqu’ils se connectent à Google, ou Gmail, et ce sera le cas pour plus de 50 % du contenu sur Internet après le 6 Juin 2012 (voir World IPv6 Day) . Pour les contenus qui n’auront pas migré sur IPv6 les opérateurs, subissant cette pénurie, seront obligés de partager des adresses publiques IPv4. Mais le risque de saturation sera évité, car un nombre croissant de sessions contourneront ces équipements pour passer sur IPv6 », explique encore Alain Fiocco.

« En effet, il faut réaliser qu’un simple accès à Google Map enclenche 30 sessions TCP/IP pour que la page soit complète. Pour YouTube, c’est 90 sessions ; pour iTunes, c’est 270 sessions et pour Bit Torrent, c’est 800 sessions ! »

Donc, cela signifie que tant les ISP que les fournisseurs de contenu, tous ont intérêt à restaurer un modèle de bout-en-bout sans mécanisme de partage d’adresses.

Alors que faire ?

Par défaut, mieux vaut se mettre à jour et présenter son service en IPv6. Sinon, un fournisseur de CDN (Akamai par exemple) ou un opérateur fournissant un service managé peut assurer la ‘translation’ entre IPv4 et IPv6.

« Plus la translation est proche du contenu, meilleure sera la solution et la capacité de la faire grandir au fur et à mesure que l’IPv6 se déploiera », avertit Alain Fiocco. Cisco a sa réponse, bien entendu. Le géant de l’Internet propose son appliance (ACE30, coût de 20 à 30 K-euros) – mais également les routeurs ASR1000, GSR12000, ou les Catalyst 6500, lesquels incluent des options de transition intégrées.
___

Les scénarios techniques de migration IPv6

Lors du congrès V6, le laboratoire EANTC (siège à Berlin) a fait la démo de quelques scénarios de migration IPv6 :
– scénario « 6rd » : c’est un dispositif permettant de transporter le trafic IPv6 sur un réseau IPv4 ; et donc, des terminaux IPv6 peuvent communiquer entre eux sur une infrastructure IPv4. Deux sous-ensembles : 6rd CE, avec connectivité via piles (dual stack) côté terminal, et, côté FAI, 6rd BR (pour border router) qui fait la passerelle avec l’Internet global IPv6 ;
– scénario « DS-Lite » (dual stack-Lite), standardisé par l’IETF (RFC 6333), apporte l’inverse : la gestion de l’adressage IPv4 (par encapsulation) sur une infra IPv6 native, ceci via un routeur AFTR (Address family transition router). Cette solution, qui réalise un pontage basique, combine le tunneling IPv4-IPv6 (4in6) et la translation NAT44 ;
– scénario « DS-PPPoE » : (dual stack-Point-to-Point-Protocol over Ethernet ; RFC 5072):  ce protocole fournit aussi bien les accès IPv4 que IPv6 ;
– scénario DS-L2TP : (dual stack- Layer TwoTunneling Protocol ; RFC 2661) : le tunneling de packets PPP,  en couche 2 de transport, permet d’établir des sessions IPv6 sur un core network IPv4.

Cela fonctionne. Mais il reste à vérifier, en fonction de ses priorités, quelle option est la plus élégante, la plus efficace. Et à quel coût.
___
(*) CGNAT  Carrier Grade Network Address Translators: Juniper, faisant aussi de son côté, la promotion du Jour J de juin 2012 pour le énième grand lancement d’IPv6, propose aux FAI une offre spéciale ‘Six Appeal’ . c’est un kit de démarrage ‘GNAT’ sur ses routeurs MX.


Lire la biographie de l´auteur  Masquer la biographie de l´auteur