Re: [v6ops] Apple and IPv6, a few clarifications

🔓Dan Wing <dwing@cisco.com> Wed, 24 June 2015 08:08 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7941B31BF for <v6ops@ietfa.amsl.com>; Wed, 24 Jun 2015 01:08:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.21
X-Spam-Level:
X-Spam-Status: No, score=-14.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 A0FBWdGrUVWl for <v6ops@ietfa.amsl.com>; Wed, 24 Jun 2015 01:08:09 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1711B31CC for <v6ops@ietf.org>; Wed, 24 Jun 2015 01:08:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22071; q=dns/txt; s=iport; t=1435133288; x=1436342888; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=I86SpnU8WZZxDcaoF43pV7OtVmASCE8DKb2Ek5lUkVs=; b=kQzHujPKtab9CS7U0pDWJNcJwa8hFcnixp9UarXkAnstpqM8fLtAHoOA uCK5sjFr2GfuGH3J9nOp848K24GaRrtDpNFgXhJtJC2k/DHkd1Wel2E+4 vgVyCx3B/efQChHEeVLXYx4OD1E+UWWxNPbHQQdg6pKwouss0h5fUfuf7 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DOAwD2ZIpV/5BdJa1bgxBUX70oCYFcAQuFdgKBSTgUAQEBAQEBAYEKhCMBAQQBAQEaSgcLEAsOCicHJx8RBhOILw3NKwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEikiBAoQtDkcEB4MXgRQFhRyHYYQngluEWIRbgh6BOoQQgmuHf4Qmg1smggwFF4FyHjEBAQGBAIFFAQEB
X-IronPort-AV: E=Sophos;i="5.13,671,1427760000"; d="scan'208,217";a="4196749"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP; 24 Jun 2015 08:08:06 +0000
Received: from [10.24.206.20] ([10.24.206.20]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t5O885mw020343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jun 2015 08:08:06 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_45EAF800-424D-449C-BFE3-70BF300CA720"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= <dwing@cisco.com>
In-Reply-To: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com>
Date: Wed, 24 Jun 2015 01:08:06 -0700
Message-Id: <79C25286-FC91-490F-8323-9550EAC0911B@cisco.com>
References: <E1C235B5-1421-4DAF-A2F3-F963982233DF@apple.com> <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com>
To: David Schinazi <dschinazi@apple.com>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/_G7YkWzl-5WfsKGjd9FKLXPg4AE>
Cc: Vividh Siddha <vividh@apple.com>, v6ops@ietf.org
Subject: Re: [v6ops] Apple and IPv6, a few clarifications
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Jun 2015 08:08:12 -0000

On 24-Jun-2015 12:15 am, David Schinazi <dschinazi@apple.com> wrote: 
> Hi again,
> 
> First off, thanks everyone for the feedback and advice!
> Here's an attempt at answering the questions that arose since my last post.
> 
> *) Personal hotspot on iOS
> Currently the hotspot shares whatever address families it gets from the cellular network.
> The current implementation broadcasts an IPv6-only network if the cellular network is of that type,
> but I could imagine carriers bringing up IPv4 specifically when using this feature. Our custom version
> of prefix sharing is described in more detail here:
> https://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netinet6/nd6_prproxy.c <https://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netinet6/nd6_prproxy.c>
> It supports creating multiple hotspots at the same time, such as Wi-FI and Bluetooth and bridges them.
> 
> *) iOS and cellular carrier networks
> I do not know if or when specific carriers plan to change their IPv6 policies. That said, we do believe
> there is a growing trend towards IPv6. When roaming between carriers, your device will get new
> addresses and could possibly switch between address families.
> 
> *) VPN
> Our implementation of IKEv2, which is our current recommended VPN protocol, supports IPv6 on both
> the inside and outside of the tunnel. Other protocols are currently not guaranteed to be fully compatible.
> 
> *) Internet Sharing on the Mac
> We agree that it would be nice to support IPv6, but the risk/reward tradeoff isn't necessarily there yet.
> 
> *) Internet Sharing on the Mac - NAT64 testing mode
> To reset expectations on this feature, it targets developers of networked apps that are not knowledgeable
> in IPv6, most likely not anyone on this list. If you're writing your own sockets code that works on dual-stack
> and have a dual-stacked server, you probably know what you're doing already. The goal is really not
> performance optimization, simply checking that your app will manage to connect to your server at all.
> Realistically, today any service accessible by apps over IPv6 is also available over IPv4. Debugging path
> MTU issues is currently out of scope of this test network. The App Store IPv6 compatibility requirement will
> not reject an app solely based on tests using the NAT64 test network. The NAT64+DNS64 on the Mac will
> currently only query for A records and return synthesized AAAA records to its clients, it effectively ignores any
> AAAA records it receives from the wide area. We're looking into improving this feature, we agree that adding
> real IPv6 connectivity and using a different prefix would be better.
> 
> *) Happy Eyeballs
> Thanks to everyone for the advice on this topic, we're looking into the best compromise between providing
> our customers with good response times in the short term and helping them in the long term by helping the
> deployment of IPv6. An issue with RFC 6555 is that it was designed in a mindset where DNS resolution is
> provided by synchronous APIs such as getaddrinfo. In practice, your AAAA and A records do not come back
> at the same time and if you receive the A record first, every millisecond you wait before sending out a SYN is
> an IPv6 tax you're levying on your users. This being helpful in the long term, there must be a sweet spot. To
> clarify our use of the RTT to prioritize addresses, we use historical RTT measurements of all TCP packets on
> that route. If and when we release an updated implementation, I will update this list.

I have long thought Apple's implementation of Happy Eyeballs is awesome.  Tweaking the algorithm's built-in fudge factor to trend more towards IPv6 would make it more consistent with other OSs and applications (which give 200-300ms Happy Eyeballs head start to IPv6, which is similar to the fudge factor done by Apple).  Myself, I would like the fudge factor to be configurable via sysctl or at least viewable via netstat (or similar).  As it is, it is difficult to understand why a system is heavily preferring IPv4 or IPv6, and when it will give up; disconnecting and reconnecting the network is a harsh troubleshooting step for other traffic.

-d


> 
> *) 464XLAT
> We've considered using this technology and decided that it was not the best course of action. This doesn't
> mean we will never consider it and we're definitely interested in discussing pros and cons but in my
> humble (personal) opinion, calling us names to "get our attention" is not likely to convince us that 464XLAT
> is the One True Path to IPv6 deployment.
> 
> As mentioned in my last message, all these details only reflect the current betas and can change in the future.
> 
> Thanks,
> David
> 
> 
>> On Jun 19, 2015, at 14:46, David Schinazi <dschinazi@apple.com <mailto:dschinazi@apple.com>> wrote:
>> 
>> Hi everyone,
>> 
>> I'd like to clarify a few points about Apple's IPv6 announcements during WWDC 2015.
>> The video (streaming with Safari or download with all browsers) and slides of that talk
>> are available at: https://developer.apple.com/videos/wwdc/2015/?id=719 <https://developer.apple.com/videos/wwdc/2015/?id=719>
>> 
>> *) Personal hotspot on iOS
>> If your iPhone has dual-stack connectivity on its cellular network, the hotspot it creates
>> will be dual-stack as well. The phone will share its prefix with Wi-Fi clients.
>> 
>> *) Internet Sharing on the Mac
>> Today, regular internet sharing (from your ethernet to Wi-Fi for example) does not
>> support IPv6 because of the limited use cases, and the lack of demand for it.
>> 
>> *) Internet Sharing on the Mac - NAT64 testing mode
>> The NAT64 test mode was designed to help developers ensure that their app can still
>> function with IPv6-only NAT64+DNS64 connectivity and communicate with their IPv4
>> server, even if the developer does not have access to the IPv6 internet. That NAT64
>> network does not have IPv6 connectivity to the global IPv6 internet. As such, the current
>> version advertises addresses from 2001::/64 instead of ULAs to simulate real IPv6
>> connectivity, as all IPv6 packets are terminated at the NAT64 server on the Mac.
>> This implementation detail could change in the future.
>> 
>> *) Making IPv4 literals work on NAT64 networks when using high-level APIs
>> Starting with this year's versions, if you use NSURLSession to connect to an IPv4
>> literal on an IPv6-only NAT64-DNS64 network, the API will bump in a IPv6 literal
>> synthesized using RFC 7050. Note that this will not happen when using sockets
>> directly. We do not support under-the-sockets bump-in-API (RFC 3338) and we
>> do not support 464XLAT.
>> 
>> *) Happy Eyeballs
>> We've heard feedback on our Happy Eyeballs implementation and are investigating
>> this topic.
>> 
>> Note that this reflects how these technologies work in the current versions of the
>> 2015 betas, many of these details could change in future betas. Please keep in mind
>> that these betas are previews and we welcome feedback on improving them.
>> 
>> Feel free to contact me if you have any questions, I will also attend IETF93.
>> 
>> Thanks,
>> David Schinazi
>> Apple CoreOS Networking Engineer
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops