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

From: Thomas Narten <[email-masked]>
Date: Wed, 08 May 2002 11:06:36 -0400

> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 May 2002 10:37:14 -0500

What we've described in this section is precisely how the most functional 
DHCPv4 clients operate today - e.g., the Apple DHCPv4 client does link 
change detection, and in practice the user experience is much better than 
what you get with the ISC dhcp client, which does not do link change 
detection.   The confirm message is necessary.   Using RA messages to do 
link change detection is great, and we talked about it, but as you say, it 
requires an additional RA option on whose presence we cannot count at this 
time.

So I would say we should leave this just the way it is.