Subject: [its] Thoughts on source IP addresses in ITS

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 Mar 2016 17:10:36 -0700

I've looked through draft-jeong-its-v2i-problem-statement and the 
background on ITS that was given at recent IETF plenary.

It seems like there are quite different performance expectations for 
different types of V2V and V2I which has an impact on what one might 
want to do in terms of IP address management.

Some use cases are about connecting to the Internet, where it seems like 
one would want a global IP address with some support for mobility. (But 
there are privacy considerations that probably mean we don't want to 
keep the IP address for a long time.) Using DHCP to assign such 
addresses might be reasonable.

But for some V2V and vehicle to roadside use cases the performance 
requirements might not allow for waiting for IP address assignment, 
while at the same time the communication is entirely local. In such a 
case there isn't a need for a global IP address. One could even argue 
that there is no need for an IP address at all if the purpose is to 
notify neighboring vehicles about a hazard or that I've slammed on the 
brakes.

One could potentially send such a packets using a link-local source 
address (and multicast them to a link-local group).
But that still requires having a link-local address, and concerns about 
privacy means we need to change that source address. But it wouldn't 
serve any purpose if the message is unidirectional.

I think we could consider sending such packets with the unspecified 
(all-zeros) IPv6 source address.
We typically don't use this (an exception is Duplicate Address 
Detection) but for local unidirectional traffic it is an option to 
consider if the performance/privacy of IP address assignment is an issue.

Regards,
    Erik

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 22 Mar 2016 20:07:50 +0900

Hi Erik,
These are good comments on IP address in V2I and V2V communications.
I will also address your comments on the revised version of
draft-jeong-its-v2i-problem-statement .

Thanks.

Best Regards,
Paul

On Tue, Mar 22, 2016 at 9:10 AM, Erik Nordmark <[email-masked]> wrote:

> different types of V2V and V2I which has an impact on what one might want
> to do in terms of IP address management.
>
> there are privacy considerations that probably mean we don't want to keep
> the IP address for a long time.) Using DHCP to assign such addresses might
> be reasonable.
>
> requirements might not allow for waiting for IP address assignment, while
> at the same time the communication is entirely local. In such a case there
> isn't a need for a global IP address. One could even argue that there is no
> need for an IP address at all if the purpose is to notify neighboring
> vehicles about a hazard or that I've slammed on the brakes.
>
> privacy means we need to change that source address. But it wouldn't serve
> any purpose if the message is unidirectional.
>
> We typically don't use this (an exception is Duplicate Address Detection)
> but for local unidirectional traffic it is an option to consider if the
> performance/privacy of IP address assignment is an issue.
>
> Regards,
>    Erik
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: Margaret Cullen <[email-masked]>
Date: Mon, 21 Mar 2016 22:13:32 -0400

On Mar 21, 2016, at 8:10 PM, Erik Nordmark <[email-masked]> wrote:
> 
> One could potentially send such a packets using a link-local source address (and multicast them to a link-local group).
> But that still requires having a link-local address, and concerns about privacy means we need to change that source address. But it wouldn't serve any purpose if the message is unidirectional.

> 
> I think we could consider sending such packets with the unspecified (all-zeros) IPv6 source address.
> We typically don't use this (an exception is Duplicate Address Detection) but for local unidirectional traffic it is an option to consider if the performance/privacy of IP address assignment is an issue.

I think a defined special-use global address (the same for everyone) would be better for this purpose, as it would not restrict the use of a multi-link network within the vehicle, or require the receiving stack to accept packets from the all-zeros address (which some stacks may not right now).

Margaret

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 22 Mar 2016 10:08:07 -0700

The vehicle-to-vehicle nomadic topology is exactly what the MANET
protocols (OLSR, AODV and ancillaries) cater to.  Whatever addressing
scheme picked should interface cleanly with those protocols.

On Tue, 2016-03-22 at 20:07 +0900, Mr. Jaehoon Paul Jeong wrote:
>         I've looked through draft-jeong-its-v2i-problem-statement and
>         the background on ITS that was given at recent IETF plenary.
>         
>         It seems like there are quite different performance
>         expectations for different types of V2V and V2I which has an
>         impact on what one might want to do in terms of IP address
>         management.
>         
>         Some use cases are about connecting to the Internet, where it
>         seems like one would want a global IP address with some
>         support for mobility. (But there are privacy considerations
>         that probably mean we don't want to keep the IP address for a
>         long time.) Using DHCP to assign such addresses might be
>         reasonable.
>         
>         But for some V2V and vehicle to roadside use cases the
>         performance requirements might not allow for waiting for IP
>         address assignment, while at the same time the communication
>         is entirely local. In such a case there isn't a need for a
>         global IP address. One could even argue that there is no need
>         for an IP address at all if the purpose is to notify
>         neighboring vehicles about a hazard or that I've slammed on
>         the brakes.
>         
>         One could potentially send such a packets using a link-local
>         source address (and multicast them to a link-local group).
>         But that still requires having a link-local address, and
>         concerns about privacy means we need to change that source
>         address. But it wouldn't serve any purpose if the message is
>         unidirectional.
>         
>         I think we could consider sending such packets with the
>         unspecified (all-zeros) IPv6 source address.
>         Detection) but for local unidirectional traffic it is an
>         option to consider if the performance/privacy of IP address
>         assignment is an issue.
>         
>         Regards,
>            Erik
>

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 22 Mar 2016 10:46:06 -0700

> I think a defined special-use global address (the same for everyone) would be better for this purpose, as it would not restrict the use of a multi-link network within the vehicle, or require the re…

Margaret.

I suspect we should first discuss the need before going to far down into 
implementation. I don't claim to understand the performance needs around 
IP address acquisition for ITS to know whether we need something 
different than DHCP+SLAAC.

But as a quick note, a global anycast source address that you suggest 
might have operational issues. For instance, you might think you can 
deliver ICMP errors back to that address, or traceroute towards it, but 
doing so leads to surprising results.

Presumably no stack should respond to an NS or ICMP echo to that 
address, which means it might need to be marked as 'anycast' in the 
stack. I haven't checked whether stacks allow such addresses to be used 
as a source.

Thanks,
    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 22 Mar 2016 10:45:39 -0700

> scheme picked should interface cleanly with those protocols.

Rex,

The descriptions I've read about some of the ITS use cases leads me to 
believe that for some of them a link-local multicast is appropriate were 
one node is sharing some event or state with other nodes in physical 
proximity. Hence multi-hop IP routing might not be needed?

Do the MANET protocols currently support multicast?

Thanks,
    Erik

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 22 Mar 2016 19:14:32 +0100

>  want to do in terms of IP address management.

For example in V2Internet the entertainment apps inside the vehicle may
tolerate longer latencies than V2Infrastructure or than V2V.

IP address management like in DHCP or SLAAC does involve some additional
latency.

It is still possible to communicate without involving too long address
management operations, like when nodes self-form some of their addresses.

> Some use cases are about connecting to the Internet, where it seems
> like one would want a global IP address with some support for
> mobility. (But there are privacy considerations that probably mean we
> don't want to keep the IP address for a long time.) Using DHCP to
> assign such addresses might be reasonable.
>
>  case there isn't a need for a global IP address. One could even
> argue that there is no need for an IP address at all if the purpose
> is to notify neighboring vehicles about a hazard or that I've slammed
> on the brakes.
>

Yes, a link-local group may be appropriate between nearbyy vehicles, or
between a vehicle and nearby infrastructure like a traffic lights pole.

> But that still requires having a link-local address, and concerns
> about privacy means we need to change that source address. But it
> wouldn't serve any purpose if the message is unidirectional.

The privacy aspects are obviously important.  A part of the privacy
discussion can be geared in the particular context of vehicular
communications.  We dont care about same privacy concerns in vehicles
than in the Internet.

For example, we do care about crackers listening to cars passing by and
beaconing data.  But we trade that against legislation that requires,
for example, the windshield to be clear for view as well as the license
plate.

On another hand, identifiers that change on some dynamic basis, may be
advantageously offering privacy, even though crackers can still listen
to them.

One can think about changing the link-local address dynamically, but not
in such a way as to disturb ongoing communications.

> (all-zeros) IPv6 source address. We typically don't use this (an
> exception is Duplicate Address Detection) but for local
> unidirectional traffic it is an option to consider if the

Yes, makes sense to send such packets with the all-zeros src address.
However, there is still a need for the receiver to be able to identify
the sender somehow, in order to be able to reply better rather than
to-everyone (unless they have a dedicated channel which does not noise
the others).

Alex

>
> Regards, Erik
>
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 22 Mar 2016 19:19:32 +0100

Le 22/03/2016 03:13, Margaret Cullen a écrit :
>> source address (and multicast them to a link-local group). But that
>> still requires having a link-local address, and concerns about
>> privacy means we need to change that source address. But it
>> unspecified (all-zeros) IPv6 source address. We typically don't use
>> this (an exception is Duplicate Address Detection) but for local
> I think a defined special-use global address (the same for everyone)
> would be better for this purpose, as it would not restrict the use
> of a multi-link network within the vehicle,

I agree - with these moving networks one can not consider multi-link
networks beyond the internal structure of the moving network, which is
relatively stable.

That is because there is a huge difference between the nature of links
outside the moving network (outside the vehicle) and inside the moving
network (inside a vehicle).  For example never there will be LTE
_inside_ a moving network to link CAN devices, as much as never there
will be a short-range compressed 6lo link outside a fast moving network.

> or require the receiving stack to accept packets from the all-zeros
> address (which some stacks may not right now).

I didnt know that?  Would Routers discard RAs from an all-zero src?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 22 Mar 2016 19:28:18 +0100

Le 22/03/2016 18:08, Rex Buddenberg a écrit :
> protocols (OLSR, AODV and ancillaries) cater to.

YEs, they try to.  But no, in this particular nomadic industry AODV and 
OLSR are not largely considered.  Because they do not deal with 
stable-structure moving networks that have only 1 fragile IP hop - the 
one between vehicles.  They deal with networks where more IP hops are 
fragile, in general.

That said, if addresses are established ok, then protocols like AODV can 
certainly take advantage of the addressing architecture.

AODV can certainly leverage a potential ITS work: Route Request and 
obtain correct Route Response in a vehicle-to-vehicle topology as long 
as the routing table entries are inserted appropriately.

>  Whatever addressing

YEs, I agree.  There can be AODV combined with this work to have a more 
complete solution.  But now let's focus on the ITS first steps.

Alex

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Mar 2016 15:01:09 -0400

Erik Nordmark <[email-masked]> wrote:
    > Some use cases are about connecting to the Internet, where it seems like one
    > would want a global IP address with some support for mobility. (But there are
    > privacy considerations that probably mean we don't want to keep the IP
    > address for a long time.) Using DHCP to assign such addresses might be
    > reasonable.

Or all the privacy enhanced methods... if one cares about privacy, it seems
that layer-2 MAC addresses need to be randomized too.

    > requirements might not allow for waiting for IP address assignment, while at
    > the same time the communication is entirely local. In such a case there isn't
    > a need for a global IP address. One could even argue that there is no need
    > for an IP address at all if the purpose is to notify neighboring vehicles
    > about a hazard or that I've slammed on the brakes.

I think that the advantage of the IP layer is that we can use route-over mesh
network technology to forward the notification to vehicles further away.

Stationary roadside warnings, and maybe even public vehicles might actually
have opposite privacy implications: i.e. we need to traceability.

    > One could potentially send such a packets using a link-local source address
    > (and multicast them to a link-local group).

Why aren't privacy-enhanced link local addresses (7217) useable here?
Is the DAD time that you are concerned about?

    > We typically don't use this (an exception is Duplicate Address Detection) but
    > for local unidirectional traffic it is an option to consider if the

I don't quite see the advantage...

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 22 Mar 2016 14:33:21 -0700

Erik,

Several people seem to think that one-hop solves all the problems.  I
don't believe that.  

First of all, look inside the automobile.  There are likely to be
several end systems, therefore a LAN within the vehicle (by whatever
name) is likely.  If not today, then a year or two.  That's the first
hop.  The second hop is the radio hop.  Followed by another hop in the
destination vehicle LAN.  

Second of all, there are a lot of use cases dealing with highway travel
like a 'virtual siren' for an ambulance.  The difficulty here is that we
need to reach around corners -- for example a cross street with
RF-obstructing buildings on the corners.  Unwarned cross traffic is
lethal to ambulances in a hurry.  So you have at least two hops of RF.  

I think trying to wish these requirements away is shortsighted.

b

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 24 Mar 2016 19:36:49 +0100

Le 22/03/2016 22:33, Rex Buddenberg a écrit :
> name) is likely.  If not today, then a year or two.

It is today.

But how would one compare the fragility of the IP hop between the cars 
with the solidity of built-in often-wired on-board multiple-subnet IP 
networks?

The problem is how two such 'solid' networks join together for a short 
oe long while, on relatively known trajectories.

This is not a problem of arbitrary movements of nodes on all-wireless links.

Alex

That's the first

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 25 Mar 2016 12:12:00 +0100

Le 24/03/2016 23:35, Richard Roy a écrit :
>
>
>> -----Original Message----- From: Alexandre Petrescu
>> [mailto:[email-masked]] Sent: Thursday, March 24,
>> 2016 11:37 AM To: [email-masked] Subject: Re: [its] Thoughts on
>> source IP addresses in ITS
>>
>>
>>
>>> Several people seem to think that one-hop solves all the
>>> problems.  I don't believe that.
>>>
>>> First of all, look inside the automobile.  There are likely to
>>> be several end systems, therefore a LAN within the vehicle (by
>>> whatever name) is likely.  If not today, then a year or two.
>>
>> It is today.
>>
>> But how would one compare the fragility of the IP hop between the
>> cars with the solidity of built-in often-wired on-board
>> multiple-subnet IP networks?
>
> [RR>] That assumes the in-vehicle networks are using IP, which today
> they are not.

In-vehicle networks _are_ using IP today.

A number of office switch manufacturers do offer small-format ruggedized
12V versions of traditional IP-enabled switches to be carried on-board
of vehicles including automobiles.

Ethernet cables are a reality in many automobiles today.

Aftermarket WiFi devices docked on OBDII (VINLI, Samsung) or
operator-specific on cigarette lighter (Orange) bring WiFi to the car
masses, and IP with it for that matter.  This only partially addresses
the number 1 feature US consumers are willing to purchase - a WiFi
hotspot in the car[ref].

Growth perspectives for more Ethernet and IP presence in more vehicles
are easy to detect.

> Even if IP does show up, there will still be layer-2 addressing
> mechanism (MAC addresses) and bridging/relaying at layer-2 for such
> scenarios is mquicker and more bandwidth efficient (over-the-air) so
> while one could use IP for such scenarios, it's "provably
> suboptimal".

Bridging inside a car is an advtageous technique in simplest car
networks, inside the car.  But certainly bridging must not be used
between the inside and the outside of the car.

Inside the car: bridging can be cost effective and fast in small in-car
networks; but the stronger separation offered by IP routing (rather than
MAC bridging) inside a car may offer higher security levels, better
safety ensurance: e.g. separate the signal linking the front camera to
emergency braking avoiding pedestrians, from the entertainment traffic,
inside a car - bridging  is less sure for that separation.

Bridging between the inside the car and the outside of a car is hardly
feasible technically.  For one, the MAC traffic outside needs to be
clean of the MAC traffic inside the car.  Typically the traffic outisde
the car is much less intense than inside the car and it should be kept
that way: think twice before talking outside the car.

More and more designers suggest addition of _their_ application-specific
boxes in a car, each with different link types.   And their are entitled
to, because these modules are so small today.  A box already exists
there which IP routes between outside and inside (typically the
3G/Ethernet box for driving guidance apps and maps).  Then, some app
designers want a 802.11p box to realize C-ACC application
(80211p/Ethernet box).  Then, other designers want a localization
app-specific additional box (GNSS/CAN).  And so on.  It's hard if not
impossible to bridge them all.

Alex

>
> Cheers,
>
> RR
>
>>
>> The problem is how two such 'solid' networks join together for a
>> short oe long while, on relatively known trajectories.
>>
>>> hop.  The second hop is the radio hop.  Followed by another hop
>>> in the destination vehicle LAN.
>>>
>>> Second of all, there are a lot of use cases dealing with highway
>>> travel like a 'virtual siren' for an ambulance.  The difficulty
>>> here is that we need to reach around corners -- for example a
>>> cross street with RF-obstructing buildings on the corners.
>>> Unwarned cross traffic is lethal to ambulances in a hurry.  So
>>> you have at least two hops of RF.
>>>
>>>>> The vehicle-to-vehicle nomadic topology is exactly what the
>>>>> MANET protocols (OLSR, AODV and ancillaries) cater to.
>>>>> Whatever addressing scheme picked should interface cleanly
>>>>> with those protocols.
>>>>
>>>> Rex,
>>>>
>>>> The descriptions I've read about some of the ITS use cases
>>>> leads me to believe that for some of them a link-local
>>>> multicast is appropriate
>> were
>>>> one node is sharing some event or state with other nodes in
>>>> physical proximity. Hence multi-hop IP routing might not be
>>>> needed?
>>>>
>>>> Thanks, Erik
>>>>>> Hi Erik, These are good comments on IP address in V2I and
>>>>>> V2V communications. I will also address your comments on
>>>>>> the revised version of
>>>>>> Best Regards, Paul
>>>>>> On Tue, Mar 22, 2016 at 9:10 AM, Erik Nordmark
>>>>>> <[email-masked]> wrote: I've looked through
>>>>>> draft-jeong-its-v2i-problem-statement
>> and
>>>>>> support for mobility. (But there are privacy
>>>>>> considerations that probably mean we don't want to keep the
>>>>>> IP address for
>> a
>>>>>> performance requirements might not allow for waiting for
>>>>>> IP address assignment, while at the same time the
>> communication
>>>>>> neighboring vehicles about a hazard or that I've slammed
>>>>>> on the brakes.
>>>>>>
>>>>>> unspecified (all-zeros) IPv6 source address. We typically
>>>>>> don't use this (an exception is Duplicate
>> Address
>>>>>> option to consider if the performance/privacy of IP
>>>>>> address assignment is an issue.
>>>>>>
>>>>>> Regards, Erik
>>>>>>
>>>>>> _______________________________________________ its mailing
>>>>>> list [email-masked]
>>>>>> -- =========================== Mr. Jaehoon (Paul) Jeong,
>>>>>> Ph.D. Assistant Professor Department of Software
>>>>>> Sungkyunkwan University Office: +82-31-299-4957 Email:
>>>>>> [email-masked], [email-masked] Personal
>>>>>> Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
>>>>>>
>>>>>> _______________________________________________ its mailing
>>>>>> list [email-masked]

---

From: Russ Housley <[email-masked]>
Date: Fri, 25 Mar 2016 13:04:52 -0400

Erik:

> I've looked through draft-jeong-its-v2i-problem-statement and the background on ITS that was given at recent IETF plenary.
> 
> It seems like there are quite different performance expectations for different types of V2V and V2I which has an impact on what one might want to do in terms of IP address management.
> 
> Some use cases are about connecting to the Internet, where it seems like one would want a global IP address with some support for mobility. (But there are privacy considerations that probably mean we don't want to keep the IP address for a long time.) Using DHCP to assign such addresses might be reasonable.
> 
> But for some V2V and vehicle to roadside use cases the performance requirements might not allow for waiting for IP address assignment, while at the same time the communication is entirely local. In such a case there isn't a need for a global IP address. One could even argue that there is no need for an IP address at all if the purpose is to notify neighboring vehicles about a hazard or that I've slammed on the brakes.
> 

Interesting thought.  As I understand the MAC address management, the MAC address is being changed every 5 minutes.  Isn’t there a IPv6 address construction that api;d let us construct a link-local address from that short-lived MAC address?

Russ

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 29 Mar 2016 16:18:50 +0200

Le 26/03/2016 00:36, Richard Roy a écrit :
>> [mailto:[email-masked]] Sent: Friday, March 25, 2016
>> 4:12 AM To: [email-masked]; [email-masked] Subject: Re: [its]
>> Thoughts on source IP addresses in ITS
>>
>>
>>
>>>> [mailto:[email-masked]] Sent: Thursday, March
>>>> 24, 2016 11:37 AM To: [email-masked] Subject: Re: [its] Thoughts
>>>> on source IP addresses in ITS
>>>>
>>>>
>>>>
>>>>> First of all, look inside the automobile.  There are likely
>>>>> to be several end systems, therefore a LAN within the vehicle
>>>>> (by whatever name) is likely.  If not today, then a year or
>>>>> two.
>>>>
>>>> It is today.
>>>>
>>>> But how would one compare the fragility of the IP hop between
>>>> the cars with the solidity of built-in often-wired on-board
>>> [RR>] That assumes the in-vehicle networks are using IP, which
>>> today they are not.
>>
>> A number of office switch manufacturers do offer small-format
>> ruggedized 12V versions of traditional IP-enabled switches to be
>> carried on-board of vehicles including automobiles.
>>
> [RR>] I have been informed by people who actually build vehicle that
> ethernets are only in very few high-end models, and even in those
> models, the ethernet portion is still small. Yes, there is a trend in
> toward the all-ethernet in-vehicle network, but they are a decade
> away.
>
>>
>> operator-specific on cigarette lighter (Orange) bring WiFi to the
>> car masses, and IP with it for that matter.  This only partially
>> addresses the number 1 feature US consumers are willing to purchase
>> - a WiFi hotspot in the car[ref].
>>
>> Growth perspectives for more Ethernet and IP presence in more
>> vehicles are easy to detect.
>>
>>> mechanism (MAC addresses) and bridging/relaying at layer-2 for
>>> such scenarios is mquicker and more bandwidth efficient
>>> (over-the-air) so while one could use IP for such scenarios, it's
>>> "provably suboptimal".
>>
>> networks, inside the car.
>
> [RR>] That's how in-vehicle networks work today; whether they call
> it bridging or something else doesn't matter.
>
>> But certainly bridging must not be used between the inside and the
>> outside of the car.
>
> [RR>] I don't understand why you say "must not be used".
> Technically, there is nothing preventing bridging between a LAN in
> the vehicle and a LAN on the roadside for example. And if you are
> concerned about layer-2 security, 802.1X works quite well.

802.1x is good for security, but here the worry is about channel
occupation and noise.  One doesnt want the numerous packets inside the
car to be replicated outside.  Because (some of) the outside channels
should be kept freer of noise.

With pure bridging all data traffic inside the car is transmitted on the
outside of the car too.  That's noise.

On another hand, data traffic from the outside of the car would
advantageously be transmitted towards a device inside the car.  For
example the 79GHz sensor and Road-Side Unit deployed as "mirror" at an
intersection would send IP packets to cars' OBUs, which would bridge
these packets further down to a device inside the car.

This latter direction (from RSU to OBU) is what some people call
"bridging" today, and nothing else.  But they forget that the car may
want to reply back (e.g. OBU asks the RSU the size of the obstacle).
And because this direction (from OBU to RSU) is neglected the IP routing
capacity of avoiding noise overlooked.

>> Inside the car: bridging can be cost effective and fast in small
>> in-car networks; but the stronger separation offered by IP routing
>> (rather than MAC bridging) inside a car may offer higher security
>> levels,
>
> [RR>] I would disagree.  Security should be applied at the
> application layer) if you really want end-to-end security.  Security
> at any lower layer is more prone to attack as we all know, and it
> doesn't matter if it's at layer-1, layer-2, layer-3, or higher.

I didnt mean security.  I meant separation between subnets which is
afforded by IP routing as opposed to bridging.  I meant to keep packet
noise away from fragile places where packet loss may be too risky.  This
is what bridging can not do.

>
>> better safety ensurance: e.g. separate the signal linking the front
>> camera to emergency braking avoiding pedestrians, from the
>> entertainment traffic, inside a car - bridging  is less sure for
>> that separation.
>
> [RR>] Again, I would disagree.  Whether layer-2 (bridging) or
> layer-3 (routing) addressing is used to direct traffic does not
> provide any advantage in "signal separation".

YEs it does.  There are different sets of software dealing with MAC
addressing or IP addressing.

If one wants to separate outside/inside by just using bridging then one
has to a particularly difficult kind of software (kernel, link-layer
drivers) which only works on particular links: all IEEE yes, but can't
bridge LTE, USB, CAN and others.  On the contrary, if one wants to
separate the outside/inside of a car by IP routing then one has to
simply configure tables which are available on a very wide range of
platforms and link layers.

Besides, IP routing has much better scalability and discovery
characteristics than MAC IEEE bridging.

>
>>
>> Bridging between the inside the car and the outside of a car is
>> hardly feasible technically.  For one, the MAC traffic outside
>> needs to be clean of the MAC traffic inside the car.  Typically the
>> traffic outisde the car is much less intense than inside the car
>> and it should be kept that way: think twice before talking outside
>> the car.
>
> [RR>] Bridging between the inside and the outside of a vehicle is
> absolutely technically feasible.

Yes, as long as we talk 802.11OCB (aka 802.11p) and Ethernet or WiFi.
But one can't bridge a mix containing CAN, USB or LTE.  These link types
are also highly used in vehicular networks.

> The separation of MAC traffic inside and outside the vehicle is
> precisely the function of the bridge.  Traffic inside the car stays
> inside the car. The only traffic that enters the vehicle is that
> which is intended for a station/destination in the vehicle.  You
> don't send ADUs over the air unless they are destined for an entity
> outside the vehicle.

That depends on how the bridging is configured.  The easiest bridge
configuration is to replicate everything.  If one wants to separate then
one has to be explicit about use of MAC protocols for MAC spanning
trees.  These are either not supported or not cared of in the vehicular
settings I have seen.  Besides, they dont work with other than IEEE
interfaces.

>> More and more designers suggest addition of _their_
>> application-specific boxes in a car, each with different link
>> types.   And their are entitled to, because these modules are so
>> small today.  A box already exists there which IP routes between
>> outside and inside (typically the 3G/Ethernet box for driving
>> guidance apps and maps).  Then, some app designers want a 802.11p
>> box to realize C-ACC application (80211p/Ethernet box).  Then,
>> other designers want a localization app-specific additional box
>> (GNSS/CAN).  And so on.  It's hard if not impossible to bridge them
>> all.
>
> [RR>] The difficulty arises from the silo thinking of all these
> designers! It's however technically feasible to bridge them as long
> as there is a one-to-one map between the layer-2 addresses on each
> LAN.  The real issue is that most these designers think in silos and
> want "their" system completely separate from any other system ...
> they want complete control ... they don't WANT their system to be
> part of a bridged LAN.

I agree.

> As the number of wireless interfaces proliferates however, the
> performance of the systems will monotonically degrade until such time
> as none of them function properly. But that's another story for
> another day :^)))

I agree.

Alex

>
> Cheers,
>
> RR
>
>>
>> Alex
>>
>>>
>>> Cheers,
>>>
>>> RR
>>>
>>>>
>>>> The problem is how two such 'solid' networks join together for
>>>> a short oe long while, on relatively known trajectories.
>>>>
>>>>> hop.  The second hop is the radio hop.  Followed by another
>>>>> hop in the destination vehicle LAN.
>>>>>
>>>>> Second of all, there are a lot of use cases dealing with
>>>>> highway travel like a 'virtual siren' for an ambulance.  The
>>>>> difficulty here is that we need to reach around corners --
>>>>> for example a cross street with RF-obstructing buildings on
>>>>> the corners. Unwarned cross traffic is lethal to ambulances
>>>>> in a hurry.  So you have at least two hops of RF.
>>>>>
>>>>>>> The vehicle-to-vehicle nomadic topology is exactly what
>>>>>>> the MANET protocols (OLSR, AODV and ancillaries) cater
>>>>>>> to. Whatever addressing scheme picked should interface
>>>>>>> cleanly with those protocols.
>>>>>>
>>>>>> Rex,
>>>>>>
>>>>>> one node is sharing some event or state with other nodes
>>>>>> in physical proximity. Hence multi-hop IP routing might not
>>>>>> be needed?
>>>>>>
>>>>>>>> Hi Erik, These are good comments on IP address in V2I
>>>>>>>> and V2V communications. I will also address your
>>>>>>>> comments on the revised version of
>>>>>>>> expectations for different types of V2V and V2I which
>>>>>>>> has
>>>> an
>>>>>>>> impact on what one might want to do in terms of IP
>>>>>>>> address management.
>>>>>>>>
>>>>>>>> Some use cases are about connecting to the Internet,
>>>>>>>> where
>>>> it
>>>>>>>> seems like one would want a global IP address with
>>>>>>>> some support for mobility. (But there are privacy
>>>>>>>> considerations that probably mean we don't want to keep
>>>>>>>> the IP address for
>>>> a
>>>>>>>> long time.) Using DHCP to assign such addresses might
>>>>>>>> be reasonable.
>>>>>>>>
>>>>>>>> performance requirements might not allow for waiting
>>>>>>>> for IP address assignment, while at the same time the
>>>> communication
>>>>>>>> is entirely local. In such a case there isn't a need
>>>>>>>> for a global IP address. One could even argue that
>>>>>>>> there is no
>>>> need
>>>>>>>> neighboring vehicles about a hazard or that I've
>>>>>>>> slammed on the brakes.
>>>>>>>>
>>>>>>>> One could potentially send such a packets using a
>>>>>>>> link-
>>>> local
>>>>>>>> source address (and multicast them to a link-local
>>>>>>>> group). But that still requires having a link-local
>>>>>>>> address, and concerns about privacy means we need to
>>>>>>>> change that source address. But it wouldn't serve any
>>>>>>>> purpose if the message
>>>> is
>>>>>>>> unidirectional.
>>>>>>>>
>>>>>>>> I think we could consider sending such packets with
>>>>>>>> the unspecified (all-zeros) IPv6 source address. We
>>>>>>>> typically don't use this (an exception is Duplicate
>>>> Address
>>>>>>>> Detection) but for local unidirectional traffic it is
>>>>>>>> an option to consider if the performance/privacy of IP
>>>>>>>> _______________________________________________ its
>>>>>>>> mailing list [email-masked]
>>>>>>>> -- =========================== Mr. Jaehoon (Paul)
>>>>>>>> Jeong, Ph.D. Assistant Professor Department of
>>>>>>>> Software Sungkyunkwan University Office:
>>>>>>>> +82-31-299-4957 Email: [email-masked],
>>>>>>>> [email-masked] Personal Homepage:
>>>>>>>> http://iotlab.skku.edu/people-jaehoon-jeong.php
>>>>>>>>
>>>>>>>> _______________________________________________ its
>>>>>>>> mailing list [email-masked]
>>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/its
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>