RFC 9748

Updating the NTP Registries

📅 published February 2025, from ietf

RFC 9748: Updating the NTP Registries 💖

Okay bestie, this is the RFC that cleans up the NTP registries 🧹✨ It's Updating the NTP Registries, written by R. Salz at Akamai Technologies, published in February 2025.

  • Request for Comments: 9748 🎀
  • Publisher: Internet Engineering Task Force (IETF) 🌐
  • Category: Standards Track, meaning it's an Internet Standards Track document 🏆
  • ISSN: 2070-1721
  • Updates: RFCs 5905, 5906, 7821, 7822, and 8573 💅
  • Obsoletes: the title block doesn't list anything it obsoletes

So this one updates five older RFCs. It doesn't replace any of them 🫶

Abstract ✨

NTP and NTS are the two protocol specs behind accurate time on the internet, and they each come with their own set of registries. Together those are called the NTP registries 🕰️

Some of those registries are totally fine, but others have wrong assignments, and some don't follow common practice either 💀 So this doc goes through every NTP and NTS registry, for completeness, and fixes the ones that need it 🔧

This document updates RFCs 5905, 5906, 7821, 7822, and 8573. 🦋

Status of This Memo 📜

This is an Internet Standards Track document. It's a product of the Internet Engineering Task Force (IETF), so it reflects consensus from the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 🙌

If you want more on Internet Standards, check out Section 2 of RFC 7841 🍓

You can find the current status, any errata, and the way to send feedback at <https://www.rfc-editor.org/info/rfc9748>. Bookmark that one 🔖

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

This document is covered by BCP 78 and by the IETF Trust's Legal Provisions Relating to IETF Documents, which you can read at https://trustee.ietf.org/license-info as they stood on the publication date. Please actually read those, because they spell out your rights and restrictions for this document 🧐

Any Code Components pulled out of this document have to include the Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come 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 🌸

Okay so, NTP and NTS together define a whole bunch of registries, and we call them the NTP registries as a group 🧚 You can find the NTP ones at https://www.iana.org/assignments/ntp-parameters, and the NTS ones at https://www.iana.org/assignments/nts 📍

Same tea as the abstract: some registries are right, some have incorrect assignments, and some don't match common practice. So this doc reviews all of them, for completeness, and corrects them where needed 🔍

The bulk of this document basically splits into two parts:

  • a summary of the relevant registries, covering the syntax requirements, the registration procedures, and the documents that define them 📚
  • a revised format and entries for each registry being changed 🔄

2. Existing Registries 📚

This section is a quick recap of the registries and the rules attached to them. It's meant to be a short summary of the syntax and registration requirements for each one 💅

What it doesn't cover is the semantics or the protocol processing rules, meaning how an implementation acts when it sends or receives any of the fields. Those live somewhere else, bestie 🙈

2.1. Reference ID and Kiss-o'-Death Registries 🔑

[RFC5905] defines two registries: "NTP Reference Identifier Codes" in Section 7.3 and "NTP Kiss-o'-Death Codes" in Section 7.4 ✨

Reference identifiers and kiss codes can be up to four ASCII characters, and if they're shorter, they get padded on the right with all-bits-zero. Entries that start with 0x58, which is the ASCII uppercase letter X, are reserved for Private or Experimental Use 🧪 Both registries are First Come First Served, and they were created per Section 16 of [RFC5905] 🎀

2.2. Extension Field Types 🧩

Section 7.5 of [RFC5905] defines what extension fields look like on the wire, but it doesn't create a registry for them. Iconic behaviour, honestly 💀

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 never gives a formal definition of the columns in the registry 🙃 Section 10 of [RFC5906] splits the Field Type into four subfields, but 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. It's especially about how they interact with the Message Authentication Code (MAC) field, since NTPv4 packets may have a MAC sitting exactly where you'd 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 🦋

Now for the tea ☕ The following problems exist with the current registry:

  • Many of the entries in the "NTP Extension Field Types" registry have swapped some of their nibbles. For example, 0x0302 was listed for Cookie Message Request instead of 0x0203 😭 The errors trace back to documentation errors in the original implementation of Autokey. This document marks the erroneous values as reserved. The reason is that some implementation might be using the registered values instead of what the original implementation used. Applications that used those values would have noticed they didn't interoperate with the dominant (if not only) implementation at the time. Marking them as reserved means those applications keep working as they do now 🛡️
  • 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 this document doesn't specify any changes to them 🤍

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. It splits 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, which splits its range in a similar way 🌷
  • Section 7.8 created the "Network Time Security Error Codes" and "Network Time Security Warning Codes" registries. Both are partitioned the same way 🎀

Part 1 is done, bestie! 🌈 Part 2 picks up with Section 3, NTP Registry Updates, so stay tuned 🧚✨

4.3. NTP Extension Field Types ✨

okay so this one's the registration procedure glow-up 💅 The registration procedure has been changed to Specification Required and [RFC5906] and this document have been added as references 🎀

Two Notes got added too, and they're lowkey important 👀

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.

Okay the note about the two Field Types 0x0204 is giving "it'll be fine" energy 🙈 Same number, different meanings, but the rest of the message sorts it out. Iconic.

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. Here's the whole glow-up, bestie 💖

+===============+====================================+=============+
| 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 🧚 Go check the References column, it's where the real security tea lives 💀

6. Normative References ✨

okay bestie, this is the reading list the spec leans on 📚 every one of these is a must-know if you wanna implement this stuff 💅

Acknowledgements 🫶

the NTP Working Group absolutely carried this one, no cap 🙌 these people helped a ton, so big thank yous to:

  • 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 🎀

the author behind all of this is Rich Salz 💖

Rich Salz
Akamai Technologies
Email: rsalz@akamai.com

that's the whole doc, periodt 🦋✨

📦 where this page comes from