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

[David Schinazi <[e-mail]>]

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.

*) 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 <[e-mail]> 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