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

JINMEI Tatuya / 神明達哉 <> Mon, 16 August 2004 12:31 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id IAA00445; Mon, 16 Aug 2004 08:31:13 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1Bwgbc-00074C-T2; Mon, 16 Aug 2004 08:28:52 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1BwgPG-0005s1-Qp for; Mon, 16 Aug 2004 08:16:07 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id IAA29746 for <>; Mon, 16 Aug 2004 08:16:05 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1BwgV3-0000Ew-1Z for; Mon, 16 Aug 2004 08:22:06 -0400
Received: from (unknown [3ffe:501:100f:1048:4164:cd3:c762:127d]) by (Postfix) with ESMTP id 4C30715263; Mon, 16 Aug 2004 21:15:57 +0900 (JST)
Date: Mon, 16 Aug 2004 21:15:54 +0900
Message-ID: <>
From: JINMEI Tatuya / 神明達哉 <>
To: Stig Venaas <>
Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
In-Reply-To: <>
References: <> <000201c4797e$2a5f37e0$> <> <>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc:,, Bernie Volz <>,
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

>>>>> On Thu, 12 Aug 2004 11:31:21 +0200, 
>>>>> Stig Venaas <> 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?

A quick response for clarification: if you mean the case where the
client receives an Advertise message containing a NoAddrsAvail status
code, I don't think the client may use other configuration options
(moreover, I don't think the client ever receives such configuration
options in this case).

RFC3315 is not so explicit in such a case, but it requires the client
just to ignore such an Advertise message:

   The client MUST ignore any Advertise message that includes a Status
   Code option containing the value NoAddrsAvail, with the exception
   that the client MAY display the associated status message to the
(Section 17.1.3)

and the server to send minimum information to indicate the error:

   If the server will not assign any addresses to any IAs in a
   subsequent Request from the client, the server MUST send an Advertise
   message to the client that includes only a Status Code option with
   code NoAddrsAvail and a status message for the user, a Server
   Identifier option with the server's DUID, and a Client Identifier
   option with the client's DUID.
(Section 17.2.2)

Again, this is just for clarification, and may be irrelevant to the
main point of this discussion.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.

dhcwg mailing list