TP 4 — IPv6 : fonctionnement et configuration

Une adresse de lien local fe80::…/64 (plage fe80::/10), construite automatiquement par la machine dès l'activation de l'interface. Elle ne permet de communiquer que sur le réseau local : un paquet à destination d'une adresse de lien local ne sort jamais du réseau. Vers des réseaux différents : impossible — et il n'y a pas de routeur ici de toute façon.

Oui : l'identifiant d'interface dérive de la MAC par EUI-64 — pour 00:03:ba:24:a9:6c, l'adresse est fe80::0203:baff:fe24:a9c6 (7ᵉ bit inversé, ff:fe inséré au milieu). C'est pratique : l'unicité de la MAC garantit presque l'unicité de l'adresse, sans aucun serveur. Ce n'est pas une bonne chose pour la vie privée : l'adresse est stable et trahit la carte réseau — la machine devient traçable d'un réseau à l'autre. D'où les identifiants aléatoires (RFC 7217) et les extensions de confidentialité.

L'adresse démarre « tentative » (tentative) : posée, mais pas encore utilisable. La transition vers « préférée » vient de la détection d'adresse dupliquée (DAD) : la machine a envoyé une sollicitation de voisin depuis l'adresse :: vers l'adresse de multicast sollicitée de l'adresse testée — et n'a reçu aucune annonce de voisin en réponse. Silence = personne n'utilise l'adresse = elle devient préférée. (C'est rapide : quelques secondes après l'activation.)

Une sollicitation de voisin (ICMPv6 type 135), émise depuis :: vers l'adresse de multicast sollicitée, avec pour cible l'adresse que la machine veut utiliser : c'est la DAD du point (c). Si un autre hôte utilisait déjà l'adresse, il répondrait par une annonce de voisin (type 136) — et l'auto-configuration s'arrêterait.

L'adresse de multicast sollicitée de l'adresse testée : ff02::1:ff + les 24 derniers bits de l'adresse (pour fe80::0203:baff:fe24:a9c6, le groupe ff02::1:ff24:a9c6). Elle remplace la diffusion d'ARP : au lieu de réveiller tout le lien, la question n'atteint que les machines dont l'adresse se termine par les mêmes 24 bits — en pratique une seule.

En plus du lien local, une adresse globale 2001:db8:0:1::… (dans le préfixe annoncé par rtr1) apparaît sur l'interface, d'abord tentative puis préférée — et une route par défaut s'installe aussi. C'est toute la différence : le routeur du lien diffuse des annonces de routeur, et la SLAAC fait le reste.

Une annonce de routeur (Router Advertisement, ICMPv6 type 134), envoyée par rtr1 vers ff02::1 en réponse à la sollicitation de routeur de pc2. Elle apporte : le préfixe 2001:db8:0:2::/64 (dont pc2 construit son adresse globale en ajoutant son identifiant d'interface), l'identité du routeur par défaut (son adresse de lien local), le MTU du lien, et les durées de validité et de préférence du préfixe.

Ça marche — pc1 et rtr1 sont sur le même réseau A. Il faut écrire ping6 fe80::… %eth0 : une adresse de lien local exige de préciser l'interface, car la même adresse existe potentiellement sur chaque lien.

Non — et c'est normal. Une adresse de lien local n'est jamais routée : elle n'a de sens que sur son propre lien. Celle de pc2 n'existe que sur le réseau B ; rtr1 refusera de faire suivre le paquet (et le message « destination unreachable — scope » le dit).

ping6 2001:db8:0:2::… fonctionne : pc1 envoie vers sa route par défaut (le lien local de rtr1), qui route vers le réseau B où vit l'adresse globale de pc2 — et le retour suit la route par défaut de pc2.

La sollicitation de routeur (type 133, pc2 → ff02::2) puis l'annonce de routeur (type 134, rtr1 → ff02::1) : c'est l'auto-configuration de pc2 qui vient de se brancher, suivie des sollicitations/annonces de voisin de la DAD sur sa nouvelle adresse globale.

ip -6 route montre default via fe80::… dev eth0 : le routeur par défaut a été installé par l'annonce de routeur — via l'adresse de lien local de rtr1. Aucune commande ip -6 route add n'a été tapée sur le PC.

vtysh ouvre la console FRR ; show running-config affiche, sur interface eth0 : ipv6 address 2001:db8:0:1::1/64 (l'adresse du routeur sur le réseau A) et no ipv6 nd suppress-ra (FRR supprime par défaut l'envoi des annonces de routeur — cette ligne les réactive), plus éventuellement ipv6 nd prefix … pour les préfixes annoncés. Sur eth1, le même schéma avec 2001:db8:0:2::1/64. C'est le routeur, et lui seul, qui décide quels préfixes les PC s'approprient.

Elle raccourcit à 30 s l'intervalle entre deux annonces de routeur — les RA partent plus souvent, donc tout changement de configuration se propage plus vite. On le vérifie dans les captures : une annonce de routeur toutes les 30 secondes.

Dans FRR, sur interface eth0 : ipv6 address 2001:db8:4242::1/64 pour l'adresse du routeur, puis ipv6 nd prefix 2001:db8:4242::/64 pour diffuser le préfixe dans les annonces. Sur pc1, au RA suivant (≤ 30 s), une deuxième adresse globale apparaît : 2001:db8:4242::…, tentative puis préférée — les deux adresses globales cohabitent.

Deux options « préfixe » : 2001:db8:0:1::/64 et 2001:db8:4242::/64, chacune avec ses durées de validité (valid lifetime) et de préférence (preferred lifetime). C'est la double annonce qui fait la transition : les deux adresses sont utilisables en même temps.

L'ancienne : 2001:db8:0:1::…. Les deux adresses sont préférées, et le choix par défaut garde l'adresse en place depuis le plus longtemps — le ping ne bascule pas tout seul vers le nouveau préfixe. C'est à nous de pousser la bascule, en raccourcissant la vie de l'ancien.

240 = la durée de vie (valid lifetime) du préfixe : après 240 s sans nouvelle annonce, l'adresse est invalide. 120 = la durée de préférence (preferred lifetime) : après 120 s, l'adresse est obsolète — les connexions en cours continuent, mais plus aucune nouvelle ne la choisit. C'est l'ancien préfixe qu'on met ainsi en fin de vie programmée.

Au RA suivant (≤ 30 s, grâce au ra-interval 30), les compteurs de l'adresse 2001:db8:0:1::… se réalignent sur valid 240sec preferred 120sec — et décomptent à vue d'œil dans le watch.

no ipv6 nd prefix 2001:db8:0:1::/64 240 120 : l'ancien préfixe n'est plus annoncé, ses durées ne sont plus rafraîchies et tombent. Quand la durée de préférence atteint zéro : l'adresse passe obsolète (marquée deprecated dans ip -6 a), les connexions en cours continuent dessus. À zéro de validité : l'adresse devient invalide et est retirée de l'interface.

La nouvelle : 2001:db8:4242::…. Avec l'ancienne devenue obsolète, la seule adresse préférée restante est la nouvelle — toutes les nouvelles connexions l'utilisent (visible dans Wireshark comme adresse source de l'echo request). La renumérotation est terminée sans coupure : les connexions établies sont mortes naturellement sur l'ancienne, jamais brutalement.