Lors de la conférence Usenix Large Installation System Administration (LISA), qui s'est tenue la semaine dernière à Boston, Irena Nikolova, ingénieur réseau chez Google, a évoqué le déploiement, en interne, d'un réseau IPv6 qui doit s'étendre à toute l'entreprise. Elle a notamment partagé les enseignements que Google a pu tirer de cette opération, et dont d'autres entreprises pourraient profiter au moment où certaines ont également entamé la migration de leurs propres réseaux vers le protocole Internet IP de prochaine génération.

Par exemple, Google a retenu qu'une migration vers l'IPv6 consiste à faire davantage de choses que la seule mise à jour logicielle et matérielle. Cela exige également une forte implication des managers et du personnel, notamment des administrateurs, déjà pris par des tâches trop nombreuses. Et, pour les entreprises qui essuient les plâtres, il faut aussi beaucoup travailler avec les fournisseurs pour les amener à corriger un code inachevé, qui comporte encore des bogues. « Ce n'est pas parce qu'on vous annonce que le protocole est pris en charge qu'il faut s'attendre à ce que cela fonctionne », a-t-elle mis en garde dans le document qui accompagnait la présentation. « Je pense que tous ceux qui ont essayé de migrer vers l'IPv6 ont rencontré les mêmes problèmes que ceux auxquels nous devons faire face », a-t-elle encore expliqué.

Un déploiement à mi-chemin, des gains déjà significatifs

Le projet, en route depuis environ quatre ans, a demandé beaucoup plus d'efforts de la part de l'équipe d'ingénieurs que ce qui était prévu au départ. Le déploiement est seulement à mi-chemin, mais Google peut d'ores et déjà faire état de gains significatifs pour l'entreprise. Environ 95% des ingénieurs de Google profitent désormais d'un accès IPv6 à leur bureau. Et au final, l'entreprise envisage de passer la totalité de son réseau en IPv6.

Le projet avait été lancé en 2008 par un petit groupe d'ingénieurs, salariés du géant de l'Internet. Certains d'entre eux y consacraient déjà 20% de leur temps de travail, celui accordé par Google à ses ingénieurs pour mener des projets personnels au sein de l'entreprise. Le but était d'introduire « l'IPv6 partout », a déclaré Irena Nikolova. L'aspect pratique était aussi un élément intéressant. Même si le réseau était lui-même privé, interne à Google, il utilisait des adresses IP publiques, et Google allait bientôt se trouver à court d'adresses IPv4 en interne. 

Le problème de la poule et de l'oeuf

Les ingénieurs de Google travaillaient alors au développement de versions IPv6 des outils et applications de Google et ils avaient besoin de les tester en interne avant de les livrer au public. Ils ont réalisé que le déploiement de l'IPv6 ressemblait au problème de la poule et de l'oeuf. Comme de nombreuses entreprises, Google a mis du temps à adopter l'IPv6 en raison du manque d'applications tierces fonctionnant avec le nouveau protocole. Mais cette rareté vient aussi du fait que peu d'entreprises exploitent les réseaux IPv6.

Le réseau interne de Google est déployé entre plus de 200 bureaux dans le monde et il dessert 30 000 salariés environ. Il comporte une grande variété de périphériques provenant de fournisseurs comme Cisco Systems, Juniper Networks et Aruba Networks, des centaines d'applications commerciales et de produits faits maison, sans compter l'usage de plusieurs systèmes d'exploitation différents, dont Linux, Mac OS X et Windows. Les ingénieurs ont essayé de modéliser le réseau IPv6 aussi finement que possible en le calquant sur l'actuel réseau IPv4, afin de conserver le même routage et le même trafic. Au début, ils ont fait fonctionner l'IPv6 sur les réseaux IPv4, en utilisant l'effet tunnel. Puis, quand c'était possible, ils ont dédoublé les piles, plaçant côte à côte l'IPv4 et l'IPv6. Mais ils ont décidé finalement qu'ils ne maintiendraient que le réseau IPv6.

Recours à l'auto-configuration sans état

Pour affecter des adresses aux périphériques IPv6, Google a suivi les directives RFC 5375 de l'Internet Engineering Task Force. Chaque campus ou bureau a reçu un bloc d'adressage /48, ce qui correspond à l'allocation de 280 adresses. Par ailleurs, chaque immeuble a reçu un bloc d'adressage /56, soit environ 272 adresses, et chaque VLAN (Virtual Local Area Network) a reçu un bloc /64, soit environ 264 adresses. Pour affecter des numéros à des appareils spécifiques, les ingénieurs ont utilisé l'auto-configuration sans état (Stateless Address Autoconfiguration, SLAAC), qui permet aux périphériques de s'attribuer des numéros à eux-mêmes. Cette approche évite la nécessité d'attribuer manuellement une adresse à chaque appareil. Celle-ci était aussi incontournable dans la mesure où certains systèmes d'exploitation ne supportent pas encore le protocole de configuration dynamique DHCPv6 (Dynamic Host Configuration Protocol), la version d'attribution des adresses pour les réseaux IPv6.