Subject: Re: [its] Updated charter - please comment

From: Nabil Benamar <[email-masked]>
Date: Fri, 4 Mar 2016 16:33:08 +0000

Hi Alex, Russ and itsers,

The charter looks good for me and it should be noted that a great amount of
research papers are focusing on the benefits of car to car communication to
solve some relevant issues. Many strategies are proposed to proactively
compute re-routing guidance to be pushed to vehicles when signs of
congestion are observed on their route. This is beyond the safety issue as
stated in the draft charter but it concerns a better driving experience !

Other car manufacturers could be interested by the outcomes of this
wg, especially when we think about Autonomous driving. Indeed, one of the
main challenges of autonomous driving in urban areas is transition through
cross-roads and intersections. In addition to safety concerns, current
intersection management technologies such as stop signs and trafic lights
can introduce significant trafic delays even under light trafic conditions.

V2V and V2I can help avoiding deadlock situations and eventual collisions
as well !

Moreover, considering the importance of IPv6 deployment nowadays and all
the possibilities and new technologies rising from it, our previous draft
can be a good starting point and a work item for the WG:
https://datatracker.ietf.org/doc/draft-petrescu-ipv6-over-80211p/

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

http://nabilbenamar.ipv6-lab.net/

On Wed, Feb 17, 2016 at 6:36 PM, Russ Housley <[email-masked]> wrote:

> Alex:
>
> Below are my comments on the proposed charter text.
>
> Russ
>
>
>
> -----------------------------------------------------------------------
>
>                      ITS (name to change)
>                    Charter
>              February 15th, 2016
>          http://ietf.org/mailman/listinfo/its
>
>
> Intelligent Transportation Systems (its)
> ----------------------------------------
> Current Status: WG forming
>
> Chairs:
>    TBD
>
> Assigned Area Director:
>    TBD
>
> Mailing list
>    Address: [email-masked]
>    To Subscribe: https://www.ietf.org/mailman/listinfo/its
>    Archive:
>    http://www.ietf.org/mail-archive/web/its/current/maillist.html
>
> Additional web page
>    TBD
>
> Charter:
>
> Goal
> ----
> The goal of this group is to standardize IP protocols for establishing
> direct and secure connectivity between moving networks.
>
> Moving Network to Moving Network Communications
> -----------------------------------------------
> The group is concerned with all situations involving moving network to
> moving network communications.  For example: vehicle-to-vehicle
> communications, nomadic user wearing a PAN and communicating to a
> homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a
> train, or train-to-intersection signalling.
>
> Example from the automobile communications space
> ------------------------------------------------
> Automobiles and vehicles of all types are increasingly connected to
> the Internet.  Entertainment apps enhancing comfort, reliable data
> exchanges for road safety, and automated driving, are commonly seen as
>
>
> Editorial:  s/automated driving, are/automated driving are/
>
> winning sale arguments for automobiles to hit the roads from now to
> year 2020.  Emergency apps for new instrumented ambulances carry many
> benefits both to the users and to society in general.
>
>
> I think that the "winning sales arguments" is not needed here.  Instead, I
> think it
> would be valuable to say that these features are coming, and that the
> safety
> features are expected to become required.
>
>
> Why IP?
> -------
> Whereas the Vehicle-to-Internet technologies are considered completed
> and deployed in automobiles currently on the roads (e.g. car tethering
> through driver's cellular smartphone, live traffic data displayed on
> the dashboard, - use of NAT/DHCP and potentially Mobile IP), the
> Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are
> still in an infancy stage: primitive link-specific data exchanges are
> limited to a non-harmonized set of applications, such as ETSI's
> CAM/DENM presence signalling; worse, some link-specific messages
> exhibit behaviour assimilated to IP behaviour but the systems are
> incompatible with the Internet without involving specific gatewaying.
> The industry needs to employ IP data exchanges between vehicles, and
> between vehicles and the immediate infrastructure, rather than
> link-specific exchanges, in order to benefit from advantages such as
> (1) short delays, (2) fast forwarding through short paths of dumb
> routers (2) ease of reusing of a huge number of a desktop Internet
> applications in a vehicular environment (extend the Internet to mobile
> platforms).
>
>
> I think this paragraph take too long to get to the main point, which is
> why IP is a goog thing in this environment.  I suggest:
>
> Today, there are several deployed Vehicle-to-Internet technologies,
> including car tethering through driver's cellular smartphone.  However,
> Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are still
> being developed.  To avoid link-specific data exchanges, and enable
> independent application sets to share the same links, IP data exchanges
> are needed.  Enabling IP communication between vehicles (V2V), and
> between vehicles and the immediate infrastructure (V2I), will provide
> (1) short delays, (2) fast forwarding through short paths of routers,
> (3) ease of reuse of existing Internet applications in a vehicular
> environment.
>
>
> Moving network to moving network communications involve link layers
>
>
> Add "nearby" here.  I think it is important to the scope.
>
> such as: 802.11 OCB, 802.15.4 with 6lowpan, 802.11ac, VLC (Visible
> Light Communications), IrDA, LTE-D.  Only the IP protocols are capable
>
>
> s/802.11 OCB/802.11p OCB (Outside the Context of a BSS)/
>
> of running on each of these links and establish IP paths across them
> in an interoperable manner.
>
> Scenarios?
> ----------
> There are a few scenarios exhibiting the need to communicate from one
> moving network to another nearby moving network.
>
> In the automobile space, the Cooperative Adaptive Cruise Control and
> Platooning features consider that vehicles close to each other
> exchange data describing their kinematic status.  At the cross-roads,
> the moving network inside a vehicle exchanges data with the moving
> network in the red-light pole.
>
> Several public safety scenarios involve moving networks.  Distinct
> organizations deploy different moving networks (in-vehicle, on-person)
> at an incident scene.  These networks need to interoperate in order to
> more effectively understand and deal with the incident scene.
>
> In connected rail scenarios the moving network deployed in trains
> communicate with other moving networks at the cross-points.
>
> What kind of solutions?
> -----------------------
> The current technical solutions considered to achieve moving network
> to moving network communications are of two kinds: IP routing
>
>
> Add "nearby" here.  I think it is important to the scope.
>
> protocols for n-hop path management and 1-hop link-scoped IP protocol
> enhancements.  The 1-hop link-scoped protocols include the protocols
> for route establishment involving ICMP Router Advertisements.  The
> n-hop path management protocols include n-hop path establishment
> protocols (e.g. Babel, OSPF) and n-hop path search protocols (most
> notably AODV and derivates).
>
>
> My understanding from the phone call was that we were going to focus on
> the 1-hop
> protocols in this proposed working group, but leverage work from other
> groups for the
> n-hop situation.
>
> I think we need to say something here about the duration of some of the
> communications.
> a vehicle traveling at 80 Km/h is not going to have communications with a
> roadside
> device for very long.
>
>
> What kind of requirements?
> --------------------------
> The requirements for mechanisms for moving network to moving network
>
>
> Add "nearby" here.  I think it is important to the scope.
>
> communications are focusing on low delays of the data paths, reduced
> number of messages for path establishment, application friendly,
> resilience to attacks, compatibility with DHCP and Mobile IP.
>
> In addition, some moving network to moving network applications
>
>
> Add "nearby" here.  I think it is important to the scope.
>
> involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the
> 1-hop IP moving network to moving netowrk mechanisms will need to
> gracefully support IP multicast.
>
> Due to the inherent characteristics of safety-related communications,
> all new moving network to moving network mechanisms must afford
> authenticity and confidentiality where necessary.  Dynamically
> establishing ephemeral communication paths between automobiles in
> public areas must offer privacy safeguards for the end users
> (passengers).
>
> Establishing 1-hop IP V2V paths must not break the existing on-board
> protocols and applications which communicate with the Internet,
> possibly via multiple radios.
>
> In a moving network deployed in an automobile, typically one exit
> point connects the moving network to other moving networks.  However,
> in a more general manner (and to support reliability) any new
> mechanism of moving network to moving network communications should
> support multi-homing: one router to use multiple interfaces towards
> outside the moving network, or multiple routers.
>
> Current version of Internet protocols
> -------------------------------------
> The version of the IP protocol is IPv6 (witness 10% IPv6 penetration
> as of early 2016, mobile operators evolving to IPv6-only, government
> IPv6 push, IPv4 exhaust at RIRs); this acommodates the current
> generation of Internet protocols.  For backwards compatibility, IPv4
> may be considered as well, but not exclusively.  Link-local IPv6
> addresses will be used.
>
>
> This it too long.  Just say that the groups will only work on IPv6
> solutions.
>
>
> What SDOs may need this work?
> -----------------------------
> The requirements and standards for moving network to moving network
> communications, often involving IPv6, and novel V2V and V2Infra
> concepts, are developed mainly at ISO TC204 "Intelligent Transport
> Systems", 3GPP, ETSI, NHTSA and IEEE.  For Vehicle-to-Internet
> communications, 3GPP LTE and other cellular technologies represent the
> long-range connectivity method; for Vehicle-to-Vehicle communications,
> LTE Direct is currently specified, as well as OCB mode of IEEE 802.11.
> Several use-cases exhibit a need for IPv6 data exchanges between
> vehicles: ETSI's Cooperative Adaptive Cruise Control and Platooning.
> The IEEE developed a popular link for short-range communications -
> IEEE 802.11p "WAVE".  The NHTSA wrote a set of requirements for V2V
> communications.
>
> Work Items
> ----------
> - use-cases for moving network to moving network communications
> - Problem Statement for moving network to moving network communications
> - Security and Privacy Requirements for moving network to
>   moving network communications
> - Problem Statement for moving network to infrastructure network
>   communications, including DNS
> - Potentially new protocol, or protocol extensions for establishing IP
>   paths for 1-hop moving network to moving network communications.
>   With MIB and security.
> - IPv6-over foo, where foo is pertinent for moving network to moving
>   network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad)
>
> Timeline
> --------
> -
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>
>
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 7 Mar 2016 16:08:25 +0100

Le 04/03/2016 17:33, Nabil Benamar a écrit :
> The charter looks good for me and it should be noted that a great amount
> of research papers are focusing on the benefits of car to car
> communication to solve some relevant issues.

Do you have a list of such research papers?

Alex

> Many strategies are
> proposed to proactively compute re-routing guidance to be pushed to
> vehicles when signs of congestion are observed on their route. This is
> beyond the safety issue as stated in the draft charter but it concerns a
> better driving experience !
>
> wg, especially when we think about Autonomous driving. Indeed, one of
> the main challenges of autonomous driving in urban areas is transition
> through cross-roads and intersections. In addition to safety concerns,
> current intersection management technologies such as stop signs and
> trafic lights can introduce significant trafic delays even under light
> trafic conditions.
>
> V2V and V2I can help avoiding deadlock situations
> and eventual collisions as well !
>
> the possibilities and new technologies rising from it, our previous
> draft can be a good starting point and a work item for the WG:
> On Wed, Feb 17, 2016 at 6:36 PM, Russ Housley <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Alex:
>
>>        Address: [email-masked] <mailto:[email-masked]>
>     I think that the "winning sales arguments" is not needed here.
>     Instead, I think it
>     would be valuable to say that these features are coming, and that
>     the safety
>     still
>     My understanding from the phone call was that we were going to focus
>     on the 1-hop
>     protocols in this proposed working group, but leverage work from
>     other groups for the
>     n-hop situation.
>
>     I think we need to say something here about the duration of some of
>     the communications.
>     a vehicle traveling at 80 Km/h is not going to have communications
>     with a roadside
>     device for very long.
>
>>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Tue, 8 Mar 2016 01:06:06 +0900

Hi all,

Short comments below.

J.
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

#email: [email-masked]
#webpage: https://sites.google.com/site/hurryon

> On Feb 18, 2016, at 3:36 AM, Russ Housley <[email-masked]> wrote:
> 
> Alex:
> 
>>          http://ietf.org/mailman/listinfo/its <http://ietf.org/mailman/listinfo/its>
>> 
>> 
>>    To Subscribe: https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>
>>    Archive:
>>    http://www.ietf.org/mail-archive/web/its/current/maillist.html <http://www.ietf.org/mail-archive/web/its/current/maillist.html>
>> 
>> Additional web page
>>    TBD
>> 
>> Charter:
>> 
>> Goal
>> ----
> I think that the "winning sales arguments" is not needed here.  Instead, I think it
> would be valuable to say that these features are coming, and that the safety

Using IPv6 will not be a better option than the only link-layer use for the safety features. Due to this reason, the infotainment feature (e.g., entertainment applications) was emphasised.

> (3) ease of reuse of existing Internet applications in a vehicular

Thanks, it is much better. 

> My understanding from the phone call was that we were going to focus on the 1-hop
> protocols in this proposed working group, but leverage work from other groups for the
> n-hop situation.
> 
> I think we need to say something here about the duration of some of the communications.
> a vehicle traveling at 80 Km/h is not going to have communications with a roadside
> device for very long.

Mentioning 80 Km/h and a very communication chance…agree. But, we should think that the long range communications like LTE (license radio) and LP-WAN (unlicensed radio) are available. N-hop protocol support at IP can be also thought. Anyway, as you pointed, we need to put something here.  

> This it too long.  Just say that the groups will only work on IPv6 solutions.
> 
>> 
>> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>
> 
> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Tue, 8 Mar 2016 01:14:23 +0900

Hi Alex,

Some comments are below.

J.

> On Feb 19, 2016, at 2:47 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> Le 17/02/2016 23:15, Richard Roy a écrit :
>> My comments are inline below ...
>> 
>> RR
>> 
>> ------------------------------------------------------------------------
>> 
>> 
>> 
> *From:*Russ Housley [mailto:[email-masked] <mailto:[email-masked]>] *Sent:* Wednesday,
>> February 17, 2016 10:36 AM *To:* Alexandre Petrescu *Cc:*
>> [email-masked] <mailto:[email-masked]> *Subject:* Re: [its] Updated charter - please comment
>> 
>> Alex:
>> 
> ITS (name to change) Charter February 15th, 2016
>> ---------------------------------------- Current Status: WG forming
>> 
>> Chairs: TBD
>> 
>> Assigned Area Director: TBD
>> 
>> Mailing list Address: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> To
>> Subscribe: https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its> Archive:
>> Additional web page TBD
>> Goal ---- The goal of this group is to standardize IP protocols for
>> establishing direct and secure connectivity between moving networks.
>> 
>> */[RR>] Hard to believe that IP protocols need standardizing.  Isn't
>> the real issue one of an appropriate "profile" for using already
>> existing RFCs to implement IPv6 networking "between moving
>> subnets"?/*
> 
> Well profiles are for Bluetooth if you wish (which is below IP, or above
> IP) but I can say "adapt" or "improve" IP protocols.
> 
> BEcause I havent much seen the word "profile" in RFCs for the IP layer.
> 
>> ----------------------------------------------- The group is
>> concerned with all situations involving moving network to moving
>> network communications.  For example: vehicle-to-vehicle
>> homenet, vehicle-to-infrastructure communications, wagon-to-wagon in
>> a train, or train-to-intersection signalling.
>> 
>> ------------------------------------------------ Automobiles and
>> vehicles of all types are increasingly connected to the Internet.
>> Entertainment apps enhancing comfort, reliable data exchanges for
>> road safety, and automated driving, are commonly seen as
>> 
>> */[RR>] Many of the apps to which you allude do not require IPv6
>> networking.  If you feel the need to provide use cases, make sure
>> they require IPv6 networking in a mobile context./*
> 
> I will try to do that.
> 
> I would like you - if possible - to suggest other use case which
> requires IPv6 networking in a mobile context?  Thanks.
> 
> Let me explain the reasoning in the paragraph above by listing a few key
> items for IPv6 networking in V2V and V2I, pick one:
> 
> I experienced the need for IP between cells of vehicles moving together.
> The need was there urgent: the programmer in the back car had
> absolutely to flush the data in the middle car and the LTE connection
> was down.  If no flush then risk of accident.  The computer that flushes
> is windows with TCP IP on WiFi.  The computer to be flushed is a linux
> variant on a CAN network.  The only way to have that flush work is to
> network the two computers IP networked together.
> 
> There is no standard in vehicular communications which requires IPv4.
> If ever IP is mentioned it is IPv6.
> 
> The example C-ACC use case is typical illustration of a direct
> vehicle-to-vehicle communication of data (as opposed to entertainment
> apps which are Vehicle-to-Internet, and 'radar' communication which is
> bouncing signals not data).
> 
> A C-ACC standard currently under definition by ETSI is using CAM and
> DENM messages.  The CAM and DENM messages are understood by some at the
> link-layer and by others at the application-layer.  If they are
> application-layer, then there is a need of a networking layer.  The only
> networking layer is IPv6.
> 
> Vehicles connected to the Internet can only use IPv6 as networking
> layer.  If we want V2V and V2I to make a V2V2I the only possibility
> again is to use IPv6 as the networking layer.
> 
> If we dont use IPv6 as the networking layer in V2V and V2I then we risk
> end up with incompatibilities, seggregation in the deployed vehicles.
> This is what happened with WAP in the mobile phone world until IP
> arrived.  This is what happens these days with consumer electronics
> standards which include more and more IP technology as a networking
> layer after initial deployments of specific apps without networking layers.
> 
>> Why IP? ------- Whereas the Vehicle-to-Internet technologies are
>> considered completed and deployed in automobiles currently on the
>> roads (e.g. car tethering through driver's cellular smartphone, live
>> traffic data displayed on the dashboard, - use of NAT/DHCP and
>> potentially Mobile IP), the Vehicle-to-Vehicle and
>> Vehicle-to-Infrastructure communications are still in an infancy
>> stage: primitive link-specific data exchanges are limited to a
>> non-harmonized set of applications, such as ETSI's CAM/DENM presence
>> signalling;
>> 
>> */[RR>] Using the term non-harmonized here is not only incorrect,
>> but inflammatory.  Please remove such ill-advised terminology from
>> the draft./*
> 
> Ok sorry if offense.
> 
>> 
>> worse, some link-specific messages exhibit behaviour assimilated to
>> IP behaviour
>> 
>> */[RR>] Not sure what the point is here.  Messages don't have
>> "behaviors", they have information content./*
> 
> Ok.
> 
>> 
>> but the systems are incompatible with the Internet without involving
>> specific gatewaying.
>> 
>> */[RR>] Gateway functionality is above the transport layer, and
>> hence out of scope of this effort. /*
> 
> Ok, removed it for clarification.  I agree with you.  I think I meant
> routing.
> 
>> applications in a vehicular environment (extend the Internet to
>> mobile platforms).
>> 
>> */[RR>] This list is contradictory and the "necessity of employing"
>> is not obvious.  If you want fast forwarding, you don't do IP, you
>> do MAC bridging at the data link layer where possible.
> 
> It sounds intuitive, but measuring it may surprise:
> 
> Apps running directly on link layer vs on a networking layer are not
> necessarily faster.  The round-trip time of 1280-byte packets on 802.11p
> is sensibly the same whether or not the 40bytes of the IPv6 header is used.
> 
> The compute parts of an IP layer does not introduce much delay compared
> to the compute parts of the Ethernet link layer.  The comparison of the
> compute-intensive parts in the two layers are the following:
> - the CRC is optional in IP but mandatory in Ethernet.
> - the table lookup is longest-match in IP (faster in simpler 1-hop
>  topologies employing default routes) and exact-match in Ethernet
>  (always same cost regardless topology size and complexity).

Generally agree. But, we should think that the use of IPv6 layer will not only add its basic IPv6 headers, but also requires security (and possibly privacy related) headers and processing accordingly. Just a quick thought, think about the big big overhead of IPSec and related key establishment procedures that invoke the IKE protocols; sure we should avoid to use these for IPv6 ITS. ;)

> 
>> If you want short delays, make the packets smaller and the
>> processing overhead minimal, both of which argue AGAINST IPv6
>> networking protocols.
> 
> I should have been clearer:
> 
> Using IPv6 as networking layer in a string of vehicles allows for fast
> and deterministic communications between the frontmost and rearmost
> vehicle regardless the size of the string - it scales.  Only with an
> 802.11p link layer (no IP)  that string is bound to a small size of a
> few hundred meters, and additional propagation delays due to radio
> propagation uncertainties - it doesnt scale.
> 
>> The advantage of IPv6 pure and simple is that using that particular
>> networking protocol, most of the rest of the world can be reached!
>> There is little debate on this point, and it is sufficient to
>> justify pursuing this work. Why not leave it at that?? /*
> 
> I agree Richard.
> 
>> */[RR>] I would avoid any discussion of link-specific data exchanges
>> because they are being mandated, and they have no bearing on this
>> work. I'd simply state the obvious advantage of being able to
>> leverage off the already deployed Internet and leave it at that./*
> 
> Improved the text.
> 
>> 
>> 
>> 
>> 
>>> of running on each of these links and establish IP paths across
>>> them in an interoperable manner.
>>> 
>>> */[RR>] Fair enough ... see comment above.  Clearly there is no
>>> need to focus on the data link and physical layers, other than to
>>> state the obvious that if a particular MAC&PHY doesn't support the
>>> requisite MTU sizes (e.g. 802.15.4), then some accommodations
>>> (e.g. 6LoWPAN) will have to be made if possible. Noe of that
>>> should affect the work of this group if I understand the goals
>>> correctly. /*
>>> 
>>> 
>>> 
>>> Scenarios? ---------- There are a few scenarios exhibiting the
>>> need to communicate from one moving network to another nearby
>>> moving network.
>>> 
>>> In the automobile space, the Cooperative Adaptive Cruise Control
>>> and Platooning features consider that vehicles close to each other
>>> exchange data describing their kinematic status.  At the
>>> cross-roads, the moving network inside a vehicle exchanges data
>>> with the moving network in the red-light pole.
>>> 
>>> organizations deploy different moving networks (in-vehicle,
>>> on-person) at an incident scene.  These networks need to
>>> interoperate in order to more effectively understand and deal with
>>> the incident scene.
>>> 
>>> */[RR>] The issue of trains and subnets thereon is tricky and the
>>> topic of several investigations ongoing in Europe (including ETSI
>>> TC RT and ITS (RT-JTFIR)).  We may want to steer clear of such use
>>> cases for the time being until the dust settles./*
> 
> There is a person from a router manufacturer who expressed high interest
> in the technology for rails.  We may get a presentation in Buenos Aires
> to help clarify.
> 
>>> 
>>> 
>>> 
>>> What kind of solutions? ----------------------- The current
>>> technical solutions considered to achieve moving network to moving
>>> network communications are of two kinds: IP routing
>>> 
>> */[RR>] Are these protocol modfications/additions, or simply
>> profiles on existing protocols?  I suspect it's the later, but you
>> are the experts:^))/*
> 
> It's improving a protocol if possible (tweak its timers, extend some
> header) or otherwise make a new one.
> 
> I am not sure about profiling protocols.  I need to understand better
> this term profiling.
> 
>> What kind of requirements? -------------------------- The
>> requirements for mechanisms for moving network to moving network
>> 
>> */[RR>] ITS communication security is being addressed in various
>> venues (most notably IEEE 1609 and ETSI TC ITS).  We should be
>> careful not to reinvent the wheel.  For example, while there is no
>> theoretical problem using IPsec, to secure IPv6 management messages
>> as well as data exchanges at the network layer, you might find using
>> 1609.2 security functions work just as well if not better, and such
>> mechanisms are/will be mandated in all "vehicles", so why not use
>> them./*
> 
> YEs, I agree.  We need to reuse from 1609, ETSI TC ITS and others.  When
> studying some of them we may realize some may come from IETF (the cert
> parts is an example).  We need to identify the right source of reuse.

Security and privacy requirements and concerns caused by the use of IPv6 should be discussed and addressed at the IETF level. We will reuse the current IPv6 security protocols; otherwise we define new ones here. ;)

>> */[RR>] All this has been and continues to be addressed in other
>> venues. The solutions derived there are being / will be mandated by
>> regulators.  We should carefully follow and contribute to those
>> efforts here appropriate, but otherwise not try to build a separate
>> sand castle! /*
> 
> I agree.  We will strive to synchronize with regulators.
> 
>> */[RR>] Not sure why this is a concern.
> 
> It's technical: in a car the Mobile Router can only have one default
> route.  Many V2I trials have that default route used by Mobile IP these
> days (forward everything to the HA).  If we come up with a new technique
> for more direct V2V and V2I communications we must make sure we dont
> disturb that Mobile IP part.  It's a typical multihoming problem.
> 
>> 1-hop V2V doesn't require and in many cases does not use ANY
>> networking at all (cf. FNTP, WSMP, HSMP, NNTP, whatever name you want
>> to give the null-networking protocol whcih has been standardized in
>> IEEE and ISO (cf. IEEE 1609.3, ISO 16460, ISO 29281-1, etc.)./*
> 
> What hop do you think about?
> 
> I think about IP hop.  Should I call it 1-IP-hop V2V?
> 
>> ------------------------------------- The version of the IP protocol
>> is IPv6 (witness 10% IPv6 penetration as of early 2016, mobile
>> operators evolving to IPv6-only, government IPv6 push, IPv4 exhaust
>> at RIRs); this acommodates the current generation of Internet
>> protocols.  For backwards compatibility, IPv4 may be considered as
>> well, but not exclusively.  Link-local IPv6 addresses will be used.
>> 
>> */[RR>] Yes. Simpler is better!/*
> 
> Thanks, I agree.  Modified accordingly.
> 
> Alex
> 
>> 
>> 
>> 
>> 
>> What SDOs may need this work? ----------------------------- The
>> requirements and standards for moving network to moving network
>> communications, 3GPP LTE and other cellular technologies represent
>> the long-range connectivity method; for Vehicle-to-Vehicle
>> communications, LTE Direct is currently specified, as well as OCB
>> mode of IEEE 802.11. Several use-cases exhibit a need for IPv6 data
>> exchanges between vehicles: ETSI's Cooperative Adaptive Cruise
>> Control and Platooning. The IEEE developed a popular link for
>> short-range communications - IEEE 802.11p "WAVE".  The NHTSA wrote a
>> set of requirements for V2V communications.
>> 
>> Work Items ---------- - use-cases for moving network to moving
>> network communications - Problem Statement for moving network to
>> moving network communications - Security and Privacy Requirements
>> for moving network to moving network communications - Problem
>> Statement for moving network to infrastructure network
>> communications, including DNS - Potentially new protocol, or protocol
>> extensions for establishing IP paths for 1-hop moving network to
>> moving network communications. With MIB and security. - IPv6-over
>> foo, where foo is pertinent for moving network to moving network
>> communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad)
>> 
>> */[RR>] The real issue is using IPv6 networking to connect mobile
>> LAN subnets ... the data link and physical layer technology is NOT
>> directly relevant.  Simpler is better!/*
>> 
>> 
>> 
>> Timeline -------- -
>> 
>> _______________________________________________ its mailing list
>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 7 Mar 2016 17:30:27 +0100

Hi Jong-Hyouk,

Many thanks for the reply.

Le 07/03/2016 17:14, Jong-Hyouk Lee a écrit :
[...]
> Generally agree. But, we should think that the use of IPv6 layer will
> not only add its basic IPv6 headers, but also requires security (and
> possibly privacy related) headers and processing accordingly. Just a
> quick thought, think about the big big overhead of IPSec and related key
> establishment procedures that invoke the IKE protocols; sure we should
> avoid to use these for IPv6 ITS. ;)

Sure we should keep in mind that the security mechanisms of IPv6 may 
involve additional overhead.

However, I would guess that IPsec has state-of-the-art fast mechanisms 
as compared to link-layer security mechanisms.

[...]

> Security and privacy requirements and concerns caused by the use of IPv6
> should be discussed and addressed at the IETF level. We will reuse the
> current IPv6 security protocols; otherwise we define new ones here. ;)

Agreed.

There are currently two inceptive directions that could drive the 
security work in ITS at IETF: the certificates work (IETF and ITU) and 
the privacy identifiers work (ETSI).

Do you see something else?  How should we have security work in ITS at IETF?

Alex

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Tue, 8 Mar 2016 01:39:00 +0900

Please see inline; anyway, we will have a face-to-face meeting soon. ;)
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

> On Mar 8, 2016, at 1:30 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi Jong-Hyouk,
> 
> Sure we should keep in mind that the security mechanisms of IPv6 may involve additional overhead.
> 
> However, I would guess that IPsec has state-of-the-art fast mechanisms as compared to link-layer security mechanisms.

Want to know!

> There are currently two inceptive directions that could drive the security work in ITS at IETF: the certificates work (IETF and ITU) and the privacy identifiers work (ETSI).
> 

As stated, we first build the requirement document for security and privacy. I’ll try to find some time to write a draft soon. Regarding the certificate, it will be one option to use. It will be all depending on requirements, e.g., some communications/applications do not require nonrepudiation so that the use of certificate will not be required. Anyway, as we are working for IPv6 ITS at the IETF first time, we should put all possible options on the table and analyse them first. In other words, we should not try to stick with one solution yet. ;)

Cheers.

---

From: Nabil Benamar <[email-masked]>
Date: Tue, 8 Mar 2016 11:06:22 +0000

Hi Alex,

Here is some a non-exhaustive list of some :

   - Proactive Vehicular Traffic Re-routing for Lower Travel Time.
   - Reliable Intersection Protocols Using Vehicular Networks.
   - STIP: Spatio-Temporal Intersection Protocols for Autonomous Vehicles.
   - Routing protocols in Vehicular Delay Tolerant Networks: A
   comprehensive survey.
   - Toward V2I Communication Technology-based Solution for Reducing Road
   Traffic Congestion in Smart Cities.
   -
   - Sensing Traffic Density Combining V2V and V2IWireless Communications.
   -
   - Efficient Macroscopic Urban Traffic Models for Reducing Congestion: a
   PDDL+ Planning Approach.
   -
   - On Stochastic Analysis of Greedy Routing in Vehicular Networks.
   -
   - Balanced Traffic Routing: Design, Implementation, and Evaluation.
   -
   - A Survey on Urban Traffic Management System Using Wireless Sensor
   Networks.

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

On Mon, Mar 7, 2016 at 3:08 PM, Alexandre Petrescu <
[email-masked]> wrote:

>>> a
>>> mobile
>>> on-person)
>>> the