RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt

["Bernie Volz" <[e-mail]>]

If a server sets the T1/T2 times to infinity, it gets what it asked for -
the configuration is static FOREVER. This is one reason it would be an
extremely bad idea to ever use these values. We added them for clarity in
the RFC, though never really figured they would be used in practice.

The no address issue is an interested one.

On a SOLICIT, the server is ONLY to return the Status Message response with
NoAddrAvail status. It is *NOT* supposed to return any configuration
information!!!

Though it is always possible that a subsequent REQUEST or RENEW/REBIND would
result in no addresses. However, in those cases the IA_NA is still returned
with T1 and T2 times and those would, IMHO, apply. (In these cases, the
NoAddrAvail status is embedded *INSIDE* the IA_* options so these options
are still returned.)

I suppose there is the case when a SOLICIT/REQUEST/RENEW/REBIND for an IA_NA
and IA_TA results in no addresses for a IA_NA and one or more addresses for
a IA_TA, in which case no T1/T2 times are provided - thought the IA_TA does
have lifetimes.

But, all of this gets very messy fairly quickly.

So, perhaps the easiest thing to do is to *ALWAYS* allow the LIFETIME option
- for stateful and stateless. A client *SHOULD* renew (etc) its information
whenver the shortest time expires - LIFETIME, T1, or lifetime on an address
(and the client needs a replacement address). If the client is stateful, is
uses RENEW (whether the client includes on or more IA_NAs if no T1 time has
expired is a matter of local policy - though it would seem reasonable for me
if it did since there's no harm in doing so). If a client is stateless, it
uses INFORMATION-REQUEST.

This also makes server implementations easier since the T1/T2 times and
"other-configuration-parameters" lifetime can be configured independently
and a server need not assure that no T1 time is greater than
"other-configuration-parameters".

- Bernie

> -----Original Message-----
> From: Joe Quanaim [mailto:[e-mail]] 
> Sent: Thursday, August 12, 2004 8:31 AM
> To: Stig Venaas; JINMEI Tatuya / ?$B?@L@C#:H
> Cc: [e-mail]; [e-mail]; Bernie Volz
> Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
> 
> 
> Stig Venaas wrote:
> > On Wed, Aug 11, 2004 at 11:12:16PM +0900, JINMEI Tatuya / 
> ?$B?@L@C#:H 
> > wrote:
> > > >>>>> On Tue, 3 Aug 2004 13:20:22 -0400,
> > > >>>>> "Bernie Volz" <[e-mail]> said:
> > > >
> > > > I too would recommend that this option only be used 
> with stateless 
> > > > (Information-Request/Reply). It does not apply to stateful - in 
> > > > stateful, even if there are no T1/T2 times (i.e., no IA_NA 
> > > > option), the client will need to do something when it no longer 
> > > > has addresses so it will get new information from the server.
> >
> > I think stateless only might be too strict.
> >
> > One example I have in mind is:
> >
> > If a client sends a request message to obtain addresses and other 
> > config options and it does not get any addresses but receives other 
> > config data. Then the client may use those options and not make a 
> > Request/Information-Request, right? You say client needs to do 
> > something when it no longer has addresses, but if you have IPv4 
> > addresses, and the only IPv6 DHCP server says it has no addresses, 
> > then I think it's ok for the client to just use what it got without 
> > switching to stateless mode, and at some later point make a new 
> > Request, still not using stateless mode.
> 
> I am not sure that the lifetime option is necessary when 
> using stateful.  I 
> would consider this example stateless because the client has 
> not successfully 
> negotiated any (IPv6) addresses.  Here I think you are right, 
> though, a 
> client should use the lifetime option.  If it has any 
> addresses, I think it 
> should ignore the lifetime option.
> 
> > How about saying this instead?:
> >
> >    The lifetime option is mainly intended for Stateless 
> DHCP service as
> >    specified in RFC 3736.  If the client receives IA Address options
> >    containing lifetimes, the lifetime option should be ignored.  The
> >    client should get updated configuration data from the 
> server when it
> >    renews the addresses.
> >
> > Another thing I'm wondering about is if T1, T2 are zero or 
> infinity. I 
> > think the lifetime option might make sense then. In 3315 it says:
> >
> >    If T1 or T2 is set to 0 by the server (for an IA_NA) or 
> there are no
> >    T1 or T2 times (for an IA_TA), the client may send a 
> Renew or Rebind
> >    message, respectively, at the client's discretion.
> >
> > If you get e.g. 0, it might be good to have some sort of 
> lifetime for 
> > the other data, and I guess you might then do renew/rebind when the 
> > lifetime expires.
> >
> 
> Even if T1 and T2 are zero or infinity, you have the lifetime 
> of the address 
> to fall back on.  RFC 3315 says:
> 
>    Note that an IA_NA has no explicit "lifetime" or "lease length" of
>    its own.  When the valid lifetimes of all of the addresses in an
>    IA_NA have expired, the IA_NA can be considered as having expired.
> 
> And says something similar for IA_TA's.  There is still an 
> issue when the 
> lifetime of the address is set to infinity, but this seems 
> like a special 
> case and one that might be used intentionally for one time 
> configuration.
> 
> Joe Quanaim.
> 


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