RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 5905, "Network Time Protocol Version 4: Protocol and Algorithms Specification", June 2010

Source of RFC: ntp (int)

Errata ID: 3627
Status: Verified
Type: Technical
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.

Notes:

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.

Report New Errata