Updating the NTP Registries
updates
- rfc-5905 — Network Time Protocol Version 4: Protocol and Algorithms Specification
- rfc-5906 — Network Time Protocol Version 4: Autokey Specification
- rfc-7821 — UDP Checksum Complement in the Network Time Protocol (NTP)
- rfc-7822 — Network Time Protocol Version 4 (NTPv4) Extension Fields
- rfc-8573 — Message Authentication Code for the Network Time Protocol
Extracted elements (15)
Erroneous nibble-swapped Autokey Field Type values are marked 'Reserved for historic reasons' rather than being silently removed or reassigned. This ensures any implementation that was built against the incorrect registered values (rather than the dominant implementation's actual wire values) can continue to function without conflict.
RFC 5906 defined 30 Autokey extension field types but split the Field Type into four subfields (only for Autokey) and did not formally define registry columns, leading to inconsistencies. RFC 9748 provides formal column definitions and a complete corrected table to resolve the ambiguity.
Field Type 0x0204 is assigned to both 'Autokey Message Request' (RFC 5906) and 'NTS Cookie' (RFC 8915 Section 5.4). The registry Note states this dual assignment is not a problem in practice because field semantics are determined by other parts of the NTP message.
Many entries in the original 'NTP Extension Field Types' registry had nibble-swapped Field Type values due to documentation errors in the original Autokey implementation; for example, 0x0302 was listed instead of the correct 0x0203 for Cookie Message Request. This document marks the erroneous values as 'Reserved for historic reasons' rather than removing them, to preserve interoperability with any implementation that used the registered (incorrect) values.
Some Extension Field Type values were mistakenly reused across different Autokey messages in the original registry. This document corrects the assignments so each unique message type has a distinct, correct Field Type value.
Extension Field Type values in the range 0xF000 through 0xFFFF inclusive are reserved for Private or Experimental Use; IANA cannot assign them.
In the NTP Reference Identifier Codes and NTP Kiss-o'-Death Codes registries, each byte of the ID field (other than zero-padding) MUST be an ASCII uppercase letter or digit. Fields starting with 0x58 (uppercase 'X') are reserved for Private or Experimental Use and IANA cannot assign them.
The IESG is requested to appoint three Designated Experts (DEs) for the NTP registries, with approvals from at least two DEs required to implement any change. DEs must be familiar with RFC 8126 Section 5 and this document's historical context.
The registration policy for all three updated NTP registries (Reference Identifier Codes, Kiss-o'-Death Codes, and Extension Field Types) is now Specification Required as defined in RFC 8126 Section 4.6, replacing the prior First Come First Served policy.
NTP Extension Field Types are encoded as a two-byte hexadecimal value. The registry columns are Field Type (required, 2-byte hex), Meaning (required, text description), and Reference (required, defining publication).
NTP Reference Identifier Codes and Kiss-o'-Death Codes are encoded as a four-byte value, right-padded with all-bits-zero. Each non-padding byte must be an ASCII uppercase letter or digit (0x41–0x5A, 0x30–0x39). Entries starting with 0x58 ('X') are reserved for Private or Experimental Use.
The 'NTP Extension Field Types' registry is substantially revised: registration procedure changed to Specification Required, a range of 0xF000–0xFFFF reserved for Private or Experimental Use, many nibble-swapped Autokey values marked 'Reserved for historic reasons', and the full corrected table of ~70 entries (including NTS fields from RFC 8915) is specified.
The 'NTP Kiss-o'-Death Codes' registry is updated: registration procedure changed to Specification Required, Note updated for 'X'-prefix reservation, and columns formally defined as ID (4-byte ASCII uppercase/digits, zero-padded), Meaning source, and Reference.
The 'NTP Reference Identifier Codes' registry is updated: registration procedure changed to Specification Required, the Note updated to clarify that codes beginning with 'X' are reserved for experimentation and IANA cannot assign them, and columns formally defined as ID (4-byte ASCII uppercase/digits, zero-padded), Clock source, and Reference.
RFC 9748 introduces no new security considerations. Security properties for each extension field type are defined in the document that specifies that extension; implementors should consult the References column of the appropriate IANA registry.