Subject: Re: I-D Action: draft-imadali-its-vinipv6-viid-00.txt

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 28 Mar 2013 17:37:10 +0100

Sorry for the late reply.

Le 19/02/2013 22:08, joel jaeggli a écrit :
> On 2/19/13 12:40 PM, Alexandru Petrescu wrote:
>>
>>
>> I think I may need to actually better expose the problem: how to form
>> IPv6 addresses for vehicles. (yes we know these already exist: DHPCv6,
>> PRefix Delegation on cellular, stateless autoconf, NAT, NPT, 64share).
>>
> One of the questions I have in that context what special property of
> cars make them need a new method?

Well they're different than Ethernet interfaces.  One could have several 
Ethernet interfaces in a single car.  And, cars have their globally 
unique space of identifiers which is not EUI-48.

When one tries to make an IPv6 addressing architecture for vehicles one 
goes into planning which could quickly overcome the space of IPv6.

There are very many hurdles to a simple straightforward IPv6 address 
planning for vehicles.

1 - At most 2^78 vehicles may exist.

     There may be not enough space in IPv6 addressing architecture space
     to uniquely distinguish between all past current and future
     vehicles.

     Theoretically, the total number of vehicles possible is given by
     interpreting the semantics of VIN (17 "digits", some holding
     max 33 values, others less).  Under optimistic interpretations, a
     trivial 1-to-1 conversion from VIN "characters" space to bit-space
     of an IPv6 address leads to 78bits.

     (the structure of VIN is :
              1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |   WMI  |        VDS      |         VIS           |
             +--------+-----------------+-----------------------+
      but more details on the net searching Vehicle  Identification
      Numbers)

     It's hard to imagine that the first 78 bits of an IPv6 address
     designate one particular vehicle.  The IPv6 address structure
     ofers something like a maximum of 61bits to designate one
     particular subnet.  And, in a vehicle there is often more than one
     subnet.

2 - the prefixes obtained from Registries, or from ISP (which one
     should I try first?) may come with a price tag.  The more vehicles,
     the pricier the allocation.

3 - prefixes which are provider-assigned  and/or provider independent
     may introduce routing churn in the core of the Internet - if these
     prefixes are numerous.

For these reasons, we still look closely at the use of ULAs (instead of 
globally routable prefixes) and at how to generate these ULAs meaningfully.

Alex

>> Alex
>>
>>>
>>> Doug
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list [email-masked] Administrative
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Mar 2013 14:24:17 -0400

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
    Alexandru> 2 - the prefixes obtained from Registries, or from ISP (which one
    Alexandru> should I try first?) may come with a price tag.  The more vehicles,
    Alexandru> the pricier the allocation.

Depending upon the way in which the VIN->subnet ID is formed, it might
be that each manufacturer should actually go and acquire a /28 or
something from their local RIR.  That would be one way. 
The RIRs might find that they want to adjust their policies and talk to
IANA, allocate this out of a Non-Connected Network space.  

That would be, from the IETF point of view, the easiest way to do this.
Creating the subnetID could in fact be manufacturer proprietary, and the
document would just be a BCP on how not to do it wrong.

It would likely be, from the RIR and automotive industry, a complex way,
because I think neither RIR community nor automative community
knows or understands each other.

A different way would be for the IETF to instruct IANA to create a NCN
space, and designate the VIN-mapping as a part of it.  This would be
harder for the IETF to do, but would I think, lead to a better world.

    Alexandru> 3 - prefixes which are provider-assigned  and/or provider independent
    Alexandru> may introduce routing churn in the core of the Internet - if these
    Alexandru> prefixes are numerous.

you have confused globally routable with globally unique.
These prefixes are simply *NOT* going to be announced in the core of the
Internet.  If they *are*, it will be a manufacturer doing so, and and
using one of many tunneling technologies to get the packets to the right
place (whether it be IPsec, IPIP, MobileIPV6, GRE, or IP-over-Acoutistic
Carrier).

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Bob Hinden <[email-masked]>
Date: Thu, 28 Mar 2013 11:51:43 -0700

Alexandru,

On Mar 28, 2013, at 9:37 AM, Alexandru Petrescu <[email-masked]> wrote:

> Well they're different than Ethernet interfaces.  One could have several Ethernet interfaces in a single car.  And, cars have their globally unique space of identifiers which is not EUI-48.
> 
> When one tries to make an IPv6 addressing architecture for vehicles one goes into planning which could quickly overcome the space of IPv6.
> 
> There are very many hurdles to a simple straightforward IPv6 address planning for vehicles.
> 

That's a lot of vehicles.  It is 302,231,454,903,657,000,000,000 to be exact.  The current world population is currently a little over 7 billion (7,075,000,000).  Assuming a few orders of magnitude of population growth and ownership of multiple vehicles per person, that still much much much smaller than 2^78.  I don't we need to worry about handling 2^78 vehicles.  Where does that number come from?

>    to uniquely distinguish between all past current and future

Likewise, I don't think we need to deal with past vehicles.  We do need to deal with the active vehicles that are likely to be on the Internet.

Bob

> For these reasons, we still look closely at the use of ULAs (instead of globally routable prefixes) and at how to generate these ULAs meaningfully.
> 
> Alex
> 
>>> Alex
>>> 
>>>> 
>>>> Doug
>>>>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 28 Mar 2013 19:29:05 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexandru Petrescu

> goes into planning which could quickly overcome the space of IPv6.

Just out of curiosity, why not use DNS to solve this problem? Isn't that how these things are normally handled?

You can use the VIN, or you can use the owner's name/address/etc., along with an added way of indentifying a system or component, to create a number of unique identifiers a car might need. It would be nice if each car had just one, but more than likely, each subsystem will need its own IP address and DNS record. Then you use whatever IPv6 prefix makes sense at the time, possibly dependent on location. The 64-bit (or whatever length) IIDs can be chosen in any of the usual optional ways.

Like all IPv6, this does not preclude also using ULAs. But for example, just like OnStar systems are able to do, it will continue to make sense to allow a stable way to reach each car.

The DNS approach makes it possible to reuse IIDs for cars in different parts of the world.

Or, we can insist that cars have a single IPv6 interface, and that all internal components are addressed in a standard way, using subheaders in the data payload. I just don't think that will fly, though.

Bert

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 29 Mar 2013 10:59:27 +0100

Le 28/03/2013 19:51, Bob Hinden a écrit :
>>>> I think I may need to actually better expose the problem: how
>>>> to form IPv6 addresses for vehicles. (yes we know these already
>>>> exist: DHPCv6, PRefix Delegation on cellular, stateless
>>>> autoconf, NAT, NPT, 64share).
>>>>
>>> One of the questions I have in that context what special property
>>> of cars make them need a new method?
>>
>> Well they're different than Ethernet interfaces.  One could have
>> several Ethernet interfaces in a single car.  And, cars have their
>>  globally unique space of identifiers which is not EUI-48.
>>
>> When one tries to make an IPv6 addressing architecture for vehicles
>> one goes into planning which could quickly overcome the space of
>> IPv6.
>>
> That's a lot of vehicles.  It is 302,231,454,903,657,000,000,000 to
> be exact.

YEs, that's a lot of potential vehicles; likewise: 2^128 is a lot of
computers potentially connected to IPv6 Internet.

> The current world population is currently a little over 7 billion
> (7,075,000,000).  Assuming a few orders of magnitude of population
> growth and ownership of multiple vehicles per person, that still
> much much much smaller than 2^78.  I don't we need to worry about
> handling 2^78 vehicles.

That sounds reasonable.  Just to note that VIN addressing space does not
prohibit that many unique vehicles to exist.

> Where does that number come from?

This 2^78 comes from the simplest interpretation, total use, and most
straighforward conversion of VIN space of 'digits' to binary space.

(The addresing space VIN - Vehicle Identification Number is fixed-length
17 'digits'.  Each of the 8 leading digits can represent 33 distinct
values, the 9th digit 10 values, and so on (interpretations of these
digits are publicly available).  It makes up for 33^3 * 33^5 * 10 * 30 *
33^3  x 10^4.  Approximately 78bits are necessary to represent this
space; different interpretations of the digits of VIN (how we read the
standards), may lead to different results.)

>> There may be not enough space in IPv6 addressing architecture
>> space to uniquely distinguish between all past current and future
>> vehicles.
>>
>
> Likewise, I don't think we need to deal with past vehicles.  We do
> need to deal with the active vehicles that are likely to be on the
> Internet.

I could agree that common sense and other factors should be taken into
account, if one needs a means to convert VIN space to IPv6 addressing
space.  Simply because 78bit is too much of what IPv6 could accommodate.

And although it's obvious to many that common sense should be involved,
there is currently no clear idea (or I haven't seen?) about what IPv6
addresses should one put in vehicles.

Should each vehicle hold a /64? a /48?

Should vehicle manufacturer request a /48 from the RIR to deploy in
vehicles?  From the ISP?  A PI or PA address?

Or should vehicle manufacturer self-generate  ULAs for all its vehicles?

Or all?

If one tries to make a recommendation about this, one needs to
understand various needs from manufacturer, as well as the existing
addressing schemes for vehicles (not necessarily IPv6): how VIN is used,
how IPv4 is used in vehicles, etc.

Alex

>> interpreting the semantics of VIN (17 "digits", some holding max 33
>> values, others less).  Under optimistic interpretations, a trivial
>> 1-to-1 conversion from VIN "characters" space to bit-space of an
>> IPv6 address leads to 78bits.
>>
>> (the structure of VIN is : 1  2  3  4  5  6  7  8  9 10 11 12 13 14
>> 15 16 17 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | WMI
>> |        VDS      |         VIS           |
>> +--------+-----------------+-----------------------+ but more
>> details on the net searching Vehicle  Identification Numbers)
>>
>> designate one particular vehicle.  The IPv6 address structure ofers
>> something like a maximum of 61bits to designate one particular
>> subnet.  And, in a vehicle there is often more than one subnet.
>>
>> should I try first?) may come with a price tag.  The more
>> vehicles, the pricier the allocation.
>>
>> 3 - prefixes which are provider-assigned  and/or provider
>> independent may introduce routing churn in the core of the Internet
>> - if these prefixes are numerous.
>>
>> For these reasons, we still look closely at the use of ULAs
>> (instead of globally routable prefixes) and at how to generate
>> these ULAs meaningfully.
>>
>> Alex
>>
>>>> Alex
>>>>
>>>>>
>>>>> Doug
>>>>>
>>>> IETF IPv6 working group mailing list [email-masked]
>>>> Administrative Requests:
>>>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 29 Mar 2013 11:23:33 +0100

Le 28/03/2013 20:29, Manfredi, Albert E a écrit :
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>
>> When one tries to make an IPv6 addressing architecture for
>> vehicles one goes into planning which could quickly overcome the
>> space of IPv6.
>
> Just out of curiosity, why not use DNS to solve this problem? Isn't
> that how these things are normally handled?

Well, it depends how one sees the VIN - Vehicle Identification Number.

I could agree that a VIN could be used to identify applications, or
services.  There are current works about converting VIN to a FQDN.
Something like this: the VIN VMP3565AXT3MD4460 is mapped into
gaslevel.T3MD4460.3565AX.VMP.vehiclebrand.fr

Remark the conversion is not straightforward.  A selection was performed
on the fields of the VIN; other people may select differently.

> You can use the VIN, or you can use the owner's name/address/etc.,
> along with an added way of indentifying a system or component, to
> create a number of unique identifiers a car might need. It would be
> nice if each car had just one, but more than likely, each subsystem
> will need its own IP address and DNS record.

Yes, many things are possible, in addition to using VIN.  And yes, I
agree each subsystem in the vehicle may need its own IP address and DNS
record.  And within each vehicle there are many such subsystems.

> Then you use whatever IPv6 prefix makes sense at the time, possibly
> dependent on location.

Well at many locations where vehicles could connect to Internet, the
cellular connections are used (less often WiFi and/or satcom).

The cellular connections deliver one address, but not a set of addresses.

Thus one needs a prefix from a 'home' anchoring point.

That doesn't solve the problem - the home still needs to decide which
prefix to tell the vehicle to assign to its computers.  What IPv6
prefixes make sense to deploy in vehicles?  Should it be PI or
PA?  Or ULA?  How big the prefix length request should be, and requested
to whom? Is a vehicle a Site?  Or is the grouping of vehicles an entire
Site?

Moreover, although that may connect the vehicle to Internet, if each
vehicle did so, then direct V2V communication would be highly
inefficient - even impossible at times (each would have to connect its
home first).

> The 64-bit (or whatever length) IIDs can be chosen in any of the
> usual optional ways.

Yes, there exist various ways to configure the IID, mostly in
relationship with interface hardware identifiers.

One potential other way would be in relationship with VIN - that's what
this draft is about. (but the VIN could be used to generate ULAs as
well, the other draft).

> Like all IPv6, this does not preclude also using ULAs.

Right, we are looking now at using ULAs.  If one tries to generate ULAs
by following the RFC, it gives an example in which they suggest using an
EUI-64 in the algorithm.  But they dont say _whose_ interface's EUI-64.
  A choice could be made among the importance of various PCs in the car,
but then why not choosing the obvious.

> But for example, just like OnStar systems are able to do, it will
> continue to make sense to allow a stable way to reach each car.

I believe OnStar is the equivalent of eCall in Europe(?)

If so, then this a single computer in the vehicle which has a single
job, and which has a single IPv4 address.  If there is other computer in
the vehicle it doesn't connect to the Internet via eCall - it must not.

With IPv6 we look at having several such computers in the vehicle and
each one of them to be reachable from the Internet directly, no
application gateways, but yes secured.

> different parts of the world.

Provided that DNS-updates are feasible for large numbers of vehicles
highly mobile, or that 'triangular' long-distance DNS requests can be
tolerated.

> Or, we can insist that cars have a single IPv6 interface, and that
> all internal components are addressed in a standard way, using
> subheaders in the data payload. I just don't think that will fly,
> though.

Right, I dont think it would fly either.  Advanced IPv4 cars of today
already have many IPv4 addresses inside the car, no need of subheaders
like Source Route.  Just that these dont scale to many cars, because
IPv4 not enough addresses left.

Thanks,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 29 Mar 2013 11:32:43 +0100

Le 28/03/2013 19:24, Michael Richardson a écrit :
> Alexandru> 2 - the prefixes obtained from Registries, or from ISP
> (which one Alexandru> should I try first?) may come with a price tag.
> The more vehicles, Alexandru> the pricier the allocation.
>
> Depending upon the way in which the VIN->subnet ID is formed, it
> might be that each manufacturer should actually go and acquire a /28
> or something from their local RIR.  That would be one way.

Yes it could be one way to be considered.

At that consideration, one should think whether 38bits is enough to put
more than one /64 in each other vehicle of that manufacturer, for that
length of time.

> The RIRs might find that they want to adjust their policies and talk
> to IANA, allocate this out of a Non-Connected Network space.

Ok.

> That would be, from the IETF point of view, the easiest way to do
> this. Creating the subnetID could in fact be manufacturer
> proprietary, and the document would just be a BCP on how not to do it
> wrong.
>
> It would likely be, from the RIR and automotive industry, a complex
> way, because I think neither RIR community nor automative community

I agree.  It looks procedural and long.  If this was discussed elsewhere
previously (like IANA/RIR lists?) I am interested to look.

> A different way would be for the IETF to instruct IANA to create a
> NCN space, and designate the VIN-mapping as a part of it.  This would
> be harder for the IETF to do, but would I think, lead to a better
> world.

NCN?  Non-Connected Networks?  That is another name for ULA space no?

> Alexandru> 3 - prefixes which are provider-assigned  and/or provider
> independent Alexandru> may introduce routing churn in the core of the
> Internet - if these Alexandru> prefixes are numerous.
>
> you have confused globally routable with globally unique. These
> prefixes are simply *NOT* going to be announced in the core of the
> Internet.

Well, confusion may have crept in, sorry if so.

I understand ULA space is not to be announced in the core of the Internet.

I understand PA Provider-Assigned addresses are to be announced in the
core of the Internet.

I understand PI Provider-Independent prefixes are to be announced at
several places, but still restricted (not 'anywhere'), yet be reachable
in the Internet.  (these restrictions are clear at RIR; e.g. it can only
be /48 not shorter, unless exceptions to be documented; and more other
clear restrictions).

> If they *are*, it will be a manufacturer doing so, and and using one
> of many tunneling technologies to get the packets to the right place
> (whether it be IPsec, IPIP, MobileIPV6, GRE, or IP-over-Acoutistic
> Carrier).

Hm...

Alex

---

From: Fernando Gont <[email-masked]>
Date: Fri, 29 Mar 2013 06:20:04 -0300

On 03/28/2013 01:37 PM, Alexandru Petrescu wrote:
[....]
>     to uniquely distinguish between all past current and future

[Disclaimer: I'm completely illiterate when it comes to this whole 'VIN'
thing]

That said, IPv6 addresses identify network attachment points. If you
need semantics other than that ("e.g., distinguish between past,
current, and future vehicles"). my take is that you're looking at the
wrong place, possibly at the expense of nodes that do the right thing.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Michael Richardson <[email-masked]>
Date: Sat, 30 Mar 2013 22:54:09 -0400

>> be harder for the IETF to do, but would I think, lead to a better

    Alexandru> NCN?  Non-Connected Networks?  That is another name for ULA space no?

Possibly.

ULA-Random is one half of the space.  No registration, no structure, no ownership.
ULA-Central is one proposal on what to do with the other half of ULA
space, and it might involve registration, it might have structure, and
it might have ownership.  ULA-Central could be a source of NCN space.

Or ICANNs could allocate a /12 for NCN space, or RIRs could each
allocate an /12 for for NCNs, or an RIR could allocate a /13 of an
existing /12, or some other more complex or subtle way.

    >> prefixes are simply *NOT* going to be announced in the core of the

    Alexandru> Well, confusion may have crept in, sorry if so.

    Alexandru> I understand ULA space is not to be announced in the core
    Alexandru> of the Internet. 

    Alexandru> I understand PA Provider-Assigned addresses are to be announced in the
    Alexandru> core of the Internet.

You are now confusing address classes with policies encouraged by RIRs,
also what a sender does and what how a receiver acts.   We can, at the
IETF never really "forbid" a sender from sending... rather we generally
write rules as to how a receiver acts when it receives valid or invalid
signals.  

So, it's not that "ULA space is not to be announced", it's that
"announcements that include ULA space SHOULD be ignored".  
It's a subtle distinction, because it explains that the decision about
what to do with address space is a decision made by mutually consenting
ISPs..

So, yes, unless things go horribly wrong, ULAs will be rejected by very
common policy, and we hope never to see them on the public default-free
zone.  Given the size of IPv6 space, and the challenge of auditing where
leaked ULA traffic might be coming from,  I hope that we will not see
ULAs in use in any place where there is administrator that could have
chosen something better.

PI (and even PA space) will generally be accepted by ISPs, provided a
number of other conditions are satisified; the SIDR WG has protocols to
cryptographically validate some of those conditions.    (as an example
of PA space, I've announced a /48 of PA space to another ISP in order to
multihome an ISP) 

There is no requirement for any set of addresses to be announced at all.
Second, there are in fact no rules what an ISP can and can not accept.

RIRs go to some lengths to make it clear that the address space that an
entity gets is not guaranteed to be routable...