Re: [dhcwg] dhcpv6-24: Temporary addresses
Thomas Narten <narten@us.ibm.com> Thu, 09 May 2002 13:37 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20933 for <dhcwg-archive@odin.ietf.org>; Thu, 9 May 2002 09:37:51 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26693 for dhcwg-archive@odin.ietf.org; Thu, 9 May 2002 09:38:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26305; Thu, 9 May 2002 09:33:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26236 for <dhcwg@optimus.ietf.org>; Thu, 9 May 2002 09:33:05 -0400 (EDT)
Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20585 for <dhcwg@ietf.org>; Thu, 9 May 2002 09:32:55 -0400 (EDT)
Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49DVjX05718; Thu, 9 May 2002 09:31:45 -0400
Message-Id: <200205091331.g49DVjX05718@cichlid.adsl.duke.edu>
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
cc: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: Temporary addresses
In-Reply-To: Message from "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> of "Wed, 08 May 2002 13:19:34 CDT." <66F66129A77AD411B76200508B65AC69B4D3C4@EAMBUNT705>
Date: Thu, 09 May 2002 09:31:45 -0400
From: Thomas Narten <narten@us.ibm.com>
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
> 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). Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- Re: [dhcwg] Changes to remove "client-link-local-… Josh Littlefield
- RE: [dhcwg] Changes to remove "client-link-local-… Ralph Droms
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- Re: [dhcwg] Changes to remove "client-link-local-… Ralph Droms
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- Re: [dhcwg] Changes to remove "client-link-local-… Ted Lemon
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- Re: [dhcwg] Changes to remove "client-link-local-… Josh Littlefield
- Re: [dhcwg] Changes to remove "client-link-local-… Ted Lemon
- Re: [dhcwg] Changes to remove "client-link-local-… Ralph Droms
- Re: [dhcwg] client unicast/client unicast option Ted Lemon
- Re: [dhcwg] Incorporation of WG last call comment… Ted Lemon
- Re: [dhcwg] Assigning DHCPv6 option codes Thomas Narten
- Re: FW: [dhcwg] co-existence of temp and normal a… Thomas Narten
- Re: FW: [dhcwg] co-existence of temp and normal a… Thomas Narten
- Re: [dhcwg] dhcpv6-24: Rapid Commit Thomas Narten
- Re: [dhcwg] dhcpv6-24: movement detection and Con… Thomas Narten
- Re: [dhcwg] dhcpv6-24: movement detection and Con… Thomas Narten
- Re: [dhcwg] dhcpv6-24: use of anycast Thomas Narten
- Re: [dhcwg] dhcpv6-24: Interface-ID option Thomas Narten
- Re: [dhcwg] dhcpv6-24: Temporary addresses Thomas Narten
- Re: [dhcwg] dhcpv6-24: movement detection and Con… Thomas Narten
- Re: [dhcwg] dhcpv6-24: movement detection and Con… Ted Lemon
- Re: [dhcwg] DHCP Option for CableLabs Client Conf… Thomas Narten
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Thomas Narten
- Re: [dhcwg] Conflicting information regarding DHC… Thomas Narten
- Re: [dhcwg] RE: I-D ACTION:draft-droms-dhcp-relay… Thomas Narten