RFC Errata
Found 11 records.
Status: Verified (6)
RFC 2131, "Dynamic Host Configuration Protocol", March 1997
Note: This RFC has been updated by RFC 3396, RFC 4361, RFC 5494, RFC 6842
Source of RFC: dhc (int)
Errata ID: 489
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Soohong Daniel Park
Date Reported: 2004-04-29
Section 3.1 number 5 says:
The client times out and retransmits the DHCPREQUEST message if the
client receives neither a DHCPACK or a DHCPNAK message.
...
If the client
receives neither a DHCPACK or a DHCPNAK message after employing the
retransmission algorithm, the client reverts to INIT state and
restarts the initialization process.
It should say:
The client times out and retransmits the DHCPREQUEST message if the
client receives neither a DHCPACK nor a DHCPNAK message.
...
If the client
receives neither a DHCPACK nor a DHCPNAK message after employing the
retransmission algorithm, the client reverts to INIT state and
restarts the initialization process.
Notes:
Errata ID: 490
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sreeni R. Nair
Date Reported: 2004-01-13
Section 4.1 says:
Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery.
It should say:
Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using unicast delivery.
Notes:
typo (uicast -> unicast). Updated 2013-06-05. Thanks to Carlos Prendes for the correction.
Errata ID: 7177
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2022-10-22
Verifier Name: Erik Kline
Date Verified: 2022-10-22
Section 4.1 says:
If the server has received a message through a DHCP relay agent, the server SHOULD choose an address from the interface on which the message was recieved as the 'server identifier' (unless the server has other, better information on which to make its choice).
It should say:
If the server has received a message through a DHCP relay agent, the server SHOULD choose an address from the interface on which the message was received as the 'server identifier' (unless the server has other, better information on which to make its choice).
Notes:
spelling correction
s/recieved/received/
Errata ID: 7367
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2023-02-23
Verifier Name: RFC Editor
Date Verified: 2023-02-23
Section 4.1 says:
The 'server identifier' field is used both to identify a DHCP server in a DHCP message and as a destination address from clients to servers. A server with multiple network addresses MUST be prepared to to accept any of its network addresses as identifying that server in a DHCP message.
It should say:
The 'server identifier' field is used both to identify a DHCP server in a DHCP message and as a destination address from clients to servers. A server with multiple network addresses MUST be prepared to accept any of its network addresses as identifying that server in a DHCP message.
Notes:
redundant word
s/to to/to/
Errata ID: 7368
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Panayiotis Gavriil
Date Reported: 2023-02-24
Verifier Name: RFC Editor
Date Verified: 2023-02-24
Section 3.1 says:
DHCPNAK - Server to client indicating client's notion of network
address is incorrect (e.g., client has moved to new
subnet) or client's lease as expired
It should say:
DHCPNAK - Server to client indicating client's notion of network
address is incorrect (e.g., client has moved to new
subnet) or client's lease has expired
Notes:
Spelling: "as expired" -> "has expired". (The original might have been the intended spelling, but grammatically it would make more sense to write "has" instead of "as" with the verb "indicate".)
Errata ID: 7369
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Panayiotis Gavriil
Date Reported: 2023-02-24
Verifier Name: RFC Editor
Date Verified: 2023-02-24
Section 3.2 says:
2. Servers with knowledge of the client's configuration parameters
respond with a DHCPACK message to the client. Servers SHOULD NOT
check that the client's network address is already in use; the
client may respond to ICMP Echo Request messages at this point.
Server Client Server
v v v
| | |
| Begins |
| initialization |
| | |
| /|\ |
| _________ __/ | \__________ |
| /DHCPREQU EST | DHCPREQUEST\ |
|/ | \|
| | |
Locates | Locates
configuration | configuration
| | |
|\ | /|
| \ | ___________/ |
| \ | / DHCPACK |
| \ _______ |/ |
| DHCPACK\ | |
| Initialization |
| complete |
| \| |
| | |
| (Subsequent |
| DHCPACKS |
| ignored) |
| | |
| | |
v v v
Figure 4: Timeline diagram of messages exchanged between DHCP
client and servers when reusing a previously allocated
network address
It should say:
2. Servers with knowledge of the client's configuration parameters
respond with a DHCPACK message to the client. Servers SHOULD NOT
check that the client's network address is already in use; the
client may respond to ICMP Echo Request messages at this point.
Server Client Server
v v v
| | |
| Begins |
| initialization |
| | |
| /|\ |
| __________/ | \__________ |
| /DHCPREQUEST | DHCPREQUEST\ |
|/ | \|
| | |
Locates | Locates
configuration | configuration
| | |
|\ | /|
| \___________ | ___________/ |
| DHCPACK \ | / DHCPACK |
| \|/ |
| | |
| Initialization |
| complete |
| | |
| | |
| (Subsequent |
| DHCPACKS |
| ignored) |
| | |
| | |
v v v
Figure 4: Timeline diagram of messages exchanged between DHCP
client and servers when reusing a previously allocated
network address
Notes:
Alignment in various places + removing space in the middle of a word ("DHCPREQU EST" -> "DHCPREQUEST")
Status: Held for Document Update (2)
RFC 2131, "Dynamic Host Configuration Protocol", March 1997
Note: This RFC has been updated by RFC 3396, RFC 4361, RFC 5494, RFC 6842
Source of RFC: dhc (int)
Errata ID: 488
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robert Floyd Jr
Date Reported: 2006-03-23
Held for Document Update by: Brian Haberman
Section 1.2 says:
In other related work, the path minimum transmission unit (MTU) discovery algorithm can determine the MTU of an arbitrary internet path [14].
It should say:
In other related work, the path maximum transmission unit (MTU) discovery algorithm can determine the MTU of an arbitrary internet path [14].
Errata ID: 6618
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rubén L.M.
Date Reported: 2021-06-22
Held for Document Update by: Eric Vyncke
Date Held: 2022-05-30
Section 3.1 says:
Server Client Server
(not selected) (selected)
v v v
| | |
| Begins initialization |
| | |
| _____________/|\____________ |
|/DHCPDISCOVER | DHCPDISCOVER \|
| | |
Determines | Determines
configuration | configuration
| | |
|\ | ____________/ |
| \________ | /DHCPOFFER |
| DHCPOFFER\ |/ |
| \ | |
| Collects replies |
| \| |
| Selects configuration |
| | |
| _____________/|\____________ |
|/ DHCPREQUEST | DHCPREQUEST\ |
| | |
| | Commits configuration
| | |
| | _____________/|
| |/ DHCPACK |
| | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\ ____________ |
| | DHCPRELEASE \|
| | |
| | Discards lease
| | |
v v v
Figure 3: Timeline diagram of messages exchanged between DHCP
client and servers when allocating a new network address
It should say:
Server Client Server
(not selected) (selected)
v v v
| | |
| Begins initialization |
| | |
| _____________/|\_____________ |
|/DHCPDISCOVER | DHCPDISCOVER \|
| | |
Determines | Determines
configuration | configuration
| | |
|\ | ____________/|
| \_________ | /DHCPOFFER |
| DHCPOFFER\ |/ |
| \ | |
| Collects replies |
| \| |
| Selects configuration |
| | |
| _____________/|\____________ |
|/ DHCPREQUEST | DHCPREQUEST\ |
| | |
| | Commits configuration
| | |
| | _____________/|
| |/ DHCPACK |
| | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\ ____________ |
| | DHCPRELEASE \|
| | |
| | Discards lease
| | |
v v v
Figure 3: Timeline diagram of messages exchanged between DHCP
client and servers when allocating a new network address
Notes:
alignment
Status: Rejected (3)
RFC 2131, "Dynamic Host Configuration Protocol", March 1997
Note: This RFC has been updated by RFC 3396, RFC 4361, RFC 5494, RFC 6842
Source of RFC: dhc (int)
Errata ID: 5100
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Fan Wei
Date Reported: 2017-08-29
Rejected by: Eric Vyncke
Date Rejected: 2024-04-23
Section 4.1 says:
Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery.
It should say:
Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK messages directly to the client using unicast delivery.
Notes:
According to prior part description in section 4.1: "In all cases, when ’giaddr’ is zero, the server broadcasts any DHCPNAK messages to 0xffffffff.", the DHCP server should not send DHCPNAK in unicast to client unless 'giaddr' is not zero.
--VERIFIER NOTES--
DHC WG feedback on this errata is:
"What's possibly being missed here is that the DHCP server has the client's MAC address, and is not relying on just on the routing table in the kernel, but also on giaddr and chaddr to determine how to send unicast responses. If giaddr is nonzero, the server sends the response using regular unicast through the IP stack's routing table, but if giaddr is zero, the server constructs a layer 2 frame with chaddr as the layer 2 destination address and unicasts that frame out the appropriate interface, bypassing the kernel's routing table and layer 3 processing entirely. So it doesn't actually matter what the IP destination address is other than that the client stack has to recognize that address as its own. The 'broadcast' bit takes care of the case where the client isn't able to do this. The server is always permitted to broadcast if it doesn't have the ability to route the response directly over layer 2, but at the time this RFC was written this was considered suboptimal, and the RFC goes to some lengths to make it possible for DHCP servers and relay agents to avoid sending broadcasts"
I.e., the current text is correct.
Errata ID: 6447
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Adrien de Croy
Date Reported: 2021-03-01
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03
Section 2.2 says:
a client requests the use of an address for some period of time. The allocation mechanism (the collection of DHCP servers) guarantees not to reallocate that address within the requested time
It should say:
a client requests the use of an address for some period of time. The allocation mechanism (the collection of DHCP servers) may or may not be able or willing to grant a lease for the requested duration. Any lease duration it offers it then guarantees not to reallocate within the offered time
Notes:
It is simply ludicrous to imagine that clients are in control of the lease duration, and that servers will simply comply, regardless of resource availability.
--VERIFIER NOTES--
The text does not say that the DHCP servers must grant the requested leased time. I.e., the current text is OK.
Errata ID: 7776
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Imrane
Date Reported: 2024-01-23
Rejected by: Eric Vyncke
Date Rejected: 2024-04-23
Section 4.3.1 says:
Client identifier MUST NOT MUST NOT MAY
It should say:
Client identifier MUST NOT MUST NOT MUST NOT
Notes:
In the "Options" list in Table 3 ("Fields and options used by DHCP server"), the "Client identifier" option has "MUST NOT" for both DHCPOFFER and DHCPACK; however, for DHCPNAK, it has "MAY".
"Client identifier" should be a "MUST NOT" for DHCPNAK as well.
It seems that the field should only be used by a client and never by a server, and if that's true for the OFFER and ACK, then it should be even more correct for the NAK.
"Vendor class identifier" has a MAY for all three messages, so maybe it was a typo in the previous option because of the repetitive input in the next one.
--VERIFIER NOTES--
RFC 6842 has addressed this problem with more information than a simple errata.
I.e., the problem in RFC 2131 exists indeed but has been fixed.