Résumé

  • LSRR et SSRR plaçaient dans l’en-tête IPv4 des adresses intermédiaires que les systèmes participants pouvaient traiter.
  • Les normes ultérieures ont conservé le format, mais ont fait du transfert source non local une fonction désactivée par défaut et recommandé le rejet des options.

À l’origine, l’adresse de destination IPv4 n’était pas toujours le dernier mot sur le prochain saut. Lorsqu’un paquet atteignait l’adresse inscrite dans ce champ, l’option pouvait fournir une nouvelle adresse. Le système qui acceptait de participer remplaçait alors la destination par cette adresse, inscrivait l’adresse de son interface de sortie dans l’emplacement libéré et avançait le pointeur de quatre octets. Le paquet transportait donc un itinéraire modifiable, pas seulement une annotation.

LSRR, de type 131, autorisait le routage ordinaire entre les étapes indiquées. SSRR, de type 137, exigeait que l’étape suivante soit directement joignable. Dans les deux cas, la longueur, le pointeur et les emplacements d’adresses devaient être valides. Le bit de copie faisait suivre l’option à chaque fragment, tandis que la limite de 60 octets de l’en-tête IPv4 bornait la taille de l’itinéraire.

Cette capacité n’a jamais constitué un ordre universel. Chaque système pouvait appliquer ses contrôles locaux, et SSRR pouvait échouer si l’étape suivante n’était pas directement accessible. Le chemin observé indiquait seulement quels systèmes avaient accepté et traité l’option; il ne certifiait pas l’ensemble du parcours.

RFC 1122 a rendu la question administrative explicite. Un hôte pouvait servir de relais de routage source, mais le transfert non local devait disposer d’un mécanisme de désactivation dont l’état initial était désactivé. Le filtrage applicable aux passerelles restait en vigueur. En cas d’échec d’un itinéraire incomplet, le problème devait normalement être signalé par ICMP Destination Unreachable, code 5, « Source Route Failed ».

RFC 6274 a ensuite relié cette souplesse à des risques concrets : contournement de contrôles de routage, accès par une interface inattendue, divulgation de topologie et parcours artificiellement amplifiés. Il insistait aussi sur la vérification des champs de longueur et de pointeur avant toute lecture ou écriture. Sa recommandation était de supprimer LSRR et SSRR par défaut, tout en conservant une activation explicite pour des environnements limités, notamment certains usages de diagnostic ou de peering.

RFC 7126 a formulé la politique opérationnelle en trois choix : supprimer le paquet, ignorer l’option et acheminer normalement, ou la traiter selon RFC 791. Pour LSRR comme pour SSRR, le choix par défaut devait être « drop » et être documenté. Ignorer n’équivaut pas à supprimer : le paquet peut alors parvenir à un équipement différent de celui attendu à cette étape.

La conclusion est donc un changement de confiance, non une disparition du mécanisme. Le routage source demeure spécifié par IPv4, mais le paquet ne peut plus présumer de la coopération du réseau.

Sources