Dès sa parution dans le numéro de novembre dernier du magazine “PC Expert”, j’ai demandé à son auteur, M. Roure, s’il était possible de relayer ce dossier (IPv6) sous format électronique (PDF) en différé (après le retrait de la vente du numéro en question). M. Roure a généreusement accepté m’a demande et s’est efforcé de me livrer le document dans les meilleurs délais possibles (des discussions avec les contributeurs ont eu lieu pour avoir les autorisations nécessaires de publication en ligne). Je profite de ce billet pour remercier M. Roure encore une fois.

Je rappelle qu’à sa parution, Thierry Ernst a écrit un billet sur ce blog disant tout le bien de ce dossier : http://g6blog.point6.net/?p=30

Je rejoins Thierry dans cet avis, et c’est bien ça qui m’a motivé pour demander une version électronique à diffuser plus largement. Cela nous change un peu des articles sur IPv6 qui font plus souvent dans le sensationnalisme, le simplisme, la superficialité et la réduction (dans les deux sens : diaboliser IPv6 vs le présenter comme étant la panacée) que dans l’analyse sérieuse et objective des forces et faiblesses de cette technologie.

Vous trouverez attaché à ce billet le dossier en format PDF : http://g6blog.point6.net/wp-content/uploads/2009/01/ipv6-pcexpert-1108.pdf

J’y joins également le code HTML qui permet sa distribution, et qui m’a été fourni par l’auteur lui-même. Je remercie par avance tous les lecteurs de ce billet d’y prêter attention.

IPv6 - PC Expert novembre 2008 by Philippe Roure est mis à disposition selon les termes de la licence Creative Commons Paternité-Pas d’Utilisation Commerciale-Pas de Modification 2.0 France.

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

“New IPv6 Publication Available”

Prague, 28 November - CZ.NIC Association, administrator of the top level domain .CZ, has placed the second updated edition of Pavel Satrapa’s book IPv6 on its website http://knihy.nic.cz/ipv6/.

Suite de l’annonce ici : http://www.nic.cz/page/618/new-ipv6-publication-available/

Notez que seul le format PDF semble être en ligne…

Au cours de ces derniers mois, plusieurs initiatives autour des mesures du taux de pénétration d’IPv6 ont vu le jour. La méthodologie est plus ou moins claire d’une initiative à l’autre et les résultats collent plus ou moins à une certaine vision de la réalité, selon les critères et les hypothèses de ceux qui effectuent les mesures mais aussi selon la communauté qui perçoit les résultats

Lors du dernier meeting RIPE à Dubaï, l’équipe R&D AFNIC a présenté un projet de plate-forme générique de mesures DNS, avec une première application au taux de pénétration d’IPv6 tel que mesuré par exploration de la zone DNS .fr grâce au logiciel DNSwitness. Vous pouvez découvrir le projet, la présentation et les premiers résultats de mesures ici : http://www.ripe.net/ripe/meetings/ripe-57/presentations/Bortzmeyer-_A_versatile_platform_for_DNS_metrics_with_its_application_to_IPv6_.Glve.pdf

Il est à souligner que cette approche par mesures actives et exploratoires DNS ne tient compte que des ressources publiées dans le DNS et qu’en aucun cas elle ne pourra fournir une vision complète du taux de pénétration réel d’IPv6, puisqu’une grande partie du trafic IPv6 provient d’équipements réseau dont aucune adresse IP n’est publiée/visible via le DNS.

Néanmoins, ce qui est intéressant dans cette approche c’est l’étude de l’évolution et des tendances sur une longue période des mêmes aspects mesurés régulièrement.

Mohsen.

La semaine dernière, j’étais invité à la présentation de RENATER 5. On m’a demandé de parler d’IPv6 après la très bonne intervention de Bernard Tuy  sur l’urgence où les signaux techniques et le signaux politiques sont listé. Pour ma présentation, j’ai voulu parler des BCP (Best Current Practice) qui est le nom pompeux que l’on peut donner aux habitutes (bonnes ou mauvaises) que l’on a pour exploiter les réseaux. Comme IPv6 introduit des modifications dans l’exploitation du réseau, cela peut remettre en cause des habitudes bien ancrées.

Après un avertissement, où j’indique sous forme de boutade que je m’intéresse qu’à ce qui ne marche pas, pour essayer de faire la part des choses entre IPv6 qui peut être déployé et les améliorations que l’on souhaiterait avoir et qui restent pour certaines du domaine de la recherche, je montre un exemple de changement de pratiques entre IPv4 et IPv6. La configuration automatique des adresses va modifier les procédures. La charte d’Eduroam s’applique mal aux login IPv6. Elle demande de garder une trace des logs de Radius, DHCP et NAT. Or avec IPv6 on n’a pas besoin de DHCP ni de NAT, la seule trace que l’on aura sera celle de Radius qui autorisera ou non un utilisateur, mais on ne connaîtra pas son adresse. Il faut donc définir d’autres procédures qui sont dans les … de la charte :-).

Autre exemple, le fait d’enregistrer le nom des machines clients dans le DNS. C’est facile en IPv4, la machine demande une adresse au serveur DHCP et celui-ci en même temps qu’il la retourne l’enregistre dans le DNS. Est-ce nécessaire avec IPv6 si on utilise la configuration sans état ? est-ce que la machine ne doit pas rester anonyme ? En effet si on l’enregistre dans un DNS elle est plus facilement découvrable.

Finalement, quand on présente l’auto-configuration, on pense tout de suite à un trou de sécurité; n’importe quelle machine peut entrer dans mon réseau.  Or c’est aussi possible en v4, un “méchant” peut entrer aussi facilement. Avec l’auto-conf, il faut surtout se protéger des étourdits qui émettent sans le vouloir des RA. Un simple filtre sur le commutateur peut suffir, mais encore faut-il que le matériel le supporte.

Une des questions à la fin a été. Est-ce que je dois changer mes commutateurs pour faire de l’IPv6. La réponse est non, par contre si je veux plus de sécurité dans mon réseau que ce soit en IPv4 ou en IPv6 (mais IPv6 agit comme un révélateur du problème), la meilleure solution consiste à faire du IEEE 802.1X.

Dans un autre billet, il serait intéressant de définir le commutateur idéal pour IPv6, c’est-à-dire embarquant des gadgets qui faciliteront la tâche des ingénieurs réseaux…

Laurent

Lors de l’AG du G6, une des bonnes résolutions pour cette future nouvelle année universitaire est de relancer le blog IPv6. On va voir si on arrive à la tenir. Un mail de Sebastien Barré m’en donne l’occasion et permet de faire le point sur shim6.

En gros shim6 est une “couche protocolaire” presque vide entre IP et le niveau 4. Elle permet de jongler avec les adresses IP. Le niveau 4 utilise toujours la même paire d’adresse pour identifier les connexions et shim6 les modifie si nécessaire pour s’adapter aux conditions du réseau. shim6 utilise des extensions IPv6 pour dialoguer avec l’autre extrémité, mais ne rajouter pas d’information protocolaire dans le flux de données. Cela permet de résoudre une grande partie du problème de multi-domiciliation, puisque la couche shim6 ne selectionne que les couples d’adresses source et destination qui fonctionnent correctement et en cas de perturbation, peut s’adapter.  L’université catholique de Louvain (UCL) vient d’annoncer la version 0.8 de leur mise en oeuvre de shim6 (http://inl.info.ucl.ac.be/LinShim6). L’alternative à Shim6 serait une généralisation de SCTP.

Personnellement, même si la tendance dans les milieux de recherche est d’essayer de séparer les fonctions d’identification et de localisation, je suis de plus en plus sceptique sur la faisabilité de cette approche. En effet, elle induit des problèmes de sécurité qui n’existent pas quand le deux fonctions ne sont pas remplies par la même valeur. Peut être qu’à long terme on arrivera à trouver une solution (c’est le rôle de la recherche). Shim6, par contre, ne modifie en rien les équipements du réseau, il faut “juste” mettre à jour les machines qui en auront besoin, ce qui peut faire beaucoup et peut créer beaucoup de contextes dans le cas d’un serveur.

En tout cas, ce sujet à lui seul permettrait de faire vive un blog

Pour les Local Internet Registries (LIR) membres du RIPE-NCC, des amendements à la politique d’allocation et d’attribution (Allocation/Assignment) des blocs d’adresse IPv6 ont été proposés et récemment acceptés.

Ces amendements, viennent d’être implementés, comme le mentionne le message suivant posté sur la liste address-policy-wg@ripe.net du wg en charge de cette affaire.

En particulier, il est désormais recommandé aux LIR/ISP d’attribuer des /56 en lieu et place des /48 (RFC 3177) dans les cas classiques.

En outre, le HD-Ratio passe de 0.8 à 0.94.

——————————————————————————————————–

From: Filiz Yilmaz <filiz@ripe.net>
To: address-policy-wg@ripe.net, policy-announce@ripe.net
Date: Wed, 28 Nov 2007 14:30:39 +0100
Subject: [policy-announce] 2005-08 Implementation

Dear Colleagues,

We previously announced that the policy proposal 2005-08, “Proposal toAmend the IPv6
Assignment and Utilisation Requirement Policy” had been accepted by theRIPE community.

This policy has now been implemented by the RIPE NCC and the following RIPE Documents have been published:

ripe-421, “IPv6 Address Allocation and Assignment Policy”
http://www.ripe.net/ripe/docs/ripe-421.html

ripe-422, “Supporting Notes for the IPv6 First Allocation Request Form”
http://www.ripe.net/ripe/docs/ripe-422.html

ripe-425, “IPv6 First Allocation Request Form”
http://www.ripe.net/ripe/docs/ripe-425.html

Kind regards,

Filiz Yilmaz
RIPE NCC
Policy Development Officer
—————————————————————————————————————————

On indique souvent que ce sont les adresses qui changent lorsque l’on passe d’IPv4 à IPv6. En fait, ce n’est pas si simple. La taille change puisqu’elle est multipliée par 4, par contre la manière dont elles sont gérées reste à peu près identique. Les règles d’attribution suivent le même parcours et les protocoles de routage sont juste adapter à la nouvelle taille. Le changement le plus significatif a été en 1994 lorsque l’on est passé d’un adressage à plat, par classe, à un adressage hiérarchique (CIDR). Cela ne veut pas dire que cette manière d’adresser les machines va rester le même pour les cents milles ans qui viennent, mais une fois que nouveau format de paquet aura réussi à s’imposer d’autres manières de gérer le réseau (et donc d’adresser les machines) pourront être introduite.

Laurent

En IPv4, il existe deux manières d’avoir des adresses. Les adresses PA (Provider Agregate) suivent la hiérarchie décrite précédement (IANA->Registre->Opérateur->client). Elles ont l’avantage de réduire la taille des tables de routage dans le coeur du réseau puisqu’un opérateur n’a pas à lister l’ensemble des clients, mais uniquement donner son préfixe. Par contre dès que l’on veut changer d’opérateur, ou que l’on veut être connecté à plusieurs opérateurs (multi-domiciliation), les adresses PA sont moins efficaces. Les adresses PI (Provider Independant) peuvent provenir de différentes sources : si un site a obtenu ses adressses avant 1994, ou s’il veut pour des raisons de multi-domiciliaition être indépendant des opérateurs. Cela procure plus de souplesse, mais sature les tables de routage de l’Internet.

En IPv6 une autre approche est testée : une machine aurait une adresse globale par fournisseur d’accès. Si sur le papier l’idée est intéressante, elle bloque sur plusieurs problèmes protocolaires qui ne sont pas résolus. La solution demander un préfixe PI. C’est possible aux États-Unis ou en Asie, mais pas en Europe.

Les adresses dans l’Internet qu’il soit v4 ou v6 sont gérées de la même manière. La planète est divisée en 5 grandes régions. Les opérateurs Internet demandent des préfixes aux Registres de leur région. Les registres se retournent vers l’IANA qui gère de manière globale l’espace d’adressage. Evidememnt au fur et à mesure des demandes, l’espace attribuable par l’IANA diminue. La question est de savoir quand il ne sera plus possible de fournir aux Registres puis aux opérateurs les préfixes dont ils ont besoin. Depuis 1994 des prévisions sont faites, elles sont évidemment complexes car elles doivent prendre en compte les évolutions des usages, l’ouverture de pays comme la Chine, l’Inde, le Brésil à l’Internet de masse, les nouvelles applications,… Il y a quelques années la date butoir était vers 2037, mais les nouvelles estimations (pessimistes et optimistes) s’accordent maintenant pour 2010.

Sur son site actualisé tous les jours, Geoff Huston prévoit l’épuisement de l’espace d’adressage de l’IANA pour le 29 Maris 2010, et celui des Registres le 18 Novembre 2010. On peut donc retenir la data symbolique du 10/10/10, comme le 6/6/6 avait été celle de la fin du réseau IPv6 expérimental, le 6Bone.