Subject: [dhcwg] New draft for leasequery extension

From: "pavan_kurapati" <[email-masked]>
Date: Sat, 5 Aug 2006 22:49:58 +0530

Hi,

We've incorporated review comments suggested during the WG meeting at Montreal and also from the discussions on the mailing list. A new draft is available for the same at

http://www.ietf.org/internet-drafts/draft-joshi-dhcp-lease-query-ext-01.txt

Please review the same and provide your comments/suggestions.

Thanks,
Pavan

Pavan Kumar Kurapati
Infosys Technologies Ltd,
Bangalore

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Andre Kostur <[email-masked]>
Date: Thu, 10 Aug 2006 12:17:07 -0700

> http://www.ietf.org/internet-drafts/draft-joshi-dhcp-lease-query-ext-01.txt

General Question:

I think this draft should mention that it would be preferable that the 
Access Concentrator be able to emit LeaseQueries on its own via some 
management IP address as this would place its behaviour completely under 
RFC 4388.

Section 4.1:

Should those MAYs be capital MAYs, or just simple "may"s?  This may be a 
style question, but it seems to imply to me that with a "MAY" it is a 
directive to Access Concentrator implementors to perform that 
behaviour.  As opposed to "may" which would imply to me that this is 
simply information of interest about what the Access Concentrator might 
be doing with this information.

Section 5.1:

I think the option is overspecified.  It should probably be:  Code + Len 
+ hwaddr.  Specifying the length of the hwaddr is unnecessary (can be 
inferred by the overall length of the option), and using a fixed-size 
hwaddr field will be wasting 10 bytes (in most cases) of the DHCP packet.

Section 5.2:

Point #2: That should be "Access concentrators which can receive a 
unicast reply...", or "Access concentrators which may receive unicast 
replies...".   And why MUST it be the last option?  Why would it be 
positionally dependent at all?

Also, does this also mean that DHCP servers MUST NOT send this option 
back to "normal" DHCP clients?  Because if it does, how will the Access 
Concentrator be able to distinguish between this option is the one that 
was reflected back to the AC, vs. this option is the data that is being 
returned as LeaseQuery data?

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 11 Aug 2006 10:39:37 +0530

Hi Andre,

   Please see my response in line.

Thanks,
Bharat

> management IP address as this would place its behaviour completely under 

Though as discussed during WG meeting, it may not be used at all but we
can add a note saying that if there is an option of using a management
address in Layer 2 Access Nodes [which can be used to communicate with
DHCP server and can receive packets from L3 Relay Agent] than that can
also be used for DHCP Leasequery messages.

> be doing with this information.

Yeah, we can change them to 'may'. It sounds more logical to use 'may'
instead of MAY here.

> hwaddr field will be wasting 10 bytes (in most cases) of the DHCP packet.

Why we added it like this is to make it compatible with DHCP header
which has these fields defined for a hardware address.

But we agree that it can use a variable length which can be used to
identify the hardware address length. So the option may look as follows:

code     len   [Hardware address details]
+------+------+------------+-------------+
|  X   |  Y   |  htype (1) | hwaddr (Z)  |
+------+------+------------+-------------+

Where Y = Z + 1

> positionally dependent at all?

This was added to make DHCP Server and L3 Relay Agent 's life a little
easier. It need not be position dependent and so we can replace this
"MUST" with "SHOULD" or "MAY" here.

> returned as LeaseQuery data?

Actually clients are not supposed to add this option at all. We can add
a statement saying that "L2 relay agent must treat all its subscriber
ports as untrusted entities. A DHCP packet coming from an untrusted
entity with access-concentrator-hw-addr added MUST be silently
discarded. If L2 relay agent is located farther to Access Node, access
node must not act as a relay agent for that line".

---

From: Andre Kostur <[email-masked]>
Date: Thu, 10 Aug 2006 23:01:12 -0700

> which has these fields defined for a hardware address.

That's because of the design decision where DHCP needed to be compatible 
with existing BOOTP implementations, where that header is already a 
fixed-length field.  So the header couldn't be re-specified.  We don't 
have the same design restrictions in defining options.

> code     len   [Hardware address details]

I don't think that should be specified at all.  It's merely an option 
within the packet.  No MUST, SHOULD, or MAY (or MAY NOT).  And it would 
make the DHCP Server's life harder, not easier.

> node must not act as a relay agent for that line". 

Client->Server isn't the issue.   It's Server->Client where the problem 
is initiated.  If the DHCP server is configured to send this option back 
to the client (and thus it becomes part of the lease data), then it 
would be inaccessable from a Leasequery point of view (much the same way 
as if in normal Leasequery, the querier were to add in option 82 in the 
query.  The DHCP server has to deal with the conflicting requirement of 
reflecting the option 82 back, as well as attempting to put in the 
option 82 that was originally sent by the client).

Thus, do we need to specify that this option MUST NOT be sent back to 
"normal" DHCP clients? Or, DHCP Servers MUST ignore the option if it is 
supplied in any DHCP message other than Leasequery, and the DHCP Server 
MUST reflect the option back to the querier exactly as it was received 
in Leasequery messages?  (Check RFC 3046 for how this reflection was 
worded for option 82)
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 11 Aug 2006 11:42:03 +0530

> have the same design restrictions in defining options.

Thats TRUE. So We shall change it as described below.

> make the DHCP Server's life harder, not easier.

Ok. We can remove it.

> option 82 that was originally sent by the client).

I am not sure if I got this correctly. Our document does not mention
that DHCP server should store this option and send this option back in
the DHCP replies of normal DHCP packets to a client.

> in Leasequery messages?  (Check RFC 3046 for how this reflection was 

We can add some text similar to the mentioned above to clarify it
explicitly.

The server should echo the entire option has already been added in
section 5.4.

Thanks,
~Bharat

---

From: Andre Kostur <[email-masked]>
Date: Fri, 11 Aug 2006 07:15:14 -0700

> the DHCP replies of normal DHCP packets to a client.

Upon a closer reading, the draft does seem to only mention Leasequery 
messages.  However, since this option does require special behaviour on 
the server (for at least one message), then I think it would be a good 
idea to mention any special behaviours (or even if there is no special 
behaviour) for the remaining messages that the server may receive.  
Otherwise we may end up leaving a loophole in the specification where 
some servers could do one thing with the option, and other servers do 
something different.

---

From: "pavan_kurapati" <[email-masked]>
Date: Fri, 11 Aug 2006 20:14:00 +0530

>some servers could do one thing with the option, and other servers do

Yes. We will take care of this  in the next version by explicitly mentioning about the Server behavior in non-leasequery messages for this option.

Thanks,
Pavan