rfc9748.original   rfc9748.txt 
ntp R. Salz Internet Engineering Task Force (IETF) R. Salz
Internet-Draft Akamai Technologies Request for Comments: 9748 Akamai Technologies
Updates: 5905, 5906, 8573, 7822, 7821 (if 20 August 2024 Updates: 5905, 5906, 7821, 7822, 8573 February 2025
approved) Category: Standards Track
Intended status: Standards Track ISSN: 2070-1721
Expires: 21 February 2025
Updating the NTP Registries Updating the NTP Registries
draft-ietf-ntp-update-registries-16
Abstract Abstract
The Network Time Protocol (NTP) and Network Time Security (NTS) The Network Time Protocol (NTP) and Network Time Security (NTS)
documents define a number of assigned number registries, collectively documents define a number of registries, collectively called the NTP
called the NTP registries. 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, and
makes updates where necessary.
This document updates RFC 5905, RFC 5906, RFC 8573, RFC 7822, and RFC
7821.
Notes
This note is to be removed before publishing as an RFC.
This document is a product of the NTP Working Group Some registries are correct, but some include incorrect assignments
(https://dt.ietf.org/wg/ntp). Source for this draft and an issue and some don’t follow common practice. For the sake of completeness,
tracker can be found at https://github.com/richsalz/draft-rsalz- this document reviews all NTP and NTS registries, and corrects the
update-registries. registries where necessary.
RFC Editor: Please update 'this RFC' to refer to this document, once This document updates RFCs 5905, 5906, 7821, 7822, and 8573.
its RFC number is known, through the document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 21 February 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9748.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Existing Registries . . . . . . . . . . . . . . . . . . . . . 3 2. Existing Registries
2.1. Reference ID, Kiss-o'-Death . . . . . . . . . . . . . . . 3 2.1. Reference ID and Kiss-o'-Death Registries
2.2. Extension Field Types . . . . . . . . . . . . . . . . . . 3 2.2. Extension Field Types
2.3. Network Time Security Registries . . . . . . . . . . . . 4 2.3. Network Time Security Registries
3. Updated Registries . . . . . . . . . . . . . . . . . . . . . 5 3. NTP Registry Updates
3.1. Guidance to Designated Experts . . . . . . . . . . . . . 5 3.1. Designated Experts
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations
4.1. NTP Reference Identifier Codes . . . . . . . . . . . . . 5 4.1. NTP Reference Identifier Codes
4.2. NTP Kiss-o'-Death Codes . . . . . . . . . . . . . . . . . 6 4.2. NTP Kiss-o'-Death Codes
4.3. NTP Extension Field Types . . . . . . . . . . . . . . . . 6 4.3. NTP Extension Field Types
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. Normative References
7. Normative References . . . . . . . . . . . . . . . . . . . . 10 Acknowledgements
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address
1. Introduction 1. Introduction
The Network Time Protocol (NTP) and Network Time Security (NTS) The Network Time Protocol (NTP) and Network Time Security (NTS)
documents define a number of assigned number registries, collectively documents define a number of registries, collectively called the NTP
called the NTP registries. The NTP registries can all be found at registries. The NTP registries can all be found at
https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml <https://www.iana.org/assignments/ntp-parameters> and the NTS
(https://www.iana.org/assignments/ntp-parameters/ntp- registries can all be found at <https://www.iana.org/assignments/
parameters.xhtml) and the NTS registries can all be found at nts>.
https://www.iana.org/assignments/nts/nts.xhtml
(https://www.iana.org/assignments/nts/nts.xhtml).
Some registries have wrong values, some registries do not follow Some registries are correct, but some include incorrect assignments
current common practice, and some are just right. For the sake of and some don’t follow common practice. For the sake of completeness,
completeness, this document reviews all NTP and NTS registries, and this document reviews all NTP and NTS registries, and corrects the
makes updates where necessary. registries where necessary.
The bulk of this document can be divided into two parts: The bulk of this document can be divided into two parts:
* First, each registry, its defining document, and a summary of its * a summary of the relevant registries, including syntax
syntax is defined. requirements, registration procedures, and the defining documents.
* Second, the revised format and entries for each registry that is * a revised format and entries for each registry being modified.
being modified is specified.
2. Existing Registries 2. Existing Registries
This section describes the registries and the rules for them. It is This section describes the registries and the rules for them. It is
intended to be a short summary of the syntax and registration intended to be a short summary of the syntax and registration
requirements for each registry. The semantics and protocol requirements for each registry. The semantics and protocol
processing rules for each registry -- that is, how an implementation processing rules for each registry -- that is, how an implementation
acts when sending or receiving any of the fields -- are not described acts when sending or receiving any of the fields -- are not described
here. here.
2.1. Reference ID, Kiss-o'-Death 2.1. Reference ID and Kiss-o'-Death Registries
[RFC5905] defined two registries; the Reference ID in Section 7.3, [RFC5905] defines two registries: "NTP Reference Identifier Codes" in
and the Kiss-o'-Death in Section 7.4. Both of these are allowed to Section 7.3 and the "NTP Kiss-o'-Death Codes" in Section 7.4.
be four ASCII characters; padded on the right with all-bits-zero if Reference identifiers and kiss codes can be up to four ASCII
necessary. Entries that start with 0x58, the ASCII letter uppercase characters, padded on the right with all-bits-zero if necessary.
X, are reserved for Private or Experimental Use. Both registries are Entries that start with 0x58, the ASCII letter uppercase X, are
first-come first-served. The formal request to define the registries reserved for Private or Experimental Use. Both registries are First
is in [RFC5905], Section 16. Come First Served. The registries were created per Section 16 of
[RFC5905].
2.2. Extension Field Types 2.2. Extension Field Types
[RFC5905], Section 7.5 defined the on-the-wire format of extension Section 7.5 of [RFC5905] defines the on-the-wire format of extension
fields but did not create a registry for them. fields but does not create a registry for them.
[RFC5906], Section 13 mentioned the Extension Field Types registry, Section 13 of [RFC5906] mentions the "NTP Extension Field Types"
and defined it indirectly by defining 30 extensions (10 each for registry, and defines it indirectly by defining 30 extensions (10
request, response, and error response). It did not provide a formal each for request, response, and error response). It does not provide
definition of the columns in the registry. [RFC5906], Section 10 a formal definition of the columns in the registry. Section 10 of
splits the Field Type into four subfields, only for use within the [RFC5906] splits the Field Type into four subfields, only for use
Autokey extensions. within the Autokey extensions.
[RFC7821] added a new entry, Checksum Complement, to the Extension [RFC7821] adds a new entry, Checksum Complement, to the "NTP
Field Types registry. Extension Field Types" registry.
[RFC7822] clarified the processing rules for Extension Field Types, [RFC7822] clarifies the processing rules for Extension 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. one would expect the next extension field header.
[RFC8573] changed the cryptography used in the MAC field. [RFC8573] changes the cryptography used in the MAC field.
[RFC8915] added four new entries to the Extension Field Types [RFC8915] adds four new entries to the "NTP Extension Field Types"
registry. registry.
The following problems exist with the current registry: The following problems exist with the current registry:
* Many of the entries in the Extension Field Types registry have * Many of the entries in the "NTP Extension Field Types" registry
swapped some of the nibbles; 0x1234 is listed as 0x1432 for have swapped some of the nibbles; for example, 0x0302 was listed
example. This was due to documentation errors with the original for Cookie Message Request instead of 0x0203. The errors are due
implementation of Autokey. This document marks the erroneous to documentation errors with the original implementation of
values as reserved, in case there is an implementation that used Autokey. This document marks the erroneous values as reserved, in
the registered values instead of what the original implementation case there is an implementation using the registered values
used. Applications that might have used those values would have instead of what the original implementation used. Applications
realized that they did not interoperate with the dominant (if not that used those values would have realized that they did not
only) implementation at the time. Marking the values as reserved interoperate with the dominant (if not only) implementation at the
ensures that any such applications would still be able to work as- time. Marking the values as reserved ensures that any such
is. applications continue to work as is.
* Some values were mistakenly re-used. * Some values were mistakenly reused.
2.3. Network Time Security Registries 2.3. Network Time Security Registries
[RFC8915] defines the NTS protocol. Its registries are listed here [RFC8915] defines the NTS protocol. The related registries are
for completeness, but no changes to them are specified in this listed here for completeness, but there are no changes specified in
document. this document.
In [RFC8915]:
Sections 7.1 through 7.5 (inclusive) added entries to existing Sections 7.1 through 7.5 (inclusive) added entries to existing
registries. registries.
Section 7.6 created a new registry, NTS Key Establishment Record Section 7.6 created the "Network Time Security Key Establishment
Types, that partitions the assigned numbers into three different Record Types" registry that partitions the range into three different
registration policies: IETF Review, Specification Required, and registration policies: IETF Review, Specification Required, and
Private or Experimental Use. Private or Experimental Use.
Section 7.7 created a new registry, NTS Next Protocols, that Section 7.7 created the "Network Time Security Next Protocols"
similarly partitions the assigned numbers. registry that similarly partitions the range.
Section 7.8 created two new registries, NTS Error Codes and NTS
Warning Codes. Both registries are also partitioned the same way.
3. Updated Registries Section 7.8 created the "Network Time Security Error Codes" and
"Network Time Security Warning Codes" registries. Both registries
are partitioned the same way.
The following general guidelines apply to all registries updated 3. NTP Registry Updates
here:
* Every registry reserves a partition for Private or Experimental The following general guidelines apply to the NTP registries:
Use.
* Entries with ASCII fields are now limited to uppercase letters or * A partition of the "NTP Extension Field Types" registry is
digits; fields starting with 0x58, the uppercase letter "X", are
reserved for Private or Experimental Use. reserved for Private or Experimental Use.
* The policy for every registry is now Specification Required, as * In the "NTP Reference Identifier Codes" and "NTP Kiss-o'-Death
defined in [RFC8126], Section 4.6. Codes" registries, entries with ASCII fields are now limited to
uppercase letters or digits. Fields starting with 0x58, the
uppercase letter "X", are reserved for Private or Experimental
Use.
The IESG is requested to choose three designated experts, with two * The policy for each registry is now Specification Required, as
being required to approve a registry change. Guidance for such defined in [RFC8126], Section 4.6.
experts is given below.
Each entry described in the sub-sections below is intended to 3.1. Designated Experts
completely replace the existing entry with the same name.
3.1. Guidance to Designated Experts The IESG is requested to choose three designated experts (DEs), with
approvals from two being required to implement a change. Guidance
for the experts is given below.
The designated experts (DE) should be familiar with [RFC8126], The DEs should be familiar with [RFC8126], particularly Section 5.
particularly Section 5. As that reference suggests, the DE should As that reference suggests, the DE should ascertain the existence of
ascertain the existence of a suitable specification, and verify that a suitable specification and verify that it is publicly available.
it is publicly available. The DE is also expected to check the The DE is also expected to check the clarity of purpose and use of
clarity of purpose and use of the requested code points. the requested code points.
In addition, the DE is expected to be familiar with this document, In addition, the DE is expected to be familiar with this document,
specifically the history documented here. specifically the history documented here.
4. IANA Considerations 4. IANA Considerations
Each entry described in the subsections below is intended to
completely replace the existing entry with the same name.
4.1. NTP Reference Identifier Codes 4.1. NTP Reference Identifier Codes
The registration procedure is changed to Specification Required. The registration procedure has been changed to Specification Required
and this document has been added as a reference.
The Note is changed to read as follows: The Note has been changed to read as follows:
* Codes beginning with the character "X" are reserved for | Codes beginning with the character "X" are reserved for
experimentation and development. IANA cannot assign them. | experimentation and development. IANA cannot assign them.
The columns are defined as follows: The columns are defined as follows:
* ID (required): a four-byte value padded on the right with all- ID (required): a four-byte value padded on the right with all-bits-
bits-zero. Each byte other than padding must be an ASCII zero. Each byte other than padding must be ASCII uppercase
uppercase letter or digits. letters or digits.
Clock source (required): a brief text description of the ID.
* Clock source (required): A brief text description of the ID. Reference (required): the publication defining the ID.
* Reference (required): the publication defining the ID.
The existing entries are left unchanged. The existing entries are left unchanged.
4.2. NTP Kiss-o'-Death Codes 4.2. NTP Kiss-o'-Death Codes
The registration procedure is changed to Specification Required. The registration procedure is changed to Specification Required and
this document has been added as a reference.
The Note is changed to read as follows: The Note has been changed to read as follows:
* Codes beginning with the character "X" are reserved for | Codes beginning with the character "X" are reserved for
experimentation and development. IANA cannot assign them. | experimentation and development. IANA cannot assign them.
The columns are defined as follows: The columns are defined as follows:
* ID (required): a four-byte value padded on the right with all- ID (required): a four-byte value padded on the right with all-bits-
bits-zero. Each byte other than padding must be an ASCII zero. Each byte other than padding must be ASCII uppercase
uppercase letter or digits. letters or digits.
Meaning source (required): a brief text description of the ID.
* Meaning source (required): A brief text description of the ID. Reference (required): the publication defining the ID.
* Reference (required): the publication defining the ID.
The existing entries are left unchanged. The existing entries are left unchanged.
4.3. NTP Extension Field Types 4.3. NTP Extension Field Types
The registration procedure is changed to Specification Required. The registration procedure has been changed to Specification Required
and [RFC5906] and this document have been added as references.
The reference [RFC5906] should be added, if possible.
The following two Notes are added: The following two Notes have been added:
* Field Types in the range 0xF000 through 0xFFFF, inclusive, are | Field Types in the range 0xF000 through 0xFFFF, inclusive, are
reserved for experimentation and development. IANA cannot assign | reserved for experimentation and development. IANA cannot assign
them. Both NTS Cookie and Autokey Message Request have the same | them. Both NTS Cookie and Autokey Message Request have the same
Field Type; in practice this is not a problem as the field | Field Type; in practice this is not a problem as the field
semantics will be determined by other parts of the message. | semantics will be determined by other parts of the message.
* The "Reserved for historic reasons" is for differences between the | The "Reserved for historic reasons" is for differences between the
original documentation and implementation of Autokey and marks the | original documentation and implementation of Autokey and marks the
erroneous values as reserved, in case there is an implementation | erroneous values as reserved, in case there is an implementation
that used the registered values instead of what the original | that used the registered values instead of what the original
implementation used. | implementation used.
The columns are defined as follows: The columns are defined as follows:
* Field Type (required): A two-byte value in hexadecimal. Field Type (required): a two-byte value in hexadecimal.
Meaning (required): a brief text description of the field type.
* Meaning (required): A brief text description of the field type. Reference (required): the publication defining the field type.
* Reference (required): the publication defining the field type.
The table is replaced with the following entries. IANA is requested IANA has updated the registry as shown in Table 1.
to replace "This RFC" with the actual RFC number once assigned.
+============+====================================+=============+ +===============+====================================+=============+
| Field Type | Meaning | Reference | | Field Type | Meaning | Reference |
+============+====================================+=============+ +===============+====================================+=============+
| 0x0000 | Crypto-NAK; authentication failure | RFC 5905 | | 0x0000 | Crypto-NAK; authentication failure | [RFC5905] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0002 | Reserved for historic reasons | This RFC | | 0x0002 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0102 | Reserved for historic reasons | This RFC | | 0x0102 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0104 | Unique Identifier | RFC 8915, | | 0x0104 | Unique Identifier | [RFC8915], |
| | | Section 5.3 | | | | Section 5.3 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0200 | No-Operation Request | RFC 5906 | | 0x0200 | No-Operation Request | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0201 | Association Message Request | RFC 5906 | | 0x0201 | Association Message Request | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0202 | Certificate Message Request | RFC 5906 | | 0x0202 | Certificate Message Request | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0203 | Cookie Message Request | RFC 5906 | | 0x0203 | Cookie Message Request | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0204 | Autokey Message Request | RFC 5906 | | 0x0204 | Autokey Message Request | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0204 | NTS Cookie | RFC 8915, | | 0x0204 | NTS Cookie | [RFC8915], |
| | | Section 5.4 | | | | Section 5.4 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0205 | Leapseconds Message Request | RFC 5906 | | 0x0205 | Leapseconds Message Request | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0206 | Sign Message Request | RFC 5906 | | 0x0206 | Sign Message Request | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0207 | IFF Identity Message Request | RFC 5906 | | 0x0207 | IFF Identity Message Request | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0208 | GQ Identity Message Request | RFC 5906 | | 0x0208 | GQ Identity Message Request | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0209 | MV Identity Message Request | RFC 5906 | | 0x0209 | MV Identity Message Request | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0302 | Reserved for historic reasons | This RFC | | 0x0302 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0304 | NTS Cookie Placeholder | RFC 8915, | | 0x0304 | NTS Cookie Placeholder | [RFC8915], |
| | | Section 5.5 | | | | Section 5.5 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0402 | Reserved for historic reasons | This RFC | | 0x0402 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0404 | NTS Authenticator and Encrypted | RFC 8915, | | 0x0404 | NTS Authenticator and Encrypted | [RFC8915], |
| | Extension Fields | Section 5.6 | | | Extension Fields | Section 5.6 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0502 | Reserved for historic reasons | This RFC | | 0x0502 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0602 | Reserved for historic reasons | This RFC | | 0x0602 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0702 | Reserved for historic reasons | This RFC | | 0x0702 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x0902 | Reserved for historic reasons | This RFC | | 0x0802 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x2005 | UDP Checksum Complement | RFC 7821 | | 0x0902 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8002 | Reserved for historic reasons | This RFC | | 0x2005 | UDP Checksum Complement | [RFC7821] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8102 | Reserved for historic reasons | This RFC | | 0x8002 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8200 | No-Operation Response | RFC 5906 | | 0x8102 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8201 | Association Message Response | RFC 5906 | | 0x8200 | No-Operation Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8202 | Certificate Message Response | RFC 5906 | | 0x8201 | Association Message Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8203 | Cookie Message Response | RFC 5906 | | 0x8202 | Certificate Message Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8204 | Autokey Message Response | RFC 5906 | | 0x8203 | Cookie Message Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8205 | Leapseconds Message Response | RFC 5906 | | 0x8204 | Autokey Message Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8206 | Sign Message Response | RFC 5906 | | 0x8205 | Leapseconds Message Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8207 | IFF Identity Message Response | RFC 5906 | | 0x8206 | Sign Message Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8208 | GQ Identity Message Response | RFC 5906 | | 0x8207 | IFF Identity Message Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8209 | MV Identity Message Response | RFC 5906 | | 0x8208 | GQ Identity Message Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8302 | Reserved for historic reasons | This RFC | | 0x8209 | MV Identity Message Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8402 | Reserved for historic reasons | This RFC | | 0x8302 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8502 | Reserved for historic reasons | This RFC | | 0x8402 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8602 | Reserved for historic reasons | This RFC | | 0x8502 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8702 | Reserved for historic reasons | This RFC | | 0x8602 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8802 | Reserved for historic reasons | This RFC | | 0x8702 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0x8902 | Reserved for historic reasons | This RFC | | 0x8802 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC002 | Reserved for historic reasons | This RFC | | 0x8902 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC102 | Reserved for historic reasons | This RFC | | 0xC002 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC200 | No-Operation Error Response | RFC 5906 | | 0xC102 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC201 | Association Message Error Response | RFC 5906 | | 0xC200 | No-Operation Error Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC202 | Certificate Message Error Response | RFC 5906 | | 0xC201 | Association Message Error Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC203 | Cookie Message Error Response | RFC 5906 | | 0xC202 | Certificate Message Error Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC204 | Autokey Message Error Response | RFC 5906 | | 0xC203 | Cookie Message Error Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC205 | Leapseconds Message Error Response | RFC 5906 | | 0xC204 | Autokey Message Error Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC206 | Sign Message Error Response | RFC 5906 | | 0xC205 | Leapseconds Message Error Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC207 | IFF Identity Message Error | RFC 5906 | | 0xC206 | Sign Message Error Response | [RFC5906] |
| | Response | | +---------------+------------------------------------+-------------+
+------------+------------------------------------+-------------+ | 0xC207 | IFF Identity Message Error | [RFC5906] |
| 0xC208 | GQ Identity Message Error Response | RFC 5906 | | | Response | |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC209 | MV Identity Message Error Response | RFC 5906 | | 0xC208 | GQ Identity Message Error Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC302 | Reserved for historic reasons | This RFC | | 0xC209 | MV Identity Message Error Response | [RFC5906] |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC402 | Reserved for historic reasons | This RFC | | 0xC302 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC502 | Reserved for historic reasons | This RFC | | 0xC402 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC602 | Reserved for historic reasons | This RFC | | 0xC502 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC702 | Reserved for historic reasons | This RFC | | 0xC602 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC802 | Reserved for historic reasons | This RFC | | 0xC702 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xC902 | Reserved for historic reasons | This RFC | | 0xC802 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+ +---------------+------------------------------------+-------------+
| 0xF000- | Reserved for Experimental Use | This RFC | | 0xC902 | Reserved for historic reasons | RFC 9748 |
| 0xFFFF | | | +---------------+------------------------------------+-------------+
+------------+------------------------------------+-------------+ | 0xF000-0xFFFF | Reserved for Experimental Use | RFC 9748 |
+---------------+------------------------------------+-------------+
Table 1 Table 1
5. Security Considerations 5. Security Considerations
This document adds no new security considerations, as they are This document adds no new security considerations, as they are
defined in the document that defines the extension. See the defined in the document that defines the extension. See the
References column of the appropriate table. References column of the appropriate IANA registry.
6. Acknowledgements
The members of the NTP Working Group helped a great deal. Notable
contributors include:
* Miroslav Lichvar, Red Hat
* Daniel Franke, formerly at Akamai Technologies
* Danny Mayer, Network Time Foundation
* Michelle Cotton, formerly at IANA
* Tamme Dittrich, Tweede Golf
7. Normative References 6. Normative References
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/rfc/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol [RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol
Version 4: Autokey Specification", RFC 5906, Version 4: Autokey Specification", RFC 5906,
DOI 10.17487/RFC5906, June 2010, DOI 10.17487/RFC5906, June 2010,
<https://www.rfc-editor.org/rfc/rfc5906>. <https://www.rfc-editor.org/info/rfc5906>.
[RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time
Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March
2016, <https://www.rfc-editor.org/rfc/rfc7821>. 2016, <https://www.rfc-editor.org/info/rfc7821>.
[RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4
(NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822,
March 2016, <https://www.rfc-editor.org/rfc/rfc7822>. March 2016, <https://www.rfc-editor.org/info/rfc7822>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code [RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code
for the Network Time Protocol", RFC 8573, for the Network Time Protocol", RFC 8573,
DOI 10.17487/RFC8573, June 2019, DOI 10.17487/RFC8573, June 2019,
<https://www.rfc-editor.org/rfc/rfc8573>. <https://www.rfc-editor.org/info/rfc8573>.
[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time Sundblad, "Network Time Security for the Network Time
Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
<https://www.rfc-editor.org/rfc/rfc8915>. <https://www.rfc-editor.org/info/rfc8915>.
Acknowledgements
The members of the NTP Working Group helped a great deal. Notable
contributors include:
* Miroslav Lichvar, Red Hat
* Daniel Franke, formerly at Akamai Technologies
* Danny Mayer, Network Time Foundation
* Michelle Cotton, formerly at IANA
* Tamme Dittrich, Tweede Golf
Author's Address Author's Address
Rich Salz Rich Salz
Akamai Technologies Akamai Technologies
Email: rsalz@akamai.com Email: rsalz@akamai.com
 End of changes. 63 change blocks. 
343 lines changed or deleted 323 lines changed or added

This html diff was produced by rfcdiff 1.48.