RFC Errata
Found 14 records.
Status: Verified (14)
RFC 5905, "Network Time Protocol Version 4: Protocol and Algorithms Specification", June 2010
Note: This RFC has been updated by RFC 7822, RFC 8573, RFC 9109
Source of RFC: ntp (int)
Errata ID: 3007
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Danny Mayer
Date Reported: 2011-10-28
Verifier Name: Brian Haberman
Date Verified: 2012-04-27
Section 7.4 says:
b. For kiss code RATE, the client MUST immediately reduce its
polling interval to that server and continue to reduce it each
time it receives a RATE kiss code.
It should say:
b. For kiss code RATE, the client MUST immediately increase its
polling interval to that server and continue to increase it each
time it receives a RATE kiss code.
Notes:
The client needs to poll the server for new timestamps less often
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.
Errata ID: 4504
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Miroslav Lichvar
Date Reported: 2015-10-15
Verifier Name: Erik Kline
Date Verified: 2022-07-27
Section 7.3 says:
LI Leap Indicator (leap): 2-bit integer warning of an impending leap
second to be inserted or deleted in the last minute of the current
month with values defined in Figure 9.
+-------+----------------------------------------+
| Value | Meaning |
+-------+----------------------------------------+
| 0 | no warning |
| 1 | last minute of the day has 61 seconds |
| 2 | last minute of the day has 59 seconds |
It should say:
LI Leap Indicator (leap): 2-bit integer warning of an impending leap
second to be inserted or deleted in the last minute of the current
day with values defined in Figure 9.
+-------+----------------------------------------+
| Value | Meaning |
+-------+----------------------------------------+
| 0 | no warning |
| 1 | last minute of the day has 61 seconds |
| 2 | last minute of the day has 59 seconds |
Notes:
There is an inconsistency (day vs month) between the LI description and the description of values in the Figure 9. Few paragraphs before that text there is: Except for a minor variation when using the IPv6 address family, these fields are backwards compatible with NTPv3.
If it was month instead of day it would not be compatible with RFC 1305 (NTPv3) and RFC 4330 (SNTPv4), which were obsoleted by RFC 5905.
Errata ID: 5600
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Takashi Nakamoto
Date Reported: 2019-01-15
Verifier Name: Erik Kline
Date Verified: 2022-08-29
Section 10. says:
Let the first stage offset in the sorted list be theta_0; then, for
the other stages in any order, the jitter is the RMS average
+----- -----+^1/2
| n-1 |
| --- |
1 | \ 2 |
psi = -------- * | / (theta_0-theta_j) |
(n-1) | --- |
| j=1 |
+----- -----+
It should say:
Let the first stage offset in the sorted list be theta_0; then, for
the other stages in any order, the jitter is the RMS average
+----- -----+^1/2
| n-1 |
| --- |
| 1 \ 2 |
psi = | -------- * / (theta_0-theta_j) |
| (n-1) --- |
| j=1 |
+----- -----+
Notes:
The formula to calculate jitter "psi" in section "10. Clock Filter Algorithm" is incorrect, and also inconsistent with the formulate to calculate "psi_s" in section "11.2.2. Cluster Algorithm".
"psi" is defined as RMS average, so the term 1/(n-1) should be within [ ]^1/2 block.
Errata ID: 5601
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Takashi Nakamoto
Date Reported: 2019-01-15
Verifier Name: Erik Kline
Date Verified: 2022-09-26
Section 11.2.3. says:
| s.rootdisp <-- p.epsilon_r + p.epsilon + |
| p.psi + PHI * (s.t - p.t) |
| + |THETA| |
| s.refid <-- p.refid |
| s.reftime <-- p.reftime |
| s.t <-- p.t |
+-------------------------------------------+
Figure 25: System Variables Update
There is an important detail not shown. The dispersion increment
(p.epsilon + p.psi + PHI * (s.t - p.t) + |THETA|) is bounded from
below by MINDISP.
It should say:
| s.rootdisp <-- p.epsilon_r + p.epsilon + |
| p.psi + PHI * (t_s - p.t) |
| + |THETA| |
| s.refid <-- p.refid |
| s.reftime <-- p.reftime |
| s.t <-- p.t |
+-------------------------------------------+
Figure 25: System Variables Update
where t_s is the time when the system variables are updated.
There is an important detail not shown. The dispersion increment
(p.epsilon + p.psi + PHI * (t_s - p.t) + |THETA|) is bounded from
below by MINDISP.
Notes:
In the same section, it is said that "By rule, an update is discarded if its time of arrival p.t is not strictly later than the last update used s.t." This means that p.t > s.t when the system variable is updated. Hence, (s.t - p.t) is negative. It may lead to a negative dispersion, but, by definition, the dispersion cannot be negative. So, the original formula should be wrong.
Because the dispersion is defined as the value that grows at constant rate PHI, s.rootdisp should be
s.rootdisp <-- p.epsilon_r + p.epsilon + p.psi + PHI * (t_s - p.t) + |THETA|
where t_s is the time when the system variables are updated. The symbol t_s is arbitrary because it is not defined in other places.
---
[verifier notes]
From https://mailarchive.ietf.org/arch/msg/ntp/CHcBo-my1WdRg5PbhSU8aFlIS_k/ :
"""
... the reported section with is indeed erroneous, and s.t
should be replaced with c.t, defined in section 9.1/12. The attached
note seems inaccurate in the statement that a new name (t_s) is
needed, since c.t covers the required concept...
"""
Errata ID: 5978
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Verbree
Date Reported: 2020-02-08
Verifier Name: Erik Kline
Date Verified: 2022-09-26
Section A.5.1.1. says:
/*
* Verify valid root distance.
*/
if (r->rootdelay / 2 + r->rootdisp >= MAXDISP || p->reftime >
r->xmt)
return; /* invalid header values */
It should say:
/*
* Verify valid root distance.
*/
if (p->rootdelay / 2 + p->rootdisp >= MAXDISP || p->reftime >
r->xmt)
return; /* invalid header values */
Notes:
The r->rootdelay and r->rootdisp are the received values not in double format and therefore, should not be compared against MAXDISP. Use the p->rootdelay and p->rootdisp instead which have already been converted to double via FP2D macro.
---
[verifier notes]
See also https://mailarchive.ietf.org/arch/msg/ntp/Cbg3sOhChyfenYoj7UG5wCymFMU/
Errata ID: 6207
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tam Phan
Date Reported: 2020-06-08
Verifier Name: Erik Kline
Date Verified: 2022-09-26
Section A.5.5.1 says:
/*
* Find the largest contiguous intersection of correctness
* intervals. Allow is the number of allowed falsetickers;
* found is the number of midpoints. Note that the edge values
* are limited to the range +-(2 ^ 30) < +-2e9 by the timestamp
* calculations.
*/
low = 2e9; high = -2e9;
for (allow = 0; 2 * allow < n; allow++) {
/*
* Scan the chime list from lowest to highest to find
* the lower endpoint.
*/
found = 0;
chime = 0;
for (i = 0; i < n; i++) {
chime -= s.m[i].type;
if (chime >= n - found) {
low = s.m[i].edge;
break;
}
if (s.m[i].type == 0)
found++;
}
/*
* Scan the chime list from highest to lowest to find
* the upper endpoint.
*/
chime = 0;
for (i = n - 1; i >= 0; i--) {
chime += s.m[i].type;
if (chime >= n - found) {
high = s.m[i].edge;
break;
}
if (s.m[i].type == 0)
found++;
}
Mills, et al. Standards Track [Page 91]
RFC 5905 NTPv4 Specification June 2010
/*
* If the number of midpoints is greater than the number
* of allowed falsetickers, the intersection contains at
* least one truechimer with no midpoint. If so,
* increment the number of allowed falsetickers and go
* around again. If not and the intersection is
* non-empty, declare success.
*/
if (found > allow)
continue;
if (high > low)
break;
}
It should say:
/*
* Find the largest contiguous intersection of correctness
* intervals. Allow is the number of allowed falsetickers;
* found is the number of midpoints. Note that the edge values
* are limited to the range +-(2 ^ 30) < +-2e9 by the timestamp
* calculations.
*/
low = 2e9; high = -2e9;
for (allow = 0; 2 * allow < n; allow++) {
/*
* Scan the chime list from lowest to highest to find
* the lower endpoint.
*/
found = 0;
chime = 0;
for (i = 0; i < n; i++) {
chime -= s.m[i].type;
if (chime >= n - allow) {
low = s.m[i].edge;
break;
}
if (s.m[i].type == 0)
found++;
}
/*
* Scan the chime list from highest to lowest to find
* the upper endpoint.
*/
chime = 0;
for (i = n - 1; i >= 0; i--) {
chime += s.m[i].type;
if (chime >= n - allow) {
high = s.m[i].edge;
break;
}
if (s.m[i].type == 0)
found++;
}
Mills, et al. Standards Track [Page 91]
RFC 5905 NTPv4 Specification June 2010
/*
* If the number of midpoints is greater than the number
* of allowed falsetickers, the intersection contains at
* least one truechimer with no midpoint. If so,
* increment the number of allowed falsetickers and go
* around again. If not and the intersection is
* non-empty, declare success.
*/
if (found > allow)
continue;
if (high > low)
break;
}
Notes:
The algorithm described in section 11.2.3 is not properly written here; we compare c to n - f in the algorithm, but f != found; f corresponds to the "allowed" falsetickers. This algorithm implementation results in the lower and upper bounds unchanging throughout the described loop, but this change should fix the implementation.
---
[INT AD notes]
For analysis and further discussion see https://mailarchive.ietf.org/arch/msg/ntp/zJNoHvZ08SPX-3kwflMK7PIReFo/ especially the one or two addition issues identified.
Errata ID: 6550
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Perry Lorier
Date Reported: 2021-04-17
Verifier Name: Erik Kline
Date Verified: 2022-08-29
Section A.5.2 says:
for (i = 0; i < NSTAGE; i++) {
p->disp += f[i].disp / (2 ^ (i + 1));
p->jitter += SQUARE(f[i].offset - f[0].offset);
}
It should say:
for (i = 0; i < NSTAGE; i++) {
p->disp += f[i].disp / (1 << (i + 1));
p->jitter += SQUARE(f[i].offset - f[0].offset);
}
Notes:
^ is the xor operator in C, not the exponent operator. 2 xor (i+1) will be zero when i == 1, causing a division by zero error.
Errata ID: 4019
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Teruaki Kitasuka
Date Reported: 2014-06-20
Verifier Name: Brian Haberman
Date Verified: 2014-06-20
Section 11.2.1 says:
An example of this calculation is shown by the rootdist() routine in Appendix A.5.1.1.
It should say:
An example of this calculation is shown by the root_dist() routine in Appendix A.5.5.2.
Notes:
No rootdist() routine is in Appendix. root_dist() appears in Appendix A.5.5.2.
Errata ID: 4121
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marina Gertsvolf
Date Reported: 2014-09-23
Verifier Name: Brian Haberman
Date Verified: 2014-10-21
Section 8 says:
In the exchange above, a packet is duplicate or replay if the transmit timestamp t3 in the packet matches the org state variable T3.
It should say:
In the exchange above, a packet is duplicate or replay if the transmit timestamp t3 in the packet matches the org state variable.
Notes:
The org state variable for peer A has not yet been assigned the value T3.
Errata ID: 4680
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Riccardo Brama
Date Reported: 2016-04-29
Verifier Name: Erik Kline
Date Verified: 2022-07-27
Section 6, Fig 3 says:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Era Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Era Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Fraction |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NTP Date Format
It should say:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Era Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Era Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Fraction +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NTP Date Format
Notes:
This allows to better appreciate only two 32b rows really form the Fraction part, leading to an overall type length of 128b instead of 160b as it could otherwise be misunderstood in the original figure.
---
The "+" vs "|" on the Fraction line would seem to improve consistency with packet layouts in other documents.
Errata ID: 5104
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Denis Ovsienko
Date Reported: 2017-08-30
Verifier Name: Erik Kline
Date Verified: 2022-07-27
Section 7.3, Fig 8 says:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| dgst (128) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Digest (128) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
As the text before the figure explains, the last field is called "Message Digest", which is consistent with the rest of the document. In this document "dgst" and "mac" mean two protocol variables associated with this packet field.
---
Note: edited to clarify 4 32bit words, rather than 3 rows.
Errata ID: 5189
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2017-11-28
Verifier Name: Erik Kline
Date Verified: 2022-09-26
Section 6 says:
| 31 Dec 1999 | 51,543 | 0 | 3,155,587,200 | Last day 20th | | | | | | Century |
It should say:
| 31 Dec 2000 | 51,909 | 0 | 3,187,209,600 | Last day 20th | | | | | | Century |
Notes:
20th Century was from 1901 to 2000.
---
[verifier notes]
See also: https://mailarchive.ietf.org/arch/msg/ntp/Cbg3sOhChyfenYoj7UG5wCymFMU/
Errata ID: 7555
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sylvain Etienne
Date Reported: 2023-06-28
Verifier Name: RFC Editor
Date Verified: 2023-06-28
Section 4 says:
Under the auspices of the Metre Convention of 1865, in 1975 the CGPM [CGPM] strongly endorsed the use of UTC as the basis for civil time.
It should say:
Under the auspices of the Metre Convention of 1875, in 1975 the CGPM [CGPM] strongly endorsed the use of UTC as the basis for civil time.
Notes:
The Metre convention was signed on 20 May 1875 as stated on https://www.bipm.org/en/metre-convention.