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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 26 June 2015 15:01 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 6DE311B3087 for <v6ops@ietfa.amsl.com>; Fri, 26 Jun 2015 08:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level:
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QYhui3fecRO for <v6ops@ietfa.amsl.com>; Fri, 26 Jun 2015 08:01:20 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9551B307C for <v6ops@ietf.org>; Fri, 26 Jun 2015 08:01:14 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t5QF1ALW003544; Fri, 26 Jun 2015 17:01:10 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8E530204D7C; Fri, 26 Jun 2015 17:04:08 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7F498204B9E; Fri, 26 Jun 2015 17:04:08 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t5QF18nq001537; Fri, 26 Jun 2015 17:01:10 +0200
Message-ID: <558D6934.5010608@gmail.com>
Date: Fri, 26 Jun 2015 17:01:08 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Owen DeLong <owen@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> <1A95A912-FC46-4D61-9AB1-8D8E4D33AC89@delong.com>
In-Reply-To: <1A95A912-FC46-4D61-9AB1-8D8E4D33AC89@delong.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/-WdMsJQxYn9K1oeh5OzjKm4Xh78>
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: Fri, 26 Jun 2015 15:01:22 -0000


Le 25/06/2015 21:08, Owen DeLong a écrit :
>
>> 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.

This is a great formulation of requirements but there is nothing else 
outside the car industry that did this kind of behaviour in the past. 
So it's not that easy to implement.  (typically a automated 
configuration is using RA/DHCP/NAT and these have a strong notion of 
directivity - client and server, provider and consumer; in the car 
setting you have two strongly opposed interests smartphone's and car's).

You dont have one protocol that can change roles dynamically.  A DHCP 
Server is a Server can't dynamically become a Client.  A NAT is in one 
direction cant dynamically change direction.

Worse - Internet addresses are centrally assigned and distributed, one 
can't make IP addresses out of nothing and reach the Internet 
bidirectionally.

That's why it's easier if a decision were made (one of the two provides 
Internet to the other).

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

This is very strong requirements and difficult to meet.

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

I wouldnt say laziness, some work hard at it, but it's not easy.

Alex

>
> Owen
>
>
>