[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dhcwg] New draft for leasequery extension

Bharat Joshi wrote: 
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.



Why we added it like this is to make it compatible with DHCP header
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.


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

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?


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.

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.

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?



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

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) 
begin:vcard
fn:Andre Kostur
n:Kostur;Andre
org:Incognito Software Inc.;Engineering
adr:;;#500 - 375 Water Street;Vancouver;BC;V6B 5C6;Canada
email;internet:akostur at incognito.com
title:Senior Software Design Engineer
tel;work:604-678-2864
tel;fax:604-688-4339
url:http://www.incognito.com
version:2.1
end:vcard


_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg