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

[Alexandru Petrescu <[e-mail]>]

Hi,

Thanks for the report.  I have a few comments.

Le 19/06/2015 23:46, David Schinazi a écrit :
[...]
> *) 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.

The way of sharing a prefix with the Wi-Fi Clients is supposedly the one
documented in RFC7278 "Extending an IPv6 /64 Prefix from a Third
Generation Partnership Project (3GPP) Mobile Interface to a LAN Link"
https://tools.ietf.org/html/rfc7278

That is straightforward to implement yet it does have some drawbacks.

The most important drawback of 64share IMHO is that the smartphone can 
not make two hotspots simultaneouly: one on WiFi and one on Bluetooth. 
Or otherwise one on WiFi5GHz and one on WiFi2.4GHz.  Or several subnets 
in a car connected with an Apple phone to the Internet.  Because it is 
impossible to share a unique /64 prefix to more than just one subnet.

It is better to tell the operator to provide a /63 to smartphones (not a
/64), with DHCPv6 Prefix Delegation.  That will fix it.

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

If you get done the above then you get Internet Sharing on the Mac Today
as well, for free.

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

Makes sense.

Alex

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