Why are DHCP messages broadcast?

I am learning DHCP in my networking class and as a part of my research, I was watching the following video:

So in the Wireshark capture in the above video (at 3:48), all the DHCP OFFER, REQUEST and ACK messages have the broadcast address as the Destination IP.

On the other hand, the following article mentions that all the messages except the DISCOVER message are unicast :

My questions are : 1. Which one of them is right? Does it really depend upon case to case basis?

2. If all the DHCP messages as mentioned in the youtube video are Broadcast, then after the initial DISCOVER message, when the client gets to know the DHCP server IP, why wouldn't the client just use the server IP as the Destination IP, in other words, why doesn't it communicate using unicast messages?

1 Answer

The authoritative source for DHCP is more likely RFC 2131. Here are excerpts from section 3.1

1. The client broadcasts a DHCPDISCOVER message on its local physical subnet.

[...]

2. Each server may respond with a DHCPOFFER message

[...]

3. The client receives one or more DHCPOFFER messages from one or more servers. The client may choose to wait for multiple responses. The client chooses one server from which to request configuration parameters, based on the configuration parameters offered in the DHCPOFFER messages. The client broadcasts a DHCPREQUEST message that MUST include the 'server identifier' option to indicate which server it has selected

[...] 4. 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.

And the explanations continue. Whenever a broadcast is sent, it's explicitely stated.

So it's mostly related to the fact that for high availability, there might be more than one DHCP server on the network broadcast domain. If communication was switching to unicast right at the initial DHCPREQUEST, the other redundant servers wouldn't know if the client has elected an other server (allowing them to recycle their own offered IP address faster) or if it just vanished.

There are more rules of use described in section 4.1. Most often communication switches to unicast once the client starts using its assigned IP address (instead of source 0.0.0.0).

If the 'giaddr' field is zero and the 'ciaddr' field is nonzero, then the server unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'. If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is set, then the server broadcasts DHCPOFFER and DHCPACK messages to 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and 'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK messages to the client's hardware address and 'yiaddr' address. In all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK messages to 0xffffffff.

note: unicast to an IP address requires ARP resolution first (and thus the client to have configured the IP address), unicast to an hardware address doesn't (and would be used for the initial DHCPOFFER when the client doesn't have an IP).

Also, for example, section 4.3.2 explains the various use cases for DHCPREQUEST: SELECTION state (first use), INIT-REBOOT (cached information, but after not using it anymore), or RENEWING (extending lease). The 3rd case states that the message should be sent using unicast.