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

David Schinazi <> Wed, 24 June 2015 07:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 50CFB1B3057 for <>; Wed, 24 Jun 2015 00:15:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.411
X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wBB_6NXZBvJv for <>; Wed, 24 Jun 2015 00:15:46 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75E621A8898 for <>; Wed, 24 Jun 2015 00:15:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailout2048s; c=relaxed/simple; q=dns/txt;; t=1435130146; x=2299043746; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8CAfIQGH6EtnGRQB5uF+aSQoFYMMuyMi2qS2AMrOrA8=; b=3Y0IlW0JvA/aykjNKCofYRXRMIVa7Y7pP/HNSofYuMKzxZf0GzX7GMsMYv3jtmpB gaYfAmSoxdl0V2JDP3J/0zGhuYI5HssK2gmynOgB4PP3ggAJ1/neuy8op6VT1Cug zcMgNA7Hk+FB7i0nmT1MCYvSmZOu77ZrcvIXCP0QdoOe4pin5gbguyENYoVALo3M hbIReV2mCBvM/pfeHExBoy5ZclcWXVnEHpMUPGj4Rca4jx6HAd2pJ5NGZP63lOLH Z+pW8SEL3SmOT0nFNWHejkc6OxlQ2enyzevtoqP1Uoy1EVUCSFm6XHc1+y1rR5C/ LgV4fmzf+lvr5DY2oozknw==;
Received: from ( []) by (Apple Secure Mail Relay) with SMTP id 0D.84.18963.2295A855; Wed, 24 Jun 2015 00:15:46 -0700 (PDT)
X-AuditID: 11973e12-f79456d000004a13-17-558a5922139f
Received: from jimbu ( []) (using TLS with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by (Apple SCV relay) with SMTP id C5.7B.32123.1295A855; Wed, 24 Jun 2015 00:15:46 -0700 (PDT)
Received: from [] by (Oracle Communications Messaging Server 64bit (built Oct 22 2013)) with ESMTPSA id <> for; Wed, 24 Jun 2015 00:15:45 -0700 (PDT)
Content-type: multipart/alternative; boundary="Apple-Mail=_6E72A312-58BA-48DB-AF86-73B9467A48E9"
MIME-version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: David Schinazi <>
In-reply-to: <>
Date: Wed, 24 Jun 2015 00:15:44 -0700
Message-id: <>
References: <>
X-Mailer: Apple Mail (2.2102)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUi2FAYrKsU2RVqsH8Xq8XpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8frZfvaCz1MZK/ZcZmtgvFzXxcjBISFgIrGwPaGLkRPIFJO4 cG89WxcjF4eQwF5GiRML57BDJEwkTh2YxAxiCwm0MknsOOsIUfSJUeJtwxmwBLNAksS+J6dZ QIbyCuhJPOqUBQkLCxhKHLz9nQkkzCagJXFgjRFImFPAVqJ770tGkDCLgKrErG2VEENyJOau /ccEYvMK2EjMPTATaquNxJfdPawgtoiAkMSOZ01MEJfJSmx908oEco2EQAebxNPz25gmMArN QnLQLISDIMLaEssWvmYGCTML6EhMXsiIKgxhfzx/hGkBI9sqRqHcxMwc3cw8E73EgoKcVL3k /NxNjKBgn24ntIPx1CqrQ4wCHIxKPLwMnztDhVgTy4orcw8xSnOwKInzbv8DFBJITyxJzU5N LUgtii8qzUktPsTIxMEp1cC4MFjuXYT7th6B66HSHqLl3K8qDq+UC7zgGnlC0Xz2s6g3z1Jk p75escd9+4Jv+sYO6v02L1h1X7I+fH9yyqd1HxY37tb5POvo9jmb9LO05Z/EhzPtMOuzn/kr 2Utz8nUx29UaIoau7t+TKr7sfF9tpzBBa4HA7CgekUXxnKyvy3JCk3ael5mmxFKckWioxVxU nAgA+1agLVcCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUiON1OVVcpsivUYOlmRovTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/Wz/ewFn6cyVuy5zNbAeLmui5GTQ0LAROLUgUnMELaYxIV7 69lAbCGBViaJHWcduxi5gOxPjBJvG86AFTELJEnse3KapYuRg4NXQE/iUacsSFhYwFDi4O3v TCBhNgEtiQNrjEDCnAK2Et17XzKChFkEVCVmbauEGJIjMXftPyYQm1fARmLugZnMEFttJL7s 7mEFsUUEhCR2PGtigrhMVmLrm1amCYz8s5DcMAvhBoiwtsSyha+ZQcLMAjoSkxcyogpD2B/P H2FawMi2ilGgKDUnsdJYL7GgICdVLzk/dxMjKDwbCoN3MP5ZZnWIUYCDUYmHd8WHzlAh1sSy 4srcQ4wSHMxKIrwM/l2hQrwpiZVVqUX58UWlOanFhxilOViUxHkXLG8JFRJITyxJzU5NLUgt gskycXBKNTDWOQuIT2boV136NPLBMckbZof4FjxcHDPne0TJJMNDU8oYfjg8ke8M7GORr9IJ 7ct+lMM1f3OfVcdx1XVv7vLuesn+f+/5zzuutq7ne7H2vppXedLZNPWTmiXyNxgdFme/Vrn1 jcnCp2KjTlvLbEZl+ScC95ZeDe5n7lz30vGcw6WgtUtKhXcqsRRnJBpqMRcVJwIACvoIiksC AAA=
Archived-At: <>
Cc: Vividh Siddha <>
Subject: Re: [v6ops] Apple and IPv6, a few clarifications
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Jun 2015 07:15:49 -0000

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: <>
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.

*) 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.


> On Jun 19, 2015, at 14:46, David Schinazi <> 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: <>
> *) 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