[Errata Rejected] RFC2131 (5100)
RFC Errata System <[email protected]>
| Newsgroups | gmane.ietf.dhc |
|---|---|
| Message-ID | <[email protected]> |
The following errata report has been rejected for RFC2131, "Dynamic Host Configuration Protocol". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5100 -------------------------------------- Status: Rejected Type: Technical Reported by: Fan Wei <[email protected]> Date Reported: 2017-08-29 Rejected by: Eric Vyncke (IESG) Section: 4.1 Original Text ------------- Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery. Corrected Text -------------- 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 goe s to some lengths to make it possible for DHCP servers and relay agents to avoid sending broadcasts" I.e., the current text is correct. -------------------------------------- RFC2131 (no draft string recorded) -------------------------------------- Title : Dynamic Host Configuration Protocol Publication Date : March 1997 Author(s) : R. Droms Category : DRAFT STANDARD Source : Dynamic Host Configuration Stream : IETF Verifying Party : IESG _______________________________________________ dhcwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/dhcwg