RFC 5905, "Network Time Protocol Version 4: Protocol and Algorithms Specification", June 2010Source of RFC: ntp (int)
See Also: RFC 5905 w/ inline errata
Errata ID: 3627
Publication Format(s) : TEXT
Reported By: Tal Mizrahi
Date Reported: 2013-05-17
Verifier Name: Brian Haberman
Date Verified: 2014-05-16
Section 7.5 says:
In NTPv4, one or more extension fields can be inserted after the header and before the MAC, which is always present when an extension field is present.
It should say:
In NTPv4, one or more extension fields can be inserted after the header and before the MAC, if a MAC is present. If a MAC is not present, one or more extension fields can be inserted after the header, according to the following rules: o If the packet includes a single extension field, the length of the extension field MUST be at least 7 words, i.e., at least 28 octets. o If the packet includes more than one extension field, the length of the last extension field MUST be at least 28 octets. The length of the other extension fields in this case MUST be at least 16 octets each.
The usage of NTP extension fields without authentication is aligned with Section 10 of RFC 5906:
The extension field parser initializes a pointer to the first octet beyond the NTP packet header and calculates the number of octets remaining to the end of the packet If the remaining length is 20 (128-bit digest plus 4-octet key ID) or 22 (160-bit digest plus 4-octet key ID), the remaining data are the MAC and parsing is complete. If the remaining length is greater than 22, an extension field is present. If the remaining length is less than 8 or not a multiple of 4, a format error has occurred and the packet is discarded; otherwise, the parser increments the pointer by the extension field length and then uses the same rules as above to determine whether a MAC is present or another extension field.