24

This is the process of DHCP operation, enter image description here

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?

Martin Schröder
  • 137
  • 1
  • 10
arif
  • 613
  • 2
  • 7
  • 12

3 Answers3

34

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.

Sanskar Omar
  • 3
  • 4
boomi
  • 993
  • 7
  • 10
  • But that could have been done by multicasting to those DHCP servers. Why broadcast everyone for it? – Pagol Mar 02 '20 at 06: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. – boomi Mar 03 '20 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 '23 at 21:00
11

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.

Zac67
  • 81,287
  • 3
  • 67
  • 131
6

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.

YLearn
  • 27,141
  • 5
  • 59
  • 128
  • 2
    Why 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. – psmears Mar 06 '18 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. – YLearn Mar 06 '18 at 16:27
  • doesn't the client also know the server's IP address at that point, so no need for broadcast on either of L2 or L3? – ilkkachu Mar 06 '18 at 16:28
  • @ilkkachu, to send a L3 unicast packet, there must be a source and destination IP. Since the client doesn’t have an IP it cannot send a unicast packet. – YLearn Mar 06 '18 at 16:30
  • 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. – psmears Mar 06 '18 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. – YLearn Mar 06 '18 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? – psmears Mar 06 '18 at 17:37
  • @psmears this is a larger discussion than comment are meant. When/if I have time later, I will provide an q/a to address this properly. – YLearn Mar 06 '18 at 20:04