Où le «temps d'aller-retour» de Ping est-il stocké dans l'en-tête IP?

Si nous utilisons des ICMP ping, nous connaissons le TTL et round-trip timesommes stockés dans l'en-tête IP. Dans la carte d'en-tête IP ci-dessous, nous connaissons l'emplacement de TTL, mais où est le temps d' aller-retour ?

Est-il stocké dans Options?

Le temps d'aller-retour n'est en fait stocké nulle part. L'hôte émetteur se souvient de l'heure à laquelle il envoie chaque message de demande d'écho ICMP, à l'aide de l'identificateur 16 bits et des champs de séquence ICMP. Lorsqu'il obtient la réponse d'écho ICMP, il note l'heure actuelle, trouve l'heure à laquelle il a envoyé le paquet de demande correspondant identifié par la réponse, calcule la différence et la signale.

En général, ping utilise le champ d'identification ICMP pour différencier plusieurs pings simultanés et le champ de séquence pour différencier les paquets individuels.

C'est à l'implémentation de décider où stocker le temps sortant pour un paquet donné: au lieu de le stocker sur l'hôte dans une table, il l'envoie généralement dans la demande sortante et utilise la copie dans la réponse pour calculer le temps. (Merci aux commentateurs de l'avoir signalé.) Il est envoyé de la manière qui convient à la mise en œuvre, et doit bien sûr faire confiance à l'extrémité distante et à tout équipement intermédiaire pour copier correctement les données. Certains systèmes sont connus pour représenter le temps en 16 octets avec une résolution de microsecondes, certains comme 8 octets avec une résolution de millisecondes.

Le format à l'intérieur de la datapartie du paquet IP est le message de demande / réponse d'écho ICMP, copié ici à partir de la RFC 792 "Format de message de contrôle Internet" (p14).

Typeest 8 pour la demande, 0 pour la réponse; Codeest 0.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Data ...
   +-+-+-+-+-

PS. Juste pour être clair, le champ d'identification de l'en-tête IP est normalement défini sur une valeur arbitraire, différente pour chaque paquet sortant, utilisée pour le réassemblage de toute fragmentation, et n'a pas la même valeur que quoi que ce soit dans le corps ICMP.

De plus, bien qu'il existe un mécanisme défini pour placer des horodatages dans l'en-tête IP en option, ce n'est pas le mécanisme normal pour le ping car de très nombreux routeurs sont configurés pour ne pas transmettre certaines options IP. Voir la spécification RFC 781 de l'option d'horodatage du protocole Internet.

Enfin, bien que tout ici ait été écrit dans une perspective IPv4, selon la question d'origine; mais le ping dans IPv6 est extrêmement similaire, voir ICMPv6 RFC 4443 .

Au moins avec l' pingutilitaire commun sous Linux, l'heure à laquelle le paquet a été envoyé est stockée dans la partie données du paquet de demande d'écho, c'est-à-dire après les en-têtes IP et ICMP. La partie de données est conservée intacte lorsque le récepteur répond avec une réponse d'écho, afin que l'expéditeur puisse calculer le temps d'aller-retour.

Ceci est décrit dans la page de manuel de l' pingutilitaire (sous "DÉTAILS DU PAQUET ICMP"):

Si l'espace de données est au moins de la taille du struct timevalping, utilise les octets de début de cet espace pour inclure un horodatage qu'il utilise dans le calcul des temps d'aller-retour. Si l'espace de données est plus court, aucun temps d'aller-retour n'est indiqué.

Sur ma machine sizeof(struct timeval)est 16, donc la définition de la taille des données par paquets à 15 empêche pingd'afficher les temps d'aller-retour:

$ ping -s 15 8.8.8.8 
PING 8.8.8.8 (8.8.8.8) 15(43) bytes of data.
23 bytes from 8.8.8.8: icmp_seq=1 ttl=121

Bien sûr, le stockage de l'horodatage d'envoi dans l'utilitaire, comme le décrit la réponse de @ jonathanjo, serait également une implémentation possible. Même l'utilitaire Linux a besoin d'une comptabilité interne, car il détecte les paquets en double.