Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA

[David Farmer <[e-mail]>]

On Wed, Dec 13, 2017 at 1:34 PM, Simon Hobson <[e-mail]>
wrote:

> Brian E Carpenter <[e-mail]> wrote:
>
> > Well, the "Note:" does leave an open question. How does the person (or
> > automaton) configuring the router that sends the RA know that no
> > information is available via DHCPv6? It is entirely possible that
> > DHCPv6 is available on another box, and the person configuring the
> > the router doesn't know it. So these flags are intrinsically unreliable
> > and can only be hints; it's *necessary* that hosts are allowed to
> > ignore them and look for DHCPv6 anyway.
>
> I keep hearing this argument time and time again, but cannot reconcile it
> with any professionally managed network. Are there really professionally
> managed networks where the guys responsible for the routers (intrinsically
> tied in with the network config) don't talk to the guys running DHCP
> servers (intrinsically tied in with the network config) ?
> Put another way, are there really networks where two different groups "do
> their own thing" without agreeing between themselves how the network is
> supposed to work ?
>

So when the people running the DHCPv6 servers screw up, and the DHCP server
is down, what tells the router tat DHCPv6 isn't available? Nothing,
therefore, at best the M and O flags signal an intent not a fact, and
should only be considered advisory.  So I consider the M an O flags to mean;

1 = there should be a DHCPv6 server, and therefore hosts should keep trying
if one doesn't readily answer
0 = there should not be a DHCPv6 server, and therefore hosts should not
keep trying if one doesn't readily answer, or hosts might not try at all

Furthermore, even if there is no router on the link to advertise an RA, or
if the router is misconfigured to set M and O flags = 0, that doesn't mean
there isn't a DHCPv6 severer on the link, or available via routed
multicast. Its is probably safe to assume there isn't a DHCPv6 relay
configured on the router though. This is why several OS send initial DHCPv6
Solicits. But, I would hope if M and O flags = 0, this would not be
continued after a couple tries. In other words, if you send a couple
solicits and get no answer, you have empirical evidence that the M and O
flags = 0 is actually correct, and should then give up.

I believe the M and O flag specification in RFC 4861 is technical correct,
but is far too subtly written. I would be good when RFC 4861 is next update
for this to be more plainly stated.

Thanks.

-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone] <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================