RFC 9748 PROPOSED STANDARD NTP · IANA · REGISTRIES
NTP registries update: Updating the NTP Registries
A clean-up of the IANA registries for NTP and NTS, fixing wrong entries and setting common rules.
RFC EDITOR
Salz, R., "Updating the NTP Registries", RFC 9748, DOI 10.17487/RFC9748, February 2025, <https://www.rfc-editor.org/info/rfc9748>.
BIBTEX
@misc{rfc9748,
series = {Request for Comments},
number = 9748,
howpublished = {RFC 9748},
publisher = {RFC Editor},
doi = {10.17487/RFC9748},
url = {https://www.rfc-editor.org/info/rfc9748},
author = {R. Salz},
title = {{Updating the NTP Registries}},
pagetotal = 10,
year = 2025,
month = feb,
} RFC text
Contents
Internet Engineering Task Force (IETF) R. Salz
Request for Comments: 9748 Akamai Technologies
Updates: 5905, 5906, 7821, 7822, 8573 February 2025
Category: Standards Track
ISSN: 2070-1721
Updating the NTP Registries
Abstract
The Network Time Protocol (NTP) and Network Time Security (NTS)
documents define a number of registries, collectively called the NTP
registries.
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.
This document updates RFCs 5905, 5906, 7821, 7822, and 8573.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
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 (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction
2. Existing Registries
2.1. Reference ID and Kiss-o'-Death Registries
2.2. Extension Field Types
2.3. Network Time Security Registries
3. NTP Registry Updates
3.1. Designated Experts
4. IANA Considerations
4.1. NTP Reference Identifier Codes
4.2. NTP Kiss-o'-Death Codes
4.3. NTP Extension Field Types
5. Security Considerations
6. Normative References
Acknowledgements
Author's Address
1. Introduction
The Network Time Protocol (NTP) and Network Time Security (NTS)
documents define a number of registries, collectively called the NTP
registries. The NTP registries can all be found at
<https://www.iana.org/assignments/ntp-parameters> and the NTS
registries can all be found at <https://www.iana.org/assignments/
nts>.
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.
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.
2. Existing Registries
This section describes the registries and the rules for them. It is
intended to be a short summary of the syntax and registration
requirements for each registry. The semantics and protocol
processing rules for each registry -- that is, how an implementation
acts when sending or receiving any of the fields -- are not described
here.
2.1. Reference ID and Kiss-o'-Death Registries
[RFC5905] defines two registries: "NTP Reference Identifier Codes" in
Section 7.3 and the "NTP Kiss-o'-Death Codes" in Section 7.4.
Reference identifiers and kiss codes can be up to four ASCII
characters, padded on the right with all-bits-zero if necessary.
Entries that start with 0x58, the ASCII letter uppercase X, are
reserved for Private or Experimental Use. Both registries are First
Come First Served. The registries were created per Section 16 of
[RFC5905].
2.2. Extension Field Types
Section 7.5 of [RFC5905] defines the on-the-wire format of extension
fields but does not create a registry for them.
Section 13 of [RFC5906] mentions the "NTP Extension Field Types"
registry, and defines it indirectly by defining 30 extensions (10
each for request, response, and error response). It does not provide
a formal definition of the columns in the registry. Section 10 of
[RFC5906] splits the Field Type into four subfields, only for use
within the Autokey extensions.
[RFC7821] adds a new entry, Checksum Complement, to the "NTP
Extension Field Types" registry.
[RFC7822] clarifies the processing rules for Extension Field Types,
particularly around the interaction with the Message Authentication
Code (MAC) field. NTPv4 packets may contain a MAC that appears where
one would expect the next extension field header.
[RFC8573] changes the cryptography used in the MAC field.
[RFC8915] adds four new entries to the "NTP Extension Field Types"
registry.
The following problems exist with the current registry:
* Many of the entries in the "NTP Extension Field Types" registry
have swapped some of the nibbles; for example, 0x0302 was listed
for Cookie Message Request instead of 0x0203. The errors are due
to documentation errors with the original implementation of
Autokey. This document marks the erroneous values as reserved, in
case there is an implementation using the registered values
instead of what the original implementation used. Applications
that used those values would have realized that they did not
interoperate with the dominant (if not only) implementation at the
time. Marking the values as reserved ensures that any such
applications continue to work as is.
* Some values were mistakenly reused.
2.3. Network Time Security Registries
[RFC8915] defines the NTS protocol. The related registries are
listed here for completeness, but there are no changes specified in
this document.
In [RFC8915]:
Sections 7.1 through 7.5 (inclusive) added entries to existing
registries.
Section 7.6 created the "Network Time Security Key Establishment
Record Types" registry that partitions the range into three different
registration policies: IETF Review, Specification Required, and
Private or Experimental Use.
Section 7.7 created the "Network Time Security Next Protocols"
registry that similarly partitions the range.
Section 7.8 created the "Network Time Security Error Codes" and
"Network Time Security Warning Codes" registries. Both registries
are partitioned the same way.
3. NTP Registry Updates
The following general guidelines apply to the NTP registries:
* A partition of the "NTP Extension Field Types" registry is
reserved for Private or Experimental Use.
* In the "NTP Reference Identifier Codes" and "NTP Kiss-o'-Death
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 policy for each registry is now Specification Required, as
defined in [RFC8126], Section 4.6.
3.1. 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 DEs should be familiar with [RFC8126], particularly Section 5.
As that reference 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 code points.
In addition, the DE is expected to be familiar with this document,
specifically the history documented here.
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
The registration procedure has been changed to Specification Required
and this document has been added as a reference.
The Note has been changed to read as follows:
| Codes beginning with the character "X" are reserved for
| experimentation and development. IANA cannot assign them.
The columns are defined as follows:
ID (required): a four-byte value padded on the right with all-bits-
zero. Each byte other than padding must be ASCII uppercase
letters or digits.
Clock source (required): a brief text description of the ID.
Reference (required): the publication defining the ID.
The existing entries are left unchanged.
4.2. NTP Kiss-o'-Death Codes
The registration procedure is changed to Specification Required and
this document has been added as a reference.
The Note has been changed to read as follows:
| Codes beginning with the character "X" are reserved for
| experimentation and development. IANA cannot assign them.
The columns are defined as follows:
ID (required): a four-byte value padded on the right with all-bits-
zero. Each byte other than padding must be ASCII uppercase
letters or digits.
Meaning source (required): a brief text description of the ID.
Reference (required): the publication defining the ID.
The existing entries are left unchanged.
4.3. NTP Extension Field Types
The registration procedure has been changed to Specification Required
and [RFC5906] and this document have been added as references.
The following two Notes have been added:
| Field Types in the range 0xF000 through 0xFFFF, inclusive, are
| reserved for experimentation and development. IANA cannot assign
| them. Both NTS Cookie and Autokey Message Request have the same
| Field Type; in practice this is not a problem as the field
| semantics will be determined by other parts of the message.
| 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.
The columns are defined as follows:
Field Type (required): a two-byte value in hexadecimal.
Meaning (required): a brief text description of the field type.
Reference (required): the publication defining the field type.
IANA has updated the registry as shown in Table 1.
+===============+====================================+=============+
| Field Type | Meaning | Reference |
+===============+====================================+=============+
| 0x0000 | Crypto-NAK; authentication failure | [RFC5905] |
+---------------+------------------------------------+-------------+
| 0x0002 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x0102 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x0104 | Unique Identifier | [RFC8915], |
| | | Section 5.3 |
+---------------+------------------------------------+-------------+
| 0x0200 | No-Operation Request | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x0201 | Association Message Request | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x0202 | Certificate Message Request | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x0203 | Cookie Message Request | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x0204 | Autokey Message Request | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x0204 | NTS Cookie | [RFC8915], |
| | | Section 5.4 |
+---------------+------------------------------------+-------------+
| 0x0205 | Leapseconds Message Request | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x0206 | Sign Message Request | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x0207 | IFF Identity Message Request | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x0208 | GQ Identity Message Request | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x0209 | MV Identity Message Request | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x0302 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x0304 | NTS Cookie Placeholder | [RFC8915], |
| | | Section 5.5 |
+---------------+------------------------------------+-------------+
| 0x0402 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x0404 | NTS Authenticator and Encrypted | [RFC8915], |
| | Extension Fields | Section 5.6 |
+---------------+------------------------------------+-------------+
| 0x0502 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x0602 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x0702 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x0802 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x0902 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x2005 | UDP Checksum Complement | [RFC7821] |
+---------------+------------------------------------+-------------+
| 0x8002 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x8102 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x8200 | No-Operation Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x8201 | Association Message Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x8202 | Certificate Message Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x8203 | Cookie Message Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x8204 | Autokey Message Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x8205 | Leapseconds Message Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x8206 | Sign Message Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x8207 | IFF Identity Message Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x8208 | GQ Identity Message Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x8209 | MV Identity Message Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0x8302 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x8402 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x8502 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x8602 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x8702 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x8802 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x8902 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0xC002 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0xC102 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0xC200 | No-Operation Error Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0xC201 | Association Message Error Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0xC202 | Certificate Message Error Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0xC203 | Cookie Message Error Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0xC204 | Autokey Message Error Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0xC205 | Leapseconds Message Error Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0xC206 | Sign Message Error Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0xC207 | IFF Identity Message Error | [RFC5906] |
| | Response | |
+---------------+------------------------------------+-------------+
| 0xC208 | GQ Identity Message Error Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0xC209 | MV Identity Message Error Response | [RFC5906] |
+---------------+------------------------------------+-------------+
| 0xC302 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0xC402 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0xC502 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0xC602 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0xC702 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0xC802 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0xC902 | Reserved for historic reasons | RFC 9748 |
+---------------+------------------------------------+-------------+
| 0xF000-0xFFFF | Reserved for Private or | RFC 9748 |
| | Experimental Use | |
+---------------+------------------------------------+-------------+
Table 1
5. Security Considerations
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 IANA registry.
6. Normative References
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol
Version 4: Autokey Specification", RFC 5906,
DOI 10.17487/RFC5906, June 2010,
<https://www.rfc-editor.org/info/rfc5906>.
[RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time
Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March
2016, <https://www.rfc-editor.org/info/rfc7821>.
[RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4
(NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822,
March 2016, <https://www.rfc-editor.org/info/rfc7822>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code
for the Network Time Protocol", RFC 8573,
DOI 10.17487/RFC8573, June 2019,
<https://www.rfc-editor.org/info/rfc8573>.
[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time
Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
<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
Rich Salz
Akamai Technologies
Email: rsalz@akamai.com
AI ELI5
On this page
PROBLEMSome of the NTP and NTS registries contain incorrect assignments or do not follow common practice, such as swapped nibbles in extension field types.
MECHANISMRFC 9748 reviews every NTP and NTS registry, switches the policy to Specification Required, reserves experimental ranges, and replaces the Extension Field Types table.
WHY IT MATTERSThe registries are now consistent and documented, and RFC 9748 updates RFCs 5905, 5906, 7821, 7822 and 8573.
§1Why the Registries Needed a Review
The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of registries, collectively called the NTP registries. Some are correct, but some include incorrect assignments and some do not follow common practice. This document reviews all of them for completeness and corrects them where necessary.
The bulk of the document has two parts: a summary of the relevant registries, with syntax requirements, registration procedures and defining documents, and a revised format and entries for each registry being modified. It does not describe how an implementation processes the fields.
Someone checked every list used by the clock-setting protocols and fixed the ones with mistakes.
§2The Existing Registries
RFC 5905 defines two registries: "NTP Reference Identifier Codes" and "NTP Kiss-o'-Death Codes". Both hold codes of up to four ASCII characters, padded on the right with all-bits-zero. Entries starting with 0x58, the ASCII letter uppercase X, are reserved for Private or Experimental Use. Both were First Come First Served.
The "NTP Extension Field Types" registry is the messy one. RFC 5905 defines the on-the-wire format of extension fields without creating a registry. RFC 5906 mentions the registry and defines it indirectly through 30 extensions (10 each for request, response and error response). RFC 7821 adds a Checksum Complement entry and RFC 8915 adds four entries.
The RFC lists two problems. Many entries have swapped nibbles; for example 0x0302 was listed for Cookie Message Request instead of 0x0203, because of documentation errors in the original Autokey implementation. Some values were also mistakenly reused. The NTS registries from RFC 8915 are listed for completeness, with no changes.
Some labels in the list had their digits swapped by accident, and a few labels were handed out twice.
§3The New Rules
Three general guidelines apply. A partition of the Extension Field Types registry is reserved for Private or Experimental Use. In the Reference Identifier and Kiss-o'-Death registries, ASCII entries are now limited to uppercase letters or digits, and fields starting with uppercase "X" (0x58) are reserved for Private or Experimental Use. The policy for each registry is now Specification Required, as defined in Section 4.6 of RFC 8126.
Both the Reference Identifier and Kiss-o'-Death registries get new Notes saying codes beginning with "X" are reserved for experimentation and development and IANA cannot assign them. Existing entries are left unchanged. The columns are an ID (four bytes, padded on the right with all-bits-zero), a description, and the defining reference.
New rules say names must use capital letters and digits, anything starting with X is for experiments, and a written description must exist before a name is handed out.
§4The Extension Field Types Table
The Extension Field Types registry now has Specification Required, with RFC 5906 and this document added as references. Field Types from 0xF000 through 0xFFFF are reserved for experimentation and development and IANA cannot assign them. The columns are Field Type (a two-byte hexadecimal value), Meaning and Reference.
The erroneous swapped-nibble values, such as 0x0002, 0x0302 and 0x8902, are marked "Reserved for historic reasons". They are reserved rather than deleted in case some implementation used the registered values instead of what the original Autokey implementation used. A Note also says that NTS Cookie and Autokey Message Request share the Field Type 0x0204; in practice this is not a problem because other parts of the message determine the field semantics.
Each entry in Section 4 is intended to completely replace the existing entry with the same name.
The wrong labels were not thrown away. They were put on hold with a note saying why, in case someone was already using them.
| Field Type | Meaning | Reference |
|---|---|---|
| 0x0000 | Crypto-NAK; authentication failure | RFC 5905 |
| 0x0104 | Unique Identifier | RFC 8915 |
| 0x0203 | Cookie Message Request | RFC 5906 |
| 0x0204 | Autokey Message Request and NTS Cookie (shared) | RFC 5906, RFC 8915 |
| 0x2005 | UDP Checksum Complement | RFC 7821 |
| 0x0302 THIS RFC | Reserved for historic reasons | RFC 9748 |
| 0xF000-0xFFFF THIS RFC | Reserved for Private or Experimental Use | RFC 9748 |
§5Designated Experts and Security
The IESG is asked to choose three designated experts (DEs), and approvals from two are required to implement a change. DEs should be familiar with RFC 8126, check that a suitable specification exists and is publicly available, and check the clarity of purpose and use of requested code points. They should also know this document, including the history it records.
The Security Considerations say the document adds no new security considerations, since those are defined in the document that defines each extension; see the References column of the relevant IANA registry.
A small panel of three experts checks new requests, and two of them must agree before anything changes.
§6References
[RFC5905]RFC 5905Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.June 2010[RFC5906]RFC 5906Haberman, B., Ed. and D. Mills, "Network Time Protocol Version 4: Autokey Specification", RFC 5906, June 2010.June 2010[RFC7821]RFC 7821Mizrahi, T., "UDP Checksum Complement in the Network Time Protocol (NTP)", RFC 7821, March 2016.March 2016[RFC7822]RFC 7822Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 (NTPv4) Extension Fields", RFC 7822, March 2016.March 2016[RFC8126]RFC 8126Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017.June 2017[RFC8573]RFC 8573Malhotra, A. and S. Goldberg, "Message Authentication Code for the Network Time Protocol", RFC 8573, June 2019.June 2019[RFC8915]RFC 8915Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Sundblad, "Network Time Security for the Network Time Protocol", RFC 8915, September 2020.September 2020