Re: [dhcwg] New draft for leasequery extension

[Andre Kostur <akostur at incognito.com>]

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

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.

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