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

Thomas Narten <narten@us.ibm.com> Wed, 08 May 2002 15:08 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 LAA11197 for <dhcwg-archive@odin.ietf.org>; Wed, 8 May 2002 11:08:57 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04316 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:09:06 -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 LAA03955; Wed, 8 May 2002 11:06:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03924 for <dhcwg@optimus.ietf.org>; Wed, 8 May 2002 11:06:17 -0400 (EDT)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10951 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:06:08 -0400 (EDT)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48F6G64112360 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:06:16 -0400
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48F6CQ230384 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:06:12 -0400
Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48F6aB19222 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:06:36 -0400
Message-Id: <200205081506.g48F6aB19222@rotala.raleigh.ibm.com>
To: dhcwg@ietf.org
Date: Wed, 08 May 2002 11:06:36 -0400
From: Thomas Narten <narten@us.ibm.com>
Subject: [dhcwg] dhcpv6-24: movement detection and Confirm message
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

> 18.1.2. Creation and transmission of Confirm messages
> 
>    Whenever a client may have moved to a new link, its IPv6 addresses
>    and other configuration information may no longer be valid.  Examples
>    of times when a client may have moved to a new link include:
> 
>      o The client reboots
> 
>      o The client is physically disconnected from a wired connection
> 
>      o The client returns from sleep mode
> 
>      o The client using a wireless technology changes access points
> 
>    In any situation when a client may have moved to a new link, the
>    client MUST initiate a Confirm/Reply message exchange.  The client

Hmm. I wonder if movement detection should just be dropped from
DHC. The problem of determining whether you have reconnected to a new
link is a generic problem, not just one that DHC has. If you have
routers, for example, you could use RAs to determine that you have
moved, which would then retrigger DHC (as appropriate). I could
imagine an RA option that included a unique identifier for the link
(this might be useful for mobility in general). Or, you could just see
of the router you were using has changed (its link-local address is an
identifier). Or, use the set of on-link prefixes on the RA. If they
are the same as before, you presumably haven't moved. Having the
client send DHC messages to the server to determine whether it has
moved seems like a fair amount of overhead and sub optimal.

Also, if one dropped the movement detection from DHC, would this allow
you to do away with the Confirm? I.e., if a client detects that it has
moved, then just have it redo the normal DHC exchanges. That would
seem simpler. Plus, if a node has actually moved, the confirm will
fail, and the normal DHC exchanges have to be used anyway.

Thomas

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