--- 1/draft-ietf-ipwave-vehicular-networking-22.txt 2021-09-02 21:13:10.721748795 -0700 +++ 2/draft-ietf-ipwave-vehicular-networking-23.txt 2021-09-02 21:13:10.821751309 -0700 @@ -1,19 +1,19 @@ IPWAVE Working Group J. Jeong, Ed. Internet-Draft Sungkyunkwan University Intended status: Informational 2 September 2021 Expires: 6 March 2022 IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases - draft-ietf-ipwave-vehicular-networking-22 + draft-ietf-ipwave-vehicular-networking-23 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 @@ -63,22 +63,22 @@ 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 12 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 14 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 15 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 18 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 22 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 23 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 25 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 27 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 27 - 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 28 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 + 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 29 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 6.1. Security Threats in Neighbor Discovery . . . . . . . . . 32 6.2. Security Threats in Mobility Management . . . . . . . . . 33 6.3. Other Threats . . . . . . . . . . . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.1. Normative References . . . . . . . . . . . . . . . . . . 35 8.2. Informative References . . . . . . . . . . . . . . . . . 39 Appendix A. Support of Multiple Radio Technologies for V2V . . . 44 Appendix B. Support of Multihop V2X Networking . . . . . . . . . 45 Appendix C. Support of Mobility Management for V2I . . . . . . . 46 @@ -1171,41 +1171,48 @@ control traffic overhead [ID-Multicast-Problems]. 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 the IPv6 ND is used to check the neighborhood of each vehicle. Thus, the vehicular routing needs to take advantage of the IPv6 ND to minimize its control overhead. RPL [RFC6550] defines a routing protocol for low-power and lossy - networks, which constructs and maintains DODAGs optimized by an - Objective Function (OF). A defined OF provides route selection and - optimization within an RPL topology. A node in a DODAG uses DODAG - Information Objects (DIOs) messages to discover and maintain the - upward routes toward the root node. Refer to Appendix B for the - detailed description of RPL for multihop V2X networking. + networks, 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. A node in a DODAG discovers and maintains the + upward routes toward the root node of the DODAG. RPL uses a Distance + Vector (DV) approach, with lazy maintenance and stretched anisotropic + routing. 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. Mainly it - updates the Address Registration Option (ARO) of ND defined in - [RFC6775] to include a status field that can indicate the movement of - a node and optionally a Transaction ID (TID) field, i.e., a sequence - number that can be used to determine the most recent location of a - node. - - RPL can use the information provided by the extended ARO 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 to the previous parent node and register - itself with a new parent node along with an incremented TID. + mobility for nodes moving through different parents. [RFC8505], as + opposed to [RFC4861], is stateful and proactively installs the ND + cache entries, which saves broadcasts and provides a deterministic + presence information for IPv6 addresses. Mainly it updates the + Address Registration Option (ARO) of ND defined in [RFC6775] to + include a status field that can indicate the movement of a node and + optionally a Transaction ID (TID) field, i.e., 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 to 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 lossy networks, which puts energy efficiency first. For using it in IPv6-based vehicular networks, there have not been actual experiences and practical implementations for vehicular networks, though it was tested in IoT low-power and lossy networks (LLN) scenarios. Moreover, due to bandwidth and energy constraints, RPL does not suggest to use a proactive mechanism (e.g., keepalive) to maintain @@ -1964,21 +1971,21 @@ 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) [OMNI]. RPL defines an IPv6 routing protocol for low-power and lossy networks (LLN), 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 + 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 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 @@ -1987,21 +1994,21 @@ 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 + 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 objective function (called OF), which allows to adapt the activity of the routing protocol to use cases, e.g., type, speed, and quality of the radios. RPL does not need converge, and provides connectivity to most nodes most of the time. The default route toward the root is maintained aggressively and may