Par Dominique Morvan, Directeur Général de Internet Fr, hébergeur et infogérant (tribune/interview)
Pourtant, notre vie à venir semble promise au tout Internet, d’autant que notre téléphone mobile nous y relie déjà. Notre voiture et notre maison le seront bientôt, avec tous leurs équipements électroniques. Le fret et beaucoup d’équipements pourraient en dépendre un jour. Bref, il va nous falloir disposer d’un espace d’adressage quasi infini, alors que celui d’IPV4 s’épuise.
Alors pourquoi cette incertitude et ces délais avant passage à l’acte ?
Il suffit de remonter le temps pour comprendre que la vision d’un progrès ne signifie pas que nous allons en bénéficier dans les jours ou les mois qui suivront.
Début des années 1970, les chercheurs des pays occidentaux se sont concentrés sur des architectures concurrentes de réseaux. En gros, il y avait 3 équipes en concurrence :
-Les constructeurs informatiques, chacun apportant une solution inspirée de son concurrent, et assez proches, sur le principe d’une étoile autour d’un ordinateur central. IBM et SNA avaient le leadership.
-Les opérateurs télécoms, qui ont poussé le principe du circuit virtuel, dont X25 a eu le succès qu’on connaît.
-Les universitaires et centres de recherche ont raisonné sur le concept du datagramme, principe de notre Internet actuel.
Dès 1975, deux projets universitaires préfiguraient déjà en France l’Internet du futur, Cigale et Cyclades. Ils reliaient les centres de calcul des laboratoires de recherche et des universités, à des vitesses « ridicules » exprimées en « bauds ». Les postes de travail étaient de simples machines à écrire communicantes (les télétypes). Les nœuds du réseau parlaient déjà le protocole IP, comme au moyen âge on parlait le vieux français.
Dans les années 80, le circuit virtuel a triomphé (Transpac). Mais retournement de situation au début des années 90, pour un passage progressif vers le tout IP, définitivement avéré à la fin des années 90. Depuis, le déploiement progressif et massif de machines en mode IP, y compris pour les communications inter-processus des systèmes d’exploitation (Windows, Linux, Unix) s’est généralisé.
Ce principe de communication inter-processus en IP permet aujourd’hui de construire des architectures réparties avec des composants matériels bon marché. Cela va faciliter la migration de IPV4 vers IPV6, au moment opportun.
Cette introspection historique montre bien qu’Internet ne s’est pas fait en 2 jours et comme jusque là, le protocole en vigueur a donné satisfaction, l’ensemble des acteurs n’a pas jugé bon de dépenser de l’énergie sur une évolution qui pourrait avoir lieu plus tard. Et pourtant, la norme IPV6 a été adoptée au milieu des années 90.
Pour les hébergeurs, que représente la migration de l’IPv4 à l’IPv6 ? Est-ce un passage obligé ?
Toutefois, on y arrive. Il est, donc, temps de se poser la question du « comment ». Pour migrer, il faut réunir deux conditions :
-Les visiteurs d’une application doivent eux-mêmes utiliser une adresse IPV6, ce qui suppose que les réseaux d’entreprise et les FAI soient compatibles IPV6.
-L’ensemble des composants périphériques de l’application sont compatibles IPV6 (routeurs, filtres de réseaux privés, répartiteurs de charge, serveurs, firewalls, DNS)
Tant que les visiteurs d’une application web ne sont pas identifiés comme étant significativement compatibles IPV6, les exploitants d’application ne démontreront pas une grande motivation à migrer en IPV6, car cette migration ne correspondra pas à une amélioration immédiate du service.
Pour un hébergeur, cela suppose que tous ses équipements « réseaux » soient bi-compatibles IPV4 et IPV6, car la migration ne sera pas « tout ou rien » et les deux versions de protocoles cohabiteront pendant de nombreuses années, le temps que le parc IPV4 disparaisse en totalité ou que les passerelles se généralisent. En particulier, les DNS doivent non seulement être bi-compatibles, mais aussi offrir le support des formats d’adresses IPV4 et IPV6.
La migration vers l’IPv6 est décrite comme la prochaine révolution du monde Internet ? Technologiquement, comment cela se traduit-elle ?
Le point de passage obligé est le remplacement des équipements réseau qui ne sont pas bi-compatibles. La migration consiste ensuite à rendre les serveurs bi-compatibles, ce qui s’effectue de façon relativement transparente, au niveau des cartes réseau du serveur.
Le principe de la communication interprocessus en IP des systèmes d’exploitation permet cette transparence. On notera d’ailleurs que ce principe permet de dissocier les communications publiques, avec les visiteurs, des communications internes à l’architecture. Ainsi, les communications avec les unités de stockage, de base de données, de sauvegarde peuvent rester en IPV4 alors que les frontaux dialoguant avec les visiteurs seront en IPV6.
En tant qu’acteur sur le marché de l’hébergement, Internet Fr a t-il effectué cette migration ? Quel est l’impact pour vos clients ?
Nos équipements de réseaux mutualisés sont tous bi-compatibles depuis plusieurs années et nous disposons des blocs d’adresse IPV6. Nous proposons donc déjà à nos clients la double compatibilité.
Beaucoup vont y venir, mais il faut d’abord qualifier leurs applications, dans la mesure où il faut s’assurer qu’un adressage absolu en format IPV4 ne subsiste pas dans une séquence logicielle de ces applications.
En matière de sécurité, la bascule entre l’IPv4 et l’IPv6 engendre-t-elle des failles de sécurité ?
Il s’agit de rajouter un tuyau système dans une architecture prévue pour cela. A première réflexion, il ne devrait pas y avoir plus de failles de sécurité que pour IPV4. Toutefois, cela dépend probablement de la façon dont les applications ont été programmées pour l’usage des interfaces avec le système d’exploitation. L’étape principale dans une migration IPV6 est alors, bien, la qualification de l’application. C’est pourquoi nous proposons des plates-formes de tests et de qualification à nos clients sous la forme de machines virtuelles dans notre plate-forme de « Cloud Computing ».
Quels avantages/bénéfices pensez-vous tirer du passage à l’IPv6 ?
Dans un premier temps, cela nous a donné la tranquillité d’esprit liée au fait de pouvoir proposer à nos clients un environnement réseau stable pour plusieurs années. Mais dans un deuxième temps, nous devrions gagner des fonctionnalités nouvelles, en particulier en ce qui concerne la mise en œuvre des dispositifs de sécurité qui figurent dans IPV6 et qui ne seront pas utilisés avant un moment.
