rfc9769v2.txt   rfc9769.txt 
Internet Engineering Task Force (IETF) M. Lichvar Internet Engineering Task Force (IETF) M. Lichvar
Request for Comments: 9769 Red Hat Request for Comments: 9769 Red Hat
Updates: 5905 A. Malhotra Updates: 5905 A. Malhotra
Category: Standards Track Boston University Category: Standards Track Boston University
ISSN: 2070-1721 April 2025 ISSN: 2070-1721 May 2025
NTP Interleaved Modes NTP Interleaved Modes
Abstract Abstract
This document specifies interleaved modes for the Network Time This document specifies interleaved modes for the Network Time
Protocol (NTP). These new modes improve the accuracy of time Protocol (NTP). These new modes improve the accuracy of time
synchronization by enabling the use of more accurate transmit synchronization by enabling the use of more accurate transmit
timestamps that are available only after the transmission of NTP timestamps that are available only after the transmission of NTP
messages. These enhancements are intended to improve timekeeping in messages. These enhancements are intended to improve timekeeping in
skipping to change at line 128 skipping to change at line 128
This document describes an interleaved client/server mode, This document describes an interleaved client/server mode,
interleaved symmetric mode, and interleaved broadcast mode. In these interleaved symmetric mode, and interleaved broadcast mode. In these
modes, the server sends a packet that contains a transmit timestamp modes, the server sends a packet that contains a transmit timestamp
corresponding to the transmission of the previous packet that was corresponding to the transmission of the previous packet that was
sent to the client or peer. This transmit timestamp can be captured sent to the client or peer. This transmit timestamp can be captured
in any software or hardware component involved in the transmission of in any software or hardware component involved in the transmission of
the packet. Both servers and clients/peers are required to keep some the packet. Both servers and clients/peers are required to keep some
state specific to the interleaved mode. state specific to the interleaved mode.
An NTPv4 implementation that supports the client/server and An NTPv4 implementation that supports the interleaved client/server
interleaved broadcast modes interoperates with NTPv4 implementations and interleaved broadcast modes interoperates with NTPv4
without this capability. A peer using the interleaved symmetric mode implementations without this capability. A peer using the
does not fully interoperate with a peer that does not support it. interleaved symmetric mode does not fully interoperate with a peer
The mode needs to be configured specifically for each symmetric that does not support it. The mode needs to be configured
association. specifically for each symmetric association.
The interleaved modes do not change the NTP packet header format and The interleaved modes do not change the NTP packet header format and
do not use new extension fields. The negotiation is implicit. The do not use new extension fields. The negotiation is implicit. The
protocol is extended with new values that can be assigned to the protocol is extended with new values that can be assigned to the
origin and transmit timestamps. Servers and peers check the origin origin and transmit timestamps. Servers and peers check the origin
timestamp to detect requests conforming to the interleaved mode. A timestamp to detect requests conforming to the interleaved mode. A
response can only be valid in one mode. If a client or peer that response can only be valid in one mode. If a client or peer that
does not support the interleaved mode received a response conforming does not support the interleaved mode received a response conforming
to the interleaved mode, it would be rejected as bogus. to the interleaved mode, it would be rejected as bogus.
 End of changes. 2 change blocks. 
7 lines changed or deleted 7 lines changed or added

This html diff was produced by rfcdiff 1.48.