Résumé

  • L’option IPv4 de type 7 réservait une suite finie d’emplacements de quatre octets où les équipements coopérants pouvaient inscrire leur adresse de sortie.
  • Cette liste n’imposait aucun itinéraire et n’authentifiait aucun saut ; la divulgation de topologie et le filtrage ont progressivement renversé le comportement par défaut.

Une place réservée avant le départ

Tout se jouait avant l’envoi. L’hôte d’origine fixait la longueur de l’option Record Route et mettait à zéro sa zone de données. Après les octets de type et de longueur, un pointeur indiquait la prochaine case disponible. Sa plus petite valeur légale était 4, et chaque adresse Internet occupait exactement quatre octets.

Lorsqu’un module IP traitait l’option en transférant le datagramme, il écrivait son adresse à la position désignée puis avançait le pointeur de quatre. RFC 1812 a ensuite précisé le choix d’un routeur : l’adresse de l’interface logique de sortie, ou un identifiant de routeur stable si cette interface n’était pas numérotée. La valeur décrivait donc l’identité utilisée vers le prochain environnement, pas nécessairement l’équipement physique dans son ensemble.

La longueur ne changeait jamais en cours de route. Quand le pointeur dépassait la longueur, la zone était pleine et le paquet continuait sans nouvelle inscription. S’il restait moins de quatre octets, le datagramme était erroné et devait être rejeté ; un message ICMP Parameter Problem pouvait être émis. L’option ne suivait pas les fragments ultérieurs et ne devait apparaître qu’une fois.

La limite pratique la plus connue—neuf adresses—vient de l’en-tête IPv4 lui-même. Sur les 60 octets possibles, 20 appartiennent à l’en-tête fixe. Dans les 40 restants, les trois octets de contrôle de Record Route laissent 37 octets, soit neuf adresses complètes si aucune autre option substantielle ne partage l’espace. C’est un plafond arithmétique, non la garantie d’observer neuf routeurs.

Observer n’est pas diriger

Record Route se distingue des options de routage à la source. Ces dernières transmettaient une liste fournie par l’émetteur et intervenaient dans le choix des destinations intermédiaires. Le type 7 ne choisissait rien : il laissait le routage ordinaire décider, puis invitait certains participants à décrire leur passage.

La nuance est essentielle pour interpréter la liste. Aucun champ ne signait l’adresse, n’attachait une identité matérielle durable au routeur ni ne prouvait que tous les intermédiaires avaient écrit. Une case vide pouvait simplement suivre la fin d’un chemin court ; elle pouvait aussi signaler un filtre, une configuration de passage inchangé, une absence d’implémentation, une fragmentation ou un trajet inattendu. La liste produisait des indices coopératifs, non un relevé exhaustif et certifié.

RFC 1122 rendait facultatifs, pour les hôtes, l’émission et le traitement de l’option. Il recommandait néanmoins qu’une réponse ICMP Echo mette à jour l’option reçue et la renvoie sans la tronquer, afin d’obtenir une trace aller-retour. Cette ambition diagnostique reposait déjà sur une chaîne de décisions administratives indépendantes.

Le renversement du réglage par défaut

En 1995, RFC 1812 exigeait des routeurs qu’ils prennent en charge Record Route dans les paquets transférés. Une commande pouvait permettre de laisser l’option intacte, mais elle devait, par défaut, maintenir l’enregistrement. La divulgation de topologie était reconnue comme un risque possible sans annuler cette présomption de coopération.

En 2014, RFC 7126 partait du constat inverse. Le type 7 pouvait faciliter la cartographie d’un réseau, même si le peu de place dans l’en-tête limitait cette capacité. Le blocage cassait les diagnostics qui utilisaient explicitement Record Route, pas le ping ordinaire ; toutefois, leur usage sur Internet était déjà presque impossible à cause des rejets répandus. Le texte recommandait donc un réglage spécifique permettant de rejeter, ignorer ou traiter l’option, avec « rejeter » comme valeur par défaut documentée.

Sources