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

Alexandru Petrescu <> Mon, 22 June 2015 20:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 762AD1ACD24 for <>; Mon, 22 Jun 2015 13:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.017
X-Spam-Level: **
X-Spam-Status: No, score=2.017 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_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iVQt6p4IOZe6 for <>; Mon, 22 Jun 2015 13:08:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4FA481ACDFA for <>; Mon, 22 Jun 2015 13:08:03 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTP id C535E4C80E7; Mon, 22 Jun 2015 22:07:30 +0200 (CEST)
From: Alexandru Petrescu <>
To: Owen DeLong <>
References: <> <> <>
Message-ID: <>
Date: Mon, 22 Jun 2015 22:07:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 150501-0, 01/05/2015), Outbound message
X-Antivirus-Status: Clean
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 20:08:05 -0000

On 22/06/2015 19:01, Owen DeLong wrote:
>> On Jun 22, 2015, at 04:22 , Alexandru Petrescu
>> <> 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"
>> 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

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 

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

To be seen.


> Owen

L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.