From: Roland Bless [mailto:[email protected]]

all that I'm proposing is to use a stable internal addressing for the onboard
network (no matter how the car is currently connected to the Internet)
and to use a security gateway/proxy when communication to the Internet
is somehow required.

WEG] ok this is a good bit clearer, apologies for not picking up more specifics 
of the application the first time. However, I think that this basically ends up 
being two separate networks, independent of any address separation that may be 
implemented. If anything on the local network needs to talk to the outside 
world, even for peer to peer (vehicle to vehicle) interactions, it talks to the 
Bluetooth/cellular/wifi/RFC6214 compliant module, which has both internal and 
external interfaces. Rather than forward the traffic directly, it then proxies 
the request out to the outside world as necessary. Even if you use that module 
as a security device instead of a proxy, where the end nodes can communicate 
through it to get outside, you could use the fact that IPv6 supports multiple 
IP addresses per interface to (temporarily?) add an address for only those 
modules expected to talk to the outside world out of whatever external GUA 
prefix is delegated to the comms module, and the rest k
 eep only the ULA to talk on the car network.

What's unclear to me is why the in-car networks can't use the exact same prefix 
for every single copy of the network, regardless of manufacturer, model, etc? 
If there's an external mediation device to handle occasional external network 
communication, and the rest of the network is expected to be closed (save maybe 
access from the Ethernet port that replaces the OBD-II port used by the 
technician to talk to the computer), why are we worried about conflicting 
addresses between manufacturers, etc? Are you also looking to derive some 
information about manufacturer, serial number, etc from the address and don't 
have enough bits to represent it uniquely? Couldn't that be solved 
independently of the address?

Alternatively, there is nothing stopping you from writing a BCP or 
informational draft that identifies a recommended ULA numbering hierarchy for 
$industry (like for example the auto industry) to use in numbering in-vehicle 
private networks such that the appropriate information is maintained and there 
is reasonable assurance of uniqueness by dint of mutual adherence to the 
standard - all of them start with FC00:: but what you do with the rest of that 
/7 is mainly up to the implementer, and only locally significant. Rather than a 
registry, simply define a way to determine reasonable uniqueness 
algorithmically so that newcomers can derive their address. You can even use 
parts of the address to identify major and minor categories, sensors, 
actuators, etc. Maybe it's something as simple as numerically representing the 
ascii value of the brand name. And this is likely a value that would never need 
to change for the life of the car, regardless of what happens to the entity 
that orig
 inally produced it.

Hope that my comments are helpful...

Wes George


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to