File talk:DHCP session en.svg

Isn't this picture slightly wrong? The state transitions should be:

DISCOVER (broadcast) — Not DISCOVERY.
OFFER (broadcast) — Not unicast, as the client is typically unconfigured as yet, the OFFER can't be unicast.
REQUEST (unicast) — This is not broadcast, as the client knows which DHCP server is making the OFFER, it is directly contacted for the REQUEST.
ACK (unicast)

JeremyCole (talk) 06:53, 19 December 2008 (UTC)[reply]

I think the pictures mixes up initial request and refreshing a lease. As I understand in the initial request the client has no IP until after the ACK, so all messages up to this point (including ACK) just have to be broadcast.

When refreshing REQUEST and ACK may be unicast, the client allready has an IP, so there is a direct way to answer.

Gsnerf (talk) 21:00, 16 February 2009 (UTC)[reply]

Both messages above are wrong. DHCP servers should reply with IP unicasts. However, DHCP allows the client to request (IP) broadcast replies with the BROADCAST bit and the RFC requires broadcasts in some situations. Whether the client knows its (future) IP is not relevant for the sender/server. The server may set the IP destination field as he pleases. Additionally, one could also argue that the picture refers to the data link layer (e.g. ethernet). The conduct on the link layer is similar: the client usually broadcasts and the server (or relay) replies in unicast. Therefore the general idea the image is conveying is correct. The use of IP addresses in the header is pretty much redundant for DHCP apart from the capability of routing this messages to the correct subnet. For all other purposes (like identifying the DHCP server) there are dedicated fields defined in the DHCP messages and the IP header is irrelevant. AmenophisIII (talk) 19:29, 16 November 2014 (UTC)[reply]