RFC 9365
IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases
RFC 9365 ✨: IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases 🚗💖
Okay bestie, let's get into it! 🎀 This one is an Informational RFC from March 2023, written by J. Jeong, Ed. at Sungkyunkwan University. It isn't on the Standards Track, so it's published just to inform, not to set rules. 💅 It doesn't obsolete or update any other RFCs, so it's a totally fresh start. 🌸
The whole vibe is IPv6 for cars talking to each other, to roadside stuff, and to everything else on the road. 🚙✨ The authors call this IPWAVE, which is short for IPv6 Wireless Access in Vehicular Environments. 🦋 They do two things: show off use cases, and do a gap analysis of which current IPv6 protocols (like Neighbor Discovery, mobility management, and security and privacy) need some glow-up for cars. 💜
Abstract 🌈
Okay so the abstract is literally the TL;DR. 🫶 It's about IPv6-based vehicular networking for Intelligent Transportation Systems (ITS). The three main scenarios are vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X). ✨ The doc explains use cases for all three, then checks whether today's IPv6 protocols can handle them. 🔥
Status of This Memo 📜
Not an Internet Standards Track specification, ngl. 🙈 It's published for information only. 💅 It's still an IETF product that represents the IETF community's consensus, got public review, and was approved by the IESG. 🎀 Not every IESG-approved doc can become an Internet Standard, though. See Section 2 of RFC 7841 for that. 🌸
You can find the current status, errata, and feedback info at https://www.rfc-editor.org/info/rfc9365. 🧚
Copyright Notice 💖
Copyright (c) 2023 IETF Trust and the document authors. All rights reserved. 🫶
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. 📜 Read them carefully, because they describe your rights and restrictions. 👑 Code Components pulled from this doc must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License says. 💀
Table of Contents 🦋
1. Introduction
2. Terminology
3. Use Cases
3.1. V2V
3.2. V2I
3.3. V2X
4. Vehicular Networks
4.1. Vehicular Network Architecture
4.2. V2I-Based Internetworking
4.3. V2V-Based Internetworking
5. Problem Statement
5.1. Neighbor Discovery
5.1.1. Link Model
5.1.2. MAC Address Pseudonym
5.1.3. Routing
5.2. Mobility Management
6. Security Considerations
6.1. Security Threats in Neighbor Discovery
6.2. Security Threats in Mobility Management
6.3. Other Threats
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Support of Multiple Radio Technologies for V2V
Appendix B. Support of Multihop V2X Networking
Appendix C. Support of Mobility Management for V2I
Appendix D. Support of MTU Diversity for IP-Based Vehicular
Networks
Acknowledgments
Contributors
Author's Address1. Introduction 🚦
Okay, so vehicular networking research is mostly about making roads safer and more efficient, plus some entertainment on the side. 🍓 To help these use cases grow, lots of governments and private orgs have been setting aside dedicated spectrum for vehicle communications. 🌈
In the US, the FCC set aside wireless channels for Dedicated Short-Range Communications (DSRC) [DSRC] in Intelligent Transportation Systems (ITS), in the 5.850 - 5.925 GHz band (aka the 5.9 GHz band). 📡 Then in November 2020, the FCC repurposed the lower 45 MHz (5.850 - 5.895 GHz) of that band for unlicensed use instead of DSRC-only use [FCC-ITS-Modification]. 😭 DSRC-based wireless can support V2V, V2I, and V2X networking. 🦋
Over in the EU, radio spectrum for safety-related and non-safety-related ITS apps was allocated in the 5.875 - 5.905 GHz band, as part of Commission Decision 2008/671/EC [EU-2008-671-EC]. 🇪🇺✨ Most other countries and regions have also adopted the 5.9 GHz band for vehicular networks. The catch is that they each split the band into channels differently. 🙈
For direct vehicle-to-vehicle wireless connectivity, IEEE amended 802.11 (aka Wi-Fi) so it can do safe driving services based on DSRC for the Wireless Access in Vehicular Environments (WAVE) system. 🚗💜 The Physical Layer (L1) and Data Link Layer (L2) bits are covered by IEEE 802.11p [IEEE-802.11p] for the DSRC PHY and MAC layers. IEEE Std 1609.2 [WAVE-1609.2] handles security, IEEE Std 1609.3 [WAVE-1609.3] defines related services at the network and transport layers, and IEEE Std 1609.4 [WAVE-1609.4] specifies multichannel operation. 🔥 IEEE 802.11p started out as its own separate amendment, but in 2012 it got folded into the base 802.11 standard (IEEE Std 802.11-2012) as IEEE 802.11 Outside the Context of a Basic Service Set (OCB) [IEEE-802.11-OCB]. 👑
3GPP standardized Cellular Vehicle-to-Everything (C-V2X) communications to support V2X in LTE mobile networks (called LTE V2X) and in 5G mobile networks (called 5G V2X) [TS-23.285-3GPP] [TR-22.886-3GPP] [TS-23.287-3GPP]. 📶 With C-V2X, vehicles can talk directly to each other without relay nodes (like eNodeB in LTE and gNodeB in 5G). 🫶
Along with the WAVE and C-V2X standards, no matter which wireless access tech is under a vehicle's IP stack, vehicular networks can do IP mobility with IPv6 [RFC8200]. 🧚 That means Mobile IPv6 protocols, like Mobile IPv6 (MIPv6) [RFC6275], Proxy Mobile IPv6 (PMIPv6) [RFC5213], Distributed Mobility Management (DMM) [RFC7333], Network Mobility (NEMO) [RFC3963], and the Locator/ID Separation Protocol (LISP) [RFC9300]. 🌸 ISO has also approved a standard for the IPv6 network protocols and services used for Communications Access for Land Mobiles (CALM) [ISO-ITS-IPv6] [ISO-ITS-IPv6-AMD1]. ✨
Now for this doc's own goal: it describes use cases and a problem statement for IPv6-based vehicular networking for ITS, which is named IPv6 Wireless Access in Vehicular Environments (IPWAVE). 🚙💖 First it introduces use cases for V2V, V2I, and V2X networking in ITS. Then, for IPv6-based vehicular networks, it does a gap analysis of current IPv6 protocols (like IPv6 Neighbor Discovery, mobility management, and security and privacy) so they can be tailored to IPv6 vehicular networking. 🦋 Basically, this doc is meant to motivate development of the key protocols for IPWAVE. 👑🔥
Heads up: this is part 1 of 15, so there's more coming! 🎀 Sections 2 and beyond are on the way, bestie. 💅
2. Terminology ✨
okay bestie, this section is basically our vocab list 📖. The doc uses the terms from [RFC8691], and then it adds its own definitions below, so let's go 💅
Context-Awareness: A vehicle can be aware of spatial-temporal mobility information (e.g., position, speed, direction, and acceleration/deceleration) of surrounding vehicles for both safety and non-safety uses through sensing or communication [CASD]. 🚗💨
Distributed Mobility Management (DMM): See [RFC7333] [RFC7429]. 🔀
Edge Computing Device (ECD): This is a computing device (or server) at the edge of the network for vehicles and vulnerable road users. It co-locates with or connects to an IP Roadside Unit (IP-RSU), which has a powerful computing capability for different kinds of computing tasks, such as image processing and classification. 🧠✨
Edge Network (EN): This is an access network that has an IP-RSU for wireless communication with other vehicles having an IP On-Board Unit (IP-OBU) and wired communication with other network devices (e.g., routers, IP-RSUs, ECDs, servers, and Mobility Anchors (MAs)). It may use a Global Navigation Satellite System (GNSS) such as Global Positioning System (GPS) with a GNSS receiver for its position recognition and the localization service for the sake of vehicles. 📍
Evolved Node B (eNodeB): This is a base station entity that supports the Long Term Evolution (LTE) air interface. 📡
Internet Protocol On-Board Unit (IP-OBU): An IP-OBU denotes a computer situated in a vehicle (e.g., car, bicycle, electric bike, motorcycle, or similar), which has a basic processing ability and can be driven by a low-power CPU (e.g., ARM). It has at least one IP interface that runs in IEEE 802.11-OCB and has an "OBU" transceiver. Also, it may have an IP interface that runs in Cellular V2X (C-V2X) [TS-23.285-3GPP] [TR-22.886-3GPP] [TS-23.287-3GPP]. It can play the role of a router connecting multiple computers (or in-vehicle devices) inside a vehicle. See the definition of the term "IP-OBU" in [RFC8691]. 🏎️🍓
IP Roadside Unit (IP-RSU): An IP-RSU is situated along the road. It has at least two distinct IP-enabled interfaces. The wireless PHY/MAC layer of at least one of its IP-enabled interfaces is configured to operate in 802.11-OCB mode [IEEE-802.11-OCB]. An IP-RSU communicates with the IP-OBU over an 802.11 wireless link operating in OCB mode. One of its IP-enabled interfaces is connected to the wired network for wired communication with other network devices (e.g., routers, IP-RSUs, ECDs, servers, and MAs). Also, it may have another IP-enabled wireless interface running in 3GPP C-V2X in addition to the IP-RSU defined in [RFC8691]. An IP-RSU is similar to an Access Network Router (ANR), defined in [RFC3753], and a Wireless Termination Point (WTP), defined in [RFC5415]. See the definition of the term "IP-RSU" in [RFC8691]. 🛣️🌸
Light Detection and Ranging (LiDAR): This is a method for measuring a distance to an object by emitting pulsed laser light and measuring the reflected pulsed light. 🔦
Mobility Anchor (MA): This is a node that maintains IPv6 addresses and mobility information of vehicles in a road network to support their IPv6 address autoconfiguration and mobility management with a binding table. An MA has end-to-end (E2E) connections (e.g., tunnels) with IP-RSUs under its control for the IPv6 address autoconfiguration and mobility management of the vehicles. This MA is similar to a Local Mobility Anchor (LMA) in PMIPv6 [RFC5213] for network-based mobility management. 🦋
Next Generation Node B (gNodeB): This is a base station entity that supports the 5G New Radio (NR) air interface. 📶
Outside the Context of a BSS (OCB): This is a mode of operation in which a station (STA) is not a member of a Basic Service Set (BSS) and does not utilize IEEE Std 802.11 authentication, association, or data confidentiality [IEEE-802.11-OCB]. 🙈
802.11-OCB: This refers to the mode specified in IEEE Std 802.11-2016 [IEEE-802.11-OCB] when the MIB attribute dot11OCBActivated is 'true'. 💜
Platooning: Moving vehicles can be grouped together to reduce air resistance for energy efficiency and reduce the number of drivers such that only the lead vehicle has a driver, and the other vehicles are autonomous vehicles without a driver and closely follow the lead vehicle [Truck-Platooning]. 🚛🫶
Traffic Control Center (TCC): This is a system that manages road infrastructure nodes (e.g., IP-RSUs, MAs, traffic signals, and loop detectors) and also maintains vehicular traffic statistics (e.g., average vehicle speed and vehicle inter-arrival time per road segment) and vehicle information (e.g., a vehicle's identifier, position, direction, speed, and trajectory as a navigation path). TCC is part of a Vehicular Cloud for vehicular networks. 🗼
Urban Air Mobility (UAM): This refers to using lower-altitude aircraft to transport passengers or cargo in urban and suburban areas. The carriers used for UAM can be manned or unmanned vehicles, which can include helicopters, electric vertical take-off and landing (eVTOL) aircraft, and unmanned aerial vehicles (UAVs). 🚁🌈
Vehicle: This is a node that has an IP-OBU for wireless communication with other vehicles and IP-RSUs. It has a GNSS radio navigation receiver for efficient navigation. Any device having an IP-OBU and a GNSS receiver (e.g., smartphone and tablet PC) can be regarded as a vehicle in this document. 📱
Vehicular Ad Hoc Network (VANET): This is a network that consists of vehicles interconnected by wireless communication. Two vehicles in a VANET can communicate with each other using other vehicles as relays even where they are out of one-hop wireless communication range. 🕸️
Vehicular Cloud: This is a cloud infrastructure for vehicular networks, having compute nodes, storage nodes, and network forwarding elements (e.g., switch and router). ☁️
Vehicle to Device (V2D): This is the wireless communication between a vehicle and a device (e.g., smartphone and IoT (Internet of Things) device). 📲
Vehicle to Pedestrian (V2P): This is the wireless communication between a vehicle and a pedestrian's device (e.g., smartphone and IoT device). 🚶♀️
Vehicle to Infrastructure to Vehicle (V2I2V): This is the wireless communication between a vehicle and another vehicle via an infrastructure node (e.g., IP-RSU). 🔁
Vehicle to Infrastructure to Everything (V2I2X): This is the wireless communication between a vehicle and another entity (e.g., vehicle, smartphone, and IoT device) via an infrastructure node (e.g., IP-RSU). 🌐
Vehicle to Everything (V2X): This is the wireless communication between a vehicle and any entity (e.g., vehicle, infrastructure node, smartphone, and IoT device), including V2V, V2I, V2D, and V2P. 💖
Vehicular Mobility Management (VMM): This is IPv6-based mobility management for vehicular networks. 🧚
Vehicular Neighbor Discovery (VND): This is an IPv6 ND (Neighbor Discovery) extension for vehicular networks. 👑
Vehicular Security and Privacy (VSP): This is IPv6-based security and privacy for vehicular networks. 🔐
Wireless Access in Vehicular Environments (WAVE): See [WAVE-1609.0]. 🌸
3. Use Cases 🗺️
This section explains use cases of V2V, V2I, and V2X networking. The use cases of the V2X networking exclude the ones of the V2V and V2I networking but include Vehicle-to-Pedestrian (V2P) and Vehicle-to-Device (V2D). 🙌
IP is widely used among popular end-user devices (e.g., smartphone and tablet) in the Internet. Applications (e.g., navigator application) for those devices can be extended such that the V2V use cases in this section can work with IPv6 as a network layer protocol and IEEE 802.11-OCB as a link-layer protocol. In addition, IPv6 security needs to be extended to support those V2V use cases in a safe, secure, privacy-preserving way. 📱🔒
The use cases presented in this section serve as the description and motivation for the need to augment IPv6 and its protocols to facilitate "Vehicular IPv6". Section 5 summarizes the overall problem statement and IPv6 requirements. Note that the adjective "Vehicular" in this document is used to represent extensions of existing protocols, such as IPv6 Neighbor Discovery, IPv6 Mobility Management (e.g., PMIPv6 [RFC5213] and DMM [RFC7429]), and IPv6 Security and Privacy Mechanisms rather than new "vehicular-specific" functions. Extensions, not brand-new vibes, iykyk 💅✨
3.1. V2V 🚗💨✨
okay bestie, let's talk V2V (vehicle-to-vehicle) use cases 💅 this section covers these bad boys:
- Context-aware navigation for driving safely and avoiding collisions
- Collision avoidance service of end systems of Urban Air Mobility (UAM)
- Cooperative adaptive cruise control on a roadway
- Platooning on a highway
- Cooperative environment sensing
These are just examples of what V2V networking can do 🫶 it can be extended to other terrestrial vehicles, river/sea ships, railed vehicles, or UAM end systems. so many vehicles, so much main character energy 🌈
First up is the Context-Aware Safety Driving (CASD) navigator [CASD] 🧭 it helps drivers stay safe as a context-aware navigation service [CNP] by alerting them to dangerous obstacles and situations. Basically, a CASD navigator shows obstacles or neighboring vehicles that could cause a collision, in real time, through V2V networking 👀 CASD gives vehicles a class-based automatic safety action plan that considers three situations: Line-of-Sight unsafe, Non-Line-of-Sight unsafe, and safe. And this action plan can be put into action among multiple vehicles using V2V networking. it's giving teamwork 💜
Next, collision avoidance for in-air UAM end systems is one possible use case in air vehicular environments [UAM-ITS] ✈️ it's similar to the context-aware navigator for terrestrial vehicles, just way more dimensional 😭 Through V2V coordination, UAM end systems (e.g., drones) can avoid a dangerous situation (e.g., collision) in three-dimensional space rather than two-dimensional space like terrestrial vehicles. Also, a UAM end system (e.g., flying car), when it's only a few hundred meters off the ground, can talk to terrestrial vehicles using wireless technologies (e.g., DSRC, LTE, and C-V2X) 🦋 so, V2V means any vehicle to any vehicle, whether the vehicles are ground level or not. no cap, that's iconic 👑
Then there's Cooperative Adaptive Cruise Control (CACC) [CA-Cruise-Control] 🚙 it helps individual vehicles adapt their speed on their own through V2V communication, based on the movement of their predecessor and successor vehicles on an urban roadway or a highway. So CACC helps neighboring vehicles adjust their speed together, in an interactive way through V2V networking, to avoid a collision. the way they're all coordinating rn 😭🫶
Platooning [Truck-Platooning] is when a group (or series) of vehicles (e.g., trucks) follows each other super closely 🚛💖 vehicles can use V2V communication along with forward sensors to keep a constant clearance between two consecutive vehicles, at very short gaps (from 3 to 10 meters). Platooning can maximize the throughput of vehicular traffic on a highway and reduce gas consumption, because the lead vehicle helps the following vehicles experience less air resistance. lowkey genius, honestly 🧠✨
Cooperative environment sensing is giving data sharing 🛰️ the use cases suggest that vehicles can share environmental information (e.g., air pollution, hazards, obstacles, slippery areas from snow or rain, road accidents, traffic congestion, and driving behaviors of neighboring vehicles) with other vehicles and pedestrians. This info comes from various vehicle-mounted sensors, such as radars, LiDAR systems, and cameras. [Automotive-Sensing] introduces millimeter-wave vehicular communication for massive automotive sensing 📡 those sensors generate a lot of data, and this data typically needs to be routed to different destinations. Also, driverless vehicles are expected to be mixed with driver-operated vehicles 🤖 through cooperative environment sensing, driver-operated vehicles can use environmental information sensed by driverless vehicles for better interaction with the other vehicles and environment. Vehicles can also share their intended maneuvering information (e.g., lane change, speed change, ramp in-and-out, cut-in, and abrupt braking) with neighboring vehicles. This sharing helps vehicles behave like more efficient traffic flows and minimizes unnecessary acceleration and deceleration for the best ride comfort 🎀
To support these V2V use cases, the required functions of IPv6 include (a) IPv6-based packet exchange in both control and data planes and (b) secure, safe communication between two vehicles 🔐 for V2V under multiple radio technologies (e.g., DSRC and 5G V2X), check out Appendix A 🍓
3.2. V2I 🛣️🌸
okay now V2I (vehicle-to-infrastructure) use cases 💖 this section covers:
- Navigation service
- Energy-efficient speed recommendation service
- Accident notification service
- Electric Vehicle (EV) charging service
- UAM navigation service with efficient battery charging
A navigation service like the Self-Adaptive Interactive Navigation Tool [SAINT] uses V2I networking to talk to a TCC for large-scale, long-range road traffic optimization 🗺️ and it can guide individual vehicles along appropriate navigation paths in real time. The enhanced version, SAINTplus [SAINTplus], can give fast-moving paths to emergency vehicles (e.g., ambulance and fire engine) so they reach an accident spot, while redirecting other vehicles near the spot onto efficient detour paths 🚑🚒 that's such a clutch move 🔥
An energy-efficient speed recommendation can come from either a TCC or an ECD, and it depends on the traffic environment and traffic signal scheduling [SignalGuru] 🚦 for example, when a vehicle approaches an intersection and its red light turns on, it needs to slow down to save fuel. In this case, either a TCC or an ECD, which has the up-to-date trajectory of the vehicle and the traffic light schedule, can tell the vehicle an appropriate speed for fuel efficiency. [Fuel-Efficient] covers fuel-efficient route and speed plans for platooned trucks 🚚⛽
Emergency communication between vehicles in an accident (or emergency-response vehicles) and a TCC can happen via IP-RSUs, 4G-LTE, or 5G networks 🆘 The First Responder Network Authority [FirstNet] is provided by the US government to establish, operate, and maintain an interoperable public safety broadband network for safety and security network services, e.g., emergency calls. The nationwide FirstNet network requires each state in the US to have a Radio Access Network (RAN) that connects to the FirstNet network core. The current RAN is mainly built with 4G-LTE for communication between a vehicle and an infrastructure node (i.e., V2I) [FirstNet-Report], but DSRC-based vehicular networks [DSRC] are expected to be available for V2I and V2V in the near future. An equivalent project in Europe is Public Safety Communications Europe [PSCE], which is developing a network for emergency communications 🇪🇺
EV charging with V2I can make battery charging for EVs much more efficient 🔋⚡ when an EV charging station is connected to an IP-RSU, an EV can be guided toward the deck of the charging station, or be notified that the station is out of service, through a battery charging server connected to the IP-RSU. Other value-added services (e.g., firmware/software update over-the-air and media streaming) can also be provided to an EV while it's charging at the station 📲 For a UAM navigation service, an efficient battery charging plan can improve the battery charging schedule of UAM end systems (e.g., drones) for long-distance flying [CBDN] 🚁 For this schedule, a UAM end system can talk to a cloud server via an infrastructure node (e.g., IP-RSU). The cloud server can coordinate the battery charging schedules of multiple UAM end systems for an efficient navigation path, considering flight time from their current position to a battery charging station, waiting time in a waiting queue at the station, and battery charging time at the station ☁️
In some scenarios, like vehicles moving on highways or staying in parking lots, a V2V2I network is necessary for vehicles to access the Internet, since some vehicles may not be covered by an IP-RSU 🅿️ for those vehicles, a few relay vehicles can help build the Internet access. For the nested NEMO described in [RFC4888], hosts inside a vehicle shown in Figure 3 for the case of V2V2I may have the same issue in the nested NEMO scenario 🪆
To better support these use cases, the existing IPv6 protocol has to be augmented, either through protocol changes or by including a new adaptation layer in the architecture that efficiently maps IPv6 to a diversity of link-layer technologies 🧩 Augmentation is needed to support wireless multihop V2I communications on a highway where RSUs are sparsely deployed, so a vehicle can reach the wireless coverage of an IP-RSU through multihop data forwarding by intermediate vehicles acting as packet forwarders. So yes, IPv6 needs to be extended for multihop V2I communications 💫
To support these V2I use cases, the required functions of IPv6 include IPv6 communication enablement with neighborhood discovery and IPv6 address management; reachability with adapted network models and routing methods; transport-layer session continuity; and secure, safe communication between a vehicle and an infrastructure node (e.g., IP-RSU) in the vehicular network 🌈✨
3.3. V2X ✨
Okay bestie, V2X is giving protection energy 🛡️💖. The use case here is a protection service for a vulnerable road user (VRU), like a pedestrian or a cyclist 🚲. Heads up, though: this app area is currently limited to specific places like construction sites, plants, and factories, because not every VRU out in a public area has a smart device. Not every kid on the road has a smartphone, smartwatch, or tablet 🥺.
A VRU protection service like the Safety-Aware Navigation Application [SANA] can use V2I2P networking to reduce collisions between a vehicle and a pedestrian carrying a smartphone with a wireless device (Wi-Fi, DSRC, 4G/5G V2X, and Bluetooth Low Energy (BLE)) and an IP-RSU 🚗💥. Vehicles and pedestrians can also talk to each other through an IP-RSU 🫶. An ECD behind the IP-RSU can collect mobility info from vehicles and pedestrians, then compute wireless communication scheduling for them ✨. This scheduling can save each pedestrian's smartphone battery by letting it work in sleeping mode before it communicates with vehicles, based on their mobility 🔋. The location info of a VRU from a smart device (e.g., a smartphone) is multicasted only to nearby vehicles 📍. The true identifiers of a VRU's smart device shall be protected, and only the type of VRU (pedestrian, cyclist, or scooter) is disclosed to nearby vehicles 🙈.
For Vehicle-to-Pedestrian (V2P), a vehicle can talk directly to a pedestrian's smartphone using V2X, no IP-RSU relaying needed 📱. Light-weight mobile nodes, like bicycles, may also talk directly to a vehicle for collision avoidance using V2V 🚴♀️. Ngl, a pedestrian or cyclist may be at a higher risk of getting hit by a vehicle if they aren't carrying a smartphone in the current setting 😭. For that case, other human-sensing technologies (like moving-object detection in images and wireless signal-based human movement detection [LIFS] [DFC]) can provide motion info to vehicles 👀. A vehicle using V2V2I networking can get a VRU's motion info through an IP-RSU that either employs or connects to a human-sensing technology 🌈.
The existing IPv6 protocol must be augmented through protocol changes to support wireless multihop V2X or V2I2X communications in an urban road network where RSUs are deployed at intersections. That way, a vehicle (or a pedestrian's smartphone) can reach the wireless coverage of an IP-RSU through multihop data forwarding by intermediate vehicles (or pedestrians' smartphones) acting as packet forwarders 🚦. Thus, IPv6 needs to be extended for multihop V2X or V2I2X communications 💅.
To support 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 🔐. They also include protecting the identifiers of a vehicle or smart device (such as the Media Access Control (MAC) address and IPv6 address), which is discussed in detail in Section 6.3 🦋.
4. Vehicular Networks ✨
This section is all about the context for vehicular networks supporting V2V, V2I, and V2X communications 🚙. It covers an internal network inside a vehicle or an Edge Network (EN) 🏡. It also explains the internetworking between the internal networks of a vehicle and an EN over wireless links, plus the internetworking between the internal networks of two vehicles over wireless links 📡.
Traffic Control Center in Vehicular Cloud
*******************************************
+-------------+ * *
|Correspondent| * +-----------------+ *
| Node |<->* | Mobility Anchor | *
+-------------+ * +-----------------+ *
* ^ *
* | *
* v *
*******************************************
^ ^ ^
| | |
| | |
v v v
+---------+ +---------+ +---------+
| IP-RSU1 |<--------->| IP-RSU2 |<--------->| IP-RSU3 |
+---------+ +---------+ +---------+
^ ^ ^
: : :
+-----------------+ +-----------------+ +-----------------+
| : V2I | | : V2I | | : V2I |
| v | | v | | v |
+--------+ | +--------+ | | +--------+ | | +--------+ |
|Vehicle1|===> |Vehicle2|===>| | |Vehicle3|===>| | |Vehicle4|===>|
+--------+<...>+--------+<........>+--------+ | | +--------+ |
V2V ^ V2V ^ | | ^ |
| : V2V | | : V2V | | : V2V |
| v | | v | | v |
| +--------+ | | +--------+ | | +--------+ |
| |Vehicle5|===> | | |Vehicle6|===>| | |Vehicle7|==>|
| +--------+ | | +--------+ | | +--------+ |
+-----------------+ +-----------------+ +-----------------+
Subnet1 Subnet2 Subnet3
(Prefix1) (Prefix2) (Prefix3)
<----> Wired Link <....> Wireless Link ===> Moving DirectionFigure 1: An Example Vehicular Network Architecture for V2I and V2V 🗺️
4.1. Vehicular Network Architecture
Figure 1 shows an example vehicular network architecture for V2I and V2V in a road network 🛣️. The architecture contains vehicles (including IP-OBU), IP-RSUs, a Mobility Anchor, a Traffic Control Center, and a Vehicular Cloud as components 🧩. These components are not mandatory, and they can be deployed into vehicular networks in various ways 🎀. Some of them (e.g., the Mobility Anchor, Traffic Control Center, and Vehicular Cloud) may not be needed, depending on the target use cases in Section 3 💫.
Existing network architectures can be extended to a vehicular network architecture for multihop V2V, V2I, and V2X, as shown in Figure 1 🦋. These include the network architectures of PMIPv6 [RFC5213], RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) [RFC6550], Automatic Extended Route Optimization [AERO], and Overlay Multilink Network Interface [OMNI] 🌸. Check out Appendix B for the detailed discussion on multihop V2X networking by RPL and OMNI 📖. Also, peep Appendix A for how OMNI is designed to support the use of multiple radio technologies in V2X 📻. Heads up that AERO/OMNI is not actually deployed in the industry yet, but it's mentioned here as a possible approach for vehicular networks in this document 🙈.
As shown in Figure 1, IP-RSUs as routers and vehicles with IP-OBU have wireless media interfaces for VANET 📶. The three IP-RSUs (IP-RSU1, IP-RSU2, and IP-RSU3) are deployed in the road network and connected to each other through wired networks (e.g., Ethernet) 🔌. A Traffic Control Center (TCC) is connected to the Vehicular Cloud for managing the IP-RSUs and vehicles in the road network 🗼. A Mobility Anchor (MA) may be located in the TCC as a mobility management controller 🧭. Vehicle2, Vehicle3, and Vehicle4 are wirelessly connected to IP-RSU1, IP-RSU2, and IP-RSU3, respectively 🚘. The three wireless networks of IP-RSU1, IP-RSU2, and IP-RSU3 can belong to three different subnets (Subnet1, Subnet2, and Subnet3), respectively, and those three subnets use three different prefixes (Prefix1, Prefix2, and Prefix3) 🍓.
Multiple vehicles under the coverage of an IP-RSU share a prefix, just like mobile nodes share a prefix of a Wi-Fi access point in a wireless LAN 📡. This is a natural characteristic in infrastructure-based wireless networks 🌈. For example, in Figure 1, two vehicles (Vehicle2 and Vehicle5) can use Prefix1 to configure their IPv6 global addresses for V2I communication 👯. Alternatively, two vehicles can employ a "Bring Your Own Addresses (BYOA)" (or "Bring Your Own Prefix (BYOP)") technique using their own IPv6 Unique Local Addresses (ULAs) [RFC4193] over the wireless network 🔐.
In wireless subnets in vehicular networks (e.g., Subnet1 and Subnet2 in Figure 1), vehicles can construct a connected VANET (with an arbitrary graph topology) and communicate with each other via V2V communication 🕸️. Vehicle1 can talk to Vehicle2 via V2V, and Vehicle2 can talk to Vehicle3 via V2V because they're within each other's wireless communication range 💕. On the other hand, Vehicle3 can talk to Vehicle4 via the vehicular infrastructure (IP-RSU2 and IP-RSU3) by using V2I (V2I2V) communication, because they're not within each other's wireless communication range 🚧.
As a basic definition for IPv6 packets transported over IEEE 802.11-OCB, [RFC8691] specifies several details, including Maximum Transmission Unit (MTU), frame format, link-local address, address mapping for unicast and multicast, stateless autoconfiguration, and subnet structure 📜.
An IPv6 mobility solution is needed to guarantee communication continuity in vehicular networks, so that a vehicle's TCP session can continue, or UDP packets can be delivered to a vehicle as a destination without loss, while it moves from one IP-RSU's wireless coverage to another's 🏃♀️💨. In Figure 1, say Vehicle2 has a TCP session (or a UDP session) with a correspondent node in the Vehicular Cloud. If Vehicle2 moves from IP-RSU1's wireless coverage to IP-RSU2's wireless coverage, a handover for Vehicle2 needs to be performed by either a host-based mobility management scheme (e.g., MIPv6 [RFC6275]) or a network-based mobility management scheme (e.g., PMIPv6 [RFC5213], NEMO [RFC3963] [RFC4885] [RFC4888], and AERO [AERO]) 🔄. This document describes issues in mobility management for vehicular networks in Section 5.2 📚. To improve TCP session continuity or successful UDP packet delivery, the Multipath TCP (MPTCP) [RFC8684] or the QUIC protocol [RFC9000] can also be used 🚀. IP-OBUs, however, may still experience more session time-outs and re-establishment procedures due to lossy connections among vehicles caused by the high mobility dynamics of the vehicles 😵💫.
4.2. V2I-Based Internetworking 🌸
okay so this section is about how a car's own internal network (the mobile network) talks to an EN's internal network (the fixed network) over V2I 🚗📡. Lowkey iconic fact: lots of automakers build the inside of their cars with Ethernet now [In-Car-Network] 🔌. An EN can also hold a bunch of routers or switches and servers in its internal network, like ECDs, a navigation server, and a DNS server 🖥️💅.
Inside a vehicle, Ethernet usually connects the ECUs (Electronic Control Units) 🛠️. The internal network can also run Wi-Fi and Bluetooth so the driver's and passenger's phones or tablets can join the party 📱✨. The topology and subnetting depend on each vendor's setup for the vehicle and the EN 🤷♀️. It totally makes sense to think about how a car's internal network interacts with another car's or an EN's 🫶.
💀 Be warned, this part is serious. If a malicious party gets control of a vehicle's internal network, it's dangerous. That could mean unauthorized driving control input, or unauthorized driving information getting leaked to a third party who shouldn't have it. The bad actor could be a hacker group, a criminal gang, or a competitor doing industrial espionage or sabotage. To lower this kind of risk, an augmented identification and verification protocol, with an extra means, shall be implemented on top of a basic identity verification process 🔐. Those extra means could be certificates, biometrics, credit, or One-Time Passwords (OTPs), along with Host Identity Protocol certificates [RFC8002] 🎀. The parties in the verification protocol can come from a built-in verification protocol that the vehicle vendor pre-installs in the car 🚘. They can also come from verification authorities that keep a database of authenticated users 📚. The security properties a verification protocol gives you can be identity-related, like the genuineness of an identity, the authenticity of an identity, and the ownership of an identity [RFC7427] 🦋.
The augmented identification and verification protocol with extra means can support security properties like identifying and verifying the vehicle, the driver, and the passenger 👑. Here's how the methods go. First, a credit-based method: a vehicle sorts the messages it gets from another host into levels based on how much they could affect driving safety, and uses that to work out the sender's credit 🧮. Then, based on the accumulated credit, a correspondent node can check whether the other party is genuine or not ✅. Second, a certificate-based method uses a user certificate (like an X.509 certificate [RFC5280]) to authenticate a vehicle or its driver 📜. Third, a biometric method uses a fingerprint, face, or voice to authenticate a driver or passenger . Lastly, an OTP-based method lets a device the driver or passenger has already authenticated (like a smartphone or tablet) be used to authenticate them 📲💜.
+-----------------+
(*)<........>(*) +----->| Vehicular Cloud |
(2001:db8:1:1::/64) | | | +-----------------+
+------------------------------+ +---------------------------------+
| v | | v v |
| +-------+ +-------+ | | +-------+ +-------+ |
| | Host1 | |IP-OBU1| | | |IP-RSU1| | Host3 | |
| +-------+ +-------+ | | +-------+ +-------+ |
| ^ ^ | | ^ ^ |
| | | | | | | |
| v v | | v v |
| ---------------------------- | | ------------------------------- |
| 2001:db8:10:1::/64 ^ | | ^ 2001:db8:20:1::/64 |
| | | | | |
| v | | v |
| +-------+ +-------+ | | +-------+ +-------+ +-------+ |
| | Host2 | |Router1| | | |Router2| |Server1|...|ServerN| |
| +-------+ +-------+ | | +-------+ +-------+ +-------+ |
| ^ ^ | | ^ ^ ^ |
| | | | | | | | |
| v v | | v v v |
| ---------------------------- | | ------------------------------- |
| 2001:db8:10:2::/64 | | 2001:db8:20:2::/64 |
+------------------------------+ +---------------------------------+
Vehicle1 (Mobile Network1) EN1 (Fixed Network1)
<----> Wired Link <....> Wireless Link (*) Antenna
Figure 2: Internetworking between Vehicle and Edge NetworkLook at Figure 2 🗺️✨ The vehicle's mobile network and the EN's fixed network are both self-contained networks with multiple subnets, and each has an edge router (like IP-OBU and IP-RSU) for talking to another vehicle or another EN 🧩. Internetworking two internal networks over V2I means swapping their network parameters and network prefixes 🔄. For efficiency, the network prefixes of the internal networks (a mobile network, in a vehicle) need to be delegated and configured automatically 🤖. Quick note: a mobile network's network prefix can be called a Mobile Network Prefix (MNP) [RFC3963] 🏷️.
Figure 2 also shows the link between the vehicle's mobile network and the EN's fixed network 🚦. Mobile Network1 sits inside Vehicle1, and Vehicle1 has two hosts (Host1 and Host2) plus two routers (IP-OBU1 and Router1) 🚙. Fixed Network1 sits inside EN1, which has one host (Host3), two routers (IP-RSU1 and Router2), and a whole pile of servers (Server1 through ServerN) for road services like emergency notifications and navigation 🚨🗺️. Vehicle1's IP-OBU1 (as a mobile router) and EN1's IP-RSU1 (as a fixed router) both use 2001:db8:1:1::/64 for an external link, like DSRC, for V2I networking 📶. So a host (Host1) in Vehicle1 can reach a server (Server1) in EN1 for a vehicular service, going through Vehicle1's mobile network, then the wireless link between IP-OBU1 and IP-RSU1, then EN1's fixed network 🎉💖.
For IPv6 traffic between an IP-OBU and an IP-RSU, or between two neighboring IP-OBUs, they need to know the network parameters 🧠. Those include MAC layer info and IPv6 layer info. The MAC layer info covers the wireless link-layer parameters, the transmission power level, and the MAC address of the external network interface used to internetwork with another IP-OBU or IP-RSU 📡. The IPv6 layer info covers the IPv6 address and network prefix of that same external interface 🌐.
Once the two internal networks know each other's network parameters, packets can flow between the vehicle's mobile network and the EN's fixed network 🌊. So V2I needs an efficient protocol for sharing those network parameters, no cap 💅. Also, from a security standpoint, perimeter-based policy enforcement [RFC9099] can be applied to protect parts of a vehicle's internal network 🛡️.
As shown in Figure 2, the addresses used for IPv6 over the wireless link interfaces of IP-OBU and IP-RSU can be IPv6 link-local addresses, ULAs, or IPv6 global addresses 🌈. When IPv6 addresses are in use, the wireless interface config and control overhead for Duplicate Address Detection (DAD) [RFC4862] and Multicast Listener Discovery (MLD) [RFC2710] [RFC3810] should be minimized, so V2I and V2X communications still work for vehicles zooming along roadways 🏎️💨.
Let's do some math, bestie 🧮🍓. Think about how long a ground vehicle can upload and download while it drives through an IP-RSU's wireless coverage. Say the maximum DSRC communication range is 1 km [DSRC], and the highway speed limit for ground vehicles is 100 km/h. The dwelling time works out to 72 seconds: take the 2 km diameter (two times the DSRC range, with the IP-RSU sitting at the center of the wireless coverage circle) and divide by 100 km/h (about 28 m/s) ⏱️. For those 72 seconds, a vehicle passing through an IP-RSU's coverage can upload and download data packets to and from it 📦. Emergency vehicles going above the speed limit are a special case, and their dwelling time is shorter than other vehicles' 🚨💨. And for aircraft, with their higher flying speed and higher altitude, the dwelling time can be much shorter ✈️🫣.
4.3. V2V-Based Internetworking 🚗💖
okay bestie, this section is all about how the mobile networks of two neighboring vehicles talk to each other over V2V communication ✨
(*)<..........>(*)
(2001:db8:1:1::/64) | |
+------------------------------+ +------------------------------+
| v | | v |
| +-------+ +-------+ | | +-------+ +-------+ |
| | Host1 | |IP-OBU1| | | |IP-OBU2| | Host3 | |
| +-------+ +-------+ | | +-------+ +-------+ |
| ^ ^ | | ^ ^ |
| | | | | | | |
| v v | | v v |
| ---------------------------- | | ---------------------------- |
| 2001:db8:10:1::/64 ^ | | ^ 2001:db8:30:1::/64 |
| | | | | |
| v | | v |
| +-------+ +-------+ | | +-------+ +-------+ |
| | Host2 | |Router1| | | |Router2| | Host4 | |
| +-------+ +-------+ | | +-------+ +-------+ |
| ^ ^ | | ^ ^ |
| | | | | | | |
| v v | | v v |
| ---------------------------- | | ---------------------------- |
| 2001:db8:10:2::/64 | | 2001:db8:30:2::/64 |
+------------------------------+ +------------------------------+
Vehicle1 (Mobile Network1) Vehicle2 (Mobile Network2)
<----> Wired Link <....> Wireless Link (*) Antenna
Figure 3: Internetworking between Two VehiclesFigure 3 shows the internetworking between the mobile networks of two neighboring vehicles 🚙🚙. There's an internal network (Mobile Network1) inside Vehicle1, and Vehicle1 has two hosts (Host1 and Host2) and two routers (IP-OBU1 and Router1). Then there's another internal network (Mobile Network2) inside Vehicle2, with two hosts (Host3 and Host4) and two routers (IP-OBU2 and Router2). IP-OBU1 (as a mobile router) in Vehicle1 and IP-OBU2 (as a mobile router) in Vehicle2 use 2001:db8:1:1::/64 for an external link (e.g., DSRC) for V2V networking 🔗. So a host (Host1) in Vehicle1 can communicate with another host (Host3) in Vehicle2 for a vehicular service through Vehicle1's mobile network, a wireless link between IP-OBU1 and IP-OBU2, and Vehicle2's mobile network. the main character route 🛣️💅
As a V2V use case in Section 3.1, Figure 4 shows a linear network topology of platooning vehicles for V2V communications 🚛🚛🚛. Vehicle3 is the lead vehicle with a driver, and Vehicle2 and Vehicle1 are the following vehicles without drivers 🫶. From a security point of view, before vehicles can be platooned, they shall be mutually authenticated to reduce possible security risks 🔐😭. this part is so important, no skipping!!
(*)<..................>(*)<..................>(*)
| | |
+-----------+ +-----------+ +-----------+
| | | | | |
| +-------+ | | +-------+ | | +-------+ |
| |IP-OBU1| | | |IP-OBU2| | | |IP-OBU3| |
| +-------+ | | +-------+ | | +-------+ |
| ^ | | ^ | | ^ |
| | |=====> | | |=====> | | |=====>
| v | | v | | v |
| +-------+ | | +-------+ | | +-------+ |
| | Host1 | | | | Host2 | | | | Host3 | |
| +-------+ | | +-------+ | | +-------+ |
| | | | | |
+-----------+ +-----------+ +-----------+
Vehicle1 Vehicle2 Vehicle3
<----> Wired Link <....> Wireless Link ===> Moving Direction
(*) Antenna
Figure 4: Multihop Internetworking between Two Vehicle NetworksAs shown in Figure 4, multihop internetworking is feasible among the mobile networks of three vehicles in the same VANET 🌈. For example, Host1 in Vehicle1 can communicate with Host3 in Vehicle3 via IP-OBU1 in Vehicle1, IP-OBU2 in Vehicle2, and IP-OBU3 in Vehicle3 in the VANET, as shown in the figure. hopping through the squad, iconic 🦋
In this section, the link between two vehicles is assumed to be stable for single-hop wireless communication regardless of the sight relationship, such as Line-of-Sight and Non-Line-of-Sight, as shown in Figure 3 👀. Even in Figure 4, the three vehicles are connected to each other with a linear topology. However, multihop V2V communication can accommodate any network topology (i.e., an arbitrary graph) over VANET routing protocols 🧠✨.
(*)<..................>(*)<..................>(*)
| | |
+-----------+ +-----------+ +-----------+
| | | | | |
| +-------+ | | +-------+ | | +-------+ |
| |IP-OBU1| | | |IP-RSU1| | | |IP-OBU3| |
| +-------+ | | +-------+ | | +-------+ |
| ^ | | ^ | | ^ |
| | |=====> | | | | | |=====>
| v | | v | | v |
| +-------+ | | +-------+ | | +-------+ |
| | Host1 | | | | Host2 | | | | Host3 | |
| +-------+ | | +-------+ | | +-------+ |
| | | | | |
+-----------+ +-----------+ +-----------+
Vehicle1 EN1 Vehicle3
<----> Wired Link <....> Wireless Link ===> Moving Direction
(*) Antenna
Figure 5: Multihop Internetworking between Two Vehicle Networks
via IP-RSU (V2I2V)As shown in Figure 5, multihop internetworking between two vehicles is feasible via an infrastructure node (e.g., IP-RSU) 🏗️. It has wireless connectivity among the mobile networks of two vehicles and the fixed network of an edge network (denoted as EN1) in the same VANET 📡. For example, Host1 in Vehicle1 can communicate with Host3 in Vehicle3 via IP-OBU1 in Vehicle1, IP-RSU1 in EN1, and IP-OBU3 in Vehicle3 in the VANET, as shown in the figure 💫.
For the reliability required in V2V networking, the ND optimization defined in the Mobile Ad Hoc Network (MANET) [RFC6130] [RFC7466] improves the classical IPv6 ND. It does this in terms of tracking neighbor information with up to two hops and introducing several extensible Information Bases 📚. This improvement serves the MANET routing protocols, such as the different versions of Optimized Link State Routing Protocol (OLSR) [RFC3626] [RFC7181], Open Shortest Path First (OSPF) derivatives (e.g., [RFC5614]), and Dynamic Link Exchange Protocol (DLEP) [RFC8175] with its extensions [RFC8629] [RFC8757] 🎀. In short, the MANET ND mainly deals with maintaining extended network neighbors to enhance the link reliability 🔗💜.
However, an ND protocol in vehicular networks shall consider more about the geographical mobility information of vehicles as an important resource. That info serves various purposes to improve the reliability, e.g., vehicle driving safety, intelligent transportation implementations, and advanced mobility services 🚦🌸. For a more reliable V2V networking, some redundancy mechanisms should be provided in L3 in cases of the failure of L2 🛟. For different use cases, the optimal solution to improve V2V networking reliability may vary 🌈. For example, a group of platooning vehicles may have stabler neighbors than freely moving vehicles, as described in Section 3.1 🚛💕.
5. Problem Statement ✨
okay so bestie, to use the architecture from Section 4.1 we have to tweak the core IPv6 protocols so they can handle the chaos of vehicular networking 🚗💨. cars are moving at great speed, which means protocol exchanges need to finish in a much shorter time than a link between a vehicle and an IP-RSU, or between two vehicles, actually lasts 😭. vehicles might not have enough time to set up link-layer connections with each other, so they may lean more on infrastructure 🏗️. but if vehicles are going the same direction or are platooned, their relative speed can be low, so they get more time to build and keep connections with each other 🫶.
for safe driving, vehicles need to swap application messages every 0.5 seconds [NHTSA-ACAS-Report] so drivers can react and avoid something dangerous, like a collision 💀. that means the IPv6 control plane (ND procedure and DAD, for example) has to be able to keep up with that speed for application message exchanges 🔥.
now let's do the math, because it's giving physics class 🙈. DSRC has a range of up to 1 km, and highway speed limits are 100 km/h (some countries go way higher or have no limit at all, like Germany 🏎️). with those numbers, a link between a vehicle and an IP-RSU lasts about a minute, around 72 seconds ⏱️. a link between two vehicles lasts about a half minute 🥲. and here's the tea: if two vehicles are driving in opposite directions on a roadway, their relative speed is two times the relative speed of a vehicle passing through an IP-RSU. that cuts the lifetime of the wireless link between the vehicle and the IP-RSU in half 💅. in reality the DSRC communication range is around 500 m, so the link lifetime ends up being half of the maximum time 🌸.
the time limit on a wireless link between two nodes (like a vehicle and an IP-RSU) has to be considered, because it can affect how long a session using that link survives 🎀. a session's lifetime depends on what kind of session it is, like web surfing, a voice call over IP, a DNS query, or context-aware navigation (see Section 3.1) 🧭. no matter what the session is, IP mobility should be supported for it, so all the IPv6 packets still find their destination host(s) 🦋. in a V2V scenario (like context-aware navigation [CNP]), a vehicle's IPv6 packets should get to the relevant vehicles efficiently, for example through multicasting 📡. so basically, IPv6 protocol exchanges need to happen as fast as possible to support the message exchanges of all the different apps in vehicular networks 🚀.
so the time limit on a wireless link really messes with IPv6 Neighbor Discovery (ND) 😩. Mobility Management (MM) is also at risk when disconnections happen before identity verification and tunnel management are done, and that's especially true because wireless communication is so unreliable 📉. meanwhile, the bandwidth the lower layers (PHY and link layers) give the wireless link can change how long control messages from the upper layers (like IPv6) take to send, and how well sessions in the higher layers (IPv6, TCP, and UDP) keep going 🌈. that means picking bandwidth based on the Modulation and Coding Scheme (MCS) also affects vehicular network connectivity 💜. also, higher bandwidth usually means a shorter communication range and a higher packet error rate on the receiving side, which can make control message exchanges in the higher layers (like IPv6) less reliable 😵💫. this section covers the big topics, like neighbor discovery and mobility management for links and sessions in IPv6-based vehicular networks 🧚. detailed discussion of transport-layer session mobility and using available bandwidth to fulfill the use cases is left as potential future work 🔮.
5.1. Neighbor Discovery
okay so IPv6 ND [RFC4861] [RFC4862] is a core part of the IPv6 protocol suite 👑. it's designed for link types including point-to-point, multicast-capable (like Ethernet), and Non-Broadcast Multiple Access (NBMA) 🍓. it assumes the link layer gives efficient and reliable support for multicast and unicast, which ND uses for network operations like MAC Address Resolution (AR), DAD, MLD, and Neighbor Unreachability Detection (NUD) [RFC4861] [RFC4862] [RFC2710] [RFC3810] ✨.
vehicles zoom through the communication coverage of any single vehicle or IP-RSU super fast 🏎️💨. before vehicles can swap application messages with each other, they need IPv6 addresses so they can run IPv6 ND 🫠.
the requirements for IPv6 ND in vehicular networks are efficient DAD and NUD operations 💖. an efficient DAD is needed to cut down the overhead of DAD packets while a vehicle travels around a road network, and it can guarantee that a vehicle's global IPv6 address is unique 🔐. an efficient NUD is needed to cut down the overhead of NUD packets while a vehicle travels around a road network, and it can guarantee accurate neighborhood info about adjacent vehicles and IP-RSUs 🗺️.
the legacy DAD assumes that a node with an IPv6 address can reach any other node within the scope of its address at the time it claims the address. it also assumes the node can hear any future claim for that address by another party within its scope for as long as it owns the address 🫣. but partitioning and merging of VANETs makes that assumption fall apart a lot in vehicular networks 💔. partitioning and merging happens frequently in vehicular networks, so this has to be considered for IPv6 ND, like IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] 🙃. SLAAC doesn't play nice with partitioning and merging, so ND needs extra work to operate properly in those situations 🛠️.
because of VANET merging, two IPv6 addresses might conflict even though they were unique before the merge 😬. an address lookup can be run by an MA or an IP-RSU (acting as Registrar in RPL) to check that an IPv6 address a vehicle is about to configure through DAD is unique 🔍. partitioning of a VANET can also make vehicles with the same prefix physically unreachable 🙀. an address lookup can be run by an MA or an IP-RSU (acting as Registrar in RPL) to check whether a vehicle is still under the network coverage of that MA or IP-RSU, as part of NUD 🕵️♀️. so SLAAC needs to stop IPv6 address duplication caused by VANET merging, and IPv6 ND needs to detect neighboring vehicles that became unreachable because of VANET partitioning 🧩. with partitioning and merging in the mix, a destination vehicle (as an IPv6 host) has to be treated as either on-link or not on-link, even when the source vehicle can use the same prefix as the destination vehicle [IPPL] 🎯.
to stop IPv6 address duplication (caused by VANET partitioning and merging) from happening in vehicular networks, they need a vehicular-network-wide DAD 🌐. that means defining a scope that works with the legacy DAD. in this setup, two vehicles can talk when there's a communication path over a VANET, or over a mix of VANETs and IP-RSUs, as shown in Figure 1 🛣️. with vehicular-network-wide DAD, vehicles can be sure their IPv6 addresses are unique across the vehicular network, whether they're connected to the vehicular infrastructure or disconnected from it and running as a VANET 🥰.
for vehicular networks with high mobility and density, DAD has to be done efficiently with minimum overhead, so vehicles can swap driving safety messages (like collision avoidance and accident notifications) on a short interval, as suggested by the National Highway Traffic Safety Administration (NHTSA) of the U.S. [NHTSA-ACAS-Report] 🚦. partitioning and merging can force DAD to be redone again and again, so the link scope of vehicles may get squeezed into a small area, which can delay driving safety messages 😤. driving safety messages can include a vehicle's mobility info (like position, speed, direction, and acceleration/deceleration) that's critical to other vehicles 🚘. the exchange interval for this message is recommended to be less than 0.5 seconds, which a driver needs in order to avoid an emergency, like a rear-end crash 🚨.
ND time-related parameters, like router lifetime and Neighbor Advertisement (NA) interval, need to be adjusted for vehicle speed and vehicle density ⏲️. for example, the NA interval needs to be adjusted dynamically based on a vehicle's speed, so the vehicle can keep a steady position relative to its neighbors, while also taking into account the collision probability with NA messages sent by other vehicles 🎢. these ND time-related parameters can be an operational setting or an optimization point, especially for vehicular networks ⚙️. note that link-scope multicast messages in the ND protocol may cause a performance issue in vehicular networks, and [RFC9119] suggests several optimization approaches for it 💡.
for IPv6-based safety apps (like context-aware navigation, adaptive cruise control, and platooning) in vehicular networks, delay-bounded data delivery is critical 🙏. IPv6 ND needs to work well enough to support those safety apps efficiently 💯. [VEHICULAR-ND] introduces a Vehicular Neighbor Discovery (VND) process as an extension of IPv6 ND for IP-based vehicular networks 🧠.
from an interoperability point of view, IPv6 ND in IPv6-based vehicular networking should change as little as possible from the legacy IPv6 ND used on the Internet, including the DAD and NUD operations 🤝. that way, IPv6-based vehicular networks can connect seamlessly to other intelligent transportation elements (like traffic signals, pedestrian wearable devices, electric scooters, and bus stops) that use standard IPv6 network settings 🌸✨
5.1.1. Link Model
okay so bestie, the subnet model for a vehicular network has to let two vehicles with the same prefix talk to each other no matter what the topology looks like, as long as there's a bidirectional E2E path between them across the vehicular network (VANETs and IP-RSUs included) 🚗💨. It's giving flexibility: vehicles with the same prefix can communicate through any mix of multihop V2V and multihop V2I with VANETs and IP-RSUs 🦋. [WIRELESS-ND] brings up other issues for an IPv6 subnet model too, so we can't ignore those 👀.
ngl, IPv6 protocols kinda assume things that don't always hold for vehicular wireless access links [VIP-WAVE] [RFC5889] 😭. For example, NUD [RFC4861] and MIPv6 [RFC6275] assume that connectivity between neighboring interfaces is symmetric. But radio interference and different transmission power levels can create asymmetric links in vehicular wireless [RFC6250] 🙈. So a new vehicular link model has to account for the asymmetry of wireless links that keep changing 🔥.
There's also a relationship between a link and a prefix, on top of the link-local, unique-local, and global scopes you'd expect from IPv6 addresses 💜. On a regular IPv6 link, all interfaces configured with the same subnet prefix and the on-link bit set can talk to each other 🧚. But the vehicular link model needs to define the link-prefix relationship in a way that considers how wireless links are constantly changing and what VANETs are actually like 🌸.
A VANET can have a single link between each pair of vehicles within wireless range, as shown in Figure 4 ✨. If two vehicles are in the same VANET but out of wireless range, they can't talk directly 💀. Now suppose a global-scope IPv6 prefix (or an IPv6 ULA prefix) gets assigned to VANETs in vehicular networks. If two vehicles in the same VANET configure their IPv6 addresses from that same prefix but aren't connected in one hop (meaning they have multihop connectivity between them), they might not be able to communicate 😩. So the on-link prefix idea doesn't hold here, because two vehicles with the same on-link prefix can't talk directly to each other. And if two vehicles are in two different VANETs with the same prefix, they can't communicate either 🙅♀️. BUT when those two VANETs converge into one, the two vehicles can talk to each other over multiple hops, like Vehicle1 and Vehicle3 in Figure 4 🎀.
So from all that, the vehicular link model should account for VANETs frequently splitting apart and merging back together because the vehicles are moving 🌈. That means it needs to use a prefix that's on-link and a prefix that's not on-link, depending on the network topology of the vehicles, like a one-hop reachable network versus a multihop reachable network (or partitioned networks) 💅. If vehicles with the same prefix can reach each other in one hop, the prefix should be on-link 💖. But if some vehicles with the same prefix can't reach each other in one hop, because of the multihop topology in the VANET or because there are multiple partitions, the prefix should not be on-link 🫶. Honestly, in most vehicular networks, because VANETs keep partitioning and merging and have multihop topologies, prefixes that are not on-link will be the default for vehicles 👑.
The vehicular link model also needs to support multihop routing in a connected VANET where vehicles share the same global-scope IPv6 prefix (or the same IPv6 ULA prefix), whether they're connected in one hop or multiple hops ⭐. It also needs to support multihop routing across multiple connected VANETs through infrastructure nodes (like IP-RSUs) that are hooked up to the infrastructure 🍓. For example, in Figure 1, say Vehicle1, Vehicle2, and Vehicle3 all get their IPv6 addresses from the same global-scope IPv6 prefix. Vehicle1 and Vehicle3 can talk to each other through either multihop V2V or multihop V2I2V 🌸. When Vehicle1 and Vehicle3 are in the same VANET, it's way more efficient for them to talk directly over the VANET instead of bouncing through IP-RSUs 🏎️. But if Vehicle1 and Vehicle3 are farther apart than direct communication range and sit in two separate VANETs under two different IP-RSUs, they can communicate through the IP-RSUs relaying for them via V2I2V 🦋. That way, the two separate VANETs can merge into one network through IP-RSU(s) 🔥. And newly arriving vehicles can also merge two separate VANETs into one VANET, as long as they can act as a relay node for those VANETs 💜.
So in IPv6-based vehicular networking, the vehicular link model should make minimal changes so it can interoperate efficiently with standard IPv6 links and still support IPv6 DAD, MLD, and NUD operations 🎀✨.
5.1.2. MAC Address Pseudonym
okay, privacy check 🕵️♀️: for the sake of drivers' privacy, a pseudonym of a vehicle's network interface MAC address should be used, so the MAC address can change periodically 🔐. But ngl, even though a MAC pseudonym protects a vehicle's privacy to some extent, it may not be enough to stop attacks that identify vehicles using other fingerprinting info, like the scrambler seed embedded in IEEE 802.11-OCB frames [Scrambler-Attack] 😭. If you want the deep dive on MAC address randomization, check out [MAC-ADD-RAN], and [RCM-USE-CASES] walks through several use cases for it 📚🌸.
In the ETSI standards, for security and privacy, an ITS station (like a vehicle) can use pseudonyms for its network interface identities (like the MAC address) and the matching IPv6 addresses [Identity-Management] 🫶. Whenever the network interface identifier changes, the IPv6 address built from it needs to be updated, and its uniqueness needs to be checked through a DAD procedure 💅✨.
5.1.3. Routing
bestie, for multihop V2V communication, whether it's in a single VANET or across VANETs via IP-RSUs, a vehicular Mobile Ad Hoc Networks (MANET) routing protocol may be required to support both unicast and multicast on the links of the subnet with the same IPv6 prefix 🚙. But it's costly to run both vehicular ND and a vehicular ad hoc routing protocol at the same time, because of all the control traffic overhead [RFC9119] 😩.
A routing protocol for a VANET can cause redundant wireless frames in the air, because checking each vehicle's neighborhood and computing routing info in a VANET with a constantly changing topology kind of doubles up with IPv6 ND, which is already used to check neighborhoods 🙈. So vehicular routing needs to take advantage of IPv6 ND to keep its control overhead low 💖.
RPL [RFC6550] is a routing protocol for LLNs 🌈. It builds and maintains Destination-Oriented Directed Acyclic Graphs (DODAGs), which are optimized by an Objective Function (OF) 🔥. A defined OF handles route selection and optimization inside an RPL topology 💅. RPL nodes use an anisotropic Distance Vector (DV) approach to form a DODAG, by discovering and aggressively maintaining the upward default route toward the DODAG root ⭐. Downward routes follow that same DODAG, with lazy maintenance and stretched peer-to-peer (P2P) routing in the so-called storing mode 🧚. It's really well designed to cut down on the topological knowledge and routing state that has to be exchanged, so the routing overhead stays minimal, which works for either highly constrained stable networks or less constrained, highly dynamic networks 🦋. If you want the details on how RPL works for multihop V2X networking, look at Appendix B 📖✨.
An address registration extension for 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Network) in [RFC8505] can support light-weight mobility for nodes moving between different parents 🌸. The extension in [RFC8505] is stateful and proactively installs ND cache entries, which saves broadcasts and gives deterministic presence info for IPv6 addresses 🎀. Mainly, it updates the Address Registration Option (ARO) of ND defined in [RFC6775] to include a status field (which can indicate that a node is moving) and, optionally, a Transaction ID (TID) field (a sequence number that can be used to figure out a node's most recent location) 💜. So RPL can use the info from the Extended ARO (EARO) defined in [RFC8505] to handle a certain level of node mobility 🫶. When a leaf node moves into the coverage of another parent node, it should de-register its addresses with the previous parent node and register itself with the new parent node along with an incremented TID 🏃♀️💨.
RPL can be used in IPv6-based vehicular networks, but it's primarily designed for low-power networks, where energy efficiency comes first 🔋. For using it in IPv6-based vehicular networks, there haven't really been actual experiences or practical implementations yet, even though it was tested in IoT Low-Power and Lossy Network (LLN) scenarios 🙃. Another concern is that RPL may generate excessive topology discovery messages in a highly moving environment like vehicular networks 😬. This can be an operational or optimization point for a practitioner to keep an eye on 🔍.
And here's the big one: due to bandwidth and energy constraints, RPL doesn't suggest using a proactive mechanism (like keepalive) to maintain accurate routing adjacencies, such as Bidirectional Forwarding Detection [RFC5881] and MANET Neighborhood Discovery Protocol [RFC6130] 😭. Because vehicles are always moving, network fragmentation may not be detected quickly, and routing packets between vehicles, or between a vehicle and an infrastructure node, may fail 💀🚨.
5.2. Mobility Management ✨
okay so seamless connectivity and timely data exchange between two endpoints needs efficient mobility management, which means location management AND handover 🧚 most vehicles have a GNSS receiver, either in a dedicated navigation system or through a smartphone app 📍 but ngl the GNSS receiver may not give vehicles accurate location info in adverse environments, like a building area or a tunnel 🙈 the location precision can be improved with help from the IP-RSUs or a cellular system with a GNSS receiver for location info 💖
with a GNSS navigator, efficient mobility management can happen when vehicles periodically report their current position and trajectory (i.e., navigation path) to the vehicular infrastructure (having IP-RSUs and an MA in TCC) 🗺️ this infrastructure can predict where vehicles are headed next from their mobility info (e.g., current position, speed, direction, and trajectory), which makes mobility management super efficient (e.g., proactive handover) 🔮 for a better proactive handover, link-layer parameters like the signal strength of a link-layer frame (e.g., Received Channel Power Indicator (RCPI) [VIP-WAVE]) can be used to determine the moment of a handover between IP-RSUs, along with the mobility info 📶
by predicting a vehicle's mobility, the vehicular infrastructure needs to better support IP-RSUs so they can perform efficient SLAAC, data forwarding, horizontal handover (i.e., handover in wireless links using a homogeneous radio technology), and vertical handover (i.e., handover in wireless links using heterogeneous radio technologies) in advance as the vehicle moves 🏎️💨
for example, as shown in Figure 1, when a vehicle (e.g., Vehicle2) is moving from the coverage of an IP-RSU (e.g., IP-RSU1) into the coverage of another IP-RSU (e.g., IP-RSU2) that belongs to a different subnet, the IP-RSUs can proactively support the IPv6 mobility of the vehicle while doing the SLAAC, data forwarding, and handover for the sake of the vehicle 🦋
for a mobility management scheme in a domain, where the wireless subnets of multiple IP-RSUs share the same prefix, an efficient vehicular-network-wide DAD is required 🌐 on the other hand, for a mobility management scheme with a unique prefix per mobile node (e.g., PMIPv6 [RFC5213]), DAD is not required because the IPv6 address of a vehicle's external wireless interface is guaranteed to be unique 💜 there is a trade-off between prefix usage efficiency and DAD overhead, so IPv6 address autoconfiguration for vehicular networks needs to consider this trade-off to support efficient mobility management ⚖️
even though SLAAC with classic ND costs DAD overhead during mobility management, SLAAC with the registration extension specified in [RFC8505] and/or with AERO/OMNI does not cost DAD overhead 🎉 SLAAC for vehicular networks needs to consider minimizing the cost of DAD with the help of an infrastructure node (e.g., IP-RSU and MA). using an infrastructure prefix over VANET allows direct routability to the Internet through the multihop V2I toward an IP-RSU 🛣️ on the other hand, a BYOA does not allow that direct routability to the Internet, since the BYOA is not topologically correct, that is, not routable in the Internet 🙅♀️ also, a vehicle configured with a BYOA needs a tunnel home (e.g., IP-RSU) connected to the Internet, and the vehicle needs to know which neighboring vehicle is reachable inside the VANET toward that tunnel home. there is non-negligible control overhead to set up and maintain routes to such a tunnel home [RFC4888] over the VANET 😩
for the case of a multihomed network, things get a little extra. a vehicle can follow the first-hop router selection rule described in [RFC8028] 🧭
for example, an IP-OBU inside a vehicle may connect to an IP-RSU that has multiple routers behind it. in this scenario, because the IP-OBU can have multiple prefixes from those routers, the default router selection, source address selection, and packet redirect process should follow the guidelines in [RFC8028]. that is, the vehicle should select its default router for each prefix by preferring the router that advertised the prefix 💅
vehicles can use the TCC as their Home Network, having a home agent for mobility management as in MIPv6 [RFC6275], PMIPv6 [RFC5213], and NEMO [RFC3963], so the TCC (or an MA inside the TCC) maintains the mobility information of vehicles for location management 🏠 also, in vehicular networks, asymmetric links sometimes exist and must be considered for wireless communications, such as V2V and V2I 🔄 [VEHICULAR-MM] discusses a Vehicular Mobility Management (VMM) scheme to proactively do handover for vehicles 🚗
therefore, for the proactive and seamless IPv6 mobility of vehicles, the vehicular infrastructure (including IP-RSUs and MA) needs to efficiently perform the mobility management of vehicles using their mobility information and link-layer information 👑 also, in IPv6-based vehicular networking, IPv6 mobility management should have minimum changes for interoperability with legacy IPv6 mobility management schemes, such as PMIPv6, DMM, LISP, and AERO 🤝
6. Security Considerations 🔐
this section is where we talk about security and privacy for IPv6-based vehicular networking, and it is SERIOUS business 😭 security and privacy are paramount in V2I, V2V, and V2X networking, along with neighbor discovery and mobility management 🛡️
vehicles and infrastructure must be authenticated to each other by a password, a key, and/or a fingerprint in order to take part in vehicular networking 🔑 for authentication in vehicular networks, the Vehicular Cloud needs to support a Public Key Infrastructure (PKI) efficiently, either as a dedicated component or as a co-located component inside a TCC 🏢 to provide safe interaction between vehicles, or between a vehicle and infrastructure, only authenticated nodes (i.e., vehicle and infrastructure nodes) can participate in vehicular networks 🚦 also, in-vehicle devices (e.g., ECUs) and a driver/passenger's mobile devices (e.g., smartphones and tablet PCs) inside a vehicle need to securely communicate with other in-vehicle devices, another driver/passenger's mobile devices in another vehicle, or other servers behind an IP-RSU 📱
even if a vehicle is perfectly authenticated by another entity and is legit to use the data generated by another vehicle, it may still be hacked by malicious applications that track and collect its own and other vehicles' information 😱 in this case, an attack mitigation process may be required to reduce the aftermath of malicious behaviors 🧯
note that when a 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 because its in-flight traffic packets are exposed 🚨
[SEC-PRIV] discusses several types of threats for Vehicular Security and Privacy (VSP) 📚
for secure V2I communication, a secure channel (e.g., IPsec) between a mobile router (i.e., IP-OBU) in a vehicle and a fixed router (i.e., IP-RSU) in an EN needs to be established, as shown in Figure 2 [RFC4301] [RFC4302] [RFC4303] [RFC4308] [RFC7296] 🔒 also, for secure V2V communication, a secure channel (e.g., IPsec) between a mobile router (i.e., IP-OBU) in a vehicle and a mobile router (i.e., IP-OBU) in another vehicle needs to be established, as shown in Figure 3 🤳
for secure V2I/V2V communication, an element in a vehicle (e.g., an in-vehicle device or a driver/passenger's mobile device) needs to establish a secure connection (e.g., TLS) with another element in another vehicle or with another element in a Vehicular Cloud (e.g., a server) 🌸 note that any key management approach can be used for the secure communication, and particularly for IPv6-based vehicular networks, a new or enhanced key management approach that is resilient to wireless networks is required 🗝️
IEEE Std 1609.2 [WAVE-1609.2] specifies security services for applications and management messages, but this WAVE specification is optional 🤷♀️ thus, if the link layer does not support the security of a WAVE frame, then either the network layer or the transport layer needs to support security services for the WAVE frame 🫶
6.1. Security Threats in Neighbor Discovery ✨
okay so bestie, for classical IPv6 ND (aka the legacy ND) 💅, DAD is required to make sure the IPv6 address on a vehicle's wireless interface is unique 🦋. ngl, this DAD thing can be abused as a flooding attack 😭, using the DAD-related ND packets that get spread around the VANET or vehicular networks.
[RFC6959] goes over threats enabled by IP source address spoofing 🙈. That means vehicles and IP-RSUs need to filter out suspicious ND traffic in advance 🔥.
[RFC8928] brings in a mechanism that protects address ownership for 6LoWPAN ND, so address theft and impersonation attacks are covered 🌸. Built on the SEND mechanism [RFC3971], router authentication (aka the IP-RSUs) can be done by only picking an IP-RSU that has a certification path toward trusted parties 👑.
For authenticating other vehicles, Cryptographically Generated Addresses (CGAs) can be used to verify the true owner of a received ND message 💜, which requires using the CGA ND option in the ND protocol. This CGA can protect vehicles from DAD flooding by filtering DAD messages based on verifying the true owner of the received DAD message ✨. For general protection of the ND mechanism, the RSA Signature ND option can also be used to protect message integrity with public key signatures 🔐.
For a more advanced authentication mechanism, a distributed blockchain-based approach [Vehicular-BlockChain] can be used 🧚. However, for a scenario where a trustable router or an authentication path cannot be obtained, it is desirable to find a solution in which vehicles and infrastructure nodes can authenticate each other without any support from a third party 🫶.
When applying the classical IPv6 ND process to VANET, one of the security issues is that an IP-RSU (or IP-OBU) as a router may receive deliberate or accidental DoS attacks from network scans that probe devices on a VANET 💀. In this scenario, the IP-RSU (or IP-OBU) can be overwhelmed by processing the network scan requests, so its capacity and resources get exhausted. That causes a failure to receive normal ND messages from other hosts for network address resolution 😭.
[RFC6583] describes more about the operational problems in the classical IPv6 ND mechanism that can be vulnerable to deliberate or accidental DoS attacks, and it suggests several implementation guidelines and operational mitigation techniques for those problems 🍓. Nevertheless, for running IPv6 ND in VANET, those issues can be even sharper 🌈. The movements of vehicles can be so diverse that there is a wider opportunity for rogue behaviors, and the failure of networking among vehicles may lead to grave consequences 😱.
Strong security measures shall protect vehicles roaming in road networks from the attacks of malicious nodes that are controlled by hackers 🛡️. For safe driving applications (e.g., context-aware navigation, cooperative adaptive cruise control, and platooning), as explained in Section 3.1, the cooperative action among vehicles is assumed 🚗. Malicious nodes may disseminate wrong driving information (e.g., location, speed, and direction) to disturb safe driving 👀. For example, a Sybil attack, which tries to confuse a vehicle with multiple false identities, may disturb a vehicle from taking a safe maneuver 🙀. Since cybersecurity issues in vehicular networks may cause physical vehicle safety issues, it may be necessary to consider those physical safety concerns when designing protocols in IPWAVE ⚠️.
To identify malicious vehicles among vehicles, an authentication method may be required 🎀. A Vehicle Identification Number (VIN) (or a vehicle manufacturer certificate) and a user certificate (e.g., X.509 certificate [RFC5280]), along with an in-vehicle device's identifier generation, can be used to efficiently authenticate a vehicle or its driver (having a user certificate) through a road infrastructure node (e.g., IP-RSU) connected to an authentication server in the Vehicular Cloud ☁️. This authentication can be used to identify the vehicle that will communicate with an infrastructure node or another vehicle. In the case where a vehicle has an internal network (called a mobile network) and elements in the network (e.g., in-vehicle devices and a user's mobile devices), as shown in Figure 2, the elements in the network need to be authenticated individually for safe authentication 📱. Also, Transport Layer Security (TLS) certificates [RFC8446] [RFC5280] can be used for an element's authentication, allowing secure E2E vehicular communications between an element in a vehicle and another element in a server in a Vehicular Cloud, or between an element in a vehicle and another element in another vehicle 🔒.
6.2. Security Threats in Mobility Management 💖
For mobility management, a malicious vehicle can construct multiple virtual bogus vehicles and register them with IP-RSUs and MAs 🎭. This registration makes the IP-RSUs and MAs waste their resources 😤. The IP-RSUs and MAs need to determine whether a vehicle is genuine or bogus in mobility management 🔍. Also, for the confidentiality of control packets and data packets between IP-RSUs and MAs, the E2E paths (e.g., tunnels) need to be protected by secure communication channels 🧁. In addition, to prevent bogus IP-RSUs and MAs from interfering with the IPv6 mobility of vehicles, mutual authentication among the IP-RSUs, MAs, and vehicles needs to be performed by certificates (e.g., TLS certificate) 🤝✨.
6.3. Other Threats 💖
Okay so, setting up a secure channel over IPsec or TLS on a highway needs multihop V2I communications over DSRC or 5G V2X (or LTE V2X) 🛣️. Multiple intermediate vehicles can act as relay nodes and help forward association and authentication messages toward an IP-RSU (or gNodeB/eNodeB) that's connected to an authentication server in the Vehicular Cloud ✨. The messages each vehicle forwards can get delayed or lost 😭, which can make a connection take longer to build or leave some vehicles unable to get authenticated 💀.
Even though vehicles can be authenticated with valid certificates by an authentication server in the Vehicular Cloud, the authenticated vehicles may still harm other vehicles 🙈. To handle this kind of security issue, vehicles' communication activities can be recorded for monitoring suspicious behaviors, either in a centralized way through a logging server (e.g., TCC) in the Vehicular Cloud, or in a decentralized way (e.g., an ECD and blockchain [Bitcoin]) with help from other vehicles and infrastructure 🧚.
There are trade-offs between centralized and decentralized logging 🦋. You can log vehicles' behaviors (e.g., location, speed, direction, acceleration/deceleration, and lane change) and their communication activities (e.g., transmission time, reception time, and packet types, such as TCP, UDP, SCTP, QUIC, HTTP, and HTTPS). The centralized approach is more efficient than the decentralized one when it comes to collecting and processing log data in a central server in the Vehicular Cloud 👑. BUT the centralized approach may cause a higher delay than the decentralized one when it comes to analyzing the log data and taking action in a local ECD or a distributed database like a blockchain 😩. The centralized approach stores log data collected from VANET in a remote logging server in a Vehicular Cloud as a central cloud, so it takes time to deliver the log data there 🌈. The decentralized approach, on the other hand, stores the log data in a nearby edge computing device as a local logging server or a nearby blockchain node that takes part in a blockchain network 🍓.
An analyzer needs to run a machine learning technique (e.g., deep learning) on the stored log data and look for suspicious behaviors of the vehicles 🤓. If that analyzer sits in or near the edge computing device, it can access the log data with a short delay, analyze it quickly, and generate feedback for a quick counteraction against malicious behaviors 🔥. But if the Vehicular Cloud holding the log data is far away from a problematic VANET with malicious behaviors, the centralized approach takes longer to analyze the data and decide on malicious behaviors than the decentralized approach does 🐢. If the log data is encrypted with a secret key, it's protected from a hacker watching it 🔐. The secret key sharing among legal vehicles, ECDs, and Vehicular Clouds should be supported efficiently 🫶.
Log data can also release a vehicle's privacy 😬. The log data can contain the MAC address and IPv6 address of a vehicle's wireless network interface. If the unique MAC address of that interface is used, a hacker can track the vehicle with it and track the privacy information of the vehicle's driver (e.g., location information) 🕵️♀️. To prevent this privacy breakage, a MAC address pseudonym can be used for the MAC address of the wireless network interface, and the matching IPv6 address should be based on that MAC address pseudonym 🎀. Once a vehicle's identity is no longer exposed in logging, vehicles can observe each other's activities to spot any misbehaviors without a privacy breakage 👀. And once a misbehavior is identified, a vehicle shall have a way to either isolate itself from others or isolate a suspicious vehicle by informing other vehicles 🚨.
For completely secure vehicular networks, we shall embrace the concept of "zero-trust" for vehicles 🧠. That means no vehicle is trustable, and verifying every message (such as IPv6 control messages including ND, DAD, NUD, and application-layer messages) is necessary ✅. This way, vehicular networks can defend against many possible cyberattacks 🛡️. So we need an efficient zero-trust framework or mechanism for vehicular networks 💅.
For non-repudiation of the harmful activities from malicious vehicles 😤, since it's hard for other normal vehicles to identify them, an additional and more advanced approach is needed. One possible approach is a blockchain-based approach [Bitcoin] used as an IPv6 security checking framework ⛓️. Each IPv6 packet 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 with fast-moving vehicles 🏎️, either a new consensus algorithm needs to be developed, or an existing consensus algorithm needs to be enhanced. A consensus-based mechanism for the security of vehicular networks in the IPv6 layer can also be considered 💜. A group of servers acting as blockchain infrastructure can be part of the security checking process in the IP layer 🌸.
To stop an adversary from tracking a vehicle with its MAC address or IPv6 address, especially for a long-living transport-layer session (e.g., voice call over IP and video streaming service) 📞, a MAC address pseudonym needs to be provided to each vehicle. In other words, each vehicle periodically updates its MAC address, and its IPv6 address needs to be updated accordingly with the MAC address change [RFC4086] [RFC8981] 🔄. This update of the MAC and IPv6 addresses should not interrupt the E2E communications between two vehicles (or between a vehicle and an IP-RSU) for a long-living transport-layer session 🙏. But here's the catch: if this pseudonym is performed without strong E2E confidentiality (using either IPsec or TLS), there's no privacy benefit from changing the MAC and IPv6 addresses, because an adversary can observe the change and track the vehicle with those addresses 😱. So the MAC address pseudonym and the IPv6 address update should be performed with strong E2E confidentiality 🔒.
The privacy exposure to the TCC via V2I is mostly about the location information of vehicles, and it may also include other in-vehicle activities, such as credit card transactions 💳. The assumed, trusted actors are the owner of a vehicle, an authorized vehicle service provider (e.g., a navigation service provider), and an authorized vehicle manufacturer providing after-sales services 🧑🔧. Privacy concerns also come up when roadway operators, such as public transportation administrators and private contractors, excessively collect vehicle activities, which may also threaten the privacy rights of vehicles 🙅♀️. It might be interesting to find a solution from a technological point of view, along with public policy development, for this issue 🧐.
The "multicasting" of the location information of a VRU's smartphone means IPv6 multicasting 📱. This multicasting comes with a possible security attack. Attackers can use "fake identifiers" as source IPv6 addresses for their devices, generate IPv6 packets, and multicast them to nearby vehicles to create confusion, making those vehicles think they're surrounded by other vehicles or pedestrians 🎭. As a result, navigation services (e.g., Google Maps [Google-Maps] and Waze [Waze]) can be fooled by fake road traffic from those vehicles or smartphones with "fake identifiers" [Fake-Identifier-Attack] 🗺️. This attack with "fake identifiers" should be detected and handled by vehicular networks 🚫. To cope with it, both legal vehicles and legal VRUs' smartphones can be registered with a TCC, and their locations can be tracked by the TCC. With this tracking, the TCC can tell what road traffic conditions are caused by those vehicles and smartphones 📊. To keep hackers from tracking those vehicles and smartphones, either a MAC address pseudonym [MAC-ADD-RAN] or secure IPv6 address generation [RFC7721] can be used to protect their privacy 🥰.
7. IANA Considerations 🎀
Good news, bestie: this document has no IANA actions. 🙌
8. References ✨
8.1. Normative References
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, https://www.rfc-editor.org/info/rfc4861.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, https://www.rfc-editor.org/info/rfc4862.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, https://www.rfc-editor.org/info/rfc6275.
[RFC8691] Benamar, N., Härri, J., Lee, J., and T. Ernst, "Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11", RFC 8691, DOI 10.17487/RFC8691, December 2019, https://www.rfc-editor.org/info/rfc8691.
8.2. Informative References
[AERO] Templin, F. L., Ed., "Automatic Extended Route Optimization (AERO)", Work in Progress, Internet-Draft, draft-templin-intarea-aero-27, 23 February 2023, https://datatracker.ietf.org/doc/html/draft-templin-intarea-aero-27.
[Automotive-Sensing] Choi, J., Va, V., Gonzalez-Prelcic, N., Daniels, R., Bhat, C., and R. Heath, "Millimeter-Wave Vehicular Communication to Support Massive Automotive Sensing", IEEE Communications Magazine, Volume 54, Issue 12, pp. 160-167, DOI 10.1109/MCOM.2016.1600071CM, December 2016, https://doi.org/10.1109/MCOM.2016.1600071CM.
[Bitcoin] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash System", https://bitcoin.org/bitcoin.pdf.
[CA-Cruise-Control] California Partners for Advanced Transportation Technology (PATH), "Cooperative Adaptive Cruise Control", https://path.berkeley.edu/research/connected-and-automated-vehicles/cooperative-adaptive-cruise-control.
[CASD] Shen, Y., Jeong, J., Oh, T., and S. H. Son, "CASD: A Framework of Context-Awareness Safety Driving in Vehicular Networks", 30th International Conference on Advanced Information Networking and Applications Workshops (WAINA), DOI 10.1109/WAINA.2016.74, March 2016, https://doi.org/10.1109/WAINA.2016.74.
[CBDN] Kim, J., Kim, S., Jeong, J., Kim, H., Park, J., and T. Kim, "CBDN: Cloud-Based Drone Navigation for Efficient Battery Charging in Drone Networks", IEEE Transactions on Intelligent Transportation Systems, Volume 20, Issue 11, pp. 4174-4191, DOI 10.1109/TITS.2018.2883058, November 2019, https://doi.org/10.1109/TITS.2018.2883058.
Still in the Informative References, and the list keeps going with some wild titles, from ITS driving protocols and Wi-Fi sensing to the mobility and IPsec RFCs. Here's the rest of it, exactly as written 🫶
[CNP] Mugabarigira, B., Shen, Y., Jeong, J., Oh, T., and H.
Jeong, "Context-Aware Navigation Protocol for Safe Driving
in Vehicular Cyber-Physical Systems", IEEE Transactions on
Intelligent Transportation Systems, Volume 24, Issue 1,
pp. 128-138, DOI 10.1109/TITS.2022.3210753, January 2023,
<https://doi.org/10.1109/TITS.2022.3210753>.
[DFC] Jeong, J., Shen, Y., Kim, S., Choe, D., Lee, K., and Y.
Kim, "DFC: Device-free human counting through WiFi fine-
grained subcarrier information", IET Communications,
Volume 15, Issue 3, pp. 337-350, DOI 10.1049/cmu2.12043,
February 2021, <https://doi.org/10.1049/cmu2.12043>.
[DSRC] ASTM International, "Standard Specification for
Telecommunications and Information Exchange Between
Roadside and Vehicle Systems - 5 GHz Band Dedicated Short
Range Communications (DSRC) Medium Access Control (MAC)
and Physical Layer (PHY) Specifications",
ASTM E2213-03(2010), DOI 10.1520/E2213-03R10, September
2018, <https://doi.org/10.1520/E2213-03R10>.
[EU-2008-671-EC]
European Union, "COMMISSION DECISION of 5 August 2008 on
the harmonised use of radio spectrum in the 5 875-5 905
MHz frequency band for safety-related applications of
Intelligent Transport Systems (ITS)", EU 2008/671/EC,
August 2008, <https://eur-lex.europa.eu/legal-
content/EN/TXT/PDF/?uri=CELEX:32008D0671&rid=7>.
[Fake-Identifier-Attack]
ABC News, "Berlin artist uses handcart full of smartphones
to trick Google Maps' traffic algorithm into thinking
there is traffic jam", February 2020,
<https://www.abc.net.au/news/2020-02-04/man-creates-fake-
traffic-jam-on-google-maps-by-carting-99-phones/11929136>.
[FCC-ITS-Modification]
Federal Communications Commission, "FCC Modernizes 5.9 GHz
Band to Improve Wi-Fi and Automotive Safety", November
2020, <https://www.fcc.gov/document/fcc-modernizes-59-ghz-
band-improve-wi-fi-and-automotive-safety-0>.
[FirstNet] FirstNet Authority, "First Responder Network Authority |
FirstNet", <https://www.firstnet.gov/>.
[FirstNet-Report]
FirstNet, "FY 2017: ANNUAL REPORT TO CONGRESS, Advancing
Public Safety Broadband Communications", FirstNet FY 2017,
December 2017, <https://www.firstnet.gov/system/tdf/
FirstNet-Annual-Report-
FY2017.pdf?file=1&type=node&id=449>.
[FPC-DMM] Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S.,
Moses, D., and C. E. Perkins, "Protocol for Forwarding
Policy Configuration (FPC) in DMM", Work in Progress,
Internet-Draft, draft-ietf-dmm-fpc-cpdp-14, 22 September
2020, <https://datatracker.ietf.org/doc/html/draft-ietf-
dmm-fpc-cpdp-14>.
[Fuel-Efficient]
van de Hoef, S., Johansson, K., and D. Dimarogonas, "Fuel-
Efficient En Route Formation of Truck Platoons", IEEE
Transactions on Intelligent Transportation Systems, Volume
19, Issue 1, pp. 102-112, DOI 10.1109/TITS.2017.2700021,
January 2018, <https://doi.org/10.1109/TITS.2017.2700021>.
[Google-Maps]
Google, "Google Maps", <https://www.google.com/maps/>.
[Identity-Management]
Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer
identities management in ITS stations", 10th IEEE
International Conference on ITS Telecommunications,
November 2010,
<https://www.eurecom.fr/fr/publication/3205>.
[IEEE-802.11-OCB]
IEEE, "IEEE Standard for Information technology -
Telecommunications and information exchange between
systems Local and metropolitan area networks-Specific
requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications",
DOI 10.1109/IEEESTD.2016.7786995, IEEE Std 802.11-2016,
December 2016,
<https://doi.org/10.1109/IEEESTD.2016.7786995>.
[IEEE-802.11p]
IEEE, "IEEE Standard for Information technology-- Local
and metropolitan area networks-- Specific requirements--
Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications Amendment 6: Wireless
Access in Vehicular Environments",
DOI 10.1109/IEEESTD.2010.5514475, IEEE Std 802.11p-2010,
July 2010, <https://doi.org/10.1109/IEEESTD.2010.5514475>.
[In-Car-Network]
Lim, H., Volker, L., and D. Herrscher, "Challenges in a
future IP/Ethernet-based in-car network for real-time
applications", Proceedings of the 48th Design Automation
Conference, pp. 7-12, DOI 10.1145/2024724.2024727, June
2011, <https://doi.org/10.1145/2024724.2024727>.
[IPPL] Nordmark, E., "IP over Intentionally Partially Partitioned
Links", Work in Progress, Internet-Draft, draft-ietf-
intarea-ippl-00, 30 March 2017,
<https://datatracker.ietf.org/doc/html/draft-ietf-intarea-
ippl-00>.
[ISO-ITS-IPv6]
ISO/TC 204, "Intelligent transport systems -
Communications access for land mobiles (CALM) - IPv6
Networking", ISO 21210:2012, June 2012,
<https://www.iso.org/standard/46549.html>.
[ISO-ITS-IPv6-AMD1]
ISO/TC 204, "Intelligent transport systems -
Communications access for land mobiles (CALM) - IPv6
Networking - Amendment 1", ISO 21210:2012/AMD 1:2017,
September 2017, <https://www.iso.org/standard/65691.html>.
[LIFS] Wang, J., Xiong, J., Jiang, H., Jamieson, K., Chen, X.,
Fang, D., and C. Wang, "Low Human-Effort, Device-Free
Localization with Fine-Grained Subcarrier Information",
IEEE Transactions on Mobile Computing, Volume 17, Issue
11, pp. 2550-2563, DOI 10.1109/TMC.2018.2812746, November
2018, <https://doi.org/10.1109/TMC.2018.2812746>.
[MAC-ADD-RAN]
Zuniga, JC., Bernardos, CJ., Ed., and A. Andersdotter,
"Randomized and Changing MAC Address", Work in Progress,
Internet-Draft, draft-ietf-madinas-mac-address-
randomization-06, 11 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-madinas-
mac-address-randomization-06>.
[NHTSA-ACAS-Report]
National Highway Traffic Safety Administration (NHTSA),
"Automotive Collision Avoidance Systems (ACAS) Program
Final Report", DOT HS 809 080, August 2000,
<https://one.nhtsa.gov/people/injury/research/pub/ACAS/
ACAS_index.htm>.
[OMNI] Templin, F. L., Ed., "Transmission of IP Packets over
Overlay Multilink Network (OMNI) Interfaces", Work in
Progress, Internet-Draft, draft-templin-intarea-omni-27,
23 February 2023, <https://datatracker.ietf.org/doc/html/
draft-templin-intarea-omni-27>.
[PARCELS] Templin, F. L., Ed., "IP Parcels and Advanced Jumbos",
Work in Progress, Internet-Draft, draft-templin-intarea-
parcels-55, 28 February 2023,
<https://datatracker.ietf.org/doc/html/draft-templin-
intarea-parcels-55>.
[PSCE] European Commission, "PSCEurope Public Safety
Communications Europe", <https://www.psc-europe.eu/>.
[RCM-USE-CASES]
Henry, J. and Y. Lee, "Randomized and Changing MAC Address
Use Cases and Requirements", Work in Progress, Internet-
Draft, draft-ietf-madinas-use-cases-05, 13 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-madinas-
use-cases-05>.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
DOI 10.17487/RFC2710, October 1999,
<https://www.rfc-editor.org/info/rfc2710>.
[RFC3626] Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link
State Routing Protocol (OLSR)", RFC 3626,
DOI 10.17487/RFC3626, October 2003,
<https://www.rfc-editor.org/info/rfc3626>.
[RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related
Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004,
<https://www.rfc-editor.org/info/rfc3753>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, DOI 10.17487/RFC3963, January 2005,
<https://www.rfc-editor.org/info/rfc3963>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308,
DOI 10.17487/RFC4308, December 2005,
<https://www.rfc-editor.org/info/rfc4308>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, DOI 10.17487/RFC4885, July 2007,
<https://www.rfc-editor.org/info/rfc4885>.
[RFC4888] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network
Mobility Route Optimization Problem Statement", RFC 4888,
DOI 10.17487/RFC4888, July 2007,
<https://www.rfc-editor.org/info/rfc4888>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008,
<https://www.rfc-editor.org/info/rfc5213>.[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, https://www.rfc-editor.org/info/rfc5280.
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, DOI 10.17487/RFC5415, March 2009, https://www.rfc-editor.org/info/rfc5415.
[RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009, https://www.rfc-editor.org/info/rfc5614.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, https://www.rfc-editor.org/info/rfc5881.
[RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, September 2010, https://www.rfc-editor.org/info/rfc5889.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, DOI 10.17487/RFC6130, April 2011, https://www.rfc-editor.org/info/rfc6130.
[RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, DOI 10.17487/RFC6250, May 2011, https://www.rfc-editor.org/info/rfc6250.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, https://www.rfc-editor.org/info/rfc6550.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, DOI 10.17487/RFC6583, March 2012, https://www.rfc-editor.org/info/rfc6583.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, https://www.rfc-editor.org/info/rfc6775.
[RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address Validation Improvement (SAVI) Threat Scope", RFC 6959, DOI 10.17487/RFC6959, May 2013, https://www.rfc-editor.org/info/rfc6959.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, https://www.rfc-editor.org/info/rfc7149.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, DOI 10.17487/RFC7181, April 2014, https://www.rfc-editor.org/info/rfc7181.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, https://www.rfc-editor.org/info/rfc7296.
[RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, https://www.rfc-editor.org/info/rfc7333.
[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, DOI 10.17487/RFC7427, January 2015, https://www.rfc-editor.org/info/rfc7427.
[RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and CJ. Bernardos, "Distributed Mobility Management: Current Practices and Gap Analysis", RFC 7429, DOI 10.17487/RFC7429, January 2015, https://www.rfc-editor.org/info/rfc7429.
[RFC7466] Dearlove, C. and T. Clausen, "An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 7466, DOI 10.17487/RFC7466, March 2015, https://www.rfc-editor.org/info/rfc7466.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, https://www.rfc-editor.org/info/rfc7721.
[RFC8002] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 8002, DOI 10.17487/RFC8002, October 2016, https://www.rfc-editor.org/info/rfc8002.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/RFC8028, November 2016, https://www.rfc-editor.org/info/rfc8028.
[RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, DOI 10.17487/RFC8175, June 2017, https://www.rfc-editor.org/info/rfc8175.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, https://www.rfc-editor.org/info/rfc8200.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, https://www.rfc-editor.org/info/rfc8446.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, https://www.rfc-editor.org/info/rfc8505.
[RFC8629] Cheng, B. and L. Berger, Ed., "Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension", RFC 8629, DOI 10.17487/RFC8629, July 2019, https://www.rfc-editor.org/info/rfc8629.
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020, https://www.rfc-editor.org/info/rfc8684.
[RFC8757] Cheng, B. and L. Berger, Ed., "Dynamic Link Exchange Protocol (DLEP) Latency Range Extension", RFC 8757, DOI 10.17487/RFC8757, March 2020, https://www.rfc-editor.org/info/rfc8757.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020, https://www.rfc-editor.org/info/rfc8899.
[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 2020, https://www.rfc-editor.org/info/rfc8928.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, https://www.rfc-editor.org/info/rfc8981.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, https://www.rfc-editor.org/info/rfc9000.
[RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, "Operational Security Considerations for IPv6 Networks", RFC 9099, DOI 10.17487/RFC9099, August 2021, https://www.rfc-editor.org/info/rfc9099.
[RFC9119] Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC. Zúñiga, "Multicast Considerations over IEEE 802 Wireless Media", RFC 9119, DOI 10.17487/RFC9119, October 2021, https://www.rfc-editor.org/info/rfc9119.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., "The Locator/ID Separation Protocol (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022, https://www.rfc-editor.org/info/rfc9300.
[SAINT] Jeong, J., Jeong, H., Lee, E., Oh, T., and D. H. C. Du, "SAINT: Self-Adaptive Interactive Navigation Tool for Cloud-Based Vehicular Traffic Optimization", IEEE Transactions on Vehicular Technology, Volume 65, Issue 6, pp. 4053-4067, DOI 10.1109/TVT.2015.2476958, June 2016, https://doi.org/10.1109/TVT.2015.2476958.
[SAINTplus] Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D. H. C. Du, "SAINT+: Self-Adaptive Interactive Navigation Tool+ for Emergency Service Delivery Optimization", IEEE Transactions on Intelligent Transportation Systems, Volume 19, Issue 4, pp. 1038-1053, DOI 10.1109/TITS.2017.2710881, June 2017, https://doi.org/10.1109/TITS.2017.2710881.
[SANA] Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation Application for Pedestrian Protection in Vehicular Networks", Lecture Notes in Computer Science book series (LNISA, Volume 9502), DOI 10.1007/978-3-319-27293-1_12, December 2015, https://doi.org/10.1007/978-3-319-27293-1_12.
[Scrambler-Attack] Bloessl, B., Sommer, C., Dressier, F., and D. Eckhoff, "The scrambler attack: A robust physical layer attack on location privacy in vehicular networks", 2015 International Conference on Computing, Networking and Communications (ICNC), DOI 10.1109/ICCNC.2015.7069376, February 2015, https://doi.org/10.1109/ICCNC.2015.7069376.
[SEC-PRIV] Jeong, J., Ed., Shen, Y., Jung, H., Park, J., and T. Oh, "Basic Support for Security and Privacy in IP-Based Vehicular Networks", Work in Progress, Internet-Draft, draft-jeong-ipwave-security-privacy-07, 4 February 2023, https://datatracker.ietf.org/doc/html/draft-jeong-ipwave-security-privacy-07.
[SignalGuru] Koukoumidis, E., Peh, L., and M. Martonosi, "SignalGuru: leveraging mobile phones for collaborative traffic signal schedule advisory", MobiSys '11: Proceedings of the 9th international conference on Mobile systems, applications, and services, pp. 127-140, DOI 10.1145/1999995.2000008, June 2011, https://doi.org/10.1145/1999995.2000008.
[TR-22.886-3GPP] 3GPP, "Study on enhancement of 3GPP support for 5G V2X services", 3GPP TS 22.886 16.2.0, December 2018, https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3108.
References (continued) 📚
Okay bestie, the reference list is giving bibliography drama 💅 Every single source is here, with its details.
[Truck-Platooning] California Partners for Advanced Transportation Technology (PATH), "Truck Platooning", https://path.berkeley.edu/research/connected-and-automated-vehicles/truck-platooning.
[TS-23.285-3GPP] 3GPP, "Architecture enhancements for V2X services", 3GPP TS 23.285 16.2.0, December 2019, https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3078.
[TS-23.287-3GPP] 3GPP, "Architecture enhancements for 5G System (5GS) to support Vehicle-to-Everything (V2X) services", 3GPP TS 23.287 16.2.0, March 2020, https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3578.
[UAM-ITS] Templin, F., Ed., "Urban Air Mobility Implications for Intelligent Transportation Systems", Work in Progress, Internet-Draft, draft-templin-ipwave-uam-its-04, 4 January 2021, https://datatracker.ietf.org/doc/html/draft-templin-ipwave-uam-its-04.
[Vehicular-BlockChain] Dorri, A., Steger, M., Kanhere, S., and R. Jurdak, "BlockChain: A Distributed Solution to Automotive Security and Privacy", IEEE Communications Magazine, Volume 55, Issue 12, pp. 119-125, DOI 10.1109/MCOM.2017.1700879, December 2017, https://doi.org/10.1109/MCOM.2017.1700879.
[VEHICULAR-MM] Jeong, J., Ed., Mugabarigira, B., Shen, Y., and H. Jung, "Vehicular Mobility Management for IP-Based Vehicular Networks", Work in Progress, Internet-Draft, draft-jeong-ipwave-vehicular-mobility-management-09, 4 February 2023, https://datatracker.ietf.org/doc/html/draft-jeong-ipwave-vehicular-mobility-management-09.
[VEHICULAR-ND] Jeong, J., Ed., Shen, Y., Kwon, J., and S. Cespedes, "Vehicular Neighbor Discovery for IP-Based Vehicular Networks", Work in Progress, Internet-Draft, draft-jeong-ipwave-vehicular-neighbor-discovery-15, 4 February 2023, https://datatracker.ietf.org/doc/html/draft-jeong-ipwave-vehicular-neighbor-discovery-15.
[VIP-WAVE] Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the Feasibility of IP Communications in 802.11p Vehicular Networks", IEEE Transactions on Intelligent Transportation Systems, Volume 14, Issue 1, pp. 82-97, DOI 10.1109/TITS.2012.2206387, March 2013, https://doi.org/10.1109/TITS.2012.2206387.
[WAVE-1609.0] IEEE, "IEEE Guide for Wireless Access in Vehicular Environments (WAVE) - Architecture", DOI 10.1109/IEEESTD.2014.6755433, IEEE Std 1609.0-2013, March 2014, https://doi.org/10.1109/IEEESTD.2014.6755433.
[WAVE-1609.2] IEEE, "IEEE Standard for Wireless Access in Vehicular Environments - Security Services for Applications and Management Messages", DOI 10.1109/IEEESTD.2016.7426684, IEEE Std 1609.2-2016, March 2016, https://doi.org/10.1109/IEEESTD.2016.7426684.
[WAVE-1609.3] IEEE, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Networking Services", DOI 10.1109/IEEESTD.2016.7458115, IEEE Std 1609.3-2016, April 2016, https://doi.org/10.1109/IEEESTD.2016.7458115.
[WAVE-1609.4] IEEE, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Multi-Channel Operation", DOI 10.1109/IEEESTD.2016.7435228, IEEE Std 1609.4-2016, March 2016, https://doi.org/10.1109/IEEESTD.2016.7435228.
[Waze] Google, "Waze", https://www.waze.com/.
[WIRELESS-ND] Thubert, P., Ed. and M. Richardson, "Architecture and Framework for IPv6 over Non-Broadcast Access", Work in Progress, Internet-Draft, draft-thubert-6man-ipv6-over-wireless-15, 8 March 2023, https://datatracker.ietf.org/doc/html/draft-thubert-6man-ipv6-over-wireless-15.
Appendix A. Support of Multiple Radio Technologies for V2V ✨
Vehicular networks can be made up of several radio technologies, like DSRC and 5G V2X (or LTE V2X) 🚗. A Layer 2 solution can support multihop communications in vehicular networks, but the scalability issue with multihop forwarding still sticks around when vehicles need to disseminate or forward packets toward destinations that are several hops away 😬. The IPv6-based approach for V2V, as a network-layer protocol, can also handle multiple radio technologies as MAC protocols, such as DSRC and 5G V2X (or LTE V2X) 💖. So the existing IPv6 protocol can be augmented by adding a virtual interface (e.g., OMNI [OMNI] and DLEP [RFC8175]) and/or by making protocol changes, so it supports both wireless single-hop/multihop V2V communications and multiple radio technologies in vehicular networks 🔥. That way, vehicles can talk to each other over V2V to share an emergency situation or road hazard info on a highway with multiple radio technologies 🛣️✨.
Appendix B. Support of Multihop V2X Networking 🦋
Okay, so the multihop V2X networking can be supported by RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) [RFC6550] and the Overlay Multilink Network Interface [OMNI] with AERO [AERO] 🧚.
RPL defines an IPv6 routing protocol for Low-Power and Lossy Networks (LLNs), and it's mostly designed for home automation routing, building automation routing, industrial routing, and urban LLN routing 🏙️. It uses a Destination-Oriented Directed Acyclic Graph (DODAG) to construct routing paths for hosts (e.g., IoT devices) in a network 🌸. The DODAG uses an Objective Function (OF) for route selection and optimization within the network. A user can use different routing metrics to define an OF for a specific scenario 💜. RPL supports multipoint-to-point, point-to-multipoint, and point-to-point traffic, and the major traffic flow is multipoint-to-point 🍓. For example, in a highway scenario, a vehicle may not access an IP-RSU directly because of the distance of the DSRC coverage (up to 1 km) 🙈. In this case, RPL can be extended to support a multihop V2I, since a vehicle can take advantage of other vehicles as relay nodes to reach the IP-RSU 🚙. Also, RPL can be extended to support both multihop V2V and V2X in a similar way ✨.
RPL is primarily designed to minimize the control plane activity, which is the relative amount of routing protocol exchanges versus data traffic. This approach is beneficial for situations where the power and bandwidth are scarce (e.g., an IoT LLN, where RPL is typically used today), but also in situations of high relative mobility between the nodes in the network (also known as swarming, e.g., within a variable set of vehicles with a similar global motion, or a variable set of drones flying toward the same direction) 🌈.
To reduce the routing exchanges, RPL leverages a Distance Vector (DV) approach. This doesn't need global knowledge of the topology, and it only optimizes the routes to and from the root, which allows peer-to-peer (P2P) paths to be stretched 💅. Although RPL installs its routes proactively, it only maintains them lazily, meaning in reaction to actual traffic or as a slow background activity 😌. RPL also leverages the concept of an OF, which lets it adapt the activity of the routing protocol to use cases, e.g., type, speed, and quality of the radios 👑. RPL does not need to converge, and it provides connectivity to most nodes most of the time 🫶. The default route toward the root is maintained aggressively and may change while a packet progresses without causing loops, so the packet will still reach the root 🔥.
There are two modes for routing in RPL: non-storing mode and storing mode 🎀. In non-storing mode, a node inside the mesh or swarm that changes its point(s) of attachment to the graph informs the root with a single unicast packet flowing along the default route, and the connectivity is restored immediately. This mode is preferable for use cases where Internet connectivity is dominant ⭐. On the other hand, in storing mode, the routing stretch is reduced for better P2P connectivity, and the Internet connectivity is restored more slowly during the time it takes for the DV operation to run hop-by-hop 🐢. While an RPL topology can quickly scale up and down and fit the needs of vehicle mobility, the total performance of the system also depends on how quickly a node can form an address, join the mesh (including Authentication, Authorization, and Accounting (AAA)), and manage its global mobility to become reachable from another node outside the mesh 💀.
OMNI defines a protocol for the transmission of IPv6 packets over Overlay Multilink Network Interfaces, which are virtual interfaces governing multiple physical network interfaces 🧩. OMNI supports multihop V2V communication between vehicles in multiple forwarding hops via intermediate vehicles with OMNI links. It also supports multihop V2I communication between a vehicle and an infrastructure access point by way of multihop V2V communication 🛰️. The OMNI interface supports an NBMA link model, where multihop V2V and V2I communications use each mobile node's ULAs without any need for DAD or MLD messaging 🌟.
In the OMNI protocol, an OMNI virtual interface can indeed have a ULA [RFC4193], but the wireless physical interfaces associated with the OMNI virtual interface can use any prefixes 🪄. The ULA supports both V2V and V2I multihop forwarding within the vehicular network (e.g., via a VANET routing protocol), while each vehicle can communicate with Internet correspondents using IPv6 global addresses via OMNI interface encapsulation over the wireless interface 🌍.
For the control traffic overhead of running both vehicular ND and a VANET routing protocol, the AERO/OMNI approach may avoid this issue. It does so by using MANET routing protocols only (i.e., no multicast of IPv6 ND messaging) in the wireless underlay network, while applying efficient unicast IPv6 ND messaging in the OMNI overlay on an as-needed basis for router discovery and NUD 🧠. This greatly reduces the overhead of VANET-wide multicasting while providing agile accommodation for dynamic topology changes 🦋💖.
Appendix C. Support of Mobility Management for V2I 🚗💨
okay so bestie, seamless app communication between two vehicles, or between a vehicle and an infrastructure node, needs mobility management in vehicular networks 🫶. The mobility schemes are the host-based mobility scheme, the network-based mobility scheme, and the software-defined networking scheme ✨.
So the host-based one (think MIPv6 🌸) has an IP-RSU acting as the home agent. The network-based one (think PMIPv6 🦋) is a whole different vibe. An MA is the mobility management controller, like the Local Mobility Anchor (LMA) in PMIPv6, which also serves vehicles as a home agent 👑. Meanwhile an IP-RSU plays the access router, like the Mobile Access Gateway (MAG) in PMIPv6 [RFC5213] 💅. The host-based scheme needs client functionality in the IPv6 stack of a vehicle, which acts as a mobile node, so the vehicle can do the mobility signaling message exchange with the home agent 🙈. The network-based scheme doesn't need that client functionality in the vehicle, because the network infrastructure node (the MAG in PMIPv6) acts as a proxy mobility agent and handles the mobility signaling message exchange with the home agent (the LMA in PMIPv6) on the vehicle's behalf 🧚.
Now the tea ☕: there's a scalability issue and a route optimization issue in the network-based mobility scheme (PMIPv6 is the example) when one MA covers a large vehicular network governing many IP-RSUs 😭. This is where a distributed mobility scheme (DMM [RFC7429]) slaps 🔥. It mitigates the scalability issue by distributing multiple MAs across the vehicular network, positioned closer to vehicles, which helps with route optimization and with bottleneck mitigation at a central MA in the network-based scheme 💜. All of these approaches (the host-based scheme, the network-based scheme, and the distributed mobility scheme), plus a hybrid that combines them, need to give vehicles an efficient mobility service, especially vehicles moving fast along relatively predictable trajectories on roadways 🛣️✨.
Next, the control plane can be separated from the data plane for efficient mobility management and data forwarding, using the concept of Software-Defined Networking (SDN) [RFC7149] [FPC-DMM] 🌈. Forwarding Policy Configuration (FPC) in [FPC-DMM] is a flexible mobility management system that can manage that separation of data plane and control plane in DMM, so keep it in mind 🎀. In SDN, the control plane and data plane are split for efficient management of forwarding elements (like switches and routers). An SDN controller configures those forwarding elements in a centralized way, and they do packet forwarding according to the forwarding tables the SDN controller configured 💖. An MA acting as an SDN controller needs to efficiently configure and monitor its IP-RSUs and vehicles for mobility management and security services 🍓.
Appendix D. Support of MTU Diversity for IP-Based Vehicular Networks 🌸
okay this one is about MTUs (Maximum Transmission Units), aka how big a packet can be on a link 📏. The wireless and/or wired-line links in paths between mobile nodes and fixed network correspondents can be configured with a variety of MTUs 🧩. All IPv6 links are required to support a minimum MTU of 1280 octets, and they may support larger MTUs too 💅.
Here's the drama 😭: figuring out the path MTU (aka the minimum link MTU along the path) has proven to be inefficient and unreliable. That's because path MTU discovery depends on the loss-oriented ICMPv6 messaging service, which is super uncertain. There have been more reliable path MTU determination services for TCP [RFC4821] and UDP [RFC8899] lately, which is great 🙌. Still, the MTUs discovered are always capped by the most restrictive link MTU in the path, which is often 1500 octets or smaller 🥲.
Enter the AERO/OMNI service 🦋, which tackles the MTU issue by adding a brand new layer to the Internet architecture called the "OMNI Adaptation Layer (OAL)" ✨. The OAL lets end systems that configure an OMNI interface use a full 65535-octet MTU. How? It leverages the IPv6 fragmentation and reassembly service during encapsulation, producing fragment sizes that are assured to traverse the path without loss due to a size restriction 🧚. So end systems can send packets that are often much larger than the actual path MTU 🤯.
Here's the tea ☕: performance studies over many decades have proven that applications get greater performance by sending smaller numbers of large packets (instead of larger numbers of small packets), even when fragmentation is needed 💜. The OAL goes even bigger through the IP Parcels construct [PARCELS], which provides "packets-in-packet" encapsulation for a total size up to 4 MB 👑. Together, the OAL and IP Parcels will provide a revolutionary new capability for greater efficiency in both mobile and fixed networks 🔥.
BUT (okay, not me saying "but" 💀) due to the highly dynamic nature of vehicular networks, a high packet loss may not be able to be avoided 😭. High packet loss on IP Parcels can cause multiple TCP sessions to hit packet retransmissions, session time-outs, or re-establishment of the sessions all at once 🥲. Other protocols, like MPTCP and QUIC, may also run into similar issues. So a mechanism for mitigating this issue in OAL and IP Parcels should be considered 🫶.
Acknowledgments 🫶✨
This work was supported by a grant from the Institute of Information & Communications Technology Planning & Evaluation (IITP) funded by the Korea MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud-based Security Intelligence Technology Development for the Customized Security Service Provisioning) 🙏.
This work was supported in part by the MSIT, Korea, under the ITRC (Information Technology Research Center) support program (IITP-2022-2017-0-01633) supervised by the IITP 💜.
This work was supported in part by the IITP (2020-0-00395-003, Standard Development of Blockchain-based Network Management Automation Technology) 🌈.
This work was supported in part by the French research project DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded by the European Commission I (636537-H2020) 🇪🇺✨.
This work was supported in part by the Cisco University Research Program Fund, Grant # 2019-199458 (3696), and by ANID Chile Basal Project FB0008 🦋.
Contributors 💖
This document is a group work of the IPWAVE working group, and it greatly benefits from inputs and texts by Rex Buddenberg (Naval Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest University of Technology and Economics), Jose Santa Lozanoi (Universidad of Murcia), Richard Roy (MIT), Francois Simon (Pilot), Sri Gundavelli (Cisco), Erik Nordmark (Zededa), Dirk von Hugo (Deutsche Telekom), Pascal Thubert (Cisco), Carlos Bernardos (UC3M), Russ Housley (Vigil Security), Suresh Krishnan (Cisco), Nancy Cam-Winget (Cisco), Fred L. Templin (The Boeing Company), Jung-Soo Park (ETRI), Zeungil (Ben) Kim (Hyundai Motors), Kyoungjae Sun (Soongsil University), Zhiwei Yan (CNNIC), YongJoon Joe (LSware), Peter E. Yee (Akayla), and Erik Kline (Aalyria) 🎀. The authors sincerely appreciate all of their contributions 🫶💜.
The following are coauthors of this document 👯♀️:
Nabil Benamar
Department of Computer Sciences,
High School of Technology of Meknes
Moulay Ismail University
Morocco
Phone: +212 6 70 83 22 36
Email: benamar73@gmail.comSandra Cespedes
NIC Chile Research Labs
Universidad de Chile
Av. Blanco Encalada 1975
Santiago
Chile
Phone: +56 2 29784093
Email: scespede@niclabs.clJérôme Härri
Communication Systems Department
EURECOM
Sophia-Antipolis
France
Phone: +33 4 93 00 81 34
Email: jerome.haerri@eurecom.frDapeng Liu
Alibaba
Beijing
100022
China
Phone: +86 13911788933
Email: max.ldp@alibaba-inc.comTae (Tom) Oh
Department of Information Sciences and Technologies
Rochester Institute of Technology
One Lomb Memorial Drive
Rochester, NY 14623-5603
United States of America
Phone: +1 585 475 7642
Email: Tom.Oh@rit.eduCharles E. Perkins
Futurewei Inc.
2330 Central Expressway,
Santa Clara, CA 95050
United States of America
Phone: +1 408 330 4586,
Email: charliep@computer.orgAlexandre Petrescu
CEA, LIST, CEA Saclay
91190 Gif-sur-Yvette
France
Phone: +33169089223
Email: Alexandre.Petrescu@cea.frYiwen Chris Shen
Department of Computer Science & Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4106
Email: chrisshen@skku.edu
URI: https://chrisshen.github.ioMichelle Wetterwald
FBConsulting
21, Route de Luxembourg,
L-L-6633, Wasserbillig,
Luxembourg
Email: Michelle.Wetterwald@gmail.comAuthor's Address 📮🌸
Jaehoon Paul Jeong (editor)
Department of Computer Science and Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4957
Email: pauljeong@skku.edu
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php📦 where this page comes from
- ietf: rfc9365 2023-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms