RE: Centrally assigned "ULAs" for automotives and other environments

"George, Wes" <wesley.george@twcable.com> Tue, 27 September 2011 17:40 UTC

Return-Path: <wesley.george@twcable.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC3B21F8CD7 for <ipv6@ietfa.amsl.com>; Tue, 27 Sep 2011 10:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.241
X-Spam-Level:
X-Spam-Status: No, score=-0.241 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bQRZHs4Gtkg for <ipv6@ietfa.amsl.com>; Tue, 27 Sep 2011 10:40:52 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 628FC21F8C21 for <ipv6@ietf.org>; Tue, 27 Sep 2011 10:40:52 -0700 (PDT)
X-SENDER-IP: 10.136.163.12
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.67,596,1309752000"; d="scan'208";a="263979726"
Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 27 Sep 2011 13:41:18 -0400
Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 27 Sep 2011 13:43:37 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: Roland Bless <roland.bless@kit.edu>
Date: Tue, 27 Sep 2011 13:43:36 -0400
Subject: RE: Centrally assigned "ULAs" for automotives and other environments
Thread-Topic: Centrally assigned "ULAs" for automotives and other environments
Thread-Index: Acx9L8CuFbXCKiRQQO+KX2vsPdQVbQABzFZg
Message-ID: <34E4F50CAFA10349A41E0756550084FB0FC21052@PRVPEXVS04.corp.twcable.com>
References: <4E81D15F.6090906@kit.edu> <CAL9jLaZLznsQo5doEa0upgwMQ06FqPLmYizGfb4i8ck7gu2QAw@mail.gmail.com> <4E81DB65.6010503@kit.edu> <34E4F50CAFA10349A41E0756550084FB0FA69D42@PRVPEXVS04.corp.twcable.com> <4E81F4FC.8000104@kit.edu>
In-Reply-To: <4E81F4FC.8000104@kit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 6man <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2011 17:40:53 -0000

From: Roland Bless [mailto:roland.bless@kit.edu]

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