Skip to main content

IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases
draft-ietf-ipwave-vehicular-networking-28

Discuss


Yes

Erik Kline

No Objection


Abstain


No Record

Andrew Alston
John Scudder
Martin Duke
Warren Kumari

Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.

Roman Danyliw Discuss

Discuss (2022-04-05)
I had difficulty in understanding the bounds for the scope of the use cases and proposed architecture.  At times I had trouble understanding what was an example of related work, and what was narrative formally describing the gaps in IPv6 for vehicular networking.  In that spirit:

** The Privacy Considerations are under-specified:

-- Section 6.3 suggests the needs for logging, “To deal with this kind of security issue, for monitoring suspicious behaviors, vehicles' communication activities can be recorded in either a central way through a logging server (e.g., TCC) in the vehicular cloud or a distributed way (e.g., blockchain [Bitcoin]) along with other vehicles or infrastructure.  To solve the issue ultimately, we need a solution where, without    privacy breakage, …”.  Some discussion on the “privacy breakage” is needed.  What exactly would be the trade offs between a centralized vs. distributed log?  Who would get to see this information?  What is sensitive about this information?

-- Section 5.1.2 and 6.3 highlights the use of MAC address pseudonyms.  This is helpful.  More discussion is needed about the associate privacy threat being mitigated.  Section 6.3 mentions an “adversary from tracking a vehicle” which I think means a passive observer of the path.  However, there are other entities in which ecosystem – what is the privacy exposure to the TCC, V2I, etc?  The opening in Section 6 notes that “vehicles and infrastructure must be authenticated” and those credentials (perhaps bound to even MAC pseudonyms) would also facilitate tracking even given MAC pseudonyms.  Section 6.1 explicit comments on using VINs in certificates.  Who are the assumed trusted actors?

-- Section 3.3 notes a V2P use case where the pedestrian’s smart-phone is sharing unspecified information.  Does that include location information?  Who gets it?  What kind of identifiers are shared?

** Section 4.2

   Note that it is dangerous if the
   internal network of a vehicle is controlled by a malicious party.  To
   minimize this kind of risk, an reinforced identification and
   verification protocol shall be implemented. 

-- What are these dangers?

-- What is a ‘reinforced identification’?

-- Who are the parties in this verification protocol?  What security properties is this verification providing?

** Section 6.
   Vehicles and infrastructure must be authenticated in order to
   participate in vehicular networking.  

Authenticated with respect to whom? Vehicles to infrastructure and vice-versa?  Or to someone else?

** Section 6 makes references to “secure communication” – what is the expected key management approach and is that in scope?

** The need for safety properties (very helpful) is asserted multiple times but not further discussed in the Security Considerations:

-- Section 3:  
       In addition, IPv6
      security needs to be extended to support those V2V use cases in a
      safe, secure, privacy-preserving way.

-- Section 3.1: 
      To support applications of these V2V use cases, the required
     functions of IPv6 include IPv6-based packet exchange and secure,    
     safe communication between two vehicles.  

-- Section 3.3:
   To support applications of these V2X use cases, the required
   functions of IPv6 include IPv6-based packet exchange, transport-layer
   session continuity, and secure, safe communication between a vehicle
   and a pedestrian either directly or indirectly via an IP-RSU.
Comment (2022-04-05)
Thank you to Daniel Migault for the SECDIR review.

** Section 1.  Editorial
   Vehicular networking studies have mainly focused on improving safety
   and efficiency, and also enabling entertainment in vehicular
   networks.  

This first sentence is unrelated to the reset of the paragraph which is focused on spectrum allocation.

** Section 1.

   Most countries and regions in
   the world have adopted the same frequency allocation for vehicular
   networks. 

This statement seems incongruent with the previous two sentences which describe how the US and EU have allocated very similar but not “same” spectrum (5.850 – 5.925 vs. 5.875 vs. 5.905).

** Section 2.  Edge Computing is defined but doesn’t seem to be used in the rest of the document beyond in ECD.  Is it needed?

** Section 2.

IP-OBU: "Internet Protocol On-Board Unit": An IP-OBU denotes a
      computer situated in a vehicle

Is this “computer” the same as an ECD defined earlier in the section?

** Section 3.1.  Editorial.

   These five techniques will be important elements for autonomous
   vehicles, which may be either terrestrial vehicles or UAM end
   systems. 

This sentence seems to suggest that all give techniques are relevant to both terrestrial and UAMs.  As far as I can tell, the first three (1 – 3) are terrestrial related, the fourth is relevant to both terrestrial and UAM, and the fifth is UAM only.

** Section 3.1

   To encourage more vehicles to participate in this cooperative
   environmental sensing, a reward system will be needed.  Sensing
   activities of each vehicle need to be logged in either a central way
   through a logging server (e.g., TCC) in the vehicular cloud or a
   distributed way (e.g., blockchain [Bitcoin]) through other vehicles
   or infrastructure.  In the case of a blockchain, each sensing message
   from a vehicle can be treated as a transaction and the neighboring
   vehicles can play the role of peers in a consensus method of a
   blockchain [Bitcoin][Vehicular-BlockChain].

I’m struggling to link this proposed solution to stated uses case or gap-analysis for IPv6.  Can the IPv6 enablers be described.

** Section 3.2.  Typo?  s/air firmware/over-the-air firmware/.  If not a typo, what is an “air firmware/software update”?

** Section 3.2. Editorial?
   For this battery charging schedule, a UAM
   end system can communicate with an infrastructure node (e.g., IP-RSU)
   toward a cloud server via V2I communications.

Is there is a missing word here.  What does it mean to “... communicate with an infrastructure node … toward a cloud server”

** Section 4.2

   It is reasonable to consider the
   interaction between the internal network and an external network
   within another vehicle or an EN.   

Can the intent of this be clarified?  Isn’t something on the internal vehicle network talking to another vehicle the definition of V2V per Section 3.1?

** Section 4.2.  Is there any expectation of any perimeter-based policy enforcement between this internal network and the edge network (e.g., firewall?).

** Section 4.3.  Is there implicit trust between the platooning vehicles?  Security impact if one becomes untrusted?

** Section 5.
   For safe driving, vehicles need to exchange application messages
   every 0.5 second [NHTSA-ACAS-Report] to let drivers take an action to
   avoid a dangerous situation (e.g., vehicle collision), so IPv6
   protocol exchanges  need to support this order of magnitude for
   application message exchanges.  

This is a helpful performance envelope.  Can this be more tightly linked to IPv6?  It seems like this kind of performance is related to the capabilities of the link layer to move the IPv6 packets fast enough.

** Section 5.1.1
   For instance, some IPv6 protocols assume symmetry in the connectivity
   among neighboring interfaces [RFC6250].  

RFC6250 (Section 3.1.1) seems to be saying the opposite of this sentence which is that symmetry can’t be assumed.  What protocols are making this assumption?

** Section 5.1.2

   However, the pseudonym handling is not
   implemented and tested yet for applications on IP-based vehicular
   networking. 

No issues.  However, isn’t this true for all of the VIP and VND work (as in, it needs more testing)?

** Section 6.

   For the authentication in
   vehicular networks, vehicular cloud needs to support a kind of Public
   Key Infrastructure (PKI) in an efficient way.

What does the qualifier of “a kind of” PKI mean?

** Section 6

   Also, in-vehicle devices (e.g.,
   ECU) and a driver/passenger's mobile devices (e.g., smartphone and
   tablet PC) in a vehicle need to communicate with other in-vehicle
   devices and another driver/passenger's mobile devices in another
   vehicle, or other servers behind an IP-RSU in a secure way. 

Is securing arbitrary communication between a smartphone-A in vehicle-1 and smartphone-B in vehicle-2 in scope?

** Section 6.
   Even
   though a vehicle is perfectly authenticated and legitimate,

What does it mean for a vehicle to be legitimate?  Authenticated to whom?

** Section 6
   Note that when driver/passenger's mobile devices are
   connected to a vehicle's internal network, the vehicle may be more
   vulnerable to possible attacks from external networks.

This doesn’t seem framed right.  Why is it _more vulnerable_?  More relative to what?  I think the central idea is that like any network (e.g., public library, IETF conference network), the end-node assumes risk of its packets transiting a network it doesn’t control, and exposes itself to “local network/segment” attacks of any peer nodes on the network.

** Section 6.3
   Alternatively, for
   completely secure vehicular networks, we shall embrace the concept of
   "zero-trust" for vehicles in which no vehicle is trustable and
   verifying every message is necessary.  For doing so, we shall have an
   efficient zero-trust framework or mechanism for vehicular networks.

-- What is a “completely secure vehicular network”?

-- There seems to be an architecture mismatch in this aspirational zero trust architecture.  How does the premise of “verifying every message” align with focus of this document being IPv6 protocol mechanisms.  What is an “IPv6 message”?  Is that a packet?  It would seem to me that these messages would be application layer matters.

** Section 6.3

Each message from a
   vehicle can be treated as a transaction and the neighboring vehicles
   can play the role of peers in a consensus method of a blockchain
   [Bitcoin] [Vehicular-BlockChain].

Same comment as for ZT -- what is an “IPv6 message” that could be put on a blockchain?

** Section 6.3

   For the non-repudiation of the harmful activities of malicious nodes,
   a blockchain technology can be used [Bitcoin].  Each message from a
   vehicle can be treated as a transaction and the neighboring vehicles
   can play the role of peers in a consensus method of a blockchain
   [Bitcoin] [Vehicular-BlockChain].  For a blockchain's efficient
   consensus in vehicular networks having fast moving vehicles, a new
   consensus algorithm needs to be developed or an existing consensus
   algorithm needs to be enhanced.

Given the architecture layout in Figures 1 – 5?  Where does this block live?  Who checks it?  Under what circumstances?  It isn’t clear how this architectural construct is linked a gap analysis of IPv6 for vehicular networking.

Éric Vyncke Discuss

Discuss (2022-04-05)
Thank you for the work put into this document. I found the use cases part of section 3.1 very interesting to read even if some of them seem very far fetched ;-)

Please find below some blocking DISCUSS points (easy to address though), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to

- Carlos Bernardos for the shepherd's write-up even if a justification for the informational status would have been welcome but the WG consensus description is appreciated. 

- Pascal Thubert for his IETF last call INT directorate review at: https://datatracker.ietf.org/doc/review-ietf-ipwave-vehicular-networking-20-intdir-lc-thubert-2021-06-18/ and for his IESG telechat INT directorate review https://datatracker.ietf.org/doc/review-ietf-ipwave-vehicular-networking-27-intdir-telechat-thubert-2022-02-28/ Pascal's Last Call & telechat reviews were (at least partially) acted upon by Paul ;-)

I hope that this helps to improve the document,

Regards,

-éric

# DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## Abstract & Section 1

"then enumerates requirements for the extensions of those IPv6 protocols" does not match any IPWAVE WG work item, i.e., it is outside the scope of the charter of IPWAVE WG. As the document does not explicitly specify requirements, I strongly suggest to use the word "gaps" rather than "requirements" in the abstract and section 1.

## Section 4.1

Using an IPv6 address out of a ULA prefix still requires DAD. So the text below should be updated to be corrected:
  "their own IPv6 Unique Local Addresses
   (ULAs) [RFC4193] over the wireless network, which does not require
   the messaging (e.g., Duplicate Address Detection (DAD)) of IPv6
   Stateless Address Autoconfiguration (SLAAC) [RFC4862]."

## Section 4.2

Very similar comment as above (i.e., DAD & MLD must be done for all IPv6 addresses of an interface and not only for the global one):
  "... When global IPv6
   addresses are used, wireless interface configuration and control
   overhead for DAD"

## Section 5.2
  "... If DHCPv6 is used to assign
   a unique IPv6 address to each vehicle in this shared link, DAD is not
   required. "
This is incorrect and must be changed (see section 18.2.10.1. of RFC 8415)
Comment (2022-04-05)
# COMMENTS

"100km/h as the speed limit in highway" will make many European drivers smile as it is really slow...

## Section 1

"Most countries and regions in the world have adopted the same frequency allocation for vehicular networks." but there are TWO frequency allocations described just before, so, which one has been adopted ? 

## Section 2

"GPS" is just the USA commercial example of the more generic "global navigation satellite system" (GNSS), GNSS should be used in this document. 

As IP-RSU have at least 2 interfaces, should "Also, it may have *the* third IP-enabled wireless interface" be replaced by "Also, it may have *a* third IP-enabled wireless interface" ?

LiDAR ... "by measuring the reflected pulsed light" but on which kind of metrics ?

## Section 3.1

Should the 1st and 5th bullets be grouped together ?

Please describe "UAM" (e.g., in the terminology section) as it is unclear to the reader whether it is a crewed / uncrewed aircraft.

If both road and air vehicles are use case, what about river / sea ships or trains ?

Does the paragraph about "reward system" belong to the use case ? It rather sounds like a business requirement. Suggest to remove this part.

Like written by Pascal Thubert in his telechat review, the last paragraph "IPv6-based packet exchange and secure" should be clear that this is not only about data plane traffic but also control plane L2/L3 ones. Please also use the Oxford comma, i.e., add a "," after "exchange".

## Section 3.2

Suggest to also mention "5G" after "IP-RSU or 4G-LTE networks"

How is the UAM use case different from a driverless terrestrial EV ? Suggest to merge those use cases.

## Section 4.1

As noted by other ADs, "Existing network architectures," the list should not include OMNI yet as it is not deployed and would probably not be described as an architecture.

"the wireless media interfaces are autoconfigured with a global IPv6 prefix", is it the same shared prefix or multiple prefixes ?

Is "RSU" the same concept as "IP-RSU" ?

The last paragraph is about TCP session continuity, but does not explain why multi-path TCP or QUIC session resumption cannot be used.

## Section 4.2

The computation about "dwell time" is interesting even if it is computed in the best case. But, I really wonder whether using IPv6 and routing are applicable to the use case as opposed to more layer-2 + tunnel solutions (like 3GPP) with such short time for hand-over. I am a strong supporter of layer-3 (IPv6 and routing), but I cannot refrain from thinking that IPv6 is the wrong technical solution for those use cases... Was this discussed in the WG ?

## Section 5.1

What is "legacy DAD" ?

  "...the NA interval needs to be
   dynamically adjusted according to a vehicle's speed so that the
   vehicle can maintain its neighboring vehicles in a stable way"
With the issues linked to multicast over wireless, are the authors and the WG sure that increasing the amount of multicast will not aggravate the problem ? See RFC 9119 (cited as a normative down reference)

## Section 5.1.2

Please add some references to the MADINAS WG current work items. The authors may also consider adding this use case to the MADINAS use case.

"The pseudonym of a MAC address affects an IPv6 address based on the MAC address", nearly no implementations use EUI-64 anymore so this part should probably be removed from the document. But, the change of MAC address probably has other impact on the IP stack, e.g., the neighbour cache.

## Section 5.1.3

AFAIK, RPL relies on messages to discover the topology and I am afraid that in such a moving / dynamic environment, there will be too many of RPL messages. Will RPL scale in this ever changing network ? Please note that I am not a RPL expert.

## Section 6.1

Some explanations on how SEND protects against DAD flooding would be welcome.

Is "classical IPv6 ND" the same as the previously used "legacy ND" ?

Wondering why "Vehicle Identification Number (VIN)" is suggested to be used as SubjectAltName in a certificate rather than a car manufacturer cert ?

## Section 6.3

The part about bitcoin and blockchain errs probably too far away from the IETF remit.

## Appendix B

I fail to understand how RPL and OMNI can be compared as they are vastly different technologies (routing vs. tunneling).

"In OMNI protocol, each wireless media interface is configured with an IPv6 Unique Local Address (ULA)" but from my last read of OMNI drafts (1+ year ago), the OMNI virtual interface can have a ULA indeed but the wireless physical ones are using any prefix.

## Appendix D

What will be the impact of high packet loss rate (that I am expecting on such networks) on IP parcels ?

# NITS  

Please check that all IPv6 addresses are in lowercase (e.g., in section 4.1).

Erik Kline Yes

Alvaro Retana No Objection

Comment (2022-04-06)
I support Roman's and Eric's DISCUSS positions.  I, too, found the line between examples and gaps/requirements to be blurry, at best.


This document lists more than 40 Normative references!  Most (all?) of them point at examples of potential technology or are there as background.  For example, the first few point at MLD/MLDv2, OLSR, NEMO, and a couple of documents about terminology and documentation -- all clearly informative.

This is how the IESG Statement on Normative and Informative References [1] characterizes them:

   Within an RFC, references to other documents fall into two general
   categories: "normative" and "informative". Normative references specify
   documents that must be read to understand or implement the technology 
   in the new RFC, or whose technology must be present for the technology 
   in the new RFC to work. An informative reference is not normative; 
   rather, it only provides additional information. For example, an 
   informative reference might provide background or historical information. 
   Informative references are not required to implement the technology in 
   the RFC. 

Please examine the references and classify them accordingly.



[1] https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/

Francesca Palombini No Objection

Comment (2022-04-06)
Thank you for the work on this document

Many thanks to Jim Fenton for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/8JP36SKQXl7jNXXdWEbcXng5bD0/, and to
the authors for addressing it.

Francesca

Lars Eggert No Objection

Comment (2022-04-05)
Section 1. , paragraph 5, comment:
>    Along with these WAVE standards and C-V2X standards, regardless of a
>    wireless access technology under the IP stack of a vehicle, vehicular
>    networks can operate IP mobility with IPv6 [RFC8200] and Mobile IPv6
>    protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv6)
>    [RFC5213], Distributed Mobility Management (DMM) [RFC7333], Network
>    Mobility (NEMO) [RFC3963], Locator/ID Separation Protocol (LISP)
>    [I-D.ietf-lisp-rfc6830bis], and Automatic Extended Route Optimization
>    based on the Overlay Multilink Network Interface (AERO/OMNI)
>    [I-D.templin-6man-aero] [I-D.templin-6man-omni]).  In addition, ISO
>    has approved a standard specifying the IPv6 network protocols and
>    services to be used for Communications Access for Land Mobiles (CALM)
>    [ISO-ITS-IPv6][ISO-ITS-IPv6-AMD1].

Isn't it a bit premature to list AERO and OMNI alongside a number of published
standards from the IETF and other organizations? As far as I know they are
individual documents that have not been adopted? (Here and elsewhere in the
document.)

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "invalid"; alternatives might be "not valid", "unenforceable", "not
   binding", "inoperative", "illegitimate", "incorrect", "improper",
   "unacceptable", "inapplicable", "revoked", "rescinded".

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 5.2. , paragraph 7, nit:
-    home.  There is nonnegligible control overhead to set up and maintain
+    home.  There is non-negligible control overhead to set up and maintain
+                       +

Section 1. , paragraph 3, nit:
> 9.4 [WAVE-1609.4] specifies the multi-channel operation. IEEE 802.11p was fi
>                                 ^^^^^^^^^^^^^
This word is normally spelled as one.

Section 4.1. , paragraph 7, nit:
> arty. To minimize this kind of risk, an reinforced identification and verific
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 4.3. , paragraph 17, nit:
> livered to relevant vehicles in an efficient way (e.g., multicasting). With
>                              ^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "efficiently" to avoid
wordiness.

Section 4.3. , paragraph 17, nit:
> layers (e.g., IPv6, TCP, and UDP). Hence the bandwidth selection according t
>                                    ^^^^^
A comma may be missing after the conjunctive/linking adverb "Hence".

Section 5.1.1. , paragraph 4, nit:
> y with standard IPv6 links in an efficient fashion to support IPv6 DAD, MLD a
>                            ^^^^^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "efficiently" to avoid
wordiness.

Section 5.1.2. , paragraph 2, nit:
> ergy constraints, RPL does not suggest to use a proactive mechanism (e.g., k
>                                ^^^^^^^^^^^^^^
The verb "suggest" is used with the gerund form.

Section 5.2. , paragraph 4, nit:
> lic Key Infrastructure (PKI) in an efficient way. To provide safe interactio
>                              ^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "efficiently" to avoid
wordiness.

Section 5.2. , paragraph 5, nit:
> other servers behind an IP-RSU in a secure way. Even though a vehicle is per
>                                ^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "securely" to avoid wordiness.

Section 5.2. , paragraph 8, nit:
> eceived ND message, which requires to use the CGA ND option in the ND protoc
>                                    ^^^^^^
Did you mean "using"? Or maybe you should add a pronoun? In active voice,
"require" + "to" takes an object, usually a pronoun.

Section 6. , paragraph 3, nit:
>  taking a safe maneuver. Since cyber security issues in vehicular networks ma
>                                ^^^^^^^^^^^^^^
The word "cybersecurity" is spelled as one.

Section 6.1. , paragraph 4, nit:
> ensus algorithm needs to be developed or an existing consensus algorithm need
>                                      ^^^
Use a comma before "or" if it connects two independent clauses (unless they are
closely connected and short).

Section 8.2. , paragraph 7, nit:
>  Device-free human counting through WiFi fine-grained subcarrier information
>                                     ^^^^
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

Section 8.2. , paragraph 23, nit:
> unction (called OF), which allows to adapt the activity of the routing proto
>                                   ^^^^^^^^
Did you mean "adapting"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

"Appendix B. ", paragraph 5, nit:
> ST, CEA Saclay, Gif-sur-Yvette, Ile-de-France 91190, France, Phone: +33169089
>                                 ^^^^^^^^^^^^^
"Ile-de-France" is an imported foreign expression, which originally has a
diacritic. Consider using "Île-de-France".

Uncited references: [RFC3849].

Murray Kucherawy No Objection

Comment (2022-04-06)
First off, this is really interesting stuff.  Thanks for putting it together, and I'm looking forward to reading more.

I support Roman's and Eric's DISCUSS positions.  I also concur with Alvaro's comments about references.

The shepherd writeup doesn't say why "Informational" is the right type of RFC here.  (It becomes obvious quickly, but please still answer the question.  We often go to the writeup first.)

Section 2 defines "Class-Based Safety Plan", "V2I2D", "VMM", "VND", and "VSP", but then those terms don't appear anywhere in the document.  (I did find "class-based automatic safety action plan" later.)  It also defines "OCB" and "VIP', but then only really uses them as part of reference anchors.  On the flipside, I would love to see a definition (or reference) for "UAM".

Paul Wouters No Objection

Comment (2022-04-06)
I concur with Ronan's DISCUSS concerns.

In addition, I have a few comments:

        To encourage more vehicles to participate in this cooperative
        environmental sensing, a reward system will be needed.

The reward system could be "you are allowed to sell your car and drive it here".
In other words, how things are encouraged seems very open, and not really limited
to a reward system. I'd strongly recommend removing blockchain/bitcoin references
as these are too speculative - if anything these reward systems seem to be headed
towards getting banned or restricted by governments.

I'm very nervous about adding pedestrians to vehicle networks. It will
be a big privacy concern, especially if these networks are commercially
run by for-profit companies as these days companies are very eager to
monetize their data. Furthermore, pedestrian gadgets (phones, tablets)
usually can only connect to one wifi network, so sacrificing this to V2X
might not be what they want when sitting near an intersection at the coffee
shop.

 also think Bring-Your-Own- Prefix (BYOP)") does not avoid doing DAD, especially
if there might be malicious parties around.

   Note that it is dangerous if the
   internal network of a vehicle is controlled by a malicious party.  To
   minimize this kind of risk, an reinforced identification and
   verification protocol shall be implemented.

I don't see easy solutions here. No one wants to give control of their vehicle network
to another entity - even if identification/verification is "reinforced".

   For doing so, we shall have an
   efficient zero-trust framework or mechanism for vehicular networks.

There is a lot of heavy lifting done by this one sentence. Especially when it is
also being combined with blockchain/bitcoin solutions. All of these mechanisms
seem many orders of magnitude slower than for an attaker to pretend to be a new
and different vehicle.

Zaheduzzaman Sarker No Objection

Comment (2022-04-06)
Thanks for working on this informational document.

I found this document a good read from the vehicular connectivity and networking point of view, however, there are some cases where the descriptions are not clear to convey the message and required ask.  Specially in section 4 and section 6. I think Roman already have covered most of those. Hence supporting his discuss points regarding  those sections.

I also have following observation/comments which I believe if addressed will improve the document-

* Abstract: I actually didn't find enumerated requirements form the problem statements that obviously. Hence, I would suggest to remove this part ("then enumerates requirements for the extensions of those IPv6 protocols for IPv6-based vehicular networking") from the abstract. Lets stick to what the title says.  Otherwise, I would expect a numbered list of requirements that the wg would like to refer to and fulfill in future works.

* Please add V2P (and X2P) definitions like others in the terminology section.

* Section 3.1: it says -

     "To encourage more vehicles to participate in this cooperative environmental sensing, a reward system will be needed. Sensing activities of each vehicle need to be logged in either a central way through a logging server (e.g., TCC) in the vehicular cloud or a distributed way (e.g., blockchain [Bitcoin]) through other vehicles or infrastructure. In the case of a blockchain, each sensing message from a vehicle can be treated as a transaction and the neighboring vehicles can play the role of peers in a consensus method of a blockchain [Bitcoin][Vehicular-BlockChain]."

   This seems like a misfit to the use case section and felt more like belongs to some sort of requirement for a reward system. I would suggest to just remove this paragraph.

* Section 5: it says -

    "Since the vehicles are likely to be moving at great speed, protocol exchanges need to be completed in a relatively short time compared to the lifetime of a link between a vehicle and an IP-RSU, or between two vehicles"

  While it is true that vehicles can move with "great speed", it is also true that the relative speeds between vehicles might not be that "great", e.g. platooning case. And when vehicles passes each other or a IP-RSU really fast there might not be enough time to setup the link layer connection and V2I communication becomes more important. I found the quoted section of problem statement to be ignorant of these facts and missing the potential relation among V2V, V2I and V2X connectivity and communication.

*  I would note that, fro, the use case and problem statement, tranport-layer session mobility and usage of available bandwidth mentioned in the document. However, those are not discussed with details but I understand would play vital role to support the discussed application use cases and architecture. I assume this might be due to  the scope of the document but this document should say something about those aspect, at least mention as potential future work that need to fulfill the envisioned use cases.

Robert Wilton Abstain

Comment (2022-04-07)
I'm not an expect on these areas of technology, but I find parts of this document to be quite uncompelling.  However, it is an informational document, where considerable latitude is allowed.

Although I'm happy for the authors to correct my misunderstandings below, if they wish, I'm doubtful that such a discussion will really be helpful, hence my abstain ballot.

Some of my concerns when reviewing this document:

(1) It feels like quite a lot of these problems are (or could be) solved today using the existing wireless networks and GPS already included in cars.  E.g., presumably they are already making use of IP over 4G-LTE without needing these proposed protocol changes?  I.e., how many of the problems described here can really be most efficiently solved by having a local dynamic network?

(2) Having some sort of bitcoin/blockchain based micropayment scheme for sharing sensor data between vehicles feels highly implausible to me, given that the world hasn't seemed to manage a micropayment scheme for websites which seems like an easier problem to solve.

(3) Would vehicles even be able to safely trust sensor data coming from other vehicles?  E.g., hacked vehicles that randomly occasionally inject false sensor readings.  Who would have legal liability if your vehicle takes some action based on unreliable 3rd party sensor data?  I appreciate that it outside this type of technical document, but I think that it limits the likely hood of solving this in an ad hoc network.

(4) I struggle to understand how the V2X use cases really work.  In a street (at least in the UK) there would often be people in very close proximity to a vehicle (e.g., walking on the pavement [sidewalk] next to a vehicle, and presumably it is only people in front of the vehicle that are potential collision problems, and for these cases, are radar/lidar/cameras/sensors not a more robust choice (and are already deployed today, and seemingly improving every year).  I would think that the only way that this could work with a smartphone is if it sharing very precise (0.1 m) location data all the time to everything around it, which would probably degrade the battery and would also seem to have some serious privacy considerations.

(5) In Appendix D, I don't understand how the AERO/OMNI service solves the MTU problem.  It seems to be just introducing another layer to solve exactly the problem that are already solved by existing transport layer protocols.  If there is some data illustrating how TCP over OAL (with IP parcels) is more efficient that straight TCP over IP then that would be worth sharing.

Regards,
Rob

Andrew Alston No Record

John Scudder No Record

Martin Duke No Record

Warren Kumari No Record