Why are DHCP request and acknowledgment messages broadcasted and not unicasted?
Asked Answered
S

1

6

In 'Request' part of the DORA process, IP and MAC address of the DHCP server is known to the client (as the IP datagram sent in Offer has this information). So if the destination is known, why is the request still broadcasted to every machine on the network?

Similarly in 'Ack' part of the DORA process, the IP address of the client is now successfully set inside it and known to the DHCP server. Why does it still broadcast the message?

Seasoning answered 18/8, 2015 at 9:29 Comment(0)
M
11

The REQUEST is broadcast for the case where there are multiple DHCP servers on the network and the client has received multiple OFFER responses, from RFC 2131 Section 3.1:

The servers receive the DHCPREQUEST broadcast from the client. Those servers not selected by the DHCPREQUEST message use the message as notification that the client has declined that server's offer. The server selected in the DHCPREQUEST message commits the binding for the client to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting client.

The ACK from the server may not always be a broadcast packet, but could be in the case you examined. Part of the DHCP protocol allows for enabling broadcast destination for DHCPOFFER, DHCPACK and DHCPNAK messages. This is necessary because some TCP/IP stacks can't receive unicast datagrams until the IP address have been fully claimed and assigned to the network interface. From RFC 2131 Section 4.1:

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.

Microbe answered 29/8, 2015 at 15:46 Comment(1)
The explanation is very clear and straight to the point. It helps a lotSelfcontradiction

© 2022 - 2024 — McMap. All rights reserved.