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

Joe Quanaim <jdq@lucent.com> Thu, 12 August 2004 12:52 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28858; Thu, 12 Aug 2004 08:52:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvExf-0007Io-BD; Thu, 12 Aug 2004 08:45:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvElE-0004dv-3z for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 08:32:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27640 for <dhcwg@ietf.org>; Thu, 12 Aug 2004 08:32:46 -0400 (EDT)
Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvEq9-0002qE-II for dhcwg@ietf.org; Thu, 12 Aug 2004 08:37:55 -0400
Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7CCVpld019613; Thu, 12 Aug 2004 07:31:51 -0500 (CDT)
Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7CCVox23191; Thu, 12 Aug 2004 08:31:50 -0400 (EDT)
From: Joe Quanaim <jdq@lucent.com>
To: Stig Venaas <Stig.Venaas@uninett.no>, "JINMEI Tatuya / ?$B?@L@C#:H" <jinmei@isl.rdc.toshiba.co.jp>
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: <200408030929.31655.jdq@lucent.com> <y7v4qn9u5kv.wl@ocean.jinmei.org> <20040812093121.GB8177@sverresborg.uninett.no>
In-Reply-To: <20040812093121.GB8177@sverresborg.uninett.no>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200408120831.02326.jdq@lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Bernie Volz <volz@cisco.com>
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jdq@lucent.com
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
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" <volz@cisco.com> 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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg