Le service de découverte des voisins d'IPv6,
normalisé dans le , inclut une fonction
de détection de l'injoignabilité du voisin (section 7.3 du ). En trois secondes, elle permet de détecter
la panne d'un voisin et donc, s'il existe un autre voisin pouvant
assurer la même fonction, de basculer vers un voisin qui
marche. Seulement, s'il n'existe pas de voisin équivalent, il ne sert
à rien de détecter la panne (puisqu'on n'a pas d'alternative) et ce
service est, dans ce cas, bien trop impatient, menant à une charge
inutile du réseau.
Tout mécanisme de détection de la panne d'un composant réseau fait
face à la même nécessité de compromis : si on essaie très souvent, on
détectera les pannes rapidement mais on chargera le réseau. Autre
problème, on risque de croire à tort qu'il y a une panne alors qu'on
avait un problème temporaire dans les couches basses (convergence
spanning tree prenant
plusieurs secondes, par exemple). Si on
essaie rarement, on épargnera le réseau, on risquera moins de détecter
de fausses pannes, mais on risque de ne pas voir
les vraies pannes aussi vite.
Le optimise plutôt
du côté de la rapidité de la détection. Un cas typique où on peut avoir un voisin équivalent est celui de
deux routeurs sur le même réseau local. Il est
important de détecter la panne d'un routeur très vite, pour pouvoir
passer à l'autre avant que les applications ne s'en aperçoivent. Les
délais spécifiés dans la section 10 du
(MAX_UNICAST_SOLICIT, trois
transmissions séparées par une seconde) sont donc raisonnables. Mais
ce nouveau RFC se focalise sur le cas où il n'y
a pas d'alternative et où une détection agressive et repétée de la
joignabilité est donc inutile. Il faut donc faire un compromis
différent. Le décrit ce problème,
ainsi que d'autres questions opérationnelles liées à la découverte des voisins.
Notez que le protocole équivalent pour IPv4,
ARP (), n'a pas ce
problème car le RFC ne spécifie pas de délais particuliers, les mises
en œuvre d'ARP sont donc libres d'optimiser selon leur goût, par
exemple vers moins de nervosité dans la détection des pannes.
La section 3 décrit les changements faits dans le protocole. On a
désormais le droit d'envoyer plus de
MAX_UNICAST_SOLICIT s'il n'existe pas de voisin
alternatif. Dans ce cas, on est censé utiliser un repli
exponentiel entre deux transmissions. Le modèle de la
section 7.3.2 du est mis à jour pour
ajouter un état : UNREACHABLE. On y entre lorsqu'il
n'y a plus de réponses aux sollicitations. Lorsqu'un voisin est
dans cet état, on continue à lui envoyer des paquets, comme dans
l'état PROBE, mais les tests
de joignabilité
utilisent le multicast, car
le voisin a peut-être changé d'adresse MAC. Et,
évidemment, on ne choisit plus ce voisin comme routeur par défaut.
Au bout d'un moment (le RFC recommande un maximum de soixante
secondes), le voisin est considéré comme définitivement mort et retiré
de la table des voisins. Au fait, pour voir cette table, sur Linux, c'est (ici avec trois routeurs possibles) :
% ip -6 neighbour show
fe80::641 dev eth0 lladdr 00:07:b4:02:b2:01 router DELAY
fe80::250:3eff:fe97:7c00 dev eth0 lladdr 00:50:3e:97:7c:00 router STALE
fe80::20e:39ff:fe43:6400 dev eth0 lladdr 00:0e:39:43:64:00 router REACHABLE
Sur une autre machine, avec plusieurs voisins, dont un routeur :
% ip -6 neighbour show
fe80::21e:8cff:fe7f:48fa dev eth0 lladdr 00:1e:8c:7f:48:fa REACHABLE
fe80::a2f3:c1ff:fec4:5b6e dev eth0 lladdr a0:f3:c1:c4:5b:6e REACHABLE
fe80::f6ca:e5ff:fe4d:1f41 dev eth0 lladdr f4:ca:e5:4d:1f:41 router REACHABLE
fe80::f6ec:38ff:fef0:d6f9 dev eth0 lladdr f4:ec:38:f0:d6:f8 REACHABLE
Sur ce même Linux, les paramètres de la détection d'injoignabilité
sont réglables avec sysctl, variables
net.ipv6.neigh.default.ucast_solicit et net.ipv6.neigh.default.mcast_solicit.
Si vous aimez la programmation, la section 4 de notre RFC contient
un algorithme (spécifié en langage naturel) mettant en œuvre les
nouvelles possibilités, et donc moins impatient que l'algorithme actuel.