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