RFC Errata
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: 3126
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Richard Walters
Date Reported: 2012-02-16
Held for Document Update by: Brian Haberman
Section 3 says:
+-------------------+-------------------+------------------+ | Association Mode | Assoc. Mode Value | Packet Mode Value| +-------------------+-------------------+------------------+ | Symmetric Active | 1 | 1 or 2 | | Symmetric Passive | 2 | 1 | | Client | 3 | 4 | | Server | 4 | 3 | | Broadcast Server | 5 | 5 | | Broadcast Client | 6 | N/A | +-------------------+-------------------+------------------+ Figure 1: Association and Packet Modes In the client/server variant, a persistent client sends packet mode 4 packets to a server, which returns packet mode 3 packets.
It should say:
+-------------------+-------------------+------------------+ | Association Mode | Assoc. Mode Value | Packet Mode Value| +-------------------+-------------------+------------------+ | Symmetric Active | 1 | 1 or 2 | | Symmetric Passive | 2 | 1 | | Client | 3 | 4 | | Server | 4 | 3 | | Broadcast Server | 5 | N/A | | Broadcast Client | 6 | 5 | +-------------------+-------------------+------------------+ Figure 1: Association and Packet Modes In the client/server variant, a persistent client sends packet mode 3 packets to a server, which returns packet mode 4 packets.
Notes:
The majority of the rows in Figure 1 are correct if the 'Packet Mode Value' refers to the mode of packets which are expected to be received by an NTP speaker which has mobilized an association with the corresponding 'Association Mode'. Assuming this is the case, the last two rows are incorrect:
* A peer with a mobilized 'Broadcast Server' mode association is not expected to receive any packets at all for this association -- a broadcast server does not receive anything back (see 'Broadcast' mode row in Section 9.2, Figure 20, where each column in that row is 'DSCRD'.) Therefore, the value of 'Packet Mode Value' for 'Broadcast Server' should be 'N/A', not '5'.
* A peer with a mobilized 'Broadcast Client' mode association is expected to receive packets with a 'Packet Mode Value' of 5 for this association (see 'Bcast Client' mode row in Section 9.2, Figure 20, where each column in that row is 'DSCRD' except for the '5' column, which is 'PROC'.) Therefore, the value of 'Packet Mode Value' for 'Broadcast Client' should be '5', not 'N/A'.
It might help the clarity of Figure 1 if the row labeled 'Packet Mode Value' were to be changed to 'Receive Packet Mode Value(s)'.
The text immediately following Figure 1 also has the packet mode values swapped. As made clear throughout the RFC (for example, see Section 9.2 where is says, "FXMIT. This indicates a client (mode 3) packet matching no association (mode 0). If the destination address is not a broadcast address, the server constructs a server (mode 4) packet and returns it to the client without retaining state."), clients send servers packet mode 3 packets, not packet mode 4 packets; it is servers which send clients packet mode 4 packets, not packet mode 3 packets.
Just to make it perfectly clear, here are the modes of packets sent:
* Time t0: client mobilizes 'Client' mode association for server (via configuration, or due to reception of manycast server packet)
* Time t1: client transmits mode 3 packet to server (e.g. via poll(p) => peer_xmit(p) when c.t >= p->nextdate)
* Time t2: server receives mode 3 packet from client (dispatch: FXMIT; no association found or mobilized)
* Time t3: server transmits mode 4 packet to client
* Time t4: client receives mode 4 packet from server (matches previously mobilized association -- dispatch: PROC)