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 sofiane Imadali wrote: > 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 <rog...@gmail.com> 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 >> <sofiane.imadali.i...@gmail.com> 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 >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> -- >> >> Roger Jorgensen | ROJO9-RIPE >> rog...@gmail.com | - IPv6 is The Key! >> http://www.jorgensen.no | ro...@jorgensen.no > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
