This is the process of DHCP operation,
My question is at the 3rd step why does the Client send a Broadcast and not a Unicast as after the previous two operations the address of the DHCP server / Relay server should be known?
Add a comment
|
3 Answers
https://www.rfc-editor.org/rfc/rfc2131#page-16
The servers receive the DHCPREQUEST broadcast from the client. Those servers not selected by the DHCPREQUEST message use the message as notification that the client has declined that server's offer.
The protocol assumes there may be multiple DHCP servers. By broadcasting the request message, all servers that may have issued an offer can be aware of the client's choice.
-
But that could have been done by multicasting to those DHCP servers. Why broadcast everyone for it?– PagolMar 2, 2020 at 6:08
-
A multicast response would be assuming the servers are listening for a multicast group address, which isn't part of the standard. I would guess that broadcasting is less complex and therefore more reliable, even if it is noisier. Further, consider the case where DHCP relays are used. The router would have to be 'DHCP multicast' aware, adding an additional dependency into the network. The DHCP relay function could've been designed this way, but it's possible that mandating multicast support for something as basic as DHCP creates unnecessary overhead.– boomiMar 3, 2020 at 11:53
-
@Pagol, at the time of IPv4 BOOTP (DHCP is based on the Bootstrap Protocol) in September 1985, multicast did not exist as an RFC standard (July 1986). IPv6 does use multicast for DHCP: "DHCP servers receive messages from clients using a reserved, link-scoped multicast address. A DHCP client transmits most messages to this reserved multicast address, so that the client need not be configured with the address or addresses of DHCP servers."– Ron Maupin ♦Apr 26 at 21:00
You can potentially have multiple DHCP servers - the request is sent as broadcast to notify the other DHCP servers that have potentially sent offers that their offer isn't taken.
Because until the server sends the DHCPACK, the client still doesn’t have an IP address. It is possible for a DHCP server to respond to a request with a DHCPNACK.
-
2Why would that imply that broadcast would need to be used?The client knows the server's MAC address from the DHCPOFFER message, so it could send the DHCPREQUEST unicast to that server - there's no need for an IP address for that to happen.– psmearsMar 6, 2018 at 13:51
-
1@psmears, because L3 broadcasts are sent as L2 broadcasts. DHCP is not a L2 protocol, so you are bound to rules as the data is passed from L3 to L2.– YLearnMar 6, 2018 at 16:27
-
2@YLearn: You also need a source and destination IP for an L3 multicast or broadcast packet, too, so that's clearly not the issue :) There's no theoretical reason why the DHCPREQUEST packet couldn't be sent with the destination IP and MAC of the server, and (as with the broadcast packet) a source IP of 0.0.0.0. The reason for the broadcast is to let other DHCP servers (if any) know that the client is declining their offers.– psmearsMar 6, 2018 at 17:01
-
1@psmears, the destination of a L3 broadcast is 255.255.255.255. You can source a L3 broadcast from 0.0.0.0. However, you cannot source a L3 unicast from 0.0.0.0.– YLearnMar 6, 2018 at 17:20
-
2@YLearn: You can certainly send a packet with the bytes for the source address set to zero! That may be forbidden by some RFC though - do you know of one? RFC1700 says 0.0.0.0 "may only be used as a source address" (but nothing about unicast/broadcast); RFC1122 says 0.0.0.0 "MUST NOT be sent, except as a source address as part of an initialization procedure by which the host learns its own IP address" (again, no uni/broadcast restriction). Is this mandated somewhere else?– psmearsMar 6, 2018 at 17:37