Network Time Protocol Version 4 (NTPv4) Extension Fields
updated by
- rfc-9748 — Updating the NTP Registries
updates
- rfc-5905 — Network Time Protocol Version 4: Protocol and Algorithms Specification
Extracted elements (19)
Extension fields were introduced as a generic mechanism to add future capabilities without modifying the fixed NTP header format, as described in Section 16 of RFC 5905. The Field Type registry enables extensibility without protocol version changes.
The minimum size of 28 octets for a single extension field in the absence of a MAC is chosen to allow a receiver to unambiguously distinguish an extension field from a MAC (which is at most 24 octets), preventing parsing ambiguity when no MAC is present.
Erratum 3627 on RFC 5905 previously clarified that a MAC is not mandatory after an extension field; this document formally incorporates that correction by updating the normative text of Section 7.5 of RFC 5905.
A client and server can negotiate a MAC longer than 24 octets (the default cap when no extension field is present) by using a prior exchange of packets containing an extension field that defines the agreed MAC size and algorithm.
The Autokey extension field is always followed by a MAC; Section 10 of RFC 5906 specifies parsing rules for distinguishing extension fields from MACs in that context. This document clarifies that other extension fields do not require a trailing MAC.
A MAC is not mandatory after an NTP extension field. One or more extension fields can appear in an NTPv4 packet without a MAC being present, correcting the original RFC 5905 text which stated a MAC was always present when an extension field was present.
A MAC MUST NOT be longer than 24 octets if there is no extension field present, unless a longer MAC is agreed upon by both client and server via prior extension-field negotiation.
A specification that defines a new extension field MUST specify whether the extension field requires a MAC or not. If it does require a MAC, the specification MUST define the algorithm and MAC length.
If a host receives an extension field with an unknown Field Type, the host SHOULD ignore the extension field and MAY drop the packet altogether if policy requires it.
If an extension field allows more than one MAC algorithm, information about which algorithm was used MUST be included in the extension field itself.
If an NTP packet is received with two or more recognized extension fields that require a MAC with different algorithms, the packet MUST be discarded.
If there are multiple extension fields that require a MAC, they MUST all require the use of the same algorithm and MAC length. An NTP packet MUST NOT be sent with two or more extension fields requiring a MAC with different algorithms.
Middleboxes such as firewalls MUST NOT filter NTP packets based on their extension fields, since packets may contain new extension fields that the middlebox has not been updated to recognize.
When no MAC is present and a packet includes a single extension field, the length of that extension field MUST be at least 7 words (28 octets). If more than one extension field is present, the last MUST be at least 28 octets and all others MUST be at least 16 octets each.
An NTPv4 MAC field, when present, resides at the end of the packet and can be 24 octets, 20 octets, or a 4-octet crypto-NAK. It follows all extension fields when both are present.
The NTP extension field Field Type is a 16-bit value specific to the defined function, registered in an IANA registry; the corresponding registry entry points to the document that defines the Length, Value, and Padding semantics for that type.
An NTP server should flag packets containing a large number of extension fields or unusually large extension field sizes as a potential attack indicator, unless large fields are expected for the configured extension type.
Malicious use of extension fields cannot amplify DDoS attacks against NTP servers because servers ignore unknown extension fields and do not propagate or echo extension fields from incoming packets; servers create their own extension fields only when needed for a response.
An NTP extension field consists of a 16-bit Field Type, a 16-bit Length (total octets including padding), a variable-length Value, and zero-padding to a 4-octet (word) boundary. Minimum length is 16 octets (4 words); maximum length is 65532 octets due to the 16-bit Length field.