ICMP type 14, Timestamp reply

Protocol suite:	TCP/IP.
Protocol type:	Transport layer control protocol.
Base protocol:	ICMP, Internet Control Message Protocol.
Related ICMP message:	Timestamp request.
Host implementation:	Optional.
Router implementation:	Optional.
Links:	IANA: ICMP parameters.

The Identifier and Sequence number fields should be returned to the sender unaltered.

RFC 792, page 17:

The data received (a timestamp) in the message is returned in the reply together with an additional timestamp. The timestamp is 32 bits of milliseconds since midnight UT.

The Originate Timestamp is the time the sender last touched the message before sending it, the Receive Timestamp is the time the echoer first touched it on receipt, and the Transmit Timestamp is the time the echoer last touched the message on sending it.

If the time is not available in miliseconds or cannot be provided with respect to midnight UT then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value.

The identifier and sequence number may be used by the echo sender to aid in matching the replies with the requests. For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each request sent. The destination returns these same values in the reply.

Code 0 may be received from a gateway or a host.

Host Implementation:

RFC 1122, pages 37 and 38:

Implementation of originating and processing the Timestamp option is OPTIONAL. If it is implemented, the following rules apply:

The originating host MUST record a timestamp in a Timestamp option whose Internet address fields are not pre-specified or whose first pre-specified address is the host's interface address.

The destination host MUST (if possible) add the current timestamp to a Timestamp option before passing the option to the transport layer or to ICMP for processing.

A timestamp value MUST follow the rules given in Section 3.2.2.8 for the ICMP Timestamp message.

RFC 1122, pages 43 and 44:

A host MAY implement Timestamp and Timestamp Reply. If they are implemented, the following rules MUST be followed.

The ICMP Timestamp server function returns a Timestamp Reply to every Timestamp message that is received. If this function is implemented, it SHOULD be designed for minimum variability in delay (e.g., implemented in the kernel to avoid delay in scheduling a user process).

The following cases for Timestamp are to be handled according to the corresponding rules for ICMP Echo:

The IP source address in an ICMP Timestamp Reply MUST be the same as the specific-destination address of the corresponding Timestamp Request message.

If a Source-route option is received in an ICMP Echo Request, the return route MUST be reversed and used as a Source Route option for the Timestamp Reply message.

If a Record Route and/or Timestamp option is received in a Timestamp Request, this these) option(s) SHOULD be updated to include the current host and included in the IP header of the Timestamp Reply message.

Incoming Timestamp Reply messages MUST be passed up to the ICMP user interface.

The preferred form for a timestamp value (the "standard value") is in units of milliseconds since midnight Universal Time. However, it may be difficult to provide this value with millisecond resolution. For example, many systems use clocks that update only at line frequency, 50 or 60 times per second. Therefore, some latitude is allowed in a "standard value": (a) A "standard value" MUST be updated at least 15 times per second (i.e., at most the six low-order bits of the value may be undefined). (b) The accuracy of a "standard value" MUST approximate that of operator-set CPU clocks, i.e., correct within a few minutes.

Router Implementation:

RFC 1812, page 42:

Routers MAY support the timestamp option in datagrams originated by the router. The following rules apply:

When originating a datagram containing a Timestamp Option, a router MUST record a timestamp in the option if - Its Internet address fields are not pre-specified or - Its first pre-specified address is the IP address of the logical interface over which the datagram is being sent (or the router's router-id if the datagram is being sent over an unnumbered interface).

If the router itself receives a datagram containing a Timestamp Option, the router MUST insert the current time into the Timestamp Option (if there is space in the option to do so) before passing the option to the transport layer or to ICMP for processing. If space is not present, the router MUST increment the Overflow Count in the option.

To maximize the utility of the timestamps contained in the timestamp option, the timestamp inserted should be, as nearly as practical, the time at which the packet arrived at the router. For datagrams originated by the router, the timestamp inserted should be, as nearly as practical, the time at which the datagram was passed to the Link Layer for transmission.

The timestamp option permits the use of a non-standard time clock, but the use of a non-synchronized clock limits the utility of the time stamp. Therefore, routers are well advised to implement the Network Time Protocol for the purpose of synchronizing their clocks.

MAC header

IP header

ICMP message 14

Data

Message format:

00	08	16
Type	Code	ICMP header checksum
Identifier		Sequence number
Originate timestamp
Receive timestamp
Transmit timestamp

Type. 8 bits. Set to 14.

Code. 8 bits. Always cleared to 0.

ICMP Header Checksum. 16 bits.
The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type field. When the checksum is computed, the checksum field should first be set to 0. When the data packet is transmitted, the checksum is computed and inserted into this field. When the data packet is received, the checksum is again computed and verified against the checksum field. If the two checksums do not match then an error has occurred.

Identifier. 16 bits.
If code is zero then an identifier is used to help match timestamp requests to the associated reply. It may be cleared to zero.

Sequence number. 16 bits.
If code is zero then a sequence number is used to help match timestamp requests to the associated reply. It may be cleared to zero.

Originate timestamp. 32 bits.

Receive timestamp. 32 bits.

Transmit timestamp. 32 bits.

Glossary:

RFCs:

[RFC 792] INTERNET CONTROL MESSAGE PROTOCOL.