Cricket Liu, d’Infoblox, met en lumière une approche pratique de la migration de l’IPv4 vers l’IPv6

Lorsque ses créateurs ont conçu l’IPv4, celle-ci permettait la création de plus de 4 milliards d’adresses : une allocation plus que généreuse puisqu’à l’époque, une adresse IP correspondait à un seul ordinateur. Même lorsque chaque bureau a été doté de son propre PC, l’IPAM (la gestion des adresses IP) est restée relativement simple pour les petites entreprises. Mais ensuite les téléphones sur IP, les ordinateurs portables, les PDAs et les Smartphones sont arrivés, ce qui a engendré une forte augmentation du nombre d’adresses. Des applications comme les alarmes contre le vol, les systèmes d’accès sécurisés, les détecteurs de fumée ou d’autres fonctionnalités qui étaient auparavant indépendantes ont peu à peu migrées sur le réseau d’entreprise et l’IPAM est devenue une question de premier plan, y compris pour des organisations de taille réduite.

La virtualisation fait monter la pression : alors qu’un serveur virtuel ne peut prendre que quelques secondes à installer, l’attribution d’une adresse IP peut quand à elle demander 30 à 40 minutes de travail manuel, voir même être retardée de plusieurs jours si une adresse IP valide pour un hôte spécifique nécessite des recherches fastidieuses à travers une montagne de feuilles de calcul et beaucoup de communication entre les différents services de l’entreprise.

L’automatisation de fonctions essentielles comme l’attribution, le suivi et la gestion des adresses IP devient une necessité vitale pour toutes les moyennes et grandes entreprises. En effet, l’adoption de l’IPv6 ajoute un degré supplémentaire de complexité en raison de ses adresses plus longues et de la période intermédiaire indispensable durant laquelle l’IPv4 et l’IPv6 devront cohabiter. Chaque société s’appuyant sur Internet doit gérer les deux protocoles en parallèle pour pouvoir continuer à servir ses anciens clients et partenaires restés en IPv4 tout en acceptant les nouveaux clients et entreprises ayant adopté de façon précoce l’IPv6. Il est alors plus compliqué de gérer deux types d’adresses, de prendre en compte la taille plus importante des adresses IPv6 et de supporter le poids d’une utilisation ”en doublon”.

Si le portefeuille client d’une entreprise est prédominant en Europe et aux USA, l’envie de soutenir l’IPv6 y était certainement moins présente que dans les pays en voie de développement où le nouveau protocole a été rapidement adopté. Les entreprises occidentales qui n’auront rien fait auront surement eu un avantage économique à court terme mais, même en Europe, nous allons manquer d’adresses IPv4 dans le courant de l’anée et la nouvelle génération d’équipements sera alors inaccessible.

Il est vrai que des moyens de contourner le problème existent, comme par exemple le NAT (la traduction d’adresses réseaux), qui permet aux adresses IPv4 déjà utilisées quelque part ailleurs d’être utilisées dans un réseau interne et traduites en une adresse IPv6 unique à l’extérieur de ce réseau. Lorsqu’un message arrive sur le réseau, le serveur NAT traduit l’adresse IPv6 en adresse IPv4 interne, et vice versa lorsqu’un message quitte le réseau. En pratique cependant, le NAT ajoute de la latence, ce qui représente un risque supplémentaire de défaillance, et certains services ne fonctionnent tout simplement pas avec le NAT.

Sur le long terme, ceux qui ne relèvent pas le défi de l’IPv6 immédiatement souffriront d’un service totalement asphyxié et, lors du passage au ‘Cloud Computing’, ce désavantage prendra des proportions très sérieuses.

La migration vers l’IPv6

Se préparer à L’IPv6 implique de dépenser de l’argent pour former les équipes informatiques d’une part et modifier les applications utilisant des adresses IP d’autre part : le retour sur investissement ne sera pas obligatoirement immédiat. Cependant, si vous ignorez le problème, vous serez tôt ou tard forcés d’agir pour rester compétitifs.

Le plan de transition doit tenir compte des éléments suivants :

• Révision des politiques de sécurité. Un pare-feu qui ignore l’existence des adresses IPv6 pourra ignorer ce type de paquets.
• Vérification de la compatibilité des applications avec l’IPv6. Des mises à jours seront peut être nécessaires.
• Prise de conscience que la compatibilité avec l’IPv6 peut représenter des risques supplémentaires. Les implémentations IPv6 sont encore en developpement et leur fiabilité n’est peut être pas encore confirmée.
• Reconnaissance du manque d’outils de base. Les outils et les méthodes de gestion et de résolution de problèmes actuels peuvent ne pas fonctionner avec l’IPv6.
• Mise en place de tests de compatibilité des services IPv6. Il n’y a pas encore suffisamment d’implémentations pour effectuer des tests comparatifs.

Vos Systèmes de Gestion Réseau (NMS) devront également être automatisés pour l’IPv6, car les champs d’adresses sont plus larges et les bases de données plus grandes et parceque les équipements IPv4 et IPv6 apparaitront simultanément sur l’interface utilisateur. L’automatisation permettra également de réduire le risque d’erreur humaine, de simplifier la transition et de rendre la gestion des adresses IP plus transparente.

Il est aussi sage de prévoir un banc de test IPv6 pour que les équipes informatiques se familiarisent avec ce type d’adresses avant de commencer la migration proprement dite. Commencez en installant des serveurs externes frontaux supportant l’IPv6. Configurer ensuite votre infrastructure de routage de coeur de réseau pour qu’elle route l’IPv6. Ce n’est qu’à ce moment là que vous serez réelement prêts pour la migration totale : identifiez les serveurs et les services capables de fonctioner en double pile puis décidez quelle technologie de transition est la meillere pour accéder ensuite aux autres.

Infoblox a d’ors et déjà developpé toute une gamme d’outils pour aider les équipes informatiques à opérer une transition sans heurt. Mais si vous dépendez encore de processus manuels, profitez de cette opportunité pour automatiser vos services de coeur de réseau et vous assurer une transition la plus douce possible vers l’IPv6.

Cricket Liu, expert DNS et vice président de la section Architecture et Technologies d’Infoblox