inetdoc.net

En voyant les difficultés rencontrées par les étudiants dans la mise en œuvre du protocole IPv6, je me suis décidé à rédiger un nouvel article sur l'autoconfiguration IPv6. L'objectif de ce document est de poser les bases de l'argumentation en faveur des communications sans suivi d'état (stateless) et de rassembler les éléments nécessaires à la mise en route d'une maquette de projet. Les communications IPv6 ne sont pas la finalité, elles constituent juste la première étape avant de passer aux services de la couche application. Il est terriblement frustrant de constater que cette première étape constitue trop souvent un mur infranchissable. Mon espoir est que le fait d'avoir compilé en un seul article des ressources disséminées sur le Net permettra d'arriver plus vite à un fonctionnement correct et fera avancer la compréhension de l'utilisation d'IPv6. Il est de coutume de dire que l'adoption du protocole IPv6 est freinée par le fait qu'elle nécessite la coopération de tous les acteurs ; des développeurs jusqu'aux opérateurs réseau. Le développement de l'Internet des objets pourrait bien être, enfin, le nouvel usage déterminant dans cette adoption.

L'interconnexion réseau type utilisée pour illustrer le propos rassemble les briques de base : un tunnel d'accès au réseau public, des routeurs et deux VLANs. Par commodité, j'ai utilisé des instances de machines virtuelles et Open vSwitch, mais ce n'est pas une obligation.

IPv6 n'est pas le seul écueil dans le déroulement des enseignements. Dire que le service DNS est une pièce critique et essentielle est un lieu commun. Mais, quand on arrive à conclure qu'une application ne marche pas et à rester bloqué devant la fenêtre vide de WireShark parce que le fichier /etc/resolv.conf est vide, on est «en droit de s'inquiéter». Que faire pour dépasser ce genre de blocage ?

Sachant que la mise en œuvre d'une infrastructure DNS au début de chaque séance de travaux pratiques est irréaliste, le service multicast DNS (mDNS), qui est sans infrastructure, est une solution très intéressante. Lorsque j'ai rédigé le document Initiation au développement C sur les sockets IPv4 & IPv6, j'ai inclus une infrastructure DNS complète. C'est certainement beaucoup trop lourd à utiliser en séance. La situation s'est reproduite dans le billet NIS, NFSv4, autofs5 & dual stack IPv4 + IPv6 ; même si dans ce dernier cas, le cocktail de tous les services à utiliser était long à installer en tout état de cause.

Dans la section Multicast DNS, j'essaie de montrer qu'avec une résolution DNS classique «mal en point», il est toujours possible d'utiliser des noms d'hôtes et peut être d'éviter de conclure sur le mauvais fonctionnement d'une application qui n'a en réalité aucun problème ! Ceci dit, pour être tout à fait honnête, je n'ai fait que déplacer le problème du fichier /etc/resolv.conf au fichier /etc/nsswitch.conf ...

En bonus, il est possible de «propager» les enregistrements mDNS d'un domaine de diffusion à l'autre grâce à la fonction reflector du démon avahi.

Pour conclure ce billet, encore trop long, l'autoconfiguration IPv6 associée au service mDNS constitue une solution d'interconnexion réseau éphémère qui mérite que l'on s'y attarde. Son usage dépasse largement le cadre des enseignements.