Options handling for Unicast packets in RENEW State
rajeevalochan.ramaswamy at wipro.com
rajeevalochan.ramaswamy at wipro.com
Tue Mar 27 04:56:15 UTC 2007
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.
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)
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 12:40 AM
To: dhcp-users at isc.org
Subject: Re: Options handling for Unicast packets in RENEW State
On Mon, Mar 26, 2007 at 12:39:37PM +0530, venkataramana.kaza at wipro.com
> 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
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
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
I would say it is also not preferred.
> The operations of DHCP relay and DHCP server is such cases is based on
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
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.
More information about the dhcp-users