[dhcwg] dhcpv6-24: Temporary addresses

[Ralph Droms <[e-mail]>]

Narten:

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

Response:

Removed restriction on extension of lifetimes on temporary addresses.
Added text pointing to RFC 3041 for guidance in extending lifetimes on
temporary addresses and when to request additional temporary
addresses. 

*** dhcpv6.tty	Thu May 16 09:26:56 2002
--- dhcpv6-24.txt	Tue Apr 23 15:35:14 2002
***************
*** 3944,3980 ****
     its own.  When the lifetimes of all of the addresses in an IA have
     expired, the IA can be considered as having expired.
  
!    An IA_TA option does not include values for T1 and T2.  A client
!    MAY request that the lifetimes on temporary addresses be extended
!    by including the addresses in a IA_TA option sent in a Renew or
!    Rebind message to a server.  For example, a client would request
!    an extension on the lifetime of a temporary address to allow an
!    application to continue to use an established TCP connection.
! 
!    The client obtains new temporary addresses by sending an IA_TA option
!    with a new IAID to a server.  Requesting new temporary addresses from
!    the server is the equivalent of generating new temporary addresses
!    as described in RFC 3041.  The server will generate new temporary
!    addresses and return them to the client.  The client should request
!    new temporary addresses before the lifetimes on the previously
!    assigned addresses expire.
  
  
  
  
- Droms (ed.), et al.            Expires 22 Oct 2002             [Page 61]
- 
- Internet Draft              DHCP for IPv6 (-24)              22 Apr 2002
  
  
-    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.
  
!    This option MAY appear in a Confirm message if the lifetimes on the
!    temporary addresses in the associated IA have not expired.
  
  
  22.6. IA Address option
--- 4005,4031 ----
     its own.  When the lifetimes of all of the addresses in an IA have
     expired, the IA can be considered as having expired.
  
!    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.
! 
!    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.
  
  
  
  
  
  
  
! 
! Droms (ed.), et al.            Expires 22 Oct 2002             [Page 62]
! 
! Internet Draft              DHCP for IPv6 (-24)              22 Apr 2002
  
  
  22.6. IA Address option

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