Résumé

  • L’option Type 68 de la RFC 791 permettait aux modules IP d’ajouter une heure, parfois associée à une adresse ; son compteur de débordement sur quatre bits comptait les modules empêchés d’écrire faute de place.
  • Avec des horloges potentiellement désynchronisées et un espace limité, l’option consignait des observations partielles, pas une mesure fiable du délai de bout en bout.

Une heure inscrite dans le datagramme

La RFC 791 définit l’option Internet Timestamp, de type 68. L’émetteur réservait de la place dans l’en-tête IP ; chaque module IP participant pouvait inscrire une valeur au moment où il traitait le datagramme. Cette valeur comptait les millisecondes depuis minuit UT sur 32 bits. Si l’UT ou une horloge exprimée en UT n’était pas disponible, le bit de poids fort signalait une valeur non standard.

Les indicateurs déterminaient le contenu d’un emplacement. Le drapeau 0 enregistrait l’heure seule. Le drapeau 1 associait une adresse à chaque heure. Le drapeau 3 préinscrivait des adresses, et un module n’ajoutait l’heure que si son adresse correspondait à la prochaine adresse. Un pointeur désignait l’emplacement suivant. La longueur maximale de l’option était de 40 octets : l’émetteur devait donc décider quelle part de l’en-tête consacrer au relevé.

Cette limite donne au compteur de débordement sa signification précise. Quatre bits comptaient les modules IP qui trouvaient l’option pleine et ne pouvaient ajouter d’heure. Faute de place, le module transmettait le paquet et incrémentait le compteur. Mais s’il restait un espace insuffisant pour une entrée complète, ou si le compteur dépassait sa capacité, la RFC 791 considérait le datagramme comme erroné ; un message ICMP Parameter Problem pouvait être envoyé. Le champ ne désignait ni le routeur absent ni la raison de son absence.

La RFC imposait aussi deux limites de transport : l’option n’était pas recopiée dans les fragments et ne pouvait apparaître qu’une fois. On ne pouvait donc pas supposer que chaque fragment contenait un historique complet.

Des observations, pas une durée

Une série d’heures peut ressembler à une trace de latence. Pourtant, la RFC 791 ne garantissait ni la synchronisation ou la précision des horloges, ni la participation de chaque routeur, ni une liste complète des sauts. Chaque horodatage reflétait l’horloge propre au module qui l’avait écrit. La différence entre deux valeurs peut mêler décalage d’horloge et temps de transit. La lecture défendable est plus modeste : le paquet peut transporter un ensemble borné d’observations adresse-heure et un compteur de débordement.

Les exigences ultérieures pour les hôtes ont confirmé le caractère facultatif de cette fonction. La RFC 1122 rendait facultatives l’émission et le traitement de l’option Timestamp. Une définition fournit donc un format et des règles, sans prouver son déploiement par les hôtes ou les routeurs.

En 2014, la RFC 7126 a décrit les risques : divulgation de l’horloge, indices topologiques et empreinte des équipements. Elle indiquait que les abandons fréquents avaient rendu ces techniques quasiment impossibles selon son analyse, et recommandait que les routeurs, passerelles de sécurité et pare-feu abandonnent les paquets porteurs de l’option. C’est la caractérisation et la recommandation de cette RFC, pas une mesure actuelle de tous les réseaux.

Cette option illustre une limite de l’observabilité : une trace embarquée peut être utile tout en restant incomplète, dépendante des horloges et coûteuse en espace d’en-tête. Le format indique ce qu’un module participant pouvait inscrire ; une entrée absente ne prouve pas qu’aucun saut n’a eu lieu.

Sources