Re: [v6ops] Mobile: Happy DNSclientBalls

Erik Kline <ek@google.com> Thu, 11 January 2018 12:06 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 78B6B12EB12 for <v6ops@ietfa.amsl.com>; Thu, 11 Jan 2018 04:06:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 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, T_RP_MATCHES_RCVD=-0.01, 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 9839Y8H8jYMb for <v6ops@ietfa.amsl.com>; Thu, 11 Jan 2018 04:06:52 -0800 (PST)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 6E30D12EB10 for <v6ops@ietf.org>; Thu, 11 Jan 2018 04:06:52 -0800 (PST)
Received: by mail-yw0-x234.google.com with SMTP id c78so893375ywb.13 for <v6ops@ietf.org>; Thu, 11 Jan 2018 04:06:52 -0800 (PST)
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=3ZWiZnRPNRYrprCTLD0hwWDKIeij9Q5YBvfoq970goM=; b=ZTLuNqwE+kBb2FEQPU/qJAvBp1UTdgUGyyJ9iNWRi3U8pUYjz2DzqiphN46zAyf/e8 /5sL4IN2aNZu0tynAadSZbw7dhVtXW5rVURyxY1XAHoRrU7O2oW5c7Au35PpgdF8vWf8 vpfLjBYbK/S19JUqzVZAXEk/eWFChiUIADO+B9lMndPV/6ZDYtjlR6U7XhEMdoRF+JUv Q7aOAaVyPM1p//sRZAJgKJ5YgR/gQ3Cm8Ko5aAfLsGfOh/J8sQO1yo9CMpfWnGnJqzHI oLb9Q79RsYSl9g8gQIaGggDZo75KOdA+pJA83iCmSYYzxO6FUuQ1ptVS1JgTGflnjQ9Q rcTA==
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=3ZWiZnRPNRYrprCTLD0hwWDKIeij9Q5YBvfoq970goM=; b=bWGjDkfJHY+o+0MB8NJ+1n2lwHeVkLvLV1ykznC9dQtMqNt/cHR/E5IPL9qT7OMkzs IDYEuclfK2Y4toGvCIId/gtwK2NRe87fOLR4LfnnQJ14lqlWvCwbj4tG3MOdSdJWTmk6 /CwM22gJLVt5YfzSw1GMLmteIK0AUKYPf6YLV6VDqwtz2JnIwTZGhHNAHCwCKoUEFRRu GQokbTMIK/jEUaDIgHg3gS+3RMriW6nfzdqE/2JLCiysRZoVAbpen5BBxZJEs2yB3uJt BPJgSOdvtxs3UdarXZ8ePCb406Ejk5LQpA864pFRJm1c+qAhgWNUhwHj/1gnJ2PG2ZBA zPoA==
X-Gm-Message-State: AKGB3mLGFuicUAIxDBZbraW5BywtkcOnyKc2qGCZT33KSYp5nanEjiuC S0jZt8zcprdx45jQhaY66j8B9XsJqyOElzkeq78sY62A
X-Google-Smtp-Source: ACJfBosEX/ClwgWVhc8JKnZzrXGgbMdm1K4nQlO0OEouKwd7UwH96gU127M7mzw53vU0YJQKH5nevXM/qcBFixIGMvA=
X-Received: by 10.13.217.80 with SMTP id b77mr12636047ywe.123.1515672411305; Thu, 11 Jan 2018 04:06:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.164.167 with HTTP; Thu, 11 Jan 2018 04:06:30 -0800 (PST)
In-Reply-To: <CAEiR1_mGa9Zt64VR07KZOQnbP3AouGo=4Bk0m4Dkn9XR-GzdfQ@mail.gmail.com>
References: <CAEiR1_k1gbhdiQnv_xHRggJVT3Z2Y8otYv7SYwJD8bfUU3hiSg@mail.gmail.com> <CAAedzxogNue1en3y9aN3xu90XHPPcxLF7oTN=5EzhabqwRZGOw@mail.gmail.com> <CAEiR1_mGa9Zt64VR07KZOQnbP3AouGo=4Bk0m4Dkn9XR-GzdfQ@mail.gmail.com>
From: Erik Kline <ek@google.com>
Date: Thu, 11 Jan 2018 21:06:30 +0900
Message-ID: <CAAedzxqCnmZnEY3wcYz7B7B-GyMzt755ox0zSSDogKWbyL+Vdg@mail.gmail.com>
To: Thor-Henrik Kvandahl <kvandahl@gmail.com>
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c087654b5161705627efbe7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/_QXzimv6-gwb7NL5_qBN8pOOBUo>
Subject: Re: [v6ops] Mobile: Happy DNSclientBalls
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, 11 Jan 2018 12:06:54 -0000

You can "expect a change" in the sense that it is something we want to
fix.  When it is ultimately fixed it will effectively only apply to
releases going forward from the date of the fix (i.e. it will not be
backported to contemporaneous nor prior releases).

On 11 January 2018 at 20:47, Thor-Henrik Kvandahl <kvandahl@gmail.com> wrote:
> Actually, in the updated "Happy Eyeballs" RFC8305, handling of multiple DNS
> server addresses are addressed and "queries SHOULD be sent over IPv6 first".
> Also you say Google has an open bug on RFC6724, sorting of nameservers.
> If I understand the RFCs correct, Android Oreo and Nougat (and also older?)
> terminals should change behavior and prefer IPv6 nameservers.
> Is this correct and can we expect a change ?
>
> 3.1.  Handling Multiple DNS Server Addresses
>
>    "If multiple DNS server addresses are configured for the current
>    network, the client may have the option of sending its DNS queries
>    over IPv4 or IPv6.  In keeping with the Happy Eyeballs approach,
>    queries SHOULD be sent over IPv6 first (note that this is not
>    referring to the sending of AAAA or A queries, but rather the address
>    of the DNS server itself and IP version used to transport DNS
>    messages).  If DNS queries sent to the IPv6 address do not receive
>    responses, that address may be marked as penalized and queries can be
>    sent to other DNS server addresses.
>
>    As native IPv6 deployments become more prevalent and IPv4 addresses
>    are exhausted, it is expected that IPv6 connectivity will have
>    preferential treatment within networks.  If a DNS server is
>    configured to be accessible over IPv6, IPv6 should be assumed to be
>    the preferred address family.
>
>    Client systems SHOULD NOT have an explicit limit to the number of DNS
>    servers that can be configured, either manually or by the network.
>    If such a limit is required by hardware limitations, the client
>    SHOULD use at least one address from each address family from the
>    available list."
>
>
>
> --
> Thor-Henrik Kvandahl
>
> 2018-01-11 8:57 GMT+01:00 Erik Kline <ek@google.com>om>:
>>
>> We have an open bug to do RFC6724 sorting of nameservers.  Haven't
>> gotten around to it just yet.
>>
>> As far as requirements go, I'm not aware of anything off the top of my
>> head.  Carriers can (and do) try to require whatever they can dream
>> up, but that's separate.
>>
>> On 11 January 2018 at 16:46, Thor-Henrik Kvandahl <kvandahl@gmail.com>
>> wrote:
>> > Hi,
>> >
>> >
>> >
>> > Does anyone know if there are defined requirements on behaviour for the
>> > DNS
>> > client on a Mobile Node (MN/UE) connected to a dual stack APN where the
>> > 3gpp
>> > IE container provisioned both IPv4 and IPv6 name servers?
>> >
>> > As far as I know it is up to the UE to prefer between the provisioned
>> > name
>> > servers, and I think they should prefer IPv6 name servers.
>> > My Android Oreo and Nougat DNS clients uses only IPv4 for DNS requests
>> > and I
>> > think it would be better for the NAT44(4) devices between the PGW and
>> > the
>> > resolver if the UE preferred to use the IPv6 name server(s).
>> >
>> > If there are no requirements for this, does anyone know the Google
>> > policy
>> > for Android on this?
>> >
>> > Iphone's seems to prefer the IPv6 name servers.
>> >
>> >
>> >
>> >
>> > --
>> >
>> > Thor-Henrik Kvandahl
>> >
>> > _______________________________________________
>> > v6ops mailing list
>> > v6ops@ietf.org
>> > https://www.ietf.org/mailman/listinfo/v6ops
>> >
>
>