Subject: Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs

From: sofiane Imadali <[email-masked]>
Date: Wed, 20 Feb 2013 18:14:32 +0100

Hi,
Thanks for your interest Roger, your question is very pertinent and I
wanted to share it with the group (hope you don't mind bringing this
offlist mail to the list).

Indeed, one needs to understand the context before understanding the
possible uses of the method.

First, a bit of state of the art that couldn't appear in the drafts.
VIN is not a private information. It is meant to be public. I gave a
list of ISO specifications that say exactly How a VIN is built, Where
it should appear, How to reverse engineer it. In a nutshell, the VIN
is alphanumeric, it appears on your wind shield, and you can break it
down to 3 pieces: the manufacturer ID, the vehicle's description, and
the vehicle ID.

     - What networking questions/perspectives should these VIN-related
data trigger  ?
     - Today in a closed operator domain, the vehicle (Mobile Router)
can generate a ULA prefix for site-scoped communications. It is
subject to collisions if used on a large number of vehicles (10^4 or
more - RFC4193). In the vehicular context you're facing this
limitation.
For applications such as remote diagnosis, or other services
(involving access to in-vehicle Machines), the solution we propose
allows to create a predictable (deterministic manner) unique
(collision-free) prefix, that in a closed loop (operator domain,
manufacturer domain) allows you to determine which vehicle to access
with which prefix: No DNS, No Prefix Delegation, No DHCPv6, nor any
other additional artefact involved.
Again, with this proposal, if you are an operator/manufacturer with a
list of your vehicles fleet, you can determine a list of ULA prefixes
to access each one of them: No additional protocol involved, no
collisions.

     - What applications can be enabled by the use of this kind of
VIN-based Prefixes and IDs ?
     - This also answers the question of regarding those 2 proposals
only from a privacy-concerns standpoint. Vendor web-based apps where
you give a VIN code and  returns the history of a vehicle already
exists. When selling your car, a buyer can look up your VIN in a
database and get a history of car accidents, repairs ...etc all
related to your vehicle. This is no science-fiction, it has already
been used in the US for quite a while. Here is on example googling the
keywords (second hand car VIN history):
http://www.edmunds.com/car-buying/vin-check.html

     - About the privacy concerns.
     - I am no expert in the field of privacy. I do understand the
concerns though, and this is why I chose to trigger them in the draft
and in my research work before it is evoked in the mailling list. My
humble opinion about the subject is that we should not mistake VIN for
a MAC. Not compare them, and not apply blindly the concepts of MAC
randomization for VIN-based IIDs/Prefixes. The compromise of
(Uniqueness/randomization And Privacy) that is studied and
standardized in RFC 4941 for IID, should not directly apply to VIN
with no regard to the nature of the object we are using. Please have a
look at: http://en.wikipedia.org/wiki/VIN_Etching, which should inform
you more about another possible application of VIN (in general, not
just networking) which is car theft prevention, to understand why
*your VIN is a public good and not a private property that you buy
with your car*.

To sum up; in order not to trigger (too soon) the privacy concerns and
be blocked by that, the primal use case (domain, site) would be a
closed operator network, or car manufacturer in the manufacture
(closed loop). This method allows us to set internal routing to access
the in-vehicle devices, by a deterministic manner: VIN --> ULA prefix.
No additional protocol is needed to do that. Any service provided by
this devices (monitoring vehicle state for example) is a use case that
applies to this addressing approach.

Thanks for reading and feedback;
Cheers
Sofiane

On Mon, Feb 18, 2013 at 11:11 PM, Roger Jørgensen <[email-masked]> wrote:
> Hi,
>
> What I wonder about is why we need this, what are the usecases and the
> _intention_ behind these two draft from you?
>
> just... why?
>
>
> The reason I ask is that I try to understand it, and see if the
> privacy option is a real concern in _your_ context or not.
>
>
>
> --- Roger J ---
>
> On Mon, Feb 18, 2013 at 7:49 PM, sofiane Imadali
> <[email-masked]> wrote:
>> Hello 6MAN folks,
>>
>> I would like to announce, on behalf of the co-authors, the submission
>> of 2 drafts relating to VIN-based IPv6 addressing.
>> VIN stands for Vehicle Identification Number, and it is specifically
>> used in a context of IPv6 vehicular communications. These proposals
>> aim at providing discussion about a new mapping/conversion method from
>> VIN to ULA prefixes (guaranteed unique) and Interface Identifiers.
>>
>> Please find the above mentioned documents at:
>> 1) Vehicle Identification Number-Based IPv6 Interface Identifier
>> (VIID), at: http://tools.ietf.org/html/draft-imadali-its-vinipv6-viid-00
>> 2) Vehicle Identification Number-Based Unique Local IPv6 Unicast
>> Addresses (VULA), at:
>> http://tools.ietf.org/html/draft-imadali-its-vinipv6-vula-00
>>
>> Your comments are welcome,
>>
>> Cheers,
>> Sofiane.
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>
>
> --
>
> Roger Jorgensen           | ROJO9-RIPE
> [email-masked]          | - IPv6 is The Key!
> http://www.jorgensen.no   | [email-masked]

---

From: Roger Jørgensen <[email-masked]>
Date: Wed, 20 Feb 2013 23:03:03 +0100

> offlist mail to the list).

no I don't mind, I'll comment on your answer inline

<snip>
> to access each one of them: No additional protocol involved, no

I don't think it's  clear enough in the draft that we're talking about
closed circuit system, not communicated initiated from within the car
to outside, any outside device  including other cars. The case of
accessing the car's network from a service point of view are still
inside the car's domain.

Am I understanding this correct?

Another issue is the use of the term site, you could explain how you
are using that term.
I personal would consider any inner car communication to be within a
site, including when I connect my phone to the on-board media-system
to stream music or movie. Any communication toward outside the car are
out of the site.

<snip>
> applies to this addressing approach.

as said above, I understand those two draft to talk about inner car
communication, not communication toward _any_ device outside the car.
That include communication to other nearby cars, parking automate and
more.

Or to sum it up as I see it with regard to the privacy issue - the
issue is when the car, or someone in the car use an IP toward _any_
outside device that can be traced back to the VIN of any car
(vehicles).

> Thanks for reading and feedback;

no problem, good to get such a good explanation back :)

--

---

From: Ray Hunter <[email-masked]>
Date: Thu, 21 Feb 2013 11:01:36 +0100

A similar issue is likely to emerge with other mobile device - mobile
device communication,where there are a large number of mobile devices
circulating globally, but relatively few of them are present in any one
given area at any given time e.g. wearable computing, medical monitors,
RFID tags attached to small articles in transit, pet ID chips that warn
the owner if they stray......

IMHO it is a bad idea to define any sort of static mapping between L8
identifiers and L3/L2.

64 bits of IID are simply not going to be enough to encode adequate
semantics for all envisioned mobile applications.

SLAAC (using MAC as the universal seed) is almost certainly going to be
less likely to suffer collisions than any number of competing
industry-specific standards that overload the IID space.

IMHVO The industry should generate prefixes/addresses based on existing
standards, and then perform any dynamic VIN / Pet ID / L8 ID mapping via
some (industry-specific) protocol to identify the specific vehicle/ pet/
shirt as appropriate. There is perhaps a role here for the IETF to
assist in defining a L3<->L8 mapping protocol, especially for links with
rapidly changing members, and which includes an industry identifier and
an industry specific portion.

regards,
RayH