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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 8 May 2002 16:43:20 -0500

Perhaps we can reword 18.1.2 to not make this required (MUST)?

For example, if the client has another means of determining whether it is still on the same link (such as it receives a RA) and wants to use that technique (since it might do that for stateless autoconfigured addresses), there is no requirement that it use Confirm (if it determines that it is on a new link)?

Perhaps stated more clearly ... if the client has determined through some other means that it has moved to a new link, it need not use Confirm. Otherwise, a client SHOULD use a Confirm/Reply message exchange when it believes it may have moved to a new link.

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).

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, May 08, 2002 11:37 AM
To: Thomas Narten
Cc: [email-masked]
Subject: Re: [dhcwg] dhcpv6-24: movement detection and Confirm message

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.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 May 2002 16:52:42 -0500

Probably the right way to do this is to say that if the client has reason 
to believe, based on the listed reasons or any other reasons, that it is on 
a different link, but that it cannot be sure it is on a different link, it 
SHOULD send a Confirm message.   If it is _sure_ that it is on another link 
(e.g., based on an RA), it SHOULD send a Solicit message.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 09 May 2002 08:43:30 -0400

> 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