Subject: RE: [dhcwg] dhcpv6-24: Temporary addresses

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 9 May 2002 08:52:35 -0500

>> >    A server MUST return the same set of temporary address for the same
>> >    IA_TA (as identified by the IAID) as long as those addresses are
>> >    still valid.  After the lifetimes of the addresses in an IA_TA have
>> >    expired, the IAID may be reused to identify a new IA_TA with new
>> >    temporary addresses.
>
>> was in reference to a Request. We wanted to be clear on what happens
>> should a server receive a Request with the same IAID in a IA_TA
>> option that it already sent a Reply to.
>
>OK. This makes sense. This would be the same for temp and non-temp
>addresses. Right? Is the same text present in the non-temp case (I
>don't recall right off)?

Yes, it really should be the same and I think it is implied in other statements relating to addresses in an IA (that can not be removed until the valid lifetime has expired).

We do say (for the IA option): "When the lifetimes of all of the addresses in an IA have expired, the IA can be considered as having expired."

The one issue with Temporary Addresses is that a server implementor could assume "hey, they're temporary and assigned once and ..." so why save the binding information (they have to flag the address as in use until the valid lifetime expires, but that doesn't mean they'd have to remember which client was using it and for which binding). So, it was important to indicate that the server must remember this because of retransmissions (and now renewals since that wasn't in -24).

>No, I think "valid" is right. 

Agreed.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Thursday, May 09, 2002 9:32 AM
To: Bernie Volz (EUD)
Cc: [email-masked]
Subject: Re: [dhcwg] dhcpv6-24: Temporary addresses 

> One question is whether to modify the IA_TA option to be basically
> the same format as the IA option and include T1/T2 times. I would
> say NO. Instead, for IA_TAs, it is up to the client to initiate a
> Renew (and eventually Rebind) should it want to extend the
> lifetimes. Normally, the lifetimes are not extended (unless the
> client needs to do so). I think this matches the RFC 3041 behavior?

I think we could do it either way. I think it is fine for the client
to decide (if it wants to) whether (ever) to renew a temporary address.

> More text on when to get a new set of temp addresses also makes
> sense (as you proposed). A new set of temp addresses will require a
> new IA_TA IAID.

That is what I understand.

> The following text:

> >    A server MUST return the same set of temporary address for the same
> >    IA_TA (as identified by the IAID) as long as those addresses are
> >    still valid.  After the lifetimes of the addresses in an IA_TA have
> >    expired, the IAID may be reused to identify a new IA_TA with new
> >    temporary addresses.

> was in reference to a Request. We wanted to be clear on what happens
> should a server receive a Request with the same IAID in a IA_TA
> option that it already sent a Reply to.

OK. This makes sense. This would be the same for temp and non-temp
addresses. Right? Is the same text present in the non-temp case (I
don't recall right off)?

> This could happen, for
> example, because of retransmissions or if the client "crashes"
> before receiving the initial Reply and reuses the same IAID when
> booting perhaps several hours later. Anyway, the point was that in a
> Request, if the IA_TA IAID is the for an existing binding, the
> server should return that existing binding if the lifetimes are
> still reasonable. We might think about whether we should change "are
> still valid" to "are still preferred"?

No, I think "valid" is right. If the address is valid, it is still
assigned the client, and it would be incorrect for the server to
return a different address (in general).

Thomas

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 15 May 2002 12:24:38 -0500

Ralph:

I think all we wanted to do was to remove the prohibition against renewing IA_TA's. I don't think we want to drop the IA_TA concept or need to add T1/T2 times to the IA_TA option since the intent is NOT to renew these. If the client needs to continue using existing temporary addresses, it must initiate a Renew in time to renew them. The server can always have policy that would disallow this (for example if a renumbering event is happening).

And, adding some comments that in a managed (stateful) addressing environment the RFC 3041 procedures basically trigger stateful requests for temporary addresses in place of the stateless autoconfiguration would be useful.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Wednesday, May 15, 2002 1:11 PM
To: [email-masked]
Subject: Re: [dhcwg] dhcpv6-24: Temporary addresses

At 11:11 AM 5/8/2002 -0400, Thomas Narten wrote:
>I don't think the above is what we want. A Client should be able to
>renew/extend lifetimes for temp addresses *if* they want. But in
>general, they won't. (Note this is also allowed in 3041 in the sense
>that this is left open as a possibility -- I don't see a need for DHC
>to preclude this from being done)

OK (but see below).

>Ralph asked:
>
> > The basic question is "can a client ask and a server agree to extend
> > the lifetimes on temp addresses".  If lifetimes on temp addresses can
> > be extended, how are they different from non-temp addresses?  Good
> > question to discuss in WG.
>
>They are different in that applications can specifically request that
>temp addresses be used for communication, *or* that temp addresses NOT
>be used. Thus, there has to be a way to distinguish between temp and
>non-temp addresses. Also, I believe that a node might be using several
>sets of temp addresses simultaneously. Normally, that would mean one
>set that is "preferred", but there could be a number of others that
>are "deprecated", meaning not to be used for new communication, but
>still available to the applications that are already using them. If an
>application is still using a temp address, it may need to extend the
>valid Lifetime to prevent the address from going away.

I agree that the protocol software needs to identify temporary addresses so 
that applications can select for or against them.  But, how does DHCP 
handle temporary and non-temp addresses differently?  Is is just a tag that 
the server supplies and the protocol software interprets to identify 
temporary addresses or are there other differences?

>This also raises a different point. There should be more text about
>when to get a new set of temp addresses. I.e., one could point to 3041
>for guidance on when to get a new one and use similar rules. I.e.,
>unlike permanent addresses, the normal action when a temporary address
>becomes deprecated is to request a new (i.e., different) one. The old
>one still remains for a while, but is being phased out. In contrast,
>for public/global addresses, the normal action is to renew the *same*
>address and extend its preferred lifetime.
>
> >    An identity association for temporary addresses option MUST NOT
> >    appear in a Renew or Rebind message.  This option MAY appear in a
> >    Confirm message if the lifetimes on the temporary addresses in the
> >    associated IA have not expired.
>
>If the client wants to extend a binding (perhaps an application is
>still using that address) it should not be prohibited by the
>protocol from  doing so.

OK - we can reference RFC3041 for that guidance...

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

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

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 15 May 2002 15:33:00 -0400

this sounds good to me.
/jim

-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Wednesday, May 15, 2002 1:25 PM
To: 'Ralph Droms'; [email-masked]
Subject: RE: [dhcwg] dhcpv6-24: Temporary addresses

Ralph: 

- Bernie 

-----Original Message----- 
From: Ralph Droms [ mailto:[email-masked]] 
Sent: Wednesday, May 15, 2002 1:11 PM 
To: [email-masked] 
Subject: Re: [dhcwg] dhcpv6-24: Temporary addresses 

OK (but see below).