--- 1/draft-ietf-ipwave-vehicular-networking-16.txt 2020-07-28 19:13:36.930885503 -0700 +++ 2/draft-ietf-ipwave-vehicular-networking-17.txt 2020-07-28 19:13:37.014887650 -0700 @@ -1,19 +1,19 @@ IPWAVE Working Group J. Jeong, Ed. Internet-Draft Sungkyunkwan University -Intended status: Informational July 7, 2020 -Expires: January 8, 2021 +Intended status: Informational July 28, 2020 +Expires: January 29, 2021 IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases - draft-ietf-ipwave-vehicular-networking-16 + draft-ietf-ipwave-vehicular-networking-17 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 @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 8, 2021. + This Internet-Draft will expire on January 29, 2021. Copyright Notice Copyright (c) 2020 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 @@ -55,37 +55,35 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 11 - 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 12 - 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 16 + 4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 12 + 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 13 + 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 17 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 19 - 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 20 - 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 21 - 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 22 - 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 24 - 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 25 - 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 25 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 - 7. Informative References . . . . . . . . . . . . . . . . . . . 29 - Appendix A. Changes from draft-ietf-ipwave-vehicular- - networking-15 . . . . . . . . . . . . . . . . . . . 36 - Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 36 - Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 36 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 + 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 21 + 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 22 + 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 23 + 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 25 + 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 26 + 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 26 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 7. Informative References . . . . . . . . . . . . . . . . . . . 30 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 38 + Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 38 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40 1. Introduction Vehicular networking studies have mainly focused on improving safety and efficiency, and also enabling entertainment in vehicular networks. 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). DSRC- based wireless communications can support vehicle-to-vehicle (V2V), @@ -308,21 +306,21 @@ o Context-aware navigation for safe driving and collision avoidance; o Cooperative adaptive cruise control in a roadway; o Platooning in a highway; o Cooperative environment sensing; o Collision avoidance service of end systems of Urban Air Mobility - (UAM). + (UAM) [UAM-ITS]. These five techniques will be important elements for autonomous vehicles, which may be either terrestrial vehicles or UAM end systems. Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers to drive safely 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 @@ -384,26 +382,28 @@ To encourage more vehicles to participate in this cooperative environmental sensing, a reward system will be needed. Sensing activities of each vehicle need to be logged in either a central way through a logging server (e.g., TCC) in the vehicular cloud or a distributed way (e.g., blockchain [Bitcoin]) through other vehicles or infrastructure. In the case of a blockchain, each sensing message from a vehicle can be treated as a transaction and the neighboring vehicles can play the role of peers in a consensus method of a blockchain [Bitcoin][Vehicular-BlockChain]. - The existing IPv6 protocol does not support wireless single-hop V2V - communications as well as wireless multihop V2V communications. - Thus, the IPv6 needs to support both single-hop and multihop - communications in a wireless medium so that vehicles can communicate - with each other by V2V communications to share either an emergency - situation or road hazard in a highway. + The existing IPv6 protocol must be augmented through the addition of + an Overlay Multilink Network (OMNI) Interface [OMNI] and/or protocol + changes in order to support wireless single-hop V2V communications as + well as wireless multihop V2V communications. Thus, the IPv6 needs + to support both single-hop and multihop communications in a wireless + medium so that vehicles can communicate with each other by V2V + communications to share either an emergency situation or road hazard + in a highway. To support applications of these V2V use cases, the functions of IPv6 such as VND and VSP are prerequisites for IPv6-based packet exchange and secure, safe communication between two vehicles. 3.2. V2I The use cases of V2I networking discussed in this section include o Navigation service; @@ -463,25 +463,26 @@ battery charging schedule of UAM end systems (e.g., drone) for long- distance flying [CBDN]. For this battery charging schedule, a UAM end system can communicate with an infrastructure node (e.g., IP-RSU) toward a cloud server via V2I communications. 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. - The existing IPv6 protocol does not support wireless multihop V2I - communications in a highway where RSUs are sparsely deployed, so a - vehicle can reach the wireless coverage of an RSU through the - multihop data forwarding of intermediate vehicles. Thus, IPv6 needs - to be extended for multihop V2I communications. + The existing IPv6 protocol must be augmented through the addition of + an OMNI interface and/or protocol changes in order to support + wireless multihop V2I communications in a highway where RSUs are + sparsely deployed, so a vehicle can reach the wireless coverage of an + RSU through the multihop data forwarding of intermediate vehicles. + Thus, IPv6 needs to be extended for multihop V2I communications. To support applications of these V2I use cases, the functions of IPv6 such as VND, VMM, and VSP are prerequisites for IPv6-based packet exchange, transport-layer session continuity, and secure, safe communication between a vehicle and a server in the vehicular cloud. 3.3. V2X The use case of V2X networking discussed in this section is for a pedestrian protection service. @@ -496,27 +497,28 @@ pedestrians, 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 the communication with vehicles, considering their mobility. 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. - The existing IPv6 protocol does not support wireless multihop V2X (or - V2I2X) communications in an urban road network where RSUs are - deployed at intersections, so a vehicle (or a pedestrian's - smartphone) can reach the wireless coverage of an RSU through the - multihop data forwarding of intermediate vehicles (or pedestrians' - smartphones). Thus, IPv6 needs to be extended for multihop V2X (or - V2I2X) communications. + The existing IPv6 protocol must be augmented through the addition of + an OMNI interface and/or protocol changes in order to support + wireless multihop V2X (or V2I2X) communications in an urban road + network where RSUs are deployed at intersections, so a vehicle (or a + pedestrian's smartphone) can reach the wireless coverage of an RSU + through the multihop data forwarding of intermediate vehicles (or + pedestrians' smartphones). Thus, IPv6 needs to be extended for + multihop V2X (or V2I2X) communications. To support applications of these V2X use cases, the functions of IPv6 such as VND, VMM, and VSP are prerequisites for IPv6-based packet exchange, transport-layer session continuity, and secure, safe communication between a vehicle and a pedestrian either directly or indirectly via an IP-RSU. 4. Vehicular Networks This section describes an example vehicular network architecture @@ -562,27 +564,26 @@ 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 [OMNI-Interface]. The vehicular network - architecture contains vehicles (including IP-OBU), IP-RSUs, Mobility - Anchor, Traffic Control Center, and Vehicular Cloud as components. - - Note that the components of the vehicular network architecture can be - mapped to those of an IP-based aeronautical network architecture in - [OMNI-Interface], as shown in Figure 2. + V2V in a road network [OMNI]. The vehicular network architecture + contains vehicles (including IP-OBU), IP-RSUs, Mobility Anchor, + Traffic Control Center, and Vehicular Cloud as components. Note that + the components of the vehicular network architecture can be mapped to + those of an IP-based aeronautical network architecture in [OMNI], as + shown in Figure 2. +-------------------+------------------------------------+ | Vehicular Network | Aeronautical Network | +===================+====================================+ | IP-RSU | Access Router (AR) | +-------------------+------------------------------------+ | Vehicle (IP-OBU) | Mobile Node (MN) | +-------------------+------------------------------------+ | Moving Network | End User Network (EUN) | +-------------------+------------------------------------+ @@ -594,50 +595,51 @@ Figure 2: Mapping between Vehicular Network Components and Aeronautical Network 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. An existing network architecture (e.g., an IP-based aeronautical - network architecture [OMNI-Interface][UAM-ITS], a network - architecture of PMIPv6 [RFC5213], and a low-power and lossy network - architecture [RFC6550]) can be extended to a vehicular network - architecture for multihop V2V, V2I, and V2X, as shown in Figure 1. - In a highway scenario, a vehicle may not access an RSU directly - because of the distance of the DSRC coverage (up to 1 km). For - example, RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) - [RFC6550] can be extended to support a multihop V2I since a vehicle - can take advantage of other vehicles as relay nodes to reach the RSU. - Also, RPL can be extended to support both multihop V2V and V2X in the - similar way. + network architecture [OMNI][UAM-ITS], a network architecture of + PMIPv6 [RFC5213], and a low-power and lossy network architecture + [RFC6550]) can be extended to a vehicular network architecture for + multihop V2V, V2I, and V2X, as shown in Figure 1. In a highway + scenario, a vehicle may not access an RSU directly because of the + distance of the DSRC coverage (up to 1 km). For example, the OMNI + interface and/or RPL (IPv6 Routing Protocol for Low-Power and Lossy + Networks) [RFC6550] can be extended to support a multihop V2I since a + vehicle can take advantage of other vehicles as relay nodes to reach + the RSU. Also, RPL can be extended to support both multihop V2V and + V2X in the similar way. Wireless communications needs to be considered for end systems for Urban Air Mobility (UAM) such as flying cars and taxis [UAM-ITS]. + These UAM end systems may have multiple wireless transmission media interfaces (e.g., cellular, communications satellite (SATCOM), short- range omni-directional interfaces), which are offered by different data link service providers. To support not only the mobility management of the UAM end systems, but also the multihop and multilink communications of the UAM interfaces, the UAM end systems - can employ an Overlay Multilink Network (OMNI) interface - [OMNI-Interface] as a virtual Non-Broadcast Multiple Access (NBMA) - connection to a serving ground domain infrastructure. This - infrastructure can be configured over the underlying data links. The - OMNI interface and its link model provide a means of multilink, - multihop and mobility coordination to the legacy IPv6 ND messaging - [RFC4861] according to the NBMA principle. Thus, the OMNI link model - can support efficient UAM internetworking services without additional - mobility messaging, and without any modification to the IPv6 ND - messaging services or link model. + can employ an Overlay Multilink Network (OMNI) interface [OMNI] as a + virtual Non-Broadcast Multiple Access (NBMA) connection to a serving + ground domain infrastructure. This infrastructure can be configured + over the underlying data links. The OMNI interface and its link + model provide a means of multilink, multihop and mobility + coordination to the legacy IPv6 ND messaging [RFC4861] according to + the NBMA principle. Thus, the OMNI link model can support efficient + UAM internetworking services without additional mobility messaging, + and without any modification to the IPv6 ND messaging services or + link model. As shown in this figure, IP-RSUs as routers and vehicles with IP-OBU have wireless media interfaces for VANET. Furthermore, the wireless media interfaces are autoconfigured with a global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to support both V2V and V2I networking. Note that 2001:DB8::/32 is a documentation prefix [RFC3849] for example prefixes in this document, and also that any routable IPv6 address needs to be routable in a VANET and a vehicular network including IP- RSUs. @@ -652,29 +654,37 @@ 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 RSU share a prefix such that 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 Prefix 1 to configure their - IPv6 global addresses for V2I communication. + IPv6 global addresses for V2I communication. Alternatively, mobile + nodes can employ an OMNI interface and use their own IPv6 Unique + Local Addresses (ULAs) [RFC4193] over the wireless network without + requiring the messaging of IPv6 Stateless Address Autoconfiguration + (SLAAC) [RFC4862], which uses an on-link prefix provided by the + (visited) wireless LAN; this technique is known as "Bring-Your-Own- + Addresses". A single subnet prefix announced by an RSU can span multiple vehicles in VANET. For example, in Figure 1, for Prefix 1, three vehicles (i.e., Vehicle1, Vehicle2, and Vehicle5) can construct a connected VANET. Also, for Prefix 2, two vehicles (i.e., Vehicle3 and Vehicle6) can construct another connected VANET, and for Prefix 3, two vehicles (i.e., Vehicle4 and Vehicle7) can construct another - connected VANET. + connected VANET. Alternatively, each vehicle could employ an OMNI + interface with their own ULAs such that no topologically-oriented + subnet prefixes need be announced by the RSU. 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 @@ -693,21 +703,22 @@ 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 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 corresponding 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]). + network-based mobility management scheme (e.g., PMIPv6 [RFC5213] and + AERO [RFC6706BIS]). In the host-based mobility scheme (e.g., MIPv6), an IP-RSU plays a role of a home agent. On the other hand, in the network-based mobility scheme (e.g., PMIPv6, an MA plays a 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 a role of an access router such as a Mobile Access Gateway (MAG) in PMIPv6 [RFC5213]. The host-based mobility scheme needs client functionality in IPv6 stack of a vehicle as a mobile node for mobility signaling message exchange between the vehicle and home @@ -774,21 +785,21 @@ 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 the interaction between the internal network and an external network within another vehicle or an EN. +-----------------+ (*)<........>(*) +----->| Vehicular Cloud | - 2001:DB8:1:1::/64 | | | +-----------------+ + (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 | @@ -812,21 +823,21 @@ As shown in Figure 3, as internal networks, a vehicle's moving 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 the 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 moving network) in a vehicle need to be delegated and configured automatically. Note that a moving network's network prefix can be called a Mobile Network Prefix - (MNP) [OMNI-Interface]. + (MNP) [OMNI]. Figure 3 also shows the internetworking between the vehicle's moving network and the EN's fixed network. There exists an internal network (Moving 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 @@ -844,37 +855,38 @@ 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 moving network and the EN's fixed network. Thus, V2I requires an efficient protocol for the mutual knowledge of network parameters. - As shown in Figure 3, global IPv6 addresses are used for the wireless - link interfaces for IP-OBU and IP-RSU, but IPv6 Unique Local - Addresses (ULAs) [RFC4193] can also be used for those wireless link - interfaces as long as IPv6 packets can be routed to them in the - vehicular networks [OMNI-Interface]. For the guarantee of the - uniqueness of an IPv6 address, the configuration and control overhead - of the DAD of the wireless link interfaces should be minimized to - support the V2I and V2X communications of vehicles moving fast along - roadways. + As shown in Figure 3, the addresses used for IPv6 transmissions over + the wireless link interfaces for IP-OBU and IP-RSU can be either + global IPv6 addresses, or IPv6 ULAs as long as IPv6 packets can be + routed within vehicular networks [OMNI]. When global 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; when + ULAs and the OMNI interface are used, no DAD nor MLD messaging is + needed. 4.3. V2V-based Internetworking This section discusses the internetworking between the moving networks of two neighboring vehicles via V2V communication. (*)<..........>(*) - 2001:DB8:1:1::/64 | | + (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 | @@ -896,24 +908,25 @@ Figure 4: Internetworking between Two Vehicles Figure 4 shows the internetworking between the moving networks of two neighboring vehicles. There exists an internal network (Moving Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and Host2), and two routers (IP-OBU1 and Router1). There exists another internal network (Moving 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 moving network, a wireless link between IP-OBU1 and IP- - OBU2, and Vehicle2's moving network. + V2V networking. Alternatively, Vehicle1 and Vehicle2 employ an OMNI + interface and use IPv6 ULAs for V2V networking. Thus, a host (Host1) + in Vehicle1 can communicate with another host (Host3) in Vehicle2 for + a vehicular service through Vehicle1's moving network, a wireless + link between IP-OBU1 and IP-OBU2, and Vehicle2's moving network. As a V2V use case in Section 3.1, Figure 5 shows the linear network topology of platooning vehicles for V2V communications where Vehicle3 is the leading vehicle with a driver, and Vehicle2 and Vehicle1 are the following vehicles without drivers. (*)<..................>(*)<..................>(*) | | | +-----------+ +-----------+ +-----------+ | | | | | | @@ -966,25 +979,26 @@ 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. This section presents key topics such as neighbor discovery and mobility management. 5.1. Neighbor Discovery IPv6 ND [RFC4861][RFC4862] is a core part of the IPv6 protocol suite. - IPv6 ND is designed for point-to-point links and transit links (e.g., - Ethernet). 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), Duplicate Address - Detection (DAD), and Neighbor Unreachability Detection (NUD). + 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). 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 to be configured with a link-local IPv6 address or a global IPv6 address, and 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 the DAD packets during a vehicle's travel in a road network, which guaranteeing the uniqueness of a vehicle's global IPv6 @@ -1041,32 +1055,35 @@ Internet, including the DAD and NUD operations. 5.1.1. Link Model A prefix model for a vehicular network needs to facilitate the 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 prefix 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. Note that the OMNI link model - supports these multihop V2V and V2I through an OMNI multilink service - [OMNI-Interface]. + multihop V2I with VANETs and IP-RSUs. Note that 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. - IPv6 protocols work under certain assumptions for the link model that - do not necessarily hold in a vehicular wireless link - [VIP-WAVE][RFC5889]. For instance, some IPv6 protocols assume - symmetry in the connectivity among neighboring interfaces [RFC6250]. - However, radio interference and different levels of transmission - power may cause asymmetric links to appear in vehicular wireless - links. As a result, a new vehicular link model needs to consider the - asymmetry of dynamically changing vehicular wireless links. + IPv6 protocols work under certain assumptions that do not necessarily + hold for vehicular wireless access link types other than OMNI/NBMA + [VIP-WAVE][RFC5889]; the rest of this section discusses implications + for those link types that do not apply when the OMNI/NBMA link model + is used. For instance, some IPv6 protocols assume symmetry in the + connectivity among neighboring interfaces [RFC6250]. However, radio + interference and different levels of transmission power may cause + asymmetric links to appear in vehicular wireless links. 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 and global types of IPv6 addresses. In an IPv6 link, it is assumed that all interfaces which are configured with the same subnet prefix and with 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. @@ -1114,23 +1131,24 @@ to communicate with each other directly via VANET rather than indirectly via IP-RSUs. On the other hand, when Vehicle1 and Vehicle3 are far away from direct communication range in separate VANETs and under two different IP-RSUs, they can communicate with each other through the relay of IP-RSUs via V2I2V. Thus, two separate VANETs can merge into one network via IP-RSU(s). Also, newly arriving vehicles can merge 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 the interoperability with the legacy - IPv6 link model in an efficient fashion to support the IPv6 DAD and - NUD operations. + should have minimum changes for interoperability with standard IPv6 + links in an efficient fashion to support IPv6 DAD, MLD and NUD + operations. When the OMNI NBMA link model is used, there are no link + model changes nor DAD/MLD messaging required. 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]. @@ -1149,21 +1167,21 @@ checked through the DAD procedure. For vehicular networks with high mobility and density, this DAD needs to be performed efficiently with minimum overhead so that the vehicles can exchange application messages (e.g., collision avoidance and accident notification) with each other with a short interval (e.g., 0.5 second) [NHTSA-ACAS-Report]. 5.1.3. Routing For multihop V2V communications in either a VANET or VANETs via IP- - RSUs, a vehicular ad hoc routing protocol (e.g., AODV or OLSRv2) may + 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 [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 @@ -1207,26 +1225,25 @@ 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 shared link, where the wireless subnets of multiple IP-RSUs share the same prefix, an efficient vehicular-network-wide DAD is required. If DHCPv6 is used to assign a unique IPv6 address to each vehicle in this shared link, the DAD is not required. On the other hand, for a mobility management scheme with a unique prefix per mobile node (e.g., PMIPv6 [RFC5213] and OMNI - [OMNI-Interface]), DAD is not required because the IPv6 address of a - vehicle's external wireless interface is guaranteed to be unique. - There is a tradeoff between the prefix usage efficiency and DAD - overhead. Thus, the IPv6 address autoconfiguration for vehicular - networks needs to consider this tradeoff to support efficient - mobility management. + [OMNI]), DAD is not required because the IPv6 address of a vehicle's + external wireless interface is guaranteed to be unique. There is a + tradeoff between the prefix usage efficiency and DAD overhead. Thus, + the IPv6 address autoconfiguration for vehicular networks needs to + consider this tradeoff to support efficient mobility management. 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 @@ -1456,33 +1473,39 @@ ISO/TC 204, "Intelligent Transport Systems - Communications Access for Land Mobiles (CALM) - IPv6 Networking - Amendment 1", ISO 21210:2012/AMD 1:2017, September 2017. [NHTSA-ACAS-Report] National Highway Traffic Safety Administration (NHTSA), "Final Report of Automotive Collision Avoidance Systems (ACAS) Program", DOT HS 809 080, August 2000. - [OMNI-Interface] - Templin, F. and A. Whyman, "Transmission of IPv6 Packets + [OMNI] Templin, F. and A. Whyman, "Transmission of IPv6 Packets over Overlay Multilink Network (OMNI) Interfaces", draft- templin-6man-omni-interface-24 (work in progress), June 2020. + [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, October + 1999. + [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. + [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery + Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. + [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004. [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", RFC 4086, June 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. @@ -1661,56 +1684,38 @@ [WAVE-1609.3] IEEE 1609 Working Group, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Networking Services", IEEE Std 1609.3-2016, April 2016. [WAVE-1609.4] IEEE 1609 Working Group, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Multi-Channel Operation", IEEE Std 1609.4-2016, March 2016. -Appendix A. Changes from draft-ietf-ipwave-vehicular-networking-15 - - The following changes are made from draft-ietf-ipwave-vehicular- - networking-15: - - o This version is revised based on the further comments from the - following reviewers: Fred L. Templin (The Boeing Company) and - YongJoon Joe (LSware). - - o According to the comments from Fred L. Templin, in Section 3.1 - and Section 3.2, UAM (Urban Air Mobility) end systems are - considered for new V2V and V2I use cases. - - o According to the comments from YongJoon Joe, in Section 3.1 and - Section 6, the text about a consensus method of a blockchain in - vehicular networks is revised such that a consensus algorithm - needs to be efficient for fast moving vehicles. - -Appendix B. Acknowledgments +Appendix A. Acknowledgments This work was supported by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant 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 (Ministry of Science and ICT), Korea, under the ITRC (Information Technology Research Center) support program (IITP-2019-2017-0-01633) supervised by the IITP (Institute for Information & communications Technology Promotion). 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). -Appendix C. Contributors +Appendix B. Contributors This document is a group work of 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, Dirk von Hugo (Deutsche Telekom), Pascal Thubert (Cisco), Carlos Bernardos (UC3M), Russ Housley (Vigil Security), Suresh Krishnan (Kaloom), Nancy Cam-Winget (Cisco), Fred L. Templin (The Boeing Company), Jung-Soo Park (ETRI),