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

Hi David,

Thanks for working towards supporting the IPv6-only carrier case!

Not all visited operators can yet be relied on to allow dual-stack or even IPv6-only bearers.
Does it support fallback to an IPv4-only bearer when data roaming?

Also could you clarify what the position will be with VPN support?

Ross

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