Options handling for Unicast packets in RENEW State

[David W. Hankins]

On Mon, Mar 26, 2007 at 12:39:37PM +0530, venkataramana.kaza at wipro.com wrote:
> Regarding giaddr not being set, the requirement of the DHCP option82
> feature in Relay Agent operating at Layer 2 was not to set the giaddr
> field in the DHCP packets.

That's correct, and the existing code is rather presumtive in assuming
that in l2 relay agent cases, there would always be a l3 relay involved
inbetween (that the l2 relay and server are never on the same broadcast
domain).

Inserting option 82 in packets that are unicast from the client to
the server (rather than broadcast) is also fairly invasive and would
not appear to have a great deal of benefit since the client is
normally reachable via direct unicast (so the problems solved by
the relay agent option are no longer present).

> We are not sure why ISC DHCP server need to take decision of echoing
> DHCP option82 tag based on giaddr field.

Well, it doesn't "need" to, that's just what the original author
selected.

Since I'm not the original author, I also can't be sure why.  But I
think that l2 relay agents were not common at that time, and that
the author was trying as hard as he reasonably could to ensure that
option 82 would never be sent directly to a client (since it can
extend the packet beyond the client's MTU, and there are problems
with many clients receiving packets larger than their MTU...but
relays (identified by giaddr) can often receive large packets).

> Our Relay Agent does not set giaddr field even in INIT state, but
> proper replies are received in that case. 

RFC2131 relay agent "chaining" allows at most one giaddr to be set, and
at most one option 82 to be appended to the DHCP packet.

So at INIT, it is your l3 relay agent that is reaching the DHCP server,
it sets giaddr and leaves the option 82 supplied from l2 alone.

> It looks like, DHCP server does not echo option82 tag only in the case
> when unicast packets are sent to the client.

Which are in response to unicast requests.

> Secondly, according to the standards, RFC 3046 and TR-101, it is not
> mandatory to add DHCP option82 tag by relay agent in DHCP client RENEW
> state.

I would say it is also not preferred.

> The operations of DHCP relay and DHCP server is such cases is based on
> implementation.

I suppose all behaviour is ultimately dependent upon implementation,
but in this case it is RFC2131 specified behaviour (a normal unicast
renewal between client and server with no relay agent involved).

> In our Relay Agent, since the DHCP option82 feature is only for
> adding/removing DHCP option82 field, it always expects option82 tag to
> be present in all DHCP downstream packets.

I think that RFC3046 describes some situations where the server
(operating correctly) would not reply with option 82, and so this
is possibly not the best choice.

It would be good to have some "fall back behaviour" when option 82
is not present that still gets the server's packet delivered to
the client, if not in the general case then at least in the
unicast case.

> To substantiate the same, TR-101 also states that DHCP server must
> always echo back the option82 tag.

RFC3046 is our reference, we implement IETF standards, not DSL Forum
standards.

-- 
ISC Training!  http://www.isc.org/training/  training at isc.org
Washington DC area, April 16-20 2007.  DNS & BIND, DDNS & DHCP.
-- 
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