Summary
- IPv4 option 68 defined a finite, packet-carried record in which participating systems could append timestamps or address-and-timestamp pairs.
- The mechanism survived in host and router requirements, yet unauthenticated entries, unsynchronised clocks, information disclosure and widespread filtering steadily reduced its operational value.
A writable notebook inside the header
The original IPv4 specification did not treat a packet as a sealed message. Among its options was Internet Timestamp, type 68: a request that systems processing the datagram add observations to space reserved by the sender. The copy bit was zero, so the option belonged only to the first fragment, and it could occur no more than once in a datagram.
Its internal layout made the bargain explicit. A length octet bounded the whole option at 40 octets. A pointer identified the next available slot, with 5 as the smallest legal value. Four bits counted overflow; four more selected the recording mode. When the option had no room for another entry, a participant incremented the overflow counter instead of writing beyond the declared boundary. If that four-bit counter itself overflowed, or if the length or pointer was invalid, the datagram was erroneous and had to be discarded; an ICMP Parameter Problem could be sent.
This was not merely a clock field. Flag 0 asked for consecutive 32-bit timestamps. Flag 1 asked each participant to write its Internet address before its timestamp. Flag 3 arrived with addresses already specified and invited a timestamp only when the next address matched the machine doing the processing. The preferred time value was milliseconds since midnight Universal Time. A machine without that time base could write another value only by setting the high-order bit to mark it as non-standard.
The option therefore carried a compact record of participation, not a neutral measurement of the whole path. Each entry said what one implementation chose and was able to write, under its own clock and the selected mode. It did not authenticate the writer, compel every hop to join, supply a date, or make clocks comparable.
Requirements preserved the cooperation model
Later host requirements made both originating and processing the option optional. A host that implemented origination had to record its own timestamp when the selected mode allowed it; a destination implementing processing had, if possible, to append the current value before passing the option upward. The time rules continued to prefer milliseconds since midnight UT and required the non-standard marker when a correct value was unavailable.
Router requirements were stronger. RFC 1812 required routers to support the option in forwarded packets. In the prespecified-address mode, a router recorded only when the next address matched one of its addresses, not necessarily the incoming or outgoing interface. Implementations could offer a switch that left flag-0 or flag-1 options unchanged, but that switch had to default off. The same document also exposed the central measurement problem: timestamps were most useful when inserted close to arrival, while unsynchronised clocks limited what comparisons could mean.
From diagnostic request to filtered exception
By 2014, the security and operational balance had changed. RFC 7126 described the option as a troubleshooting mechanism that could reveal processing times and, in some modes, device addresses. Those observations could also disclose topology, machine time, implementation characteristics and perhaps physical-device identity through clock skew. An instrument designed to make the path observable also made the path more legible to an unwanted observer.
Filtering weakened the remaining case for the mechanism. Ordinary ping did not require IPv4 options, while option-dependent diagnostics could fail wherever an administrative boundary dropped them. RFC 7126 judged timestamp-option techniques already virtually unusable because dropping was widespread, and recommended that routers, security gateways and firewalls discard packets containing the option.
Sources
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
