IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases
draft-ietf-ipwave-vehicular-networking-30
Yes
Erik Kline
No Objection
Abstain
Note: This ballot was opened for revision 24 and is now closed.
Erik Kline
Yes
Francesca Palombini
No Objection
Comment
(2022-04-06 for -28)
Sent
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
Murray Kucherawy
No Objection
Comment
(2022-05-19 for -29)
Sent for earlier
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 for -28)
Sent
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 for -28)
Sent
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.
Éric Vyncke
(was Discuss)
No Objection
Comment
(2022-06-25 for -29)
Sent
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).
Roman Danyliw
(was Discuss)
Abstain
Comment
(2022-11-02)
Sent
Thank you to Daniel Migault for the SECDIR review. Thank you for making edits in response to my DISCUSS positions. Despite these changes, it is my assessment that the security and privacy properties are not sufficiently described given the wide array of enabling technologies cited (e.g., credit-based authorization models, blockchain based authentication and logging, in vehicle credit card transactions). Furthermore, the document references architectural elements such as “legal vehicles” and “legal … smartphones”; and threats such as “privacy breakage” without sufficient explanation. For the reasons above and a few noted by Rob Wilton in his ballot, I am abstaining on this document. The IESG DISCUSS criteria (https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-disc) is not applicable to my above concerns since no protocol is being described and the guidance presented here is not intended to be implemented without significant further design and specification.
Alvaro Retana Former IESG member
No Objection
No Objection
(2022-04-06 for -28)
Sent
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/
Lars Eggert Former IESG member
No Objection
No Objection
(2022-04-05 for -28)
Sent
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].
Robert Wilton Former IESG member
Abstain
Abstain
(2022-04-07 for -28)
Sent
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