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

[Stig Venaas <[e-mail]>]

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.

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

Actually, I think SHOULD might be appropriate. Are those the correct
message types?

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

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

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

> 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

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