IETF Logo Mail Archive

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

Thomas Narten <narten@us.ibm.com> Thu, 09 May 2002 12:50 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 IAA18253 for <dhcwg-archive@odin.ietf.org>; Thu, 9 May 2002 08:50:44 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA23315 for dhcwg-archive@odin.ietf.org; Thu, 9 May 2002 08:50:52 -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 IAA23104; Thu, 9 May 2002 08:47:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23082 for <dhcwg@optimus.ietf.org>; Thu, 9 May 2002 08:47:14 -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 IAA18082 for <dhcwg@ietf.org>; Thu, 9 May 2002 08:47:05 -0400 (EDT)
Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49ChUH05436; Thu, 9 May 2002 08:43:30 -0400
Message-Id: <200205091243.g49ChUH05436@cichlid.adsl.duke.edu>
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
cc: 'Ted Lemon' <Ted.Lemon@nominum.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 "Wed, 08 May 2002 16:43:20 CDT." <66F66129A77AD411B76200508B65AC69B4D3CE@EAMBUNT705>
Date: Thu, 09 May 2002 08:43:30 -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

> I didn't find anything in the Stateless Autoconfiguration RFC that
> covers this case, but it would seem to me that if a client has
> determined (through RAs?) that it is on a new link, it would want to
> reset the ManagedFlag & OtherConfigFlag based on the RAs received on
> that new link. Hence, a Confirm might not even make sense if that
> new link is using Stateless since there will be no DHCP servers to
> respond (and if it followed the specification as we currently have
> it written, it would use the old configuration information).

This isn't covered very well in the existing ND specs. But the general
topic has received a lot of attention in the Mobile IP space. For
obvious reasons, they are very interested in detecting movements
quickly.

Thomas

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

v2.23.0 | Report a Bug | By Email