Re: Vehicle's VIN in IPv6.

George Michaelson <ggm+ietf@apnic.net> Thu, 31 March 2011 08:44 UTC

Return-Path: <ggm+ietf@apnic.net>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE613A6AFA for <ipv6@core3.amsl.com>; Thu, 31 Mar 2011 01:44:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level:
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7UIXbi74Lzw for <ipv6@core3.amsl.com>; Thu, 31 Mar 2011 01:44:19 -0700 (PDT)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 4AE2D3A6AFD for <ipv6@ietf.org>; Thu, 31 Mar 2011 01:44:09 -0700 (PDT)
Received: from dhcp-54ae.meeting.ietf.org (dhcp-54ae.meeting.ietf.org [130.129.84.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id CB627B681F for <ipv6@ietf.org>; Thu, 31 Mar 2011 18:45:44 +1000 (EST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Vehicle's VIN in IPv6.
From: George Michaelson <ggm+ietf@apnic.net>
In-Reply-To: <AANLkTintFks2OmnfcnUKah8omAEHgiY8BzVhCxL=bD99@mail.gmail.com>
Date: Thu, 31 Mar 2011 10:45:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C53621C2-41A0-4818-8E01-377A5468DD8D@apnic.net>
References: <5C4A2B87ED124653A9BDEDAC14D6F2C8@sparrow> <AANLkTintFks2OmnfcnUKah8omAEHgiY8BzVhCxL=bD99@mail.gmail.com>
To: ipv6@ietf.org
X-Mailer: Apple Mail (2.1084)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 31 Mar 2011 08:44:20 -0000

There is a general model here which will re-occur many many times.

manufacturers have context-specific serial numbers which behave in context like EUI164.

It is reasonable (from their perspective) to ask if there is an address management function which can suit their context, to exploit IPv6. Perhaps a private overlay network for IPSEC trusted remote upload and download. re-blow your SONY TV on any Internet via a trust path homed inside the manufacturer. 'ET call home' models of device management.

I believe we have to have this discussion, but can I point out that global address policy lies in many places, only some of which are held in IETF Mailing lists.

So, a decision to establish a registry which spans outside of the private domain, and touches into global-unicast behaviours really has to be far, far wider than 'here'

It has to encompass the RIR process, basically. Or, clarify why its not in that model/space.

128 bits is a higher trust. we have to run this in the wider public interest. We currently hold ourselves to a tiny footprint for a reason, but that reason doesn't EXCLUDE this discussion, it certainly informs it.

-George (personal capacity)

On 31/03/2011, at 10:40 AM, Scott Brim wrote:

> Hello Radek.
> 
> I have privacy concerns, because the VIN is permanent for the vehicle.
> I suspect there is a good chance that the vehicle's IP address will
> not be used just for diagnostics, but also for general purpose
> connections to the Internet (for example fetching a movie for the
> children).  If an IP address is based on VIN, then it will never
> change, ever.  It will be possible for observers to build up
> information about what the vehicle's users like to connect to.
> 
> Also, if you are a diagnostic center and you receive packets from an
> IP address claiming to have a particular VIN number, how do you
> authenticate it?  How do you know that is really the vehicle it claims
> to be?  You will need application layer authentication in any case.
> 
> I believe it would be much better to decouple "vehicle identification"
> from "IP layer location" (the IP address).  These tokens have
> different purposes.  The vehicle identification is for use with
> database applications and diagnostic applications, while the IP
> address is for IP forwarding to know how to reach the vehicle.  You
> could possibly allow the vehicle to connect to the network and get any
> IP address -- any address at all -- and then connect to the diagnostic
> center and tell you its VIN and authenticate, all in a higher layer
> protocol.
> 
> 2011/3/30 Radek Wróbel <radoslaw.wrobel@pwr.wroc.pl>:
>> Dear 6man!
>> My name is Radek Wrobel, I'm writing from Poland (I'm working in Wroclaw
>> University of Technology, Division of Car Vehicles and Combustion
>> Engines). With this idea I wrote to IANA and Leo Vegoda redirected me to
>> you.
>> Vehicle / mechanic engineers are working on a new On Board Diagnosis
>> standard for vehicles (http://en.wikipedia.org/wiki/On-board_diagnostics).
>> Today EOBDv1 can diagnose (quasi online) 849 failures. One of most important
>> advantage of EOBDv2 (but not only it) will be constant, real time
>> communication with service. The best way of them will be indyvidual number
>> for every car vehicles in the world. This number ought to cooporate with
>> global networking - TCP/IP (IPv6). All cars have indyvidual number - VIN
>> (17 characters which indicates on a country of production  and mark of the
>> car: digits and letters A-X). Maybe there is time when someone must think
>> about conversion VIN to IPv6 (like it's in local IPv4)? I've a few ideas
>> about it and of course I can share them if you will be intersting in.
>> Also we cooperate with VW and Toyota. I think they will be interesting about
>> it too.
>> Best regards, Radek Wrobel.
>> +48660406004
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> 
>> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------