DHCPACK question

[David W. Hankins]

On Thu, Feb 12, 2009 at 08:01:45AM +0000, Simon Hobson wrote:
>> Feb 12 08:35:18 net1 dhcpd: DHCPINFORM from 205.118.130.186 via 
>> 205.118.130.129
>> Feb 12 08:35:18 net1 dhcpd: DHCPACK to 205.118.130.186 (00:0d:5e:82:75:d1) 
>> via eth0
>
> * In the case of INFORM, I think the client just broadcasts the packet 
> (it's interested in any answer, not specifically an answer from the server 
> that gave it it's lease). It does however set the flag to say it can handle 
> a unicast reply and so the server replies directly, not via the relay 
> agent.

It's not the unicast flag that dictates this, the only language in
RFC 2131 that talks about replying to DHCPINFORMs says you SHOULD
unicast the reply to the contents of 'ciaddr'.

In this case, the client appears to be properly filling the ciaddr
field, but doesn't know the servers' unicast IP address(es).  It
broadcasts the DHCPINFORM, which hits relay agents, which forwards
to servers, which make their replies unicast to ciaddr.

This is all correct, and described in RFC 2131.

I think the OP is noticing that this behaviour is unlike 'DORA'
exchanges, which return the reply to 'giaddr' always if it is set
(the relay always handles the reply).

I don't know precisely why the DHCPINFORM exchange is so very
different from other message exchanges, but I have a theory;

DHCP leveraged existing BOOTP relays, so even today DHCP relay
behaviour is simply BOOTP relay behaviour with some DHCP-extension.

BOOTP relays will forward unicast replies (server->relay->client) to
the 'yiaddr' field, which is required to be zeroed in DHCPINFORM
replies.

So a unicast reply with DHCPINFORM via a relay agent is not a
possibility without extending BOOTP relays, or clouding the meaning
of the yiaddr field contents, or making all such replies broadcast
in nature.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090212/29bd8bb7/attachment.bin>