diff options
Diffstat (limited to 'doc/rfc/rfc9365.txt')
| -rw-r--r-- | doc/rfc/rfc9365.txt | 2687 |
1 files changed, 2687 insertions, 0 deletions
diff --git a/doc/rfc/rfc9365.txt b/doc/rfc/rfc9365.txt new file mode 100644 index 0000000..4173226 --- /dev/null +++ b/doc/rfc/rfc9365.txt @@ -0,0 +1,2687 @@ + + + + +Internet Engineering Task Force (IETF) J. Jeong, Ed. +Request for Comments: 9365 Sungkyunkwan University +Category: Informational March 2023 +ISSN: 2070-1721 + + + IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem + Statement and Use Cases + +Abstract + + This document discusses the problem statement and use cases of + IPv6-based vehicular networking for Intelligent Transportation + Systems (ITS). The main scenarios of vehicular communications are + vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and + vehicle-to-everything (V2X) communications. First, this document + explains use cases using V2V, V2I, and V2X networking. Next, for + IPv6-based vehicular networks, it makes a gap analysis of current + IPv6 protocols (e.g., IPv6 Neighbor Discovery, mobility management, + as well as security and privacy). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9365. + +Copyright Notice + + Copyright (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +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 Address + +1. Introduction + + Vehicular networking studies have mainly focused on improving road + safety and efficiency and also enabling entertainment in vehicular + networks. To proliferate the use cases of vehicular networks, + several governments and private organizations have committed to + allocating dedicated spectrum for vehicular communications. The + Federal Communications Commission (FCC) in the US allocated wireless + channels for Dedicated Short-Range Communications (DSRC) [DSRC] in + the Intelligent Transportation Systems (ITS) with the frequency band + of 5.850 - 5.925 GHz (i.e., 5.9 GHz band). In November 2020, the FCC + adjusted the lower 45 MHz (i.e., 5.850 - 5.895 GHz) of the 5.9 GHz + band for unlicensed use instead of DSRC-dedicated use + [FCC-ITS-Modification]. DSRC-based wireless communications can + support vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), + and vehicle-to-everything (V2X) networking. The European Union (EU) + allocated radio spectrum for safety-related and non-safety-related + applications of ITS with the frequency band of 5.875 - 5.905 GHz, as + part of the Commission Decision 2008/671/EC [EU-2008-671-EC]. Most + other countries and regions in the world have adopted the 5.9 GHz + band for vehicular networks, though different countries use different + ways to divide the band into channels. + + For direct inter-vehicular wireless connectivity, IEEE has amended + standard 802.11 (commonly known as Wi-Fi) to enable safe driving + services based on DSRC for the Wireless Access in Vehicular + Environments (WAVE) system. The Physical Layer (L1) and Data Link + Layer (L2) issues are addressed in IEEE 802.11p [IEEE-802.11p] for + the PHY and MAC layers of the DSRC, while IEEE Std 1609.2 + [WAVE-1609.2] covers security aspects, IEEE Std 1609.3 [WAVE-1609.3] + defines related services at network and transport layers, and IEEE + Std 1609.4 [WAVE-1609.4] specifies the multichannel operation. IEEE + 802.11p was first a separate amendment but was later rolled into the + base 802.11 standard (IEEE Std 802.11-2012) as IEEE 802.11 Outside + the Context of a Basic Service Set (OCB) in 2012 [IEEE-802.11-OCB]. + + 3GPP has standardized Cellular Vehicle-to-Everything (C-V2X) + communications to support V2X in LTE mobile networks (called LTE V2X) + and V2X in 5G mobile networks (called 5G V2X) [TS-23.285-3GPP] + [TR-22.886-3GPP] [TS-23.287-3GPP]. With C-V2X, vehicles can directly + communicate with each other without relay nodes (e.g., eNodeB in LTE + and gNodeB in 5G). + + Along with these WAVE standards and C-V2X standards, regardless of a + wireless access technology under the IP stack of a vehicle, vehicular + networks can operate IP mobility with IPv6 [RFC8200], that is, Mobile + IPv6 protocols, e.g., 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]. In addition, ISO has approved + a standard specifying the IPv6 network protocols and services to be + used for Communications Access for Land Mobiles (CALM) [ISO-ITS-IPv6] + [ISO-ITS-IPv6-AMD1]. + + This document describes use cases and a problem statement about + IPv6-based vehicular networking for ITS, which is named IPv6 Wireless + Access in Vehicular Environments (IPWAVE). First, it introduces the + use cases for using V2V, V2I, and V2X networking in ITS. Next, for + IPv6-based vehicular networks, it makes a gap analysis of current + IPv6 protocols (e.g., IPv6 Neighbor Discovery, mobility management, + as well as security and privacy) so that those protocols can be + tailored to IPv6-based vehicular networking. Thus, this document is + intended to motivate development of key protocols for IPWAVE. + +2. Terminology + + This document uses the terminology described in [RFC8691]. In + addition, the following terms are defined below: + + 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. + +3.1. V2V + + The use cases of V2V networking discussed in this section include: + + * 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 + + The above use cases are examples for using V2V networking, which can + be extended to other terrestrial vehicles, river/sea ships, railed + vehicles, or UAM end systems. + + A Context-Aware Safety Driving (CASD) navigator [CASD] can help + drivers to drive safely as a context-aware navigation service [CNP] + by alerting them to dangerous obstacles and situations. That is, a + CASD navigator displays obstacles or neighboring vehicles relevant to + possible collisions in real time through V2V networking. CASD + provides vehicles with a class-based automatic safety action plan + that considers three situations, namely, the Line-of-Sight unsafe, + Non-Line-of-Sight unsafe, and safe situations. This action plan can + be put into action among multiple vehicles using V2V networking. + + A service for collision avoidance of in-air UAM end systems is one + possible use case in air vehicular environments [UAM-ITS]. This use + case is similar to that of a context-aware navigator for terrestrial + vehicles. Through V2V coordination, those UAM end systems (e.g., + drones) can avoid a dangerous situation (e.g., collision) in three- + dimensional space rather than two-dimensional space for terrestrial + vehicles. Also, a UAM end system (e.g., flying car), when only a few + hundred meters off the ground, can communicate with terrestrial + vehicles with wireless communication technologies (e.g., DSRC, LTE, + and C-V2X). Thus, V2V means any vehicle to any vehicle, whether the + vehicles are ground level or not. + + Cooperative Adaptive Cruise Control (CACC) [CA-Cruise-Control] helps + individual vehicles to adapt their speed autonomously through V2V + communication among vehicles according to the mobility of their + predecessor and successor vehicles on an urban roadway or a highway. + Thus, CACC can help adjacent vehicles to efficiently adjust their + speed in an interactive way through V2V networking in order to avoid + a collision. + + Platooning [Truck-Platooning] allows a series (or group) of vehicles + (e.g., trucks) to follow each other very closely. Vehicles can use + V2V communication in addition to forward sensors in order to maintain + 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 the gas consumption + because the lead vehicle can help the following vehicles experience + less air resistance. + + Cooperative-environment-sensing use cases suggest that vehicles can + share environmental information (e.g., air pollution, hazards, + obstacles, slippery areas by snow or rain, road accidents, traffic + congestion, and driving behaviors of neighboring vehicles) from + various vehicle-mounted sensors, such as radars, LiDAR systems, and + cameras, with other vehicles and pedestrians. [Automotive-Sensing] + introduces millimeter-wave vehicular communication for massive + automotive sensing. A lot of data can be generated by those sensors, + and these data typically need to be routed to different destinations. + In addition, from the perspective of driverless vehicles, it is + expected that driverless vehicles can 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. Thus, this + information sharing can help the vehicles behave as more efficient + traffic flows and minimize unnecessary acceleration and deceleration + to achieve the best ride comfort. + + To support applications of 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 the support of V2V under multiple radio + technologies (e.g., DSRC and 5G V2X), refer to Appendix A. + +3.2. V2I + + The use cases of V2I networking discussed in this section include: + + * 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 (for example, the Self-Adaptive Interactive + Navigation Tool [SAINT]) that uses V2I networking interacts with a + TCC for the large-scale/long-range road traffic optimization and can + guide individual vehicles along appropriate navigation paths in real + time. The enhanced version of SAINT [SAINTplus] can give fast-moving + paths to emergency vehicles (e.g., ambulance and fire engine) to let + them reach an accident spot while redirecting other vehicles near the + accident spot into efficient detour paths. + + Either a TCC or an ECD can recommend an energy-efficient speed to a + vehicle that depends on its traffic environment and traffic signal + scheduling [SignalGuru]. For example, when a vehicle approaches an + intersection area and a red traffic light for the vehicle becomes + turned on, it needs to reduce its speed to save fuel consumption. 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 notify + the vehicle of an appropriate speed for fuel efficiency. + [Fuel-Efficient] covers fuel-efficient route and speed plans for + platooned trucks. + + The emergency communication between vehicles in an accident (or + emergency-response vehicles) and a TCC can be performed via either + IP-RSUs or 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 construction of the nationwide FirstNet network requires + each state in the US to have a Radio Access Network (RAN) that will + connect to the FirstNet's network core. The current RAN is mainly + constructed using 4G-LTE for communication between a vehicle and an + infrastructure node (i.e., V2I) [FirstNet-Report], but it is expected + that DSRC-based vehicular networks [DSRC] will be available for V2I + and V2V in the near future. An equivalent project in Europe is + called Public Safety Communications Europe [PSCE], which is + developing a network for emergency communications. + + An EV charging service with V2I can facilitate the efficient battery + charging of EVs. In the case where an EV charging station is + connected to an IP-RSU, an EV can be guided toward the deck of the EV + charging station or be notified that the charging station is out of + service through a battery charging server connected to the IP-RSU. + In addition to this EV charging service, other value-added services + (e.g., firmware/software update over-the-air and media streaming) can + be provided to an EV while it is charging its battery at the EV + charging 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 + battery charging schedule, a UAM end system can communicate with a + cloud server via an infrastructure node (e.g., IP-RSU). This cloud + server can coordinate the battery charging schedules of multiple UAM + end systems for their 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, such as 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 to 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 must 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 necessary to + support wireless multihop V2I communications on a highway where RSUs + are sparsely deployed so that a vehicle can reach the wireless + coverage of an IP-RSU through the multihop data forwarding of + intermediate vehicles as packet forwarders. Thus, IPv6 needs to be + extended for multihop V2I communications. + + To support applications of 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 + + The use case of V2X networking discussed in this section is for a + protection service for a vulnerable road user (VRU), e.g., a + pedestrian or cyclist. Note that the application area of this use + case is currently limited to a specific environment, such as + construction sites, plants, and factories, since not every VRU in a + public area is equipped with a smart device (e.g., not every child on + a road has a smartphone, smart watch, or tablet). + + A VRU protection service, such as the Safety-Aware Navigation + Application [SANA], using V2I2P networking can reduce the collision + of a vehicle and a pedestrian carrying a smartphone equipped with a + network device for wireless communication (e.g., Wi-Fi, DSRC, 4G/5G + V2X, and Bluetooth Low Energy (BLE)) with an IP-RSU. Vehicles and + pedestrians can also communicate with each other via an IP-RSU. An + ECD behind the IP-RSU can collect the mobility information from + vehicles and pedestrians, and then compute wireless communication + scheduling for the sake of them. This scheduling can save the + battery of each pedestrian's smartphone by allowing it to work in + sleeping mode before communication with vehicles, considering their + mobility. The location information of a VRU from a smart device + (e.g., smartphone) is multicasted only to the nearby vehicles. The + true identifiers of a VRU's smart device shall be protected, and only + the type of the VRU, such as pedestrian, cyclist, or scooter, is + disclosed to the nearby vehicles. + + For Vehicle-to-Pedestrian (V2P), a vehicle can directly communicate + with a pedestrian's smartphone by V2X without IP-RSU relaying. + Light-weight mobile nodes, such as bicycles, may also communicate + directly with a vehicle for collision avoidance using V2V. Note that + it is true that either a pedestrian or a cyclist may have a higher + risk of being hit by a vehicle if they are not with a smartphone in + the current setting. For this case, other human-sensing technologies + (e.g., moving-object detection in images and wireless signal-based + human movement detection [LIFS] [DFC]) can be used to provide motion + information to vehicles. A vehicle by V2V2I networking can obtain a + VRU's motion information via an IP-RSU that either employs or + connects to a human-sensing technology. + + The existing IPv6 protocol must be augmented through protocol changes + in order to support wireless multihop V2X or V2I2X communications in + an urban road network where RSUs are deployed at intersections so + that a vehicle (or a pedestrian's smartphone) can reach the wireless + coverage of an IP-RSU through the multihop data forwarding of + intermediate vehicles (or pedestrians' smartphones) as packet + forwarders. Thus, IPv6 needs to be extended for multihop V2X or + V2I2X communications. + + To support applications of these V2X use cases, the required + functions of IPv6 include IPv6-based packet exchange; transport-layer + session continuity; secure, safe communication between a vehicle and + a pedestrian either directly or indirectly via an IP-RSU; and the + protection of identifiers of either 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 describes the context for vehicular networks supporting + V2V, V2I, and V2X communications and describes an internal network + within a vehicle or an Edge Network (EN). Additionally, this section + explains not only the internetworking between the internal networks + of a vehicle and an EN via wireless links but also the + internetworking between the internal networks of two vehicles via + 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 Direction + + Figure 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 vehicular network architecture contains + vehicles (including IP-OBU), IP-RSUs, Mobility Anchor, Traffic + Control Center, and 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., Mobility Anchor, Traffic + Control Center, and Vehicular Cloud) may not be needed for the + vehicular networks according to target use cases in Section 3. + + Existing network architectures, such as 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], can be extended to a + vehicular network architecture for multihop V2V, V2I, and V2X, as + shown in Figure 1. Refer to Appendix B for the detailed discussion + on multihop V2X networking by RPL and OMNI. Also, refer to + Appendix A for the description of how OMNI is designed to support the + use of multiple radio technologies in V2X. Note that though AERO/ + OMNI is not actually deployed in the industry, this AERO/OMNI is + mentioned 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 are + connected with each other through the wired networks (e.g., + Ethernet). A Traffic Control Center (TCC) is connected to the + Vehicular Cloud for the management of 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 (i.e., Subnet1, Subnet2, and + Subnet3), respectively. Those three subnets use three different + prefixes (i.e., Prefix1, Prefix2, and Prefix3). + + Multiple vehicles under the coverage of an IP-RSU share a prefix just + as 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 (i.e., + 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 can communicate with each other via V2V + communication. Vehicle1 can communicate with Vehicle2 via V2V + communication, and Vehicle2 can communicate with Vehicle3 via V2V + communication because they are within the wireless communication + range of each other. On the other hand, Vehicle3 can communicate + with Vehicle4 via the vehicular infrastructure (i.e., IP-RSU2 and IP- + RSU3) by employing V2I (i.e., V2I2V) communication because they are + not within the wireless communication range of each other. + + 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 for the guarantee of + communication continuity in vehicular networks so that a vehicle's + TCP session can be continued or that UDP packets can be delivered to + a vehicle as a destination without loss while it moves from an IP- + RSU's wireless coverage to another IP-RSU's wireless coverage. In + Figure 1, assuming that Vehicle2 has a TCP session (or a UDP session) + with a correspondent node in the Vehicular Cloud, Vehicle2 can move + from IP-RSU1's wireless coverage to IP-RSU2's wireless coverage. In + this case, 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. For improving TCP session continuity or successful UDP + packet delivery, the Multipath TCP (MPTCP) [RFC8684] or QUIC protocol + [RFC9000] can also be used. IP-OBUs, however, may still experience + more session time-out and re-establishment procedures due to lossy + connections among vehicles caused by the high mobility dynamics of + them. + +4.2. V2I-Based Internetworking + + This section discusses the internetworking between a vehicle's + internal network (i.e., mobile network) and an EN's internal network + (i.e., fixed network) via V2I communication. The internal network of + a vehicle is nowadays constructed with Ethernet by many automotive + vendors [In-Car-Network]. Note that an EN can accommodate multiple + routers (or switches) and servers (e.g., ECDs, navigation server, and + DNS server) in its internal network. + + A vehicle's internal network often uses Ethernet to interconnect + Electronic Control Units (ECUs) in the vehicle. The internal network + can support Wi-Fi and Bluetooth to accommodate a driver's and + passenger's mobile devices (e.g., smartphone or tablet). The network + topology and subnetting depend on each vendor's network configuration + for a vehicle and an EN. It is reasonable to consider interactions + between the internal network of a vehicle and that of another vehicle + or an EN. Note that it is dangerous if the internal network of a + vehicle is controlled by a malicious party. These dangers can + include unauthorized driving control input and unauthorized driving + information disclosure to an unauthorized third party. A malicious + party can be a group of hackers, a criminal group, and a competitor + for industrial espionage or sabotage. To minimize this kind of risk, + an augmented identification and verification protocol, which has an + extra means, shall be implemented based on a basic identity + verification process. These extra means could include approaches + based on certificates, biometrics, credit, or One-Time Passwords + (OTPs) in addition to Host Identity Protocol certificates [RFC8002]. + The parties of the verification protocol can be from a built-in + verification protocol in the current vehicle, which is pre-installed + by a vehicle vendor. The parties can also be from any verification + authorities that have the database of authenticated users. The + security properties provided by a verification protocol can be + identity-related information, such as 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 such as the identification and + verification of a vehicle, driver, and passenger. First, a credit- + based method is when a vehicle classifies the messages it received + from another host into various levels based on their potential + effects on driving safety in order to calculate the credit of that + sender. Based on accumulated credit, a correspondent node can verify + the other party to see whether it is genuine or not. Second, a + certificate-based method includes a user certificate (e.g., X.509 + certificate [RFC5280]) to authenticate a vehicle or its driver. + Third, a biometric method includes a fingerprint, face, or voice to + authenticate a driver or passenger. Lastly, an OTP-based method lets + another already-authenticated device (e.g., smartphone and tablet) of + a driver or passenger be used to authenticate a driver or passenger. + + +-----------------+ + (*)<........>(*) +----->| 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 Network + + As shown in Figure 2, as internal networks, a vehicle's mobile + network and an EN's fixed network are self-contained networks having + multiple subnets and having an edge router (e.g., IP-OBU and IP-RSU) + for communication with another vehicle or another EN. The + internetworking between two internal networks via V2I communication + requires the exchange of the network parameters and the network + prefixes of the internal networks. For the efficiency, the network + prefixes of the internal networks (as a mobile network) in a vehicle + need to be delegated and configured automatically. Note that a + mobile network's network prefix can be called a Mobile Network Prefix + (MNP) [RFC3963]. + + Figure 2 also shows the internetworking between the vehicle's mobile + network and the EN's fixed network. There exists an internal network + (Mobile Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and + Host2) and two routers (IP-OBU1 and Router1). There exists another + internal network (Fixed Network1) inside EN1. EN1 has one host + (Host3), two routers (IP-RSU1 and Router2), and the collection of + servers (Server1 to ServerN) for various services in the road + networks, such as the emergency notification and navigation. + Vehicle1's IP-OBU1 (as a mobile router) and EN1's IP-RSU1 (as a fixed + router) use 2001:db8:1:1::/64 for an external link (e.g., DSRC) for + V2I networking. Thus, a host (Host1) in Vehicle1 can communicate + with a server (Server1) in EN1 for a vehicular service through + Vehicle1's mobile network, a wireless link between IP-OBU1 and IP- + RSU1, and EN1's fixed network. + + For the IPv6 communication between an IP-OBU and an IP-RSU or between + two neighboring IP-OBUs, they need to know the network parameters, + which include MAC layer and IPv6 layer information. The MAC layer + information includes wireless link-layer parameters, transmission + power level, and the MAC address of an external network interface for + the internetworking with another IP-OBU or IP-RSU. The IPv6 layer + information includes the IPv6 address and network prefix of an + external network interface for the internetworking with another IP- + OBU or IP-RSU. + + Through the mutual knowledge of the network parameters of internal + networks, packets can be transmitted between the vehicle's mobile + network and the EN's fixed network. Thus, V2I requires an efficient + protocol for the mutual knowledge of network parameters. Note that + from a security point of view, perimeter-based policy enforcement + [RFC9099] can be applied to protect parts of the internal network of + a vehicle. + + As shown in Figure 2, the addresses used for IPv6 transmissions over + the wireless link interfaces for IP-OBU and IP-RSU can be IPv6 link- + local addresses, ULAs, or IPv6 global addresses. When IPv6 addresses + are used, wireless interface configuration and control overhead for + Duplicate Address Detection (DAD) [RFC4862] and Multicast Listener + Discovery (MLD) [RFC2710] [RFC3810] should be minimized to support + V2I and V2X communications for vehicles moving fast along roadways. + + Let us consider the upload/download time of a ground vehicle when it + passes through the wireless communication coverage of an IP-RSU. For + a given typical setting where 1 km is the maximum DSRC communication + range [DSRC] and 100 km/h is the speed limit on highways for ground + vehicles, the dwelling time can be calculated to be 72 seconds by + dividing the diameter of the 2 km (i.e., two times the DSRC + communication range where an IP-RSU is located in the center of the + circle of wireless communication) by the speed limit of 100 km/h + (i.e., about 28 m/s). For the 72 seconds, a vehicle passing through + the coverage of an IP-RSU can upload and download data packets to/ + from the IP-RSU. For special cases, such as emergency vehicles + moving above the speed limit, the dwelling time is relatively shorter + than that of other vehicles. For cases of airborne vehicles (i.e., + aircraft), considering a higher flying speed and a higher altitude, + the dwelling time can be much shorter. + +4.3. V2V-Based Internetworking + + This section discusses the internetworking between the mobile + networks of two neighboring vehicles via 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 Vehicles + + Figure 3 shows the internetworking between the mobile networks of two + neighboring vehicles. There exists an internal network (Mobile + Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and Host2) + and two routers (IP-OBU1 and Router1). There exists another internal + network (Mobile Network2) inside Vehicle2. Vehicle2 has two hosts + (Host3 and Host4) and two routers (IP-OBU2 and Router2). Vehicle1's + IP-OBU1 (as a mobile router) and Vehicle2's IP-OBU2 (as a mobile + router) use 2001:db8:1:1::/64 for an external link (e.g., DSRC) for + V2V networking. Thus, 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. + + As a V2V use case in Section 3.1, Figure 4 shows a linear network + topology of platooning vehicles for V2V communications where 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. + + (*)<..................>(*)<..................>(*) + | | | + +-----------+ +-----------+ +-----------+ + | | | | | | + | +-------+ | | +-------+ | | +-------+ | + | |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 Networks + + As 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. + + 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) with 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 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 for serving + 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 + + In order to specify protocols using the architecture mentioned in + Section 4.1, IPv6 core protocols have to be adapted to overcome + certain challenging aspects of vehicular networking. Since the + vehicles are likely to be moving at great speed, protocol exchanges + need to be completed in a relatively short time compared to the + lifetime of a link between a vehicle and an IP-RSU or between two + vehicles. In these cases, vehicles may not have enough time either + to build link-layer connections with each other and may rely more on + connections with infrastructure. In other cases, the relative speed + between vehicles may be low when vehicles move toward the same + direction or are platooned. For those cases, vehicles can have more + time to build and maintain connections with each other. + + For safe driving, vehicles need to exchange application messages + every 0.5 seconds [NHTSA-ACAS-Report] to let drivers take an action + to avoid a dangerous situation (e.g., vehicle collision), so the IPv6 + control plane (e.g., ND procedure and DAD) needs to support this + order of magnitude for application message exchanges. Also, + considering the communication range of DSRC (up to 1 km) and 100 km/h + as the speed limit on highways (some countries can have much higher + speed limits or even no limit, e.g., Germany), the lifetime of a link + between a vehicle and an IP-RSU is in the order of a minute (e.g., + about 72 seconds), and the lifetime of a link between two vehicles is + about a half minute. Note that if two vehicles are moving in the + opposite directions in a roadway, the relative speed of this case is + two times the relative speed of a vehicle passing through an IP-RSU. + This relative speed causes the lifetime of the wireless link between + the vehicle and the IP-RSU to be halved. In reality, the DSRC + communication range is around 500 m, so the link lifetime will be + half of the maximum time. The time constraint of a wireless link + between two nodes (e.g., vehicle and IP-RSU) needs to be considered + because it may affect the lifetime of a session involving the link. + The lifetime of a session varies depending on the session's type, + such as web surfing, a voice call over IP, a DNS query, or context- + aware navigation (in Section 3.1). Regardless of a session's type, + to guide all the IPv6 packets to their destination host(s), IP + mobility should be supported for the session. In a V2V scenario + (e.g., context-aware navigation [CNP]), the IPv6 packets of a vehicle + should be delivered to relevant vehicles efficiently (e.g., + multicasting). With this observation, IPv6 protocol exchanges need + to be performed as quickly as possible to support the message + exchanges of various applications in vehicular networks. + + Therefore, the time constraint of a wireless link has a major impact + on IPv6 Neighbor Discovery (ND). Mobility Management (MM) is also + vulnerable to disconnections that occur before the completion of + identity verification and tunnel management. This is especially true + given the unreliable nature of wireless communication. Meanwhile, + the bandwidth of the wireless link determined by the lower layers + (i.e., PHY and link layers) can affect the transmission time of + control messages of the upper layers (e.g., IPv6) and the continuity + of sessions in the higher layers (e.g., IPv6, TCP, and UDP). Hence, + the bandwidth selection according to the Modulation and Coding Scheme + (MCS) also affects the vehicular network connectivity. Note that + usually the higher bandwidth gives the shorter communication range + and the higher packet error rate at the receiving side, which may + reduce the reliability of control message exchanges of the higher + layers (e.g., IPv6). This section presents key topics, such as + neighbor discovery and mobility management for links and sessions in + IPv6-based vehicular networks. Note that the detailed discussion on + the transport-layer session mobility and usage of available bandwidth + to fulfill the use cases is left as potential future work. + +5.1. Neighbor Discovery + + IPv6 ND [RFC4861] [RFC4862] is a core part of the IPv6 protocol + suite. IPv6 ND is designed for link types including point-to-point, + multicast-capable (e.g., Ethernet), and Non-Broadcast Multiple Access + (NBMA). It assumes the efficient and reliable support of multicast + and unicast from the link layer for various network operations, such + as MAC Address Resolution (AR), DAD, MLD, and Neighbor Unreachability + Detection (NUD) [RFC4861] [RFC4862] [RFC2710] [RFC3810]. + + Vehicles move quickly within the communication coverage of any + particular vehicle or IP-RSU. Before the vehicles can exchange + application messages with each other, they need IPv6 addresses to run + IPv6 ND. + + The requirements for IPv6 ND for vehicular networks are efficient DAD + and NUD operations. An efficient DAD is required to reduce the + overhead of DAD packets during a vehicle's travel in a road network, + which can guarantee the uniqueness of a vehicle's global IPv6 + address. An efficient NUD is required to reduce the overhead of the + NUD packets during a vehicle's travel in a road network, which can + guarantee the accurate neighborhood information of a vehicle in terms + of adjacent vehicles and IP-RSUs. + + The legacy DAD assumes that a node with an IPv6 address can reach any + other node with the scope of its address at the time it claims its + address, and can hear any future claim for that address by another + party within the scope of its address for the duration of the address + ownership. However, the partitioning and merging of VANETs makes + this assumption not valid frequently in vehicular networks. The + partitioning and merging of VANETs frequently occurs in vehicular + networks. This partitioning and merging should be considered for + IPv6 ND, such as IPv6 Stateless Address Autoconfiguration (SLAAC) + [RFC4862]. SLAAC is not compatible with the partitioning and + merging, and additional work is needed for ND to operate properly + under those circumstances. Due to the merging of VANETs, two IPv6 + addresses may conflict with each other though they were unique before + the merging. An address lookup operation may be conducted by an MA + or IP-RSU (as Registrar in RPL) to check the uniqueness of an IPv6 + address that will be configured by a vehicle as DAD. Also, the + partitioning of a VANET may make vehicles with the same prefix be + physically unreachable. An address lookup operation may be conducted + by an MA or IP-RSU (as Registrar in RPL) to check the existence of a + vehicle under the network coverage of the MA or IP-RSU as NUD. Thus, + SLAAC needs to prevent IPv6 address duplication due to the merging of + VANETs, and IPv6 ND needs to detect unreachable neighboring vehicles + due to the partitioning of a VANET. According to the partitioning + and merging, a destination vehicle (as an IPv6 host) needs to be + distinguished as a host that is either on-link or not on-link even + though the source vehicle can use the same prefix as the destination + vehicle [IPPL]. + + To efficiently prevent IPv6 address duplication (due to the VANET + partitioning and merging) from happening in vehicular networks, the + vehicular networks need to support a vehicular-network-wide DAD by + defining a scope that is compatible with the legacy DAD. In this + case, two vehicles can communicate with each other when there exists + a communication path over VANET or a combination of VANETs and IP- + RSUs, as shown in Figure 1. By using the vehicular-network-wide DAD, + vehicles can assure that their IPv6 addresses are unique in the + vehicular network whenever they are connected to the vehicular + infrastructure or become disconnected from it in the form of VANET. + + For vehicular networks with high mobility and density, DAD needs to + be performed efficiently with minimum overhead so that the vehicles + can exchange driving safety messages (e.g., collision avoidance and + accident notification) with each other with a short interval as + suggested by the National Highway Traffic Safety Administration + (NHTSA) of the U.S. [NHTSA-ACAS-Report]. Since the partitioning and + merging of vehicular networks may require re-performing the DAD + process repeatedly, the link scope of vehicles may be limited to a + small area, which may delay the exchange of driving safety messages. + Driving safety messages can include a vehicle's mobility information + (e.g., position, speed, direction, and acceleration/deceleration) + that is critical to other vehicles. The exchange interval of this + message is recommended to be less than 0.5 seconds, which is required + for a driver to avoid an emergency situation, such as a rear-end + crash. + + ND time-related parameters, such as 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 + dynamically adjusted according to a vehicle's speed so that the + vehicle can maintain its position relative to its neighboring + vehicles in a stable way, considering the collision probability with + the NA messages sent by other vehicles. The ND time-related + parameters can be an operational setting or an optimization point + particularly for vehicular networks. Note that the link-scope + multicast messages in the ND protocol may cause a performance issue + in vehicular networks. [RFC9119] suggests several optimization + approaches for the issue. + + For IPv6-based safety applications (e.g., context-aware navigation, + adaptive cruise control, and platooning) in vehicular networks, the + delay-bounded data delivery is critical. IPv6 ND needs to work to + support those IPv6-based safety applications efficiently. + [VEHICULAR-ND] introduces a Vehicular Neighbor Discovery (VND) + process as an extension of IPv6 ND for IP-based vehicular networks. + + From the interoperability point of view, in IPv6-based vehicular + networking, IPv6 ND should have minimum changes from the legacy IPv6 + ND used in the Internet, including DAD and NUD operations, so that + IPv6-based vehicular networks can be seamlessly connected to other + intelligent transportation elements (e.g., traffic signals, + pedestrian wearable devices, electric scooters, and bus stops) that + use the standard IPv6 network settings. + +5.1.1. Link Model + + A subnet model for a vehicular network needs to facilitate + communication between two vehicles with the same prefix regardless of + the vehicular network topology as long as there exist bidirectional + E2E paths between them in the vehicular network including VANETs and + IP-RSUs. This subnet model allows vehicles with the same prefix to + communicate with each other via a combination of multihop V2V and + multihop V2I with VANETs and IP-RSUs. [WIRELESS-ND] introduces other + issues in an IPv6 subnet model. + + IPv6 protocols work under certain assumptions that do not necessarily + hold for vehicular wireless access link types [VIP-WAVE] [RFC5889]. + For instance, some IPv6 protocols, such as NUD [RFC4861] and MIPv6 + [RFC6275], assume symmetry in the connectivity among neighboring + interfaces. However, radio interference and different levels of + transmission power may cause asymmetric links to appear in vehicular + wireless links [RFC6250]. As a result, a new vehicular link model + needs to consider the asymmetry of dynamically changing vehicular + wireless links. + + There is a relationship between a link and a prefix, besides the + different scopes that are expected from the link-local, unique-local, + and global types of IPv6 addresses. In an IPv6 link, it is defined + that all interfaces that are configured with the same subnet prefix + and with the on-link bit set can communicate with each other on an + IPv6 link. However, the vehicular link model needs to define the + relationship between a link and a prefix, considering the dynamics of + wireless links and the characteristics of VANET. + + A VANET can have a single link between each vehicle pair within the + wireless communication range, as shown in Figure 4. When two + vehicles belong to the same VANET, but they are out of wireless + communication range, they cannot communicate directly with each + other. Suppose that a global-scope IPv6 prefix (or an IPv6 ULA + prefix) is assigned to VANETs in vehicular networks. Considering + that two vehicles in the same VANET configure their IPv6 addresses + with the same IPv6 prefix, if they are not connected in one hop (that + is, they have multihop network connectivity between them), then they + may not be able to communicate with each other. Thus, in this case, + the concept of an on-link IPv6 prefix does not hold because two + vehicles with the same on-link IPv6 prefix cannot communicate + directly with each other. Also, when two vehicles are located in two + different VANETs with the same IPv6 prefix, they cannot communicate + with each other. On the other hand, when these two VANETs converge + to one VANET, the two vehicles can communicate with each other in a + multihop fashion, for example, when they are Vehicle1 and Vehicle3, + as shown in Figure 4. + + From the previous observation, a vehicular link model should consider + the frequent partitioning and merging of VANETs due to vehicle + mobility. Therefore, the vehicular link model needs to use a prefix + that is on-link and a prefix that is not on-link according to the + network topology of vehicles, such as a one-hop reachable network and + a multihop reachable network (or partitioned networks). If the + vehicles with the same prefix are reachable from each other in one + hop, the prefix should be on-link. On the other hand, if some of the + vehicles with the same prefix are not reachable from each other in + one hop due to either the multihop topology in the VANET or multiple + partitions, the prefix should not be on-link. In most cases in + vehicular networks, due to the partitioning and merging of VANETs and + the multihop network topology of VANETs, prefixes that are not on- + link will be used for vehicles as default. + + The vehicular link model needs to support multihop routing in a + connected VANET where the vehicles with the same global-scope IPv6 + prefix (or the same IPv6 ULA prefix) are connected in one hop or + multiple hops. It also needs to support the multihop routing in + multiple connected VANETs through infrastructure nodes (e.g., IP-RSU) + where they are connected to the infrastructure. For example, in + Figure 1, suppose that Vehicle1, Vehicle2, and Vehicle3 are + configured with their IPv6 addresses based on the same global-scope + IPv6 prefix. Vehicle1 and Vehicle3 can also communicate with each + other via either multihop V2V or multihop V2I2V. When Vehicle1 and + Vehicle3 are connected in a VANET, it will be more efficient for them + to communicate with each other directly via VANET rather than + indirectly via IP-RSUs. On the other hand, when Vehicle1 and + Vehicle3 are farther apart than the direct communication range in two + separate VANETs and under two different IP-RSUs, they can communicate + with each other through the relay of IP-RSUs via V2I2V. Thus, the + two separate VANETs can merge into one network via IP-RSU(s). Also, + newly arriving vehicles can merge the two separate VANETs into one + VANET if they can play the role of a relay node for those VANETs. + + Thus, in IPv6-based vehicular networking, the vehicular link model + should have minimum changes for interoperability with standard IPv6 + links efficiently to support IPv6 DAD, MLD, and NUD operations. + +5.1.2. MAC Address Pseudonym + + For the protection of drivers' privacy, a pseudonym of a MAC address + of a vehicle's network interface should be used so that the MAC + address can be changed periodically. However, although such a + pseudonym of a MAC address can protect to some extent the privacy of + a vehicle, it may not be able to resist attacks on vehicle + identification by other fingerprint information, for example, the + scrambler seed embedded in IEEE 802.11-OCB frames [Scrambler-Attack]. + Note that [MAC-ADD-RAN] discusses more about MAC address + randomization, and [RCM-USE-CASES] describes several use cases for + MAC address randomization. + + In the ETSI standards, for the sake of security and privacy, an ITS + station (e.g., vehicle) can use pseudonyms for its network interface + identities (e.g., MAC address) and the corresponding IPv6 addresses + [Identity-Management]. Whenever the network interface identifier + changes, the IPv6 address based on the network interface identifier + needs to be updated, and the uniqueness of the address needs to be + checked through a DAD procedure. + +5.1.3. Routing + + For multihop V2V communications in either a VANET or VANETs via IP- + RSUs, a vehicular Mobile Ad Hoc Networks (MANET) routing protocol may + be required to support both unicast and multicast in the links of the + subnet with the same IPv6 prefix. However, it will be costly to run + both vehicular ND and a vehicular ad hoc routing protocol in terms of + control traffic overhead [RFC9119]. + + A routing protocol for a VANET may cause redundant wireless frames in + the air to check the neighborhood of each vehicle and compute the + routing information in a VANET with a dynamic network topology + because IPv6 ND is used to check the neighborhood of each vehicle. + Thus, the vehicular routing needs to take advantage of IPv6 ND to + minimize its control overhead. + + RPL [RFC6550] defines a routing LLN protocol, which constructs and + maintains Destination-Oriented Directed Acyclic Graphs (DODAGs) + optimized by an Objective Function (OF). A defined OF provides route + selection and optimization within an RPL topology. The RPL nodes use + an anisotropic Distance Vector (DV) approach to form a DODAG by + discovering and aggressively maintaining the upward default route + toward the root of the DODAG. Downward routes follow the same DODAG, + with lazy maintenance and stretched peer-to-peer (P2P) routing in the + so-called storing mode. It is well-designed to reduce the + topological knowledge and routing state that needs to be exchanged. + As a result, the routing protocol overhead is minimized, which allows + either highly constrained stable networks or less constrained, highly + dynamic networks. Refer to Appendix B for the detailed description + of RPL for multihop V2X networking. + + An address registration extension for 6LoWPAN (IPv6 over Low-Power + Wireless Personal Area Network) in [RFC8505] can support light-weight + mobility for nodes moving through different parents. The extension + described in [RFC8505] is stateful and proactively installs the ND + cache entries; this saves broadcasts and provides deterministic + presence information for IPv6 addresses. Mainly, it updates the + Address Registration Option (ARO) of ND defined in [RFC6775] to + include a status field (which can indicate the movement of a node) + and optionally a Transaction ID (TID) field (which is a sequence + number that can be used to determine the most recent location of a + node). Thus, RPL can use the information provided by the Extended + ARO (EARO) defined in [RFC8505] to deal with a certain level of node + mobility. When a leaf node moves to the coverage of another parent + node, it should de-register its addresses with the previous parent + node and register itself with a new parent node along with an + incremented TID. + + RPL can be used in IPv6-based vehicular networks, but it is primarily + designed for low-power networks, which puts energy efficiency first. + For using it in IPv6-based vehicular networks, there have not been + actual experiences and practical implementations, 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, such as vehicular networks. + This issue can be an operational or optimization point for a + practitioner. + + Moreover, due to bandwidth and energy constraints, RPL does not + suggest using a proactive mechanism (e.g., keepalive) to maintain + accurate routing adjacencies, such as Bidirectional Forwarding + Detection [RFC5881] and MANET Neighborhood Discovery Protocol + [RFC6130]. As a result, due to the mobility of vehicles, network + fragmentation may not be detected quickly, and the routing of packets + between vehicles or between a vehicle and an infrastructure node may + fail. + +5.2. Mobility Management + + The seamless connectivity and timely data exchange between two + endpoints requires efficient mobility management including location + management and handover. Most vehicles are equipped with a GNSS + receiver as part of a dedicated navigation system or a corresponding + smartphone app. Note that the GNSS receiver may not provide vehicles + with accurate location information in adverse environments, such as a + building area or a tunnel. The location precision can be improved + with assistance of the IP-RSUs or a cellular system with a GNSS + receiver for location information. + + With a GNSS navigator, efficient mobility management can be performed + with the help of vehicles periodically reporting their current + position and trajectory (i.e., navigation path) to the vehicular + infrastructure (having IP-RSUs and an MA in TCC). This vehicular + infrastructure can predict the future positions of the vehicles from + their mobility information (e.g., the current position, speed, + direction, and trajectory) for efficient mobility management (e.g., + proactive handover). For a better proactive handover, link-layer + parameters, such as 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 + mobility information. + + By predicting a vehicle's mobility, the vehicular infrastructure + needs to better support IP-RSUs to 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 along with the movement of the vehicle. + + 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) belonging to a different + subnet, the IP-RSUs can proactively support the IPv6 mobility of the + vehicle while performing 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 the prefix usage efficiency + and DAD overhead. Thus, the 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 the minimization of 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 such direct routability to the + Internet since the BYOA is not topologically correct, that is, not + routable in the Internet. In addition, 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 the 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, 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. 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 the vehicles with + their mobility information and link-layer information. Also, in + IPv6-based vehicular networking, IPv6 mobility management should have + minimum changes for the interoperability with the legacy IPv6 + mobility management schemes, such as PMIPv6, DMM, LISP, and AERO. + +6. Security Considerations + + This section discusses security and privacy for IPv6-based vehicular + networking. 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 participate in + vehicular networking. For the authentication in vehicular networks, + the Vehicular Cloud needs to support a Public Key Infrastructure + (PKI) efficiently, as either a dedicated or 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) in 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 though a vehicle is perfectly + authenticated by another entity and legitimate to use the data + generated by another vehicle, it may be hacked by malicious + applications that track and collect its 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 due to the exposure of its in-flight + traffic packets. [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 and a driver/passenger's mobile device) needs to + establish a secure connection (e.g., TLS) with another element in + another vehicle or 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 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, either the network layer or the transport layer needs to + support security services for the WAVE frame. + +6.1. Security Threats in Neighbor Discovery + + For the classical IPv6 ND (i.e., the legacy ND), DAD is required to + ensure the uniqueness of the IPv6 address of a vehicle's wireless + interface. This DAD can be used as a flooding attack that uses the + DAD-related ND packets disseminated over the VANET or vehicular + networks. [RFC6959] introduces threats enabled by IP source address + spoofing. This possibility indicates that vehicles and IP-RSUs need + to filter out suspicious ND traffic in advance. [RFC8928] introduces + a mechanism that protects the ownership of an address for 6LoWPAN ND + from address theft and impersonation attacks. Based on the SEND + mechanism [RFC3971], the authentication for routers (i.e., IP-RSUs) + can be conducted by only selecting 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 against + DAD flooding by DAD filtering based on the verification for the true + owner of the received DAD message. For a general protection of the + ND mechanism, the RSA Signature ND option can also be used to protect + the integrity of the messages by 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 that the + capacity and resources of the IP-RSU (or IP-OBU) are exhausted, + causing the failure of receiving 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 suggests + several implementation guidelines and operational mitigation + techniques for those problems. Nevertheless, for running IPv6 ND in + VANET, those issues can be acuter since 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) for disturbing 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 to + allow 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 + + For the setup of a secure channel over IPsec or TLS, the multihop V2I + communications over DSRC or 5G V2X (or LTE V2X) is required on a + highway. In this case, multiple intermediate vehicles as relay nodes + can help to forward association and authentication messages toward an + IP-RSU (or gNodeB/eNodeB) connected to an authentication server in + the Vehicular Cloud. In this kind of process, the authentication + messages forwarded by each vehicle can be delayed or lost, which may + increase the construction time of a connection or cause some vehicles + to not be able to be authenticated. + + Even though vehicles can be authenticated with valid certificates by + an authentication server in the Vehicular Cloud, the authenticated + vehicles may harm other vehicles. To deal with this kind of security + issue, for monitoring suspicious behaviors, vehicles' communication + activities can be recorded in either a centralized approach through a + logging server (e.g., TCC) in the Vehicular Cloud or a decentralized + approach (e.g., an ECD and blockchain [Bitcoin]) by the help of other + vehicles and infrastructure. + + There are trade-offs between centralized and decentralized approaches + in logging of vehicles' behaviors (e.g., location, speed, direction, + acceleration/deceleration, and lane change) and communication + activities (e.g., transmission time, reception time, and packet + types, such as TCP, UDP, SCTP, QUIC, HTTP, and HTTPS). A centralized + approach is more efficient than a decentralized approach in terms of + log data collection and processing in a central server in the + Vehicular Cloud. However, the centralized approach may cause a + higher delay than a decentralized approach in terms of the analysis + of the log data and counteraction in a local ECD or a distributed + database like a blockchain. The centralized approach stores log data + collected from VANET into a remote logging server in a Vehicular + Cloud as a central cloud, so it takes time to deliver the log data to + a remote logging server. On the other hand, the decentralized + approach stores the log data into a nearby edge computing device as a + local logging server or a nearby blockchain node, which participates + in a blockchain network. On the stored log data, an analyzer needs + to perform a machine learning technique (e.g., deep learning) and + seek suspicious behaviors of the vehicles. If such an analyzer is + located either within or near the edge computing device, it can + access the log data with a short delay, analyze it quickly, and + generate feedback to allow for a quick counteraction against such + malicious behaviors. On the other hand, if the Vehicular Cloud with + the log data is far away from a problematic VANET with malicious + behaviors, the centralized approach takes a longer time with the + analysis of the log data and the decision-making on malicious + behaviors than the decentralized approach. If the log data is + encrypted by a secret key, it can be protected from the observation + of a hacker. The secret key sharing among legal vehicles, ECDs, and + Vehicular Clouds should be supported efficiently. + + Log data can release privacy breakage of a vehicle. The log data can + contain the MAC address and IPv6 address for a vehicle's wireless + network interface. If the unique MAC address of the wireless network + interface is used, a hacker can track the vehicle with that MAC + address and can 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 corresponding IPv6 address should be based + on such a MAC address pseudonym. By solving a privacy issue of a + vehicle's identity in logging, vehicles may observe each other's + activities to identify any misbehaviors without privacy breakage. + Once identifying a misbehavior, 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 where no vehicle is trustable + and verifying every message (such as IPv6 control messages including + ND, DAD, NUD, and application-layer messages) is necessary. In this + way, vehicular networks can defend against many possible + cyberattacks. Thus, we need to have an efficient zero-trust + framework or mechanism for vehicular networks. + + For the non-repudiation of the harmful activities from malicious + vehicles, as it is difficult for other normal vehicles to identify + them, an additional and advanced approach is needed. One possible + approach is to use a blockchain-based approach [Bitcoin] 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 having fast-moving vehicles, either a new + consensus algorithm needs to be developed, or an existing consensus + algorithm needs to be enhanced. In addition, a consensus-based + mechanism for the security of vehicular networks in the IPv6 layer + can also be considered. A group of servers as blockchain + infrastructure can be part of the security checking process in the IP + layer. + + To prevent 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; that is, each vehicle + periodically updates its MAC address, and the vehicle's IPv6 address + needs to be updated accordingly by the MAC address change [RFC4086] + [RFC8981]. Such an 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. + However, if this pseudonym is performed without strong E2E + confidentiality (using either IPsec or TLS), there will be no privacy + benefit from changing MAC and IPv6 addresses because an adversary can + observe the change of the MAC and IPv6 addresses and track the + vehicle with those addresses. Thus, 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 may also include other in-vehicle + activities, such as transactions of credit cards. The assumed, + trusted actors are the owner of a vehicle, an authorized vehicle + service provider (e.g., navigation service provider), and an + authorized vehicle manufacturer for providing after-sales services. + In addition, privacy concerns for excessively collecting vehicle + activities from roadway operators, such as public transportation + administrators and private contractors, may also pose threats on + violating privacy rights of vehicles. It might be interesting to + find a solution from a technological point of view along with public + policy development for the issue. + + The "multicasting" of the location information of a VRU's smartphone + means IPv6 multicasting. There is a possible security attack related + to this multicasting. Attackers can use "fake identifiers" as source + IPv6 addresses of their devices to generate IPv6 packets and + multicast them to nearby vehicles in order to cause confusion that + those vehicles are surrounded by other vehicles or pedestrians. As a + result, navigation services (e.g., Google Maps [Google-Maps] and Waze + [Waze]) can be confused with fake road traffic by 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 this attack, 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 the road traffic conditions caused by those vehicles and + smartphones. In addition, to prevent hackers from tracking the + locations of those vehicles and smartphones, either a MAC address + pseudonym [MAC-ADD-RAN] or secure IPv6 address generation [RFC7721] + can be used to protect the privacy of those vehicles and smartphones. + +7. IANA Considerations + + 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>. + + [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>. + + [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 may consist of multiple radio technologies, such + as DSRC and 5G V2X (or LTE V2X). Although a Layer 2 solution can + provide support for multihop communications in vehicular networks, + the scalability issue related to multihop forwarding still remains + when vehicles need to disseminate or forward packets toward + destinations that are multiple hops away. In addition, the + IPv6-based approach for V2V as a network-layer protocol can + accommodate multiple radio technologies as MAC protocols, such as + DSRC and 5G V2X (or LTE V2X). Therefore, the existing IPv6 protocol + can be augmented through the addition of a virtual interface (e.g., + OMNI [OMNI] and DLEP [RFC8175]) and/or protocol changes in order to + support both wireless single-hop/multihop V2V communications and + multiple radio technologies in vehicular networks. In such a way, + vehicles can communicate with each other by V2V communications to + share either an emergency situation or road hazard information on a + highway having multiple radio technologies. + +Appendix B. Support of Multihop V2X Networking + + The multihop V2X networking can be supported by RPL (IPv6 Routing + Protocol for Low-Power and Lossy Networks) [RFC6550] and Overlay + Multilink Network Interface [OMNI] with AERO [AERO]. + + RPL defines an IPv6 routing protocol for Low-Power and Lossy Networks + (LLNs) as being 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 the multipoint-to-point traffic. 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, the 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 the 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, which does not need a global knowledge of the topology, and + only optimizes the routes to and from the root, allowing peer-to-peer + (P2P) paths to be stretched. Although RPL installs its routes + proactively, it only maintains them lazily, that is, in reaction to + actual traffic or as a slow background activity. Additionally, RPL + leverages the concept of an OF, which allows adapting 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 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 for the DV operation to operate hop-by-hop. While an + RPL topology can quickly scale up and down and fit the needs of + mobility of vehicles, the total performance of the system will also + depend 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 that 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 multihop V2V communication. The OMNI interface + supports an NBMA link model where multihop V2V and V2I communications + use each mobile node's ULAs without need for any DAD or MLD + messaging. + + In the OMNI protocol, an OMNI virtual interface can have a ULA + [RFC4193] indeed, but 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 for running both vehicular ND and a + VANET routing protocol, the AERO/OMNI approach may avoid this issue + 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 for + VANET-wide multicasting while providing agile accommodation for + dynamic topology changes. + +Appendix C. Support of Mobility Management for V2I + + The seamless application communication between two vehicles or + between a vehicle and an infrastructure node requires mobility + management in vehicular networks. The mobility management schemes + include a host-based mobility scheme, network-based mobility scheme, + and software-defined networking scheme. + + In the host-based mobility scheme (e.g., MIPv6), an IP-RSU plays the + role of a home agent. On the other hand, in the network-based + mobility scheme (e.g., PMIPv6), an MA plays the role of a mobility + management controller, such as a Local Mobility Anchor (LMA) in + PMIPv6, which also serves vehicles as a home agent, and an IP-RSU + plays the role of an access router, such as a Mobile Access Gateway + (MAG) in PMIPv6 [RFC5213]. The host-based mobility scheme needs + client functionality in the IPv6 stack of a vehicle as a mobile node + for mobility signaling message exchange between the vehicle and home + agent. On the other hand, the network-based mobility scheme does not + need such client functionality of a vehicle because the network + infrastructure node (e.g., MAG in PMIPv6) as a proxy mobility agent + handles the mobility signaling message exchange with the home agent + (e.g., LMA in PMIPv6) for the sake of the vehicle. + + There are a scalability issue and a route optimization issue in the + network-based mobility scheme (e.g., PMIPv6) when an MA covers a + large vehicular network governing many IP-RSUs. In this case, a + distributed mobility scheme (e.g., DMM [RFC7429]) can mitigate the + scalability issue by distributing multiple MAs in the vehicular + network such that they are positioned closer to vehicles for route + optimization and bottleneck mitigation in a central MA in the + network-based mobility scheme. All these mobility approaches (i.e., + a host-based mobility scheme, network-based mobility scheme, and + distributed mobility scheme) and a hybrid approach of a combination + of them need to provide an efficient mobility service to vehicles + moving fast and moving along with relatively predictable trajectories + along the roadways. + + In vehicular networks, the control plane can be separated from the + data plane for efficient mobility management and data forwarding by + using the concept of Software-Defined Networking (SDN) [RFC7149] + [FPC-DMM]. Note that Forwarding Policy Configuration (FPC) in + [FPC-DMM], which is a flexible mobility management system, can manage + the separation of data plane and control plane in DMM. In SDN, the + control plane and data plane are separated for the efficient + management of forwarding elements (e.g., switches and routers) where + an SDN controller configures the forwarding elements in a centralized + way, and they perform packet forwarding according to their forwarding + tables that are configured by the SDN controller. An MA 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 + + The wireless and/or wired-line links in paths between both mobile + nodes and fixed network correspondents may configure a variety of + Maximum Transmission Units (MTUs), where all IPv6 links are required + to support a minimum MTU of 1280 octets and may support larger MTUs. + Unfortunately, determining the path MTU (i.e., the minimum link MTU + in the path) has proven to be inefficient and unreliable due to the + uncertain nature of the loss-oriented ICMPv6 messaging service used + for path MTU discovery. Recent developments have produced a more + reliable path MTU determination service for TCP [RFC4821] and UDP + [RFC8899]; however, the MTUs discovered are always limited by the + most restrictive link MTU in the path (often 1500 octets or smaller). + + The AERO/OMNI service addresses the MTU issue by introducing a new + layer in the Internet architecture known as the "OMNI Adaptation + Layer (OAL)". The OAL allows end systems that configure an OMNI + interface to utilize a full 65535-octet MTU by leveraging the IPv6 + fragmentation and reassembly service during encapsulation to produce + fragment sizes that are assured of traversing the path without loss + due to a size restriction. Thus, this allows end systems to send + packets that are often much larger than the actual path MTU. + + Performance studies over the course of many decades have proven that + applications will see greater performance by sending smaller numbers + of large packets (as opposed to larger numbers of small packets) even + if fragmentation is needed. The OAL further supports even larger + packet sizes 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. On the other hand, due to the highly dynamic nature of + vehicular networks, a high packet loss may not be able to be avoided. + The high packet loss on IP Parcels can simultaneously cause multiple + TCP sessions to experience packet retransmissions, session time-out, + or re-establishment of the sessions. Other protocols, such as MPTCP + and QUIC, may also experience similar issues. 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, greatly + benefiting 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 + 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.com + + + Sandra Cespedes + NIC Chile Research Labs + Universidad de Chile + Av. Blanco Encalada 1975 + Santiago + Chile + Phone: +56 2 29784093 + Email: scespede@niclabs.cl + + + Jérôme Härri + Communication Systems Department + EURECOM + Sophia-Antipolis + France + Phone: +33 4 93 00 81 34 + Email: jerome.haerri@eurecom.fr + + + Dapeng Liu + Alibaba + Beijing + 100022 + China + Phone: +86 13911788933 + Email: max.ldp@alibaba-inc.com + + + Tae (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.edu + + + Charles E. Perkins + Futurewei Inc. + 2330 Central Expressway, + Santa Clara, CA 95050 + United States of America + Phone: +1 408 330 4586, + Email: charliep@computer.org + + + Alexandre Petrescu + CEA, LIST, CEA Saclay + 91190 Gif-sur-Yvette + France + Phone: +33169089223 + Email: Alexandre.Petrescu@cea.fr + + + Yiwen 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.io + + + Michelle Wetterwald + FBConsulting + 21, Route de Luxembourg, + L-L-6633, Wasserbillig, + Luxembourg + Email: Michelle.Wetterwald@gmail.com + + +Author'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 |