RE: [dhcwg] dhcpv6-24: Temporary addresses

I don't have a problem in allowing IA_TAs to be in Renew/Rebind. It wasn't clear from our previous discussions on this subject whether we needed that capability or not.

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?

The changes should be fairly minor to accommodate this.

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.

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

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, May 08, 2002 11:12 AM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcpv6-24: Temporary addresses

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

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)

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.

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.

Thomas

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg