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

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:Ted.Lemon@nominum.com]
Sent: Wednesday, May 08, 2002 11:37 AM
To: Thomas Narten
Cc: dhcwg@ietf.org
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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg