Re: [dhcwg] dhcpv6-24: Temporary addresses

Thomas Narten <> Thu, 09 May 2002 13:37 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id JAA20933 for <>; Thu, 9 May 2002 09:37:51 -0400 (EDT)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id JAA26693 for; Thu, 9 May 2002 09:38:00 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id JAA26305; Thu, 9 May 2002 09:33:08 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id JAA26236 for <>; Thu, 9 May 2002 09:33:05 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA20585 for <>; Thu, 9 May 2002 09:32:55 -0400 (EDT)
Received: from (narten@localhost) by (8.11.6/8.11.6) with ESMTP id g49DVjX05718; Thu, 9 May 2002 09:31:45 -0400
Message-Id: <>
To: "Bernie Volz (EUD)" <>
Subject: Re: [dhcwg] dhcpv6-24: Temporary addresses
In-Reply-To: Message from "Bernie Volz (EUD)" <> of "Wed, 08 May 2002 13:19:34 CDT." <66F66129A77AD411B76200508B65AC69B4D3C4@EAMBUNT705>
Date: Thu, 09 May 2002 09:31:45 -0400
From: Thomas Narten <>
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

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

I think we could do it either way. I think it is fine for the client
to decide (if it wants to) whether (ever) to renew a temporary address.

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

That is what I understand.

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

OK. This makes sense. This would be the same for temp and non-temp
addresses. Right? Is the same text present in the non-temp case (I
don't recall right off)?

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

No, I think "valid" is right. If the address is valid, it is still
assigned the client, and it would be incorrect for the server to
return a different address (in general).


dhcwg mailing list