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

Alexandru Petrescu <> Mon, 22 June 2015 11:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1A8FF1B2F78 for <>; Mon, 22 Jun 2015 04:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.283
X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G4TIm4W9O2IK for <>; Mon, 22 Jun 2015 04:22:12 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E48701ACE99 for <>; Mon, 22 Jun 2015 04:22:11 -0700 (PDT)
Received: from ( []) by (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5MBM9Ax020645 for <>; Mon, 22 Jun 2015 13:22:09 +0200
Received: from (localhost []) by localhost (Postfix) with SMTP id 3B3C9202A47 for <>; Mon, 22 Jun 2015 13:25:02 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 31CF4202A82 for <>; Mon, 22 Jun 2015 13:25:02 +0200 (CEST)
Received: from [] ( []) by (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5MBM5A8023656 for <>; Mon, 22 Jun 2015 13:22:09 +0200
Message-ID: <>
Date: Mon, 22 Jun 2015 13:22:05 +0200
From: Alexandru Petrescu <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Jun 2015 11:22:14 -0000


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"

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.


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