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

["Bernie Volz (EUD)" <[e-mail]>]

Thomas:

What I don't like about the separate option space is can the IA values then overlap between the various options or are they assigned from ONE number space. If it is one option, I think it is clearer that they are assigned from ONE number space (but perhaps that is just my way of thinking).

There is always the issue of what happens if an IA already exists (on the server) and now the client sends a message with that IA but uses a DIFFERENT type for that IA number.

As I write this, I see that if we had (1) a separate option and (2) a separate number space for the IAs within that option number, then we would avoid this issue since then there is no conflict. This kind of makes the IA a 48 bit value - 16-bits for the option and 32-bits for the IA value.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:[e-mail]]
Sent: Tuesday, April 09, 2002 1:30 PM
To: Bernie Volz (EUD)
Cc: [e-mail]; [e-mail]
Subject: Re: FW: [dhcwg] co-existence of temp and normal addresses 


> 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