Why are DHCP Offer and Ack broadcasted?

Question

Why can\'t the server use the destination IP address of 0.0.0.0 as is used in source IP of DHCP Discover and Request? It can use the MAC address of the client learnt from DHCP D

Answer 1

The unicast or broadcast choice is specified in the DHCP RFC 2131:

If the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the BOOTP relay agent whose address appears in 'giaddr'. 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.

with ciaddr and giaddr being:

ciaddr        4  Client IP address; only filled in if client is in BOUND, RENEW or REBINDING state and can respond to ARP requests.
giaddr        4  Relay agent IP address, used in booting via a relay agent.

So the DHCP server chooses to broadcast or not accordingly to the current state of the client (mainly if it has already a IP address or not) and accordingly to the sender of the message, if it's a relay agent or just a client.

In this case, my DCHP server chose to unicast the DHCPOFFER because my machine already had a IP address and I don't have a relay agent in my LAN.

EDIT:

And nobody can use the IP address 0.0.0.0 as a destination address. As specified in the IPv4 RFC 5735:

0.0.0.0/8 - Addresses in this block refer to source hosts on "this" network. Address 0.0.0.0/32 may be used as a source address for this host on this network; other addresses within 0.0.0.0/8 may be used to refer to specified hosts on this network ([RFC1122], Section 3.2.1.3).

Answer 2

From the RFC 2131, page 24:

Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery. The IP destination address (in the IP header) is set to the DHCP 'yiaddr' address and the link-layer destination address is set to the DHCP 'chaddr' address. Unfortunately, some client implementations are unable to receive such unicast IP datagrams until the implementation has been configured with a valid IP address (leading to a deadlock in which the client's IP address cannot be delivered until the client has been configured with an IP address).

A client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address SHOULD set the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or DHCPREQUEST messages that client sends. The BROADCAST bit will provide a hint to the DHCP server and BOOTP relay agent to broadcast any messages to the client on the client's subnet.

A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0. The BOOTP clarifications document discusses the ramifications of the use of the BROADCAST bit.