Résumé

  • Le premier Neighbor Discovery donnait une liste de routeurs par défaut sans expliquer lequel convenait à l’Internet ordinaire ni quel autre ne desservait qu’un préfixe particulier.
  • RFC 4191 ajouta trois préférences et une Route Information Option avec échéance. L’hôte complet choisit d’abord le préfixe le plus long, départage ensuite les préfixes égaux et place la joignabilité connue avant la préférence annoncée.
  • Cette information reste une recommandation locale : pas une métrique, une authentification ni un ordre. Le routeur ne doit pas vider sa table dans les hôtes, qui peuvent ignorer ou remplacer les valeurs.

Une liste égale devant des sorties inégales

Le modèle de RFC 2461 était volontairement simple. Les Router Advertisements alimentaient une Prefix List et une Default Router List. Pour une destination hors lien, l’hôte choisissait un premier saut dans cette dernière.

Avec Ethernet, Wi-Fi, tunnels d’entreprise et réseaux d’essai, l’égalité devenait trompeuse. Deux routeurs pouvaient répondre sur leurs liens tout en menant vers des mondes différents. La joignabilité de voisin permettait d’écarter une machine en panne, non de dire qu’un routeur vivant ne savait atteindre qu’un réseau isolé.

Un Redirect corrigeait parfois le choix, mais seulement sur un même lien. Il ne pouvait envoyer l’hôte vers un routeur d’une autre interface. Le multihébergement révélait donc une information manquante entre la liste locale et la topologie réelle.

Trois rangs, surtout pas une métrique

Publié en novembre 2005, RFC 4191 ajouta High, Medium et Low sur deux bits ; la quatrième combinaison resta réservée. Trois valeurs suffisaient précisément parce qu’elles ne devaient pas devenir une mesure universelle de coût, de débit ou de délai.

Un administrateur connaissant les deux routeurs pouvait signaler une sortie publique principale et un secours. Les rangs devaient être configurés, non calculés automatiquement à partir d’une métrique de routage interne. L’hôte recevait une intention bornée, pas la projection complète d’un contrôle invisible.

Avec Router Lifetime à zéro, la préférence d’en-tête perd tout effet. Un routeur qui retire sa candidature au défaut ne conserve pas une autorité abstraite grâce à ses deux bits.

L’option 24 transporta quelques routes

La Route Information Option, type 24, contient longueur de préfixe, préférence, durée et préfixe. Un tunnel peut ainsi annoncer le réseau privé qu’il dessert, tandis qu’une autre interface reste la route par défaut. Une option ::/0 peut même remplacer, pour l’hôte complet, la préférence et la durée de l’en-tête.

La durée transforme l’indication en bail. Zéro retire la route de ce prochain saut ; tous les bits à un signifient l’infini. Rien ne prouve pour autant que le routeur possède le préfixe, qu’il soit annoncé mondialement ou que le chemin soit sûr. La phrase exacte est plus modeste : pendant ce délai, ce routeur se présente comme premier saut pour ces destinations.

Le RFC déconseille toute annonce par défaut, tout déversement de table et plus de dix-sept options par lien et par RA. La limite arbitraire protège une architecture : exposer quelques décisions utiles sans faire absorber aux terminaux la dynamique interne des routeurs.

Le préfixe le plus long garda la priorité

Le déploiement pouvait rester volontaire. Le type A ignore les deux extensions ; le type B comprend la préférence par défaut mais pas les routes ; le type C emploie les deux dans une petite table conceptuelle.

Le type C cherche d’abord le préfixe correspondant le plus long. La préférence ne départage que des routes de longueur identique. Une route Low étroite peut donc battre un défaut High : elle répond à une question plus précise.

Puis intervient la joignabilité. Un premier saut connu comme inaccessible est évité au profit du candidat suivant. En l’absence d’observation, il est provisoirement supposé joignable. Une modification de route invalide les entrées touchées du Destination Cache et relance la détermination. Une configuration locale peut également supplanter la valeur reçue.

Le routeur propose ; le code de l’hôte observe, tranche et peut refuser. Une préférence ne fabrique pas une preuve de fonctionnement.

Sonder seulement pour un trafic utile

Après avoir écarté un routeur préférable, l’hôte doit découvrir son retour. RFC 4191 demande une Neighbor Solicitation lorsqu’un trafic utile lui aurait été destiné, tout en limitant la sonde à une par minute et par routeur. Sans trafic concerné, aucune surveillance perpétuelle n’est justifiée.

La préférence donne une raison de vouloir le retour, le trafic une raison de dépenser un paquet, et Neighbor Unreachability Detection fournit le fait. C’est cette séparation qui empêche la politique de remplacer l’observation.

Une route instable ne devait pas envahir les caches

Une annonce peut dépendre d’un lien ou d’une route dynamique, mais l’implémentation doit découpler les hôtes des oscillations internes. Répliquer chaque flap dans des milliers de caches ajoute invalidations, recalculs et sondes à l’instabilité initiale.

Lorsqu’une interface cesse de s’annoncer avec Router Lifetime zéro, les Route Information Options devraient elles aussi recevoir une durée nulle. Retirer le défaut tout en laissant survivre des routes étroites crée une autorité résiduelle incohérente.

Une préférence plus fine permet un mensonge plus discret

RFC 3756 avait déjà décrit les faux RA, Redirects et paramètres ND. L’extension offre à l’attaquant une précision supplémentaire : annoncer High ou publier une route étroite vers une destination sensible.

Une fausse route par défaut casse beaucoup de choses et se remarque. Une route fausse vers l’administration ou le paiement peut attirer une classe précieuse sans perturber le reste. L’option ne signe ni l’auteur ni son droit sur la destination. Une durée infinie peut prolonger le problème ; elle ne transforme toujours pas le champ en commande si la joignabilité échoue ou si la politique locale le rejette.

Le préfixe source révéla la limite suivante

RFC 8028 montra en 2016 qu’un bon choix de destination pouvait encore être un mauvais choix d’égress. Dans un réseau à plusieurs préfixes fournisseurs, un paquet portant l’adresse source du fournisseur A peut être rejeté par le filtre, le pare-feu avec état ou l’uRPF du fournisseur B.

L’hôte doit donc associer le préfixe source au routeur qui l’a annoncé. RFC 4191 n’était pas annulé : sa réponse restait limitée au couple destination–premier saut. Source, état de retour et filtrage demeuraient d’autres faits locaux.

Sources et limites

Le modèle initial vient de RFC 2461, révisé par RFC 4861. Les préférences, l’option, les modèles A/B/C, la sélection, les sondes et les limites sont dans RFC 4191. RFC 3756 borne la confiance, et RFC 8028 ajoute le lien entre source et premier saut.

Ces textes ne mesurent ni déploiement actuel, ni réglages fournisseurs, ni délai universel de reprise. Ils ne prouvent pas qu’une route annoncée est autorisée ou globalement vraie. Ils montrent seulement comment IPv6 donna aux hôtes un vocabulaire routier mince et temporaire tout en gardant la décision locale.