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

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

At Wed, 13 Dec 2017 17:41:23 +0530,
Naveen Kottapalli <[e-mail]> wrote:

> I got that.  But am not sure on what is the use when devices don't bother
> the value of that bit in RA.

Effectively nothing.  If you look at RFC2461 and RFC2462, you'll find
behavior regarding these bits were more normative.  For example,
Section 5.5.3 of RFC2462 stated:

   [...] If the value of ManagedFlag changes from FALSE to
   TRUE, and the host is not already running the stateful address
   autoconfiguration protocol, the host should invoke the stateful
   address autoconfiguration protocol, requesting both address
   information and other information.
(you should read "the stateless address autoconfiguration protocol" as
DHCPv6).

But when we tried to update these docs (the result is RFC4861 and
RFC4862) we realized that it was not widely implemented and that it
would be quite difficult to specify more sensible behavior that met
people's varied opinions and preferences.  IIRC those include:

- some people wanted to be able to run DHCPv6 without bothering RA
  (technically, RFC2461/2462 didn't prohibit it, but there was a
  desire of making it clearer)
- some people wanted to have a way to signal hosts not to use DHCPv6
  (this is probably your interpretation.  but even RFC2461/2462 didn't
  have a clear description of such a way).  on a related matter, the
  meaning of zero-M/O bits wasn't clear (RFC2462 said hosts shouldn't
  stop DHCPv6 on the bit change from 1 to 0, but it didn't say
  anything about what it means if the bit is 0 from the beginning).
- some people wanted to have a way to turn off running DHCPv6
  (the original description of changing M from 1 to 0 didn't work
  that way)

In retrospect, it was probably just a bad idea to try to control this
just from these two bits.  So there was also an idea of deprecating
those bits.  But some people didn't like the idea due to compatibility
with existing implementations that rely on those bits.

So, the current wording of RFC4861 (and the silence about these bits
in RFC4862) was a kind of procedural compromise.  I suspect no one can
give a reasonable technical explanation to "what is the use of these
bits?" or "why do we even have these bits if they are useless?".

There have been attempts to give clearer semantics to these bits, but
none of them has succeeded.

That's an unfortunate situation, given that there are actually
implementations that still refer to these bits. But, knowing the
history I'm pessimistic about any further effort on these bits.  My
humble suggestion is to just accept the reality and use our time for
something else.

--
JINMEI, Tatuya