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

[Owen DeLong <[e-mail]>]

> On Jun 26, 2015, at 08:01 , Alexandru Petrescu <[e-mail]> wrote:
> 
> 
> 
> Le 25/06/2015 21:08, Owen DeLong a écrit :
>> 
>>> On Jun 25, 2015, at 02:11 , Alexandru Petrescu <[e-mail]> wrote:
>>> 
>>> 
>>> 
>>> Le 24/06/2015 20:38, james woodyatt a écrit :
>>>> On Jun 24, 2015, at 07:12, Alexandru Petrescu
>>>> <[e-mail] <mailto:[e-mail]>>
>>>> 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).

I disagree… HDMI provides some similar functionalities.

Many portable routers provide similar functionality in hotel rooms all over the place.

Apple’s airport products provide similar functionality.

There are MANY examples of similar functionality (albeit with a coarser UI) that abound.

For that matter, Internet Connection Sharing on MacOS X and Windows provides similar functionality.

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

You don’t need it. It’s a very simple independent selection in two devices worst case:

	Phone:
		Internet Source:			[Carrier [|Wifi 1[|Wifi2…]]]
		[share internet with			optional menu of wifi and/or other networks, possibly allowing multi-select]

	Car:
		Internet Source:			[Carrier [|Phone 1[|Phone 2…]]]
		[share internet with			optional menu of wifi and/or other networks, possibly allowing multi-select]

If you choose Carrier in both cases, then both will independently access the internet via their respective carriers.

If you choose the Car’s wifi on the phone and the phone’s wifi on the car, then you get what you would expect — a disconnected LAN.

Not rocket science to configure and not hard for the end user to understand IMHO.

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

Why is that a problem? That’s what DHCP-PD is for.

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

It’s a little bit (very tiny fraction) easier because one gets to implement a host instead of a router, but really not enough easier to be worth the loss in user functionality.

Heck, I can put everything needed together on a Raspberry PI for under $100 without writing any software of my own. 

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

See above… It’s already been met in the phone. The phone already has all the required functionality.
Why can’t the same functionality be implemented in a car with a larger form factor and greater power resources
with the ability to potentially support a larger codebase?

When did a more capable system become a bigger development challenge for basic functionality than
an embedded system? Somehow I missed the memo when that flip occurred.

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

See above… It’s not hard, it’s been done, there’s open source code to do it.

Owen