Re: FW: [dhcwg] co-existence of temp and normal addresses

Thomas Narten <> Mon, 08 April 2002 18:37 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id OAA02176 for <>; Mon, 8 Apr 2002 14:37:06 -0400 (EDT)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id OAA28712 for; Mon, 8 Apr 2002 14:37:09 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id NAA24995; Mon, 8 Apr 2002 13:53:58 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id NAA24973 for <>; Mon, 8 Apr 2002 13:53:56 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id NAA01166 for <>; Mon, 8 Apr 2002 13:53:53 -0400 (EDT)
Received: from (narten@localhost) by (8.11.6/8.11.6) with ESMTP id g38E7vq05345; Mon, 8 Apr 2002 07:07:57 -0700
Message-Id: <>
To: "Bernie Volz (EUD)" <>
Subject: Re: FW: [dhcwg] co-existence of temp and normal addresses
In-Reply-To: Message from "Bernie Volz (EUD)" <> of "Sun, 07 Apr 2002 22:35:58 CDT." <66F66129A77AD411B76200508B65AC69B4D1CA@EAMBUNT705>
Date: Mon, 08 Apr 2002 07:07:57 -0700
From: Thomas Narten <>
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

> Though I hate to do it because it reopens the discussions, if we
> consider anything we shouldn't add more IA types. Instead, we should
> redesign the IA option slightly and add a type field. The type field
> (8 bit?) could have the following values:
> 	0	-	"Normal" addresses
> 	1	-	"Temporary" addresses

I think these two may make sense. The reason is that temporary
addresses are different than other addresses in *how* the client uses
them. A client may want to use several at a time, or just one. It may
want to extend the lease of one particular one (if the application
continues to use it), etc.  That is, temporary addresses really do
have the potential for being used in application-specific manners. As
an example (not that I necessarily agree with it), when temporary
addresses were designed in the IPNg WG, there were some people that
thought it should be possible to have a new address created whenever a
new application started. Allowing the client to ask for "yet another
new temporary address" (as opposed to "give me the temporary addresses
I'm supposed to have")) would support this.

> 	2	-	"DSTM" addresses (this replaces the DSTM option)
> 	...

I can see the benfit here. Having a type makes sense in cases where
identifying the type of address (i.e, how it will be used) is
necessary to decide how to allocate and use it.


dhcwg mailing list