Re: [dhcwg] dhcpv6-24: movement detection and Confirm message

Thomas Narten <narten@us.ibm.com> Thu, 09 May 2002 12:47 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 IAA18118 for <dhcwg-archive@odin.ietf.org>; Thu, 9 May 2002 08:47:32 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA23142 for dhcwg-archive@odin.ietf.org; Thu, 9 May 2002 08:47:40 -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 IAA22712; Thu, 9 May 2002 08:43:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22683 for <dhcwg@optimus.ietf.org>; Thu, 9 May 2002 08:43:30 -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 IAA17950 for <dhcwg@ietf.org>; Thu, 9 May 2002 08:43:19 -0400 (EDT)
Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49Cg9105424; Thu, 9 May 2002 08:42:09 -0400
Message-Id: <200205091242.g49Cg9105424@cichlid.adsl.duke.edu>
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
cc: 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 "Wed, 08 May 2002 11:15:52 CDT." <66F66129A77AD411B76200508B65AC69B4D3BF@EAMBUNT705>
Date: Thu, 09 May 2002 08:42:09 -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

> It is just one of the ways a client could determine whether it
> moved; it really isn't a requirement to have within the DHCP
> specification.

Right.

> Do note however that since RAs don't have a unique link ID (yet?)
> and a RA might contain no prefixes (just have the "M" flag set), and
> in this case Confirm could be useful.

I think that future work might better handle this.

One approach might be to leave the Confirm stuff in for now, and if
better or more general ways of detecting movement are defined, drop
the config stuff in a revision. On the other hand, once its in the
spec, servers will have to implement it forever, so taking it out only
effects clients...

Thomas

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg