IETF Logo Mail Archive

Re: [v6ops] Microsoft Win10 source address selection woes

Erik Kline <ek@google.com> Thu, 07 September 2017 11:09 UTC

Return-Path: <ek@google.com>
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 6154A1329AD for <v6ops@ietfa.amsl.com>; Thu, 7 Sep 2017 04:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 mbK34feHXzRz for <v6ops@ietfa.amsl.com>; Thu, 7 Sep 2017 04:09:07 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F311132D67 for <v6ops@ietf.org>; Thu, 7 Sep 2017 04:09:07 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id r85so14228025ywg.1 for <v6ops@ietf.org>; Thu, 07 Sep 2017 04:09:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DedM/ezweawDT0ZHIHvGw5sqtb+DsqSTnY+pif+8fJ0=; b=NgpOonvAOBGbfKuNPjHGbuJBPLMiSVggw5bFrJ+b55eJ1AeKffMERBpFqOFQEejuhS ATvUUO4AWa0keiT/xgIRmD+S/czQovR8EDAowiTFMpEh5Y6L4eDZNDlZEVa4nfan/Zti EAr2eOsQjExKmoaA+dD4dNmo5G2kVTTshaKU+IYcNvosHPcPlNkSGr26P60k6VyX6CNa JLaj88NLw4cXdvb0ynDNjo+QILN06RzPKbp2XLtyYrfIP9Yz0vSMBFYBh5dL7RbubPIH +QWbRh95FVUq4TAnSRLJRBChAwmB+BpLxg36L9DR4OtOqS4bLRvdE0NtABt+YpIzNJww OK9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DedM/ezweawDT0ZHIHvGw5sqtb+DsqSTnY+pif+8fJ0=; b=e7BPa9CbevwEVnc2SBSdOkA9SAy6d7ae/fWmcKqpxf6RE+tJUSjxMCPm/y03Iz5N6j bfjkZvKyf6z2CajwRrvvp2bJmSenRj7Vjj8rA+Zg4uC1mJH3YGhJL/eGHFJYuSOSZQxy EaoJni1/UPctFuskRxmnoIU8KrI9RFDsHzeejDLJswT9zosIoUjM9NOYbMxzTd7nyjqu wG5oV/qQhqU+skA1c+JHhaerDiAfOvGLacl3Z3tNSq290AeJiHsg6zO2pv2uD54zqSoz xITn8o+iAoj+NQ6Bq7wQL6KomvdOhP6FCuXkJl0onkLhzM0326OqEdYOYqbNLn0vsKk8 B3rA==
X-Gm-Message-State: AHPjjUhAog20SUxuKIt/aW2VJfAitPKc2ek3hFnbK53WIRTcrSpHSD8P juJon6flxruFl4tsD6WiHZjm7GG8wkDkt6pP4Q==
X-Google-Smtp-Source: ADKCNb7AM/dnwfZRxo+Y433CKdy8rrTQJ91rISl2Kejo4DgcWx+iIUHupacMeD7D55fJkPjQ7a8yeWDP994HzrK0SEo=
X-Received: by 10.37.126.4 with SMTP id z4mr1772945ybc.136.1504782546437; Thu, 07 Sep 2017 04:09:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.52.78 with HTTP; Thu, 7 Sep 2017 04:08:45 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.20.1709071245380.29378@uplift.swm.pp.se>
References: <alpine.DEB.2.20.1709071245380.29378@uplift.swm.pp.se>
From: Erik Kline <ek@google.com>
Date: Thu, 07 Sep 2017 20:08:45 +0900
Message-ID: <CAAedzxpBz_Eh5_k84-8WZ+xOBHS4_CY20DwJ4biXrRi4Xr0nBA@mail.gmail.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="001a114e2f862f01300558977d44"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/0rr-AxjoLFXOobioDA8KgSVXmdo>
Subject: Re: [v6ops] Microsoft Win10 source address selection woes
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: Thu, 07 Sep 2017 11:09:09 -0000

Is it expected that apps should make use of some
https://tools.ietf.org/html/rfc5014 API?

On 7 September 2017 at 19:53, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>
> I am finding interesting behavior with my fully updated Win10. It seems to
> prefer "public" address over temporary, which doesn't seem to follow
> RFC6724. These addresses are all in the same /64, I am running with A=1.
>
> (obfuscated some fields)
>
>> netsh int ipv6 sho addr
>
>
> Interface 6: Ethernet
>
> Addr Type  DAD State   Valid Life Pref. Life Address
> ---------  ----------- ---------- ---------- ------------------------
> Temporary  Deprecated    5d2h5m1s         0s PREFIX:8403:XYZ:f15e:d720
> Temporary  Preferred    6d2h3m27s    2h1m57s PREFIX:a910:XYZ:ef8e:3484
> Public     Preferred  29d23h57m11s 6d23h57m11s PREFIX:c16d:XYZ:XYZ:a45c
> Other      Preferred     infinite   infinite fe80::c16d:fb79:XYZ:XYZ%6
>
> Now, when I use web browsers (firefox/chrome/edge) they all use the public
> address for outgoing connections. This is not what I expected (and not what
> I see on my MacOS machine).
>
> RFC6724 rule 7 seems it should indicate that temporary address should be
> chosen. However, RFC3484 says public addresses should be chosen over
> temporary ones, unless specific API calls are made.
>
> Does this mean Windows 10 doesn't implement RFC6724 but instead implements
> 3484?
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.46.0 | Report a Bug | By Email | System Status