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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 8 Apr 2002 09:23:37 -0500

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:[email-masked]]
Sent: Monday, April 08, 2002 10:08 AM
To: Bernie Volz (EUD)
Cc: [email-masked]; [email-masked]
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

---

From: Thomas Narten <[email-masked]>
Date: Tue, 09 Apr 2002 10:29:48 -0700

> 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.

Right.  In the specific cases of Temporary and "normal" addresses, I
think the client does know which it wants and needs to treat them
differently.

> However, it is not clear that this would be the case down the road
> depending on how "type" is defined.

Thinking a bit more on this, I don't think a separate type field is
needed in the IA itself. Just let the DHCP option number itself serve
that purpose. I.e., it's perfectly OK to assign different option
numbers for the temporary vs. normal address case. The actual format
of the options could be the same, if that is what makes sense.

> For example, one might ask
> whether we should split the "normal" case in two and have
> "normal-global" and "normal-site".

I would argue no, for the reason that the client shouldn't be
distinguishing these cases. I.e, the client just gets a set of
addresses (0, 1, 2 or  more globals, 0 or more site-locals) and
assigns them to the interface. The client shouldn't care about how
many or what type. It just uses the ones assigned to it.

So I think we are in agreement that generalizing this is a potentially
troubling direction.

However, in the specific case of temporary address vs. non-temporary,
the client may well have more specific knowledge about how they are
used (e.g., the client may want to switch to a new temporary address
more frequently than another client, so this should be under client
control).

Thomas

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg