Un monde IPv6

Le problème du support d’IPv6 par les applications qui permettent le fonctionnement de la grille de calcul EGEE est un problème particulièrement complexe. Dans ce contexte de grille, on parle de middleware. Tout d’abord les noeuds de la grille hébergent plusieurs applications à la fois, ensuite les noeuds sont répartis sur plusieurs sites et interagissent ensemble, le middleware représente un nombre de ligne de code énorme écrites dans de nombreux langages, enfin le middleware s’appuie sur un grand nombre de logiciels externes (les dépendances externes) sur lesquels l’équipe de développeurs n’a pas la main. Le portage de ce middleware est un exemple concret particulièrement complet des difficultés rencontrées pour le portage des applications.

Le portage de tout le middleware en un coup est inimaginable, il faut donc trouver une solution pour que la grille continue de fonctionner durant le déploiement d’IPv6: le déploiemenent sur des machines dual-stack offre cette possibilité.

Afin d’aider les développeurs, mon collègue Etienne Dublé de l’Unité Réseaux du CNRS (UREC) a réalisé un certain nombre d’études, trois documents sont particulièrement généraux et peuvent apporter un bénéfices à tous :

• Tout d’abord un rapport sur la manière de tester si un serveur TCP est capable d’accepter des clients IPv4 et IPv6. Ce document est très utile pour les développeurs mais aussi pour les administrateurs systèmes.
• Un rapport sur la manière de programmer en IPv6 sur une machine double pile. En effet le portage du middleware dépend des caractèristiques internes des langages. Les avantages et inconvénients des langages C/C++, PERL, Java, Python y sont décrits et un exemple concret de programmation dans chacun de ces langages est fourni. Ce document apporte des résultats particulièrement intéressants pour Java et Python.
• Pour diagnostiquer la compatibilité IPv6, un outil IPv6 CARE  a été développé. Il intercepte les appels de fonctions relatifs au réseau effectués par votre programme. Il utilise pour cela un mécanisme original qui permet de “surcharger” les fonctions de la libc par des fonctions définies dans une autre librairie partagée. IPv6 CARE fonctionne pour les programmes écrits en C, C++, PERL, Java, Python (tout langage utilisant la librairie C ou tout interpréteur utilisant la librairie C).
  IPv6 CARE se compose donc d’une librairie partagée, et celle-ci doit être référencée via la variable système “LD_PRELOAD” pour que la surcharge fonctionne. Pour l’utiliser, il suffit, après l’avoir installé:
  • de simplement définir LD_PRELOAD : export LD_PRELOAD=/chemin/vers/libipv6-care.so
  • de lancer les programmes que vous voulez tester (ils vont fonctionner normalement, sans changement : pas d’aspect intrusif dans vos applications)

  ==> Vous obtiendrez un rapport sur le diagnostic dans /tmp/ipv6_problems
  Pour ne plus utiliser IPv6 CARE, annulez la définition de la variable LD_PRELOAD

  Vous pouvez télécharger

  • l’outil à  http://www.urec.cnrs.fr/IMG/gz/ipv6_care-1.1.tar.gz
  • la documentation https://edms.cern.ch/document/980506

Tout d’abord, bonne année à tous ! Que 2008 soit pour vous riche en bonnes nouvelles et en adresses IPv6

Le coût énergétique des équipements, qu’ils soient mobiles ou fixes, est une contrainte de plus en plus d’actualité. Or les infrastructures actuelles ne prennent pas vraiment en compte cette contrainte. En ce qui nous concernent, le mécanisme de translation d’adresse implique du calcul de la part du translateur NAT (le boîtier ADSL par exemple), mais impose aussi aux équipements connectés derrière ce NAT une émission régulière de messages pour le maintien de contexte (keepalive) pour des applications comme la voix sur IP. Deux articles pour prendre la mesure de cette consommation : le premier par 60 millions de consommateurs donne une mesure de consommation de chaque boîtier d’opérateur en France. Le second article se base sur une étude par Nokia montre la consommation due aux messages keepalive sur des équipements mobiles comme les téléphones 3G.

Est-ce qu’IPv6 peut y changer quelque chose ? Probablement car comme les équipements deviennent joignables directement en IPv6, les mécanismes de translation intermédiaire et de maintien de contexte ne sont plus nécessaires. Cependant les mécanismes IPv6 comme l’auto-configuration et la mobilité demandent aussi beaucoup de message, donc ont un coût énergétique non négligeable. Les travaux des groupes de travail IETF sur les réseaux de senseurs (6lowpan, rl2n) devraient apporter un éclairage sur la réduction de la consommation d’énergie des réseaux IPv6.