Re: [dhcwg] New draft for leasequery extension

[Bharat Joshi <bharat_joshi at infosys.com>]

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

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

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

Ok. We can remove it.

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

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.

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

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



**************** 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
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg