[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