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

Joe Quanaim <> Tue, 03 August 2004 13:39 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA08362; Tue, 3 Aug 2004 09:39:15 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1BrzSU-000801-6u; Tue, 03 Aug 2004 09:36:02 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1BrzRL-0007ty-TW for; Tue, 03 Aug 2004 09:34:52 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA08108 for <>; Tue, 3 Aug 2004 09:34:50 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1BrzUN-0001Xy-Ox for; Tue, 03 Aug 2004 09:38:03 -0400
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id i73DY6Fg007238; Tue, 3 Aug 2004 08:34:06 -0500 (CDT)
Received: from by (8.11.7+Sun/EMS-1.5 sol2) id i73DY5C19387; Tue, 3 Aug 2004 09:34:05 -0400 (EDT)
From: Joe Quanaim <>
To: JINMEI Tatuya / 神明達哉 <>,,
Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
Date: Tue, 03 Aug 2004 09:33:29 -0400
User-Agent: KMail/1.5.4
References: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: quoted-printable
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: quoted-printable

JINMEI Tatuya / 神明達哉 wrote:
> 2. the usage of the lifetime option for other exchanges than
>    Info-req/Reply exchanges.
>    I'm even not 100% sure if the lifetime can be used for the other
>    types of exchanges.  Probably it can according to the draft, but
>    then I'll have several questions on how to use it.
>    For example, the draft says:
>      Before making the request it MUST wait for a random amount of time
>      between 0 and INF_MAX_DELAY.  INF_MAX_DELAY is defined in [RFC 3315].
>   Is this also applies to the other cases even if INF_MAX_DELAY is a
>   dedicated parameter for Info-req?  If so, is it really valid?

Isn't this duplicating rfc 3315?  Removing it would prevent any subsequent 
updates to rfc 3315 from conflicing with this statement.

>   Also, how does the client exactly react to the expiration event for
>   the other cases?  For example, consider the following scenario:
>   - the client performs Solicit->Advertise->Request->Reply exchanges,
>     and gets an IPv6 address allocated, a DNS server address X, and an
>     associated lifetime T.
>   - before the timeout "T1" for the allocated address passes, lifetime
>     T expires.  In this case, should the client restart the entire
>     session from Solicit?  Or should the client send a renew message?
>     If so, the renew message also tries to update the allocated
>     address even if it's too early?  Or should the client even start
>     Information-request/Reply exchanges just to update the DNS address
>     information?

Using this option in a stateful transaction makes things more complicated.  
The lifetime option can expire between t1, t2, or the valid lifetime of an 
address.  As Jinmei Tatuya notes, what should the client be expected to do?  
Restart the message exchange; just do an information-request; etc.

Any negotiated value for t1, t2, or valid lifetime of an address could take 
precedence over the lifetime option.  This essentially makes the option 
stateless only, but it simplifies the resulting changes to a client 

Joe Quanaim.

dhcwg mailing list