idnits 2.17.1 draft-ietf-ipwave-vehicular-networking-06.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 (October 22, 2018) is 2013 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Online' is mentioned on line 1146, 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 October 22, 2018 5 Expires: April 25, 2019 7 IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement 8 and Use Cases 9 draft-ietf-ipwave-vehicular-networking-06 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 April 25, 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 . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . 15 80 4.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 15 81 4.2.4. Pseudonym Handling . . . . . . . . . . . . . . . . . 15 82 5. Problem Exploration . . . . . . . . . . . . . . . . . . . . . 16 83 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 16 84 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 16 85 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 17 86 5.1.3. Prefix Dissemination/Exchange . . . . . . . . . . . . 17 87 5.1.4. Routing . . . . . . . . . . . . . . . . . . . . . . . 17 88 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 17 89 5.3. Security and Privacy . . . . . . . . . . . . . . . . . . 18 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 91 7. Informative References . . . . . . . . . . . . . . . . . . . 19 92 Appendix A. Relevant Topics to IPWAVE Working Group . . . . . . 27 93 A.1. Vehicle Identity Management . . . . . . . . . . . . . . . 27 94 A.2. Multihop V2X . . . . . . . . . . . . . . . . . . . . . . 27 95 A.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 27 96 A.4. DNS Naming Services and Service Discovery . . . . . . . . 28 97 A.5. IPv6 over Cellular Networks . . . . . . . . . . . . . . . 28 98 A.5.1. Cellular V2X (C-V2X) Using 4G-LTE . . . . . . . . . . 28 99 A.5.2. Cellular V2X (C-V2X) Using 5G . . . . . . . . . . . . 29 100 Appendix B. Changes from draft-ietf-ipwave-vehicular- 101 networking-05 . . . . . . . . . . . . . . . . . . . 29 102 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 29 103 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 29 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 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 Vehicular Cloud: A cloud infrastructure for vehicular networks, 198 having compute nodes, storage nodes, and network nodes. 200 o Traffic Control Center (TCC): A node that maintains road 201 infrastructure information (e.g., RSUs, traffic signals, and loop 202 detectors), vehicular traffic statistics (e.g., average vehicle 203 speed and vehicle inter-arrival time per road segment), and 204 vehicle information (e.g., a vehicle's identifier, position, 205 direction, speed, and trajectory as a navigation path). TCC is 206 included in a vehicular cloud for vehicular networks. 208 3. Use Cases 210 This section provides use cases of V2V, V2I, and V2X networking. The 211 use cases of the V2X networking exclude the ones of the V2V and V2I 212 networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to- 213 Device (V2D). 215 3.1. V2V 217 The use cases of V2V networking discussed in this section include 219 o Context-aware navigation for driving safety and collision 220 avoidance; 222 o Cooperative adaptive cruise control in an urban roadway; 224 o Platooning in a highway; 226 o Cooperative environment sensing. 228 These four techniques will be important elements for self-driving 229 vehicles. 231 Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers 232 to drive safely by letting the drivers recognize dangerous obstacles 233 and situations. That is, CASD navigator displays obstables or 234 neighboring vehicles relevant to possible collisions in real-time 235 through V2V networking. CASD provides vehicles with a class-based 236 automatic safety action plan, which considers three situations, such 237 as the Line-of-Sight unsafe, Non-Line-of-Sight unsafe and safe 238 situations. This action plan can be performed among vehicles through 239 V2V networking. 241 Cooperative Adaptive Cruise Control (CACC) [CA-Cruise-Control] helps 242 vehicles to adapt their speed autonomously through V2V communication 243 among vehicles according to the mobility of their predecessor and 244 successor vehicles in an urban roadway or a highway. CACC can help 245 adjacent vehicles to efficiently adjust their speed in a cascade way 246 through V2V networking. 248 Platooning [Truck-Platooning] allows a series of vehicles (e.g., 249 trucks) to move together with a very short inter-distance. Trucks 250 can use V2V communication in addition to forward sensors in order to 251 maintain constant clearance between two consecutive vehicles at very 252 short gaps (from 3 meters to 10 meters). This platooning can 253 maximize the throughput of vehicular traffic in a highway and reduce 254 the gas consumption because the leading vehicle can help the 255 following vehicles to experience less air resistance. 257 Cooperative-environment-sensing use cases suggest that vehicles can 258 share environmental information from various vehicle-mounted sensors, 259 such as radars, LiDARs and cameras with other vehicles and 260 pedestrians. [Automotive-Sensing] introduces a millimeter-wave 261 vehicular communication for massive automotive sensing. Data 262 generated by those sensors can be substantially large, and these data 263 shall be routed to different destinations. In addition, from the 264 perspective of driverless vehicles, it is expected that driverless 265 vehicles can be mixed with driver-operated vehicles. Through 266 cooperative environment sensing, driver-operated vehicles can use 267 environmental information sensed by driverless vehicles for better 268 interaction with the context. 270 3.2. V2I 272 The use cases of V2I networking discussed in this section include 274 o Navigation service; 276 o Energy-efficient speed recommendation service; 278 o Accident notification service. 280 A navigation service, such as the Self-Adaptive Interactive 281 Navigation Tool (called SAINT) [SAINT], using V2I networking 282 interacts with TCC for the large-scale/long-range road traffic 283 optimization and can guide individual vehicles for appropriate 284 navigation paths in real time. The enhanced SAINT (called SAINT+) 285 [SAINTplus] can give the fast moving paths for emergency vehicles 286 (e.g., ambulance and fire engine) toward accident spots while 287 providing other vehicles with efficient detour paths. 289 A TCC can recommend an energy-efficient speed to a vehicle driving in 290 different traffic environments. [Fuel-Efficient] studies fuel- 291 efficient route and speed plans for platooned trucks. 293 The emergency communication between accident vehicles (or emergency 294 vehicles) and TCC can be performed via either RSU or 4G-LTE networks. 295 The First Responder Network Authority (FirstNet) [FirstNet] is 296 provided by the US government to establish, operate, and maintain an 297 interoperable public safety broadband network for safety and security 298 network services, such as emergency calls. The construction of the 299 nationwide FirstNet network requires each state in the US to have a 300 Radio Access Network (RAN) that will connect to FirstNet's network 301 core. The current RAN is mainly constructed by 4G-LTE for the 302 communication between a vehicle and an infrastructure node (i.e., 303 V2I) [FirstNet-Report], but it is expected that DSRC-based vehicular 304 networks [DSRC] will be available for V2I and V2V in near future. 306 3.3. V2X 308 The use case of V2X networking discussed in this section is 309 pedestrian protection service. 311 A pedestrian protection service, such as Safety-Aware Navigation 312 Application (called SANA) [SANA], using V2I2P networking can reduce 313 the collision of a vehicle and a pedestrian carrying a smartphone 314 equipped with the access technology with an RSU (e.g., WiFi). 315 Vehicles and pedestrians can also communicate with each other via an 316 RSU that delivers scheduling information for wireless communication 317 in order to save the smartphones' battery through sleeping mode. 319 For Vehicle-to-Pedestrian (V2P), a vehicle and a pedestrian's 320 smartphone can directly communicate with each other via V2X without 321 the relaying of an RSU as in a V2V scenario such that the 322 pedestrian's smartphone is regarded as a vehicle with a wireless 323 media interface to be able to communicate with another vehicle. In 324 Vehicle-to-Device (V2D), a device can be a mobile node such as 325 bicycle and motorcycle, and can communicate directly with a vehicle 326 for collision avoidance. 328 4. Analysis for Existing Protocols 329 4.1. Existing Protocols for Vehicular Networking 331 We describe some currently existing protocols and proposed solutions 332 with respect to the following aspects that are relevant and essential 333 for vehicular networking: 335 o IPv6 over 802.11-OCB; 337 o IP address autoconfiguration; 339 o Routing; 341 o Mobility management; 343 o DNS naming service; 345 o Service discovery; 347 o Security and privacy. 349 4.1.1. IPv6 over 802.11-OCB 351 For IPv6 packets transporting over IEEE 802.11-OCB, 352 [IPv6-over-802.11-OCB] specifies several details, such as Maximum 353 Transmission Unit (MTU), frame format, link-local address, address 354 mapping for unicast and multicast, stateless autoconfiguration, and 355 subnet structure. Especially, an Ethernet Adaptation (EA) layer is 356 in charge of transforming some parameters between IEEE 802.11 MAC 357 layer and IPv6 network layer, which is located between IEEE 358 802.11-OCB's logical link control layer and IPv6 network layer. 360 4.1.2. IP Address Autoconfiguration 362 For IP address autoconfiguration, Fazio et al. proposed a vehicular 363 address configuration (VAC) scheme using DHCP where elected leader- 364 vehicles provide unique identifiers for IP address configurations in 365 vehicles [Address-Autoconf]. Kato et al. proposed an IPv6 address 366 assignment scheme using lane and position information 367 [Address-Assignment]. Baldessari et al. proposed an IPv6 scalable 368 address autoconfiguration scheme called GeoSAC for vehicular networks 369 [GeoSAC]. Wetterwald et al. conducted for heterogeneous vehicular 370 networks (i.e., employing multiple access technologies) a 371 comprehensive study of the cross-layer identities management, which 372 constitutes a fundamental element of the ITS architecture 373 [Identity-Management]. 375 4.1.3. Routing 377 For routing, Tsukada et al. presented a work that aims at combining 378 IPv6 networking and a Car-to-Car Network routing protocol (called 379 C2CNet) proposed by the Car2Car Communication Consortium (C2C-CC), 380 which is an architecture using a geographic routing protocol 381 [VANET-Geo-Routing]. Abrougui et al. presented a gateway discovery 382 scheme for VANET, called Location-Aided Gateway Advertisement and 383 Discovery (LAGAD) mechanism [LAGAD]. 385 4.1.4. Mobility Management 387 For mobility management, Chen et al. tackled the issue of network 388 fragmentation in VANET environments [IP-Passing-Protocol] by 389 proposing a protocol that can postpone the time to release IP 390 addresses to the DHCP server and select a faster way to get the 391 vehicle's new IP address, when the vehicle density is low or the 392 speeds of vehicles are highly variable. Nguyen et al. proposed a 393 hybrid centralized-distributed mobility management called H-DMM to 394 support highly mobile vehicles [H-DMM]. [NEMO-LMS] proposed an 395 architecture to enable IP mobility for moving networks using a 396 network-based mobility scheme based on PMIPv6. Chen et al. proposed 397 a network mobility protocol to reduce handoff delay and maintain 398 Internet connectivity to moving vehicles in a highway [NEMO-VANET]. 399 Lee et al. proposed P-NEMO, which is a PMIPv6-based IP mobility 400 management scheme to maintain the Internet connectivity at the 401 vehicle as a mobile network, and provides a make-before-break 402 mechanism when vehicles switch to a new access network 403 [PMIP-NEMO-Analysis]. Peng et al. proposed a novel mobility 404 management scheme for integration of VANET and fixed IP networks 405 [VNET-MM]. Nguyen et al. extended their previous works on a 406 vehicular adapted DMM considering a Software-Defined Networking (SDN) 407 architecture [SDN-DMM]. 409 4.1.5. DNS Naming Service 411 For DNS naming service, Multicast DNS (mDNS) [RFC6762] allows devices 412 in one-hop communication range to resolve each other's DNS name into 413 the corresponding IP address in multicast. DNS Name 414 Autoconfiguration (DNSNA) [ID-DNSNA] proposes a DNS naming service 415 for Internet-of-Things (IoT) devices in a large-scale network. 417 4.1.6. Service Discovery 419 To discover instances of a demanded service in vehicular networks, 420 DNS-based Service Discovery (DNS-SD) [RFC6763] with either DNSNA 421 [ID-DNSNA] or mDNS [RFC6762] provides vehicles with service discovery 422 by using standard DNS queries. Vehicular ND [ID-Vehicular-ND] 423 proposes an extension of IPv6 ND for the prefix and service 424 discovery. Note that a DNS query for service discovery is unicasted 425 in DNSNA, but it is multicasted in both mDNS and Vehicular ND. 427 4.1.7. Security and Privacy 429 For security and privacy, Fernandez et al. proposed a secure 430 vehicular IPv6 communication scheme using Internet Key Exchange 431 version 2 (IKEv2) and Internet Protocol Security (IPsec) 432 [Securing-VCOMM]. Moustafa et al. proposed a security scheme 433 providing authentication, authorization, and accounting (AAA) 434 services in vehicular networks [VNET-AAA]. 436 *-------------* 437 * * +-------+ 438 * Vehicular Cloud *<------>| TCC | 439 * * +_______+ 440 *-------------* 441 ^ ^ 442 | | 443 | | 444 v v 445 +--------+ Ethernet +--------+ 446 | RSU1 |<----------->| RSU2 | 447 +________+ +________+ 448 ^ ^ ^ 449 : : : 450 V2I : : V2I V2I : 451 v v v 452 +--------+ +--------+ +--------+ 453 |Vehicle1|==> |Vehicle2|==> |Vehicle3|==> 454 | |<....>| |<....>| | 455 +________+ V2V +________+ V2V +________+ 457 <----> Wired Link <....> Wireless Link ==> Moving Direction 459 Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 461 4.2. General Problems 463 This section describes a possible vehicular network architecture for 464 V2V, V2I, and V2X communications. Then it analyzes the limitations 465 of the current protocols for vehicular networking. 467 4.2.1. Vehicular Network Architecture 469 Figure 1 shows a possible architecture for V2I and V2V networking in 470 a road network. It is assumed that RSUs as routers and vehicles with 471 OBU have wireless media interfaces (e.g., IEEE 802.11-OCB, LTE Uu and 472 Device-to-Device (D2D) (also known as PC5 [TS-23.285-3GPP]), 473 Bluetooth, and Light Fidelity (Li-Fi)) for V2I and V2V communication. 474 Also, it is assumed that such the wireless media interfaces are 475 autoconfigured with a global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to 476 support both V2V and V2I networking. The two RSUs (RSU1 and RSU2) 477 are deployed in the road network and are connected to a Vehicular 478 Cloud through the Internet. TCC is connected to the Vehicular Cloud 479 and the two vehicles (Vehicle1 and Vehicle2) are wirelessly connected 480 to RSU1, and the last vehicle (Vehicle3) is wirelessly connected to 481 RSU2. Vehicle1 can communicate with Vehicle2 via V2V communication, 482 and Vehicle2 can communicate with Vehicle3 via V2V communication. 483 Vehicle1 can communicate with Vehicle3 via RSU1 and RSU2 employing 484 V2I (i.e., V2I2V) communication. 486 In vehicular networks, unidirectional links exist and must be 487 considered for wireless communications. Also, in the vehicular 488 networks, control plane must be separated from data plane for 489 efficient mobility management and data forwarding using Software- 490 Defined Networking (SDN) [SDN-DMM]. ID/Pseudonym change for privacy 491 requires a lightweight DAD. IP tunneling over the wireless link 492 should be avoided for performance efficiency. The mobility 493 information of a mobile (e.g., vehicle-mounted) device through a GPS 494 receiver in its vehicle, such as trajectory, position, speed, and 495 direction, can be used by the mobile device and infrastructure nodes 496 (e.g., TCC and RSU) for the accommodation of mobility-aware proactive 497 protocols. Vehicles can use the TCC as their Home Network having a 498 home agent for mobility management as in MIPv6 [RFC6275] and Proxy 499 Mobile IPv6 (PMIPv6) [RFC5213], so the TCC maintains the mobility 500 information of vehicles for location management. 502 Cespedes et al. proposed a vehicular IP in WAVE called VIP-WAVE for 503 I2V and V2I networking [VIP-WAVE]. The standard WAVE does not 504 support both seamless communications for Internet services and multi- 505 hop communications between a vehicle and an infrastructure node 506 (e.g., RSU), either. To overcome these limitations of the standard 507 WAVE, VIP-WAVE enhances the standard WAVE by the following three 508 schemes: (i) an efficient mechanism for the IPv6 address assignment 509 and DAD, (ii) on-demand IP mobility based on PMIPv6 [RFC5213], and 510 (iii) one-hop and two-hop communications for I2V and V2I networking. 512 Baccelli et al. provided an analysis of the operation of IPv6 as it 513 has been described by the IEEE WAVE standards 1609 [IPv6-WAVE]. This 514 analysis confirms that the use of the standard IPv6 protocol stack in 515 WAVE is not sufficient. It recommends that the IPv6 addressing 516 assignment should follow considerations for ad-hoc link models, 517 defined in [RFC5889] for nodes' mobility and link variability. 519 Petrescu et al. proposed the joint IP networking and radio 520 architecture for V2V and V2I communication in [Joint-IP-Networking]. 521 The proposed architecture considers an IP topology in a similar way 522 as a radio link topology, in the sense that an IP subnet would 523 correspond to the range of 1-hop vehicular communication. This 524 architecture defines three types of vehicles: Leaf Vehicle, Range 525 Extending Vehicle, and Internet Vehicle. 527 +----------------+ 528 (*)<........>(*) +----->| Vehicular Cloud| 529 2001:DB8:1:1::/64 | | | +----------------+ 530 +------------------------------+ +---------------------------------+ 531 | v | | v v | 532 | .-------. .------. .-------. | | .-------. .------. .-------. | 533 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 534 | ._______. .______. ._______. | | ._______. .______. ._______. | 535 | ^ ^ ^ | | ^ ^ ^ | 536 | | | | | | | | | | 537 | v v v | | v v v | 538 | ---------------------------- | | ------------------------------- | 539 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 540 | | | | | | 541 | v | | v | 542 | .-------. .-------. | | .-------. .-------. .-------. | 543 | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | 544 | ._______. ._______. | | ._______. ._______. ._______. | 545 | ^ ^ | | ^ ^ ^ | 546 | | | | | | | | | 547 | v v | | v v v | 548 | ---------------------------- | | ------------------------------- | 549 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 550 +______________________________+ +_________________________________+ 551 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 553 <----> Wired Link <....> Wireless Link (*) Antenna 555 Figure 2: Internetworking between Vehicle Network and RSU Network 557 4.2.1.1. V2I-based Internetworking 559 This section discusses the internetworking between a vehicle's moving 560 network and an RSU's fixed network via V2I communication. 562 As shown in Figure 2, the vehicle's moving network and the RSU's 563 fixed network are self-contained networks having multiple subnets and 564 having an edge router for the communication with another vehicle or 565 RSU. The method of prefix assignment for each subnet inside the 566 vehicle's mobile network and the RSU's fixed network is out of scope 567 for this document. Internetworking between two internal networks via 568 V2I communication requires an exchange of network prefix and other 569 parameters through a prefix discovery mechanism, such as ND-based 570 prefix discovery [ID-Vehicular-ND]. For the ND-based prefix 571 discovery, network prefixs and parameters should be registered into a 572 vehicle's router and an RSU router with an external network interface 573 in advance. 575 The network parameter discovery collects networking information for 576 an IP communication between a vehicle and an RSU or between two 577 neighboring vehicles, such as link layer, MAC layer, and IP layer 578 information. The link layer information includes wireless link layer 579 parameters, such as wireless media (e.g., IEEE 802.11-OCB, LTE Uu and 580 D2D, Bluetooth, and LiFi) and a transmission power level. Note that 581 LiFi is a technology for light-based wireless communication between 582 devices in order to transmit both data and position. The MAC layer 583 information includes the MAC address of an external network interface 584 for the internetworking with another vehicle or RSU. The IP layer 585 information includes the IP address and prefix of an external network 586 interface for the internetworking with another vehicle or RSU. 588 Once the network parameter discovery and prefix exchange operations 589 have been performed, packets can be transmitted between the vehicle's 590 moving network and the RSU's fixed network. DNS services should be 591 supported to enable name resolution for hosts or servers residing 592 either in the vehicle's moving network or the RSU's fixed network. 593 It is assumed that the DNS names of in-vehicle devices and their 594 service names are registered into a DNS server (i.e., recursive DNS 595 server called RDNSS) in a vehicle or an RSU, as shown in Figure 2. 596 For service discovery, those DNS names and service names can be 597 advertised to neighboring vehicles through either DNS-based service 598 discovery mechanisms [RFC6762][RFC6763][ID-DNSNA] and ND-based 599 service discovery [ID-Vehicular-ND]. For the ND-based service 600 discovery, service names should be registered into a vehicle's router 601 and an RSU router with an external network interface in advance. 602 Refer to Section 4.1.5 and Section 4.1.6 for detailed information. 603 For these DNS services, an RDNSS within each internal network of a 604 vehicle or RSU can be used for the hosts or servers. 606 Figure 2 shows internetworking between the vehicle's moving network 607 and the RSU's fixed network. There exists an internal network 608 (Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server 609 (RDNSS1), the two hosts (Host1 and Host2), and the two routers 610 (Router1 and Router2). There exists another internal network (Fixed 611 Network1) inside RSU1. RSU1 has the DNS Server (RDNSS2), one host 612 (Host3), the two routers (Router3 and Router4), and the collection of 613 servers (Server1 to ServerN) for various services in the road 614 networks, such as the emergency notification and navigation. 615 Vehicle1's Router1 (called mobile router) and RSU1's Router3 (called 616 fixed router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) 617 for I2V networking. 619 (*)<..........>(*) 620 2001:DB8:1:1::/64 | | 621 +------------------------------+ +---------------------------------+ 622 | v | | v | 623 | .-------. .------. .-------. | | .-------. .------. .-------. | 624 | | Host1 | |RDNSS1| |Router1| | | |Router5| |RDNSS3| | Host4 | | 625 | ._______. .______. ._______. | | ._______. .______. ._______. | 626 | ^ ^ ^ | | ^ ^ ^ | 627 | | | | | | | | | | 628 | v v v | | v v v | 629 | ---------------------------- | | ------------------------------- | 630 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:30:1::/64 | 631 | | | | | | 632 | v | | v | 633 | .-------. .-------. | | .-------. .-------. | 634 | | Host2 | |Router2| | | |Router6| | Host5 | | 635 | ._______. ._______. | | ._______. ._______. | 636 | ^ ^ | | ^ ^ | 637 | | | | | | | | 638 | v v | | v v | 639 | ---------------------------- | | ------------------------------- | 640 | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | 641 +______________________________+ +_________________________________+ 642 Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) 644 <----> Wired Link <....> Wireless Link (*) Antenna 646 Figure 3: Internetworking between Two Vehicle Networks 648 4.2.1.2. V2V-based Internetworking 650 This section discusses the internetworking between the moving 651 networks of two neighboring vehicles via V2V communication. 653 Figure 3 shows internetworking between the moving networks of two 654 neighboring vehicles. There exists an internal network (Moving 655 Network1) inside Vehicle1. Vehicle1 has the DNS Server (RDNSS1), the 656 two hosts (Host1 and Host2), and the two routers (Router1 and 657 Router2). There exists another internal network (Moving Network2) 658 inside Vehicle2. Vehicle2 has the DNS Server (RDNSS3), the two hosts 659 (Host4 and Host5), and the two routers (Router5 and Router6). 660 Vehicle1's Router1 (called mobile router) and Vehicle2's Router5 661 (called mobile router) use 2001:DB8:1:1::/64 for an external link 662 (e.g., DSRC) for V2V networking. 664 The differences between IPWAVE (including Vehicular Ad Hoc Networks 665 (VANET)) and Mobile Ad Hoc Networks (MANET) are as follows: 667 o IPWAVE is not power-constrained operation; 669 o Traffic can be sourced or sinked outside of IPWAVE; 671 o IPWAVE shall support both distributed and centralized operations; 673 o No "sleep" period operation is required for energy saving. 675 4.2.2. Latency 677 The communication delay (i.e., latency) between two vehicular nodes 678 (vehicle and RSU) should be bounded to a certain threshold. For IP- 679 based safety applications (e.g., context-aware navigation, adaptive 680 cruise control, and platooning) in vehicular network, this bounded 681 data delivery is critical. The real implementations for such 682 applications are not available, so the feasibility of IP-based safety 683 applications is not tested yet. 685 4.2.3. Security 687 Strong security measures shall protect vehicles roaming in road 688 networks from the attacks of malicious nodes, which are controlled by 689 hackers. For safety applications, the cooperation among vehicles is 690 assumed. Malicious nodes may disseminate wrong driving information 691 (e.g., location, speed, and direction) to make driving be unsafe. 692 Sybil attack, which tries to illude a vehicle with multiple false 693 identities, disturbs a vehicle in taking a safe maneuver. 694 Applications on IP-based vehicular networking, which are resilient to 695 such a sybil attack, are not developed and tested yet. 697 4.2.4. Pseudonym Handling 699 For the protection of drivers' privacy, pseudonym for a vehicle's 700 network interface should be used, with the help of which the 701 interface's identifier can be changed periodically. Such a pseudonym 702 affects an IPv6 address based on the network interface's identifier, 703 and a transport-layer (e.g., TCP) session with an IPv6 address pair. 704 The pseudonym handling is not implemented and tested yet for 705 applications on IP-based vehicular networking. 707 5. Problem Exploration 709 This section discusses key topics for IPWAVE WG, such as neighbor 710 discovery, mobility management, and security & privacy. 712 5.1. Neighbor Discovery 714 Neighbor Discovery (ND) [RFC4861] is a core part of the IPv6 protocol 715 suite. This section discusses the need for modifying ND for use with 716 vehicular networking (e.g., V2V, V2I, and V2X). The vehicles are 717 moving fast within the communication coverage of a vehicular node 718 (e.g., vehicle and RSU). The external wireless link between two 719 vehicular nodes can be used for vehicular networking, as shown in 720 Figure 2 and Figure 3. 722 ND time-related parameters such as router lifetime and Neighbor 723 Advertisement (NA) interval should be adjusted for high-speed 724 vehicles and vehicle density. As vehicles move faster, the NA 725 interval should decrease for the NA messages to reach the neighboring 726 vehicles promptly. Also, as vehicle density is higher, the NA 727 interval should increase for the NA messages to reduce collision 728 probability with other NA messages. 730 5.1.1. Link Model 732 IPv6 protocols work under certain assumptions for the link model that 733 do not necessarily hold in WAVE [IPv6-WAVE]. For instance, some IPv6 734 protocols assume symmetry in the connectivity among neighboring 735 interfaces. However, interference and different levels of 736 transmission power may cause unidirectional links to appear in a WAVE 737 link model. 739 There is a relationship between a link and prefix, besides the 740 different scopes that are expected from the link-local and global 741 types of IPv6 addresses. In an IPv6 link, it is assumed that all 742 interfaces which are configured with the same subnet prefix and with 743 on-link bit set can communicate with each other on an IP link or 744 extended IP links via ND proxy. Note that a subnet prefix can be 745 used by spanning multiple links as a multi-link subnet [RFC6775]. 746 Also, note that IPv6 Stateless Address Autoconfiguration can be 747 performed in the multiple links where each of them is not assigned 748 with a unique subnet prefix, that is, all of them are configured with 749 the same subnet prefix [RFC4861][RFC4862]. A WAVE link model needs 750 to consider a multi-hop VANET over a multi-link subnet. Such a VANET 751 is usually a multi-link subnet consisting of multiple vehicles 752 interconnected by wireless communication range. Such a subnet has a 753 highly dynamic topology over time due to node mobility. 755 Thus, IPv6 ND should be extended to support the concept of an IPv6 756 link corresponding to an IPv6 prefix even in a multi-link subnet 757 consisting of multiple vehicles and RSUs that are interconnected with 758 wireless communication range in vehicular networks. 760 5.1.2. MAC Address Pseudonym 762 In the ETSI standards, for the sake of security and privacy, an ITS 763 station (e.g., vehicle) can use pseudonyms for its network interface 764 identities (e.g., MAC address) and the corresponding IPv6 addresses 765 [Identity-Management]. Whenever the network interface identifier 766 changes, the IPv6 address based on the network interface identifier 767 should be updated. For the continuity of an end-to-end (E2E) 768 transport-layer (e.g., TCP, UDP, and SCTP) session, the new IP 769 addresses of the transport-layer session should be notified to both 770 the end points and the packets of the session should be forwarded to 771 their destinations with the changed network interface identifier and 772 IPv6 address. 774 5.1.3. Prefix Dissemination/Exchange 776 A vehicle and an RSU can have their internal network, as shown in 777 Figure 2 and Figure 3. In this case, nodes in within the internal 778 networks of two vehicular nodes (e.g., vehicle and RSU) want to 779 communicate with each other. For this communication on the wireless 780 link, the network prefix dissemination or exchange is required. It 781 is assumed that a vehicular node has an external network interface 782 and its internal network. The standard IPv6 ND needs to be extended 783 for the communication between the internal-network vehicular nodes by 784 letting each of them know the other side's prefix with a new ND 785 option [ID-Vehicular-ND]. Thus, this ND extension for routing 786 functionality can reduce control traffic for routing in vehicular 787 networks. 789 5.1.4. Routing 791 For Neighbor Discovery in vehicular networks (called vehicular ND), 792 Ad Hoc routing is required for either unicast or multicast in the 793 links in a connected VANET with the same IPv6 prefix [GeoSAC]. Also, 794 a rapid DAD should be supported to prevent or reduce IPv6 address 795 conflicts in a multi-link subnet for both V2V and V2I by using a DAD 796 optimization [RFC6775]. 798 5.2. Mobility Management 800 The seamless connectivity and timely data exchange between two end 801 points requires an efficient mobility management including location 802 management and handover. Most of vehicles are equipped with a GPS 803 receiver as part of a dedicated navigation system or a corresponding 804 smartphone App. In the case where the provided location information 805 is precise enough, well-known temporary degradations in precision may 806 occur due to system configuration or the adverse local environment. 807 This precision is improved thanks to assistance by the RSUs or a 808 cellular system with this navigation system. With this GPS 809 navigator, an efficient mobility management is possible by vehicles 810 periodically reporting their current position and trajectory (i.e., 811 navigation path) to TCC. TCC can predict the future positions of the 812 vehicles with their mobility information (i.e., the current position, 813 speed, direction, and trajectory) for location management. 815 With the prediction of the vehicle mobility, TCC can support RSUs to 816 perform DAD, data packet routing, horizontal handover (i.e., handover 817 in wireless links using a homogeneous radio technology), and vertical 818 handover (i.e., handover in wireless links using heterogeneous radio 819 technologies) in a proactive manner. When it is assigned a new IPv6 820 address belonging to a different subnet, a vehicle can skip the DAD 821 operation, reducing IPv6 control traffic overhead. RSUs can 822 efficiently forward data packets from the wired network to a moving 823 destination vehicle along its trajectory. RSUs can smoothly perform 824 handover for the sake of a moving vehicle along its trajectory. 826 5.3. Security and Privacy 828 Security and privacy are paramount in the V2I, V2V, and V2X 829 networking in vehicular networks. Only authorized vehicles should be 830 allowed to use vehicular networking. Also, in-vehicle devices and 831 mobile devices in a vehicle need to communicate with other in-vehicle 832 devices and mobile devices in another vehicle, and other servers in 833 an RSU in a secure way. 835 A Vehicle Identification Number (VIN) and a user certificate along 836 with in-vehicle device's identifier generation can be used to 837 efficiently authenticate a vehicle or a user through a road 838 infrastructure node (e.g., RSU) connected to an authentication server 839 in TCC. Also, Transport Layer Security (TLS) certificates can be 840 used for secure E2E vehicle communications. 842 For secure V2I communication, a secure channel between a mobile 843 router in a vehicle and a fixed router in an RSU should be 844 established, as shown in Figure 2. Also, for secure V2V 845 communication, a secure channel between a mobile router in a vehicle 846 and a mobile router in another vehicle should be established, as 847 shown in Figure 3. 849 To prevent an adversary from tracking a vehicle with its MAC address 850 or IPv6 address, MAC address pseudonym should be provided to the 851 vehicle; that is, each vehicle should periodically update its MAC 852 address and the corresponding IPv6 address as suggested in 853 [RFC4086][RFC4941]. Such an update of the MAC and IPv6 addresses 854 should not interrupt the E2E communications between two vehicular 855 nodes (e.g., vehicle and RSU) in terms of transport layer for a long- 856 living higher-layer session. However, if this pseudonym is performed 857 without strong E2E confidentiality, there will be no privacy benefit 858 from changing MAC and IP addresses, because an adversary can see the 859 change of the MAC and IP addresses and track the vehicle with those 860 addresses. 862 6. Security Considerations 864 This document discussed security and privacy for IP-based vehicular 865 networking. 867 The security and privacy for key components in IP-based vehicular 868 networking, such as neighbor discovery and mobility management, need 869 to be analyzed in depth. 871 7. Informative References 873 [Address-Assignment] 874 Kato, T., Kadowaki, K., Koita, T., and K. Sato, "Routing 875 and Address Assignment using Lane/Position Information in 876 a Vehicular Ad-hoc Network", IEEE Asia-Pacific Services 877 Computing Conference, December 2008. 879 [Address-Autoconf] 880 Fazio, M., Palazzi, C., Das, S., and M. Gerla, "Automatic 881 IP Address Configuration in VANETs", ACM International 882 Workshop on Vehicular Inter-Networking, September 2016. 884 [Automotive-Sensing] 885 Choi, J., Va, V., Gonzalez-Prelcic, N., Daniels, R., R. 886 Bhat, C., and R. W. Heath, "Millimeter-Wave Vehicular 887 Communication to Support Massive Automotive Sensing", 888 IEEE Communications Magazine, December 2016. 890 [Broadcast-Storm] 891 Wisitpongphan, N., K. Tonguz, O., S. Parikh, J., Mudalige, 892 P., Bai, F., and V. Sadekar, "Broadcast Storm Mitigation 893 Techniques in Vehicular Ad Hoc Networks", IEEE Wireless 894 Communications, December 2007. 896 [CA-Cruise-Control] 897 California Partners for Advanced Transportation Technology 898 (PATH), "Cooperative Adaptive Cruise Control", [Online] 899 Available: 900 http://www.path.berkeley.edu/research/automated-and- 901 connected-vehicles/cooperative-adaptive-cruise-control, 902 2017. 904 [CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A 905 Framework of Context-Awareness Safety Driving in Vehicular 906 Networks", International Workshop on Device Centric Cloud 907 (DC2), March 2016. 909 [DSRC] ASTM International, "Standard Specification for 910 Telecommunications and Information Exchange Between 911 Roadside and Vehicle Systems - 5 GHz Band Dedicated Short 912 Range Communications (DSRC) Medium Access Control (MAC) 913 and Physical Layer (PHY) Specifications", 914 ASTM E2213-03(2010), October 2010. 916 [ETSI-GeoNetwork-IP] 917 ETSI Technical Committee Intelligent Transport Systems, 918 "Intelligent Transport Systems (ITS); Vehicular 919 Communications; GeoNetworking; Part 6: Internet 920 Integration; Sub-part 1: Transmission of IPv6 Packets over 921 GeoNetworking Protocols", ETSI EN 302 636-6-1, October 922 2013. 924 [ETSI-GeoNetworking] 925 ETSI Technical Committee Intelligent Transport Systems, 926 "Intelligent Transport Systems (ITS); Vehicular 927 Communications; GeoNetworking; Part 4: Geographical 928 addressing and forwarding for point-to-point and point-to- 929 multipoint communications; Sub-part 1: Media-Independent 930 Functionality", ETSI EN 302 636-4-1, May 2014. 932 [EU-2008-671-EC] 933 European Union, "Commission Decision of 5 August 2008 on 934 the Harmonised Use of Radio Spectrum in the 5875 - 5905 935 MHz Frequency Band for Safety-related Applications of 936 Intelligent Transport Systems (ITS)", EU 2008/671/EC, 937 August 2008. 939 [FirstNet] 940 U.S. National Telecommunications and Information 941 Administration (NTIA), "First Responder Network Authority 942 (FirstNet)", [Online] 943 Available: https://www.firstnet.gov/, 2012. 945 [FirstNet-Report] 946 First Responder Network Authority, "FY 2017: ANNUAL REPORT 947 TO CONGRESS, Advancing Public Safety Broadband 948 Communications", FirstNet FY 2017, December 2017. 950 [Fuel-Efficient] 951 van de Hoef, S., H. Johansson, K., and D. V. Dimarogonas, 952 "Fuel-Efficient En Route Formation of Truck Platoons", 953 IEEE Transactions on Intelligent Transportation Systems, 954 January 2018. 956 [GeoSAC] Baldessari, R., Bernardos, C., and M. Calderon, "GeoSAC - 957 Scalable Address Autoconfiguration for VANET Using 958 Geographic Networking Concepts", IEEE International 959 Symposium on Personal, Indoor and Mobile Radio 960 Communications, September 2008. 962 [H-DMM] Nguyen, T. and C. Bonnet, "A Hybrid Centralized- 963 Distributed Mobility Management for Supporting Highly 964 Mobile Users", IEEE International Conference on 965 Communications, June 2015. 967 [ID-DNSNA] 968 Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 969 Autoconfiguration for Internet of Things Devices", draft- 970 jeong-ipwave-iot-dns-autoconf-04 (work in progress), 971 October 2018. 973 [ID-Vehicular-ND] 974 Jeong, J., Ed., Shen, Y., Jo, Y., Jeong, J., and J. Lee, 975 "IPv6 Neighbor Discovery for Prefix and Service Discovery 976 in Vehicular Networks", draft-jeong-ipwave-vehicular- 977 neighbor-discovery-04 (work in progress), October 2018. 979 [Identity-Management] 980 Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer 981 Identities Management in ITS Stations", The 10th 982 International Conference on ITS Telecommunications, 983 November 2010. 985 [IEEE-802.11-OCB] 986 IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium 987 Access Control (MAC) and Physical Layer (PHY) 988 Specifications", IEEE Std 802.11-2016, December 2016. 990 [IEEE-802.11p] 991 IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium 992 Access Control (MAC) and Physical Layer (PHY) 993 Specifications - Amendment 6: Wireless Access in Vehicular 994 Environments", IEEE Std 802.11p-2010, June 2010. 996 [IP-Passing-Protocol] 997 Chen, Y., Hsu, C., and W. Yi, "An IP Passing Protocol for 998 Vehicular Ad Hoc Networks with Network Fragmentation", 999 Elsevier Computers & Mathematics with Applications, 1000 January 2012. 1002 [IPv6-over-802.11-OCB] 1003 Petrescu, A., Benamar, N., Haerri, J., Lee, J., and T. 1004 Ernst, "Transmission of IPv6 Packets over IEEE 802.11 1005 Networks operating in mode Outside the Context of a Basic 1006 Service Set (IPv6-over-80211-OCB)", draft-ietf-ipwave- 1007 ipv6-over-80211ocb-25 (work in progress), June 2018. 1009 [IPv6-WAVE] 1010 Baccelli, E., Clausen, T., and R. Wakikawa, "IPv6 1011 Operation for WAVE - Wireless Access in Vehicular 1012 Environments", IEEE Vehicular Networking Conference, 1013 December 2010. 1015 [ISO-ITS-IPv6] 1016 ISO/TC 204, "Intelligent Transport Systems - 1017 Communications Access for Land Mobiles (CALM) - IPv6 1018 Networking", ISO 21210:2012, June 2012. 1020 [Joint-IP-Networking] 1021 Petrescu, A., Boc, M., and C. Ibars, "Joint IP Networking 1022 and Radio Architecture for Vehicular Networks", 1023 11th International Conference on ITS Telecommunications, 1024 August 2011. 1026 [LAGAD] Abrougui, K., Boukerche, A., and R. Pazzi, "Location-Aided 1027 Gateway Advertisement and Discovery Protocol for VANets", 1028 IEEE Transactions on Vehicular Technology, Vol. 59, No. 8, 1029 October 2010. 1031 [Multicast-802] 1032 Perkins, C., Stanley, D., Kumari, W., and JC. Zuniga, 1033 "Multicast Considerations over IEEE 802 Wireless Media", 1034 draft-perkins-intarea-multicast-ieee802-03 (work in 1035 progress), July 2017. 1037 [Multicast-Alert] 1038 Camara, D., Bonnet, C., Nikaein, N., and M. Wetterwald, 1039 "Multicast and Virtual Road Side Units for Multi 1040 Technology Alert Messages Dissemination", IEEE 8th 1041 International Conference on Mobile Ad-Hoc and Sensor 1042 Systems, October 2011. 1044 [NEMO-LMS] 1045 Soto, I., Bernardos, C., Calderon, M., Banchs, A., and A. 1046 Azcorra, "NEMO-Enabled Localized Mobility Support for 1047 Internet Access in Automotive Scenarios", 1048 IEEE Communications Magazine, May 2009. 1050 [NEMO-VANET] 1051 Chen, Y., Hsu, C., and C. Cheng, "Network Mobility 1052 Protocol for Vehicular Ad Hoc Networks", 1053 Wiley International Journal of Communication Systems, 1054 November 2014. 1056 [PMIP-NEMO-Analysis] 1057 Lee, J., Ernst, T., and N. Chilamkurti, "Performance 1058 Analysis of PMIPv6-Based Network Mobility for Intelligent 1059 Transportation Systems", IEEE Transactions on Vehicular 1060 Technology, January 2012. 1062 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1063 "Randomness Requirements for Security", RFC 4086, June 1064 2005. 1066 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1067 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 1068 September 2007. 1070 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1071 Address Autoconfiguration", RFC 4862, September 2007. 1073 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1074 Extensions for Stateless Address Autoconfiguration in 1075 IPv6", RFC 4941, September 2007. 1077 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1078 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1079 RFC 5213, August 2008. 1081 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 1082 Hoc Networks", RFC 5889, September 2010. 1084 [RFC5944] Perkins, C., Ed., "IP Mobility Support in IPv4, Revised", 1085 RFC 5944, November 2010. 1087 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1088 Support in IPv6", RFC 6275, July 2011. 1090 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1091 February 2013. 1093 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1094 Discovery", RFC 6763, February 2013. 1096 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1097 "Neighbor Discovery Optimization for IPv6 over Low-Power 1098 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1099 November 2012. 1101 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 1102 "Requirements for Distributed Mobility Management", 1103 RFC 7333, August 2014. 1105 [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. 1106 Bernardos, "Distributed Mobility Management: Current 1107 Practices and Gap Analysis", RFC 7429, January 2015. 1109 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1110 (IPv6) Specification", RFC 8200, July 2017. 1112 [SAINT] Jeong, J., Jeong, H., Lee, E., Oh, T., and D. Du, "SAINT: 1113 Self-Adaptive Interactive Navigation Tool for Cloud-Based 1114 Vehicular Traffic Optimization", IEEE Transactions on 1115 Vehicular Technology, Vol. 65, No. 6, June 2016. 1117 [SAINTplus] 1118 Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D. 1119 Du, "SAINT+: Self-Adaptive Interactive Navigation Tool+ 1120 for Emergency Service Delivery Optimization", 1121 IEEE Transactions on Intelligent Transportation Systems, 1122 June 2017. 1124 [SANA] Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation 1125 Application for Pedestrian Protection in Vehicular 1126 Networks", Springer Lecture Notes in Computer Science 1127 (LNCS), Vol. 9502, December 2015. 1129 [SDN-DMM] Nguyen, T., Bonnet, C., and J. Harri, "SDN-based 1130 Distributed Mobility Management for 5G Networks", 1131 IEEE Wireless Communications and Networking Conference, 1132 April 2016. 1134 [Securing-VCOMM] 1135 Fernandez, P., Santa, J., Bernal, F., and A. Skarmeta, 1136 "Securing Vehicular IPv6 Communications", 1137 IEEE Transactions on Dependable and Secure Computing, 1138 January 2016. 1140 [TR-22.886-3GPP] 1141 3GPP, "Study on Enhancement of 3GPP Support for 5G V2X 1142 Services", 3GPP TS 22.886, June 2018. 1144 [Truck-Platooning] 1145 California Partners for Advanced Transportation Technology 1146 (PATH), "Automated Truck Platooning", [Online] Available: 1147 http://www.path.berkeley.edu/research/automated-and- 1148 connected-vehicles/truck-platooning, 2017. 1150 [TS-23.285-3GPP] 1151 3GPP, "Architecture Enhancements for V2X Services", 3GPP 1152 TS 23.285, June 2018. 1154 [VANET-Geo-Routing] 1155 Tsukada, M., Jemaa, I., Menouar, H., Zhang, W., Goleva, 1156 M., and T. Ernst, "Experimental Evaluation for IPv6 over 1157 VANET Geographic Routing", IEEE International Wireless 1158 Communications and Mobile Computing Conference, June 2010. 1160 [VIP-WAVE] 1161 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 1162 Feasibility of IP Communications in 802.11p Vehicular 1163 Networks", IEEE Transactions on Intelligent Transportation 1164 Systems, March 2013. 1166 [VMaSC-LTE] 1167 Ucar, S., Ergen, S., and O. Ozkasap, "Multihop-Cluster- 1168 Based IEEE 802.11p and LTE Hybrid Architecture for VANET 1169 Safety Message Dissemination", IEEE Transactions on 1170 Vehicular Technology, April 2016. 1172 [VNET-AAA] 1173 Moustafa, H., Bourdon, G., and Y. Gourhant, "Providing 1174 Authentication and Access Control in Vehicular Network 1175 Environment", IFIP TC-11 International Information 1176 Security Conference, May 2006. 1178 [VNET-MM] Peng, Y. and J. Chang, "A Novel Mobility Management Scheme 1179 for Integration of Vehicular Ad Hoc Networks and Fixed IP 1180 Networks", Springer Mobile Networks and Applications, 1181 February 2010. 1183 [WAVE-1609.0] 1184 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 1185 in Vehicular Environments (WAVE) - Architecture", IEEE Std 1186 1609.0-2013, March 2014. 1188 [WAVE-1609.2] 1189 IEEE 1609 Working Group, "IEEE Standard for Wireless 1190 Access in Vehicular Environments - Security Services for 1191 Applications and Management Messages", IEEE Std 1192 1609.2-2016, March 2016. 1194 [WAVE-1609.3] 1195 IEEE 1609 Working Group, "IEEE Standard for Wireless 1196 Access in Vehicular Environments (WAVE) - Networking 1197 Services", IEEE Std 1609.3-2016, April 2016. 1199 [WAVE-1609.4] 1200 IEEE 1609 Working Group, "IEEE Standard for Wireless 1201 Access in Vehicular Environments (WAVE) - Multi-Channel 1202 Operation", IEEE Std 1609.4-2016, March 2016. 1204 Appendix A. Relevant Topics to IPWAVE Working Group 1206 This section discusses topics relevant to IPWAVE WG: (i) vehicle 1207 identity management; (ii) multihop V2X; (iii) multicast; (iv) DNS 1208 naming services and service discovery; (v) IPv6 over cellular 1209 networks. 1211 A.1. Vehicle Identity Management 1213 A vehicle can have multiple network interfaces using different access 1214 network technologies [Identity-Management]. These multiple network 1215 interfaces mean multiple identities. To identify a vehicle with 1216 multiple indenties, a Vehicle Identification Number (VIN) can be used 1217 as a globally unique vehicle identifier. 1219 To support the seamless connectivity over the multiple identities, a 1220 cross-layer network architecture is required with vertical handover 1221 functionality [Identity-Management]. Also, an AAA service for 1222 multiple identities should be provided to vehicles in an efficient 1223 way to allow horizontal handover as well as vertical handover; note 1224 that AAA stands for Authentication, Authorization, and Accounting. 1226 A.2. Multihop V2X 1228 Multihop packet forwarding among vehicles in 802.11-OCB mode shows an 1229 unfavorable performance due to the common known broadcast-storm 1230 problem [Broadcast-Storm]. This broadcast-storm problem can be 1231 mitigated by the coordination (or scheduling) of a cluster head in a 1232 connected VANET or an RSU in an intersection area, where the cluster 1233 head can work as a coodinator for the access to wireless channels. 1235 A.3. Multicast 1237 IP multicast in vehicular network environments is especially useful 1238 for various services. For instance, an automobile manufacturer can 1239 multicast a particular group/class/type of vehicles for service 1240 notification. As another example, a vehicle or an RSU can 1241 disseminate alert messages in a particular area [Multicast-Alert]. 1243 In general IEEE 802 wireless media, some performance issues about 1244 multicast are found in [Multicast-802]. Since several procedures and 1245 functions based on IPv6 use multicast for control-plane messages, 1246 such as Neighbor Discovery (ND) and Service Discovery, 1247 [Multicast-802] describes that the ND process may fail due to 1248 unreliable wireless link, causing failure of the DAD process. Also, 1249 the Router Advertisement messages can be lost in multicasting. 1251 A.4. DNS Naming Services and Service Discovery 1253 When two vehicular nodes communicate with each other using the DNS 1254 name of the partner node, DNS naming service (i.e., DNS name 1255 resolution) is required. As shown in Figure 2 and Figure 3, a 1256 recursive DNS server (RDNSS) within an internal network can perform 1257 such DNS name resolution for the sake of other vehicular nodes. 1259 A service discovery service is required for an application in a 1260 vehicular node to search for another application or server in another 1261 vehicular node, which resides in either the same internal network or 1262 the other internal network. In V2I or V2V networking, as shown in 1263 Figure 2 and Figure 3, such a service discovery service can be 1264 provided by either DNS-based Service Discovery (DNS-SD) [RFC6763] 1265 with mDNS [RFC6762] or the vehicular ND with a new option for service 1266 discovery [ID-Vehicular-ND]. 1268 A.5. IPv6 over Cellular Networks 1270 Recently, 3GPP has announced a set of new technical specifications, 1271 such as Release 14 (3GPP-R14), which proposes an architecture 1272 enhancements for V2X services using the modified sidelink interface 1273 that originally is designed for the LTE-D2D communications. 3GPP-R14 1274 specifies that the V2X services only support IPv6 implementation. 1275 3GPP is also investigating and discussing the evolved V2X services in 1276 the next generation cellular networks, i.e., 5G new radio (5G-NR), 1277 for advanced V2X communications and automated vehicles' applications. 1279 A.5.1. Cellular V2X (C-V2X) Using 4G-LTE 1281 Before 3GPP-R14, some researchers have studied the potential usage of 1282 C-V2X communications. For example, [VMaSC-LTE] explores a multihop 1283 cluster-based hybrid architecture using both DSRC and LTE for safety 1284 message dissemination. Most of the research considers a short 1285 message service for safety instead of IP datagram forwarding. In 1286 other C-V2X research, the standard IPv6 is assumed. 1288 The 3GPP technical specification [TS-23.285-3GPP] states that both IP 1289 based and non-IP based V2X messages are supported, and only IPv6 is 1290 supported for IP based messages. Moreover, [TS-23.285-3GPP] 1291 instructs that a UE autoconfigures a link-local IPv6 address by 1292 following [RFC4862], but without sending Neighbor Solicitation and 1293 Neighbor Advertisement messages for DAD. This is because a unique 1294 prefix is allocated to each node by the 3GPP network, so the IPv6 1295 addresses cannot be duplicate. 1297 A.5.2. Cellular V2X (C-V2X) Using 5G 1299 The emerging services, functions, and applications, which are 1300 developped in automotive industry, demand reliable and efficient 1301 communication infrastructure for road networks. Correspondingly, the 1302 support of enhanced V2X (eV2X)-based services by future converged and 1303 interoperable 5G systems is required. The 3GPP Technical Report 1304 [TR-22.886-3GPP] is studying new use cases and the corresponding 1305 service requirements for V2X (including V2V and V2I) using 5G in both 1306 infrastructure mode and the sidelink variations in the future. 1308 Appendix B. Changes from draft-ietf-ipwave-vehicular-networking-05 1310 The following changes are made from draft-ietf-ipwave-vehicular- 1311 networking-05: 1313 o In Figure 2 and Figure 3, the vehicle networks and RSU network are 1314 updated. 1316 Appendix C. Acknowledgments 1318 This work was supported by Basic Science Research Program through the 1319 National Research Foundation of Korea (NRF) funded by the Ministry of 1320 Education (2017R1D1A1B03035885). 1322 This work was supported in part by Global Research Laboratory Program 1323 through the NRF funded by the Ministry of Science and ICT (MSIT) 1324 (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT 1325 (18-EE-01). 1327 This work was supported in part by the French research project 1328 DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded 1329 by the European Commission I (636537-H2020). 1331 Appendix D. Contributors 1333 This document is a group work of IPWAVE working group, greatly 1334 benefiting from inputs and texts by Rex Buddenberg (Naval 1335 Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest 1336 University of Technology and Economics), Jose Santa Lozanoi 1337 (Universidad of Murcia), Richard Roy (MIT), Francois Simon (Pilot), 1338 Sri Gundavelli (Cisco), Erik Nordmark, and Dirk von Hugo (Deutsche 1339 Telekom). The authors sincerely appreciate their contributions. 1341 The following are co-authors of this document: 1343 Nabil Benamar 1344 Department of Computer Sciences 1345 High School of Technology of Meknes 1346 Moulay Ismail University 1347 Morocco 1349 Phone: +212 6 70 83 22 36 1350 EMail: benamar73@gmail.com 1352 Sandra Cespedes 1353 Department of Electrical Engineering 1354 Universidad de Chile 1355 Av. Tupper 2007, Of. 504 1356 Santiago, 8370451 1357 Chile 1359 Phone: +56 2 29784093 1360 EMail: scespede@niclabs.cl 1362 Jerome Haerri 1363 Communication Systems Department 1364 EURECOM 1365 Sophia-Antipolis 1366 France 1368 Phone: +33 4 93 00 81 34 1369 EMail: jerome.haerri@eurecom.fr 1371 Dapeng Liu 1372 Alibaba 1373 Beijing, Beijing 100022 1374 China 1376 Phone: +86 13911788933 1377 EMail: max.ldp@alibaba-inc.com 1379 Tae (Tom) Oh 1380 Department of Information Sciences and Technologies 1381 Rochester Institute of Technology 1382 One Lomb Memorial Drive 1383 Rochester, NY 14623-5603 1384 USA 1386 Phone: +1 585 475 7642 1387 EMail: Tom.Oh@rit.edu 1388 Charles E. Perkins 1389 Futurewei Inc. 1390 2330 Central Expressway 1391 Santa Clara, CA 95050 1392 USA 1394 Phone: +1 408 330 4586 1395 EMail: charliep@computer.org 1397 Alexandre Petrescu 1398 CEA, LIST 1399 CEA Saclay 1400 Gif-sur-Yvette, Ile-de-France 91190 1401 France 1403 Phone: +33169089223 1404 EMail: Alexandre.Petrescu@cea.fr 1406 Yiwen Chris Shen 1407 Department of Computer Science & Engineering 1408 Sungkyunkwan University 1409 2066 Seobu-Ro, Jangan-Gu 1410 Suwon, Gyeonggi-Do 16419 1411 Republic of Korea 1413 Phone: +82 31 299 4106 1414 Fax: +82 31 290 7996 1415 EMail: chrisshen@skku.edu 1416 URI: http://iotlab.skku.edu/people-chris-shen.php 1418 Michelle Wetterwald 1419 FBConsulting 1420 21, Route de Luxembourg 1421 Wasserbillig, Luxembourg L-6633 1422 Luxembourg 1424 EMail: Michelle.Wetterwald@gmail.com 1426 Author's Address 1427 Jaehoon Paul Jeong (editor) 1428 Department of Software 1429 Sungkyunkwan University 1430 2066 Seobu-Ro, Jangan-Gu 1431 Suwon, Gyeonggi-Do 16419 1432 Republic of Korea 1434 Phone: +82 31 299 4957 1435 Fax: +82 31 290 7996 1436 EMail: pauljeong@skku.edu 1437 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php