Why is DHCP client able to accept DHCP Offer packet?

Question

I am seeing a DHCP packet flow, which consists of at least 4 packets:

• Discovery

• Offer

• Request

• ACK

With the discovery packet, client tries to find DHCP server. Since client does not know his own IP address and DHCP server's IP address, src and destination IP address are 0.0.0.0 and 255.255.255.255.

With the offer packet, the server responds to the client by setting the src IP address to his IP and dest IP address to client's new IP address. But I have a question now. The client at point does not know his IP address. How can the client accept this packet without knowing his IP address?

Answer 1

Remember that the exchange happens using layer-2 addressing, not layer-3 addressing. The frame is addressed to the host MAC address, so the host will accept the frame. A problem may arise at layer-3 for an unconfigured IPv4 process. Some, generally older, clients cannot process a unicast layer-3 packet until IPv4 has been configured, but there is a workaround for that. The client sets the broadcast flag so that it receives the offer as a broadcast.

It is all explained in _RFC 2131, Dynamic Host Configuration Protocol:

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

Answer 2

If you take a typical example of an Ethernet client and host/router, the acceptance or not by the client depends on the Ethernet MAC address, which is a 48-bit number, and does not depend on the 32-bit destination IP address at all. If not in promiscuous mode (activated by tcpdump and/or wireshark), the Ethernet MAC will block all incoming traffic which is not broadcast, multicast or addressed specifically to the client. The DHCP server will ensure it bypasses hardware filtering by extracting the clients MAC address from the DHCP discovery packet. Once the incoming packet's Ethernet header is stripped away in the client, it is typically a software and not a hardware problem to decide whether to accept the packet or not (for example by only accept the first DHCP server that responds, or only accepting offers from a particular class of DHCP server)

Answer 3

DHCP offer message: The server will respond to host in this message specifying the unleased IP address and other TCP configuration information. This message is broadcasted by server.

for the offer message

source IP address : DHCP SERVER IP address

destination IP address : 255.255.255.255

source MAC address : DHCP SERVER MAC address

destination MAC address : FFFFFFFFFFFF