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.

[[page]]

« L'un des plus gros problèmes a été le support insuffisant de l'IPv6 par les appareils réseaux et les logiciels », a convenu Irina Nikolova. Beaucoup de périphériques réseaux actuels ne supportent l'IPv6 que grâce à une mise en oeuvre logicielle, ce qui signifie que l'essentiel du traitement du trafic est réalisé par logiciel, plutôt qu'avec un matériel spécialisé. Par conséquent, en IPv6, les opérations réseaux consomment beaucoup plus de cycles processeur qu'en IPv4. Au moins un fournisseur d'équipement sans fil ne prenait pas en charge les ACL (Access Control Lists). En outre, les périphériques d'optimisation du réseau WAN (Wide Area Network) ne savent pas chiffrer le trafic IPv6, car le protocole WCCP (Web Cache Control Protocol) qu'ils utilisent ne fonctionne pas encore avec le nouveau protocole. Les équipements réseaux ne sont pas les seuls à poser problème. Les imprimantes restent aussi problématiques, en ce que nombre d'entre elles ne prennent pas totalement en charge l'IPv6. 

Contraint d'éliminer des applications ne supportant pas IPv6

Les applications et la compatibilité avec les OS se sont également avérées être un défi. Google a été amenée à éliminer au fur et mesure des applications qui ne supportaient pas l'IPv6. Mais un certain nombre d'outils essentiels, comme des bases de données et des applications de facturation, ont été conservées, car elles ne peuvent pas être modifiées ou mises à jour facilement. Et même si les versions actuelles de la plupart des systèmes d'exploitation prennent en charge l'IPv6, ceux-ci ne le font pas par défaut. Ce qui suppose une intervention supplémentaire de la part des administrateurs et des utilisateurs. «  Nous pouvons aussi confirmer que les problèmes techniques sont souvent le fait d'un nouveau code, inachevé ou comprenant des bogues. Il a fallu intervenir auprès des fournisseurs pour les inciter à améliorer leurs produits en termes de support pour l'IPv6. C'était un autre défi » , indique le document de Google.

Google a également dû se confronter aux prestataires de service, ces entreprises chargées d'amener la connectivité jusqu'aux bureaux de Google. Les SLA (Service Level Agreements) ne sont pas aussi exigeants en matière d'IPv6 qu'en matière d'IPv4. Les prestataires ont mis plus de temps à relier les points d'accès IPv6 distincts que pour la mise en place et la configuration de peerings en IPv4. Google a dû également réécrire ses propres outils de surveillance réseaux pour travailler en IPv6. Malgré ces obstacles, Irena Nikolova s'est dite confiante et ne doute pas que l'équipe va réussir à mettre en oeuvre un réseau tout-IPv6 chez Google. « Nous avons également cessé de qualifier l'IPv6 de 'nouveau protocole', mais nous commençons à parler de l'IPv4 comme de 'l'ancien protocole' », a-t-elle enfin déclaré.