DHCPINFORM

[David W. Hankins]

On Wed, Feb 04, 2009 at 09:29:51AM +0100, Marty Sørensen wrote:
> I have been reading the RFC on DHCPINFORM but cant find out if the
> DHCPserver has to reply with all options (special option-82) on DHCPINFORM -
> ACK ?

RFC 3046 is what directs servers to include the relay agent
information option;

   DHCP servers claiming to support the Relay Agent Information option
   SHALL echo the entire contents of the Relay Agent Information option
   in all replies.

In Discover/Request processing, we actually made a change not long
ago, because we would not include the relay agent information option
if we were not directing the reply to "a relay" (ex: giaddr is zeroed,
but a "l2 relay", having no IP address to set giaddr, was still
involved and sending relay agent options).

The change was to make it so the relay agent information option was
always included if the input packet included it, no other test was
used.

We didn't change DHCPINFORM at the same time because no one was
reporting a problem there.

But I have a question:  What exactly is being validated?

It sounds very suspicious to me that DHCPINFORM would be something
that would need any kind of validation.

> CIADDR: 89.x.x.155
> GIADDR: 89.x.x.252

What you are seeing here is the client broadcast its DHCPINFORM (very
common, everyday scenario, and described in RFC 2131).  The only
normative language on DHCPINFORM right now is that a server SHOULD
unicast its reply to ciaddr (RFC 2131).

Meaning, the common wisdom that DHCPINFORM is unicast client->server
is backwards; it is unicast server->client, and may be either unicast
or broadcast client->server.  Except where that's broken (see draft-
dhankins-dhcpinform-clarify).

So the server is getting the relayed DHCPINFORM, and is sending the
reply directly to CIADDR.  Is ciaddr a relay agent?  It is not.  So
the relay agent information option is not included.

This contradicts the above RFC 3046 language, but no one has ever
reported a problem with that behaviour.

-- 
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: 194 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090204/9f13e7c3/attachment.bin>