Re: [dhcwg] dhcpv6-24: Temporary addresses

Ralph Droms <> Wed, 15 May 2002 17:21 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id NAA14259 for <>; Wed, 15 May 2002 13:21:30 -0400 (EDT)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id NAA14224 for; Wed, 15 May 2002 13:21:44 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id NAA13612; Wed, 15 May 2002 13:11:30 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id NAA13594 for <>; Wed, 15 May 2002 13:11:28 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id NAA13769 for <>; Wed, 15 May 2002 13:11:14 -0400 (EDT)
Received: from ( []) by (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA01772 for <>; Wed, 15 May 2002 13:10:56 -0400 (EDT)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 15 May 2002 13:10:54 -0400
From: Ralph Droms <>
Subject: Re: [dhcwg] dhcpv6-24: Temporary addresses
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

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

>dhcwg mailing list

dhcwg mailing list