Re: [dhcwg] dhcpv6-24: movement detection and Confirm message
Thomas Narten <narten@us.ibm.com> Thu, 09 May 2002 13:45 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 JAA21271 for <dhcwg-archive@odin.ietf.org>; Thu, 9 May 2002 09:45:13 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA27022 for dhcwg-archive@odin.ietf.org; Thu, 9 May 2002 09:45:22 -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 JAA26873; Thu, 9 May 2002 09:43:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26853 for <dhcwg@optimus.ietf.org>; Thu, 9 May 2002 09:43:37 -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 JAA21166 for <dhcwg@ietf.org>; Thu, 9 May 2002 09:43:27 -0400 (EDT)
Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49DgF205830; Thu, 9 May 2002 09:42:15 -0400
Message-Id: <200205091342.g49DgF205830@cichlid.adsl.duke.edu>
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
cc: Ralph Droms <rdroms@cisco.com>, dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: movement detection and Confirm message
In-Reply-To: Message from "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> of "Thu, 09 May 2002 08:24:25 CDT." <66F66129A77AD411B76200508B65AC69B4D3D7@EAMBUNT705>
Date: Thu, 09 May 2002 09:42:14 -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
> - Client can send a Confirm to help in movement detection. It > shouldn't be required for the client to do this since it may have > other means of doing this. OK > - A server that does implement Confirm handles the message in three ways: > 1. If it has the binding for the client and the addresses are valid, >it can send a Reply with the success indication. This would be the >case if the client hasn't really moved. OK > 2. If it doesn't have a binding but in comparing the addresses >provided in the Confirm, the server can determine that the prefixes >for the addresses are NOT valid for the link, the server can Reply to >the client that the addresses are bad. I.e., with a NotOnLink. > 3. The server discards the Confirm since it can not verify that the >addresses are truely valid for the client. Hmm. If a client has moved to a completely new site, will servers in general respond "NotOnLink" or will they think "I don't know"? And if the latter, and they don't respond, won't the client retransmit and won't it take a while to time out? I would assume its important for Confirm to be quick. > (We could allow another Reply from the server that would indicate to > the client that the prefixes appear to be valid, but it can't > confirm the actual addresses. However, this isn't really necessary > since no response to the Confirm essentially means that and it could > give false information at times; that is why it would be best not to > have servers do this.) I agree its not necessary, so long as the semantics of the response make it clear the client can only assume it hasn't moved and needs to not change the state of its bindings in anyway (i.e., it should not restart the T1/T2 timers, for example) > - While I think servers SHOULD implement Confirm, they don't have >to. If they don't, they won't enhance movement detection but since >there are other mechanisms that can help with this, it is not >required. Hmm. If this message is OPTIONAL to implement, this needs to be made clear in the spec. I assumed it was mandatory. I think it should be mandatory. If it is not, there is little point in clients implementing it. I.e., it doesn't make sense for clients to implement basic features that servers aren't required to implement. This leads to bad interoperability. > - Confirm processing is much different than a Renew/Rebind. There is >much less work involved on the server - it is only verifying the >information. A Confirm can NOT be used to extend address >lifetimes/leases. IMHO, it should only be used to help the client >determine whether it moved. OK. Thanks, 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