Re: [dhcwg] Comments on draft-venaas-dhc-lifetime-00.txt

[Vijayabhaskar A K <[e-mail]>]

Stig Venaas wrote:

>On Wed, Nov 19, 2003 at 09:53:24PM +0530, Vijayabhaskar A K wrote:
>  
>
>>> A client supporting this option SHOULD include it in the Option
>>> Request option when sending an Information-request message to the
>>> DHCP server.
>>>
>>>
>>>      
>>>
>>I guess, it is applicable for  Request also... Moreover, why do you want 
>>to make the client to send this option always in the ORO option.. The 
>>better way could be, Whenever the server provides non-address 
>>configuration, it MUST include Lifetime option in the reply" Opinions?
>>    
>>
>
>I'm pretty open on this point, not sure which is best.
>  
>
Including this option in the ORO somehow makes this option unrelated to 
non-address configuration.. But it is not so.... They are tied together 
and server should be able to send this option if any of the non-address 
conf are requested.. The key thing is, life time is part of the 
non-address conf

>  
>
>>I am thinking about a model, where there will be 2 lifetimes, preferred 
>>and valid..  Once the preferred life time expires, it should start 
>>unicasting the Information-request to renew the configure 
>>information.... By this way, it is possible to refresh the parameters 
>>even before it expire..  Once the valid life time expires, it should 
>>send a multicast Information-Request to All Relays mutlicast address... 
>>But, It should ignore the old configuration *only* after obtaining the 
>>configuration info from some other server....
>>    
>>
>
>I'm not sure this is necessary, would like to get more opinions on this.
>
>  
>
>>You need to add text about the retransmission mechanism also... Look at 
>>RFC 3315.. It has some timer values associated with Information-Request
>>
>>INF_MAX_DELAY     1 sec   Max delay of first Information-request
>> INF_TIMEOUT       1 sec   Initial Information-request timeout
>> INF_MAX_RT      120 secs  Max Information-request timeout value
>>    
>>
>
>Will do.
>
>  
>
>>Add text on client behavior and server behavior to explain it clearly....
>>
>>You need to add some thing like, "If the client has address 
>>configuration obtained from the server, the client MAY ignore this 
>>option and send renew along with the IAs"
>>    
>>
>
>Right. I can say that it's only used for options not having a specified
>lifetime of their own, and if client sends a request, renew, rebind or
>information-request message to the DHCP server before the lifetime has
>expired, it MAY update all this data as well.
>  
>
Sounds good..

>Actually, I think SHOULD might be appropriate. Are those the correct
>message types?
>  
>
yes, the intention here is, instead of mainitaining two seperate life 
times for address and non-address conf, the clients can include the 
renewal of these info whenever it gets a chance to contact the server.. 
you can even say. this life time can be ignored, till it have a 
configuration which has associated life time in it..

>  
>
>>you may need to explain what are all the possible values it can have? Is 
>>0 valid? Do you want to provide the permanent lease with 0xffffffff? Or 
>>do you want to make 0xffffffff reserved ? I guess, the server should be 
>>able to make the lifetime as 0, to make the client stop using the 
>>configuration and initiate the fresh Information-request/Reply to obtain 
>>    
>>
>
>But can't the server immediately offer the options, instead of setting
>it to 0 and have a new request?
>  
>
It may choose to stop serving this link and may want trigger the client 
to use some other dhcp server

>  
>
>>new configuration information.. 0xffffffff can be assumed as infinite 
>>lease and can be used in the network where the  configuration is stable 
>>and there wont be any change in it....
>>    
>>
>
>Maybe, but omitting the option or not supporting it should be the same,
>right?
>  
>
yes.. but, in dhcp terms 0xffffffff has a meaning of infinite lease.. Do 
you want to keep it?

>  
>
>>>4. IANA Considerations
>>>
>>> IANA is requested to assign an option-code for the lifetime option
>>> from the option-code space defined in [RFC 3315].
>>>
>>>
>>>      
>>>
>>The format should be something like....
>>
>>IANA is requested to assign an option code to the following options
>> from the option-code space defined in "DHCPv6 Options" section of the
>> DHCPv6 specification [1].
>>    
>>
>
>ok, will change this.
>
>  
>
>>No.. There are security constraints...Any intruder can frame a reply 
>>packet with a very less life time in the lifetime option and make the 
>>clients to intiate requests in very short intervals, making the network 
>>flooded and servers overloaded.... DHCP authentication as defined in RFC 
>>3315 should be used for authentication...
>>    
>>
>
>My thinking is that the current lifetime value is forgotten when it
>expires.  Then when you get new config info, you'll either have a
>correct value, or no value meaning infinite or unspecified (as it is
>when option isn't supported). Obviously something that needs to be
>spelled out in next version.
>
>  
>
certainly, you have somethings to be added in this section

>>You need to add a section where you should list the only messages in 
>>which this option can appear... Something like...
>>
>>8. Appearance of these options
>>                                                                          
>> The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name
>> options MUST NOT appear in other than the following messages: Solicit,
>> Advertise, Request, Renew, Rebind, Information-Request and Reply.
>>                                                                          
>> The option number for these options MAY appear in the Option Request
>> Option [1] in the following messages: Solicit, Request, Renew,
>> Rebind, Information-Request and Reconfigure.
>>    
>>
>
>Will do, thanks,
>
>Stig
>
>
>  
>


-- 
__________________________________________________________
Vijayabhaskar A K            Phone : [phone]
Hewlett Packard              Mobile: [phone]
29 Cunningham Road           Telnet: 847-3085
Bangalore 52                 Email : [e-mail]

Until you have the courage to lose sight of the shore,
you will not know the terror of being forever lost at sea.
 __________________________________________________________




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