DHCP - Broadcast flag

DHCP uses a series of messages to perform the process necessary to assign IP addresses to DHCP clients. Until the process is fully completed, the client will not have fully formed its network parameters.

Some devices and operating systems are not capable of sending DHCP messages using unicast communication, even though they do obtain partial information about the destination MAC address and/or IP address of the intended destination of the DHCP message before the completion of the DORA process. It is for this reason that some messages, such as the DHCPOFFER and the DHCPACK messages may be sent either as unicast or broadcast. DHCPREQUEST and DHCPDICSOVER messages are always sent as broadcasts.

Both DHCPOFFER and DHCPACK messages are sent by the DHCP server. How does it know to send those messages as broadcast or unicast? It is informed using the Broadcast Flag found in the Flags field of the DHCP header. As stated in the RFC (link below):

To work around some clients that cannot accept IP unicast datagrams before the TCP/IP software is configured as discussed in the previous paragraph, DHCP uses the 'flags' field. The leftmost bit is defined as the BROADCAST (B) flag. The semantics of this flag are discussed in section 4.1 of this document. The remaining bits of the flags field are reserved for future use. They MUST be set to zero by clients and ignored by servers and relay agents. Figure 2 gives the format of the 'flags' field. 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B| MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B: BROADCAST flag MBZ: MUST BE ZERO (reserved for future use) Figure 2: Format of the 'flags' field

Using the broadcast flag, a client can inform the DHCP server whether it requires a broadcast response or it can handle a unicast response.

https://www.rfc-editor.org/rfc/rfc2131#page-11

Links to this page: