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

Owen DeLong <owen@delong.com> Thu, 25 June 2015 19:09 UTC

Return-Path: <owen@delong.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 80F421ACD09 for <v6ops@ietfa.amsl.com>; Thu, 25 Jun 2015 12:09:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.111
X-Spam-Level:
X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 BqZWx5nqihBD for <v6ops@ietfa.amsl.com>; Thu, 25 Jun 2015 12:09:44 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 844161ACCD8 for <v6ops@ietf.org>; Thu, 25 Jun 2015 12:09:44 -0700 (PDT)
Received: from delong-dhcp203.delong.com (delong-dhcp3 [192.159.10.203]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.2) with ESMTP id t5PJ8EwH010114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Jun 2015 12:09:41 -0700
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <558BC5AF.3060406@gmail.com>
Date: Thu, 25 Jun 2015 12:08:14 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A95A912-FC46-4D61-9AB1-8D8E4D33AC89@delong.com>
References: <E1C235B5-1421-4DAF-A2F3-F963982233DF@apple.com> <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <558ABAC3.4010802@gmail.com> <4F519538-0706-4BBA-9508-3E59F7A8BB62@nestlabs.com> <558BC5AF.3060406@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/DW4m-mW8Lz0ZsY3I785DFAjQ7Zw>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Apple and IPv6, a few clarifications - ND proxy for bridging hotspots
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: Thu, 25 Jun 2015 19:09:45 -0000

> On Jun 25, 2015, at 02:11 , Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
> 
> 
> 
> Le 24/06/2015 20:38, james woodyatt a écrit :
>> On Jun 24, 2015, at 07:12, Alexandru Petrescu
>> <alexandru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com>>
>> wrote:
>>> 
>>> […] 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. […]
>> 
>> I suspect the point you may be missing here is the logic encoded
>> elsewhere in iOS that restricts the use of Mobile Internet Sharing
>> to the telephony uplink. It is not possible with iOS to share
>> Internet access over the Wi-fi (or other interfaces) with tethered
>> devices. Only the telephony data service is eligible for Mobile
>> Internet Sharing.
> 
> That is a good point.
> 
> There is an ongoing technical debate in the car comm community - should
> the smartphone provide Internet connectivity to the car?  Or should the
> smartphone use the Internet connectivity offered by the car.

The car community should not be making this decision.

The car _AND_ the smartphone should be delivered in such a way that the
end user can choose whichever plan best suits his needs and offers him the
best set of tradeoffs between features, price, and whatever else the end user
chooses to care about.

If I want the phone to provide the connectivity to the car, I should be able
to do that.

If I want the car to provide connectivity and have the phone use that, I should
be able to do that.

I should be able to choose and I should be able to change my decision whenever
it suits me.

> 
> Right now where I live a large number of marketed cars are on the first
> option.  It is on that option that I think smartphone's iOS Mobile
> Internet Sharing can help, provided it does more than NDproxy.

For most of the marketed cars I am aware of in the US where that is the
case, it is largely because the car doesn’t really know what a network is
in any meaningful way, or, because the car maker didn’t want to think about
solving the connectivity problem in a useful way.

I do not know of a case where it is a well thought out decision by the
manufacturer to have that as a deliberate architecture rather than just
laziness at best.

Owen