UNICAST and BROADCAST mode response

[Alex Bligh]

--On 1 June 2011 08:01:45 +0100 Simon Hobson <dhcp1 at thehobsons.co.uk> wrote:

> my server (isc-dhcpd-4.2.1) can send replies either in
>> BROADCAST or in UNICAST mode (see wireshark screen capture). But
>> most of the time, the replies are in UNICAST. I am familiar with the
>> "always-unicast" config setting. However, if such a parameter is not
>> present, how/when does the server sends its OFFERs/AKCs/NAKs in
>> BROADCAST mode?
>
> In general, if the client is already configured with an IP address, then
> traffic will be unicast, otherwise it will be broadcast.
>
> So when a client first brings up it's interface, it can only broadcast as
> it has no address to use - and responses must also be broadcast. However,
> once it has an address*, the client can use unicast and talk directly to
> the server - and the server can talk directly back with unicast.

What is meant to happen is set out in the RFC (this may, particularly
in the case of clients, be different from what actually happens). I
believe the RFC specifies that certain responses are meant to be
broadcast *however* they are received (i.e. it isn't meant to look
at the means of arrival). Responses via a proxy are always unicast.
For direct responses, I believe the logic is

* If BOOTP_BROADCAST is set in the request, always broadcast the
  response.

* If the response is a response to DHCP_DISCOVER or DHCP_ACK (i.e.
  DHCP_OFFER, DHCP_ACK or DHCP_NAK) always broadcast the response.

* If the response is a response to DHCP_INFORM, then depend only
  on BOOTP_BROADCAST

* The BOOTP_BROADCAST flag in the response should be set if a broadcast
  reply is used.

That's my read, anyway.

-- 
Alex Bligh