101
0/240
Loading content...
Network latency is invisible yet critical. A packet's journey through the network involves delays at each hop—queuing time, processing time, transmission time, and propagation time. But how do you measure these delays? How do you determine where latency is introduced?
The IPv4 Timestamp option provides a mechanism for routers to record their local time as packets pass through. This creates a timeline of the packet's journey, revealing how long each segment of the path takes. While largely superseded by modern protocols like NTP and PTP, understanding the Timestamp option provides insight into network timing fundamentals.
By the end of this page, you will understand the Timestamp option structure, its three operating modes (timestamps only, timestamps with addresses, prespecified addresses), overflow handling, practical applications for network diagnostics, and why modern networks use different timing approaches.
The Timestamp option is a Class 2 (Debugging and Measurement) option that requests routers to record their local time when processing the packet.
Option Identification:
| Field | Value | Binary | Description |
|---|---|---|---|
| Type | 68 | 01000100 | Timestamp option (0x44) |
| Copy Flag | 0 | bit 0 | NOT copied to fragments |
| Class | 2 | bits 1-2 | Debugging/Measurement |
| Number | 4 | bits 3-7 | Option number within class |
Key Characteristics:
Unlike Record Route and Source Routing (Class 0 - Control), Timestamp is Class 2. This classification indicates its purpose: diagnostic measurement rather than routing control. The class value appears in bits 1-2 of the type field.
Time Representation:
Timestamps are recorded as 32-bit unsigned integers representing milliseconds since midnight UTC.
Maximum value: 2³² - 1 = 4,294,967,295 milliseconds
Milliseconds in a day: 24 × 60 × 60 × 1000 = 86,400,000
Since max > ms/day, the value wraps around at midnight.
Values beyond 86,400,000 indicate non-standard time.
Standard Time Bit:
If a router cannot provide time in the standard format (milliseconds since midnight UTC), it should set the high-order bit of the timestamp to 1, indicating a non-standard timestamp.
The Timestamp option has a more complex structure than other options, with additional control fields.
+--------+--------+--------+--------+
| Type | Length |Pointer |Oflw|Flg|
| (68) | | | | |
+--------+--------+--------+--------+
| Timestamp #1 or |
| IP Address #1 + Timestamp |
+-----------------------------------+
| Timestamp #2 or |
| IP Address #2 + Timestamp |
+-----------------------------------+
| ... |
+-----------------------------------+
Fields:
| Field | Size | Offset | Description |
|---|---|---|---|
| Type | 1 byte | 0 | Value 68 (0x44) |
| Length | 1 byte | 1 | Total option length |
| Pointer | 1 byte | 2 | Offset to next timestamp slot (1-indexed) |
| Overflow (Oflw) | 4 bits | 3 (high) | Count of routers that couldn't record |
| Flag | 4 bits | 3 (low) | Timestamp mode (0, 1, or 3) |
| Timestamp Data | Variable | 4+ | Timestamps or IP+Timestamp pairs |
Byte 3 is split: the upper 4 bits form the Overflow counter (0-15), and the lower 4 bits specify the Flag/mode (0, 1, or 3). This packing is unusual but efficient for the limited options space.
123456789101112
// Extracting Overflow and Flag from byte 3uint8_t byte3 = option[3]; uint8_t overflow = (byte3 >> 4) & 0x0F; // Upper 4 bitsuint8_t flag = byte3 & 0x0F; // Lower 4 bits // Combining them backbyte3 = (overflow << 4) | (flag & 0x0F); // Example: byte3 = 0x23// overflow = 0x2 = 2 (2 routers couldn't record)// flag = 0x3 = 3 (prespecified addresses mode)The Flag field specifies one of three operating modes, each with different data storage requirements.
Flag = 0: Timestamps Only
Routers record only timestamps, without identifying themselves.
Flag = 1: IP Address + Timestamp Pairs
Each router records its IP address followed by its timestamp.
Flag = 3: Prespecified IP Addresses
Source pre-fills IP addresses; routers only record timestamps next to their address.
| Flag | Mode Name | Entry Size | Max Entries | Router Identifies Itself? |
|---|---|---|---|---|
| 0 | Timestamps only | 4 bytes | 9 | No |
| 1 | IP + Timestamp | 8 bytes | 4 | Yes (records own IP) |
| 3 | Prespecified | 8 bytes | 4 | Only if IP matches |
Let's examine each mode in detail with concrete byte-level examples.
Mode 0: Timestamps Only (Flag = 0)
In this mode, routers record only their timestamp. This is the most space-efficient mode but doesn't identify timestamp sources.
Mode 0: Timestamps Only═══════════════════════════════════════════════════════════════ Initial option (source creates):Offset: 0 1 2 3 4 5 6 7 8 ... +----+----+----+----+----+----+----+----+----+ | 68 | 40 | 5 | 00 | 0 | 0 | 0 | 0 | ... +----+----+----+----+----+----+----+----+----+ Type Len Ptr O|F --------TS1 slot-------- │ │ │ └── Flag = 0 (timestamps only) └──── Overflow = 0 After Router 1 (time: 36,000,000 ms = 10:00:00 UTC): +----+----+----+----+----+----+----+----+----+ | 68 | 40 | 9 | 00 | 02 | 25 | 48 | 00 | ... +----+----+----+----+----+----+----+----+----+ ↑ └──── 0x02254800 = 36,000,000 Ptr advanced to 9 (next slot) After Router 2 (time: 36,000,050 ms): +----+----+----+----+----+----+----+----+----+----+----+----+ | 68 | 40 | 13 | 00 | 02 | 25 | 48 | 00 | 02 | 25 | 48 | 32 | +----+----+----+----+----+----+----+----+----+----+----+----+ --------TS1-------- --------TS2-------- 36,000,000 ms 36,000,050 ms Delta between routers: 50 ms transit time!Mode 1: IP Address + Timestamp Pairs (Flag = 1)
Each router records its IP address followed by its timestamp, providing full attribution.
Mode 1: IP Address + Timestamp Pairs═══════════════════════════════════════════════════════════════ Initial option:Offset: 0 1 2 3 4 5 6 7 8 9 10 11 12 ... +----+----+----+----+----+----+----+----+----+----+----+----+----+ | 68 | 36 | 5 | 01 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ... +----+----+----+----+----+----+----+----+----+----+----+----+----+ Type Len Ptr O|F -----IP slot------ ----TS slot---- │ │ │ └── Flag = 1 (IP + TS pairs) └──── Overflow = 0 After Router 1 (IP: 192.168.1.1, time: 43,200,000): +----+----+----+----+----+----+----+----+----+----+----+----+----+ | 68 | 36 | 13 | 01 | C0 | A8 | 01 | 01 | 02 | 93 | 5E | 00 | ... +----+----+----+----+----+----+----+----+----+----+----+----+----+ └─192.168.1.1─┘ └─43,200,000──┘ After Router 2 (IP: 10.0.0.1, time: 43,200,100): +----+----+----+----+----+----+----+----+----+----+----+----+----+ | 68 | 36 | 21 | 01 | C0 | A8 | 01 | 01 | 02 | 93 | 5E | 00 | ... +----+----+----+----+----+----+----+----+----+----+----+----+----+ └─192.168.1.1─┘ └─43,200,000──┘ ... | 0A | 00 | 00 | 01 | 02 | 93 | 5E | 64 | ... └───10.0.0.1───┘ └─43,200,100──┘ Now we know: 192.168.1.1 recorded at 43,200,000 10.0.0.1 recorded at 43,200,100 Transit time: 100 msMode 3: Prespecified Addresses (Flag = 3)
The source pre-fills IP addresses of specific routers. Only those routers record their timestamps.
Mode 3: Prespecified Addresses═══════════════════════════════════════════════════════════════ Source creates option with specific routers:"I want timestamps from 192.168.1.1 and 10.0.0.1 only" Initial: +----+----+----+----+----+----+----+----+----+----+----+----+----+ | 68 | 20 | 5 | 03 | C0 | A8 | 01 | 01 | 0 | 0 | 0 | 0 | ... +----+----+----+----+----+----+----+----+----+----+----+----+----+ │ │ └─192.168.1.1─┘ └─Timestamp TBD─┘ │ └── Flag = 3 (prespecified) └──── Overflow = 0 ... | 0A | 00 | 00 | 01 | 0 | 0 | 0 | 0 | ... └───10.0.0.1───┘ └─Timestamp TBD─┘ Router 192.168.1.1 receives packet:1. Check if any prespecified IP matches our address2. Found match at offset 4! 3. Record timestamp at offset 84. Advance pointer After 192.168.1.1: ... | C0 | A8 | 01 | 01 | 02 | 93 | 5E | 00 | ... └─pre-filled────┘ └─NOW FILLED!──┘ Router 10.0.0.1 receives packet:1. Check prespecified IPs2. Match at next slot!3. Record timestamp After 10.0.0.1: ... | 0A | 00 | 00 | 01 | 02 | 93 | 5E | C8 | ... └─pre-filled────┘ └─NOW FILLED!──┘ Other routers that see this packet? They pass it throughunchanged - their IPs aren't in the list.Like Record Route, the Timestamp option has limited space. The Overflow counter tracks how many routers couldn't record due to insufficient space.
Overflow Mechanics:
Overflow Interpretation:
| Overflow | Meaning |
|---|---|
| 0 | All routers successfully recorded |
| 1-14 | That many routers couldn't record |
| 15 | At least 15 couldn't record (may be more) |
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758
/** * Router processing of Timestamp option with overflow handling */int process_timestamp(uint8_t *option, uint32_t my_time) { uint8_t type = option[0]; uint8_t length = option[1]; uint8_t pointer = option[2]; uint8_t oflw_flag = option[3]; uint8_t overflow = (oflw_flag >> 4) & 0x0F; uint8_t flag = oflw_flag & 0x0F; // Calculate entry size based on mode int entry_size = (flag == 0) ? 4 : 8; // Flag 0: TS only; 1,3: IP+TS // Check if there's room if (pointer + entry_size - 1 > length) { // No room - increment overflow if (overflow < 15) { overflow++; option[3] = (overflow << 4) | flag; } else { // Overflow at maximum - per RFC 791, may drop or error // Most implementations just leave at 15 } return 0; // Continue forwarding } // Record timestamp based on mode int data_offset = pointer - 1; // Convert to 0-indexed switch (flag) { case 0: // Timestamps only // Write timestamp at pointer position write_timestamp(&option[data_offset], my_time); option[2] = pointer + 4; // Advance pointer break; case 1: // IP + Timestamp pairs // Write our IP, then timestamp write_ip(&option[data_offset], my_ip); write_timestamp(&option[data_offset + 4], my_time); option[2] = pointer + 8; break; case 3: // Prespecified addresses // Check if our IP is at pointer position if (read_ip(&option[data_offset]) == my_ip) { // It's us! Record timestamp in next 4 bytes write_timestamp(&option[data_offset + 4], my_time); option[2] = pointer + 8; } // If not us, don't record or advance break; } return 0;}If the overflow counter is non-zero, the timestamp data is incomplete. The packet traversed more hops than could be recorded. In Flag 0 mode with 9 timestamps max, any path longer than 9 hops will have overflow.
The complete processing algorithm for the Timestamp option accounts for all three modes and overflow handling.
While largely superseded by modern protocols, the Timestamp option still has educational and niche applications.
Legitimate Use Cases:
Calculating One-Way Delay:
If Router A recorded timestamp 43,200,000 (12:00:00.000)
And Router B recorded timestamp 43,200,150 (12:00:00.150)
One-way delay A→B = 150 - 0 = 150 ms
BUT: This assumes synchronized clocks!
If A's clock is 100ms behind B's:
Actual delay = 150 - 100 = 50ms
The Clock Synchronization Problem:
Accurate delay measurement requires synchronized clocks. Without synchronization:
Router clocks are often inaccurate unless synchronized via NTP or PTP. Millisecond-level timestamps are only meaningful if all routers have sub-millisecond clock accuracy, which is rarely the case without dedicated timing infrastructure.
Some ping implementations support the Timestamp option via command-line flags.
Linux:
ping -T tsonly destination # Flag 0: Timestamps only
ping -T tsandaddr destination # Flag 1: Address + Timestamp
ping -T tsprespec host1 host2 # Flag 3: Prespecified addresses
Windows:
ping -s N destination
(Windows uses -s for timestamp; N = number of hops to timestamp)
# Linux: Timestamps only$ ping -T tsonly -c 1 8.8.8.8PING 8.8.8.8 (8.8.8.8) 56(124) bytes of data.64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=15.2 msTS: 43200000 43200050 43200100 [recording stopped] # Linux: Timestamps with addresses $ ping -T tsandaddr -c 1 8.8.8.864 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=15.4 msTS: 192.168.1.1 43200000 10.0.0.1 43200050 [recording stopped - only 4 entries fit] # Linux: Prespecified routers$ ping -T tsprespec 192.168.1.1 10.0.0.1 -c 1 8.8.8.864 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=15.3 msTS: 192.168.1.1 43200000 10.0.0.1 43200050 # Windows example> ping -s 4 8.8.8.8Pinging 8.8.8.8 with 32 bytes of data:Reply from 8.8.8.8: bytes=32 time=16ms TTL=57Timestamp: 192.168.1.1 : 43200000 10.0.0.1 : 43200050 # Note: Many ISPs filter timestamp options, so you may see# empty results or timeouts. Works best in controlled networks.Timestamp values are in milliseconds since midnight UTC. To convert: hours = ts / 3600000; minutes = (ts % 3600000) / 60000; seconds = (ts % 60000) / 1000. Remember timestamps may wrap at midnight or be non-standard (high bit set).
The Timestamp option's limitations led to the development of more sophisticated timing mechanisms.
Why Timestamp Option Fell Out of Use:
| Feature | IP Timestamp | ICMP Timestamp | NTP | PTP (IEEE 1588) |
|---|---|---|---|---|
| Precision | Milliseconds | Milliseconds | Milliseconds | Nanoseconds |
| Hop Count | 9 max | N/A | N/A | N/A |
| Bidirectional | No | Yes | Yes | Yes |
| Clock Sync | Required | Compensates | Provides | Provides |
| Security | Often blocked | Often blocked | Acceptable | Excellent |
| Modern Use | Rare | Rare | Common | Critical systems |
While less dangerous than Source Routing, the Timestamp option still carries security implications.
Security Concerns:
While less critical than Source Routing, many security-conscious networks filter all IP options at borders. If you don't need option processing, disable it. The performance benefit of skipping option parsing is a bonus.
# Linux iptables: Drop packets with timestamp option# Match IP option type 68 (0x44)iptables -A INPUT -m ipv4options --ts -j DROPiptables -A FORWARD -m ipv4options --ts -j DROP # Alternative: Drop ALL packets with any optionsiptables -A INPUT -m ipv4options --any -j DROP # Cisco IOS: Disable timestamp processing specifically! There's no specific command; use general option filtering:ip access-list extended NO_OPTIONS deny ip any any option any-options permit ip any any # Apply to interface:interface GigabitEthernet0/1 ip access-group NO_OPTIONS inWe've thoroughly covered the IPv4 Timestamp option. Let's consolidate the key points:
Module Complete:
You've now mastered all five IPv4 options covered in this module:
These options, while rarely used in modern networks, form the foundation for understanding protocol extensibility, router processing complexity, and the security/performance tradeoffs that influenced IPv6's different approach.
Congratulations! You now have complete mastery of IPv4 options. You understand their formats, processing algorithms, practical applications, and security implications. This knowledge is essential for packet analysis, security auditing, and deep protocol understanding.