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

[Alexandru Petrescu <[e-mail]>]

On 22/06/2015 19:01, Owen DeLong wrote:
>
>> 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.

Yes.  It can bridge those which are bridgeable.

Bridging point-to-point bluetooth link to the dashboard and the
broadcast WiFi car hotspot is not working.

Safety and entertainment subnets in a car which must not be bridged for
reliability reasons (don't noise the safety messages) - is not working 
either zith 64share.

Bridging Bluetooth and WiFi ha no link-layer security.

> If the phone wants to treat them as routed interfaces, then it
> breaks.

Yes, 64share breaks in routed subnets.

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

Well, one cellular network operator has a /47 to 'share' with all its
customer UEs.  If that operator gave a /48 to an UE it could satisfy 
only 2 such customers, not millions.

> but at least provide enough subnets to cover BT, USB, 2.4, and 5Ghz
> plus some headroom for future applications.

I agree, headroom should be provided.

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

Because the DHCPv6 Prefix Delegation is a userspace application
implementing a protocol - suffices it to compile on each of these
code bases.  It acts the same everywhere.

It's not a GUI, or some kernel module, or some AF-dependent software.

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

I think I didnt read the message as you did.

I assume by 2001::/64 is meant actually 2001::/3, or some other
2001:X:Y:U:Z::/64 that the operator prodived.  I think it was said
2001::/3 to distiguish from ULA fd00::/something, and so I said it made
sense.

And, if what is said is really meaning 2001::/64 then I agree with you -
that's at IANA and one wouldn't juggle with 2001::/64 just like that.
If one wants to juggle with something then it's with fd00::/64
(ULA) and with 2001:db8::/32 (docu prefix).

>>> *) 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 [...] about dual-stack and
> Apple should pull their head out [...] about 464XLAT, but either one
> would meet my immediate needs.

I wouldnt put it that blunt.  But I would agree that less transitioning 
be faster transition.

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

I think I agree with you.  I am very happy one particular operator leads 
with IPv6 deployment in a successful way.  But I am very unhappy that 
operation is taken blindly as an example by other operators.  It has 
drawbacks.

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

To be seen.

Alex

>
> Owen
>
>


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com