Résumé

  • Dans RFC 2019, une priorité LLC non nulle portée par un RA, NA ou NS IPv6 valide reçu sur FDDI constituait un indice sur le trajet d’un voisin précis, et non une preuve du chemin complet.
  • Cet indice autorisait l’unicast vers ce voisin jusqu’à 4 352 octets ; le multicast gardait le MTU minimal, puis RFC 2467 a retiré la détection en 1998.

Un réseau local mêlant FDDI et un média au MTU plus faible pouvait adopter une règle simple : annoncer partout la plus petite valeur. RFC 2019 conservait cette base prudente. Le MTU IPv6 par défaut d’une interface FDDI était fixé à 4 352 octets ; une annonce de routeur ou une configuration manuelle plus petite l’abaissait. Une annonce supérieure au défaut ou à la valeur manuelle pouvait être journalisée, mais devait autrement être ignorée.

Cette prudence avait un coût. Deux nœuds reliés uniquement par FDDI pouvaient se comporter comme si leur voisinage traversait le segment le plus contraint. RFC 2019 ne résolut pas ce problème en cartographiant le LAN. Il exploita plutôt une transformation précise effectuée à sa frontière.

Lorsque le mécanisme était actif, l’interface FDDI plaçait une priorité LLC non nulle dans les Router Advertisements, Neighbor Advertisements et Neighbor Solicitations. Selon le texte de 1996, un pont IEEE 802.1D traduisant une trame Ethernet vers FDDI remettait cette priorité à zéro. Une trame née sur Ethernet, ou l’ayant traversé, perdait donc la marque sur laquelle reposait l’inférence.

Si N1 recevait de N2 l’un de ces messages valide avec une priorité non nulle, N1 pouvait envoyer à N2 des paquets unicast jusqu’à 4 352 octets, même si la valeur commune annoncée était plus petite. N2 pouvait être la destination, mais aussi le routeur de prochain saut. Dans ce second cas, l’autorisation ne disait rien sur les liens suivants.

Le vocabulaire importe. Une trame observée renseignait une adjacence ; elle ne certifiait ni la permanence de la topologie, ni la livraison du paquet, ni la réussite d’une application. « Valide » renvoyait aux contrôles du protocole Neighbor Discovery de l’époque. RFC 1970 distinguait d’ailleurs l’apprentissage d’informations de liaison non sollicitées de la confirmation de joignabilité aller-retour, associée à une Neighbor Advertisement sollicitée. La marque de RFC 2019 n’était ni une authentification ni un oracle de routage.

Le multicast restait au plus petit MTU de tous les médias du LAN ponté. C’est cohérent : il ne vise pas un voisin unique dont un message marqué permettrait une exception bilatérale. La capacité récupérée était donc privée au couple d’adjacence et à l’unicast, tandis que le trafic partagé gardait le dénominateur commun.

Le mécanisme devait pouvoir être désactivé, bien qu’il fût actif par défaut. Une interface désactivée envoyait les trois messages à priorité zéro. La révocation était ainsi explicite : sans marque, pas de permission spéciale. RFC 2019 signalait aussi qu’il aurait été possible de marquer tous les paquets IPv6, mais que les trois messages de contrôle suffisaient.

La leçon n’est pas qu’un bit décrivait le réseau. Le pont supprimait une possibilité—le passage par Ethernet—dans le contexte exact défini par le RFC. Cette information négative achetait une action de même taille : relever le plafond d’unicast pour un voisin, sans toucher au reste.

En décembre 1998, RFC 2467 remplaça RFC 2019. Il conserva le MTU FDDI par défaut de 4 352 octets et les garde-fous pour les médias plus petits. En revanche, sa liste des changements supprima explicitement la « détection d’adjacence FDDI » en raison de développements récents dans IEEE 802.1p. Le nouveau texte avertit aussi de ne pas dépendre de la découverte de MTU à travers des ponts sans savoir que ceux-ci l’implémentent correctement.

Ce retrait ne prouve ni un échec de déploiement ni une vulnérabilité. Les sources ne mesurent pas l’adoption ni le gain de performance, et RFC 2019 déclarait ne pas traiter les questions de sécurité. Le constat vérifiable est plus étroit : lorsque la sémantique de priorité évolua, l’inférence cessa d’être assez stable pour le RFC de remplacement.

La portée exacte de l’indice

Observation Permission dans RFC 2019 Ce qui n’était pas prouvé
RA, NA ou NS valide, priorité non nulle sur FDDI Le trajet observé depuis ce voisin n’a pas traversé Ethernet selon l’hypothèse du RFC Chemin complet, durée, sécurité, livraison
Voisin ainsi observé Unicast jusqu’à 4 352 octets vers ce voisin ou prochain saut Multicast et sauts ultérieurs
MTU plus petit annoncé ou configuré Valeur commune prudente Limite intrinsèque de chaque voisin FDDI
MTU plus grand annoncé Journalisation éventuelle Autorité de dépasser le plafond par défaut ou manuel

Sources