RE: [dhcwg] dhcpv6-24: Temporary addresses

["Bound, Jim" <[e-mail]>]

this sounds good to me.
/jim

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



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:[e-mail]] 
Sent: Wednesday, May 15, 2002 1:11 PM 
To: [e-mail] 
Subject: Re: [dhcwg] dhcpv6-24: Temporary addresses 


At 11:11 AM 5/8/2002 -0400, Thomas Narten wrote: 
> >    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) 

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 
>[e-mail] 
> https://www1.ietf.org/mailman/listinfo/dhcwg 


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