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

[🔓Dan Wing <[e-mail]>]

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

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.

-d


> 
> *) 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] <mailto:[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
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops