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

[Tore Anderson <[e-mail]>]

Hello David,

First of all, let me say that the news from WWDC is very exciting, and
I hope your strategy proves successful. With some luck, your approach
of forcing app developers to write IPv6-capable code will also
indirectly benefit the other platforms too.

I have some follow-up questions though, see in-line:

* David Schinazi

> *) 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.

And if the cellular network is IPv6-only? Does the tethered WLAN become
IPv6-only too? If so, I can imagine that this would cause IPv4
compatibility issues for older Apple devices without the new
Bump-in-the-API stuff, as well as for non-Apple devices attaching to
the tethered WLAN.

Hopefully this is not something that will put network operators off
from provisioning IPv6(-only) connectivity to the Apple devices on
their network...

> *) 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.

One thing that is not clear to me, is if what happens if the app
developer's server is dual-stacked. For example, if the DNS entries are
as follows:

www.example.com. IN A 192.0.2.1
www.example.com. IN AAAA 2001:db8::1

...what exactly happens when the iOS node on the NAT64 testing WLAN
attempts to access it? Obviously, as there is no connectivity to
2001:db8::1, native IPv6 towards the "IN AAAA" record cannot work.

Does the DNS64 in the OS X host consider "::/0" as part of the Special
Exclusion Set (cf. RFC6146 s5.1.4), causing it to ignore the upstream
AAAA record and perform DNS64 synthesis instead, e.g., returning this
to the tethered host:

www.example.com. IN A 192.0.2.1
www.example.com. IN AAAA 2001::192.0.2.1

Or will it simply return the upstream DNS records verbatim (i.e., not
performing any DNS64 synthesis), and rely on the Happy Eyeballs
implementation in the iOS node to quickly figure out that the
2001:db8::1 address is unreachable and fail over to 192.0.2.1 (at which
point the Bump-in-the-API can kick in and perform local translation to
2001::192.0.2.1)?

Or perhaps something else entirely?

> *) 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.

Does this mean that if the app is using socket directly, but in a
correct and IPv6-supporting way, to either:

1) communicate with dual-stacked hostnames (assuming ::/0 is not in the
DNS64's Special Exclusion Set as per what I wrote earlier), or
2) directly to an IPv6 literal address (think for example peer-to-peer
applications/protocols that do not use DNS to begin with),

..will then any tests for correct IPv6-only app behaviour the developer
performs on the NAT64 network fail, even though the app is doing
everything right?

A related question: Will the test system that validates App Store
submissions for correct IPv6-only behaviour have full access to the
entire IPv6 Internet, ensuring that apps such as the above will be
approved, even though they might not work correctly behind an OS X
NAT64-only test network?

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

Great! Let me add my voice to this: Please ensure that IPv6 is
consistently preferred over IPv4, if both protocols work equally
well/fast (or roughly so). Only fall back on IPv4 it is clear that IPv6
is performing *significantly* worse than IPv4, or not at all. See
RFC6555 s4.1.

Tore