rfc9769.original   rfc9769.txt 
Internet Engineering Task Force M. Lichvar Internet Engineering Task Force (IETF) M. Lichvar
Internet-Draft Red Hat Request for Comments: 9769 Red Hat
Updates: 5905 (if approved) A. Malhotra Updates: 5905 A. Malhotra
Intended status: Standards Track Boston University Category: Standards Track Boston University
Expires: 10 May 2025 6 November 2024 ISSN: 2070-1721 May 2025
NTP Interleaved Modes NTP Interleaved Modes
draft-ietf-ntp-interleaved-modes-08
Abstract Abstract
This document specifies interleaved modes for the Network Time This document specifies interleaved modes for the Network Time
Protocol (NTP), which improve the accuracy of time synchronization by Protocol (NTP). These new modes improve the accuracy of time
enabling use of more accurate transmit timestamps that are available synchronization by enabling the use of more accurate transmit
only after the transmission of NTP messages. These enhancements are timestamps that are available only after the transmission of NTP
intended to improve timekeeping in environments where high accuracy messages. These enhancements are intended to improve timekeeping in
is critical. This document updates RFC 5905 by defining these new environments where high accuracy is critical. This document updates
operational modes. RFC 5905 by defining these new operational modes.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 10 May 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9769.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language
2. Interleaved Client/Server Mode . . . . . . . . . . . . . . . 4 2. Interleaved Client/Server Mode
3. Interleaved Symmetric Mode . . . . . . . . . . . . . . . . . 9 3. Interleaved Symmetric Mode
4. Interleaved Broadcast Mode . . . . . . . . . . . . . . . . . 11 4. Interleaved Broadcast Mode
5. Impact of Implementation Errors . . . . . . . . . . . . . . . 12 5. Impact of Implementation Errors
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses
1. Introduction 1. Introduction
RFC 5905 [RFC5905] describes the operations of NTPv4 in a client/ RFC 5905 [RFC5905] describes the operations of NTPv4 in a client/
server, symmetric, and broadcast mode. The transmit and receive server mode, symmetric mode, and broadcast mode. The transmit and
timestamps are two of the four timestamps included in every NTPv4 receive timestamps are two of the four timestamps included in every
packet used for time synchronization. NTPv4 packet used for time synchronization.
For a highly accurate and stable synchronization, the transmit and For a highly accurate and stable synchronization, the transmit and
receive timestamp should be captured close to the beginning of the receive timestamps should be captured close to the beginning of the
actual transmission and the end of the reception respectively. An actual transmission and the end of the reception, respectively. An
asymmetry in the timestamping causes the offset measured by NTP to asymmetry in the timestamping causes the offset measured by NTP to
have an error. have an error.
There are at least four options where a timestamp of an NTP packet Four options where a timestamp of an NTP packet may be captured with
may be captured with a software NTP implementation running on a a software NTP implementation running on a general-purpose operating
general-purpose operating system: system are as follows:
1. User space (software) 1. User space (software)
2. Network device driver or kernel (software) 2. Network device driver or kernel (software)
3. Data link layer (hardware - MAC chip) 3. Data link layer (hardware - MAC chip)
4. Physical layer (hardware - PHY chip) 4. Physical layer (hardware - PHY chip)
Software timestamps captured in user space in the NTP implementation Software timestamps captured in the user space in the NTP
itself are least accurate. They do not account for delays due to implementation itself are the least accurate. They do not account
system calls used for sending and receiving packets, processing and for delays due to system calls used for sending and receiving
queuing delays in the system, network device drivers, and hardware. packets, processing and queuing delays in the system, network device
Hardware timestamps captured at the physical layer are most accurate. drivers, and hardware. Hardware timestamps captured at the physical
layer are the most accurate.
A transmit timestamp captured in the driver or hardware is more A transmit timestamp captured in the driver or hardware is more
accurate than the user-space timestamp, but it is available to the accurate than the user-space timestamp, but it is available to the
NTP implementation only after it sent the packet using a system call. NTP implementation only after it sent the packet using a system call.
The timestamp cannot be included in the packet itself unless the The timestamp cannot be included in the packet itself unless the
driver or hardware supports NTP and can modify the packet before or driver or hardware supports NTP and can modify the packet before or
during the actual transmission. during the actual transmission.
The protocol described in RFC 5905 does not specify any mechanism for The protocol described in RFC 5905 [RFC5905] does not specify any
a server to provide its clients and peers with a more accurate mechanism for a server to provide its clients and peers with a more
transmit timestamp that is known only after the transmission. A accurate transmit timestamp that is known only after the
packet that strictly follows RFC 5905, i.e. it contains a transmit transmission. A packet that strictly follows RFC 5905 [RFC5905],
timestamp corresponding to the packet itself, is said to be in basic i.e., that contains a transmit timestamp corresponding to the packet
mode. itself, is said to be in the basic mode.
Different mechanisms could be used to exchange timestamps known after Different mechanisms could be used to exchange timestamps known after
the transmission. The server could respond to each request with two the transmission. The server could respond to each request with two
packets. The second packet would contain the transmit timestamp packets. The second packet would contain the transmit timestamp
corresponding to the first packet. However, such a protocol would corresponding to the first packet. However, such a protocol would
enable a traffic amplification attack, or it would use packets with enable a traffic amplification attack, or it would use packets with
an asymmetric length, which would cause an asymmetry in the network an asymmetric length, which would cause an asymmetry in the network
delay and an error in the measured offset. delay and an error in the measured offset.
This document describes an interleaved client/server, interleaved This document describes an interleaved client/server mode,
symmetric, and interleaved broadcast mode. In these modes, the interleaved symmetric mode, and interleaved broadcast mode. In these
server sends a packet which 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 broadcast An NTPv4 implementation that supports the interleaved client/server
interleaved modes interoperates with NTPv4 implementations without and interleaved broadcast modes interoperates with NTPv4
this capability. A peer using the symmetric interleaved mode does implementations without this capability. A peer using the
not fully interoperate with a peer which does not support it. The interleaved symmetric mode does not fully interoperate with a peer
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 timestamp. 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 be valid only 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 interleaved mode received a response conforming to does not support the interleaved mode received a response conforming
the interleaved mode, it would be rejected as bogus. to the interleaved mode, it would be rejected as bogus.
An explicit negotiation would require a new extension field. RFC An explicit negotiation would require a new extension field. RFC
5905 does not specify how servers should handle requests with an 5905 [RFC5905] does not specify how servers should handle requests
unknown extension field. The original use of extension fields was with an unknown extension field. The original use of extension
authentication with Autokey [RFC5906], which cannot be negotiated. fields was authentication with Autokey [RFC5906], which cannot be
Some existing implementations do not respond to requests with unknown negotiated. Some existing implementations do not respond to requests
extension fields. This behavior would prevent clients from reliably with unknown extension fields. This behavior would prevent clients
detecting support for the interleaved mode. from reliably detecting support for the interleaved mode.
Requests and responses cannot always be formed in interleaved mode. Requests and responses cannot always be formed in the interleaved
It cannot be used exclusively. Servers, clients, and peers that mode. It cannot be used exclusively. Servers, clients, and peers
support the interleaved mode need to support also the basic mode. that support the interleaved mode need to also support the basic
mode.
This document assumes familiarity with RFC 5905. This document assumes familiarity with RFC 5905 [RFC5905].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Interleaved Client/Server Mode 2. Interleaved Client/Server Mode
The interleaved client/server mode is similar to the basic client/ The interleaved client/server mode is similar to the basic client/
server mode. The difference between the two modes is in the values server mode. The difference between the two modes is in the values
saved to the origin and transmit timestamp fields. saved to the origin and transmit timestamp fields.
The origin timestamp is a cookie which is used to detect that a The origin timestamp is a cookie that is used to detect that a
received packet is a response to the last packet sent in the other received packet is a response to the last packet sent in the other
direction of the association. It is a copy of one of the timestamps direction of the association. It is a copy of one of the timestamps
from the packet to which it is responding, or zero if it is not a from the packet to which it is responding, or zero if it is not a
response. Servers following RFC 5905 ignore the origin timestamp in response. Servers following RFC 5905 [RFC5905] ignore the origin
client requests. A server response which does not have a matching timestamp in client requests. A server response that does not have a
origin timestamp is called bogus. matching origin timestamp is considered bogus.
A client request in the basic mode has an origin timestamp equal to A client request in the basic mode has an origin timestamp equal to
the transmit timestamp from the last valid server response, or is the transmit timestamp from the last valid server response, or the
zero (which indicates the first request of the association). A origin timestamp is zero (which indicates the first request of the
server response in the basic mode has an origin timestamp equal to association). A server response in the basic mode has an origin
the transmit timestamp from the client request. The transmit timestamp equal to the transmit timestamp from the client request.
timestamp in the response corresponds to the transmission of the The transmit timestamp in the response corresponds to the
response in which the timestamp is contained. transmission of the response in which the timestamp is contained.
A client request in the interleaved mode has an origin timestamp A client request in the interleaved mode has an origin timestamp
equal to the receive timestamp from the last valid server response. equal to the receive timestamp from the last valid server response.
A server response in the interleaved mode has an origin timestamp A server response in the interleaved mode has an origin timestamp
equal to the receive timestamp from the client request. The transmit equal to the receive timestamp from the client request. The transmit
timestamp in the response corresponds to the transmission of the timestamp in the response corresponds to the transmission of the
previous response which had the receive timestamp equal to the origin previous response that had the receive timestamp equal to the origin
timestamp from the request. timestamp from the request.
A server which supports the interleaved mode needs to save pairs of A server that supports the interleaved mode needs to save pairs of
local receive and transmit timestamps. The server SHOULD discard old local receive and transmit timestamps. The server SHOULD discard old
timestamps to limit the amount of memory used for the interleaved timestamps to limit the amount of memory used for the interleaved
mode, e.g. by using a fixed-length queue and dropping old timestamps mode, e.g., by using a fixed-length queue and dropping old timestamps
as new timestamps are saved. The server MAY separate the timestamps as new timestamps are saved. The server MAY separate the timestamps
by IP addresses, but it SHOULD NOT separate them by port numbers to by IP addresses, but it SHOULD NOT separate them by port numbers to
support clients that change their port between requests, as support clients that change their port between requests, as
recommended in RFC 9109 [RFC9109]. recommended in RFC 9109 [RFC9109].
The server MAY restrict the interleaved mode to specific IP addresses The server MAY restrict the interleaved mode to specific IP addresses
and/or authenticated clients. and/or authenticated clients.
Both servers and clients that support the interleaved mode MUST NOT Both servers and clients that support the interleaved mode MUST NOT
send a packet that has a transmit timestamp equal to the receive send a packet that has a transmit timestamp equal to the receive
timestamp in order to reliably detect whether received packets timestamp in order to reliably detect whether received packets
conform to the interleaved mode. One way to ensure that is to conform to the interleaved mode. One way to ensure this behavior is
increment the transmit timestamp by 1 unit (i.e. about 1/4 of a to increment the transmit timestamp by 1 unit (i.e., about 1/4 of a
nanosecond) if the two timestamps are equal, or a new timestamp can nanosecond) if the two timestamps are equal, or a new timestamp can
be generated. be generated.
The transmit and receive timestamps in server responses need to be The transmit and receive timestamps in server responses need to be
unique to prevent two different clients from sending requests with unique to prevent two different clients from sending requests with
the same origin timestamp and the server responding in the the same origin timestamp and the server responding in the
interleaved mode with an incorrect transmit timestamp. If the interleaved mode with an incorrect transmit timestamp. If the
timestamps are not guaranteed to be monotonically increasing, the timestamps are not guaranteed to be monotonically increasing, the
server SHOULD check that the transmit and receive timestamps are not server SHOULD check that the transmit and receive timestamps are not
already saved as a receive timestamp of a previous request (from the already saved as a receive timestamp of a previous request (from the
skipping to change at page 6, line 13 skipping to change at line 239
in the interleaved mode unless the following two conditions are met: in the interleaved mode unless the following two conditions are met:
1. The request does not have a receive timestamp equal to the 1. The request does not have a receive timestamp equal to the
transmit timestamp. transmit timestamp.
2. The origin timestamp from the request matches the local receive 2. The origin timestamp from the request matches the local receive
timestamp of a previous request that the server has saved (for timestamp of a previous request that the server has saved (for
the IP address if it separates timestamps by addresses). the IP address if it separates timestamps by addresses).
A response in the interleaved mode MUST contain the transmit A response in the interleaved mode MUST contain the transmit
timestamp of the response which contained the receive timestamp timestamp of the response that contained the receive timestamp
matching the origin timestamp from the request. The server can drop matching the origin timestamp from the request. The server can drop
the timestamps after sending the response. The receive timestamp the timestamps after sending the response. The receive timestamp
MUST NOT be used again to detect a request conforming to the MUST NOT be used again to detect a request conforming to the
interleaved mode. interleaved mode.
If the conditions are not met (i.e. the request is not detected to If the conditions are not met (i.e., the request is not detected to
conform to the interleaved mode), the server MUST NOT respond in the conform to the interleaved mode), the server MUST NOT respond in the
interleaved mode. If it responds, it MUST be in the basic mode. In interleaved mode. If it responds, it MUST be in the basic mode. In
any case, the server SHOULD save the new receive and transmit any case, the server SHOULD save the new receive and transmit
timestamps to be able to respond in the interleaved mode to the next timestamps to be able to respond in the interleaved mode to the next
request from the client. request from the client.
The first request from a client is always in the basic mode and so is The first request from a client is always in the basic mode, and so
the server response. It has a zero origin timestamp and zero receive is the server response. It has a zero origin timestamp and zero
timestamp. Only when the client receives a valid response from the receive timestamp. Only when the client receives a valid response
server, it will be able to send a request in the interleaved mode. from the server will it be able to send a request in the interleaved
mode.
The protocol recovers from packet loss. When a client request or The protocol recovers from packet loss. When a client request or
server response is lost, the client will use the same origin server response is lost, the client will use the same origin
timestamp in the next request. The server can respond in the timestamp in the next request. The server can respond in the
interleaved mode if it still has the timestamps corresponding to the interleaved mode if it still has the timestamps corresponding to the
origin timestamp. If the server already responded to the timestamp origin timestamp. If the server already responded to the timestamp
in the interleaved mode, or it had to drop the timestamps for other in the interleaved mode or it had to drop the timestamps for other
reasons, it will respond in the basic mode and save new timestamps, reasons, it will respond in the basic mode and save new timestamps,
which will enable an interleaved response to the subsequent request. which will enable an interleaved response to the subsequent request.
The client SHOULD limit the number of requests in the interleaved The client SHOULD limit the number of requests in the interleaved
mode between server responses to prevent processing of very old mode between server responses to prevent the processing of very old
timestamps in case a large number of consecutive requests is lost. timestamps in cases where a large number of consecutive requests are
lost.
An example of packets in a client/server exchange using the An example of packets in a client/server exchange using the
interleaved mode is shown in Figure 1. The packets in the basic and interleaved mode is shown in Figure 1. The packets in the basic and
interleaved mode are indicated with B and I respectively. The interleaved modes are indicated with B and I, respectively. The
timestamps t1~, t3~ and t11~ point to the same transmissions as t1, timestamps t1~, t3~, and t11~ point to the same transmissions as t1,
t3 and t11, but they may be less accurate. The first exchange is in t3, and t11, but they may be less accurate. The first exchange is in
the basic mode followed by a second exchange in the interleaved mode. the basic mode followed by a second exchange in the interleaved mode.
For the third exchange, the client request is in the interleaved For the third exchange, the client request is in the interleaved
mode, but the server response is in the basic mode, because the mode, but the server response is in the basic mode, because the
server did not have the pair of timestamps t6 and t7 (e.g. they were server did not have the pair of timestamps t6 and t7 (e.g., they were
dropped to save timestamps for other clients using the interleaved dropped to save timestamps for other clients using the interleaved
mode). mode).
Server t2 t3 t6 t7 t10 t11 t2 t3 t6 t7 t10 t11
-----+----+----------------+----+----------------+----+----- Server -----+----+----------------+----+----------------+----+-----
/ \ / \ / \ / \ / \ / \
Client / \ / \ / \ / \ / \ / \
--+----------+----------+----------+----------+----------+-- Client --+----------+----------+----------+----------+----------+--
t1 t4 t5 t8 t9 t12 t1 t4 t5 t8 t9 t12
Mode: B B I I I B Mode B B I I I B
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Org | 0 | | t1~| | t2 | | t4 | | t6 | | t5 | Origin | 0 | | t1~| | t2 | | t4 | | t6 | | t5 |
Rx | 0 | | t2 | | t4 | | t6 | | t8 | |t10 | Rx | 0 | | t2 | | t4 | | t6 | | t8 | |t10 |
Tx | t1~| | t3~| | t1 | | t3 | | t5 | |t11~| Tx | t1~| | t3~| | t1 | | t3 | | t5 | |t11~|
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Figure 1: Packet timestamps in interleaved client/server mode Figure 1: Packet Timestamps in Interleaved Client/Server Mode
When the client receives a response from the server, it performs the When the client receives a response from the server, it performs the
tests described in RFC 5905. Two of the tests are modified for the tests described in RFC 5905 [RFC5905]. Two of the tests are modified
interleaved mode: for the interleaved mode:
1. The check for duplicate packets compares both receive and 1. The check for duplicate packets compares both receive and
transmit timestamps in order to not drop a valid response in the transmit timestamps in order to not drop a valid response in the
interleaved mode if it follows a response in the basic mode and interleaved mode if it follows a response in the basic mode and
they contain the same transmit timestamp. they contain the same transmit timestamp.
2. The check for bogus packets compares the origin timestamp with 2. The check for bogus packets compares the origin timestamp with
both transmit and receive timestamps from the request. If the both transmit and receive timestamps from the request. If the
origin timestamp is equal to the transmit timestamp, the response origin timestamp is equal to the transmit timestamp, the response
is in the basic mode. If the origin timestamp is equal to the is in the basic mode. If the origin timestamp is equal to the
receive timestamp, the response is in the interleaved mode. receive timestamp, the response is in the interleaved mode.
The client SHOULD NOT update its NTP state when an invalid response The client SHOULD NOT update its NTP state when an invalid response
is received, to not lose the timestamps which will be needed to is received, so that the timestamps that will be needed to complete a
complete a measurement when the subsequent response in the measurement when the subsequent response in the interleaved mode is
interleaved mode is received. received will not be lost.
If the packet passed the tests and conforms to the interleaved mode, If the packet passed the tests and conforms to the interleaved mode,
the client can compute the offset and delay using the formulas from the client can compute the offset and delay using the formulas from
RFC 5905 and one of two different sets of timestamps. The first set RFC 5905 [RFC5905] and one of two different sets of timestamps. The
is RECOMMENDED for clients that filter measurements based on the first set is RECOMMENDED for clients that filter measurements based
delay. The corresponding timestamps from Figure 1 are written in on the delay. The corresponding timestamps from Figure 1 are written
parentheses. in parentheses.
T1 - local transmit timestamp of the previous request (t1) * T1 - local transmit timestamp of the previous request (t1)
T2 - remote receive timestamp from the previous response (t2) * T2 - remote receive timestamp from the previous response (t2)
T3 - remote transmit timestamp from the latest response (t3) * T3 - remote transmit timestamp from the latest response (t3)
T4 - local receive timestamp of the previous response (t4) * T4 - local receive timestamp of the previous response (t4)
The second set gives a more accurate measurement of the current The second set gives a more accurate measurement of the current
offset, but the delay is much more sensitive to a frequency error offset, but the delay is much more sensitive to a frequency error
between the server and client due to a much longer interval between between the server and client due to a much longer interval between
T1 and T4. T1 and T4.
T1 - local transmit timestamp of the latest request (t5) * T1 - local transmit timestamp of the latest request (t5)
T2 - remote receive timestamp from the latest response (t6) * T2 - remote receive timestamp from the latest response (t6)
T3 - remote transmit timestamp from the latest response (t3) * T3 - remote transmit timestamp from the latest response (t3)
T4 - local receive timestamp of the previous response (t4) * T4 - local receive timestamp of the previous response (t4)
Clients MAY filter measurements based on the mode. The maximum Clients MAY filter measurements based on the mode. The maximum
number of dropped measurements in the basic mode SHOULD be limited in number of dropped measurements in the basic mode SHOULD be limited in
case the server does not support or is not able to respond in the cases where the server does not support, or is not able to respond
interleaved mode. Clients that filter measurements based on the in, the interleaved mode. Clients that filter measurements based on
delay will implicitly prefer measurements in the interleaved mode the delay will implicitly prefer measurements in the interleaved mode
over the basic mode, because they have a shorter delay due to a more over the basic mode, because they have a shorter delay due to a more
accurate transmit timestamp (T3). accurate transmit timestamp (T3).
The server MAY limit saving of the receive and transmit timestamps to The server MAY limit the saving of the receive and transmit
requests which have an origin timestamp specific to the interleaved timestamps to requests that have an origin timestamp specific to the
mode in order to not waste resources on clients using the basic mode. interleaved mode in order to not waste resources on clients using the
Such an optimization will delay the first interleaved response of the basic mode. Such an optimization will delay the first interleaved
server to a client by one exchange. response of the server to a client by one exchange.
A check for a non-zero origin timestamp works with NTP clients that A check for a non-zero origin timestamp works with NTP clients that
always set the timestamp to zero. From the server's point of view, always set the timestamp to zero. From the server's point of view,
such clients start a new association with each request. such clients start a new association with each request.
To avoid searching the saved receive timestamps for non-zero origin To avoid searching the saved receive timestamps for non-zero origin
timestamps from requests conforming to the basic mode, the server can timestamps from requests conforming to the basic mode, the server can
encode in low-order bits of the receive and transmit timestamps below encode in low-order bits of the receive and transmit timestamps below
precision of the clock a flag indicating whether the timestamp is a the precision of the clock a flag indicating whether the timestamp is
receive timestamp. If the server receives a request with a non-zero a receive timestamp. If the server receives a request with a non-
origin timestamp which does not indicate it is a receive timestamp of zero origin timestamp that does not indicate that it is a receive
the server, the request does not conform to the interleaved mode and timestamp of the server, the request does not conform to the
it is not necessary to perform the search and/or save the new receive interleaved mode, and it is not necessary to perform the search and/
and transmit timestamp. or save the new receive and transmit timestamps.
3. Interleaved Symmetric Mode 3. Interleaved Symmetric Mode
The interleaved symmetric mode uses the same principles as the The interleaved symmetric mode uses the same principles as the
interleaved client/server mode. A packet in the interleaved interleaved client/server mode. A packet in the interleaved
symmetric mode has a transmit timestamp which corresponds to the symmetric mode has a transmit timestamp that corresponds to the
transmission of the previous packet sent to the peer and an origin transmission of the previous packet sent to the peer and an origin
timestamp equal to the receive timestamp from the last packet timestamp equal to the receive timestamp from the last packet
received from the peer. received from the peer.
To enable synchronization in both directions of a symmetric To enable synchronization in both directions of a symmetric
association, both peers need to support the interleaved mode. For association, both peers need to support the interleaved mode. For
this reason, it SHOULD be disabled by default and enabled with an this reason, it SHOULD be disabled by default and enabled with an
option in the configuration of the active side of the association. option in the configuration of the active side of the association.
In order to prevent the peer from matching the transmit timestamp In order to prevent a peer from matching transmit timestamps with
with an incorrect packet when the peers' transmissions do not incorrect packets when its transmissions do not alternate with
alternate (e.g. they use different polling intervals) and a previous transmissions of its peer (e.g., they use different polling
packet was lost, the use of the interleaved mode in symmetric intervals) and one or more previous packets were lost, the use of the
associations requires additional restrictions. interleaved mode in symmetric associations requires additional
restrictions.
Peers which have an association need to count valid packets received Peers that have an association need to count valid packets received
between their transmissions to determine in which mode a packet between their transmissions to determine in which mode a packet
should be formed. A valid packet in this context is a packet which should be formed. A valid packet in this context is a packet that
passed all NTP tests for duplicate, replayed, bogus, and passed all NTP tests for duplicate, replayed, bogus, and
unauthenticated packets. Other received packets may update the NTP unauthenticated packets. Other received packets may update the NTP
state to allow the (re)initialization of the association, but they do state to allow the (re)initialization of the association, but they do
not change the selection of the mode. not change the selection of the mode.
A peer A MUST NOT send a peer B a packet in the interleaved mode A Peer A MUST NOT send a Peer B a packet in the interleaved mode
unless all of the following conditions are met: unless all of the following conditions are met:
1. The peer A has an active association with the peer B which was 1. Peer A has an active association with Peer B that was specified
specified with the option enabling the interleaved mode, OR the with the option enabling the interleaved mode, OR Peer A received
peer A received at least one valid packet in the interleaved mode at least one valid packet in the interleaved mode from Peer B.
from the peer B.
2. The peer A did not send a packet to the peer B since it received 2. Peer A did not send a packet to Peer B since the time that it
the last valid packet from the peer B. received the last valid packet from Peer B.
3. The previous packet that the peer A sent to the peer B was the 3. The previous packet that Peer A sent to Peer B was the only
only response to a packet received from the peer B. response to a packet received from Peer B.
The first condition is needed for compatibility with implementations The first condition is needed for compatibility with implementations
that do not support or are not configured for the interleaved mode. that do not support, or are not configured for, the interleaved mode.
The other conditions prevent a missing response from causing a The other conditions prevent a missing response from causing a
mismatch between the remote transmit (T2) and local receive timestamp mismatch between the remote transmit timestamp (T2) and local receive
(T3), which would cause a large error in the measured offset and timestamp (T3), which would cause a large error in the measured
delay. offset and delay.
An example of packets exchanged in a symmetric association is shown An example of packets exchanged in a symmetric association is shown
in Figure 2. The minimum polling interval of the peer A is twice as in Figure 2. The minimum polling interval of Peer A is twice as long
long as the maximum polling interval of the peer B. The first as the maximum polling interval of Peer B. The first packet sent by
packets sent by the peers are in the basic mode. The second and each peer is in the basic mode. The second and third packets sent by
third packet sent by the peer A is in the interleaved mode. The Peer A are in the interleaved mode. The second packet sent by Peer B
second packet sent by the peer B is in the interleaved mode, but the is in the interleaved mode, but subsequent packets sent by Peer B are
following packets sent by the peer B are in the basic mode, because in the basic mode, because multiple responses are sent for each
multiple responses are sent per request. request.
Peer A t2 t3 t6 t8 t9 t12 t14 t15 t2 t3 t6 t8 t9 t12 t14 t15
-----+--+--------+-----------+--+--------+-----------+--+----- Peer A -----+--+--------+-----------+--+--------+-----------+--+----
/ \ / / \ / / \ / \ / / \ / / \
Peer B / \ / / \ / / \ / \ / / \ / / \
--+--------+--+-----------+--------+--+-----------+--------+-- Peer B --+--------+--+-----------+--------+--+-----------+--------+-
t1 t4 t5 t7 t10 t11 t13 t16 t1 t4 t5 t7 t10 t11 t13 t16
Mode: B B I B I B B I Mode B B I B I B B I
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Org | 0 | | t1~| | t2 | | t3~| | t4 | | t3 | | t3 | |t10 | Origin | 0 | | t1~| | t2 | | t3~| | t4 | | t3 | | t3 | |t10 |
Rx | 0 | | t2 | | t4 | | t4 | | t8 | |t10 | |t10 | |t14 | Rx | 0 | | t2 | | t4 | | t4 | | t8 | |t10 | |t10 | |t14 |
Tx | t1~| | t3~| | t1 | | t7~| | t3 | |t11~| |t13~| | t9 | Tx | t1~| | t3~| | t1 | | t7~| | t3 | |t11~| |t13~| | t9 |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Figure 2: Packet timestamps in interleaved symmetric mode Figure 2: Packet Timestamps in Interleaved Symmetric Mode
If the peer A has no association with the peer B and it responds with If Peer A has no association with Peer B and it responds with
symmetric passive packets, it does not need to count the packets in symmetric passive packets, it does not need to count the packets in
order to meet the restrictions, because each request has at most one order to meet the restrictions, because each request has at most one
response. The processing of the requests can be implemented in the response. The processing of the requests can be implemented in the
same way as a server handling requests in the interleaved client/ same way as a server handling requests in the interleaved client/
server mode. server mode.
The peers can compute the offset and delay using one of the two sets The peers can compute the offset and delay using one of the two sets
of timestamps specified in the client/server section. They can of timestamps specified in Section 2. They can switch between the
switch between the sets to minimize the interval between T1 and T4 in sets to minimize the interval between T1 and T4 in order to reduce
order to reduce the error in the measured delay. the error in the measured delay.
4. Interleaved Broadcast Mode 4. Interleaved Broadcast Mode
A packet in the interleaved broadcast mode contains two transmit A packet in the interleaved broadcast mode contains two transmit
timestamps. One corresponds to the packet itself and is saved in the timestamps. One corresponds to the packet itself and is saved in the
transmit timestamp field. The other corresponds to the previous transmit timestamp field. The other corresponds to the previous
packet and is saved in the origin timestamp field. The packet is packet and is saved in the origin timestamp field. The packet is
compatible with the basic mode, which uses a zero origin timestamp. compatible with the basic mode, which uses a zero origin timestamp.
An example of packets sent in the broadcast mode is shown in An example of packets sent in the broadcast mode is shown in
Figure 3. Figure 3.
Server t1 t3 t5 t7 t1 t3 t5 t7
------+------------+------------+------------+--------- Server ------+------------+------------+------------+---------
\ \ \ \ \ \ \ \
Client \ \ \ \ \ \ \ \
---------+------------+------------+------------+------ Client ---------+------------+------------+------------+------
t2 t4 t6 t8 t2 t4 t6 t8
Mode: B I I I Mode B I I I
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Org | 0 | | t1 | | t3 | | t5 | Origin | 0 | | t1 | | t3 | | t5 |
Rx | 0 | | 0 | | 0 | | 0 | Rx | 0 | | 0 | | 0 | | 0 |
Tx | t1~| | t3~| | t5~| | t7~| Tx | t1~| | t3~| | t5~| | t7~|
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Figure 3: Packet timestamps in interleaved broadcast mode Figure 3: Packet Timestamps in Interleaved Broadcast Mode
A client which does not support the interleaved mode ignores the A client that does not support the interleaved mode ignores the
origin timestamp and processes all packets as if they were in the origin timestamp and processes all packets as if they were in the
basic mode. basic mode.
A client which supports the interleaved mode MUST check if the origin A client that supports the interleaved mode MUST check if the origin
timestamp is not zero to detect packets conforming to the interleaved timestamp is not zero to detect packets conforming to the interleaved
mode. The client SHOULD also compare the origin timestamp with the mode. The client SHOULD also compare the origin timestamp with the
transmit timestamp from the previous packet to detect lost packets. transmit timestamp from the previous packet to detect lost packets.
If the difference is larger than a specified maximum (e.g. 1 second), If the difference is larger than a specified maximum (e.g., 1
the packet SHOULD NOT be used for synchronization in the interleaved second), the packet SHOULD NOT be used for synchronization in the
mode to avoid a large error in the measurement. interleaved mode to avoid a large error in the measurement.
The client computes the offset using the origin timestamp from the The client computes the offset using the origin timestamp from the
received packet and the local receive timestamp of the previous received packet and the local receive timestamp of the previous
packet. If the client needs to measure the network delay, it SHOULD packet. If the client needs to measure the network delay, it SHOULD
use the interleaved client/server mode. If it used the basic client/ use the interleaved client/server mode. If it used the basic client/
server or symmetric mode, the less accurate measurement of the delay server mode or symmetric mode, the less accurate measurement of the
would impact also accuracy of the offset measured in the interleaved delay would also impact the accuracy of the offset measured in the
broadcast mode. interleaved broadcast mode.
5. Impact of Implementation Errors 5. Impact of Implementation Errors
The interleaved modes make NTP more complex and more sensitive to The interleaved modes make NTP more complex and more sensitive to
errors in implementations. Some errors that do not cause any implementation errors. Some errors that do not cause any problems
problems between implementations supporting only the basic mode can between implementations supporting only the basic mode can cause an
cause an occasional missing or corrupted measurement when one or both occasional missing or corrupted measurement when one or both sides
sides support the interleaved mode. This section describes the support the interleaved mode. This section describes the impact of
impact of what could possibly be the most likely errors in the most what could possibly be the most likely errors in the most commonly
commonly used mode - client/server. used mode -- client/server.
If a client that does not support the interleaved mode sets the If a client that does not support the interleaved mode sets the
origin timestamp to other values than the transmit timestamp from the origin timestamp to values other than the transmit timestamp from the
last valid server response, or zero, the origin timestamp can match a last valid server response, or zero, the origin timestamp can match a
receive timestamp of a previous server response (possibly to a receive timestamp of a previous server response (possibly to a
different client) and cause an unexpected interleaved response. The different client) and cause an unexpected interleaved response. The
client is expected to drop the response as bogus due to having a client is expected to drop the response as bogus due to having a
wrong origin timestamp. If it did not check for bogus responses, it wrong origin timestamp. If it did not check for bogus responses, it
would get a corrupted measurement with possibly a large error in the would get a corrupted measurement, possibly with a large error in the
offset and delay. It would also be vulnerable to off-path attacks. offset and delay. It would also be vulnerable to off-path attacks.
The worst case of this failure would be a client that specifically The worst-case scenario for this failure would be a client that
sets the origin timestamp to the server's receive timestamp, i.e. the specifically sets the origin timestamp to the server's receive
client accidentally implemented the interleaved mode, but it does not timestamp, i.e., the client accidentally implemented the interleaved
accept interleaved responses. This client would still be able to mode, but it does not accept interleaved responses. This client
synchronize its clock. It would drop interleaved responses as bogus would still be able to synchronize its clock. It would drop
and set the origin timestamp to the receive timestamp from the last interleaved responses as bogus and set the origin timestamp to the
valid response in the basic mode. As servers are required to not receive timestamp from the last valid response in the basic mode. As
respond twice to the same origin timestamp in the interleaved mode, servers are required to not respond twice to the same origin
at least every other response would be in the basic mode and accepted timestamp in the interleaved mode, at least every other response
by the client. would be in the basic mode and accepted by the client.
A missing or corrupted measurement can be caused also by problems on A missing or corrupted measurement can also be caused by problems on
the server side. A server which does not ensure the receive and the server side. A server that does not ensure that the receive and
transmit timestamps in its responses are unique in a sufficiently transmit timestamps in its responses are unique in a sufficiently
long interval can misinterpret requests formed correctly in the basic long interval can misinterpret requests formed correctly in the basic
mode as interleaved and respond in the interleaved mode. The mode as interleaved and respond in the interleaved mode. The
response would be dropped by the client as bogus. response would be dropped by the client as bogus.
A duplicated server receive timestamp can cause an expected A duplicated server receive timestamp can cause an expected
interleaved response to contain a transmit timestamp which does not interleaved response to contain a transmit timestamp that does not
correspond to the transmission of the previous response from which correspond to the transmission of the previous response from which
the client copied the receive timestamp to the origin timestamp in the client copied the receive timestamp to the origin timestamp in
the request, but a different response which contained the same the request, but a different response that contained the same receive
receive timestamp. The response would be accepted by the client with timestamp. The response would be accepted by the client with a small
a small error in the transmit timestamp equal to the difference error in the transmit timestamp equal to the difference between the
between the transmit timestamps of the two different responses. As transmit timestamps of the two different responses. As the requests
the two requests to which the responses responded were received at corresponding to the two different responses were received at the
the same time (according to the server's clock), the two same time (according to the server's clock), the two transmissions
transmissions would be expected to be close to each other and the would be expected to be close to each other and the difference
difference between them would be comparable to the error a basic between them would be comparable to the error a basic response
response normally has in its transmit timestamp. normally has in its transmit timestamp.
6. Security Considerations 6. Security Considerations
The security considerations of time protocols in general are The security considerations for time protocols in general are
discussed in RFC 7384 [RFC7384], and specifically the security discussed in RFC 7384 [RFC7384]. Security considerations specific to
considerations of NTP are discussed in RFC 5905. NTP are discussed in RFC 5905 [RFC5905].
Security issues that apply to the basic modes apply also to the Security issues that apply to the basic modes discussed in RFC 5905
interleaved modes. They are described in The Security of NTP's [RFC5905] also apply to the interleaved modes. These issues are
Datagram Protocol [SECNTP]. described in "The Security of NTP's Datagram Protocol" [SECNTP].
Clients and peers SHOULD NOT leak the receive timestamp in packets Clients and peers SHOULD NOT leak the receive timestamp in packets
sent to other peers or clients (e.g. as a reference timestamp) to sent to other peers or clients (e.g., as a reference timestamp) to
prevent off-path attackers from easily getting the origin timestamp prevent off-path attackers from easily getting the origin timestamp
needed to make a valid response in the interleaved mode. needed to make a valid response in the interleaved mode.
Clients using the interleaved mode SHOULD randomize all bits of Clients using the interleaved mode SHOULD randomize all bits of
receive and transmit timestamps in their requests (i.e. use a receive and transmit timestamps in their requests (i.e., provide a
precision of 32) to make it more difficult for off-path attackers to precision of 2^32 seconds) to make it more difficult for off-path
guess the origin timestamp in the server response. attackers to guess the origin timestamp in the server response.
Unlike in the basic client/server mode, clients using interleaved Unlike in the basic client/server mode, clients using the interleaved
mode cannot set the origin timestamp in their requests to zero (i.e. mode cannot set the origin timestamp in their requests to zero (i.e.,
reset the NTP association with every request) to make it more reset the NTP association with every request) to make it more
difficult to track them as they move between networks. difficult to track them as they move between networks.
Attackers can force the server to drop its timestamps in order to Attackers can force the server to drop its timestamps in order to
prevent clients from getting an interleaved response. They can send prevent clients from getting an interleaved response. They can send
a large number of requests, send requests with a spoofed source a large number of requests, send requests with a spoofed source
address, or replay an authenticated request if the interleaved mode address, or replay an authenticated request if the interleaved mode
is enabled only for authenticated clients. Clients MUST NOT rely on is enabled only for authenticated clients. Clients MUST NOT rely on
servers to be able to respond in the interleaved mode. servers to be able to respond in the interleaved mode.
Protecting symmetric associations in the interleaved mode against Protecting symmetric associations in the interleaved mode against
replay attacks is even more difficult than in the basic mode. In replay attacks is even more difficult than in the basic mode. In
both modes, the NTP state needs to be protected between the reception both modes, the NTP state needs to be protected between the reception
of the last non-replayed response and transmission of the next of the last non-replayed response and transmission of the next
request in order for the request to contain the origin timestamp request in order for the request to contain the origin timestamp
expected by the peer. The difference is in the timestamps needed to expected by the peer. The difference is in the timestamps needed to
complete a measurement. In the basic mode only one valid response is complete a measurement. In the basic mode, only one valid response
needed at a time and it is used as soon as it is received, but the is needed at a time and it is used as soon as it is received, but the
interleaved mode needs two consecutive valid responses. The NTP interleaved mode needs two consecutive valid responses. The NTP
state needs to be protected all the time to not lose the timestamps state needs to be protected at all times, so that the timestamps that
which are needed to complete the measurement when the second response are needed to complete the measurement when the second response is
is received. received will not be lost.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This document has no IANA actions.
8. Acknowledgements
The interleaved modes described in this document are based on the
implementation written by David Mills in the NTP project
(http://www.ntp.org). The specification of the broadcast mode is
based purely on this implementation. The specification of the
symmetric mode has some modifications. The client/server mode is
specified as a new mode compatible with the symmetric mode, similarly
to the basic symmetric and client/server modes.
The authors would like to thank Doug Arnold, Roman Danyliw, Reese
Enghardt, Daniel Franke, Benjamin Kaduk, Erik Kline, Catherine
Meadows, Tal Mizrahi, Steven Sommars, Harlan Stenn, Kristof Teichel,
and Gunter Van de Velde for their useful comments and suggestions.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 8.2. Informative References
[RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol [RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol
Version 4: Autokey Specification", RFC 5906, Version 4: Autokey Specification", RFC 5906,
DOI 10.17487/RFC5906, June 2010, DOI 10.17487/RFC5906, June 2010,
<https://www.rfc-editor.org/info/rfc5906>. <https://www.rfc-editor.org/info/rfc5906>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC9109] Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol [RFC9109] Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol
Version 4: Port Randomization", RFC 9109, Version 4: Port Randomization", RFC 9109,
DOI 10.17487/RFC9109, August 2021, DOI 10.17487/RFC9109, August 2021,
<https://www.rfc-editor.org/info/rfc9109>. <https://www.rfc-editor.org/info/rfc9109>.
[SECNTP] Malhotra, A., Gundy, M. V., Varia, M., Kennedy, H., [SECNTP] Malhotra, A., Van Gundy, M., Varia, M., Kennedy, H.,
Gardner, J., and S. Goldberg, "The Security of NTP's Gardner, J., and S. Goldberg, "The Security of NTP's
Datagram Protocol", 2016, Datagram Protocol", Cryptology ePrint Archive, Paper
<http://eprint.iacr.org/2016/1006>. 2016/1006, 2016, <https://eprint.iacr.org/2016/1006>.
Acknowledgements
The interleaved modes described in this document are based on the
implementation written by David Mills in the NTP project
(https://www.ntp.org). The specification of the broadcast mode is
based purely on this implementation. The specification of the
symmetric mode has some modifications. The client/server mode is
specified as a new mode compatible with the symmetric mode. It is a
simplified special case of the symmetric mode, analogously to how the
basic client/server mode is a special case of the basic symmetric
mode.
The authors would like to thank Doug Arnold, Roman Danyliw, Reese
Enghardt, Daniel Franke, Benjamin Kaduk, Erik Kline, Catherine
Meadows, Tal Mizrahi, Steven Sommars, Harlan Stenn, Kristof Teichel,
and Gunter Van de Velde for their useful comments and suggestions.
Authors' Addresses Authors' Addresses
Miroslav Lichvar Miroslav Lichvar
Red Hat Red Hat
Purkynova 115 Purkynova 115
612 00 Brno 612 00 Brno
Czech Republic Czech Republic
Email: mlichvar@redhat.com Email: mlichvar@redhat.com
Aanchal Malhotra Aanchal Malhotra
Boston University Boston University
111 Cummington St 111 Cummington St
Boston, 02215 Boston, MA 02215
United States of America United States of America
Email: aanchal4@bu.edu Email: aanchal4@bu.edu
 End of changes. 100 change blocks. 
291 lines changed or deleted 295 lines changed or added

This html diff was produced by rfcdiff 1.48.