Options handling for Unicast packets in RENEW State

[rajeevalochan.ramaswamy at wipro.com]

Hi David,

Thanks for the reply.

I appreciate your explanation about the need for option82 tag in RENEW
state even though I don't fully accept it ;)

I will be waiting for the new releases of ISC DHCP server which will
work with our devices. Meanwhile we will look into changing our software
to work with the older releases too.

Regards,
Rajeev

-----Original Message-----
From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On
Behalf Of David W. Hankins
Sent: Tuesday, March 27, 2007 9:07 PM
To: dhcp-users at isc.org
Subject: Re: Options handling for Unicast packets in RENEW State

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



The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
 
www.wipro.com