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

I don't have a major issue if we dropped Confirm.

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.

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.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, May 08, 2002 11:07 AM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcpv6-24: movement detection and Confirm message

> 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