4

Wireshark trace from my PC when it was assigned an IP from DHCP server.

Why is a DHCP OFFER message is destined to IP: 10.0.0.21 (which was assigned to my PC by DHCP server later) before even the system configured it? When the host is still asking for an IP address, how can server send a unicast message? The host's IP address will still be 0.0.0.0 So, can anyone explain this?

Improve this question

2 Answers 2

Reset to default
3

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.

enter image description here

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.
Improve this answer
7
  • So, In a lot of my testing, I find that all four messages are broadcasts. I have a capture on my other PC, I'll upload that later. But without that for the moment, could you explain why all four messages are sometimes broadcasts, and other times alternating broadcast/unicast like all the documentation states.
    – Eddie
    Commented Mar 31, 2016 at 14:36
  • @Eddie, broadcasts at which layer (layer-3)?
    – Ron Maupin ♦
    Commented Mar 31, 2016 at 14:42
  • Both from what I recall. Dst IP 255.255.255.255, Dst MAC: ffff.ffff.ffff. I'll try to upload the packet capture when I get home.
    – Eddie
    Commented Mar 31, 2016 at 16:01
  • 2
    @Eddie A client can set the broadcast flag in the BOOTP options to indicate it would be confused by a unicast reply. See RFC 1542 section 3.1.1
    – richardb
    Commented Mar 31, 2016 at 16:50
  • @Ron So, under what conditions the OFFER message can be unicast and when can they be broadcast messages. As pointed by Eddie, I have seen all four messages broadcasted sometimes. So, why is that client needs to set its broadcast bit to 1 in some cases but not for all?
    – Rakesh Nittur
    Commented Mar 31, 2016 at 18:15
0

4.4.1 Initialization and allocation of network address:

The client begins in INIT state and forms a DHCPDISCOVER message.
The client should wait a random time between one and ten seconds to
desynchronize the use of DHCP at startup. The client sets 'ciaddr'(client IP Address) to 0x00000000. The client MAY request specific parameters by including the 'parameter request list' option. The client MAY suggest a network address and/or lease time by including the 'requested IP address' and 'IP address lease time' options. The client MUST include its hardware address in the 'chaddr'(client hardware address) field for use in delivery of DHCP reply messages. The client MAY include a different unique identifier in the 'client identifier' option. If the client does not include the 'client identifier' option, the server will use the contents of the 'chaddr' field to identify the client's lease.

The client generates and records a random transaction identifier and inserts that identifier into the 'xid' field. The client records its own local time for later use in computing the lease expiration. The client then broadcasts the DHCPDISCOVER on the local hardware broadcast address to 0xffffffff IP broadcast address and 'DHCP server' UDP port.

If the 'xid'(transaction id) of an arriving DHCPOFFER message does not match the 'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message must be silently discarded. Any arriving DHCPACK messages must be silently discarded.

The client collects DHCPOFFER messages over a period of time, selects one DHCPOFFER message from the (possibly many) incoming DHCPOFFER messages (e.g., the first DHCPOFFER message or the DHCPOFFER message from the previously used server) and extracts the server address from the 'server identifier' option in the DHCPOFFER message. The time over which the client collects messages and the mechanism used to select one DHCPOFFER are implementation dependent. The client may perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request. When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender's hardware address, and 0 as the sender's IP address, to avoid confusing ARP caches in other hosts on the same subnet. If the network address appears to be in use, the client sends a DHCPDECLINE message to the server and waits for another DHCPOFFER. As the client does not have a valid network address, the client must broadcast the DHCPDECLINE message.

Improve this answer
1
  • When quoting someone else's work, you should properly attribute it.
    – Ron Maupin ♦
    Commented Mar 31, 2016 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.