<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-ntp-interleaved-modes-08" number="9769" updates="5905" consensus="true" ipr="trust200902" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" prepTime="2025-05-23T15:16:47" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-ntp-interleaved-modes-08" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9769" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title>NTP Interleaved Modes</title>
    <seriesInfo name="RFC" value="9769" stream="IETF"/>
    <author fullname="Miroslav Lichvar" initials="M." surname="Lichvar">
      <organization showOnFrontPage="true">Red Hat</organization>
      <address>
        <postal>
          <street>Purkynova 115</street>
          <city>Brno</city>
          <code>612 00</code>
          <country>Czech Republic</country>
        </postal>
        <email>mlichvar@redhat.com</email>
      </address>
    </author>
    <author fullname="Aanchal Malhotra" initials="A." surname="Malhotra">
      <organization showOnFrontPage="true">Boston University</organization>
      <address>
        <postal>
          <street>111 Cummington St</street>
          <city>Boston</city>
          <region>MA</region>
          <code>02215</code>
          <country>United States of America</country>
        </postal>
        <email>aanchal4@bu.edu</email>
      </address>
    </author>
    <date month="05" year="2025"/>
    <area>INT</area>
    <workgroup>ntp</workgroup>
    <keyword>NTP</keyword>
    <keyword>interleaved mode</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document specifies interleaved modes for the Network Time
        Protocol (NTP).  These new modes improve the accuracy of time synchronization by
        enabling the use of more accurate transmit timestamps that are available
        only after the transmission of NTP messages. These enhancements are
        intended to improve timekeeping in environments where high accuracy is
        critical. This document updates RFC 5905 by defining these new
        operational modes.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9769" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interleaved-client-server-m">Interleaved Client/Server Mode</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interleaved-symmetric-mode">Interleaved Symmetric Mode</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interleaved-broadcast-mode">Interleaved Broadcast Mode</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-impact-of-implementation-er">Impact of Implementation Errors</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1"><xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905">RFC 5905</xref> describes the operations of
        NTPv4 in a client/server mode, symmetric mode, and broadcast mode. The transmit
        and receive timestamps are two of the four timestamps included in every
        NTPv4 packet used for time synchronization.</t>
      <t indent="0" pn="section-1-2">For a highly accurate and stable synchronization, the transmit and
        receive timestamps should be captured close to the beginning of the
        actual transmission and the end of the reception, respectively. An
        asymmetry in the timestamping causes the offset measured by NTP to have
        an error.</t>
      <t indent="0" pn="section-1-3">Four options where a timestamp of an NTP packet may be captured with a
        software NTP implementation running on a general-purpose operating system
        are as follows:
</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-1-4"><li pn="section-1-4.1" derivedCounter="1.">
          <t indent="0" pn="section-1-4.1.1">User space (software)</t>
        </li>
        <li pn="section-1-4.2" derivedCounter="2.">
          <t indent="0" pn="section-1-4.2.1">Network device driver or kernel (software)</t>
        </li>
        <li pn="section-1-4.3" derivedCounter="3.">
          <t indent="0" pn="section-1-4.3.1">Data link layer (hardware - MAC chip)</t>
        </li>
        <li pn="section-1-4.4" derivedCounter="4.">
          <t indent="0" pn="section-1-4.4.1">Physical layer (hardware - PHY chip)</t>
        </li>
      </ol>
      <t indent="0" pn="section-1-5">Software timestamps captured in the user space in the NTP
        implementation itself are the least accurate. They do not account for
        delays due to
        system calls used for sending and receiving packets, processing and
        queuing delays in the system, network device drivers, and hardware.
        Hardware timestamps captured at the physical layer are the most
        accurate.</t>
      <t indent="0" pn="section-1-6">A transmit timestamp captured in the driver or hardware is more
        accurate than the user-space timestamp, but it is available to the NTP
        implementation only after it sent the packet using a system call. The
        timestamp cannot be included in the packet itself unless the driver or
        hardware supports NTP and can modify the packet before or during the
        actual transmission.</t>
      <t indent="0" pn="section-1-7">The protocol described in <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905">RFC 5905</xref> does not specify any mechanism for
        a server to provide its clients and peers with a more accurate transmit
        timestamp that is known only after the transmission. A packet that
        strictly follows <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905">RFC 5905</xref>, i.e., that contains a transmit timestamp
        corresponding to the packet itself, is said to be in the basic mode.</t>
      <t indent="0" pn="section-1-8">Different mechanisms could be used to exchange timestamps known after
        the transmission. The server could respond to each request with two
        packets. The second packet would contain the transmit timestamp
        corresponding to the first packet. However, such a protocol would
        enable a traffic amplification attack, or it would use packets with an
        asymmetric length, which would cause an asymmetry in the network delay
        and an error in the measured offset.</t>
      <t indent="0" pn="section-1-9">This document describes an interleaved client/server mode, interleaved
        symmetric mode, and interleaved broadcast mode. In these modes, the server
        sends a packet that contains a transmit timestamp corresponding to the
        transmission of the previous packet that was sent to the client or
        peer. This transmit timestamp can be captured in any software or
        hardware component involved in the transmission of the packet. Both
        servers and clients/peers are required to keep
        some state specific to the interleaved mode.</t>
      <t indent="0" pn="section-1-10">An NTPv4 implementation that
        supports the interleaved client/server and interleaved broadcast modes
        interoperates with NTPv4 implementations without this capability. A
        peer using the interleaved symmetric mode does not fully interoperate
        with a peer that does not support it. The mode needs to be configured
        specifically for each symmetric association.</t>
      <t indent="0" pn="section-1-11">The interleaved modes do not change the NTP packet header format and
        do not use new extension fields. The negotiation is implicit. The
        protocol is extended with new values that can be assigned to the origin
        and transmit timestamps. Servers and peers check the origin timestamp to
        detect requests conforming to the
        interleaved mode. A response can only be valid in one mode. If a client
        or peer that does not support the interleaved mode received a response
        conforming to the interleaved mode, it would be rejected as bogus.</t>
      <t indent="0" pn="section-1-12">An explicit negotiation would require a new extension field. <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905">RFC 5905</xref>
        does not specify how servers should handle requests with an unknown
        extension field. The original use of extension fields was
        authentication with <xref target="RFC5906" format="default" sectionFormat="of" derivedContent="RFC5906">Autokey</xref>, which cannot
        be negotiated. Some existing implementations do not respond to requests
        with unknown extension fields. This behavior would prevent clients from
        reliably detecting support for the interleaved mode.</t>
      <t indent="0" pn="section-1-13">Requests and responses cannot always be formed in the interleaved mode.
        It cannot be used exclusively. Servers, clients, and peers that support
        the interleaved mode need to also support the basic mode.</t>
      <t indent="0" pn="section-1-14">This document assumes familiarity with <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905">RFC 5905</xref>.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t indent="0" pn="section-1.1-1">The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
         "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
         "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
         "<bcp14>SHOULD NOT</bcp14>",
         "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
         "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
         are to be interpreted as described in BCP 14
         <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only
         when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section numbered="true" toc="include" anchor="client-server-mode" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-interleaved-client-server-m">Interleaved Client/Server Mode</name>
      <t indent="0" pn="section-2-1">The interleaved client/server mode is similar to the basic
        client/server mode. The difference between the two modes is in the values
        saved to the origin and transmit timestamp fields.</t>
      <t indent="0" pn="section-2-2">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
        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
        response. Servers following <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905">RFC 5905</xref> ignore the origin timestamp in
        client requests. A server response that does not have a matching
        origin timestamp is considered bogus.</t>
      <t indent="0" pn="section-2-3">A client request in the basic mode has an origin timestamp equal to
        the transmit timestamp from the last valid server response, or the origin timestamp is zero
        (which indicates the first request of the association). A server
        response in the basic mode has an origin timestamp equal to the
        transmit timestamp from the client request. The transmit timestamp in
        the response corresponds to the transmission of the response in which
        the timestamp is contained.</t>
      <t indent="0" pn="section-2-4">A client request in the interleaved mode has an origin timestamp equal
        to the receive timestamp from the last valid server response. A server
        response in the interleaved mode has an origin timestamp equal to the
        receive timestamp from the client request. The transmit timestamp in
        the response corresponds to the transmission of the previous response
        that had the receive timestamp equal to the origin timestamp from the
        request.</t>
      <t indent="0" pn="section-2-5">A server that supports the interleaved mode needs to save pairs of
        local receive and transmit timestamps. The server <bcp14>SHOULD</bcp14> discard old
        timestamps to limit the amount of memory used for the interleaved mode,
        e.g., by using a fixed-length queue and dropping old timestamps as new
        timestamps are saved. The server <bcp14>MAY</bcp14> separate the timestamps by
        IP addresses, but it <bcp14>SHOULD NOT</bcp14> separate them by port numbers to
        support clients that change their port between requests, as recommended
        in <xref target="RFC9109" format="default" sectionFormat="of" derivedContent="RFC9109">RFC 9109</xref>.</t>
      <t indent="0" pn="section-2-6">The server <bcp14>MAY</bcp14> restrict the interleaved mode to specific IP addresses
        and/or authenticated clients.</t>
      <t indent="0" pn="section-2-7">Both servers and clients that support the interleaved mode <bcp14>MUST NOT</bcp14>
        send a packet that has a transmit timestamp equal to the receive
        timestamp in order to reliably detect whether received packets conform
        to the interleaved mode. One way to ensure this behavior is 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 be generated.</t>
      <t indent="0" pn="section-2-8">The transmit and receive timestamps in server responses need to be
        unique to prevent two different clients from sending requests with the
        same origin timestamp and the server responding in the interleaved mode
        with an incorrect transmit timestamp. If the timestamps are not
        guaranteed to be monotonically increasing, the server <bcp14>SHOULD</bcp14> check that
        the transmit and receive timestamps are not already saved as a receive
        timestamp of a previous request (from the same IP address if the server
        separates timestamps by addresses), and generate a new timestamp if
        necessary, to prevent an incorrect interleaved response later.</t>
      <t indent="0" pn="section-2-9">When the server receives a request from a client, it <bcp14>MUST NOT</bcp14> respond
        in the interleaved mode unless the following two conditions are
        met:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2-10"><li pn="section-2-10.1" derivedCounter="1.">
          <t indent="0" pn="section-2-10.1.1">The request does not have a receive timestamp equal to the transmit
            timestamp.</t>
        </li>
        <li pn="section-2-10.2" derivedCounter="2.">
          <t indent="0" pn="section-2-10.2.1">The origin timestamp from the request matches the local receive
            timestamp of a previous request that the server has saved (for the
            IP address if it separates timestamps by addresses).</t>
        </li>
      </ol>
      <t indent="0" pn="section-2-11">A response in the interleaved mode <bcp14>MUST</bcp14> contain the transmit timestamp
        of the response that contained the receive timestamp matching the
        origin timestamp from the request. The server can drop the timestamps
        after sending the response. The receive timestamp <bcp14>MUST NOT</bcp14> be used
        again to detect a request conforming to the interleaved mode.</t>
      <t indent="0" pn="section-2-12">If the conditions are not met (i.e., the request is not detected to
        conform to the interleaved mode), the server <bcp14>MUST NOT</bcp14> respond in the
        interleaved mode. If it responds, it <bcp14>MUST</bcp14> be in the basic mode. In
        any case, the server <bcp14>SHOULD</bcp14> save the new receive and transmit
        timestamps to be able to respond in the interleaved mode to the
        next request from the client.</t>
      <t indent="0" pn="section-2-13">The first request from a client is always in the basic mode, and so is
        the server response. It has a zero origin timestamp and zero receive
        timestamp. Only when the client receives a valid response from the
        server will it be able to send a request in the interleaved mode.</t>
      <t indent="0" pn="section-2-14">The protocol recovers from packet loss. When a client request or
        server response is lost, the client will use the same origin timestamp
        in the next request. The server can respond in the interleaved mode if
        it still has the timestamps corresponding to the origin timestamp. If
        the server already responded to the timestamp 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, which will
        enable an interleaved response to the subsequent request. The client
        <bcp14>SHOULD</bcp14> limit the number of requests in the interleaved mode between
        server responses to prevent the processing of very old timestamps in cases where a
        large number of consecutive requests are lost.</t>
      <t indent="0" pn="section-2-15">An example of packets in a client/server exchange using the
        interleaved mode is shown in <xref target="client-server-exchange" format="default" sectionFormat="of" derivedContent="Figure 1"/>. The packets in the basic and
        interleaved modes are indicated with B and I, respectively. The
        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 the
        basic mode followed by a second exchange in the interleaved mode. For
        the third exchange, the client request is in the interleaved 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 dropped to save
        timestamps for other clients using the interleaved mode).</t>
      <figure anchor="client-server-exchange" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-packet-timestamps-in-interl">Packet Timestamps in Interleaved Client/Server Mode</name>
        <artwork name="" type="" align="left" alt="" pn="section-2-16.1">
            t2   t3               t6   t7              t10  t11
Server -----+----+----------------+----+----------------+----+-----
           /      \              /      \              /      \
          /        \            /        \            /        \
Client --+----------+----------+----------+----------+----------+--
         t1         t4         t5         t8         t9        t12

Mode     B         B           I         I           I         B
       +----+    +----+      +----+    +----+      +----+    +----+
Origin | 0  |    | t1~|      | t2 |    | t4 |      | t6 |    | t5 |
Rx     | 0  |    | t2 |      | t4 |    | t6 |      | t8 |    |t10 |
Tx     | t1~|    | t3~|      | t1 |    | t3 |      | t5 |    |t11~|
       +----+    +----+      +----+    +----+      +----+    +----+
</artwork>
      </figure>
      <t indent="0" pn="section-2-17">When the client receives a response from the server, it performs the
        tests described in <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905">RFC 5905</xref>. Two of the tests are modified for the
        interleaved mode:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2-18"><li pn="section-2-18.1" derivedCounter="1.">
          <t indent="0" pn="section-2-18.1.1">The check for duplicate packets compares both receive and
            transmit timestamps in order to not drop a valid response in the
            interleaved mode if it follows a response in the basic mode and
            they contain the same transmit timestamp.</t>
        </li>
        <li pn="section-2-18.2" derivedCounter="2.">
          <t indent="0" pn="section-2-18.2.1">The check for bogus packets compares the origin timestamp
            with both transmit and receive timestamps from the request. If the
            origin timestamp is equal to the transmit timestamp, the response
            is in the basic mode. If the origin timestamp is equal to the
            receive timestamp, the response is in the interleaved mode.</t>
        </li>
      </ol>
      <t indent="0" pn="section-2-19">The client <bcp14>SHOULD NOT</bcp14> update its NTP state when an invalid response is
        received, so that the timestamps that will be needed to complete a
        measurement when the subsequent response in the interleaved mode is
        received will not be lost.</t>
      <t indent="0" pn="section-2-20">If the packet passed the tests and conforms to the interleaved mode,
        the client can compute the offset and delay using the formulas from <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905">RFC 5905</xref> and one of two different sets of timestamps. The first set is
        <bcp14>RECOMMENDED</bcp14> for clients that filter measurements based on the delay.
        The corresponding timestamps from <xref target="client-server-exchange" format="default" sectionFormat="of" derivedContent="Figure 1"/> are written in
        parentheses.</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-21">
        <li pn="section-2-21.1">
          <t indent="0" pn="section-2-21.1.1">T1 - local transmit timestamp of the previous request (t1)</t>
        </li>
        <li pn="section-2-21.2">
          <t indent="0" pn="section-2-21.2.1">T2 - remote receive timestamp from the previous response (t2)</t>
        </li>
        <li pn="section-2-21.3">
          <t indent="0" pn="section-2-21.3.1">T3 - remote transmit timestamp from the latest response (t3)</t>
        </li>
        <li pn="section-2-21.4">
          <t indent="0" pn="section-2-21.4.1">T4 - local receive timestamp of the previous response (t4)</t>
        </li>
      </ul>
      <t indent="0" pn="section-2-22">The second set gives a more accurate measurement of the current
        offset, but the delay is much more sensitive to a frequency error
        between the server and client due to a much longer interval between T1
        and T4.</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-23">
        <li pn="section-2-23.1">
          <t indent="0" pn="section-2-23.1.1">T1 - local transmit timestamp of the latest request (t5)</t>
        </li>
        <li pn="section-2-23.2">
          <t indent="0" pn="section-2-23.2.1">T2 - remote receive timestamp from the latest response (t6)</t>
        </li>
        <li pn="section-2-23.3">
          <t indent="0" pn="section-2-23.3.1">T3 - remote transmit timestamp from the latest response (t3)</t>
        </li>
        <li pn="section-2-23.4">
          <t indent="0" pn="section-2-23.4.1">T4 - local receive timestamp of the previous response (t4)</t>
        </li>
      </ul>
      <t indent="0" pn="section-2-24">Clients <bcp14>MAY</bcp14> filter measurements based on the mode. The maximum number
        of dropped measurements in the basic mode <bcp14>SHOULD</bcp14> be limited in cases where the
        server does not support, or is not able to respond in, the interleaved
        mode. Clients that filter measurements based on the delay will
        implicitly prefer measurements in the interleaved mode over the basic
        mode, because they have a shorter delay due to a more accurate transmit
        timestamp (T3).</t>
      <t indent="0" pn="section-2-25">The server <bcp14>MAY</bcp14> limit the saving of the receive and transmit timestamps to
        requests that have an origin timestamp specific to the interleaved
        mode in order to not waste resources on clients using the basic mode.
        Such an optimization will delay the first interleaved response of the
        server to a client by one exchange.</t>
      <t indent="0" pn="section-2-26">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, such
        clients start a new association with each request.</t>
      <t indent="0" pn="section-2-27">To avoid searching the saved receive timestamps for non-zero origin
        timestamps from requests conforming to the basic mode, the server can
        encode in low-order bits of the receive and transmit timestamps below the
        precision of the clock a flag indicating whether the timestamp is a
        receive timestamp. If the server receives a request with a non-zero
        origin timestamp that does not indicate that it is a receive timestamp of
        the server, the request does not conform to the interleaved mode, and
        it is not necessary to perform the search and/or
        save the new receive and transmit timestamps.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-interleaved-symmetric-mode">Interleaved Symmetric Mode</name>
      <t indent="0" pn="section-3-1">The interleaved symmetric mode uses the same principles as the
        interleaved client/server mode. A packet in the interleaved symmetric
        mode has a transmit timestamp that corresponds to the transmission of
        the previous packet sent to the peer and an origin timestamp equal to
        the receive timestamp from the last packet received from the peer.</t>
      <t indent="0" pn="section-3-2">To enable synchronization in both directions of a symmetric
        association, both peers need to support the interleaved mode. For this
        reason, it <bcp14>SHOULD</bcp14> be disabled by default and enabled with an option in
        the configuration of the active side of the association.</t>
      <t indent="0" pn="section-3-3">In order to prevent a peer from matching transmit timestamps with
        incorrect packets when its transmissions do not alternate with transmissions of its peer
        (e.g., they use different polling intervals) and one or more previous packets were
        lost, the use of the interleaved mode in symmetric associations
        requires additional restrictions.</t>
      <t indent="0" pn="section-3-4">Peers that have an association need to count valid packets received
        between their transmissions to determine in which mode a packet should
        be formed. A valid packet in this context is a packet that passed all
        NTP tests for duplicate, replayed, bogus, and unauthenticated packets.
        Other received packets may update the NTP state to allow the
        (re)initialization of the association, but they do not change the
        selection of the mode.</t>
      <t indent="0" pn="section-3-5">A Peer A <bcp14>MUST NOT</bcp14> send a Peer B a packet in the interleaved mode unless
        all of the following conditions are met:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3-6"><li pn="section-3-6.1" derivedCounter="1.">
          <t indent="0" pn="section-3-6.1.1">Peer A has an active association with Peer B that was
            specified with the option enabling the interleaved mode, OR Peer
            A received at least one valid packet in the interleaved mode from
            Peer B.</t>
        </li>
        <li pn="section-3-6.2" derivedCounter="2.">
          <t indent="0" pn="section-3-6.2.1">Peer A did not send a packet to Peer B since the time that it received
            the last valid packet from Peer B.
</t>
        </li>
        <li pn="section-3-6.3" derivedCounter="3.">
          <t indent="0" pn="section-3-6.3.1">The previous packet that Peer A sent to Peer B was the
            only response to a packet received from Peer B.</t>
        </li>
      </ol>
      <t indent="0" pn="section-3-7">The first condition is needed for compatibility with implementations
        that do not support, or are not configured for, the interleaved mode. The
        other conditions prevent a missing response from causing a mismatch
        between the remote transmit timestamp (T2) and local receive timestamp (T3),
        which would cause a large error in the measured offset and delay.</t>
      <t indent="0" pn="section-3-8">An example of packets exchanged in a symmetric association is shown in
        <xref target="peer-exchange" format="default" sectionFormat="of" derivedContent="Figure 2"/>. The
        minimum polling interval of Peer A is twice as long as the maximum
        polling interval of Peer B. The first packet sent by each peer is
        in the basic mode. The second and third packets sent by Peer A are in
        the interleaved mode. The second packet sent by Peer B is in the
        interleaved mode, but subsequent packets sent by Peer B are in
        the basic mode, because multiple responses are sent for each request.
</t>
      <figure anchor="peer-exchange" align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-packet-timestamps-in-interle">Packet Timestamps in Interleaved Symmetric Mode</name>
        <artwork name="" type="" align="left" alt="" pn="section-3-9.1">
            t2 t3       t6          t8 t9      t12         t14 t15
Peer A -----+--+--------+-----------+--+--------+-----------+--+----
           /    \      /           /    \      /           /    \
          /      \    /           /      \    /           /      \
Peer B --+--------+--+-----------+--------+--+-----------+--------+-
         t1       t4 t5          t7      t10 t11        t13      t16

Mode     B      B      I         B      I      B         B      I
       +----+ +----+ +----+    +----+ +----+ +----+    +----+ +----+
Origin | 0  | | t1~| | t2 |    | t3~| | t4 | | t3 |    | t3 | |t10 |
Rx     | 0  | | t2 | | t4 |    | t4 | | t8 | |t10 |    |t10 | |t14 |
Tx     | t1~| | t3~| | t1 |    | t7~| | t3 | |t11~|    |t13~| | t9 |
       +----+ +----+ +----+    +----+ +----+ +----+    +----+ +----+
</artwork>
      </figure>
      <t indent="0" pn="section-3-10">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
        order to meet the restrictions, because each request has at most one
        response. The processing of the requests can be implemented in the same
        way as a server handling requests in the interleaved client/server
        mode.</t>
      <t indent="0" pn="section-3-11">The peers can compute the offset and delay using one of the two sets
        of timestamps specified in <xref target="client-server-mode" format="default" sectionFormat="of" derivedContent="Section 2"/>. They can switch
        between the sets to minimize the interval between T1 and T4 in order to
        reduce the error in the measured delay.
</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-interleaved-broadcast-mode">Interleaved Broadcast Mode</name>
      <t indent="0" pn="section-4-1">A packet in the interleaved broadcast mode contains two transmit
        timestamps. One corresponds to the packet itself and is saved in the
        transmit timestamp field. The other corresponds to the previous packet
        and is saved in the origin timestamp field. The packet is compatible
        with the basic mode, which uses a zero origin timestamp.</t>
      <t indent="0" pn="section-4-2">An example of packets sent in the broadcast mode is shown in
        <xref target="broadcast-transmissions" format="default" sectionFormat="of" derivedContent="Figure 3"/>.
      </t>
      <figure anchor="broadcast-transmissions" align="left" suppress-title="false" pn="figure-3">
        <name slugifiedName="name-packet-timestamps-in-interlea">Packet Timestamps in Interleaved Broadcast Mode</name>
        <artwork name="" type="" align="left" alt="" pn="section-4-3.1">
               t1           t3           t5           t7
Server   ------+------------+------------+------------+---------
                \            \            \            \
                 \            \            \            \
Client   ---------+------------+------------+------------+------
                  t2           t4           t6           t8

Mode            B            I            I            I
              +----+       +----+       +----+       +----+
Origin        | 0  |       | t1 |       | t3 |       | t5 |
Rx            | 0  |       | 0  |       | 0  |       | 0  |
Tx            | t1~|       | t3~|       | t5~|       | t7~|
              +----+       +----+       +----+       +----+
</artwork>
      </figure>
      <t indent="0" pn="section-4-4">A client that does not support the interleaved mode ignores the
        origin timestamp and processes all packets as if they were in the basic
        mode.</t>
      <t indent="0" pn="section-4-5">A client that supports the interleaved mode <bcp14>MUST</bcp14> check if the origin
        timestamp is not zero to detect packets conforming to the interleaved
        mode.
        The client <bcp14>SHOULD</bcp14> also compare the origin timestamp with the transmit
        timestamp from the previous packet to detect lost packets. If the
        difference is larger than a specified maximum (e.g., 1 second), the
        packet <bcp14>SHOULD NOT</bcp14> be used for synchronization in the interleaved
        mode to avoid a large error in the measurement.</t>
      <t indent="0" pn="section-4-6">The client computes the offset using the origin timestamp from
        the received packet and the local receive timestamp of the previous
        packet. If the client needs to measure the network delay, it <bcp14>SHOULD</bcp14> use
        the interleaved client/server mode. If it used the basic client/server mode
        or symmetric mode, the less accurate measurement of the delay would
        also impact the accuracy of the offset measured in the interleaved
        broadcast mode.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-impact-of-implementation-er">Impact of Implementation Errors</name>
      <t indent="0" pn="section-5-1">The interleaved modes make NTP more complex and more sensitive to
        implementation errors. Some errors that do not cause any problems
        between implementations supporting only the basic mode can cause
        an occasional missing or corrupted measurement when one or both sides
        support the interleaved mode. This section describes the impact of what
        could possibly be the most likely errors in the most commonly used mode
        -- client/server.</t>
      <t indent="0" pn="section-5-2">If a client that does not support the interleaved mode sets the origin
        timestamp to values other than the transmit timestamp from the last
        valid server response, or zero, the origin timestamp can match a
        receive timestamp of a previous server response (possibly to a
        different client) and cause an unexpected interleaved response. The
        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 would get a corrupted measurement, possibly with a large error in the
        offset and delay. It would also be vulnerable to off-path attacks.</t>
      <t indent="0" pn="section-5-3">The worst-case scenario for this failure would be a client that specifically sets
        the origin timestamp to the server's receive timestamp, i.e., the client
        accidentally implemented the interleaved mode, but it does not accept
        interleaved responses. This client would still be able to synchronize
        its clock. It would drop interleaved responses as bogus and set the
        origin timestamp to the receive timestamp from the last valid response
        in the basic mode. As servers are required to not respond twice to the
        same origin timestamp in the interleaved mode, at least every other
        response would be in the basic mode and accepted by the client.</t>
      <t indent="0" pn="section-5-4">A missing or corrupted measurement can also be caused by problems on
        the server side. A server that does not
        ensure that the receive and transmit timestamps in its responses are unique
        in a sufficiently long interval can misinterpret requests formed
        correctly in the basic mode as interleaved and respond in the
        interleaved mode. The response would be dropped by the client as
        bogus.</t>
      <t indent="0" pn="section-5-5">A duplicated server receive timestamp can cause an expected
        interleaved response to contain a transmit timestamp that does not
        correspond to the transmission of the previous response from which the
        client copied the receive timestamp to the origin timestamp in the
        request, but a different response that contained the same receive
        timestamp. The response would be accepted by the client with a small
        error in the transmit timestamp equal to the difference between the
        transmit timestamps of the two different responses. As the requests
        corresponding to the two different responses were received at the same time
        (according to the server's clock), the two transmissions would be
        expected to be close to each other and the difference between them
        would be comparable to the error a basic response normally has in its
        transmit timestamp.</t>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">The security considerations for time protocols in general are discussed
        in <xref target="RFC7384" format="default" sectionFormat="of" derivedContent="RFC7384">RFC 7384</xref>. 
        Security considerations specific to NTP are discussed in <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905">RFC 5905</xref>.</t>
      <t indent="0" pn="section-6-2">Security issues that apply to the basic modes discussed in <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905">RFC 5905</xref> also apply to the
        interleaved modes. These issues are described in <xref target="SECNTP" format="default" sectionFormat="of" derivedContent="SECNTP">"The Security of NTP's Datagram Protocol"</xref>.
</t>
      <t indent="0" pn="section-6-3">Clients and peers <bcp14>SHOULD NOT</bcp14> leak the receive timestamp in packets
        sent to other peers or clients (e.g., as a reference timestamp) to
        prevent off-path attackers from easily getting the origin timestamp
        needed to make a valid response in the interleaved mode.</t>
      <t indent="0" pn="section-6-4">Clients using the interleaved mode <bcp14>SHOULD</bcp14> randomize all bits of
        receive and transmit timestamps in their requests (i.e., provide a precision
        of 2<sup>32</sup> seconds) to make it more difficult for off-path attackers to guess the
        origin timestamp in the server response.</t>
      <t indent="0" pn="section-6-5">Unlike in the basic client/server mode, clients using the interleaved mode
        cannot set the origin timestamp in their requests to zero (i.e., reset
        the NTP association with every request) to make it more difficult to
        track them as they move between networks.</t>
      <t indent="0" pn="section-6-6">Attackers can force the server to drop its timestamps in order to
        prevent clients from getting an interleaved response. They can send a
        large number of requests, send requests with a spoofed source address,
        or replay an authenticated request if the interleaved mode is enabled
        only for authenticated clients. Clients <bcp14>MUST NOT</bcp14> rely on servers to
        be able to respond in the interleaved mode.</t>
      <t indent="0" pn="section-6-7">Protecting symmetric associations in the interleaved mode against
        replay attacks is even more difficult than in the basic mode.
        In both modes, the NTP state needs to be protected between the
        reception of the last non-replayed response and transmission of the
        next request in order for the request to contain the origin timestamp
        expected by the peer. The difference is in the timestamps needed to
        complete a measurement. In the basic mode, only one valid response 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 state
        needs to be protected at all times, so that the timestamps that
        are needed to complete the measurement when the second response is
        received will not be lost.</t>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-7-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5905" quoteTitle="true" derivedAnchor="RFC5905">
          <front>
            <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
            <author fullname="D. Mills" initials="D." surname="Mills"/>
            <author fullname="J. Martin" initials="J." role="editor" surname="Martin"/>
            <author fullname="J. Burbank" initials="J." surname="Burbank"/>
            <author fullname="W. Kasch" initials="W." surname="Kasch"/>
            <date month="June" year="2010"/>
            <abstract>
              <t indent="0">The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5905"/>
          <seriesInfo name="DOI" value="10.17487/RFC5905"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC5906" target="https://www.rfc-editor.org/info/rfc5906" quoteTitle="true" derivedAnchor="RFC5906">
          <front>
            <title>Network Time Protocol Version 4: Autokey Specification</title>
            <author fullname="B. Haberman" initials="B." role="editor" surname="Haberman"/>
            <author fullname="D. Mills" initials="D." surname="Mills"/>
            <date month="June" year="2010"/>
            <abstract>
              <t indent="0">This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, Public Key Infrastructure (PKI) schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions.</t>
              <t indent="0">This memo includes the Autokey requirements analysis, design principles, and protocol specification. A detailed description of the protocol states, events, and transition functions is included. A prototype of the Autokey design based on this memo has been implemented, tested, and documented in the NTP version 4 (NTPv4) software distribution for the Unix, Windows, and Virtual Memory System (VMS) operating systems at http://www.ntp.org. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5906"/>
          <seriesInfo name="DOI" value="10.17487/RFC5906"/>
        </reference>
        <reference anchor="RFC7384" target="https://www.rfc-editor.org/info/rfc7384" quoteTitle="true" derivedAnchor="RFC7384">
          <front>
            <title>Security Requirements of Time Protocols in Packet Switched Networks</title>
            <author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
            <date month="October" year="2014"/>
            <abstract>
              <t indent="0">As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7384"/>
          <seriesInfo name="DOI" value="10.17487/RFC7384"/>
        </reference>
        <reference anchor="RFC9109" target="https://www.rfc-editor.org/info/rfc9109" quoteTitle="true" derivedAnchor="RFC9109">
          <front>
            <title>Network Time Protocol Version 4: Port Randomization</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <author fullname="G. Gont" initials="G." surname="Gont"/>
            <author fullname="M. Lichvar" initials="M." surname="Lichvar"/>
            <date month="August" year="2021"/>
            <abstract>
              <t indent="0">The Network Time Protocol (NTP) can operate in several modes. Some of these modes are based on the receipt of unsolicited packets and therefore require the use of a well-known port as the local port. However, in the case of NTP modes where the use of a well-known port is not required, employing such a well-known port unnecessarily facilitates the ability of attackers to perform blind/off-path attacks. This document formally updates RFC 5905, recommending the use of transport-protocol ephemeral port randomization for those modes where use of the NTP well-known port is not required.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9109"/>
          <seriesInfo name="DOI" value="10.17487/RFC9109"/>
        </reference>
        <reference anchor="SECNTP" target="https://eprint.iacr.org/2016/1006" quoteTitle="true" derivedAnchor="SECNTP">
          <front>
            <title>The Security of NTP's Datagram Protocol</title>
            <author initials="A." surname="Malhotra" fullname="A. Malhotra">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Van Gundy" fullname="M. Van Gundy">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Varia" fullname="M. Varia">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Kennedy" fullname="H. Kennedy">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Gardner" fullname="J. Gardner">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Goldberg" fullname="S. Goldberg">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016"/>
          </front>
          <refcontent>Cryptology ePrint Archive, Paper 2016/1006</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The interleaved modes described in this document are based on the
      implementation written by <contact fullname="David Mills"/> in the <eref target="https://www.ntp.org" brackets="none">NTP project</eref>. 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.</t>
      <t indent="0" pn="section-appendix.a-2">The authors would like to thank <contact fullname="Doug Arnold"/>,
      <contact fullname="Roman Danyliw"/>, <contact fullname="Reese       Enghardt"/>, <contact fullname="Daniel Franke"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Erik Kline"/>, <contact fullname="Catherine Meadows"/>, <contact fullname="Tal Mizrahi"/>,
      <contact fullname="Steven Sommars"/>, <contact fullname="Harlan       Stenn"/>, <contact fullname="Kristof Teichel"/>, and <contact fullname="Gunter Van de Velde"/> for their useful comments and
      suggestions.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Miroslav Lichvar" initials="M." surname="Lichvar">
        <organization showOnFrontPage="true">Red Hat</organization>
        <address>
          <postal>
            <street>Purkynova 115</street>
            <city>Brno</city>
            <code>612 00</code>
            <country>Czech Republic</country>
          </postal>
          <email>mlichvar@redhat.com</email>
        </address>
      </author>
      <author fullname="Aanchal Malhotra" initials="A." surname="Malhotra">
        <organization showOnFrontPage="true">Boston University</organization>
        <address>
          <postal>
            <street>111 Cummington St</street>
            <city>Boston</city>
            <region>MA</region>
            <code>02215</code>
            <country>United States of America</country>
          </postal>
          <email>aanchal4@bu.edu</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
