[LAC-TF] Topic: IPv6 in Apple (WAS: Re: [v6ops] Apple and IPv6, a few clarifications (fwd))

Thu Jul 2 19:43:31 BRT 2015

Hi,

To begin with, I would like to share the topic of IPv6 support in Apple,
which has been discussed in the v6ops WG of the IETF.

You can find the messages from David Schinazi, from Apple, he sent 3
emails to clarify the support (at the end of this email 2 of them).

Or you can find them in the link:
https://mailarchive.ietf.org/arch/search/?qdr=m&email_list=v6ops&so=frm
(Sort the messages and write the name of David)

A brief summary I have made is:

*************************************************************************

- Hotspot personal in iOS:
 			iPhone dual-stack  => Hotspot dual-stack

     IPv6-only Broadcast <= if the cellular network is of that type,

  			Multiple Hotspots at the same time

No translation (until now)
 	IPv4-only device -> IPv6-only iOS handset

- Internet Sharing in the Mac:   NO IPv6 support

"would be nice to support IPv6"

- Internet Sharing in the Mac - NAT64 testing mode:

"No IPv6 connectivity to the global IPv6 internet"

  "advertises addresses from 2001::/64 instead of ULAs to simulate real IPv6 
connectivity"

- "Making IPv4 literals work on NAT64 networks when using high-level APIs:"

NO 464XLAT support and  "under-the-sockets bump-in-API"
 		".. decided that it was not the best course of action."

- Happy Eyeballs

"We've heard feedback on our Happy Eyeballs implementation and are
investigating this topic."

- iOS and cellular carrier networks

When roaming => switch between address families

- VPN

"IKEv2 supports IPv6,..  other protocols are currently not
guaranteed to be fully compatible."

*******************************************************************************

What experiences and comments you could share about it?

As end users and as network operators.

BEST, 
_______
Azael
UNAM
Mexico

PD: Sorry No Portuguese version

---------- Forwarded message ----------
Date: Wed, 24 Jun 2015 02:15:44 -0500
From: David Schinazi <dschinazi at apple.com>
To: v6ops at ietf.org
Cc: Vividh Siddha <vividh at apple.com>
Subject: Re: [v6ops] Apple and IPv6, a few clarifications

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. device will get new
addresses and could possibly switch between address families

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 <dschinazi at 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