Options handling for Unicast packets in RENEW State

[David W. Hankins]

On Tue, Mar 27, 2007 at 10:26:15AM +0530, rajeevalochan.ramaswamy at wipro.com wrote:
> I accept the point that, for unicast packets from client, option82 tag
> is not echoed back, so that client does not receive option82 tag. But in
> a DSL scenario, it might be necessary for the relay to add option82 (so
> that server can validate the client) and expect the option82 tag in the
> reply pacekts from server in order to find the corresponding interface
> where client is connected.

Forgive me for speaking my mind for a moment.  Network designs are
very much like philosphies...we all have our favorites and like to
judge others'.

I would be wary of a design wherein agent info contents "validated"
a client.  It might locate the client, and it might guide the dhcp
server towards particular configuration parameters, but without
some very contrived network designs or at least relay agent
authentication it's very hard to see this as enforcable
"authentication" policy, and very easy to imagine scenarios of abuse.

A server might need the agent info contents in order to make
configuration decisions, but this is something servers already
have to solve since many relays do not inject the option in
renewals: we just cache the option contents we got from INIT or
INIT-REBOOT, and remember them so long as the lease remains valid.

As for the DSL devices locating the client for the reply...the
server's reply in this case is a normal IP unicast directed at
the DHCP client's assigned IP address, which we imagine they have
been using inbetween INIT and RENEW ("BOUND").

This shouldn't be any different from any other IP traffic reaching
the client, so there shouldn't be a requirement for the agent
information option.

After all, you can't put agent information in HTTP or DNS packets.


So, hopefully you've forgiven me for 'judging' your philosphy, but
I'm unconvinced that relay agent options in unicasts are a good idea.


> Is there any possibility that ISC DHCP server can be modified in future
> to echo back the option82 tag or have a configurable option to do so, so
> that it can work with L2 relay agents to overcome this problem? (Not
> sure this is the right forum to post this query)

I said the other day that I learned of this issue that morning, what
I didn't say is this is because someone sent us a patch.

Since it does repair an error in our RFC3046 behaviour, it was pulled
up to our release branches on maintenance schedule (so it will appear
in 3.1.0b2, and the first releases of 3.0.6 if there is one).

Note that even though our current sources will reflect this change,
it is likely that it may take some years to replace older software,
so this interoperation issue will persist for some years.

-- 
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