<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.25 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-rsalz-update-registries-02" category="info" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title>The update registries draft</title>
    <seriesInfo name="Internet-Draft" value="draft-rsalz-update-registries-02"/>
    <author initials="R." surname="Salz" fullname="Rich Salz">
      <organization>Akamai Technologies</organization>
      <address>
        <email>rsalz@akamai.com</email>
      </address>
    </author>
    <date year="2021" month="February" day="03"/>
    <workgroup>ntp</workgroup>
    <keyword>NTP</keyword>
    <keyword>extensions</keyword>
    <keyword>registries</keyword>
    <keyword>IANA</keyword>
    <abstract>
      <t>The Network Time Protocol (NTP) and Network Time Security (NTS) documents
define a number of assigned number registries, collectively called the NTP
registries.
Some registries have wrong values, some registries
do not follow current common practice, and some are just right.
For the sake of completeness, this document reviews all NTP and NTS registries.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/richsalz/draft-rsalz-update-registries"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Network Time Protocol (NTP) and Network Time Security (NTS) documents
define a number of assigned number registries, collectively called the NTP
registries.
Some registries have wrong values, some registries
do not follow current common practice, and some are just right.
For the sake of completeness, this document reviews all NTP and NTS registries.</t>
      <t>The bulk of this document can be divided into two parts:</t>
      <ul spacing="normal">
        <li>First, each registry, its defining document, and a summary of its
syntax is defined.</li>
        <li>Second, the revised format and entries for each registry are defined.</li>
      </ul>
    </section>
    <section anchor="existing-registries" numbered="true" toc="default">
      <name>Existing Registries</name>
      <t>This section describes the registries and the rules for them.
It is intended to be a short summary of the syntax and registration
requirements for each registry.
The semantics and protocol processing rules for each registry -- that is,
how an implementation acts when sending or receiving any of the fields --
is not described here.</t>
      <section anchor="reference-id-kiss-o-death" numbered="true" toc="default">
        <name>Reference ID, Kiss-o'-Death</name>
        <t><xref target="RFC5905" format="default"/> defined two registries, the Reference ID in Section 7.3, and the
Kiss-o'-Death in Section 7.4.  Both of these are allowed to be four ASCII
characters; padded on the right with all-bits-zero if necessary.
Entries that start with 0x58, the ASCII
letter uppercase X, are reserved for private experimentation and development.
Both registries are first-come first-served. The formal request to define
the registries is in Section 16.</t>
        <t>Section 7.5 of <xref target="RFC5905" format="default"/> defined the on-the-wire format of extension
fields but did not create a registry for it.</t>
      </section>
      <section anchor="extension-field-types" numbered="true" toc="default">
        <name>Extension Field Types</name>
        <t><xref target="RFC5906" format="default"/> mentioned the Extension Field Types registry, and defined it
indirectly by defining 30 extensions (15 each for request and response)
in Section 13.
It did not provide a formal definition of the columns in the registry.
Section 10 of <xref target="RFC5906" format="default"/> splits the Field Type into four subfields,
only for use within the Autokey extensions.</t>
        <t><xref target="RFC7821" format="default"/> added a new entry, Checksum Complement, to the Extension
Field Types registry.</t>
        <t><xref target="RFC7822" format="default"/> clarified the processing rules for Extension Field Types, particularly
around the interaction with the Message Authentication Code (MAC) field.</t>
        <t><xref target="RFC8573" format="default"/> changed the cryptography used in the MAC field.</t>
        <t>The following problems exists with the current registry:</t>
        <ul spacing="normal">
          <li>Many of the entries in the Extension Field Types registry have
swapped some of the nibbles; 0x1234 is listed as 0x1432 for example.
This document marks the erroneous values as reserved.</li>
          <li>Some values were mistakenly re-used.</li>
        </ul>
      </section>
      <section anchor="network-time-security-registries" numbered="true" toc="default">
        <name>Network Time Security Registries</name>
        <t><xref target="RFC8915" format="default"/> defines the Network Time Security (NTS) protocol.
Sections 7.1 through 7.5 (inclusive) added entries to existing registries.</t>
        <t>Section 7.6 created a new registry, NTS Key Establishment Record Types,
that partitions the assigned numbers into three different registration
policies: IETF Review, Specification Required, and Private or Experimental Use.</t>
        <t>Section 7.7 created a new registry, NTS Next Protocols,
that similarly partitions the assigned numbers.</t>
        <t>Section 7.8 created two new registries, NTS Error Codes and NTS Warning Codes.
Both registries are also partitioned the same way.</t>
      </section>
    </section>
    <section anchor="new-registries" numbered="true" toc="default">
      <name>New Registries</name>
      <t>The following general guidelines apply to all registries defined here:</t>
      <ul spacing="normal">
        <li>Every entry reserves a partition for private use and experimentation.</li>
        <li>Registries with ASCII fields are now limited to uppercase letters; fields
starting with 0x2D, the ASCII minus sign, are reserved for private use
and experimentation.</li>
        <li>The policy for every registry is now specification required, as defined
in Section 4.6 of <xref target="RFC8126" format="default"/>.</li>
      </ul>
      <t>The IESG is requested to choose three designated experts, with two being
required to approve a registry change.</t>
      <t>Each entry described in the below sub-sections is intended to completely
replace the existing entry with the same name.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="ntp-reference-identifier-codes" numbered="true" toc="default">
        <name>NTP Reference Identifier Codes</name>
        <t>The registration procedure is changed to specification required.</t>
        <t>The Note is changed to read as follows:</t>
        <ul spacing="normal">
          <li>Codes beginning with the character "-" are reserved for experimentation
and development. IANA cannot assign them.</li>
        </ul>
        <t>The columns are defined as follows:</t>
        <ul spacing="normal">
          <li>ID (required): a four-byte value padded on the right with zero's.
Each value must be an ASCII uppercase letter or minus sign</li>
          <li>Clock source (required): A brief text description of the ID</li>
          <li>Reference (required): the publication defining the ID.</li>
        </ul>
        <t>The existing entries are left unchanged.</t>
      </section>
      <section anchor="ntp-kiss-o-death-codes" numbered="true" toc="default">
        <name>NTP Kiss-o'-Death Codes</name>
        <t>The registration procedure is changed to specification required.</t>
        <t>The Note is changed to read as follows:</t>
        <ul spacing="normal">
          <li>Codes beginning with the character "-" are reserved for experimentation
and development. IANA cannot assign them.</li>
        </ul>
        <t>The columns are defined as follows:</t>
        <ul spacing="normal">
          <li>ID (required): a four-byte value padded on the right with zero's.
Each value must be an ASCII uppercase letter or minus sign.</li>
          <li>Meaning source (required): A brief text description of the ID.</li>
          <li>Reference (required): the publication defining the ID.</li>
        </ul>
        <t>The existing entries are left unchanged.</t>
      </section>
      <section anchor="ntp-extension-field-types" numbered="true" toc="default">
        <name>NTP Extension Field Types</name>
        <t>The registration procedure is changed to specification required.</t>
        <t>The reference should be <xref target="RFC5906" format="default"/> added, if possible.</t>
        <t>The following Note is added:</t>
        <ul spacing="normal">
          <li>Field Types in the range 0xF000 through 0xFFFF, inclusive, are reserved
for experimentation and development. IANA cannot assign them.
Both NTS Cookie and Autokey Message Request have the same Field Type;
in practice this is not a problem as the field semantics will be
determined by other parts of the message.</li>
        </ul>
        <t>The columns are defined as follows:</t>
        <ul spacing="normal">
          <li>Field Type (required): A two-byte value in hexadecimal.</li>
          <li>Meaning (required): A brief text description of the field type.</li>
          <li>Reference (required): the publication defining the field type.</li>
        </ul>
        <t>The table is replaced with the following entries.</t>
        <table align="center">
          <thead>
            <tr>
              <th align="left">Field Type</th>
              <th align="left">Meaning</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0x0002</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x0102</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x0104</td>
              <td align="left">Unique Identifier</td>
              <td align="left">RFC 8915, Section 5.3</td>
            </tr>
            <tr>
              <td align="left">0x0200</td>
              <td align="left">No-Operation Request</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x0201</td>
              <td align="left">Association Message Request</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x0202</td>
              <td align="left">Certificate Message Request</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x0203</td>
              <td align="left">Cookie Message Request</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x0204</td>
              <td align="left">NTS Cookie</td>
              <td align="left">RFC 8915, Section 5.4</td>
            </tr>
            <tr>
              <td align="left">0x0204</td>
              <td align="left">Autokey Message Request</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x0205</td>
              <td align="left">Leapseconds Message Request</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x0206</td>
              <td align="left">Sign Message Request</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x0207</td>
              <td align="left">IFF Identity Message Request</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x0208</td>
              <td align="left">GQ Identity Message Request</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x0209</td>
              <td align="left">MV Identity Message Request</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x0302</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x0304</td>
              <td align="left">NTS Cookie Placeholder</td>
              <td align="left">RFC 8915, Section 5.5</td>
            </tr>
            <tr>
              <td align="left">0x0402</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x0404</td>
              <td align="left">NTS Authenticator and Encrypted Extension Fields</td>
              <td align="left">RFC 8915, Section 5.6</td>
            </tr>
            <tr>
              <td align="left">0x0502</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x0602</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x0702</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x2005</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x8002</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x8102</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x8200</td>
              <td align="left">No-Operation Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x8201</td>
              <td align="left">Association Message Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x8202</td>
              <td align="left">Certificate Message Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x8203</td>
              <td align="left">Cookie Message Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x8204</td>
              <td align="left">Autokey Message Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x8205</td>
              <td align="left">Leapseconds Message Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x8206</td>
              <td align="left">Sign Message Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x8207</td>
              <td align="left">IFF Identity Message Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x8208</td>
              <td align="left">GQ Identity Message Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x8209</td>
              <td align="left">MV Identity Message Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0x8302</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x8402</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x8502</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x8602</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x8702</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x8802</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0xC002</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0xC102</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0xC200</td>
              <td align="left">No-Operation Error Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0xC201</td>
              <td align="left">Association Message Error Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0xC202</td>
              <td align="left">Certificate Message Error Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0xC203</td>
              <td align="left">Cookie Message Error Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0xC204</td>
              <td align="left">Autokey Message Error Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0xC205</td>
              <td align="left">Leapseconds Message Error Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0xC206</td>
              <td align="left">Sign Message Error Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0xC207</td>
              <td align="left">IFF Identity Message Error Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0xC208</td>
              <td align="left">GQ Identity Message Error Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0xC209</td>
              <td align="left">MV Identity Message Error Response</td>
              <td align="left">RFC 5906</td>
            </tr>
            <tr>
              <td align="left">0xC302</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0xC402</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0xC502</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0xC602</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0xC702</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0xC802</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x0902</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0x8902</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
            <tr>
              <td align="left">0xC902</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="network-time-security-key-establishment-record-types" numbered="true" toc="default">
        <name>Network Time Security Key Establishment Record Types</name>
        <t>The registration procedure is changed to specification required.</t>
        <t>The following note should be added:</t>
        <ul spacing="normal">
          <li>Record Type numbers in the range 0x4000 through 0x7FFF, inclusive,
are reserved for experimentation and development. IANA cannot assign them.</li>
        </ul>
        <t>The existing entries are left unchanged.</t>
      </section>
      <section anchor="network-time-security-next-protocols" numbered="true" toc="default">
        <name>Network Time Security Next Protocols</name>
        <t>The registration procedure is changed to specification required.</t>
        <t>The following note should be added:</t>
        <ul spacing="normal">
          <li>Protocol ID numbers in the range 0x8000 through 0xFFFF, inclusive,
are reserved for experimentation and development. IANA cannot assign them.</li>
        </ul>
        <t>The existing entries are left unchanged.</t>
      </section>
      <section anchor="network-time-security-error-codes" numbered="true" toc="default">
        <name>Network Time Security Error Codes</name>
        <t>The registration procedure is changed to specification required.</t>
        <t>The following note should be added:</t>
        <ul spacing="normal">
          <li>Error code numbers in the range 0x8000 through 0xFFFF, inclusive,
are reserved for experimentation and development. IANA cannot assign them.</li>
        </ul>
        <t>The existing entries are left unchanged.</t>
      </section>
      <section anchor="network-time-security-warning-codes" numbered="true" toc="default">
        <name>Network Time Security Warning Codes</name>
        <t>The registration procedure is changed to specification required.</t>
        <t>The following note should be added:</t>
        <ul spacing="normal">
          <li>Warning code numbers in the range 0x8000 through 0xFFFF, inclusive,
are reserved for experimentation and development. IANA cannot assign them.</li>
        </ul>
        <t>The existing entries are left unchanged.</t>
      </section>
    </section>
    <section anchor="acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>The members of the NTP Working Group helped a great deal.
Notable contributors include.</t>
      <ul spacing="normal">
        <li>Miroslav Lichvar, RedHat</li>
        <li>Daniel Franke, Akamai Technologies</li>
        <li>Danny Mayer, Network Time Foundation</li>
        <li>Michelle Cotton, IANA</li>
      </ul>
      <t>And thanks to Harlen Stenn for providing popcorn.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5905">
        <front>
          <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
          <author initials="D." surname="Mills" fullname="D. Mills">
            <organization/>
          </author>
          <author initials="J." surname="Martin" fullname="J. Martin" role="editor">
            <organization/>
          </author>
          <author initials="J." surname="Burbank" fullname="J. Burbank">
            <organization/>
          </author>
          <author initials="W." surname="Kasch" fullname="W. Kasch">
            <organization/>
          </author>
          <date year="2010" month="June"/>
          <abstract>
            <t>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.   [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5905"/>
        <seriesInfo name="DOI" value="10.17487/RFC5905"/>
      </reference>
      <reference anchor="RFC5906" target="https://www.rfc-editor.org/info/rfc5906">
        <front>
          <title>Network Time Protocol Version 4: Autokey Specification</title>
          <author initials="B." surname="Haberman" fullname="B. Haberman" role="editor">
            <organization/>
          </author>
          <author initials="D." surname="Mills" fullname="D. Mills">
            <organization/>
          </author>
          <date year="2010" month="June"/>
          <abstract>
            <t>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>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="RFC7821" target="https://www.rfc-editor.org/info/rfc7821">
        <front>
          <title>UDP Checksum Complement in the Network Time Protocol (NTP)</title>
          <author initials="T." surname="Mizrahi" fullname="T. Mizrahi">
            <organization/>
          </author>
          <date year="2016" month="March"/>
          <abstract>
            <t>The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages.  To facilitate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission.  Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification.  This document proposes an extension field that includes a 2-octet Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets of the packet rather than in the UDP Checksum field.  The behavior defined in this document is interoperable with existing NTP implementations.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7821"/>
        <seriesInfo name="DOI" value="10.17487/RFC7821"/>
      </reference>
      <reference anchor="RFC7822" target="https://www.rfc-editor.org/info/rfc7822">
        <front>
          <title>Network Time Protocol Version 4 (NTPv4) Extension Fields</title>
          <author initials="T." surname="Mizrahi" fullname="T. Mizrahi">
            <organization/>
          </author>
          <author initials="D." surname="Mayer" fullname="D. Mayer">
            <organization/>
          </author>
          <date year="2016" month="March"/>
          <abstract>
            <t>The Network Time Protocol version 4 (NTPv4) defines the optional usage of extension fields.  An extension field, as defined in RFC 5905, is an optional field that resides at the end of the NTP header and that can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header.  This document updates RFC 5905 by clarifying some points regarding NTP extension fields and their usage with Message Authentication Codes (MACs).</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7822"/>
        <seriesInfo name="DOI" value="10.17487/RFC7822"/>
      </reference>
      <reference anchor="RFC8573" target="https://www.rfc-editor.org/info/rfc8573">
        <front>
          <title>Message Authentication Code for the Network Time Protocol</title>
          <author initials="A." surname="Malhotra" fullname="A. Malhotra">
            <organization/>
          </author>
          <author initials="S." surname="Goldberg" fullname="S. Goldberg">
            <organization/>
          </author>
          <date year="2019" month="June"/>
          <abstract>
            <t>The Network Time Protocol (NTP), as described in RFC 5905, states that NTP packets should be authenticated by appending NTP data to a 128-bit key and hashing the result with MD5 to obtain a 128-bit tag. This document deprecates MD5-based authentication, which is considered too weak, and recommends the use of AES-CMAC as described in RFC 4493 as a replacement.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8573"/>
        <seriesInfo name="DOI" value="10.17487/RFC8573"/>
      </reference>
      <reference anchor="RFC8915" target="https://www.rfc-editor.org/info/rfc8915">
        <front>
          <title>Network Time Security for the Network Time Protocol</title>
          <author initials="D." surname="Franke" fullname="D. Franke">
            <organization/>
          </author>
          <author initials="D." surname="Sibold" fullname="D. Sibold">
            <organization/>
          </author>
          <author initials="K." surname="Teichel" fullname="K. Teichel">
            <organization/>
          </author>
          <author initials="M." surname="Dansarie" fullname="M. Dansarie">
            <organization/>
          </author>
          <author initials="R." surname="Sundblad" fullname="R. Sundblad">
            <organization/>
          </author>
          <date year="2020" month="September"/>
          <abstract>
            <t>This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP). </t>
            <t>NTS is structured as a suite of two loosely coupled sub-protocols. The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTS Extension Fields for NTPv4) handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8915"/>
        <seriesInfo name="DOI" value="10.17487/RFC8915"/>
      </reference>
      <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126">
        <front>
          <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
          <author initials="M." surname="Cotton" fullname="M. Cotton">
            <organization/>
          </author>
          <author initials="B." surname="Leiba" fullname="B. Leiba">
            <organization/>
          </author>
          <author initials="T." surname="Narten" fullname="T. Narten">
            <organization/>
          </author>
          <date year="2017" month="June"/>
          <abstract>
            <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
            <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
            <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="26"/>
        <seriesInfo name="RFC" value="8126"/>
        <seriesInfo name="DOI" value="10.17487/RFC8126"/>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAIn6GmAAA+1aa3PjthX9zl+BJh+y25E0fq61zpe6sr3xJOtu107TmU6n
A5GQiJoiVAC0rGTz33suAL5kSrbDzE7aiWZ21iKJ+zz33AuIw+EwSlSc84U4
ZYnmMzvUhmc/Dotlwq0YajGXxmopzHDvILLSZnjuNhXM32f1fb86inF1rvT6
lMl8pqKV0ndzrYrlKcvtMpJLfcqsLow92Nt7C4mRsTxP/sUzlUPwWphoKU8j
xqyK/VfGjNJWi5mpvq8Xza+xWix5bKu7xbS6kqsouhNr2JCcsn9c334YMPFg
RW6kys2gYfuAXZ1dn/0zinhhU6XJgCH+Mebj8lHGKbtBVNw1peen7OyOL7hk
tyJOc5WpuXTKGRO4mp0yF8M/cffQCPZE0XA4ZHwKdbAsiiiC18JSdNitXAj2
QSu4rDL2Cma+ZohJ+/6NiAst7Zru37xmSFmxELk1USJmMheMs7xYTIVmasa4
MXKei6S81PQTKjIRW3kvsjWLOb4kzJIxtx+i+rlRdKMWreSm/F6wlVb5nN3z
rCBRpv0IYISAWzaDBrViMFfDQErPQuVsSX7LWAyca24p14L9G0hgWs5TO4ou
lXamGH4nyA1KYyaQLmGgzabSVG5D7b0UK8PgAJnu43V7w5ouuJAvZJJkIoq+
ZFe51SopYIXKf0/AZ0kABXlaZHckrL085jmbCpbIe5kgADK3iiHYbMm1NadI
HbuU2ljUK0fpBaHrAZMWQijgEnEopXmXOEp/seB6TdrwXGTWueUPTIYVIhlB
LNKo8mTg/CQfDLTPlF5w64RAmos2LrVVu2BVcgCniwdcJys+1gmAw9BmhMMY
njaxllNI88qqVJIid6nIgip8W4yiK0vGIhYip6AgJFPClQEj2aZzLkfeORIV
JHMHbC3+U0gtHDQfezFyKTEgqRxY8JYsS+DjjxiZJp9qy9pBQEHZlJOZgygF
xpBFSRghdU4/A8gMW6Uih5Y8IVmK8B8LZBpfeF55MJMiSwxERnCacFvGK2Gp
0IKC/CWCO8PfeSzY1fmAfSuNGaqvhueC2zSKfvrpDx8vJ8dv945//rnMjUNR
s95IVVMK4ksgcMaejA4HZTailvD2U0cjxv6scNWbbnzpcCqzKk8zVWh2djO5
uorilFOxCW2+BqATyiXEuIxTobGVhCisHk4B0+GPQismZywXFH1OSboIKHSx
RoPUYc3ew/HYe+QVoTihBa14KXTMYdbfB84yDRP1vUc20irvqVOLBzwlG5mC
34kADaklXRxFzsMmTDUlCVU4jIkt/J9e8MiNAK5uMkaQE2ARxMEnIdrAuwN1
Fc79N0htHdtjCmp3JiFF5UP8N1xJLcoyxeNVE48CiKYF4CMTB6NYC3KX16il
KEjrAXVRLgXBYCm7XS+pcCsD3sAACgeeCCZ0rmhQko+jN1naSAL1wLsFu0/X
NVcd7jVGD/Zq/9hX1sxVh4+fr2WzxAPiddSM2KHjhtJB1CmxJjwMCfBK3KOh
tlDOxSJ3YW/kAsiqRO61wk5em2VG7ErP1456ZnbYxmDloz2IVJ75qBbAHCEz
6DkrrMK81fB0VIb2ZHywDyW+GtArxcpxLeI3SUV8B3ZjE1VSyYCw1Ip91BX7
pvADCI8zriVs9HnrpLPOZA5c25FxgfXZOuIYVwNDExe7vokFrgLp4nsq07nz
NiWkxL6eJgo5efX+bPLaU1tl3fj45JCsS3k+D7bFer20aq75Ml1TEJMyU1he
rfYlRiRDPsCdKaJjEFw4b2pzyj5fRsV1z/cNoi17WlCxG89uzojMioNTwpgQ
xORyCgNAaXsP+weHR1TVGZZQOg1dOzo88B3jgVMeR74ZVh0fzevOo0toTDFC
FSYMMrS+ZCzXoklpuLUCb2OGAwfeCQKdFkMKl6/l7vms2Y9DAt7u17zibdg1
2pUNsaoWA5raxzLgYp46ynol8zgrDIa41wHSZZABXFFOBq1ZqGa8N4Giyjqo
qYQGqG9RPxfwd4rgpi5yHzGy6BKqkesJDq/eNPJmY940YZ5KtaARa+aan23P
CUuVyRiWnbKri9tL6KBxbsBuliJGCQVIf/TDROJJ7kNoJK6Mql6Sse+NaPl3
stO/a5BDNWyX/hi5kK74nvKspWhcKaKm31DlGj8puwDUtKtMU02oP3DtGNld
7e56PDOqtiTUrMFWkK342k1/11DWHvyatTrHyKwRmXkBns4c6FBP8A5ZoYG5
uWkOnYNGHle5F/cCVei4sawKrK6tafV04l83trZ7O+19GuZ5rnAjQzl1kZc5
BrgMgbd+hqmnCD9WoNL9w5GbQMivMIQcnDeGEFRnjlKmNO0YPmBotM1Qip2D
o+8pwgWg4iM3HK7QnZrA1DUwqxA2O+YRiqzqb+P9A/S3QKhXFzfvSGZout71
OFUKfoeCEeSLg5Wz1gJLnmxXNOghDuWQ7dYisejHrXnDMz0UXlCL96msh9tA
w1NBmzQ01aEpWWZj+C+3X2hJWiwzHgtPnyW9eMFVH3D4pPMKB1A6zwDEQfSJ
8CVvPGdir9YYhxNqYEhzKBIfoyZR+DaaFEgszKt6mNqSkBDla2U3n0eluk7h
q8Tv8XxhTqEuzyt8uZ5WTtDsi+EXj1G1gaJoc5T13mOPSeOSp5CwxXLWldNR
Y0u3aRn2Ca9Kn16fulGr0MPp2obOtH2up3H+K/CKy71/dkF7bNrK5aFkNkuN
KLUuIxeZTMV3aL+FRpaalpyxKUoaHZlo1INq2Zz8rs597ZcZbq51U1GBxhKS
Vg2nfmGITgtfJSNmYmZZkYd8jiootTdNv2Pot4IhR6zvBXch+UUwGn1WHG3Z
lv06SNKVFyZVBaQjjq2tj8vDgDbhS4VMT2l63WjpJRrdo+GAqp6ey30W2YMG
ebm3t1fNi/iKD6SXI2O7TUYdYHy0N98ORje+0FgzUepO+mmg3IaVG5WPYYPp
jhCrVlHb/zW1zvJ80B/UhSMZXm47CNvVoU3jAGklMc5MRZSgT+mFqwLsemET
AOnO8kpALbwtz6+exh60DVy04WYRwfQUW44E+cdeuIX7lwDeO2ah7pcCvyWB
nKQZXvhZw3XvpOamGlehOLDkU9PlT5UTuz6fGnZ+ij6dDutP68vWT/MpCABW
gdyDSnaDLgEKq7SMiYMNDSulBW6Xh1JiLAjY7y/gKNz6PpdAbnNK6YwB1tIW
b1CNf8ejw1LYASrRP3athn9ZhlmoKolOYcQKrBawH26dGaNi6ddvltZOAWU8
JhgmPUmJlwk4LAX4Gt+2druAMqANotgFqo6AHj0Wto1mnrTmONz6TvClcefx
5mXxeBNu3RAP7ozGFgEn4dbV5WVAl93qR6eAcbj17q9Pru8W8Dbcev+3XyTg
sG+RHXZh4gPRVKqyZLPSujFxXAo76mvNUcuaxsEapFBHu8jdiRnkbgwKZotp
b0rJx31Ne9NXwElPAWCw414Cxn0pfdyX0sdbWdifdj9ZsuOnWLgtp1PAbhZ+
hoCtLNzhRKeA7cT5WEKngN3E+QwXthDn87PwBHG2BHUK2E2cz3BhN3E+KaAv
cY77ct24LyON+zLSuC8jjcc9BUz6MtKkLyNNtjCSPzB+VBGPgTTZzUibcjoF
7GKkZwnYwkidTnQK2MZIXRI6BexipGe50MlIL8nCTkbaENQpYBcjPcuFXYz0
DAF9GWnSl5EmfRlp0peRJn0ZadKXkehdxF4Cxn0FTPoI2P5r6O6fE3+tE7b6
PCOnc7L6mK0+LmuobfxM2To2O2ofm51sHJtFT53hvuDY7IUnlJ2hbf+S+RlD
Wb2qeHW+LZTj3SeQv7VQNn6n/Yxx9Fpjem/j/yOMrZ+2P2MgS73/g6FkZ/Fd
rlaZSOb+pUm/eiG8E+F0mH6i+AHxJnnv6G12lops6d5wmNMrCDCMzp6vlT/z
xRwEnVMMVS4O8DGhQ+E/svdSK5Pxe/adjNN7rgegxeQbbnHrnOdSZOwS8boT
g873y91DOYYLvhZY2sLAJb2z5H/JIjUx7IMhE2Wtyv3b7VF05t5qgnz3mso3
XGciZzdW5OVLBfRemXvXSC1B1vko+i8hDshMHjAAAA==

-->

</rfc>
