In the DHCP discover packet, the source IP address field is 0.0.0.0 which means the client does not have an IP address yet. But, in the DHCP offer packet, an unicast address (which will be allocated for this client) is specified as destination address. Since the client does not have an IP address at this moment, how does the packet which has an unicast address reach the client correctly ? How the client identifies that this offer packet is destined for it ? My understanding is that, the client which has no IP can only be reachable with a broadcast IP. I cannot understand how it is reachable with an unicast IP.
How DHCP OFFER unicast works
dhcp
Related Solutions
While an address of 0.0.0.0
can be used as a source address for DHCP, it shouldn't be used as a destination address on the network. The server can send a unicast message since it knows the host's MAC address. Remember that all traffic delivered to the host is on layer-2, so the important address is the MAC address.
This is important because a DHCP server may not be on the same LAN as the requesting host. A DHCP Offer may need to be routed, via layer-3, back to the network where the requesting host is connected.
Edit:
Thanks to richarb for providing the link to Clarifications and Extensions for the Bootstrap Protocol:
3.1.1 The BROADCAST flag
Normally, BOOTP servers and relay agents attempt to deliver BOOTREPLY messages directly to a client using unicast delivery. The IP destination address (in the IP header) is set to the BOOTP 'yiaddr' address and the link-layer destination address is set to the BOOTP 'chaddr' address. Unfortunately, some client implementations are unable to receive such unicast IP datagrams until they know their own IP address (thus we have a "chicken and egg" issue). Often, however, they can receive broadcast IP datagrams (those with a valid IP broadcast address as the IP destination and the link-layer broadcast address as the link-layer destination).
If a client falls into this category, it SHOULD set (to 1) the newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY messages it generates. This will provide a hint to BOOTP servers and relay agents that they should attempt to broadcast their BOOTREPLY messages to the client.
If a client does not have this limitation (i.e., it is perfectly able to receive unicast BOOTREPLY messages), it SHOULD NOT set the BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).
DISCUSSION: This addition to the protocol is a workaround for old host implementations. Such implementations SHOULD be modified so that they may receive unicast BOOTREPLY messages, thus making use of this workaround unnecessary. In general, the use of this mechanism is discouraged.
DHCP packets - aren't they always supposed to be broadcasted?
No, DHCP offers can be sent as unicast or broadcast. The layer-3 address doesn't really matter if it is unicast or broadcast because the frame is being delivered on the LAN by the layer-2 address.
From RFC 2321, Dynamic Host Configuration Protocol (emphasis mine):
In the case of a client using DHCP for initial configuration (before the client's TCP/IP software has been completely configured), DHCP requires creative use of the client's TCP/IP software and liberal interpretation of RFC 1122. The TCP/IP software SHOULD accept and forward to the IP layer any IP packets delivered to the client's hardware address before the IP address is configured; DHCP servers and BOOTP relay agents may not be able to deliver DHCP messages to clients that cannot accept hardware unicast datagrams before the TCP/IP software is configured.
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 [21]. 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
Best Answer
This is because the DHCP server must reside or have a relay/proxy on the same L2 network as the client.
The DHCP OFFER is sent to the L2 address of the client (i.e. it's MAC address). If the request was relayed/proxied, then the DHCP OFFER goes to the relay/proxy which will then forward it to the correct L2 network.
Broadcast traffic can be problematic for networks, so this reduces the amount of broadcast network that is necessary.