Re: [Technical Errata Reported] RFC2131 (5100)

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.

So the text as written is correct.

On Fri, Jan 12, 2024 at 1:47 AM Eric Vyncke (evyncke) <evyncke=
[email protected]> wrote:

> Let's start this new year with fixing this old errata...
>
> I would appreciate the wisdom of the DHC WG on this one
>
> Regards
>
> -éric
>
> On 03/08/2023, 13:14, "Eric Vyncke (evyncke)" <[email protected] <mailto:
> [email protected]>> wrote:
>
>
> While processing this old (2017) errata, I would like a confirmation by
> the DHC WG that the corrected text should rather be:
> " Normally, DHCP servers and BOOTP relay agents attempt to deliver
> DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
> unicast delivery except when noted in section 4.1 when 'giaddr' is zero."
>
> Thank you Fan for the errata and thank you all in advance for the
> confirmation,
>
> Regards
>
> -éric
>
> On 29/08/2017, 04:57, "RFC Errata System" <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5100 <
> http://www.rfc-editor.org/errata/eid5100>
>
>
> --------------------------------------
> Type: Technical
> Reported by: Fan Wei <[email protected] <mailto:[email protected]>>
>
>
> 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
> uicast 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.
>
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
>
> --------------------------------------
> 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
> Area : Internet
> Stream : IETF
> Verifying Party : IESG
>
> _______________________________________________
> dhcwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

_______________________________________________
dhcwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg