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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
