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

Alexandru Petrescu <> Fri, 26 June 2015 15:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6DE311B3087 for <>; Fri, 26 Jun 2015 08:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.983
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3QYhui3fecRO for <>; Fri, 26 Jun 2015 08:01:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A9551B307C for <>; Fri, 26 Jun 2015 08:01:14 -0700 (PDT)
Received: from ( []) by (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 (localhost []) by localhost (Postfix) with SMTP id 8E530204D7C; Fri, 26 Jun 2015 17:04:08 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 7F498204B9E; Fri, 26 Jun 2015 17:04:08 +0200 (CEST)
Received: from [] ( []) by (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: <>
Date: Fri, 26 Jun 2015 17:01:08 +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
To: Owen DeLong <>
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 - ND proxy for bridging hotspots
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: 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 <> wrote:
>> Le 24/06/2015 20:38, james woodyatt a écrit :
>>> On Jun 24, 2015, at 07:12, Alexandru Petrescu
>>> < <>>
>>> 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 

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.


> Owen