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

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

T1/T2 can simply be set to 0 or FFFFFFFF (T1/T2 are supposed to be set by the server in all cases, so using either of these values could easily mean no renewal or don't renew until 2^32-1 seconds have elapsed). No need for another option. Saving the 8 bytes for these two fields isn't worth it, IMHO. 
 
- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:[email-masked]]
Sent: Monday, April 08, 2002 9:17 AM
To: 'Bernie Volz (EUD)'; 'Thomas Narten'
Cc: [email-masked]
Subject: RE: FW: [dhcwg] co-existence of temp and normal addresses 

This idea is ok.
But, we need two types of IA options : Renwable IA and Non-Renewable IA,
because, T1 and T2 fields doesn't make sense, if IA contain temporary 
addresses.
 
~vijay

-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Monday, April 08, 2002 9:06 AM
To: 'Thomas Narten'; [email-masked]
Cc: [email-masked]
Subject: RE: FW: [dhcwg] co-existence of temp and normal addresses 

Thomas/Vijay: 

We did discuss this for a long time in designing the current DHCPv6 draft. 

It really would have been useful if the IPv6 community has a means to classify the 'type' of an address. This would be useful for applications when they want to "find" a specific address.

Anyway, if we had such a thing, we would have revised the IA Option to carry it. 

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 
        2       -       "DSTM" addresses (this replaces the DSTM option) 
        ... 

- Bernie 

-----Original Message----- 
From: Thomas Narten [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Sunday, April 07, 2002 10:40 PM 
To: [email-masked] 
Cc: [email-masked] 
Subject: Re: FW: [dhcwg] co-existence of temp and normal addresses 

Hi Vijay. 

I agree that you've raised a valid issue. 

> - Why can't we have separate IAs for normal and temporary addresses? 

Mixing temporary and non-temporary addresses in the same IA seems like 
it may create some problems. I suspect that NOT mixing them together 
within the same IA will simplify some things. I'll have to think a bit 
more about the rest of your proposal. 

Thomas 

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

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 9 Apr 2002 22:01:53 -0500

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:[email-masked]]
Sent: Tuesday, April 09, 2002 1:30 PM
To: Bernie Volz (EUD)
Cc: [email-masked]; [email-masked]
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