RE: FW: [dhcwg] co-existence of temp and normal addresses
"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Mon, 08 April 2002 14:38 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25396 for <dhcwg-archive@odin.ietf.org>; Mon, 8 Apr 2002 10:38:30 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA10462 for dhcwg-archive@odin.ietf.org; Mon, 8 Apr 2002 10:38:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08840; Mon, 8 Apr 2002 10:23:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08760 for <dhcwg@ns.ietf.org>; Mon, 8 Apr 2002 10:23:39 -0400 (EDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24846 for <dhcwg@ietf.org>; Mon, 8 Apr 2002 10:23:36 -0400 (EDT)
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g38ENdl11646 for <dhcwg@ietf.org>; Mon, 8 Apr 2002 09:23:39 -0500 (CDT)
Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g38ENcp21787 for <dhcwg@ietf.org>; Mon, 8 Apr 2002 09:23:39 -0500 (CDT)
Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Apr 08 09:23:38 2002 -0500
Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <ZQBPKHF2>; Mon, 8 Apr 2002 09:23:38 -0500
Message-ID: <66F66129A77AD411B76200508B65AC69B4D1D4@EAMBUNT705>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: 'Thomas Narten' <narten@us.ibm.com>
Cc: vijayak@india.hp.com, dhcwg@ietf.org
Subject: RE: FW: [dhcwg] co-existence of temp and normal addresses
Date: Mon, 08 Apr 2002 09:23:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF08.F8D007C0"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
The only problem with this typing is that it presumes the client always knows what to ask for. In the cases we have today, that appears to be appropriate. However, it is not clear that this would be the case down the road depending on how "type" is defined. For example, one might ask whether we should split the "normal" case in two and have "normal-global" and "normal-site". Or, might we have three types - "normal", "normal-global", and "normal-site". Or, should we use bits to indicate what address types are desired/allowed for the particular IA (hence an IA could ask for normal-global, normal-site, DSTM, and/or temporary). Note that I do like the idea of the types since it could easily be extended to do prefix delegation, multicast address assignments, etc. However, we have to be careful in how the types are assigned to avoid the problems above. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Monday, April 08, 2002 10:08 AM To: Bernie Volz (EUD) Cc: vijayak@india.hp.com; dhcwg@ietf.org Subject: Re: FW: [dhcwg] co-existence of temp and normal addresses > 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. Thomas
- [dhcwg] co-existence of temp and normal addresses Vijay Bhaskar A K
- FW: [dhcwg] co-existence of temp and normal addre… Vijayabhaskar A K
- RE: FW: [dhcwg] co-existence of temp and normal a… Bernie Volz (EUD)
- RE: FW: [dhcwg] co-existence of temp and normal a… Vijayabhaskar A K
- RE: FW: [dhcwg] co-existence of temp and normal a… Bernie Volz (EUD)
- RE: FW: [dhcwg] co-existence of temp and normal a… Bernie Volz (EUD)
- RE: FW: [dhcwg] co-existence of temp and normal a… Bernie Volz (EUD)