idnits 2.17.1 draft-ietf-ipwave-vehicular-networking-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 4, 2018) is 2000 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Online' is mentioned on line 1216, but not defined == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-iot-dns-autoconf-04 == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-vehicular-neighbor-discovery-04 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPWAVE Working Group J. Jeong, Ed. 3 Internet-Draft Sungkyunkwan University 4 Intended status: Informational November 4, 2018 5 Expires: May 8, 2019 7 IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement 8 and Use Cases 9 draft-ietf-ipwave-vehicular-networking-07 11 Abstract 13 This document discusses the problem statement and use cases on IP- 14 based vehicular networks, which are considered a key component of 15 Intelligent Transportation Systems (ITS). The main scenarios of 16 vehicular communications are vehicle-to-vehicle (V2V), vehicle-to- 17 infrastructure (V2I), and vehicle-to-everything (V2X) communications. 18 First, this document surveys use cases using V2V, V2I, and V2X 19 networking. Second, it analyzes proposed protocols for IP-based 20 vehicular networking and highlights the limitations and difficulties 21 found on those protocols. Third, it presents a problem exploration 22 for key aspects in IP-based vehicular networking, such as IPv6 23 Neighbor Discovery, Mobility Management, and Security & Privacy. For 24 each key aspect, this document discusses a problem statement to 25 evaluate the gap between the state-of-the-art techniques and 26 requirements in IP-based vehicular networking. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 8, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4. Analysis for Existing Protocols . . . . . . . . . . . . . . . 8 69 4.1. Existing Protocols for Vehicular Networking . . . . . . . 8 70 4.1.1. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . 8 71 4.1.2. IP Address Autoconfiguration . . . . . . . . . . . . 8 72 4.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1.4. Mobility Management . . . . . . . . . . . . . . . . . 9 74 4.1.5. DNS Naming Service . . . . . . . . . . . . . . . . . 9 75 4.1.6. Service Discovery . . . . . . . . . . . . . . . . . . 9 76 4.1.7. Security and Privacy . . . . . . . . . . . . . . . . 10 77 4.2. General Problems . . . . . . . . . . . . . . . . . . . . 10 78 4.2.1. Vehicular Network Architecture . . . . . . . . . . . 11 79 4.2.2. Latency . . . . . . . . . . . . . . . . . . . . . . . 16 80 4.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 16 81 4.2.4. Pseudonym Handling . . . . . . . . . . . . . . . . . 16 82 5. Problem Exploration . . . . . . . . . . . . . . . . . . . . . 17 83 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 17 84 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 17 85 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 18 86 5.1.3. Prefix Dissemination/Exchange . . . . . . . . . . . . 18 87 5.1.4. Routing . . . . . . . . . . . . . . . . . . . . . . . 18 88 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 19 89 5.3. Security and Privacy . . . . . . . . . . . . . . . . . . 20 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 91 7. Informative References . . . . . . . . . . . . . . . . . . . 21 92 Appendix A. Relevant Topics to IPWAVE Working Group . . . . . . 29 93 A.1. Vehicle Identity Management . . . . . . . . . . . . . . . 29 94 A.2. Multihop V2X . . . . . . . . . . . . . . . . . . . . . . 29 95 A.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 29 96 A.4. DNS Naming Services and Service Discovery . . . . . . . . 30 97 A.5. IPv6 over Cellular Networks . . . . . . . . . . . . . . . 30 98 A.5.1. Cellular V2X (C-V2X) Using 4G-LTE . . . . . . . . . . 30 99 A.5.2. Cellular V2X (C-V2X) Using 5G . . . . . . . . . . . . 31 100 Appendix B. Changes from draft-ietf-ipwave-vehicular- 101 networking-06 . . . . . . . . . . . . . . . . . . . 31 102 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 31 103 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 32 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 106 1. Introduction 108 Vehicular networking studies have mainly focused on driving safety, 109 driving efficiency, and entertainment in road networks. The Federal 110 Communications Commission (FCC) in the US allocated wireless channels 111 for Dedicated Short-Range Communications (DSRC) [DSRC], service in 112 the Intelligent Transportation Systems (ITS) Radio Service in the 113 5.850 - 5.925 GHz band (5.9 GHz band). DSRC-based wireless 114 communications can support vehicle-to-vehicle (V2V), vehicle-to- 115 infrastructure (V2I), and vehicle-to-everything (V2X) networking. 116 Also, the European Union (EU) passed a decision to allocate radio 117 spectrum for safety-related and non-safety-related applications of 118 ITS with the frequency band of 5.875 - 5.905 GHz, which is called 119 Commission Decision 2008/671/EC [EU-2008-671-EC]. 121 For direct inter-vehicular wireless connectivity, IEEE has amended 122 WiFi standard 802.11 to enable driving safety services based on the 123 DSRC in terms of standards for the Wireless Access in Vehicular 124 Environments (WAVE) system. L1 and L2 issues are addressed in IEEE 125 802.11p [IEEE-802.11p] for the PHY and MAC of the DSRC, while IEEE 126 1609.2 [WAVE-1609.2] covers security aspects, IEEE 1609.3 127 [WAVE-1609.3] defines related services at network and transport 128 layers, and IEEE 1609.4 [WAVE-1609.4] specifies the multi-channel 129 operation. Note that IEEE 802.11p has been published as IEEE 802.11 130 Outside the Context of a Basic Service Set (OCB) called IEEE 131 802.11-OCB [IEEE-802.11-OCB] in 2012. 133 Along with these WAVE standards, IPv6 [RFC8200] and Mobile IP 134 protocols (e.g., MIPv4 [RFC5944] and MIPv6 [RFC6275]) can be applied 135 (or easily modified) to vehicular networks. In Europe, ETSI has 136 standardized a GeoNetworking (GN) protocol [ETSI-GeoNetworking] and a 137 protocol adaptation sub-layer from GeoNetworking to IPv6 138 [ETSI-GeoNetwork-IP]. Note that a GN protocol is useful to route an 139 event or notification message to vehicles around a geographic 140 position, such as an acciendent area in a roadway. In addition, ISO 141 has approved a standard specifying the IPv6 network protocols and 142 services to be used for Communications Access for Land Mobiles (CALM) 143 [ISO-ITS-IPv6]. 145 This document discusses problem statements and use cases related to 146 IP-based vehicular networking for Intelligent Transportation Systems 147 (ITS), which is denoted as IP Wireless Access in Vehicular 148 Environments (IPWAVE). First, it surveys the use cases for using 149 V2V, V2I, and V2X networking in the ITS. Second, for literature 150 review, it analyzes proposed protocols for IP-based vehicular 151 networking and highlights the limitations and difficulties found on 152 those protocols. Third, for problem statement, it presents a problem 153 exploration with key aspects in IPWAVE, such as IPv6 Neighbor 154 Discovery, Mobility Management, and Security & Privacy. For each key 155 aspect of the problem statement, it analyzes the gap between the 156 state-of-the-art techniques and the requirements in IP-based 157 vehicular networking. It also discusses potential topics relevant to 158 IPWAVE Working Group (WG), such as Vehicle Identities Management, 159 Multihop V2X Communications, Multicast, DNS Naming Services, Service 160 Discovery, and IPv6 over Cellular Networks. Therefore, with the 161 problem statement, this document will open a door to develop key 162 protocols for IPWAVE that will be essential to IP-based vehicular 163 networks. 165 2. Terminology 167 This document uses the following definitions: 169 o WAVE: Acronym for "Wireless Access in Vehicular Environments" 170 [WAVE-1609.0]. 172 o DMM: Acronym for "Distributed Mobility Management" 173 [RFC7333][RFC7429]. 175 o Road-Side Unit (RSU): A node that has physical communication 176 devices (e.g., DSRC, Visible Light Communication, 802.15.4, LTE- 177 V2X, etc.) for wireless communications with vehicles and is also 178 connected to the Internet as a router or switch for packet 179 forwarding. An RSU is typically deployed on the road 180 infrastructure, either at an intersection or in a road segment, 181 but may also be located in car parking area. 183 o On-Board Unit (OBU): A node that has a DSRC device for wireless 184 communications with other OBUs and RSUs, and may be connected to 185 in-vehicle devices or networks. An OBU is mounted on a vehicle. 186 It is assumed that a radio navigation receiver (e.g., Global 187 Positioning System (GPS)) is included in a vehicle with an OBU for 188 efficient navigation. 190 o Vehicle Detection Loop (or Loop Detector): An inductive device 191 used for detecting vehicles passing or arriving at a certain 192 point, for instance approaching a traffic light or in motorway 193 traffic. The relatively crude nature of the loop's structure 194 means that only metal masses above a certain size are capable of 195 triggering the detection. 197 o Mobility Anchor (MA): A node that maintains IP addresses and 198 mobility information of vehicles in a road network to support the 199 address autoconfiguration and mobility management of them. It has 200 end-to-end connections with RSUs under its control. It maintains 201 a DAD table having the IP addresses of the vehicles moving within 202 the communication coverage of its RSUs. 204 o Vehicular Cloud: A cloud infrastructure for vehicular networks, 205 having compute nodes, storage nodes, and network nodes. 207 o Traffic Control Center (TCC): A node that maintains road 208 infrastructure information (e.g., RSUs, traffic signals, and loop 209 detectors), vehicular traffic statistics (e.g., average vehicle 210 speed and vehicle inter-arrival time per road segment), and 211 vehicle information (e.g., a vehicle's identifier, position, 212 direction, speed, and trajectory as a navigation path). TCC is 213 included in a vehicular cloud for vehicular networks. 215 3. Use Cases 217 This section provides use cases of V2V, V2I, and V2X networking. The 218 use cases of the V2X networking exclude the ones of the V2V and V2I 219 networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to- 220 Device (V2D). 222 3.1. V2V 224 The use cases of V2V networking discussed in this section include 226 o Context-aware navigation for driving safety and collision 227 avoidance; 229 o Cooperative adaptive cruise control in an urban roadway; 231 o Platooning in a highway; 233 o Cooperative environment sensing. 235 These four techniques will be important elements for self-driving 236 vehicles. 238 Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers 239 to drive safely by letting the drivers recognize dangerous obstacles 240 and situations. That is, CASD navigator displays obstables or 241 neighboring vehicles relevant to possible collisions in real-time 242 through V2V networking. CASD provides vehicles with a class-based 243 automatic safety action plan, which considers three situations, such 244 as the Line-of-Sight unsafe, Non-Line-of-Sight unsafe and safe 245 situations. This action plan can be performed among vehicles through 246 V2V networking. 248 Cooperative Adaptive Cruise Control (CACC) [CA-Cruise-Control] helps 249 vehicles to adapt their speed autonomously through V2V communication 250 among vehicles according to the mobility of their predecessor and 251 successor vehicles in an urban roadway or a highway. CACC can help 252 adjacent vehicles to efficiently adjust their speed in a cascade way 253 through V2V networking. 255 Platooning [Truck-Platooning] allows a series of vehicles (e.g., 256 trucks) to move together with a very short inter-distance. Trucks 257 can use V2V communication in addition to forward sensors in order to 258 maintain constant clearance between two consecutive vehicles at very 259 short gaps (from 3 meters to 10 meters). This platooning can 260 maximize the throughput of vehicular traffic in a highway and reduce 261 the gas consumption because the leading vehicle can help the 262 following vehicles to experience less air resistance. 264 Cooperative-environment-sensing use cases suggest that vehicles can 265 share environmental information from various vehicle-mounted sensors, 266 such as radars, LiDARs and cameras with other vehicles and 267 pedestrians. [Automotive-Sensing] introduces a millimeter-wave 268 vehicular communication for massive automotive sensing. Data 269 generated by those sensors can be substantially large, and these data 270 shall be routed to different destinations. In addition, from the 271 perspective of driverless vehicles, it is expected that driverless 272 vehicles can be mixed with driver-operated vehicles. Through 273 cooperative environment sensing, driver-operated vehicles can use 274 environmental information sensed by driverless vehicles for better 275 interaction with the context. 277 3.2. V2I 279 The use cases of V2I networking discussed in this section include 281 o Navigation service; 283 o Energy-efficient speed recommendation service; 285 o Accident notification service. 287 A navigation service, such as the Self-Adaptive Interactive 288 Navigation Tool (called SAINT) [SAINT], using V2I networking 289 interacts with TCC for the large-scale/long-range road traffic 290 optimization and can guide individual vehicles for appropriate 291 navigation paths in real time. The enhanced SAINT (called SAINT+) 292 [SAINTplus] can give the fast moving paths for emergency vehicles 293 (e.g., ambulance and fire engine) toward accident spots while 294 providing other vehicles with efficient detour paths. 296 A TCC can recommend an energy-efficient speed to a vehicle driving in 297 different traffic environments. [Fuel-Efficient] studies fuel- 298 efficient route and speed plans for platooned trucks. 300 The emergency communication between accident vehicles (or emergency 301 vehicles) and TCC can be performed via either RSU or 4G-LTE networks. 302 The First Responder Network Authority (FirstNet) [FirstNet] is 303 provided by the US government to establish, operate, and maintain an 304 interoperable public safety broadband network for safety and security 305 network services, such as emergency calls. The construction of the 306 nationwide FirstNet network requires each state in the US to have a 307 Radio Access Network (RAN) that will connect to FirstNet's network 308 core. The current RAN is mainly constructed by 4G-LTE for the 309 communication between a vehicle and an infrastructure node (i.e., 310 V2I) [FirstNet-Report], but it is expected that DSRC-based vehicular 311 networks [DSRC] will be available for V2I and V2V in near future. 313 3.3. V2X 315 The use case of V2X networking discussed in this section is 316 pedestrian protection service. 318 A pedestrian protection service, such as Safety-Aware Navigation 319 Application (called SANA) [SANA], using V2I2P networking can reduce 320 the collision of a vehicle and a pedestrian carrying a smartphone 321 equipped with the access technology with an RSU (e.g., WiFi). 322 Vehicles and pedestrians can also communicate with each other via an 323 RSU that delivers scheduling information for wireless communication 324 in order to save the smartphones' battery through sleeping mode. 326 For Vehicle-to-Pedestrian (V2P), a vehicle and a pedestrian's 327 smartphone can directly communicate with each other via V2X without 328 the relaying of an RSU as in a V2V scenario such that the 329 pedestrian's smartphone is regarded as a vehicle with a wireless 330 media interface to be able to communicate with another vehicle. In 331 Vehicle-to-Device (V2D), a device can be a mobile node such as 332 bicycle and motorcycle, and can communicate directly with a vehicle 333 for collision avoidance. 335 4. Analysis for Existing Protocols 337 4.1. Existing Protocols for Vehicular Networking 339 We describe some currently existing protocols and proposed solutions 340 with respect to the following aspects that are relevant and essential 341 for vehicular networking: 343 o IPv6 over 802.11-OCB; 345 o IP address autoconfiguration; 347 o Routing; 349 o Mobility management; 351 o DNS naming service; 353 o Service discovery; 355 o Security and privacy. 357 4.1.1. IPv6 over 802.11-OCB 359 For IPv6 packets transporting over IEEE 802.11-OCB, 360 [IPv6-over-802.11-OCB] specifies several details, such as Maximum 361 Transmission Unit (MTU), frame format, link-local address, address 362 mapping for unicast and multicast, stateless autoconfiguration, and 363 subnet structure. Especially, an Ethernet Adaptation (EA) layer is 364 in charge of transforming some parameters between IEEE 802.11 MAC 365 layer and IPv6 network layer, which is located between IEEE 366 802.11-OCB's logical link control layer and IPv6 network layer. 368 4.1.2. IP Address Autoconfiguration 370 For IP address autoconfiguration, Fazio et al. proposed a vehicular 371 address configuration (VAC) scheme using DHCP where elected leader- 372 vehicles provide unique identifiers for IP address configurations in 373 vehicles [Address-Autoconf]. Kato et al. proposed an IPv6 address 374 assignment scheme using lane and position information 375 [Address-Assignment]. Baldessari et al. proposed an IPv6 scalable 376 address autoconfiguration scheme called GeoSAC for vehicular networks 377 [GeoSAC]. Wetterwald et al. conducted for heterogeneous vehicular 378 networks (i.e., employing multiple access technologies) a 379 comprehensive study of the cross-layer identities management, which 380 constitutes a fundamental element of the ITS architecture 381 [Identity-Management]. 383 4.1.3. Routing 385 For routing, Tsukada et al. presented a work that aims at combining 386 IPv6 networking and a Car-to-Car Network routing protocol (called 387 C2CNet) proposed by the Car2Car Communication Consortium (C2C-CC), 388 which is an architecture using a geographic routing protocol 389 [VANET-Geo-Routing]. Abrougui et al. presented a gateway discovery 390 scheme for VANET, called Location-Aided Gateway Advertisement and 391 Discovery (LAGAD) mechanism [LAGAD]. 393 4.1.4. Mobility Management 395 For mobility management, Chen et al. tackled the issue of network 396 fragmentation in VANET environments [IP-Passing-Protocol] by 397 proposing a protocol that can postpone the time to release IP 398 addresses to the DHCP server and select a faster way to get the 399 vehicle's new IP address, when the vehicle density is low or the 400 speeds of vehicles are highly variable. Nguyen et al. proposed a 401 hybrid centralized-distributed mobility management called H-DMM to 402 support highly mobile vehicles [H-DMM]. [NEMO-LMS] proposed an 403 architecture to enable IP mobility for moving networks using a 404 network-based mobility scheme based on PMIPv6. Chen et al. proposed 405 a network mobility protocol to reduce handoff delay and maintain 406 Internet connectivity to moving vehicles in a highway [NEMO-VANET]. 407 Lee et al. proposed P-NEMO, which is a PMIPv6-based IP mobility 408 management scheme to maintain the Internet connectivity at the 409 vehicle as a mobile network, and provides a make-before-break 410 mechanism when vehicles switch to a new access network 411 [PMIP-NEMO-Analysis]. Peng et al. proposed a novel mobility 412 management scheme for integration of VANET and fixed IP networks 413 [VNET-MM]. Nguyen et al. extended their previous works on a 414 vehicular adapted DMM considering a Software-Defined Networking (SDN) 415 architecture [SDN-DMM]. 417 4.1.5. DNS Naming Service 419 For DNS naming service, Multicast DNS (mDNS) [RFC6762] allows devices 420 in one-hop communication range to resolve each other's DNS name into 421 the corresponding IP address in multicast. DNS Name 422 Autoconfiguration (DNSNA) [ID-DNSNA] proposes a DNS naming service 423 for Internet-of-Things (IoT) devices in a large-scale network. 425 4.1.6. Service Discovery 427 To discover instances of a demanded service in vehicular networks, 428 DNS-based Service Discovery (DNS-SD) [RFC6763] with either DNSNA 429 [ID-DNSNA] or mDNS [RFC6762] provides vehicles with service discovery 430 by using standard DNS queries. Vehicular ND [ID-Vehicular-ND] 431 proposes an extension of IPv6 ND for the prefix and service discovery 432 with new ND options [ID-VND-Discovery]. Note that a DNS query for 433 service discovery is unicasted in DNSNA, but it is multicasted in 434 both mDNS and Vehicular ND. 436 4.1.7. Security and Privacy 438 For security and privacy, Fernandez et al. proposed a secure 439 vehicular IPv6 communication scheme using Internet Key Exchange 440 version 2 (IKEv2) and Internet Protocol Security (IPsec) 441 [Securing-VCOMM]. Moustafa et al. proposed a security scheme 442 providing authentication, authorization, and accounting (AAA) 443 services in vehicular networks [VNET-AAA]. 445 4.2. General Problems 447 This section describes a possible vehicular network architecture for 448 V2V, V2I, and V2X communications. Then it analyzes the limitations 449 of the current protocols for vehicular networking. 451 Traffic Control Center in Vehicular Cloud 452 *-----------------------------------------* 453 * * 454 * +----------------+ * 455 * | Mobility Anchor| * 456 * +----------------+ * 457 * ^ * 458 * | * 459 *--------------------v--------------------* 460 ^ ^ ^ 461 | | | 462 +------------------ | -------------|-------------+ +------------------+ 463 | v v | | v | 464 | +--------+ Ethernet +--------+ | | +--------+ | 465 | | RSU1 |<----------->| RSU2 |<---------->| RSU3 | | 466 | +--------+ +--------+ | | +--------+ | 467 | ^ ^ ^ | | ^ | 468 | : : : | | : | 469 | V2I : : V2I V2I : | | V2I : | 470 | v v v | | v | 471 | +--------+ +--------+ +--------+ | | +--------+ | 472 | |Vehicle1|===> |Vehicle2|===> |Vehicle3|===>| | |Vehicle4|===>| 473 | | |<....>| |<....>| | | | | | | 474 | +--------+ V2V +--------+ V2V +--------+ | | +--------+ | 475 | | | | 476 +-------------------------------------------------+ +------------------+ 477 Subnet1 Subnet2 479 <----> Wired Link <....> Wireless Link ===> Moving Direction 481 Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 483 4.2.1. Vehicular Network Architecture 485 Figure 1 shows a possible architecture for V2I and V2V networking in 486 a road network. It is assumed that RSUs as routers and vehicles with 487 OBU have wireless media interfaces (e.g., IEEE 802.11-OCB, LTE Uu and 488 Device-to-Device (D2D) (also known as PC5 [TS-23.285-3GPP]), 489 Bluetooth, and Light Fidelity (Li-Fi)) for V2I and V2V communication. 490 Also, it is assumed that such the wireless media interfaces are 491 autoconfigured with a global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to 492 support both V2V and V2I networking. Three RSUs (RSU1, RSU2, and 493 RSU3) are deployed in the road network and are connected to a 494 Vehicular Cloud through the Internet. A Traffic Control Center (TCC) 495 is connected to the Vehicular Cloud for the management of RSUs and 496 vehicles in the road network. A Mobility Anchor (MA) is located in 497 the TCC as its key component for the mobility management of vehicles. 498 Two vehicles (Vehicle1 and Vehicle2) are wirelessly connected to 499 RSU1, and one vehicle (Vehicle3) is wirelessly connected to RSU2. 500 The wireless networks of RSU1 and RSU2 belong to a multi-link subnet 501 (denoted as Subnet1) with the same network prefix. Thus, these three 502 vehicles are within the same subnet. On the other hand, another 503 vehicle (Vehicle4) is wireless connected to RSU4, belonging to 504 another subnet (denoted as Subnet2). That is, the first three 505 vehicles (i.e., Vehicle1, Vehicle2, and Vehicle3) and the last 506 vehicle (i.e., Vehicle4) are located in the two different subnets. 507 Vehicle1 can communicate with Vehicle2 via V2V communication, and 508 Vehicle2 can communicate with Vehicle3 via V2V communication because 509 they are within the same subnet along their IPv6 addresses, which are 510 based on the same prefix. On the other hand, Vehicle3 can 511 communicate with Vehicle4 via RSU2 and RSU3 employing V2I (i.e., 512 V2I2V) communication because they are within the two different 513 subnets along with their IPv6 addresses, which are based on the two 514 different prefixes. 516 In vehicular networks, unidirectional links exist and must be 517 considered for wireless communications. Also, in the vehicular 518 networks, control plane must be separated from data plane for 519 efficient mobility management and data forwarding using Software- 520 Defined Networking (SDN) [SDN-DMM]. ID/Pseudonym change for privacy 521 requires a lightweight DAD. IP tunneling over the wireless link 522 should be avoided for performance efficiency. The mobility 523 information of a mobile (e.g., vehicle-mounted) device through a GPS 524 receiver in its vehicle, such as trajectory, position, speed, and 525 direction, can be used by the mobile device and infrastructure nodes 526 (e.g., TCC and RSU) for the accommodation of mobility-aware proactive 527 protocols. Vehicles can use the TCC as their Home Network having a 528 home agent for mobility management as in MIPv6 [RFC6275] and Proxy 529 Mobile IPv6 (PMIPv6) [RFC5213], so the TCC maintains the mobility 530 information of vehicles for location management. 532 Cespedes et al. proposed a vehicular IP in WAVE called VIP-WAVE for 533 I2V and V2I networking [VIP-WAVE]. The standard WAVE does not 534 support both seamless communications for Internet services and multi- 535 hop communications between a vehicle and an infrastructure node 536 (e.g., RSU), either. To overcome these limitations of the standard 537 WAVE, VIP-WAVE enhances the standard WAVE by the following three 538 schemes: (i) an efficient mechanism for the IPv6 address assignment 539 and DAD, (ii) on-demand IP mobility based on PMIPv6 [RFC5213], and 540 (iii) one-hop and two-hop communications for I2V and V2I networking. 542 Baccelli et al. provided an analysis of the operation of IPv6 as it 543 has been described by the IEEE WAVE standards 1609 [IPv6-WAVE]. This 544 analysis confirms that the use of the standard IPv6 protocol stack in 545 WAVE is not sufficient. It recommends that the IPv6 addressing 546 assignment should follow considerations for ad-hoc link models, 547 defined in [RFC5889] for nodes' mobility and link variability. 549 Petrescu et al. proposed the joint IP networking and radio 550 architecture for V2V and V2I communication in [Joint-IP-Networking]. 551 The proposed architecture considers an IP topology in a similar way 552 as a radio link topology, in the sense that an IP subnet would 553 correspond to the range of 1-hop vehicular communication. This 554 architecture defines three types of vehicles: Leaf Vehicle, Range 555 Extending Vehicle, and Internet Vehicle. 557 +----------------+ 558 (*)<........>(*) +----->| Vehicular Cloud| 559 2001:DB8:1:1::/64 | | | +----------------+ 560 +------------------------------+ +---------------------------------+ 561 | v | | v v | 562 | .-------. .------. .-------. | | .-------. .------. .-------. | 563 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 564 | ._______. .______. ._______. | | ._______. .______. ._______. | 565 | ^ ^ ^ | | ^ ^ ^ | 566 | | | | | | | | | | 567 | v v v | | v v v | 568 | ---------------------------- | | ------------------------------- | 569 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 570 | | | | | | 571 | v | | v | 572 | .-------. .-------. | | .-------. .-------. .-------. | 573 | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | 574 | ._______. ._______. | | ._______. ._______. ._______. | 575 | ^ ^ | | ^ ^ ^ | 576 | | | | | | | | | 577 | v v | | v v v | 578 | ---------------------------- | | ------------------------------- | 579 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 580 +______________________________+ +_________________________________+ 581 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 583 <----> Wired Link <....> Wireless Link (*) Antenna 585 Figure 2: Internetworking between Vehicle Network and RSU Network 587 4.2.1.1. V2I-based Internetworking 589 This section discusses the internetworking between a vehicle's moving 590 network and an RSU's fixed network via V2I communication. 592 As shown in Figure 2, the vehicle's moving network and the RSU's 593 fixed network are self-contained networks having multiple subnets and 594 having an edge router for the communication with another vehicle or 595 RSU. The method of prefix assignment for each subnet inside the 596 vehicle's mobile network and the RSU's fixed network is out of scope 597 for this document. Internetworking between two internal networks via 598 V2I communication requires an exchange of network prefix and other 599 parameters through a prefix discovery mechanism, such as ND-based 600 prefix discovery [ID-VND-Discovery]. For the ND-based prefix 601 discovery, network prefixs and parameters should be registered into a 602 vehicle's router and an RSU router with an external network interface 603 in advance. 605 The network parameter discovery collects networking information for 606 an IP communication between a vehicle and an RSU or between two 607 neighboring vehicles, such as link layer, MAC layer, and IP layer 608 information. The link layer information includes wireless link layer 609 parameters, such as wireless media (e.g., IEEE 802.11-OCB, LTE Uu and 610 D2D, Bluetooth, and LiFi) and a transmission power level. Note that 611 LiFi is a technology for light-based wireless communication between 612 devices in order to transmit both data and position. The MAC layer 613 information includes the MAC address of an external network interface 614 for the internetworking with another vehicle or RSU. The IP layer 615 information includes the IP address and prefix of an external network 616 interface for the internetworking with another vehicle or RSU. 618 Once the network parameter discovery and prefix exchange operations 619 have been performed, packets can be transmitted between the vehicle's 620 moving network and the RSU's fixed network. DNS services should be 621 supported to enable name resolution for hosts or servers residing 622 either in the vehicle's moving network or the RSU's fixed network. 623 It is assumed that the DNS names of in-vehicle devices and their 624 service names are registered into a DNS server (i.e., recursive DNS 625 server called RDNSS) in a vehicle or an RSU, as shown in Figure 2. 626 For service discovery, those DNS names and service names can be 627 advertised to neighboring vehicles through either DNS-based service 628 discovery mechanisms [RFC6762][RFC6763][ID-DNSNA] and ND-based 629 service discovery [ID-Vehicular-ND][ID-VND-Discovery]. For the ND- 630 based service discovery, service names should be registered into a 631 vehicle's router and an RSU router with an external network interface 632 in advance. Refer to Section 4.1.5 and Section 4.1.6 for detailed 633 information. For these DNS services, an RDNSS within each internal 634 network of a vehicle or RSU can be used for the hosts or servers. 636 Figure 2 shows internetworking between the vehicle's moving network 637 and the RSU's fixed network. There exists an internal network 638 (Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server 639 (RDNSS1), the two hosts (Host1 and Host2), and the two routers 640 (Router1 and Router2). There exists another internal network (Fixed 641 Network1) inside RSU1. RSU1 has the DNS Server (RDNSS2), one host 642 (Host3), the two routers (Router3 and Router4), and the collection of 643 servers (Server1 to ServerN) for various services in the road 644 networks, such as the emergency notification and navigation. 645 Vehicle1's Router1 (called mobile router) and RSU1's Router3 (called 646 fixed router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) 647 for I2V networking. 649 (*)<..........>(*) 650 2001:DB8:1:1::/64 | | 651 +------------------------------+ +---------------------------------+ 652 | v | | v | 653 | .-------. .------. .-------. | | .-------. .------. .-------. | 654 | | Host1 | |RDNSS1| |Router1| | | |Router5| |RDNSS3| | Host4 | | 655 | ._______. .______. ._______. | | ._______. .______. ._______. | 656 | ^ ^ ^ | | ^ ^ ^ | 657 | | | | | | | | | | 658 | v v v | | v v v | 659 | ---------------------------- | | ------------------------------- | 660 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:30:1::/64 | 661 | | | | | | 662 | v | | v | 663 | .-------. .-------. | | .-------. .-------. | 664 | | Host2 | |Router2| | | |Router6| | Host5 | | 665 | ._______. ._______. | | ._______. ._______. | 666 | ^ ^ | | ^ ^ | 667 | | | | | | | | 668 | v v | | v v | 669 | ---------------------------- | | ------------------------------- | 670 | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | 671 +______________________________+ +_________________________________+ 672 Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) 674 <----> Wired Link <....> Wireless Link (*) Antenna 676 Figure 3: Internetworking between Two Vehicle Networks 678 4.2.1.2. V2V-based Internetworking 680 This section discusses the internetworking between the moving 681 networks of two neighboring vehicles via V2V communication. 683 Figure 3 shows internetworking between the moving networks of two 684 neighboring vehicles. There exists an internal network (Moving 685 Network1) inside Vehicle1. Vehicle1 has the DNS Server (RDNSS1), the 686 two hosts (Host1 and Host2), and the two routers (Router1 and 687 Router2). There exists another internal network (Moving Network2) 688 inside Vehicle2. Vehicle2 has the DNS Server (RDNSS3), the two hosts 689 (Host4 and Host5), and the two routers (Router5 and Router6). 691 Vehicle1's Router1 (called mobile router) and Vehicle2's Router5 692 (called mobile router) use 2001:DB8:1:1::/64 for an external link 693 (e.g., DSRC) for V2V networking. 695 The differences between IPWAVE (including Vehicular Ad Hoc Networks 696 (VANET)) and Mobile Ad Hoc Networks (MANET) are as follows: 698 o IPWAVE is not power-constrained operation; 700 o Traffic can be sourced or sinked outside of IPWAVE; 702 o IPWAVE shall support both distributed and centralized operations; 704 o No "sleep" period operation is required for energy saving. 706 4.2.2. Latency 708 The communication delay (i.e., latency) between two vehicular nodes 709 (vehicle and RSU) should be bounded to a certain threshold. For IP- 710 based safety applications (e.g., context-aware navigation, adaptive 711 cruise control, and platooning) in vehicular network, this bounded 712 data delivery is critical. The real implementations for such 713 applications are not available, so the feasibility of IP-based safety 714 applications is not tested yet. 716 4.2.3. Security 718 Strong security measures shall protect vehicles roaming in road 719 networks from the attacks of malicious nodes, which are controlled by 720 hackers. For safety applications, the cooperation among vehicles is 721 assumed. Malicious nodes may disseminate wrong driving information 722 (e.g., location, speed, and direction) to make driving be unsafe. 723 Sybil attack, which tries to illude a vehicle with multiple false 724 identities, disturbs a vehicle in taking a safe maneuver. 725 Applications on IP-based vehicular networking, which are resilient to 726 such a sybil attack, are not developed and tested yet. 728 4.2.4. Pseudonym Handling 730 For the protection of drivers' privacy, pseudonym for a vehicle's 731 network interface should be used, with the help of which the 732 interface's identifier can be changed periodically. Such a pseudonym 733 affects an IPv6 address based on the network interface's identifier, 734 and a transport-layer (e.g., TCP) session with an IPv6 address pair. 735 The pseudonym handling is not implemented and tested yet for 736 applications on IP-based vehicular networking. 738 5. Problem Exploration 740 This section discusses key topics for IPWAVE WG, such as neighbor 741 discovery, mobility management, and security & privacy. 743 5.1. Neighbor Discovery 745 Neighbor Discovery (ND) [RFC4861] is a core part of the IPv6 protocol 746 suite. This section discusses the need for modifying ND for use with 747 vehicular networking (e.g., V2V, V2I, and V2X). The vehicles are 748 moving fast within the communication coverage of a vehicular node 749 (e.g., vehicle and RSU). The external wireless link between two 750 vehicular nodes can be used for vehicular networking, as shown in 751 Figure 2 and Figure 3. 753 ND time-related parameters such as router lifetime and Neighbor 754 Advertisement (NA) interval should be adjusted for high-speed 755 vehicles and vehicle density. As vehicles move faster, the NA 756 interval should decrease for the NA messages to reach the neighboring 757 vehicles promptly. Also, as vehicle density is higher, the NA 758 interval should increase for the NA messages to reduce collision 759 probability with other NA messages. 761 5.1.1. Link Model 763 IPv6 protocols work under certain assumptions for the link model that 764 do not necessarily hold in a vehicular wireless link [VIP-WAVE]. For 765 instance, some IPv6 protocols assume symmetry in the connectivity 766 among neighboring interfaces. However, interference and different 767 levels of transmission power may cause unidirectional links to appear 768 in vehicular wireless links. As a result, a new vehicular link model 769 is required for the vehicular wireless link. 771 There is a relationship between a link and prefix, besides the 772 different scopes that are expected from the link-local and global 773 types of IPv6 addresses. In an IPv6 link, it is assumed that all 774 interfaces which are configured with the same subnet prefix and with 775 on-link bit set can communicate with each other on an IP link or 776 extended IP links via ND proxy. Note that a subnet prefix can be 777 used by spanning multiple links as a multi-link subnet [RFC6775]. 778 Also, note that IPv6 Stateless Address Autoconfiguration can be 779 performed in the multiple links where each of them is not assigned 780 with a unique subnet prefix, that is, all of them are configured with 781 the same subnet prefix [RFC4861][RFC4862]. A vehicular link model 782 needs to consider a multi-hop VANET over a multi-link subnet. Such a 783 VANET is usually a multi-link subnet consisting of multiple vehicles 784 interconnected by wireless communication range. Such a subnet has a 785 highly dynamic topology over time due to node mobility. 787 Thus, IPv6 ND should be extended into a Vehicular Neighbor Discovey 788 (VND) [ID-Vehicular-ND] to support the concept of an IPv6 link 789 corresponding to an IPv6 prefix even in a multi-link subnet 790 consisting of multiple vehicles and RSUs that are interconnected with 791 wireless communication range in IP-based vehicular networks. 793 5.1.2. MAC Address Pseudonym 795 In the ETSI standards, for the sake of security and privacy, an ITS 796 station (e.g., vehicle) can use pseudonyms for its network interface 797 identities (e.g., MAC address) and the corresponding IPv6 addresses 798 [Identity-Management]. Whenever the network interface identifier 799 changes, the IPv6 address based on the network interface identifier 800 should be updated. For the continuity of an end-to-end (E2E) 801 transport-layer (e.g., TCP, UDP, and SCTP) session, with a mobility 802 management scheme (e.g., MIPv6 and PMIPv6), the new IP address for 803 the transport-layer session should be notified to an appropriate end 804 point, and the packets of the session should be forwarded to their 805 destinations with the changed network interface identifier and IPv6 806 address. 808 5.1.3. Prefix Dissemination/Exchange 810 A vehicle and an RSU can have their internal network, as shown in 811 Figure 2 and Figure 3. In this case, nodes in within the internal 812 networks of two vehicular nodes (e.g., vehicle and RSU) want to 813 communicate with each other. For this communication on the wireless 814 link, the network prefix dissemination or exchange is required. It 815 is assumed that a vehicular node has an external network interface 816 and its internal network. The legacy IPv6 ND [RFC4861] needs to be 817 extended to a vehicular ND (VND) [ID-Vehicular-ND] for the 818 communication between the internal-network nodes (e.g., an in-vehicle 819 device in a vehicle and a server in an RSU) of vehicular nodes by 820 letting each of them know the other side's prefix with a new ND 821 option [ID-VND-Discovery]. Thus, this ND extension for routing 822 functionality can reduce control traffic for routing in vehicular 823 networks without an additional vehicular ad hoc routing protocol 824 [VANET-Geo-Routing]. 826 5.1.4. Routing 828 For multihop V2V communications in a multi-link subnet (as a 829 connected VANET), a vehicular ad hoc routing protocol (e.g., 830 geographic routing) may be required to support both unicast and 831 multicast in the links of the subnet with the same IPv6 prefix 832 [VANET-Geo-Routing]. Instead of the vehicular ad hoc routing 833 protocol, Vehicular ND along with a prefix discovery option can be 834 used to let vehicles exchange their prefixes in a multihop fashion 836 [ID-Vehicular-ND][ID-VND-Discovery]. With the exchanged prefixes, 837 they can compute their routing table (or IPv6 ND's neighbor cache) 838 for the multi-link subnet with a distance-vector algorithm 839 [Intro-to-Algorithms]. Also, an efficient, rapid DAD should be 840 supported to prevent or reduce IPv6 address conflicts in the multi- 841 link subnet by using a DAD optimization [ID-Vehicular-ND][RFC6775] or 842 an IPv6 geographic-routing-based address autoconfiguration [GeoSAC]. 844 5.2. Mobility Management 846 The seamless connectivity and timely data exchange between two end 847 points requires an efficient mobility management including location 848 management and handover. Most of vehicles are equipped with a GPS 849 receiver as part of a dedicated navigation system or a corresponding 850 smartphone App. In the case where the provided location information 851 is precise enough, well-known temporary degradations in precision may 852 occur due to system configuration or the adverse local environment. 853 This precision is improved thanks to assistance by the RSUs or a 854 cellular system with this navigation system. With this GPS 855 navigator, an efficient mobility management is possible by vehicles 856 periodically reporting their current position and trajectory (i.e., 857 navigation path) to RSUs and a Mobility Anchor (MA) in TCC. The RSUs 858 and MA can predict the future positions of the vehicles with their 859 mobility information (i.e., the current position, speed, direction, 860 and trajectory) for the efficient mobility management (e.g., 861 proactive handover). For a better proactive handover, link-layer 862 parameters, such as the signal strength of a link-layer frame (e.g., 863 Received Channel Power Indicator (RCPI) [VIP-WAVE]), can be used to 864 determine the moment of a handover between RSUs along with mobility 865 information [ID-Vehicular-ND]. 867 With the prediction of the vehicle mobility, MA can support RSUs to 868 perform DAD, data packet routing, horizontal handover (i.e., handover 869 in wireless links using a homogeneous radio technology), and vertical 870 handover (i.e., handover in wireless links using heterogeneous radio 871 technologies) in a proactive manner. Even though a vehicle moves 872 into the wireless link under another RSU belonging to a different 873 subnet, the RSU can proactively perform the DAD for the sake of the 874 vehicle, reducing IPv6 control traffic overhead in the wireless link 875 [ID-Vehicular-ND]. 877 Therefore, with a proactive handover and a multihop DAD in vehicular 878 networks [ID-Vehicular-ND], RSUs can efficiently forward data packets 879 from the wired network (or the wireless network) to a moving 880 destination vehicle along its trajectory along with the MA. Thus, a 881 moving vehicle can communicate with its corresponding vehicle in the 882 vehicular network or a host/server in the Internet along its 883 trajectory. 885 5.3. Security and Privacy 887 Security and privacy are paramount in the V2I, V2V, and V2X 888 networking in vehicular networks. Only authorized vehicles should be 889 allowed to use vehicular networking. Also, in-vehicle devices and 890 mobile devices in a vehicle need to communicate with other in-vehicle 891 devices and mobile devices in another vehicle, and other servers in 892 an RSU in a secure way. 894 A Vehicle Identification Number (VIN) and a user certificate along 895 with in-vehicle device's identifier generation can be used to 896 efficiently authenticate a vehicle or a user through a road 897 infrastructure node (e.g., RSU) connected to an authentication server 898 in TCC. Also, Transport Layer Security (TLS) certificates can be 899 used for secure E2E vehicle communications. 901 For secure V2I communication, a secure channel between a mobile 902 router in a vehicle and a fixed router in an RSU should be 903 established, as shown in Figure 2. Also, for secure V2V 904 communication, a secure channel between a mobile router in a vehicle 905 and a mobile router in another vehicle should be established, as 906 shown in Figure 3. 908 To prevent an adversary from tracking a vehicle with its MAC address 909 or IPv6 address, MAC address pseudonym should be provided to the 910 vehicle; that is, each vehicle should periodically update its MAC 911 address and the corresponding IPv6 address as suggested in 912 [RFC4086][RFC4941]. Such an update of the MAC and IPv6 addresses 913 should not interrupt the E2E communications between two vehicular 914 nodes (e.g., vehicle and RSU) in terms of transport layer for a long- 915 living higher-layer session. However, if this pseudonym is performed 916 without strong E2E confidentiality, there will be no privacy benefit 917 from changing MAC and IP addresses, because an adversary can see the 918 change of the MAC and IP addresses and track the vehicle with those 919 addresses. 921 6. Security Considerations 923 This document discussed security and privacy for IP-based vehicular 924 networking. 926 The security and privacy for key components in IP-based vehicular 927 networking, such as neighbor discovery and mobility management, need 928 to be analyzed in depth. 930 7. Informative References 932 [Address-Assignment] 933 Kato, T., Kadowaki, K., Koita, T., and K. Sato, "Routing 934 and Address Assignment using Lane/Position Information in 935 a Vehicular Ad-hoc Network", IEEE Asia-Pacific Services 936 Computing Conference, December 2008. 938 [Address-Autoconf] 939 Fazio, M., Palazzi, C., Das, S., and M. Gerla, "Automatic 940 IP Address Configuration in VANETs", ACM International 941 Workshop on Vehicular Inter-Networking, September 2016. 943 [Automotive-Sensing] 944 Choi, J., Va, V., Gonzalez-Prelcic, N., Daniels, R., R. 945 Bhat, C., and R. W. Heath, "Millimeter-Wave Vehicular 946 Communication to Support Massive Automotive Sensing", 947 IEEE Communications Magazine, December 2016. 949 [Broadcast-Storm] 950 Wisitpongphan, N., K. Tonguz, O., S. Parikh, J., Mudalige, 951 P., Bai, F., and V. Sadekar, "Broadcast Storm Mitigation 952 Techniques in Vehicular Ad Hoc Networks", IEEE Wireless 953 Communications, December 2007. 955 [CA-Cruise-Control] 956 California Partners for Advanced Transportation Technology 957 (PATH), "Cooperative Adaptive Cruise Control", [Online] 958 Available: 959 http://www.path.berkeley.edu/research/automated-and- 960 connected-vehicles/cooperative-adaptive-cruise-control, 961 2017. 963 [CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A 964 Framework of Context-Awareness Safety Driving in Vehicular 965 Networks", International Workshop on Device Centric Cloud 966 (DC2), March 2016. 968 [DSRC] ASTM International, "Standard Specification for 969 Telecommunications and Information Exchange Between 970 Roadside and Vehicle Systems - 5 GHz Band Dedicated Short 971 Range Communications (DSRC) Medium Access Control (MAC) 972 and Physical Layer (PHY) Specifications", 973 ASTM E2213-03(2010), October 2010. 975 [ETSI-GeoNetwork-IP] 976 ETSI Technical Committee Intelligent Transport Systems, 977 "Intelligent Transport Systems (ITS); Vehicular 978 Communications; GeoNetworking; Part 6: Internet 979 Integration; Sub-part 1: Transmission of IPv6 Packets over 980 GeoNetworking Protocols", ETSI EN 302 636-6-1, October 981 2013. 983 [ETSI-GeoNetworking] 984 ETSI Technical Committee Intelligent Transport Systems, 985 "Intelligent Transport Systems (ITS); Vehicular 986 Communications; GeoNetworking; Part 4: Geographical 987 addressing and forwarding for point-to-point and point-to- 988 multipoint communications; Sub-part 1: Media-Independent 989 Functionality", ETSI EN 302 636-4-1, May 2014. 991 [EU-2008-671-EC] 992 European Union, "Commission Decision of 5 August 2008 on 993 the Harmonised Use of Radio Spectrum in the 5875 - 5905 994 MHz Frequency Band for Safety-related Applications of 995 Intelligent Transport Systems (ITS)", EU 2008/671/EC, 996 August 2008. 998 [FirstNet] 999 U.S. National Telecommunications and Information 1000 Administration (NTIA), "First Responder Network Authority 1001 (FirstNet)", [Online] 1002 Available: https://www.firstnet.gov/, 2012. 1004 [FirstNet-Report] 1005 First Responder Network Authority, "FY 2017: ANNUAL REPORT 1006 TO CONGRESS, Advancing Public Safety Broadband 1007 Communications", FirstNet FY 2017, December 2017. 1009 [Fuel-Efficient] 1010 van de Hoef, S., H. Johansson, K., and D. V. Dimarogonas, 1011 "Fuel-Efficient En Route Formation of Truck Platoons", 1012 IEEE Transactions on Intelligent Transportation Systems, 1013 January 2018. 1015 [GeoSAC] Baldessari, R., Bernardos, C., and M. Calderon, "GeoSAC - 1016 Scalable Address Autoconfiguration for VANET Using 1017 Geographic Networking Concepts", IEEE International 1018 Symposium on Personal, Indoor and Mobile Radio 1019 Communications, September 2008. 1021 [H-DMM] Nguyen, T. and C. Bonnet, "A Hybrid Centralized- 1022 Distributed Mobility Management for Supporting Highly 1023 Mobile Users", IEEE International Conference on 1024 Communications, June 2015. 1026 [ID-DNSNA] 1027 Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 1028 Autoconfiguration for Internet of Things Devices", draft- 1029 jeong-ipwave-iot-dns-autoconf-04 (work in progress), 1030 October 2018. 1032 [ID-Vehicular-ND] 1033 Xiang, Zhong., Jeong, J., Ed., and Y. Shen, "IPv6 Neighbor 1034 Discovery for IP-Based Vehicular Networks", draft-xiang- 1035 ipwave-vehicular-neighbor-discovery-00 (work in progress), 1036 November 2018. 1038 [ID-VND-Discovery] 1039 Jeong, J., Ed., Shen, Y., Jo, Y., Jeong, J., and J. Lee, 1040 "IPv6 Neighbor Discovery for Prefix and Service Discovery 1041 in Vehicular Networks", draft-jeong-ipwave-vehicular- 1042 neighbor-discovery-04 (work in progress), October 2018. 1044 [Identity-Management] 1045 Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer 1046 Identities Management in ITS Stations", The 10th 1047 International Conference on ITS Telecommunications, 1048 November 2010. 1050 [IEEE-802.11-OCB] 1051 IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium 1052 Access Control (MAC) and Physical Layer (PHY) 1053 Specifications", IEEE Std 802.11-2016, December 2016. 1055 [IEEE-802.11p] 1056 IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium 1057 Access Control (MAC) and Physical Layer (PHY) 1058 Specifications - Amendment 6: Wireless Access in Vehicular 1059 Environments", IEEE Std 802.11p-2010, June 2010. 1061 [Intro-to-Algorithms] 1062 H. Cormen, T., E. Leiserson, C., L. Rivest, R., and C. 1063 Stein, "Introduction to Algorithms, 3rd ed.", The 1064 MIT Press, July 2009. 1066 [IP-Passing-Protocol] 1067 Chen, Y., Hsu, C., and W. Yi, "An IP Passing Protocol for 1068 Vehicular Ad Hoc Networks with Network Fragmentation", 1069 Elsevier Computers & Mathematics with Applications, 1070 January 2012. 1072 [IPv6-over-802.11-OCB] 1073 Petrescu, A., Benamar, N., Haerri, J., Lee, J., and T. 1074 Ernst, "Transmission of IPv6 Packets over IEEE 802.11 1075 Networks operating in mode Outside the Context of a Basic 1076 Service Set (IPv6-over-80211-OCB)", draft-ietf-ipwave- 1077 ipv6-over-80211ocb-30 (work in progress), September 2018. 1079 [IPv6-WAVE] 1080 Baccelli, E., Clausen, T., and R. Wakikawa, "IPv6 1081 Operation for WAVE - Wireless Access in Vehicular 1082 Environments", IEEE Vehicular Networking Conference, 1083 December 2010. 1085 [ISO-ITS-IPv6] 1086 ISO/TC 204, "Intelligent Transport Systems - 1087 Communications Access for Land Mobiles (CALM) - IPv6 1088 Networking", ISO 21210:2012, June 2012. 1090 [Joint-IP-Networking] 1091 Petrescu, A., Boc, M., and C. Ibars, "Joint IP Networking 1092 and Radio Architecture for Vehicular Networks", 1093 11th International Conference on ITS Telecommunications, 1094 August 2011. 1096 [LAGAD] Abrougui, K., Boukerche, A., and R. Pazzi, "Location-Aided 1097 Gateway Advertisement and Discovery Protocol for VANets", 1098 IEEE Transactions on Vehicular Technology, Vol. 59, No. 8, 1099 October 2010. 1101 [Multicast-802] 1102 Perkins, C., Stanley, D., Kumari, W., and JC. Zuniga, 1103 "Multicast Considerations over IEEE 802 Wireless Media", 1104 draft-perkins-intarea-multicast-ieee802-03 (work in 1105 progress), July 2017. 1107 [Multicast-Alert] 1108 Camara, D., Bonnet, C., Nikaein, N., and M. Wetterwald, 1109 "Multicast and Virtual Road Side Units for Multi 1110 Technology Alert Messages Dissemination", IEEE 8th 1111 International Conference on Mobile Ad-Hoc and Sensor 1112 Systems, October 2011. 1114 [NEMO-LMS] 1115 Soto, I., Bernardos, C., Calderon, M., Banchs, A., and A. 1116 Azcorra, "NEMO-Enabled Localized Mobility Support for 1117 Internet Access in Automotive Scenarios", 1118 IEEE Communications Magazine, May 2009. 1120 [NEMO-VANET] 1121 Chen, Y., Hsu, C., and C. Cheng, "Network Mobility 1122 Protocol for Vehicular Ad Hoc Networks", 1123 Wiley International Journal of Communication Systems, 1124 November 2014. 1126 [PMIP-NEMO-Analysis] 1127 Lee, J., Ernst, T., and N. Chilamkurti, "Performance 1128 Analysis of PMIPv6-Based Network Mobility for Intelligent 1129 Transportation Systems", IEEE Transactions on Vehicular 1130 Technology, January 2012. 1132 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1133 "Randomness Requirements for Security", RFC 4086, June 1134 2005. 1136 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1137 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 1138 September 2007. 1140 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1141 Address Autoconfiguration", RFC 4862, September 2007. 1143 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1144 Extensions for Stateless Address Autoconfiguration in 1145 IPv6", RFC 4941, September 2007. 1147 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1148 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1149 RFC 5213, August 2008. 1151 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 1152 Hoc Networks", RFC 5889, September 2010. 1154 [RFC5944] Perkins, C., Ed., "IP Mobility Support in IPv4, Revised", 1155 RFC 5944, November 2010. 1157 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1158 Support in IPv6", RFC 6275, July 2011. 1160 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1161 February 2013. 1163 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1164 Discovery", RFC 6763, February 2013. 1166 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1167 "Neighbor Discovery Optimization for IPv6 over Low-Power 1168 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1169 November 2012. 1171 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 1172 "Requirements for Distributed Mobility Management", 1173 RFC 7333, August 2014. 1175 [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. 1176 Bernardos, "Distributed Mobility Management: Current 1177 Practices and Gap Analysis", RFC 7429, January 2015. 1179 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1180 (IPv6) Specification", RFC 8200, July 2017. 1182 [SAINT] Jeong, J., Jeong, H., Lee, E., Oh, T., and D. Du, "SAINT: 1183 Self-Adaptive Interactive Navigation Tool for Cloud-Based 1184 Vehicular Traffic Optimization", IEEE Transactions on 1185 Vehicular Technology, Vol. 65, No. 6, June 2016. 1187 [SAINTplus] 1188 Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D. 1189 Du, "SAINT+: Self-Adaptive Interactive Navigation Tool+ 1190 for Emergency Service Delivery Optimization", 1191 IEEE Transactions on Intelligent Transportation Systems, 1192 June 2017. 1194 [SANA] Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation 1195 Application for Pedestrian Protection in Vehicular 1196 Networks", Springer Lecture Notes in Computer Science 1197 (LNCS), Vol. 9502, December 2015. 1199 [SDN-DMM] Nguyen, T., Bonnet, C., and J. Harri, "SDN-based 1200 Distributed Mobility Management for 5G Networks", 1201 IEEE Wireless Communications and Networking Conference, 1202 April 2016. 1204 [Securing-VCOMM] 1205 Fernandez, P., Santa, J., Bernal, F., and A. Skarmeta, 1206 "Securing Vehicular IPv6 Communications", 1207 IEEE Transactions on Dependable and Secure Computing, 1208 January 2016. 1210 [TR-22.886-3GPP] 1211 3GPP, "Study on Enhancement of 3GPP Support for 5G V2X 1212 Services", 3GPP TS 22.886, June 2018. 1214 [Truck-Platooning] 1215 California Partners for Advanced Transportation Technology 1216 (PATH), "Automated Truck Platooning", [Online] Available: 1217 http://www.path.berkeley.edu/research/automated-and- 1218 connected-vehicles/truck-platooning, 2017. 1220 [TS-23.285-3GPP] 1221 3GPP, "Architecture Enhancements for V2X Services", 3GPP 1222 TS 23.285, June 2018. 1224 [VANET-Geo-Routing] 1225 Tsukada, M., Jemaa, I., Menouar, H., Zhang, W., Goleva, 1226 M., and T. Ernst, "Experimental Evaluation for IPv6 over 1227 VANET Geographic Routing", IEEE International Wireless 1228 Communications and Mobile Computing Conference, June 2010. 1230 [VIP-WAVE] 1231 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 1232 Feasibility of IP Communications in 802.11p Vehicular 1233 Networks", IEEE Transactions on Intelligent Transportation 1234 Systems, vol. 14, no. 1, March 2013. 1236 [VMaSC-LTE] 1237 Ucar, S., Ergen, S., and O. Ozkasap, "Multihop-Cluster- 1238 Based IEEE 802.11p and LTE Hybrid Architecture for VANET 1239 Safety Message Dissemination", IEEE Transactions on 1240 Vehicular Technology, April 2016. 1242 [VNET-AAA] 1243 Moustafa, H., Bourdon, G., and Y. Gourhant, "Providing 1244 Authentication and Access Control in Vehicular Network 1245 Environment", IFIP TC-11 International Information 1246 Security Conference, May 2006. 1248 [VNET-MM] Peng, Y. and J. Chang, "A Novel Mobility Management Scheme 1249 for Integration of Vehicular Ad Hoc Networks and Fixed IP 1250 Networks", Springer Mobile Networks and Applications, 1251 February 2010. 1253 [WAVE-1609.0] 1254 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 1255 in Vehicular Environments (WAVE) - Architecture", IEEE Std 1256 1609.0-2013, March 2014. 1258 [WAVE-1609.2] 1259 IEEE 1609 Working Group, "IEEE Standard for Wireless 1260 Access in Vehicular Environments - Security Services for 1261 Applications and Management Messages", IEEE Std 1262 1609.2-2016, March 2016. 1264 [WAVE-1609.3] 1265 IEEE 1609 Working Group, "IEEE Standard for Wireless 1266 Access in Vehicular Environments (WAVE) - Networking 1267 Services", IEEE Std 1609.3-2016, April 2016. 1269 [WAVE-1609.4] 1270 IEEE 1609 Working Group, "IEEE Standard for Wireless 1271 Access in Vehicular Environments (WAVE) - Multi-Channel 1272 Operation", IEEE Std 1609.4-2016, March 2016. 1274 Appendix A. Relevant Topics to IPWAVE Working Group 1276 This section discusses topics relevant to IPWAVE WG: (i) vehicle 1277 identity management; (ii) multihop V2X; (iii) multicast; (iv) DNS 1278 naming services and service discovery; (v) IPv6 over cellular 1279 networks. 1281 A.1. Vehicle Identity Management 1283 A vehicle can have multiple network interfaces using different access 1284 network technologies [Identity-Management]. These multiple network 1285 interfaces mean multiple identities. To identify a vehicle with 1286 multiple indenties, a Vehicle Identification Number (VIN) can be used 1287 as a globally unique vehicle identifier. 1289 To support the seamless connectivity over the multiple identities, a 1290 cross-layer network architecture is required with vertical handover 1291 functionality [Identity-Management]. Also, an AAA service for 1292 multiple identities should be provided to vehicles in an efficient 1293 way to allow horizontal handover as well as vertical handover; note 1294 that AAA stands for Authentication, Authorization, and Accounting. 1296 A.2. Multihop V2X 1298 Multihop packet forwarding among vehicles in 802.11-OCB mode shows an 1299 unfavorable performance due to the common known broadcast-storm 1300 problem [Broadcast-Storm]. This broadcast-storm problem can be 1301 mitigated by the coordination (or scheduling) of a cluster head in a 1302 connected VANET or an RSU in an intersection area, where the cluster 1303 head can work as a coodinator for the access to wireless channels. 1305 A.3. Multicast 1307 IP multicast in vehicular network environments is especially useful 1308 for various services. For instance, an automobile manufacturer can 1309 multicast a particular group/class/type of vehicles for service 1310 notification. As another example, a vehicle or an RSU can 1311 disseminate alert messages in a particular area [Multicast-Alert]. 1313 In general IEEE 802 wireless media, some performance issues about 1314 multicast are found in [Multicast-802]. Since several procedures and 1315 functions based on IPv6 use multicast for control-plane messages, 1316 such as Neighbor Discovery (ND) and Service Discovery, 1317 [Multicast-802] describes that the ND process may fail due to 1318 unreliable wireless link, causing failure of the DAD process. Also, 1319 the Router Advertisement messages can be lost in multicasting. 1321 A.4. DNS Naming Services and Service Discovery 1323 When two vehicular nodes communicate with each other using the DNS 1324 name of the partner node, DNS naming service (i.e., DNS name 1325 resolution) is required. As shown in Figure 2 and Figure 3, a 1326 recursive DNS server (RDNSS) within an internal network can perform 1327 such DNS name resolution for the sake of other vehicular nodes. 1329 A service discovery service is required for an application in a 1330 vehicular node to search for another application or server in another 1331 vehicular node, which resides in either the same internal network or 1332 the other internal network. In V2I or V2V networking, as shown in 1333 Figure 2 and Figure 3, such a service discovery service can be 1334 provided by either DNS-based Service Discovery (DNS-SD) [RFC6763] 1335 with mDNS [RFC6762] or the vehicular ND with a new option for service 1336 discovery [ID-Vehicular-ND][ID-VND-Discovery]. 1338 A.5. IPv6 over Cellular Networks 1340 Recently, 3GPP has announced a set of new technical specifications, 1341 such as Release 14 (3GPP-R14), which proposes an architecture 1342 enhancements for V2X services using the modified sidelink interface 1343 that originally is designed for the LTE-D2D communications. 3GPP-R14 1344 specifies that the V2X services only support IPv6 implementation. 1345 3GPP is also investigating and discussing the evolved V2X services in 1346 the next generation cellular networks, i.e., 5G new radio (5G-NR), 1347 for advanced V2X communications and automated vehicles' applications. 1349 A.5.1. Cellular V2X (C-V2X) Using 4G-LTE 1351 Before 3GPP-R14, some researchers have studied the potential usage of 1352 C-V2X communications. For example, [VMaSC-LTE] explores a multihop 1353 cluster-based hybrid architecture using both DSRC and LTE for safety 1354 message dissemination. Most of the research considers a short 1355 message service for safety instead of IP datagram forwarding. In 1356 other C-V2X research, the standard IPv6 is assumed. 1358 The 3GPP technical specification [TS-23.285-3GPP] states that both IP 1359 based and non-IP based V2X messages are supported, and only IPv6 is 1360 supported for IP based messages. Moreover, [TS-23.285-3GPP] 1361 instructs that a UE autoconfigures a link-local IPv6 address by 1362 following [RFC4862], but without sending Neighbor Solicitation and 1363 Neighbor Advertisement messages for DAD. This is because a unique 1364 prefix is allocated to each node by the 3GPP network, so the IPv6 1365 addresses cannot be duplicate. 1367 A.5.2. Cellular V2X (C-V2X) Using 5G 1369 The emerging services, functions, and applications, which are 1370 developped in automotive industry, demand reliable and efficient 1371 communication infrastructure for road networks. Correspondingly, the 1372 support of enhanced V2X (eV2X)-based services by future converged and 1373 interoperable 5G systems is required. The 3GPP Technical Report 1374 [TR-22.886-3GPP] is studying new use cases and the corresponding 1375 service requirements for V2X (including V2V and V2I) using 5G in both 1376 infrastructure mode and the sidelink variations in the future. 1378 Appendix B. Changes from draft-ietf-ipwave-vehicular-networking-06 1380 The following changes are made from draft-ietf-ipwave-vehicular- 1381 networking-06: 1383 o In Figure 1, a vehicular network architecture is modified to show 1384 a vehicular link model in a multi-link subnet with vehicular 1385 wireless links. 1387 o In Section 5.1, a Vehicular Neighbor Discovery (VND) 1388 [ID-Vehicular-ND] is introduced along with a vehicular link model 1389 in a multi-link subnet. In such a subnet, the description of MAC 1390 Address Pseudonym, Prefix Dissemination/Exchange, and Routing is 1391 clarified. 1393 o In Section 5.2, a proactive handover is introduced for an 1394 efficient mobility management with the cooperation among vehicles, 1395 RSUs, and MA along with link-layer parameters, such as Received 1396 Channel Power Indicator (RCPI). 1398 Appendix C. Acknowledgments 1400 This work was supported by Basic Science Research Program through the 1401 National Research Foundation of Korea (NRF) funded by the Ministry of 1402 Education (2017R1D1A1B03035885). 1404 This work was supported in part by Global Research Laboratory Program 1405 through the NRF funded by the Ministry of Science and ICT (MSIT) 1406 (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT 1407 (18-EE-01). 1409 This work was supported in part by the French research project 1410 DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded 1411 by the European Commission I (636537-H2020). 1413 Appendix D. Contributors 1415 This document is a group work of IPWAVE working group, greatly 1416 benefiting from inputs and texts by Rex Buddenberg (Naval 1417 Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest 1418 University of Technology and Economics), Jose Santa Lozanoi 1419 (Universidad of Murcia), Richard Roy (MIT), Francois Simon (Pilot), 1420 Sri Gundavelli (Cisco), Erik Nordmark, and Dirk von Hugo (Deutsche 1421 Telekom). The authors sincerely appreciate their contributions. 1423 The following are co-authors of this document: 1425 Nabil Benamar 1426 Department of Computer Sciences 1427 High School of Technology of Meknes 1428 Moulay Ismail University 1429 Morocco 1431 Phone: +212 6 70 83 22 36 1432 EMail: benamar73@gmail.com 1434 Sandra Cespedes 1435 NIC Chile Research Labs 1436 Universidad de Chile 1437 Av. Blanco Encalada 1975 1438 Santiago 1439 Chile 1441 Phone: +56 2 29784093 1442 EMail: scespede@niclabs.cl 1444 Jerome Haerri 1445 Communication Systems Department 1446 EURECOM 1447 Sophia-Antipolis 1448 France 1450 Phone: +33 4 93 00 81 34 1451 EMail: jerome.haerri@eurecom.fr 1453 Dapeng Liu 1454 Alibaba 1455 Beijing, Beijing 100022 1456 China 1457 Phone: +86 13911788933 1458 EMail: max.ldp@alibaba-inc.com 1460 Tae (Tom) Oh 1461 Department of Information Sciences and Technologies 1462 Rochester Institute of Technology 1463 One Lomb Memorial Drive 1464 Rochester, NY 14623-5603 1465 USA 1467 Phone: +1 585 475 7642 1468 EMail: Tom.Oh@rit.edu 1470 Charles E. Perkins 1471 Futurewei Inc. 1472 2330 Central Expressway 1473 Santa Clara, CA 95050 1474 USA 1476 Phone: +1 408 330 4586 1477 EMail: charliep@computer.org 1479 Alexandre Petrescu 1480 CEA, LIST 1481 CEA Saclay 1482 Gif-sur-Yvette, Ile-de-France 91190 1483 France 1485 Phone: +33169089223 1486 EMail: Alexandre.Petrescu@cea.fr 1488 Yiwen Chris Shen 1489 Department of Computer Science & Engineering 1490 Sungkyunkwan University 1491 2066 Seobu-Ro, Jangan-Gu 1492 Suwon, Gyeonggi-Do 16419 1493 Republic of Korea 1495 Phone: +82 31 299 4106 1496 Fax: +82 31 290 7996 1497 EMail: chrisshen@skku.edu 1498 URI: http://iotlab.skku.edu/people-chris-shen.php 1499 Michelle Wetterwald 1500 FBConsulting 1501 21, Route de Luxembourg 1502 Wasserbillig, Luxembourg L-6633 1503 Luxembourg 1505 EMail: Michelle.Wetterwald@gmail.com 1507 Author's Address 1509 Jaehoon Paul Jeong (editor) 1510 Department of Software 1511 Sungkyunkwan University 1512 2066 Seobu-Ro, Jangan-Gu 1513 Suwon, Gyeonggi-Do 16419 1514 Republic of Korea 1516 Phone: +82 31 299 4957 1517 Fax: +82 31 290 7996 1518 EMail: pauljeong@skku.edu 1519 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php