Resumen

  • La opción Tipo 68 de RFC 791 permitía que módulos IP añadieran una hora, a veces junto a una dirección; el contador de desbordamiento de cuatro bits registraba los módulos que no pudieron escribir por falta de espacio.
  • Como los relojes podían no estar sincronizados y el registro tenía un límite, la opción conservaba observaciones parciales, no una medida fiable del retardo extremo a extremo.

Una hora dentro del datagrama

La RFC 791 definió la opción Internet Timestamp, Tipo 68. El emisor reservaba espacio en la cabecera IP y cada módulo IP participante podía escribir una marca temporal al procesar el datagrama. El valor era un contador de 32 bits en milisegundos desde la medianoche UT. Si no se disponía de UT o de un reloj expresado en UT, el bit más alto señalaba un valor no estándar.

Los indicadores cambiaban el contenido de cada posición. La bandera 0 guardaba solo la hora. La bandera 1 emparejaba una dirección con cada hora. La bandera 3 incluía direcciones de antemano y un módulo añadía la hora únicamente si su dirección coincidía con la siguiente de la lista. Un puntero señalaba la próxima posición disponible. La opción no podía superar 40 octetos: el emisor tenía que decidir cuánto espacio de cabecera dedicar al registro.

Ese límite da sentido específico al contador de desbordamiento. Sus cuatro bits contaban los módulos IP que encontraban la opción llena y no podían añadir una marca temporal. Cuando ya no había espacio, el módulo reenviaba el paquete e incrementaba el contador. Pero si quedaba espacio insuficiente para una entrada completa, o si el propio contador excedía su rango, RFC 791 consideraba erróneo el datagrama y permitía enviar un mensaje ICMP Parameter Problem. El campo no identificaba qué router faltaba ni por qué.

La especificación también limitó el recorrido del registro: la opción no se copiaba a los fragmentos y solo podía aparecer una vez. Por ello, no se podía presumir que cada fragmento llevara un historial de ruta completo.

Observaciones, no tiempo transcurrido

Una secuencia de horas puede parecer una traza de latencia. RFC 791 no garantizaba relojes sincronizados o precisos, la participación de todos los routers ni una lista completa de saltos. Cada valor reflejaba el reloj del módulo que lo escribía. La diferencia entre dos marcas puede mezclar desfases de reloj con el tiempo de tránsito real. La lectura defendible es más limitada: el paquete podía transportar un conjunto acotado de observaciones de dirección y hora, además de un contador de desbordamiento.

Los requisitos posteriores para hosts confirmaron que la función era opcional. La RFC 1122 dejó como opcionales tanto el origen como el procesamiento de la opción Timestamp. Una definición de protocolo establecía un formato y una conducta, pero no demostraba que los hosts o routers la desplegaran.

En 2014, la RFC 7126 describió riesgos para la seguridad: revelar relojes, aportar pistas topológicas e identificar dispositivos. Según su propia caracterización, el descarte generalizado hacía estas técnicas prácticamente imposibles; recomendó que routers, pasarelas de seguridad y cortafuegos DEBERÍAN descartar paquetes con la opción. Es la valoración y recomendación de esa RFC, no una medición actual de todas las redes.

La opción muestra una limitación de la observabilidad: un registro dentro del paquete puede ofrecer pistas útiles y, a la vez, ser incompleto, depender de relojes y consumir espacio de cabecera. El formato dice qué podía escribir un módulo participante; una entrada ausente no prueba que no hubiera un salto.

Fuentes