Subject: Windows 10 doesn't honour 'M' flag in RA

From: Naveen Kottapalli <[email-masked]>
Date: Tue, 12 Dec 2017 12:50:31 +0530

Hello,

In our recent testing, we observed that Windows 10 doesn't honour 'M' flag
in RA.  It's not just Windows 10, same behaviour is observed with latest
Mac OS as well.  Is there any specification reference to support this?

Your valuable input is highly appreciated.

Yours,
Naveen.

---

From: Erik Kline <[email-masked]>
Date: Tue, 12 Dec 2017 16:25:54 +0900

What does it really mean, to "honour the 'M' flag"?  Those bits are
advisory /at best/.

On 12 December 2017 at 16:20, Naveen Kottapalli <[email-masked]> wrote:
> in RA.  It's not just Windows 10, same behaviour is observed with latest Mac
> OS as well.  Is there any specification reference to support this?
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Naveen Kottapalli <[email-masked]>
Date: Tue, 12 Dec 2017 13:10:12 +0530

I mean that though the 'M' bit is set to 0, client initiated DHCPv6 Solicit.

Yours,
Naveen.

On 12 December 2017 at 12:55, Erik Kline <[email-masked]> wrote:

> Mac

---

From: Enno Rey <[email-masked]>
Date: Tue, 12 Dec 2017 08:45:38 +0100

Hi,

> I mean that though the 'M' bit is set to 0, client initiated DHCPv6 Solicit.

that's a deliberate decision from Microsoft: their recent OSs all send out DHCPv6 Solicits at a very early stage of (IPv6) stack initialization (even before sending the router solicitation => at that point there's not even an RA to process/to inspect the flags of).
See also https://insinuator.net/2017/01/ipv6-properties-of-windows-server-2016-windows-10/

best

Enno

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Matthias Luft, Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Dec 2017 08:47:26 +0100 (CET)

> I mean that though the 'M' bit is set to 0, client initiated DHCPv6 Solicit.

       M              1-bit "Managed address configuration" flag.  When
                      set, it indicates that addresses are available via
                      Dynamic Host Configuration Protocol [DHCPv6].

>From earlier discussions, there is nothing saying "you can't do DHCPv6 
requests if M=0". So technically these implementations aren't in violation 
of any standards, the M and O flags are only informational.

It would however be interesting to understand the rationale if this 
change from the OS vendors.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Dec 2017 18:50:50 +0000

This is why it would be better to have IPv6 ND and DHCPv6 as a unified
stateless/stateful autoconfiguration service. Everything can be done in
a single message exchange (RS/RA with DHCPv6 option) instead of
requiring multiple message exchanges just for the sake of examining
the M/O bits.

Thanks - Fred

---

From: Naveen Kottapalli <[email-masked]>
Date: Wed, 13 Dec 2017 16:32:45 +0530

Yes, it would have been the better way.  If clients aren't even referring
the 'M' bit, what is the use of carrying in RA?

Yours,
Naveen.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Dec 2017 12:26:50 +0100 (CET)

On Wed, 13 Dec 2017, Naveen Kottapalli wrote:

> Yes, it would have been the better way.  If clients aren't even 
> referring the 'M' bit, what is the use of carrying in RA?

Some operating systems do, some don't. It's a hint. It's up to the 
implementor to decide what to do if the flag is set or not.

---

From: Naveen Kottapalli <[email-masked]>
Date: Wed, 13 Dec 2017 17:41:23 +0530

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

Yours,
Naveen.

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Dec 2017 12:29:44 +0000

On 13 Dec 2017, at 12:11, Naveen Kottapalli <[email-masked]<mailto:[email-masked]>> 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.

You wouldn’t believe how many thousand emails have discussed this :)

A ‘hint’ was the consensus.

Tim

Yours,
Naveen.

On 13 December 2017 at 16:56, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, 13 Dec 2017, Naveen Kottapalli wrote:

Yes, it would have been the better way.  If clients aren't even referring the 'M' bit, what is the use of carrying in RA?

Some operating systems do, some don't. It's a hint. It's up to the implementor to decide what to do if the flag is set or not.

--
Mikael Abrahamsson    email: [email-masked]<mailto:[email-masked]>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Dec 2017 15:24:18 +0000

Hi Naveen,

> Yes, it would have been the better way.

It’s not too late to set things right. Combining IPv6 ND router discovery
and DHCPv6 in a single, unified service combines the best features of
stateless and stateful autoconfiguration. All it takes is defining a new
IPv6 ND message option.

Plus, it is backwards compatible. If the host sends an RS with a DHCPv6
option, and the router does not recognize the option, the router sends
back an RA with no DHCPv6 option and the host can know that it needs
to do things the old way (i.e., send DHCPv6 Solicit after receiving the RA).
In the other direction, the router will never send an RA with the DHCPv6
option included unless the host first sent an RS with DHCPv6 option.

With a combined autoconfiguration service  like this, the ages-old debate
about SLAAC vs. DHCPv6 goes away, and we truly get the best of both
worlds.

Thanks - Fred

From: Naveen Kottapalli [mailto:[email-masked]]
Sent: Wednesday, December 13, 2017 3:03 AM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA

Yours,
Naveen.

On 13 December 2017 at 00:20, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Dec 2017 11:03:39 -0500

> A ‘hint’ was the consensus.

A 'hint' was the vote.   I don't believe that it was a consensus.   As Naveen points out, the current solution is technically invalid.   It would be better not to have the 'M' bit than to have it be a hint.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 13 Dec 2017 08:45:46 -0800

Ted,

The actual text from Section 4.2. "Router Advertisement Message Format” in RFC4861 is:

                     If the M flag is set, the O flag is redundant and
                     can be ignored because DHCPv6 will return all
                     available configuration information.

      O              1-bit "Other configuration" flag.  When set, it
                     indicates that other configuration information is
                     available via DHCPv6.  Examples of such information
                     are DNS-related information or information on other
                     servers within the network.

        Note: If neither M nor O flags are set, this indicates that no
        information is available via DHCPv6.

I think the protocol specification is clear.

Bob

> On Dec 13, 2017, at 8:03 AM, Ted Lemon <[email-masked]> wrote:
>

---

From: Naveen Kottapalli <[email-masked]>
Date: Wed, 13 Dec 2017 22:45:51 +0530

Response inline.

Yours,
Naveen.

On 13 December 2017 at 22:15, Bob Hinden <[email-masked]> wrote:

> Naveen] This statement isn't saying that 'M' bit SHOULD / SHALL be
referred to learn or get the addresses via DHCPv6.  This is where the point
is.

> > A 'hint' was the vote.   I don't believe that it was a consensus.   As
> Naveen points out, the current solution is technically invalid.   It would
> be better not to have the 'M' bit than to have it be a hint.
> >
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Dec 2017 07:49:27 +1300

> [Naveen] This statement isn't saying that 'M' bit SHOULD / SHALL be

See below for why this cannot be a requirement.

>> I think the protocol specification is clear.

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.

[BTW I came to this realisation after drafting the text in
https://tools.ietf.org/html/draft-hinden-ipv4flag-01#section-4.
The logic of the situation is quite similar.]

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Dec 2017 14:32:30 -0500

> ignore them and look for DHCPv6 anyway.

So, maybe what we should be writing is:

O              1-bit "Other configuration" flag.  When clear it
               indicates that this router believes that it has all
               available/valid configuration information.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Simon Hobson <[email-masked]>
Date: Wed, 13 Dec 2017 19:34:48 +0000

> 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 ?

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Dec 2017 19:41:10 +0000

Hi,

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Simon Hobson
> Sent: Wednesday, December 13, 2017 11:35 AM
> To: [email-masked] list <[email-masked]>; IPv6 List <[email-masked]>
> 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) ?

A unified SLAAC/DHCPv6 service would reconcile the ambiguity.

Thanks - Fred

---

From: james woodyatt <[email-masked]>
Date: Wed, 13 Dec 2017 12:27:45 -0800

> 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 ?

Put another way, "are there really professionally managed networks?”

Worth noting: the point is that the “Note:” in RFC 4861 cited previously in the thread asserts that M=0&O=0 is a signal to all hosts on the link that “no information is available via DHCPv6,” which is really only true while *all* the routers on the link are consistently sending that signal. It stops being true as soon as one or more of the routers on the link contradict the signal, and it continues to not be true until all the contradicting routers expire their valid lifetimes. On a “professionally managed network,” there might never be any contradicting routers on the link at any time, and in that case the Note correctly describes how the protocol works. In other cases, however, it remains a little less than clear.

So, I ask again: are there really professionally managed networks?

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: David Farmer <[email-masked]>
Date: Wed, 13 Dec 2017 15:00:32 -0600

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

> 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:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

---

From: Bob Hinden <[email-masked]>
Date: Wed, 13 Dec 2017 13:43:27 -0800

James,

> On Dec 13, 2017, at 12:27 PM, james woodyatt <[email-masked]> wrote:
> 

Yes.  The common definition of professional is that you get paid to do a job.  How well you do it is another matter :-)

To you point, I think there are networks where all of the routers are configured correctly.

Bob

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 13 Dec 2017 22:07:36 +0000

Hi Naveen (or anyone else who cares to answer),

> OS as well.  

I'm curious: What is being harmed by this behavior? I can definitely see advantages in Windows and Mac OS doing it this way; I'm just struggling to understand the disadvantages. Years ago, there was a problem in some ISP networks prior to full launch of IPv6 and prior to support for SOL_MAX_RT (RFC 7083) of DHCPv6 servers being overwhelmed by Solicit messages they were configured not to respond to (because IPv6 wasn't formally supported). But with SOL_MAX_RT, that really shouldn't be an issue. So what is being broken by this behavior now?

Barbara

---

From: Enno Rey <[email-masked]>
Date: Thu, 14 Dec 2017 00:35:29 +0100

Hi,

On Wed, Dec 13, 2017 at 10:07:36PM +0000, STARK, BARBARA H wrote:
> > in RA.?? It's not just Windows 10, same behaviour is observed with latest Mac
> > OS as well.?? 
> 
> I'm curious: What is being harmed by this behavior? I can definitely see advantages in Windows and Mac OS doing it this way; I'm just struggling to understand the disadvantages.

when the router
- sends RAs with "O" flag.
- is configured as a DHCPv6 server handing out one or several v6 DNS server(s)

[which is a very common setup of CPE devices in broadband networks]

then the node sending a DHCPv6 SOLICIT (without being "advised" to do so by the "M" flag) will receive (from the DHCPv6 server not being able to serve it's request) a "NoAddrAvail" status code and will hence (in full compliance with RFC 3315 sect. 17.13) ignore the *full* DHCPv6 packet received from the server. This in turns means it will not learn the (v6) DNS server which is clearly not what is intended by that type of setup from the broadband providers.

See also: https://insinuator.net/2017/01/ipv6-properties-of-windows-server-2016-windows-10/

best

Enno

 Years ago, there was a problem in some ISP networks prior to full launch of IPv6 and prior to support for SOL_MAX_RT (RFC 7083) of DHCPv6 servers being overwhelmed by Solicit messages they were configured not to respond to (because IPv6 wasn't formally supported). But with SOL_MAX_RT, that really shouldn't be an issue. So what is being broken by this behavior now?

-- 
Enno Rey

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 13 Dec 2017 18:58:39 -0800

At Wed, 13 Dec 2017 17:41:23 +0530,

> 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

---

From: Naveen Kottapalli <[email-masked]>
Date: Thu, 14 Dec 2017 17:36:55 +0530

No harm is seen with this behaviour.  Just curious on know why the
protocols are designed this way where devices doesn't honour the flags sent.

Yours,
Naveen.

On 14 December 2017 at 03:37, STARK, BARBARA H <[email-masked]> wrote:

> I'm curious: What is being harmed by this behavior? I can definitely see
> advantages in Windows and Mac OS doing it this way; I'm just struggling to
> understand the disadvantages. Years ago, there was a problem in some ISP
> networks prior to full launch of IPv6 and prior to support for SOL_MAX_RT
> (RFC 7083) of DHCPv6 servers being overwhelmed by Solicit messages they
> were configured not to respond to (because IPv6 wasn't formally supported).
> But with SOL_MAX_RT, that really shouldn't be an issue. So what is being
> broken by this behavior now?
>
> Barbara
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Dec 2017 09:01:26 -0500

STARK, BARBARA H <[email-masked]> wrote:
    >> In our recent testing, we observed that Windows 10 doesn't honour 'M'
    >> flag in RA.  It's not just Windows 10, same behaviour is observed with
    >> latest Mac OS as well. 

    > I'm curious: What is being harmed by this behavior? I can definitely

I think a concern is that for a network on which there are no legitimate
DHCPv6 servers (O=0,M=0), that the operator of the router(s) sending RAs
don't know if the hosts will take the configuration from the RA, or the
configuration from the rogue DHCPv6 server.

One might think that setting M=0 and filtering all RAs from "access" ports
that this would protect the network.  But it's not the case, you need to
filter DHCPv6 as well.