rfc9748.original.xml   rfc9748.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 3.3. -ietf-ntp-update-registries-16" number="9748" category="std" consensus="true" su
3) --> bmissionType="IETF" obsoletes="" updates="5905, 5906, 7821, 7822, 8573" tocInclu
<?rfc compact="yes"?> de="true" sortRefs="true" symRefs="true" version="3" xml:lang="en">
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-ntp-update-registries-16" category="std" consensus="true" submissionType="
IETF" updates="5905, 5906, 8573, 7822, 7821" tocInclude="true" sortRefs="true" s
ymRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.22.0 -->
<front> <front>
<title>Updating the NTP Registries</title> <title>Updating the NTP Registries</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-ntp-update-registries-16 "/> <seriesInfo name="RFC" value="9748"/>
<author initials="R." surname="Salz" fullname="Rich Salz"> <author initials="R." surname="Salz" fullname="Rich Salz">
<organization>Akamai Technologies</organization> <organization>Akamai Technologies</organization>
<address> <address>
<email>rsalz@akamai.com</email> <email>rsalz@akamai.com</email>
</address> </address>
</author> </author>
<date year="2024" month="August" day="20"/> <date year="2025" month="February"/>
<area>INT</area>
<workgroup>ntp</workgroup> <workgroup>ntp</workgroup>
<keyword>NTP</keyword> <keyword>NTP</keyword>
<keyword>extensions</keyword> <keyword>extensions</keyword>
<keyword>registries</keyword> <keyword>registries</keyword>
<keyword>IANA</keyword> <keyword>IANA</keyword>
<abstract> <abstract>
<?line 34?>
<t>The Network Time Protocol (NTP) and Network Time Security (NTS) documents <t>The Network Time Protocol (NTP) and Network Time Security (NTS) documents
define a number of assigned number registries, collectively called the NTP define a number of registries, collectively called the NTP
registries.</t> registries.</t>
<!-- [rfced] May we update this text for clarity? Note that it appears in the A
bstract and the Introduction.
Original:
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, and
makes updates where necessary.
Perhaps:
Some registries are correct, but some include incorrect assignments
and some don’t follow common practice. For the sake of completeness,
this document reviews all NTP and NTS registries, and corrects the
registries where necessary.
-->
<t>Some registries have wrong values, some registries <t>Some registries have wrong values, some registries
do not follow current common practice, and some are just right. do not follow current common practice, and some are just right.
For the sake of completeness, this document reviews all NTP and NTS registries, For the sake of completeness, this document reviews all NTP and NTS registries,
and makes updates where necessary.</t> and makes updates where necessary.</t>
<t>This document updates RFC 5905, RFC 5906, RFC 8573, RFC 7822, and <t>This document updates RFCs 5905, 5906, 7821, 7822, and 8573.
RFC 7821.</t> </t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Notes</name>
<t>This document is a product of the
<eref target="https://dt.ietf.org/wg/ntp">NTP Working Group</eref>.
Source for this draft and an issue tracker can be found at
<eref target="https://github.com/richsalz/draft-rsalz-update-registries"/>.
</t>
<t>RFC Editor: Please update 'this RFC' to refer to this document,
once its RFC number is known, through the document.</t>
</note>
</front> </front>
<middle> <middle>
<?line 48?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The Network Time Protocol (NTP) and Network Time Security (NTS) documen ts <t>The Network Time Protocol (NTP) and Network Time Security (NTS) documen ts
define a number of assigned number registries, collectively called the NTP define a number of registries, collectively called the NTP
registries. registries.
The NTP registries can all be found at The NTP registries can all be found at
<eref target="https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xht ml">https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml</eref> <eref target="https://www.iana.org/assignments/ntp-parameters" brackets="angle"/ >
and the NTS registries can all be found at and the NTS registries can all be found at
<eref target="https://www.iana.org/assignments/nts/nts.xhtml">https://www.iana.o rg/assignments/nts/nts.xhtml</eref>.</t> <eref target="https://www.iana.org/assignments/nts" brackets="angle"/>.</t>
<t>Some registries have wrong values, some registries <t>Some registries have wrong values, some registries
do not follow current common practice, and some are just right. do not follow current common practice, and some are just right.
For the sake of completeness, this document reviews all NTP and NTS registries, For the sake of completeness, this document reviews all NTP and NTS registries,
and makes updates where necessary.</t> and makes updates where necessary.</t>
<!-- [rfced] To better align with the text in section 2 and for clarity, may we
update the text as follows?
Original:
The bulk of this document can be divided into two parts:
* First, each registry, its defining document, and a summary of its
syntax is defined.
* Second, the revised format and entries for each registry that is
being modified is specified.
Perhaps:
The bulk of this document can be divided into two parts:
* a summary of the relevant registries, including syntax requirements,
registration procedures, and the defining documents.
* a revised format and entries for each registry
being modified.
-->
<t>The bulk of this document can be divided into two parts:</t> <t>The bulk of this document can be divided into two parts:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>First, each registry, its defining document, and a summary of its <t>First, each registry, its defining document, and a summary of its
syntax is defined.</t> syntax is defined.</t>
</li> </li>
<li> <li>
<t>Second, the revised format and entries for each registry that is <t>Second, the revised format and entries for each registry that is
being modified is specified.</t> being modified is specified.</t>
</li> </li>
skipping to change at line 90 skipping to change at line 111
</section> </section>
<section anchor="existing-registries"> <section anchor="existing-registries">
<name>Existing Registries</name> <name>Existing Registries</name>
<t>This section describes the registries and the rules for them. <t>This section describes the registries and the rules for them.
It is intended to be a short summary of the syntax and registration It is intended to be a short summary of the syntax and registration
requirements for each registry. requirements for each registry.
The semantics and protocol processing rules for each registry -- that is, The semantics and protocol processing rules for each registry -- that is,
how an implementation acts when sending or receiving any of the fields -- how an implementation acts when sending or receiving any of the fields --
are not described here.</t> are not described here.</t>
<section anchor="reference-id-kiss-o-death"> <section anchor="reference-id-kiss-o-death">
<name>Reference ID, Kiss-o'-Death</name> <name>Reference ID and Kiss-o'-Death Registries</name>
<t><xref target="RFC5905"/> defined two registries; the Reference ID in <!-- [rfced] As we believe "these" refers to the code points (not the registries
Section 7.3, and the ), may we update the text as described below? Also, are the codes 4 ASCII chara
Kiss-o'-Death in Section 7.4. Both of these are allowed to be four ASCII cters or are they allowed to be up to 4 ASCII characters?
Original:
Both of these are allowed to
be four ASCII characters; padded on the right with all-bits-zero if
necessary.
Perhaps:
Reference identifiers and kiss codes can be up to four ASCII characters,
padded on the right with all-bits-zero if necessary.
-->
<!-- [rfced] Because the registries were created (i.e., it's no longer a request
), we updated the text as follows. Please let us know if corrections are needed
.
Original:
The formal request to define the registries
is in [RFC5905], Section 16.
Perhaps:
The registries were created per
Section 16 of [RFC5905].
-->
<t><xref target="RFC5905"/> defines two registries:
"NTP Reference Identifier Codes" in Section <xref target="RFC5905" sectio
n="7.3" sectionFormat="bare"/> and the
"NTP Kiss-o'-Death Codes" in Section <xref target="RFC5905" section="7.4" sectio
nFormat="bare"/>. Both of these are allowed to be four ASCII
characters; padded on the right with all-bits-zero if necessary. characters; padded on the right with all-bits-zero if necessary.
Entries that start with 0x58, the ASCII Entries that start with 0x58, the ASCII
letter uppercase X, are reserved for Private or Experimental Use. letter uppercase X, are reserved for Private or Experimental Use.
Both registries are first-come first-served. The formal request to define Both registries are First Come First Served. The registries were created
the registries is in <xref section="16" sectionFormat="comma" target="RFC5905"/> per <xref section="16" sectionFormat="of" target="RFC5905"/>.</t>
.</t>
</section> </section>
<section anchor="extension-field-types"> <section anchor="extension-field-types">
<name>Extension Field Types</name> <name>Extension Field Types</name>
<t><xref section="7.5" sectionFormat="comma" target="RFC5905"/> defined <t><xref section="7.5" sectionFormat="of" target="RFC5905"/> defines the
the on-the-wire format of extension on-the-wire format of extension
fields but did not create a registry for them.</t> fields but does not create a registry for them.</t>
<t><xref section="13" sectionFormat="comma" target="RFC5906"/> mentioned <t><xref target="RFC5906" sectionFormat="of" section="13"/> mentions the
the Extension Field Types registry, and defined it "NTP Extension Field Types" registry, and defines it
indirectly by defining 30 extensions (10 each for request, response, and indirectly by defining 30 extensions (10 each for request, response, and
error response). error response).
It did not provide a formal definition of the columns in the registry. It does not provide a formal definition of the columns in the registry.
<xref section="10" sectionFormat="comma" target="RFC5906"/> splits the Field Typ <xref section="10" sectionFormat="of" target="RFC5906"/> splits the Field Type i
e into four subfields, nto four subfields,
only for use within the Autokey extensions.</t> only for use within the Autokey extensions.</t>
<t><xref target="RFC7821"/> added a new entry, Checksum Complement, to t <t><xref target="RFC7821"/> adds a new entry, Checksum Complement, to th
he Extension e "NTP Extension Field Types" registry.</t>
Field Types registry.</t> <t><xref target="RFC7822"/> clarifies the processing rules for Extension
<t><xref target="RFC7822"/> clarified the processing rules for Extension Field Types,
Field Types,
particularly around the interaction with the Message Authentication particularly around the interaction with the Message Authentication
Code (MAC) field. NTPv4 packets may contain a MAC that appears where Code (MAC) field. NTPv4 packets may contain a MAC that appears where
one would expect the next extension field header.</t> one would expect the next extension field header.</t>
<t><xref target="RFC8573"/> changed the cryptography used in the MAC fie <t><xref target="RFC8573"/> changes the cryptography used in the MAC fie
ld.</t> ld.</t>
<t><xref target="RFC8915"/> added four new entries to the Extension Fiel <t><xref target="RFC8915"/> adds four new entries to the "NTP Extension
d Types registry.</t> Field Types" registry.</t>
<t>The following problems exist with the current registry:</t> <t>The following problems exist with the current registry:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Many of the entries in the Extension Field Types registry have <!-- [rfced] Is this a real example of something that was registered incorrectl
swapped some of the nibbles; 0x1234 is listed as 0x1432 for example. y? We don't see either of these values in <https://www.iana.org/assignments/ntp-
parameters/ntp-parameters.xhtml#ntp-parameters-3> or <http://web.archive.org/web
/20230927142951/https://www.iana.org/assignments/ntp-parameters/ntp-parameters.x
html#ntp-parameters-3>. Would it be helpful to use a real example (e.g., 0x020
3 vs 0x0302 (Cookie Message Request))?
Original:
* Many of the entries in the Extension Field Types registry have
swapped some of the nibbles; 0x1234 is listed as 0x1432 for
example.
-->
<t>Many of the entries in the "NTP Extension Field Types" registry h
ave
swapped some of the nibbles; 0x1234 is listed as 0x1432, for example.
This was due to documentation errors with the original implementation This was due to documentation errors with the original implementation
of Autokey. of Autokey.
This document marks the erroneous values as reserved, in case there This document marks the erroneous values as reserved, in case there
is an implementation that used the registered values is an implementation using the registered values
instead of what the original implementation used. instead of what the original implementation used.
Applications that might have used those values would have realized Applications that used those values would have realized
that they did not interoperate with the dominant (if not only) that they did not interoperate with the dominant (if not only)
implementation at the time. implementation at the time.
Marking the values as reserved ensures that any such applications would still Marking the values as reserved ensures that any such applications continue
be able to work as-is.</t> to work as is.</t>
</li> </li>
<li> <li>
<t>Some values were mistakenly re-used.</t> <t>Some values were mistakenly reused.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="network-time-security-registries"> <section anchor="network-time-security-registries">
<name>Network Time Security Registries</name> <name>Network Time Security Registries</name>
<t><xref target="RFC8915"/> defines the NTS protocol. <t><xref target="RFC8915"/> defines the NTS protocol.
Its registries are listed here for completeness, but no changes The related registries are listed here for completeness, but there are no
to them are specified in this document.</t> changes specified in this document.</t>
<t>Sections 7.1 through 7.5 (inclusive) added entries to existing regist
ries.</t> <t>In <xref target="RFC8915"/>:</t>
<t>Section 7.6 created a new registry, NTS Key Establishment Record Type <t>Sections <xref target="RFC8915" section="7.1" sectionFormat="bare"/>
s, through <xref target="RFC8915" section="7.5" sectionFormat="bare"/> (inclusive)
that partitions the assigned numbers into three different registration added entries to existing registries.</t>
policies: IETF Review, Specification Required, and Private or Experimental Use.<
/t> <t>Section <xref target="RFC8915" section="7.6" sectionFormat="bare"/> c
<t>Section 7.7 created a new registry, NTS Next Protocols, reated the "Network Time Security Key Establishment Record Types" registry that
that similarly partitions the assigned numbers.</t> partitions the range into three different registration policies:
<t>Section 7.8 created two new registries, NTS Error Codes and NTS Warni IETF Review, Specification Required, and Private or Experimental Use.</t>
ng Codes. <t>Section <xref target="RFC8915" section="7.7" sectionFormat="bare"/> c
Both registries are also partitioned the same way.</t> reated the "Network Time Security Next Protocols" registry that similarly partit
ions the range.</t>
<t>Section <xref target="RFC8915" section="7.8" sectionFormat="bare"/> c
reated the "Network Time Security Error Codes" and "Network Time Security Warnin
g Codes" registries.
Both registries are partitioned the same way.</t>
</section> </section>
</section> </section>
<section anchor="updated-registries"> <section anchor="updated-registries">
<name>Updated Registries</name> <name>Registry Updates</name>
<!-- [rfced] Section 3: Because this document seems to only update the NTP regis
tries, may we update the text as follows?
Original:
The following general guidelines apply to all registries updated here:
Perhaps:
The following general guidelines apply to the NTP registries:
-->
<t>The following general guidelines apply to all registries updated here:< /t> <t>The following general guidelines apply to all registries updated here:< /t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Every registry reserves a partition for Private or Experimental Use .</t> <t>Each registry reserves a partition for Private or Experimental Use. </t>
</li> </li>
<li> <li>
<t>Entries with ASCII fields are now limited to uppercase letters or d igits; fields <t>Entries with ASCII fields are now limited to uppercase letters or d igits; fields
starting with 0x58, the uppercase letter "X", are reserved for Private or starting with 0x58, the uppercase letter "X", are reserved for Private or
Experimental Use.</t> Experimental Use.</t>
</li> </li>
<li> <li>
<t>The policy for every registry is now Specification Required, as def ined <t>The policy for every registry is now Specification Required, as def ined
in <xref section="4.6" sectionFormat="comma" target="RFC8126"/>.</t> in <xref section="4.6" sectionFormat="comma" target="RFC8126"/>.</t>
</li> </li>
</ul> </ul>
<t>The IESG is requested to choose three designated experts, with two bein <t>The IESG is requested to choose three designated experts, with approval
g s from two being required to implement a change. Guidance for the experts is giv
required to approve a registry change. Guidance for such experts is en below.</t>
given below.</t> <!-- [rfced] Section 3: This text seems misplaced. Perhaps this is intended to
appear in Section 4?
Original:
Each entry described in the sub-sections below is intended to
completely replace the existing entry with the same name.
-->
<t>Each entry described in the sub-sections below is intended to completel y <t>Each entry described in the sub-sections below is intended to completel y
replace the existing entry with the same name.</t> replace the existing entry with the same name.</t>
<section anchor="guidance-to-designated-experts"> <section anchor="guidance-to-designated-experts">
<name>Guidance to Designated Experts</name> <name>Guidance to Designated Experts</name>
<t>The designated experts (DE) should be familiar with <xref target="RFC 8126"/>, particularly <t>The designated experts (DE) should be familiar with <xref target="RFC 8126"/>, particularly
Section 5. As that reference suggests, the DE should ascertain the existence Section <xref target="RFC8126" section="5" sectionFormat="bare"/>. As that refer
of a suitable specification, and verify that it is publicly available. The DE ence suggests, the DE should ascertain the existence
of a suitable specification and verify that it is publicly available. The DE
is also expected to check the clarity of purpose and use of the requested is also expected to check the clarity of purpose and use of the requested
code points.</t> code points.</t>
<t>In addition, the DE is expected to be familiar with this document, <t>In addition, the DE is expected to be familiar with this document,
specifically the history documented here.</t> specifically the history documented here.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="ntp-reference-identifier-codes"> <section anchor="ntp-reference-identifier-codes">
<name>NTP Reference Identifier Codes</name> <name>NTP Reference Identifier Codes</name>
<t>The registration procedure is changed to Specification Required.</t> <!-- [rfced] Note that we have added "and this document has been added as a refe
<t>The Note is changed to read as follows:</t> rence" to the text in the IANA Considerations section. Please let us know if an
<ul spacing="normal"> y corrections are needed.
<li>
<t>Codes beginning with the character "X" are reserved for experimen For example:
tation Original:
and development. IANA cannot assign them.</t> The registration procedure is changed to Specification Required.
</li>
</ul> Current:
The registration procedure has been changed to Specification Required
and this document has been added as a reference.
-->
<t>The registration procedure has been changed to Specification Required
and this document has been added as a reference.</t>
<t>The Note has been changed to read as follows:</t>
<blockquote>Codes beginning with the character "X" are reserved for
experimentation and development. IANA cannot assign them.</blockquote>
<t>The columns are defined as follows:</t> <t>The columns are defined as follows:</t>
<ul spacing="normal"> <dl spacing="compact" newline="false">
<li> <dt>ID (required):</dt><dd> a four-byte value padded on the right
<t>ID (required): a four-byte value padded on the right with all-bit with all-bits-zero. Each byte other than padding must be ASCII
s-zero. uppercase letters or digits.</dd>
Each byte other than padding must be an ASCII uppercase letter or digits.</t> <dt>Clock source (required):</dt><dd>a brief text description of the I
</li> D.</dd>
<li> <dt>Reference (required):</dt><dd>the publication defining the ID.</dd
<t>Clock source (required): A brief text description of the ID.</t> >
</li> </dl>
<li>
<t>Reference (required): the publication defining the ID.</t>
</li>
</ul>
<t>The existing entries are left unchanged.</t> <t>The existing entries are left unchanged.</t>
</section> </section>
<section anchor="ntp-kiss-o-death-codes"> <section anchor="ntp-kiss-o-death-codes">
<name>NTP Kiss-o'-Death Codes</name> <name>NTP Kiss-o'-Death Codes</name>
<t>The registration procedure is changed to Specification Required.</t> <t>The registration procedure is changed to Specification Required and t
<t>The Note is changed to read as follows:</t> his document has been added as a reference.</t>
<ul spacing="normal"> <t>The Note has been changed to read as follows:</t>
<li>
<t>Codes beginning with the character "X" are reserved for experimen <blockquote>Codes beginning with the character "X" are reserved for
tation experimentation and development. IANA cannot assign them.</blockquote>
and development. IANA cannot assign them.</t>
</li>
</ul>
<t>The columns are defined as follows:</t> <t>The columns are defined as follows:</t>
<ul spacing="normal"> <dl spacing="compact" newline="false">
<li> <dt>ID (required):</dt><dd>a four-byte value padded on the right
<t>ID (required): a four-byte value padded on the right with all-bit with all-bits-zero. Each byte other than padding must be ASCII
s-zero. uppercase letters or digits.</dd>
Each byte other than padding must be an ASCII uppercase letter or digits.</t> <dt>Meaning source (required):</dt><dd>a brief text description of the
</li> ID.</dd>
<li> <dt>Reference (required):</dt><dd>the publication defining the ID.</dd
<t>Meaning source (required): A brief text description of the ID.</t >
> </dl>
</li>
<li>
<t>Reference (required): the publication defining the ID.</t>
</li>
</ul>
<t>The existing entries are left unchanged.</t> <t>The existing entries are left unchanged.</t>
</section> </section>
<section anchor="ntp-extension-field-types"> <section anchor="ntp-extension-field-types">
<name>NTP Extension Field Types</name> <name>NTP Extension Field Types</name>
<t>The registration procedure is changed to Specification Required.</t> <!-- [rfced] We have updated the text as follows to note that this document has
<t>The reference <xref target="RFC5906"/> should be added, if possible.< been added as a reference to the NTP Extension Field Types registry. Please let
/t> us know if any updates are needed.
<t>The following two Notes are added:</t>
<ul spacing="normal"> Original:
<li> The registration procedure is changed to Specification Required.
<t>Field Types in the range 0xF000 through 0xFFFF, inclusive, are re
served The reference [RFC5906] should be added, if possible.
for experimentation and development. IANA cannot assign them.
Both NTS Cookie and Autokey Message Request have the same Field Type; Current:
in practice this is not a problem as the field semantics will be The registration procedure has been changed to Specification Required
determined by other parts of the message.</t> and [RFC5906] and this document have been added as references.
</li> -->
<li>
<t>The "Reserved for historic reasons" is for differences between th <t>The registration procedure has been changed to Specification Required
e and <xref target="RFC5906"/> and this document have been added as references.</
original documentation and implementation of Autokey and marks t>
the erroneous values as reserved, in case there is an implementation <t>The following two Notes have been added:</t>
that used the registered values instead of what the original
implementation used.</t> <blockquote>Field Types in the range 0xF000 through 0xFFFF,
</li> inclusive, are reserved for experimentation and development. IANA
</ul> 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.</blockquote>
<blockquote>The "Reserved for historic reasons" is for differences
between the original documentation and implementation of Autokey and
marks the erroneous values as reserved, in case there is an
implementation that used the registered values instead of what the
original implementation used.</blockquote>
<t>The columns are defined as follows:</t> <t>The columns are defined as follows:</t>
<ul spacing="normal"> <dl spacing="compact" newline="false">
<li> <dt>Field Type (required):</dt><dd>a two-byte value in hexadecimal.</d
<t>Field Type (required): A two-byte value in hexadecimal.</t> d>
</li> <dt>Meaning (required):</dt><dd>a brief text description of the field
<li> type.</dd>
<t>Meaning (required): A brief text description of the field type.</ <dt>Reference (required):</dt><dd>the publication defining the field t
t> ype.</dd>
</li> </dl>
<li>
<t>Reference (required): the publication defining the field type.</t <t>IANA has updated the registry as shown in <xref target="tab1"/>.</t>
> <table anchor="tab1">
</li>
</ul>
<t>The table is replaced with the following entries.
IANA is requested to replace "This RFC" with the actual RFC number once
assigned.</t>
<table>
<thead> <thead>
<tr> <tr>
<th align="left">Field Type</th> <th align="left">Field Type</th>
<th align="left">Meaning</th> <th align="left">Meaning</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0x0000</td> <td align="left">0x0000</td>
<td align="left">Crypto-NAK; authentication failure</td> <td align="left">Crypto-NAK; authentication failure</td>
<td align="left">RFC 5905</td> <td align="left"><xref target="RFC5905"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0002</td> <td align="left">0x0002</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0102</td> <td align="left">0x0102</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0104</td> <td align="left">0x0104</td>
<td align="left">Unique Identifier</td> <td align="left">Unique Identifier</td>
<td align="left">RFC 8915, Section 5.3</td> <td align="left"><xref target="RFC8915" sectionFormat="comma" sect ion="5.3"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0200</td> <td align="left">0x0200</td>
<td align="left">No-Operation Request</td> <td align="left">No-Operation Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0201</td> <td align="left">0x0201</td>
<td align="left">Association Message Request</td> <td align="left">Association Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0202</td> <td align="left">0x0202</td>
<td align="left">Certificate Message Request</td> <td align="left">Certificate Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0203</td> <td align="left">0x0203</td>
<td align="left">Cookie Message Request</td> <td align="left">Cookie Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0204</td> <td align="left">0x0204</td>
<td align="left">Autokey Message Request</td> <td align="left">Autokey Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0204</td> <td align="left">0x0204</td>
<td align="left">NTS Cookie</td> <td align="left">NTS Cookie</td>
<td align="left">RFC 8915, Section 5.4</td> <td align="left"><xref target="RFC8915" sectionFormat="comma" sect ion="5.4"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0205</td> <td align="left">0x0205</td>
<td align="left">Leapseconds Message Request</td> <td align="left">Leapseconds Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0206</td> <td align="left">0x0206</td>
<td align="left">Sign Message Request</td> <td align="left">Sign Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0207</td> <td align="left">0x0207</td>
<td align="left">IFF Identity Message Request</td> <td align="left">IFF Identity Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0208</td> <td align="left">0x0208</td>
<td align="left">GQ Identity Message Request</td> <td align="left">GQ Identity Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0209</td> <td align="left">0x0209</td>
<td align="left">MV Identity Message Request</td> <td align="left">MV Identity Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0302</td> <td align="left">0x0302</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0304</td> <td align="left">0x0304</td>
<td align="left">NTS Cookie Placeholder</td> <td align="left">NTS Cookie Placeholder</td>
<td align="left">RFC 8915, Section 5.5</td> <td align="left"><xref target="RFC8915" sectionFormat="comma" sect ion="5.5"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0402</td> <td align="left">0x0402</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0404</td> <td align="left">0x0404</td>
<td align="left">NTS Authenticator and Encrypted Extension Fields< /td> <td align="left">NTS Authenticator and Encrypted Extension Fields< /td>
<td align="left">RFC 8915, Section 5.6</td> <td align="left"><xref target="RFC8915" sectionFormat="comma" sect ion="5.6"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0502</td> <td align="left">0x0502</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0602</td> <td align="left">0x0602</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0702</td> <td align="left">0x0702</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr>
<tr>
<td align="left">0x0802</td>
<td align="left">Reserved for historic reasons</td>
<td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0902</td> <td align="left">0x0902</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x2005</td> <td align="left">0x2005</td>
<td align="left">UDP Checksum Complement</td> <td align="left">UDP Checksum Complement</td>
<td align="left">RFC 7821</td> <td align="left"><xref target="RFC7821"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8002</td> <td align="left">0x8002</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8102</td> <td align="left">0x8102</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8200</td> <td align="left">0x8200</td>
<td align="left">No-Operation Response</td> <td align="left">No-Operation Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8201</td> <td align="left">0x8201</td>
<td align="left">Association Message Response</td> <td align="left">Association Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8202</td> <td align="left">0x8202</td>
<td align="left">Certificate Message Response</td> <td align="left">Certificate Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8203</td> <td align="left">0x8203</td>
<td align="left">Cookie Message Response</td> <td align="left">Cookie Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8204</td> <td align="left">0x8204</td>
<td align="left">Autokey Message Response</td> <td align="left">Autokey Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8205</td> <td align="left">0x8205</td>
<td align="left">Leapseconds Message Response</td> <td align="left">Leapseconds Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8206</td> <td align="left">0x8206</td>
<td align="left">Sign Message Response</td> <td align="left">Sign Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8207</td> <td align="left">0x8207</td>
<td align="left">IFF Identity Message Response</td> <td align="left">IFF Identity Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8208</td> <td align="left">0x8208</td>
<td align="left">GQ Identity Message Response</td> <td align="left">GQ Identity Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8209</td> <td align="left">0x8209</td>
<td align="left">MV Identity Message Response</td> <td align="left">MV Identity Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8302</td> <td align="left">0x8302</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8402</td> <td align="left">0x8402</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8502</td> <td align="left">0x8502</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8602</td> <td align="left">0x8602</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8702</td> <td align="left">0x8702</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8802</td> <td align="left">0x8802</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8902</td> <td align="left">0x8902</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC002</td> <td align="left">0xC002</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC102</td> <td align="left">0xC102</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC200</td> <td align="left">0xC200</td>
<td align="left">No-Operation Error Response</td> <td align="left">No-Operation Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC201</td> <td align="left">0xC201</td>
<td align="left">Association Message Error Response</td> <td align="left">Association Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC202</td> <td align="left">0xC202</td>
<td align="left">Certificate Message Error Response</td> <td align="left">Certificate Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC203</td> <td align="left">0xC203</td>
<td align="left">Cookie Message Error Response</td> <td align="left">Cookie Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC204</td> <td align="left">0xC204</td>
<td align="left">Autokey Message Error Response</td> <td align="left">Autokey Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC205</td> <td align="left">0xC205</td>
<td align="left">Leapseconds Message Error Response</td> <td align="left">Leapseconds Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC206</td> <td align="left">0xC206</td>
<td align="left">Sign Message Error Response</td> <td align="left">Sign Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC207</td> <td align="left">0xC207</td>
<td align="left">IFF Identity Message Error Response</td> <td align="left">IFF Identity Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC208</td> <td align="left">0xC208</td>
<td align="left">GQ Identity Message Error Response</td> <td align="left">GQ Identity Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC209</td> <td align="left">0xC209</td>
<td align="left">MV Identity Message Error Response</td> <td align="left">MV Identity Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC302</td> <td align="left">0xC302</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC402</td> <td align="left">0xC402</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC502</td> <td align="left">0xC502</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC602</td> <td align="left">0xC602</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC702</td> <td align="left">0xC702</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC802</td> <td align="left">0xC802</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC902</td> <td align="left">0xC902</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xF000-<br/>0xFFFF</td> <td align="left">0xF000-0xFFFF</td>
<td align="left">Reserved for Experimental Use</td> <td align="left">Reserved for Experimental Use</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<!-- [rfced] To what does "the appropriate table" refer? Is it the Reference co
lumn in table 1, or the tables as they appear in the IANA registry?
Original:
This document adds no new security considerations, as they are
defined in the document that defines the extension. See the
References column of the appropriate table.
-->
<t>This document adds no new security considerations, as they are defined <t>This document adds no new security considerations, as they are defined
in the document that defines the extension. See the References column of the in the document that defines the extension. See the References column of the
appropriate table.</t> appropriate table.</t>
</section> </section>
<section anchor="acknowledgements">
</middle>
<back>
<references anchor="sec-normative-references">
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.590
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.590
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.782
1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.782
2.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.812
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.857
3.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.891
5.xml"/>
</references>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The members of the NTP Working Group helped a great deal. <t>The members of the NTP Working Group helped a great deal.
Notable contributors include:</t> Notable contributors include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Miroslav Lichvar, Red Hat</t> <t><contact fullname="Miroslav Lichvar"/>, Red Hat</t>
</li> </li>
<li> <li>
<t>Daniel Franke, formerly at Akamai Technologies</t> <t><contact fullname="Daniel Franke"/>, formerly at Akamai Technologie s</t>
</li> </li>
<li> <li>
<t>Danny Mayer, Network Time Foundation</t> <t><contact fullname="Danny Mayer"/>, Network Time Foundation</t>
</li> </li>
<li> <li>
<t>Michelle Cotton, formerly at IANA</t> <t><contact fullname="Michelle Cotton"/>, formerly at IANA</t>
</li> </li>
<li> <li>
<t>Tamme Dittrich, Tweede Golf</t> <t><contact fullname="Tamme Dittrich"/>, Tweede Golf</t>
</li> </li>
</ul> </ul>
</section> </section>
</middle> <!-- [rfced] Please review the "Inclusive Language" portion of the online
<back> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
<references anchor="sec-normative-references"> and let us know if any changes are needed. Updates of this nature typically
<name>Normative References</name> result in more precise language, which is helpful for readers.
<reference anchor="RFC5905">
<front>
<title>Network Time Protocol Version 4: Protocol and Algorithms Specif
ication</title>
<author fullname="D. Mills" initials="D." surname="Mills"/>
<author fullname="J. Martin" initials="J." role="editor" surname="Mart
in"/>
<author fullname="J. Burbank" initials="J." surname="Burbank"/>
<author fullname="W. Kasch" initials="W." surname="Kasch"/>
<date month="June" year="2010"/>
<abstract>
<t>The Network Time Protocol (NTP) is widely used to synchronize com
puter clocks in the Internet. This document describes NTP version 4 (NTPv4), whi
ch 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 h
eader to accommodate the Internet Protocol version 6 address family. NTPv4 inclu
des fundamental improvements in the mitigation and discipline algorithms that ex
tend 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 c
ases, specific server configuration is not required. It corrects certain errors
in the NTPv3 design and implementation and includes an optional extension mechan
ism. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5905"/>
<seriesInfo name="DOI" value="10.17487/RFC5905"/>
</reference>
<reference anchor="RFC5906">
<front>
<title>Network Time Protocol Version 4: Autokey Specification</title>
<author fullname="B. Haberman" initials="B." role="editor" surname="Ha
berman"/>
<author fullname="D. Mills" initials="D." surname="Mills"/>
<date month="June" year="2010"/>
<abstract>
<t>This memo describes the Autokey security model for authenticating
servers to clients using the Network Time Protocol (NTP) and public key cryptog
raphy. Its design is based on the premise that IPsec schemes cannot be adopted i
ntact, since that would preclude stateless servers and severely compromise timek
eeping accuracy. In addition, Public Key Infrastructure (PKI) schemes presume au
thenticated time values are always available to enforce certificate lifetimes; h
owever, cryptographically verified timestamps require interaction between the ti
mekeeping and authentication functions.</t>
<t>This memo includes the Autokey requirements analysis, design prin
ciples, and protocol specification. A detailed description of the protocol state
s, events, and transition functions is included. A prototype of the Autokey desi
gn based on this memo has been implemented, tested, and documented in the NTP ve
rsion 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 In
ternet 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">
<front>
<title>UDP Checksum Complement in the Network Time Protocol (NTP)</tit
le>
<author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
<date month="March" year="2016"/>
<abstract>
<t>The Network Time Protocol (NTP) allows clients to synchronize to
a time server using timestamped protocol messages. To facilitate accurate timest
amping, some implementations use hardware-based timestamping engines that integr
ate the accurate transmission time into every outgoing NTP packet during transmi
ssion. Since these packets are transported over UDP, the UDP Checksum field is t
hen updated to reflect this modification. This document proposes an extension fi
eld that includes a 2-octet Checksum Complement, allowing timestamping engines t
o reflect the checksum modification in the last 2 octets of the packet rather th
an in the UDP Checksum field. The behavior defined in this document is interoper
able with existing NTP implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7821"/>
<seriesInfo name="DOI" value="10.17487/RFC7821"/>
</reference>
<reference anchor="RFC7822">
<front>
<title>Network Time Protocol Version 4 (NTPv4) Extension Fields</title
>
<author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
<author fullname="D. Mayer" initials="D." surname="Mayer"/>
<date month="March" year="2016"/>
<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 opt
ional field that resides at the end of the NTP header and that can be used to ad
d optional capabilities or additional information that is not conveyed in the st
andard NTP header. This document updates RFC 5905 by clarifying some points rega
rding NTP extension fields and their usage with Message Authentication Codes (MA
Cs).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7822"/>
<seriesInfo name="DOI" value="10.17487/RFC7822"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</
title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use const
ants to identify various protocol parameters. To ensure that the values in these
fields do not have conflicting uses and to promote interoperability, their allo
cations are often coordinated by a central record keeper. For IETF protocols, th
at role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance descr
ibing 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 d
efines a framework for the documentation of these guidelines by specification au
thors, 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>
<reference anchor="RFC8573">
<front>
<title>Message Authentication Code for the Network Time Protocol</titl
e>
<author fullname="A. Malhotra" initials="A." surname="Malhotra"/>
<author fullname="S. Goldberg" initials="S." surname="Goldberg"/>
<date month="June" year="2019"/>
<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 deprecat
es MD5-based authentication, which is considered too weak, and recommends the us
e 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">
<front>
<title>Network Time Security for the Network Time Protocol</title>
<author fullname="D. Franke" initials="D." surname="Franke"/>
<author fullname="D. Sibold" initials="D." surname="Sibold"/>
<author fullname="K. Teichel" initials="K." surname="Teichel"/>
<author fullname="M. Dansarie" initials="M." surname="Dansarie"/>
<author fullname="R. Sundblad" initials="R." surname="Sundblad"/>
<date month="September" year="2020"/>
<abstract>
<t>This memo specifies Network Time Security (NTS), a mechanism for
using Transport Layer Security (TLS) and Authenticated Encryption with Associate
d Data (AEAD) to provide cryptographic security for the client-server mode of th
e 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 fiel
ds in the NTP packets, and holds all required state only on the client via opaqu
e cookies.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8915"/>
<seriesInfo name="DOI" value="10.17487/RFC8915"/>
</reference>
</references>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+1bW3PbxhV+31+x4zzU7pCM7paZTKcqJbma1G5qKW1nOp3O
EliSW4FYFguIYmr/937n7C4IUCAth3loptVMEhLAnvv5zgVMv98XqU1yNddD
mRZqUvaNLif9vFz0q0WqSt0v9NS4sjDa9Q/PhL/ohvL0zcFpj/591pPnp6+P
e/L1+dER//tQlKbMQPAHetjkU1nOtHx/9738UNMSCchMbbEaSlemAhe1mg/l
zdXdtVja4n5a2GoxlJBDmEUxlGVRufLo4ODNwZHA0ypP/6Eym4PJCsQWZiik
LG3iv0rpbAGKE1d/X82bXxM7X6ikrO9W4/pKboW41yvIkA7l3yB0T+rHUufO
2Nz15NoaPXlz8f7i70KoqpzZggTo4x8pvTE/mGQmb1X2I1+zxXQoL+7VXBl5
p5NZbjM7NcxcSo2r2VAWDk//VvFDA8gjclvMYb8HTbQ/XI/I5MP4ob50Fi+d
+UvkgGH8UF86ipeO/KXzwyN/kD6ES/DiMH4Il94ceo70QYh+vy/VGOrDUkLc
kVN1Sd6Sd2au5feFhQtsJl/CbK8kfNS+f6uTqjDliu7fvpKIu2qu89KJVE9M
rqWSeTUf60LaiVTOmWmu03ipaXewyHRChslWMlH4ksYIE+vnBkLcWnBdX5Ez
9aDlsrCIyAeVVUTLtR9BMiACSjkBC7uUkLeAhBQvc5vLBSluEt1j3fioKrT8
J0JTFmY6Kwfi2hYsi1P3mvSguMo04kc7cCtnxtV6g+2D0UsnoQFnBxvs7rap
q6Brc9ByMmSeXM40eOY6AUVVrAbkiCbV+By8FpI0fDrzn3yy0iefsOAgwrfD
gffx3KRppoX4St7kZWHTClrb/Bfg8buAMw2fJypnA481nFpBQFWKb2dluXDD
r79eLpcDo3I1QH5+7QVg+b4m/FuoAplc6mLz6+BxVs6z37BvvBS3PwdH/ifQ
/l8KXi3HVXZP/NocyI6wYWoeTAp/m7y0ErEl4YjSDRGp8toUrgQ+K0Bt4Lvq
SVOCCMUXVZ5IzWutAPXzORgTNzwn3Cov1aM04YROByCLqLV52mNTkJoO3CeM
xUwE1NghuNRmjQN4xDgx1sR6blMzMSS5k26hE/4yoKy6esTz9EijHvosdppT
DdK4pDBjcPFC1FEQY66osiACvs0H4oYYk410TsaCqcaUXg6VqWwqze71ShOp
QFlxfhf6X5UpNMfjU+18djkUqxxh5CVZxPzHB3Ip6bSWrG0c4EqwT0/MEJ7w
rqHwInbMXyI+OUJycMlTomUJBhKNCMAXldcawJJZ6kBSUAhTzEeDpZIijKz8
Faw7wec80fLmsie/M8717a/6l1qVMyH+/e9QSD99ir7n6Frb+htm1SQC+1Jw
sLCvB8e96A3Rot1+6mQg5e8srnrRnc86RRla+wkwUciL29HNjUhmivIUKPMN
Aj0lX4IMe5xyVC4NSOF0f4zw7f+oCyvNpJlQVyE62dZolIpw5uDx9NyHtGeE
vAYXJOZCF4mCWH/tsWQFRCwefMQD380D8pb8cPWIBw07K5M/OJiYtWqGZkGO
QUb2EwIX/9ETG0iKHc6hTFKYaYAOdPeGFxsxzoEsawf1amsenn365F17FVsy
YABCQd6tFpRDHWdeD1oeBieb9/Gf/tIUOqY1fFM3eSIE17hCVJmUoytBd1pS
PtXRvM68mulZQ9Bj8CRb4Uvg2ilxA7UolKKUphQGCYDQL1Hvxqs1nB0fNLpR
+fLwwCfZhBOFzUotqlvgrgd6oYuCb/prrxgpolrIWsJW6BVc4/mwCiHTkNzV
PGeHNLyEOOvS+gBau0VGAEwPrxX14M1hjl7bG7gnbJ55Q1YIPwrSwOSiKi1a
8Iam0crUo4CHzws0D3rJaAzzjWY6uQfOyZGNoNKjCGuZXnSZvkH7CLSTTBUe
tuloJ651urInqC6ZpMJ5qKUKLv1Eg0CZay8OcCrSxXeUr1PWdUZxkngIHlm4
4+W7i9Erj3EDqq0PJ4CC5F7DrHOF/sciB2EqJfGcz3OFLFZFKK+wK8xpK0im
kbRJyQxzWHNtUU8dWKlSXUQLUGdIFpipfBr0T4rVorTTQi1mK3JTGgOBWHsJ
42FMCLVr2NPRO4xG9hlJELoB376QyWH9MXzpIDceWBsvdjbxIDcD7xr1IbIN
wu5my52VcEsyYmiMApncjMEfSHzweHh0fELAlOEIxZ6jayfHR77QPSoKuoGv
4UvcTCvN+Ba6D1/fOBXdWg0LSDc50q5dBwW4hxQYbPT2qOL3PreIVq5t5UIz
SBJF6O6R3ozpJceDcR3FluOGPbrOazycBnoAIHxXKZliSY/uEJjJDMTFAqnv
4ziUnzmXLG5cAycLoYLAPkL5JtA1Mz/qVJSB06qGKE4ei9JD+FtbLrVzyAGD
vKTih8cISl6JzX7CS12iag3EO5guriKemgwR46oilk2KJFcBV1VTJS8wGrcs
E9RcITTIxzztKNc3jntHCp+oIfW6c9gVLTBBXaH73lJUwbrnpGZD2EwrXxlc
PW7Exovg3G0W4RCj3GpTeLbbeKpruQ1Z7oTPzDkfrLtUnziNyKN5xKO8Q0U9
xE3g23RG1RU+yJOschjOXoX0b2S9jq1uezCvi/NZqK0RztcFkdT8DpFwBfuN
odKMM+ADevOihlz2FuNujDq9OUe6MDjMCk2zxIS7ubLd+C4svGxoq0X7J/Cg
0QZ1zZvD+x9XuTtOfane2Rk19Hu9U7/3BMpxiI76ODM3voh8RrMWo/OaEXWx
DVY8QBOzK+4EqMK4elr7iyq4r+Cr3S2dypxdSxLwwmEUBtCteJzhNR9utKeZ
JpBPEXsFrDOt0G5kHMmUWiuKEBogGyyrQIyil3H96kEXqzVYh4wFgbVQn+9V
iU4ISgYR7oHjGOFniCXyZm5K35Sv22LfJzsimwL9SlQDf0xwc03abfTXm2fl
i7++2Nlbi055yYIcmL5H0m0zIDdJ5K0hWg+0IrbStOhb92onA99LE5ebq9u3
RDB0kN4CycxariCcN5oij/1CLQXm714A4yUNMDBCHB75LHyLzrLVL3u4Gci3
iABF0xTpxBgbCNLcPAWG0MyPqIFoV9TZcnvXmO5CRUcX2XcRkPjA5vgbQS9b
QbRFphLt62bEI0+4rigc0LS59ehciwlKl2vlr7ys3mxPjSJfXl69opmbCgXN
dQqZbFTh2dRe+PSpJ5vNYp3FpwN5EUpQUY+drpoCp0vng+vyKtJXLgFPFQzC
etHz1D3QmsOUXKBcM0A8dCGQzCQuK3htsKgAsAl1rQ8K0INzfmC7vOLegQDA
d5IxNNBr+0aMmuWS265FVSwoYIgD9fOhhapjSiTU2i6soSWXEDc51QrjpQqK
Gddi88SArYrUE7VqGQEJSOB2aSlawiONZQDv6oFy6AJT7VHf+TLMbyXqET+l
Xhz5HXDSO7pZK/xEkKJXIHHrVtluycSQYe9tufl8Qc2VcgEk/T7LY/MY7PK8
Bha2c9wKEJY8hRK9xg+uZ36WfEBaLLh4e+0TlVOr5KtIHF7vGjMe0Y0j6IZk
N5fyZczwV0MeGKuiP16Vodl55q5i4JOaz1lqTikKcz7MGzPaRVJrlQeAfgKl
NQozRI4yi0B0EAW+a8p3IcfAekQg1VcPHovmVHtzyefXjm8e5rmPM0KFXVwY
vuuTd5tAUndeeoKmOg9uHtQR1t4P/T+0/vtD651WbKdfQHBt2YX9POG1rkP1
woeWPHWJY9/0aAcJ9HeGSsdm80c9AkVpaCfpQNjer2fxuF4iodBKXR8cHNQz
Br7ij4baMGa0mynREaby+WHKLS+1wiNr742vX3EBFZc0H8LGkofVultYy/8N
NVnx/YovU9yfldSk+h0GRX29uW5s0ZeG3xSJlN4szTk/xqsQwPyiI0bV3MtS
t4YvPjTT1Jc+k1DuO9S2FyTAhEN6EhxI2V8utWbFRT3Kt1cUpP3GFL3eRkj/
Pqe4d+ILVxCyawUhPrOCkLtWEJuzfhisn4k5jc1kO7MRq03ogRIz/ahSJMhc
ZS1g+BJE8E4vwe6nIkOLAinpuztu2rm5TdeIvs68gB4DwdG/2eHHtvgF75iQ
3C/WNBDKFYKD3gvHN7TUW8YJFEJ8bBrxY22WXX8fG5p/FB+H/fVf68vWv+ZT
IABkOCCg8LRHvKrsv7/47hupWltVtJEmI9wjCcJbcSlrAke1cDsSqlYhGqsm
cLg/gZNw64fcwD/NLrTTiPQS/81h4x3H6eA4Ejuq7fHe9v+4CL1ujWCdxAjU
5ZrAYbh14ZxNjD+/iYQ7CUR7jDCf+MKiv4zAcSTgIXnb2e0EokG3AfmzCTQK
w9a/bo+crImdhsf+oNXC8btl92X2OAu3bqls7bTGFgKvw62b6+sQXeVWo3QS
OA+33v7ps+e7CbwJt979+ScRON43yY67XPo94d/MZulmpnW79DQSO9lXmpOW
NI13QKBCRfYq5xcvvHFoNXdui2hnkfLpvqKd7Uvg9b4E3uxJABAYM+6Hy++7
3gx2+JreLEYC5/vWhPN9a8L5Vhj3r3Hb0dqRMOefg/E2nU4Cu2H8GQS2wniH
Ep0EtsP4UwqdBHYj7zNU2IK8z/fCZ5C3RaiTwG7kfYYKu5H3swT2Rd7zfcHy
fF9IO98X0s73hbTz830J7IuJo30hbbQvpI22QJp/K/UkpZ5G4mg3pG3S6SSw
C9KeRWALpHUq0UlgG6R1UegksAvSnqVCJ6R9iRd2QtoGoU4CuyDtWSrsgrRn
ENgX0kb7QtpoX0gb7Qtpo30hbbQvpI32hTTaEfa/HRe/8fvBDlKbr1U7SYmv
1r++2Hw/1P7xjUpTWurxu3UXjyStI72w5ls1l08iLDdrQrz3av6io/5Z1kBC
GN3+3akLC62wTBL8cnVRGMIu3gLx+62L5D63y0ynU//7Xb8lmmv/E4iwh6Jt
8V+s/x3MW/ofbORMZwv+bcKUfjwAoWjL9d767RL90KwwYyAV/4oiyaqUXsn/
Wr4zhXWZepB/MMnsQRU9SJvK36sS9y5VjkFFXhcqv9c9/mGh5h/ElZ3//wsf
yJG+aqVBp/WrmGv6CZ1fFRLPBMJCqpEtS3pp2KRM+y08c6fmOHZpSoidzHry
bql1quVbm03EfwCfoe+j6jQAAA==
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
--> -->
</back>
</rfc> </rfc>
 End of changes. 111 change blocks. 
501 lines changed or deleted 370 lines changed or added

This html diff was produced by rfcdiff 1.48.