IETF Logo Mail Archive

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

Enno Rey <erey@ernw.de> Wed, 13 December 2017 23:35 UTC

Return-Path: <erey@ernw.de>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D30128AA1; Wed, 13 Dec 2017 15:35:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlqB8omm8Y5o; Wed, 13 Dec 2017 15:35:32 -0800 (PST)
Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE25C1201F8; Wed, 13 Dec 2017 15:35:31 -0800 (PST)
Received: from mail1.ernw.net (unknown [172.31.1.30]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id BCACD27304; Thu, 14 Dec 2017 00:35:29 +0100 (CET)
Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 9068765D5B0; Thu, 14 Dec 2017 00:35:29 +0100 (CET)
Received: by ws26.ernw.net (Postfix, from userid 1002) id 5AAA439CB5; Thu, 14 Dec 2017 00:35:29 +0100 (CET)
Date: Thu, 14 Dec 2017 00:35:29 +0100
From: Enno Rey <erey@ernw.de>
To: "STARK, BARBARA H" <bs7652@att.com>
Cc: Naveen Kottapalli <naveen.sarma@gmail.com>, v6ops list <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
Message-ID: <20171213233529.GA55691@ernw.de>
References: <CANFmOtnJiKtBH9WuOjfAAaOxmrQ8SanU1ATiEY_zSA9DbAuUAA@mail.gmail.com> <CAAedzxptEK5nZTVHwuzG0aK119Ns61cdfNT3JWPafTGcAxMeeg@mail.gmail.com> <CANFmOtm2SU13o3Wey1XqhQf0WuuTzm80XXPp7Q9UGiV6Kvh5DA@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DCD4719@GAALPA1MSGUSRBF.ITServices.sbc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DCD4719@GAALPA1MSGUSRBF.ITServices.sbc.com>
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/MeIWs5NlmSCk4-6NaQ444Gi6QMU>
Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Dec 2017 23:35:35 -0000

Hi,

On Wed, Dec 13, 2017 at 10:07:36PM +0000, STARK, BARBARA H wrote:
> Hi Naveen (or anyone else who cares to answer),
> 
> > 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 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?
> 
> Barbara
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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

v2.23.0 | Report a Bug | By Email