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

Joe Quanaim <> Thu, 12 August 2004 12:52 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id IAA28858; Thu, 12 Aug 2004 08:52:48 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1BvExf-0007Io-BD; Thu, 12 Aug 2004 08:45:39 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1BvElE-0004dv-3z for; Thu, 12 Aug 2004 08:32:48 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id IAA27640 for <>; Thu, 12 Aug 2004 08:32:46 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1BvEq9-0002qE-II for; Thu, 12 Aug 2004 08:37:55 -0400
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id i7CCVpld019613; Thu, 12 Aug 2004 07:31:51 -0500 (CDT)
Received: from by (8.11.7+Sun/EMS-1.5 sol2) id i7CCVox23191; Thu, 12 Aug 2004 08:31:50 -0400 (EDT)
From: Joe Quanaim <>
To: Stig Venaas <>, "JINMEI Tatuya / ?$B?@L@C#:H" <>
Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
Date: Thu, 12 Aug 2004 08:31:01 -0400
User-Agent: KMail/1.5.4
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Content-Transfer-Encoding: 7bit
Cc:,, Bernie Volz <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit

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