¿Dónde se almacena el "tiempo de ida y vuelta" de Ping en el encabezado de IP?

Si usamos ICMP ping, conocemos el TTL y round-trip timeestamos almacenados en el encabezado IP. En el siguiente mapa de encabezado de IP sabemos la ubicación de TTL, pero ¿dónde está el tiempo de ida y vuelta ?

¿Está almacenado en Options?

El tiempo de ida y vuelta en realidad no se almacena en ningún lado. El host remitente recuerda la hora en que envía cada mensaje de solicitud de eco ICMP, utilizando el identificador de 16 bits de ICMP y los campos de secuencia. Cuando recibe la respuesta de eco ICMP, anota la hora actual, encuentra la hora en que envió el paquete de solicitud coincidente identificado por la respuesta, calcula la diferencia y lo informa.

Típicamente, ping utiliza el campo de identificación de ICMP para diferenciar múltiples pings simultáneos y el campo de secuencia para diferenciar paquetes individuales.

Depende de la implementación decidir dónde almacenar el tiempo de salida para un paquete dado: en lugar de almacenarlo en el host en una tabla, generalmente lo envía en la solicitud de salida y usa la copia en la respuesta para calcular el tiempo. (Agradece a los comentaristas por señalar esto). Se envía de la manera que sea conveniente para la implementación y, por supuesto, tiene que confiar en el otro extremo y en cualquier equipo que intervenga para copiar adecuadamente los datos. Se sabe que algunos sistemas representan el tiempo en 16 bytes con resolución de microsegundos, algunos como 8 bytes con resolución de milisegundos.

El formato dentro de la dataporción del paquete IP es el mensaje de solicitud / respuesta de eco ICMP, copiado aquí del RFC 792 "Formato de mensaje de control de Internet" (p14).

Typees 8 para Solicitud, 0 para Respuesta; Codees 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 ...
   +-+-+-+-+-

PD. Para ser claros, el campo de identificación del encabezado IP normalmente se establece en un valor arbitrario, diferente para cada paquete saliente, utilizado para el reensamblaje de cualquier fragmentación, y no tiene el mismo valor que cualquier cosa en el cuerpo ICMP.

Además, aunque hay un mecanismo definido para colocar marcas de tiempo en el encabezado IP como una opción, este no es el mecanismo normal para hacer ping porque muchos enrutadores están configurados para no pasar ciertas opciones de IP. Consulte la especificación RFC 781 de la opción de marca de tiempo del protocolo de Internet.

Finalmente, aunque todo aquí fue escrito desde una perspectiva IPv4, según la pregunta original; pero el ping en IPv6 es extremadamente similar, vea ICMPv6 RFC 4443 .

Al menos con la pingutilidad común en Linux, el momento en que se envió el paquete se almacena en la parte de datos del paquete de solicitud de eco, es decir, después de los encabezados IP e ICMP. La parte de datos se mantiene intacta cuando el receptor responde con una respuesta de eco, para que el remitente pueda calcular el tiempo de ida y vuelta.

Esto se describe en la páginaping del manual de la utilidad (en "DETALLES DEL PAQUETE ICMP"):

Si el espacio de datos es al menos del tamaño de struct timevalping, utiliza los bytes iniciales de este espacio para incluir una marca de tiempo que utiliza en el cálculo de los tiempos de ida y vuelta. Si el espacio de datos es más corto, no se dan tiempos de ida y vuelta.

En mi máquina sizeof(struct timeval)es 16, por lo que establecer el tamaño de paquete de datos en 15 evita que se pingmuestren los tiempos de ida y vuelta:

$ 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

Por supuesto, almacenar la marca de tiempo de envío dentro de la utilidad, como describe la respuesta de @ jonathanjo, también sería una posible implementación. Incluso la utilidad Linux necesita algo de contabilidad interna, ya que detecta paquetes duplicados.