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

🔓Dan Wing <> Wed, 24 June 2015 08:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3F7941B31BF for <>; Wed, 24 Jun 2015 01:08:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.21
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A0FBWdGrUVWl for <>; Wed, 24 Jun 2015 01:08:09 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB1711B31CC for <>; Wed, 24 Jun 2015 01:08:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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-AV: E=Sophos;i="5.13,671,1427760000"; d="scan'208,217";a="4196749"
Received: from ([]) by with ESMTP; 24 Jun 2015 08:08:06 +0000
Received: from [] ([]) by (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?= <>
In-Reply-To: <>
Date: Wed, 24 Jun 2015 01:08:06 -0700
Message-Id: <>
References: <> <>
To: David Schinazi <>
X-Mailer: Apple Mail (2.2098)
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 08:08:12 -0000

On 24-Jun-2015 12:15 am, David Schinazi <> 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:
> <>
> 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.


> *) 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 < <>> 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
> _______________________________________________
> v6ops mailing list