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

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

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

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.

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.

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 ;-)

I have now cleared my previous blocking DISCUSS points as you have addressed them as well as all but one of my previous non-blocking COMMENTs. Thanks for your reaction.

I have kept below the DISCUSS & COMMENT points just for archiving, please ignore them.

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 (just for archiving)

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)

# COMMENTS (just for archiving)

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

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/

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