Une fois que l'autoconfiguration IPv6 (SLAAC) est en place, les hôtes de la maquette sont capables de contacter n'importe quel autre hôte IPv6 sur l'Internet à partir de son nom enregistré dans le service DNS. Qu'en est-il des hôtes voisins qui n'ont pas été enregistrés ? Est-il même nécessaire de les enregistrer ?
Pour revenir au préambule de ce document, l'objectif est d'aller au maximum des possibilités de configuration sans enregistrement d'état. C'est à ce niveau qu'intervient le service décrit dans le (long) document RFC6762 Multicast DNS. Il s'agit de mettre en œuvre un mécanisme de résolution des noms d'hôtes en l'absence d'infrastructure. Pour simplifier à l'extrême, le principe de fonctionnement du service mDNS rassemble les points suivants :
-
Le format des messages, ainsi que le format des enregistrements, reste inchangé par rapport au service DNS classique.
-
Le numéro de port de la couche transport utilisé est le
5353. -
Toutes les requêtes et les réponses sont émises à destination de l'adresse de multidiffusion
ff02::fb. De cette façon, tous les hôtes à l'écoute sont «au courant» des échanges d'enregistrements. -
Pour éviter les conflits avec le service DNS classique, un Top Level Domain (TLD) spécifique a été défini. Il s'agit du
.local. -
Chaque hôte détient et est responsable de ses propres enregistrements.
-
Par défaut, la portée du service est limitée à un seul domaine de diffusion ou VLAN. Par définition, le préfixe IPv6
ff02::/16à pour portée le lien local uniquement.
Voici un extrait d'analyse réseau qui illustre chacun des points énoncés ci-dessus.
2001:db8:feb2:14:b8ad:ff:feca:fe15 -> ff02::fb MDNS 94 Standard query 0x0000 AAAA ipv6-rtr.local, "QM" question 2001:db8:feb2:14::1 -> ff02::fb MDNS 116 Standard query response 0x0000 AAAA, cache flush 2001:db8:feb2:14::1
-
Sur la première ligne, l'hôte
vm21avec l'adresse IPv62001:db8:feb2:14:b8ad:ff:feca:fe15cherche à connaître l'adresse IPv6 de l'hôteipv6-rtr.local. -
Sur la seconde ligne, l'hôte concerné,
ipv6-rtr.localrépond directement sur le canal de multidiffusion en donnant son adresse IPv6 :2001:db8:feb2:14::1.
Suite à cet échange de question/réponse, les hôtes peuvent communiquer à partir de leurs noms.
Voyons maintenant quelles sont les opérations à effectuer pour bénéficier du service mDNS. Elles sont au nombre de deux.
-
Il faut installer les deux paquets avahi-daemon et avahi-utils.
etu@vm21:~$aptitude search ~iavahi i avahi-daemon - Démon Avahi pour mDNS/DNS-SD i avahi-utils - Utilitaires de navigation, publication et découverte pour Avahi i A libavahi-client3 - bibliothèque client Avahi i A libavahi-common-data - Fichiers de données communs d'Avahi i A libavahi-common3 - bibliothèque commune Avahi i A libavahi-core7 - Bibliothèque Avahi pour mDNS/DNS-SD pour l'embarqué -
Il faut éditer la ligne
hostsdu fichier de configuration du «commutateur» des services de noms,/etc/nsswitch.conf, et référencer le service mDNS.etu@vm21:~$cat /etc/nsswitch.conf # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc-reference' and `info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: compat group: compat shadow: compat hosts: files mdns_minimal [NOTFOUND=return] dns mdns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis
Pour valider cette configuration, on peut faire un test élémentaire qui désigne l'hôte à contacter par son nom. Avec la commande ping6, on obtient les résultats suivants :
etu@vm21:~$ ping6 -c 2 ipv6-rtr.local
PING ipv6-rtr.local(IPv6-rtr.local) 56 data bytes
64 bytes from IPv6-rtr.local: icmp_seq=1 ttl=64 time=0.799 ms
64 bytes from IPv6-rtr.local: icmp_seq=2 ttl=64 time=0.712 ms
--- ipv6-rtr.local ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.712/0.755/0.799/0.051 msCe test est effectué entre deux hôtes appartenant au même
VLAN. Les hôtes vm21 et ipv6-rtr sont deux placés dans le
VLAN numéro 20.
Routeur & reflector mDNS
La configuration du démon avahi-daemon prévoit que celui-ci puisse jouer le rôle de concentrateur ou reflector. Compte tenu de son rôle particulier, le routeur peut collecter les enregistrements de tous les domaines de diffusion qu'il dessert puis les rendre disponibles à l'ensemble des hôtes.
Pour activer la fonction reflector,
il faut éditer le fichier de configuration /etc/avahi/avahi-daemon.conf et rechercher la
section correspondante. Voici un extrait du fichier avec l'option
activée.
[reflector] enable-reflector=yes reflect-ipv=yes
Une fois le démon redémarré, les hôtes des trois domaines de
diffusion sont accessibles les uns les autres. Il suffit de faire
un test avec l'outil avahi-browse fourni avec le
paquet avahi-utils toujours depuis
l'hôte vm21.
etu@vm21:~$ avahi-browse --all
+ eth0 IPv6 vm21 [ba:ad:00:ca:fe:15] Workstation local
+ eth0 IPv6 vm20 [ba:ad:00:ca:fe:14] Workstation local
+ eth0 IPv6 host [ae:d3:ca:81:db:7e] Workstation local
+ eth0 IPv6 IPv6-rtr [de:ad:00:be:ef:14] Workstation local
+ eth0 IPv6 vm10 [ba:ad:00:ca:fe:0a] Workstation local
+ eth0 IPv6 IPv6-rtr [ba:ad:00:ca:fe:00] Workstation local
+ eth0 IPv6 IPv6-rtr [de:ad:00:be:ef:0a] Workstation local
+ eth0 IPv6 IPv6-rtr [ba:ad:00:ca:fe:01] Workstation local
^CGot SIGINT, quittingDans la liste ci-dessus, on repère les hôtes des autres
VLANs. On peut maintenant les
contacter directement par leur nom et le TLD .local.
etu@vm21:~$ssh vm10.local The authenticity of host 'vm10.local (2001:db8:feb2:a:b8ad:ff:feca:fe0a)' can't be established. RSA key fingerprint is 4e:6e:27:b5:c1:89:94:2c:d6:6c:72:d8:7a:e0:d3:e7. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'vm10.local,2001:db8:feb2:a:b8ad:ff:feca:fe0a' (RSA) to the list of known hosts. etu@vm10.local's password: Linux vm10 3.13-1-686-pae #1 SMP Debian 3.13.10-1 (2014-04-15) i686 No mail. Last login: Fri May 2 13:51:37 2014 from ipv6-rtr.localetu@vm10:~$