On Tue, 14 Oct 2008, Iljitsch van Beijnum wrote:
I've yet to see a DHCPv6 client implementation that would listen to the flags in RA and conditionally start or stop the service depending of the presence of flags there.Apart from Vista and special cases such as Cisco routers I'm not aware of an integrated DHCPv6 solution; they are all standalone programs that run when you run them and don't run otherwise. So there must be an administrative decision to run a DHCPv6 client.
Lots of Linux distributions include various DHCPv6 client implementations out of the box. AFAIK none of these include RA controls. DHCPv6 client behaviour is either always enabled or manually turned on (when it's always on, regardless of RA contents).
So I believe we're kidding ourselves if we think the DHCPv6 client software writers and operating system SW engineers trying to figure out a most reliable way to use DHCPv6 wouldn't start DHCPv6 client automatically under every scenario, no matter the flags. These implementations are not going to change no matter what we write in the RFCs.Disagree. I've personally seen DHCPv6 struggle to get where it is today over the past 5 years. It has been slow going with many mistakes along the way. I don't think there is any reason to assume we've reached the end state today.Over time, implementers usually refine their stuff to be more compliant. So specifying the correct behavior is a good thing even if we don't know for sure implementers are going to turn on a dime and implement it overnight.
You seem to have a misconception that whatever we write in RFCs has any significant bearing with how implementors implement that stuff if it doesn't seem to make sense for them.
There are a few rare ones that keep bugging about RA M/O flags periodically, the rest just silently ignore them. And they will very likely continue to ignore M/O definitions no matter what we put in the spec.
The reality is that most implementors will just ignore anything the spec says they don't like or consider unnecessary in the scenarios they have in mind. As long as their code interoperates (in those specific scenarios) with other major implementations, most couldn't care less.
And in some cases that's a good thing as it gives a hint what's the core feature set of the protocol; we can then throw away the rest unless there is serious interest in it.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg at ietf.org https://www.ietf.org/mailman/listinfo/dhcwg