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

[Owen DeLong <[e-mail]>]

> On Jun 22, 2015, at 04:22 , Alexandru Petrescu <[e-mail]> wrote:
> 
> 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.

Not entirely true. True, you cannot have multiple subnets. This is true in any situation where the device in question receives only one /64 (unless you make absurd small subnets).

However, in the case of hotspot on 5, 2.4, and BT, as long as the phone can bridge them all together as a single subnet, that’s perfectly viable. If the phone wants to treat them as routed interfaces, then it breaks.

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

No… If you’re going to go to PD, a /63 is stupid. Ideally, use a /48, but at least provide enough subnets to cover BT, USB, 2.4, and 5Ghz plus some headroom for future applications.

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

Since iOS and OSX  are separate code bases, I’m not sure why you think that.

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

Not really… This address is currently in the IANA free pool. It could be
assigned to an RIR and then put on a real network at any point in the
future.

It would be much better to use a /64 Apple can set aside from their own space
or some other block of addresses registered for this purpose… Heck, worst
case, Apple could sign up for a free tunnel from HE and burn the /64
assigned to that tunnel.

Ideally, the prefix should be user configurable as well.

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

They really should support 464XLAT at this point IMHO, though some of
what they are doing may obviate or lessen the need. It will be interesting
to see if this is sufficient for T-Mo to finally turn on IPv6 for my phone.

Ideally, T-Mo should pull their head out of their ass about dual-stack and
Apple should pull their head out of their ass about 464XLAT, but either
one would meet my immediate needs. Unfortunately, they’re both sitting
there playing internet chicken waiting for the other one to blink.

Given the number of other cellular networks that are following the same
path as T-Mo, I think mass is on their side, but Apple may be too stubborn
to blink and a head-on may be inevitable.

Unfortunately, it’s the end-users that will be the victims in this crash, not
the drivers.

Owen