14

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 Discover and Request to direct the frame to the appropriate client machine.

Bruce
  • 33,927
  • 76
  • 174
  • 262
  • I have a suspicion this is needed to work in environments where there are multiple, collaborating DHCP servers. It might be needed for relay agents to work properly too. – Flexo May 17 '12 at 13:36

2 Answers2

20

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.

Unicast DHCPOFFER

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).

Community
  • 1
  • 1
Avio
  • 2,700
  • 6
  • 30
  • 50
  • Your question is not sufficiently clear. Please post [a new question](http://superuser.com/questions/ask) on Superuser detailing the behavior of the involved devices, their role and, possibly, IP addresses and captured logs. – Avio Sep 28 '12 at 08:24
  • I have a similar problem, but the thing is, I have a device which sends a DHCP Discover packet destined to 255.255.255.255, the server gets this message (since I use a packet logger to look at activities of all the nodes) and replies, this reply which my device gets is a broadcast frame from the DHCP server. But the device doesnot accept the IP configuration. Any kind of explanation for this anomaly? – Abhinav Sep 28 '12 at 08:39
  • Good answer. Explains how things work and if its possible to have non broadcast DHCPOFFER. But I would like also to know the reason of having a broadcasted DHCPOFFER. Any ideas? – limitcracker Sep 18 '14 at 18:03
0

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.

martin
  • 3,149
  • 1
  • 24
  • 35
sonam singhal
  • 1