Summary

  • RFC 791’s Type 68 option let IP modules append a time, with optional address recording; its four-bit overflow count recorded modules that could not write when the option was full.
  • Because clocks could differ and the record was bounded, the option described selected processing observations rather than a reliable end-to-end delay measurement.

A clock entry inside the datagram

RFC 791 defined the Internet Timestamp option as Type 68. The sender reserved space in the IP header; each participating IP module could write a timestamp as it processed the datagram. The value was a 32-bit count of milliseconds since midnight UT. If UT was unavailable or the clock did not use it, the high bit marked the value as non-standard.

The option’s flags changed what a slot contained. Flag 0 stored time alone. Flag 1 paired an address with each time. Flag 3 supplied addresses in advance, and a module wrote a time only when its address matched the next listed address. The pointer identified the next slot. Length could not exceed 40 octets, so the sender had to choose how much of this packet’s header to spend on the record.

That limit gave the option a particular kind of negative evidence. A four-bit overflow field counted IP modules that encountered a full option and could not add a timestamp. When no room remained, a module forwarded the packet and increased the counter. But if some room remained and could not hold a complete timestamp, or if the overflow count itself exceeded its range, RFC 791 treated the datagram as erroneous and allowed an ICMP Parameter Problem report. The field did not identify which router was missing or why.

The specification also constrained where the record traveled: the option was not copied into fragments and could appear only once. A receiver therefore could not assume every fragment carried a complete route history.

Observations, not elapsed time

A sequence of timestamps can look like a latency trace. RFC 791 did not promise synchronized clocks, clock accuracy, participation by every router, or a complete list of hops. A timestamp describes what one IP module wrote using its own clock. Subtracting two values may mix clock offsets with actual transit time. The defensible reading is narrower: the packet can carry a bounded set of address-and-time observations, together with an overflow count.

The later host requirements reinforced the optional nature of the feature. RFC 1122 made originating and processing the Timestamp option optional. A protocol definition thus supplied a format and behavior without establishing that hosts or routers deployed it.

In 2014, RFC 7126 described the option as a source of clock information, topology clues and device fingerprinting. It said widespread dropping had made these techniques virtually impossible in its account, and recommended that routers, security gateways and firewalls SHOULD drop packets containing the option. That is a security recommendation and the RFC’s characterization, not a current measurement of every network.

The option’s history is a compact lesson in observability: an in-band record can expose useful traces while remaining incomplete, clock-dependent and costly in header space. Its format says what a participating module could write; it does not turn absence into proof that no hop existed.

Sources