Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots

[Alexandru Petrescu <[e-mail]>]

Hi, thanks for the reply.

Le 24/06/2015 09:15, David Schinazi a écrit :
> 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

I looked at the file. It does proxy Neighbor Discovery in order to
bridge. Proxy ND is an EXPERIMENTAL RFC4389. 64share is an
INFORMATIONAL RFC7278. This means they are not the perfect way to aim
for interoperability. An Apple smartphone could not talk to a GM car
(just examples of brand names).

In the car use-case the smartphone connects to the dashboard using a ptp
link.  And it's the car's dashboard which offers a WiFi hotspot.  These
couldn't be bridged (ND proxy) by the smartphone alone, it would need
the dashboard router to participate in this ND proxy.

What the smartphone needs is to route with longest-prefix matching and 
use different prefixes on each interface.  That is an interoperable way 
to connecting different subnets, and the RFCs are typically on the Stds 
Track (not INFORMATIONAL, nor EXPERIMENTAL).

Isn't the car use-case important for Apple smartphones?

(I mention car use-case because I work on these these days, but the
discussion of ND proxy is much older and it originated in a home context
with cable ISP and IPv6).

> It supports creating multiple hotspots at the same time, such as
> Wi-FI and Bluetooth and bridges them.

But insecurely.  Bluetooth and WiFi have different security mechanisms.
  The security mechanisms wouldn't bridge.

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

I agree.

Alex

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