Subject: Vehicle's VIN in IPv6.

From: Radek Wróbel <[email-masked]>
Date: Wed, 30 Mar 2011 17:31:56 +0200

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

---

From: Scott Brim <[email-masked]>
Date: Thu, 31 Mar 2011 10:40:12 +0200

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 <[email-masked]>:
> 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.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

---

From: George Michaelson <[email-masked]>
Date: Thu, 31 Mar 2011 10:45:39 +0200

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)

---

From: Roland Bless <[email-masked]>
Date: Thu, 31 Mar 2011 11:03:33 +0200

Hi Radek,

On 30.03.2011 17:31, Radek Wróbel wrote:
> 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.

There is already related work for this.
You should be aware of a US Patent of 2005 "Method for Setting an
Internet Protocol Address using a vehicle identification number".
US 2005/0273505 A1, first hit
http://www.google.com/patents?q=VIN+IPv6&btnG=Search+Patents
(no comment on its usefulness here...)
BMW has also recently filed a patent application with a VIN7 to IPv6
address mapping.
It's not totally clear to me what _problem_ you want to solve.
Depending on that several options exist.
However, I share the concerns that Scott Brim already expressed in his
mail.

Regards,
 Roland

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 31 Mar 2011 11:07:56 +0200

Dear all,

I fail to see why a VIN would be mapped to an IPv6 address as much as I 
fail to see why a passport number would be mapped to an IPv6 number. As 
said by Scott, the purpose of the IP address is to forward packets to 
the destination.

Such an idea is going against location privacy. To address the location 
privacy issue related to the ID of the vehicle used at the networking 
layer, the Car-to-Car Communication Consortium propose to use 
pseudonyms; when it goes to IPv6 communications (all communications are 
not IP-based) this pseudonym is used to configure an IPv6 address, i.e. 
a transient address (you can check the work of the SeVeCom project). In 
the meantime, the vehicle also has a permanent address (indeed, prefix) 
as which the vehicle is reachable (using NEMO). Up to now, there is no 
one in any of the standardisation or consortium I know (ETSI TC ITS, ISO 
TC204, ISO TC22, CEN TC278, Car2Car Communication Consortium) who is 
thinking about mapping a vehicle ID to the IPv6 address.

So, I'm afraid this idea is going nowhere.

Regards,
Thierry Ernst.

On 31/03/11 10:40, Scott Brim wrote:
> 2011/3/30 Radek Wróbel<[email-masked]>:
>> Dear 6man!

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Mar 2011 22:10:29 +1300

I rather like the thought that each BMW will need its own BGP4
advertisement. Boeing tried that for a while with airplanes, and
it didn't work out too well.

    Brian

---

From: Scott Brim <[email-masked]>
Date: Thu, 31 Mar 2011 11:12:14 +0200

> 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…

An overlay sure.  One could use IPv6 addresses the way back-to-my-Mac
does.  But I would like it to be clear that

  Internet location

and

  Endpoint identification for use by applications

are totally different functions and in the long run everything is
easier if they are kept separate.  It's taken us 20 years to get to
the point where we might be able to separate them.  Let's help others
not go through the same learning experience.

---

From: George Michaelson <[email-masked]>
Date: Thu, 31 Mar 2011 11:16:00 +0200

On 31/03/2011, at 11:12 AM, Scott Brim wrote:

> easier if they are kept separate.

I *think* I'd do a 'no disagree +1' on that, but maybe thats another conversation.

>  It's taken us 20 years to get to

Like I said, the conversation is going to happen, and we have to face their expectations. I think its being done individually, industrial sector by sector. My first introduction was the smart whitegoods sector, washing machines and the like. I had no exposure to the car segment but its clear high-value goods attract 'smart' solutions labels like flies to honey.

I don't think "go away" is the right answer. I think "your model has flaws" is closer.

The key message is that if they apply for patents in it (BMW) they clearly see dollar-signs and its very hard to trump money.

-G

---

From: Bob Hinden <[email-masked]>
Date: Thu, 31 Mar 2011 11:32:08 +0200

Brian,

> it didn't work out too well.

BGP is overkill :-)  I thought the problem with the Boeing service was largely financial, their BGP based technical solution did work.  At least the number of commercial airplanes isn't too large a number.

They could use a fixed car address and use mobile IPv6 with a provider based address.  

Bob

---

From: Scott Brim <[email-masked]>
Date: Thu, 31 Mar 2011 11:33:37 +0200

> I don't think "go away" is the right answer. I think "your model has flaws" is closer.

Someone (IAB? ISOC?) needs to publish something to the world about
separation of functions, and the perils of mixing locators and
identifiers.  We can help write it.

> The key message is that if they apply for patents in it (BMW) they clearly see dollar-signs and its very hard to trump money.

Hadn't thought of that.  Hm.

Scott

---

From: Roland Bless <[email-masked]>
Date: Thu, 31 Mar 2011 11:38:56 +0200

Hi Thierry,

> fail to see why a passport number would be mapped to an IPv6 number. As

There may be scenarios where it may be useful to uniquely address
a particular car, e.g., for (remote) diagnosis, remote unlocking
services etc. However, doing this by statically mapping the VIN to an
IPv6 address (either into the IID part or the network prefix part)
is for several reasons not a great idea.

> Such an idea is going against location privacy. To address the location

Yep.

Regards,
 Roland

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 31 Mar 2011 11:40:01 +0200

> They could use a fixed car address and use mobile IPv6 with a provider based address.
This is what the intend to do:

  Slides presented at the ITU Fully Networked Car Workshop may be of 
interest to you.

  Convergence of car connectivity

Bernadette Villeforceix (Orange) and Stéphane Petti (Orange)

http://www.itu.int/dms_pub/itu-t/oth/06/41/T06410000700002PDFE.pdf

Regards,
Thierry Ernst.

---

From: Roland Bless <[email-masked]>
Date: Thu, 31 Mar 2011 12:03:23 +0200

Hi George,

> I don't think "go away" is the right answer. I think "your model has

Yep. Given the huge IPv6 address space, some manufacturers are tempted
to use the IPv6 address as identifier.

> The key message is that if they apply for patents in it (BMW) they
> clearly see dollar-signs and its very hard to trump money.

I'm not speaking for BMW nor defending them,
but maybe it's not the $$$ directly rather than the
usual patent competition between vendors:
they probably wanted to have filed something before any
other vendor, so that they can have a royalty free
negotiation later on...

Regards,
 Roland

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 31 Mar 2011 12:08:51 +0200

Le 30/03/2011 17:31, Radek Wróbel a écrit :
> 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).

Thanks for the pointer, I am discovering OBD.  We are also interested in
wireless usage of IP within the vehicle, with off-the-shelf links (i.e.
consumer electronics market wifi, bluetooth, ant) together with OBD if
needed.

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

Excellent requirement to IP.

> 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

Hmm... sounds as good idea.  But there may be several IP addresses
within a vehicle, one for the obu, one for map device, etc.

In case one would like to map VIN to an IPv6 address one would consider
first an Interface Identifier of the IPv6 address. (rightmost 64 bits).

Interface Identifier is about an Interface, and I am not sure VIN is
about an interface, or is it. (like Interface is the Ethernet interface
of this pc).

> (like it's in local IPv4)?

Hmm..?  What do you mean?  Has VIN been mapped to some reserved IPv4
address?

> I've a few ideas about it and of course I can share them if you will
> be intersting in.

Well definitely I am interested to hear what the idea is about and what
the mapping could look like.

I am interested on everything about how to connect vehicles (cars,
buses, trains) to the Internet with IPv6.

FYI, the MEXT working group has discussed several times about vehicles
ans Internet, with protocol Mobile IPv6 and various extensions.  A
number of people are actively involved.  A specific "vehicular reqs"
draft exists expired in MEXT, as well as some solution individual drafts
(non wg item) for v2v communications.

Alex

> 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 [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Roland Bless <[email-masked]>
Date: Thu, 31 Mar 2011 12:26:46 +0200

Hi Alexandru,

> consumer electronics market wifi, bluetooth, ant) together with OBD if

See below.

> Excellent requirement to IP.

Maybe to some mapping system, but not directly to IPv6
(ID/Loc split).

> about an interface, or is it. (like Interface is the Ethernet interface

Yes, but from a security point of view, it would be a nightmare
if some hacker could directly send IP packets to the ECU controlling
your airbag or other safety relevant ECUs etc. So a strong
security architecture is a MUST. I'm not sure that there is a need
to _directly_ address any internal car devices. A security gateway
as policy enforcement point seems to be required at least.

Regards,
 Roland

---

From: Nathan Ward <[email-masked]>
Date: Thu, 31 Mar 2011 23:43:31 +1300

> it didn't work out too well.

My laptop has an address based on the physical network interface's MAC address, which is used over a tunnel to Apple for Back to my Mac. It doesn't do BGP4, obviously, and I assume it works well.
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
        inet6 fe80::217:f2ff:fed5:a13%utun0 prefixlen 64 scopeid 0x8 
        inet6 fd00:6587:52d7:20:217:f2ff:fed5:a13 prefixlen 64 

Perhaps something a bit more relevant to IETF is generating a ULA prefix from a VIN?

---

From: Scott Brim <[email-masked]>
Date: Thu, 31 Mar 2011 13:15:48 +0200

> They could use a fixed car address and use mobile IPv6 with a provider based address.

That would help.  A rendezvous point (e.g. home agent) always helps to
protect confidentiality. Plus a firewall to protect the
always-out-of-date vehicle software.   They can work out how to do
path optimization later.

---

From: Scott Brim <[email-masked]>
Date: Thu, 31 Mar 2011 13:18:27 +0200

> Perhaps something a bit more relevant to IETF is generating a ULA prefix from a VIN?

If these addresses will never be used for anything except diagnostics
and internal communications, then okay, but this looks like a classic
case of a net that is going to start out with just local use, and soon
move to needing global addresses.  Hey, I know, NAT.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 31 Mar 2011 05:28:42 -0700 (PDT)

I think the idea here is to use VIN as link layer id when assigning an 
address/prefix to a host in the car. The host can provide such an id in DHCP 
request message.

Regards,

Behcet

> Dear all,
> 
> I fail to see why a VIN would be mapped to an IPv6 address as  much as I fail 
>to see why a passport number would be mapped to an IPv6 number.  As said by 
>Scott, the purpose of the IP address is to forward packets to the  destination.
> 
>privacy issue related to the ID of the vehicle used at the  networking layer, 
>the Car-to-Car Communication Consortium propose to use  pseudonyms; when it goes 
>to IPv6 communications (all communications are not  IP-based) this pseudonym is 
>used to configure an IPv6 address, i.e. a transient  address (you can check the 
>work of the SeVeCom project). In the meantime, the  vehicle also has a permanent 
>address (indeed, prefix) as which the vehicle is  reachable (using NEMO). Up to 
>now, there is no one in any of the standardisation  or consortium I know (ETSI 
>TC ITS, ISO TC204, ISO TC22, CEN TC278, Car2Car  Communication Consortium) who 
>is thinking about mapping a vehicle ID to the IPv6  address.
> 
>important
> >> Also we  cooperate with VW and Toyota. I think they will be interesting 
>about
> >>  it too.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 31 Mar 2011 14:52:47 +0200

hmm... sounds as there would be a VIN-specific link layer? (not ieee 
ethernet, not usb, not bluetooth)?  Which is that?

Alex

---

From: Brian Haberman <[email-masked]>
Date: Thu, 31 Mar 2011 08:59:37 -0400

> from "IP layer location" (the IP address).  These tokens have

This made me immediately think of HIP with the VIN being used as the
Host Identifier.

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Thu, 31 Mar 2011 15:02:08 +0200

Dear all.

For Internet connectivity of vehicles, the use of IPv6 (with mobility
support, NEMO) is being fully considered at some standardization
organizations such as ISO and ETSI. But, I totally disagree with the
use of IPv6 as a permanent ID of a vehicle, i.e., VIN, because

1) This breaks the layered architecture concept.
2) This causes security issues, especially location privacy.

For, the comments from Behcet, plz see inline.

On Thu, Mar 31, 2011 at 2:28 PM, Behcet Sarikaya
<[email-masked]> wrote:
> address/prefix to a host in the car.

The ITS station architecture being considered at ISO and ETSI defines
that a vehicle ITS station must implement at least three entities such
as the gateway, router, and host. The mobility support for Internet
connectivity, i.e., NEMO, is in the router forming the in-vehicle
network where hosts of the vehicle ITS station are attached.

So, the use of link layer ID as the VIN does not make sense.

In addition, the link layer ID for the router of vehicle is changed
frequently, e.g., randomly generated ID is used for preventing
location tracking. Even the security mechanism developed for securing
the vehicle ITS station adopts an approach of pseudonym, i.e.,
certificate not including any identical information of vehicle and
vehicle's owner and use in a given short time.

Cheers.

The host can provide such an id in DHCP

-- 
IMARA Team, INRIA, France.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com || jong-hyouk.lee (at) inria (dot) fr
#webpage: https://sites.google.com/site/hurryon/

---

From: Roland Bless <[email-masked]>
Date: Thu, 31 Mar 2011 15:02:41 +0200

Hi,

> Perhaps something a bit more relevant to IETF is generating a ULA prefix from a VIN?

That could indeed be useful.
In the German SEIS project we are considering to use IPv6
internally for communication between ECUs in cars. For such internal
use this may help indeed a lot. It's a different story for external
connectivity.

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Thu, 31 Mar 2011 15:10:16 +0200

Hi Scott,

> move to needing global addresses.  Hey, I know, NAT.

We are currently designing a security architecture for cars
that use IPv6 for their internal communications. For this
internal communication, you may use this ULA-like prefix.
If external connectivity is required (which will be the case),
this may happen by dedicated ALGs or proxies, making sure
that the safety-critical internal communications is not
affected adversely. Filtering traffic would be easier
using something like ULAs. Direct, unauthorized access to the ECUs
is therefore unwanted and unlikely.

Regards,
 Roland

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 31 Mar 2011 15:52:00 +0200

Le 31/03/2011 12:26, Roland Bless a écrit :
>> Thanks for the pointer, I am discovering OBD.  We are also
>> interested in wireless usage of IP within the vehicle, with
>> off-the-shelf links (i.e. consumer electronics market wifi,
>> bluetooth, ant) together with OBD if needed.
>
> See below.
>
>>> 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.
>>
> Maybe to some mapping system, but not directly to IPv6 (ID/Loc
> split).

I quickly get confused on id/loc split discussions.  I meant to say that
it is wonderful to request Internet to let a vehicle connect to it
anywhere in the world and, moreover, solution should not be exclusively 
satellite.

>>> (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
>>
>> In case one would like to map VIN to an IPv6 address one would
>> consider first an Interface Identifier of the IPv6 address.
>> (rightmost 64 bits). Interface Identifier is about an Interface,
>> and I am not sure VIN is about an interface, or is it. (like
>> Interface is the Ethernet interface of this pc).
>
> Yes, but from a security point of view, it would be a nightmare if
> some hacker could directly send IP packets to the ECU controlling
> your airbag or other safety relevant ECUs etc. So a strong security
> architecture is a MUST.

I agree, appropriate security is useful.  What's ECU? (other than the
currency).

> I'm not sure that there is a need to _directly_ address any internal
> car devices. A security gateway as policy enforcement point seems to
> be required at least.

For entertainment, passengers may like to youtube without policy
enforcement, i.e. all laptops in the vehicle be each IP-addressable.

In other cases, only the OBU would be IP-addressable and it would be
connect on its ingress interface to rs232/can devices (but it would
still need a 2nd IP address on that interface).

Alex

> Regards, Roland

---

From: Bob Hinden <[email-masked]>
Date: Thu, 31 Mar 2011 16:19:42 +0200

> always-out-of-date vehicle software.   They can work out how to do

I agree.  If you put the "home agent" in the middle of the internet (for some value of middle), then path optimization probably isn't that important.

Bob

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 31 Mar 2011 07:34:09 -0700 (PDT)

I meant something like DUID.

--b

>fail
>layer,
>the

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Thu, 31 Mar 2011 16:34:20 +0200

Dear all.

Plz, see inline.

>>> They could use a fixed car address and use mobile IPv6 with a provider based address.

Clearly, not Mobile IPv6, the correct one is NEMO able to form the
in-vehicle network wherein hosts, e.g., electronic control units, can
attach through IPv6 addresses.

> I agree.  If you put the "home agent" in the middle of the internet (for some value of middle), then path optimization probably isn't that important.

No. The routing performance in terms of NEMO, i.e., IPv6 data packets
destined to hosts attached to a vehicle, should not be solved by
locating the home agent in a proper location at the Internet. It
should be approached by thinking of how network prefix being used in
the in-vehicle network, i.e., mobile network prefix in terms of NEMO,
is provisioned.

Cheers.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 31 Mar 2011 16:53:13 +0200

Le 31/03/2011 16:19, Bob Hinden a écrit :
>> On Thu, Mar 31, 2011 at 11:32, Bob Hinden<[email-masked]>
>> wrote:
>> That would help.  A rendezvous point (e.g. home agent) always
>> helps to protect confidentiality. Plus a firewall to protect the
> I agree.  If you put the "home agent" in the middle of the internet
> (for some value of middle), then path optimization probably isn't
> that important.

Makes some sense.  This "middle" depends on latency; and core network
has an order of magnitude (sometimes 2) less than even the first hop to
vehicle.

That means that it may suffice to put the HA on wired link, anywhere in
the Internet, and relatively close (in terms of hopcount) to where the
handover is about to take place.  And not necessarily put it where eg
akamai stuff sits.

Alex

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Thu, 31 Mar 2011 17:02:25 +0200

Hi, Alex.

Plz, see inline. I fully failed to understand your words.

> has an order of magnitude (sometimes 2) less than even the first hop to

In the context of ITS communication, how do you expect the movement of
vehicles? Then, how do you decide the location of home agent for
reducing the routing performance for user data packets destined to
hosts attached to the router of a vehicle?

> handover is about to take place.

In the context of this thread, Bob mentioned about the routing
performance, exactly saying user data packets' routing performance,
not saying handover latency mainly consisted of 1) movement detection
at IP level; 2) address configuration; and 3) location update (BU/BA)
to the home agent.

Cheers.

And not necessarily put it where eg

---

From: Jared Mauch <[email-masked]>
Date: Thu, 31 Mar 2011 11:14:48 -0400

On Mar 31, 2011, at 8:52 AM, Alexandru Petrescu wrote:

> hmm... sounds as there would be a VIN-specific link layer? (not ieee ethernet, not usb, not bluetooth)?  Which is that?

This is the same question I have.  What is the communications phy that will interface with the outside world?  I'm sure it's going to be something where there is an existing bit of hardware that requires a ieee ethernet/mac or other addressable interface.  seems like the VIN would be best put in a datagram transmitted over that phy.

- Jared

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 31 Mar 2011 17:37:06 +0200

Le 31/03/2011 17:02, Jong-Hyouk Lee a écrit :
>>>> On Thu, Mar 31, 2011 at 11:32, Bob
>>>> Hinden<[email-masked]> wrote:
>>>>>
>>>> helps to protect confidentiality. Plus a firewall to protect
>>>> the always-out-of-date vehicle software.   They can work out
>>>> how to do path optimization later.
>>>
>>> I agree.  If you put the "home agent" in the middle of the
>>> internet (for some value of middle), then path optimization
>>> probably isn't that important.
>>
>> Makes some sense.  This "middle" depends on latency; and core
>> network has an order of magnitude (sometimes 2) less than even the
>>  first hop to vehicle.
>
> In the context of ITS communication, how do you expect the movement
> of vehicles?

Right, mouvement of private vehicles is unpredictable.  Some common
sense may reduce the space to, say, mostly a continent.  And even some
vehicles like trains have very highly predictable trajectories.

Not only ITS should be considered, but also operators of public
transportation networks (if they're not already part of it).

> Then, how do you decide the location of home agent for reducing the
> routing performance for user data packets destined to hosts attached
>  to the router of a vehicle?

The direct seller of vehicle (concessionnaire, garage) may decide to
host HA relativley close (geo terms) to where the vehicle is owned,
suffices HA to be on wire instead of wireless, which is rather natural.
  The parts manufacturer too.  The transportation operator, etc.

The common wisdom of needing to host a webcache closer in order to
deliver data quicker to http clients assumes the http clients use wire
too (as the servers do).  The latency difference between pc's wire and
server's wire is much smaller than between server's wire and wireless.

>> That means that it may suffice to put the HA on wired link,
>> anywhere in the Internet, and relatively close (in terms of
>> hopcount) to where the handover is about to take place.
>
> not saying handover latency mainly consisted of 1) movement
> detection at IP level; 2) address configuration; and 3) location
> update (BU/BA) to the home agent.

Right, I didn't mean handover performance.

Routing performance... hmm... I believe there is not much routing
performance gain when trying to bring HA as close as possible to the
handover place.

Alex

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Thu, 31 Mar 2011 18:00:57 +0200

Hi, Alex.

Please, come back to a person who I know. See inline.

>  The parts manufacturer too.  The transportation operator, etc.

Ummm...let me explain a little thing about the use of home agent (HA)
in the context of ISO and ETSI. The HA is located at the central ITS
station that must be maintained by authorized organization, i.e.,
belonging to the government. Such private companies will not have
permissions to install the HA; might be possible for only private
company's client, but this is not the case we're talking here.

> server's wire is much smaller than between server's wire and wireless.

Come on. I don't really know why you bring this text here.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 31 Mar 2011 22:14:59 +0200

Le 31/03/2011 18:00, Jong-Hyouk Lee a écrit :
>>>>>> That would help.  A rendezvous point (e.g. home agent)
>>>>>> always helps to protect confidentiality. Plus a firewall to
>>>>>> protect the always-out-of-date vehicle software.   They can
>>>>>> work out how to do path optimization later.
>>>>>
>>>> network has an order of magnitude (sometimes 2) less than even
>>>>  the first hop to vehicle.
>>>
>>> In the context of ITS communication, how do you expect the
>>> movement of vehicles?
>>
>> Right, mouvement of private vehicles is unpredictable.  Some
>> common sense may reduce the space to, say, mostly a continent.  And
>> even some vehicles like trains have very highly predictable
>> trajectories.
>>
>>> Then, how do you decide the location of home agent for reducing
>>> the routing performance for user data packets destined to hosts
>>> attached to the router of a vehicle?
>>
>> The direct seller of vehicle (concessionnaire, garage) may decide
>> to host HA relativley close (geo terms) to where the vehicle is
>> owned, suffices HA to be on wire instead of wireless, which is
>> rather natural. The parts manufacturer too.  The transportation
>> operator, etc.
>
> Ummm...let me explain a little thing about the use of home agent
> (HA) in the context of ISO and ETSI. The HA is located at the central
> ITS station that must be maintained by authorized organization,
> i.e., belonging to the government.

Hmm... yes that can be done.  Some governments are even Cert Auth, but
that does not prevent other private organizations to be CA.

> Such private companies will not have permissions to install the HA;
> might be possible for only private company's client, but this is not
>  the case we're talking here.

Ah I see, I agree.

But I am still curious to understand the lines of VIN-v6 proposal
before discarding it. In the process maybe I (or someone else) get a
chance to suggest some alternative... to satisfy some requirement,
some problem statement.

Alex

>> deliver data quicker to http clients assumes the http clients use
>> wire too (as the servers do).  The latency difference between pc's
>>  wire and server's wire is much smaller than between server's wire
>>  and wireless.
>
>>> performance, exactly saying user data packets' routing
>>> performance, not saying handover latency mainly consisted of 1)
>>> movement detection at IP level; 2) address configuration; and 3)
>>>  location update (BU/BA) to the home agent.
>>
>> performance gain when trying to bring HA as close as possible to
>> the handover place.
>>
>> Alex
>>>
>>> Cheers.
>>>
>>>>
>>>> IETF IPv6 working group mailing list [email-masked]
>>>> Administrative Requests:
>>>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 01 Apr 2011 10:29:14 +1100

>clearly see dollar-signs and its very hard to trump money.

=> I don't think it's as organised as you might think. People apply for
patents all the time for a wide range of reasons and they don't
necessarily reflect dollar signs.

We've seen people from ITU suggest we embed IPv6 addresses in phone
numbers ....etc before. The same type of education about
locator/application identifier separation is needed here.

Hesham