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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Mon, 22 June 2015 20:08 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762AD1ACD24 for <v6ops@ietfa.amsl.com>; Mon, 22 Jun 2015 13:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVQt6p4IOZe6 for <v6ops@ietfa.amsl.com>; Mon, 22 Jun 2015 13:08:03 -0700 (PDT)
Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA481ACDFA for <v6ops@ietf.org>; Mon, 22 Jun 2015 13:08:03 -0700 (PDT)
Received: from [127.0.0.1] (unknown [82.229.156.225]) by smtp4-g21.free.fr (Postfix) with ESMTP id C535E4C80E7; Mon, 22 Jun 2015 22:07:30 +0200 (CEST)
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
To: Owen DeLong <owen@delong.com>
References: <E1C235B5-1421-4DAF-A2F3-F963982233DF@apple.com> <5587EFDD.6030807@gmail.com> <7075A962-5B82-4922-B037-AF71D2591C5F@delong.com>
Message-ID: <55886B02.80604@gmail.com>
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: <7075A962-5B82-4922-B037-AF71D2591C5F@delong.com>
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: <http://mailarchive.ietf.org/arch/msg/v6ops/npwJtVZS7t2Y7jO2WDLk-xf2SMc>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=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
>> <alexandru.petrescu@gmail.com> 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