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.
IPv6 ND [RFC 4861
] [RFC 4862
] 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) [RFC 4861
] [RFC 4862
] [RFC 2710
] [RFC 3810
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) [RFC 4862
]. 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. [RFC 9119
] 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.
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
] [RFC 5889
]. For instance, some IPv6 protocols, such as NUD [RFC 4861
] and MIPv6 [RFC 6275
], 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 [RFC 6250
]. 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.
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.
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 [RFC 9119
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 [RFC 6550
] 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 [RFC 8505
] can support light-weight mobility for nodes moving through different parents. The extension described in [RFC 8505
] 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 [RFC 6775
] 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 [RFC 8505
] 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 [RFC 5881
] and MANET Neighborhood Discovery Protocol [RFC 6130
]. 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.
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 [RFC 5213
]), 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 [RFC 8505
] 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 [RFC 4888
] over the VANET.
For the case of a multihomed network, a vehicle can follow the first-hop router selection rule described in [RFC 8028
]. 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 [RFC 8028
]. 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 [RFC 6275
], PMIPv6 [RFC 5213
], and NEMO [RFC 3963
], 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.