idnits 2.17.1 draft-ietf-ipwave-vehicular-networking-04.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 (July 16, 2018) is 2111 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Online' is mentioned on line 1059, but not defined == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-iot-dns-autoconf-03 == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-vehicular-neighbor-discovery-03 -- 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 July 16, 2018 5 Expires: January 17, 2019 7 IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement 8 and Use Cases 9 draft-ietf-ipwave-vehicular-networking-04 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 topics of 16 vehicular networking are vehicle-to-vehicle (V2V), vehicle-to- 17 infrastructure (V2I), and vehicle-to-everything (V2X) networking. 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 analyze 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 January 17, 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 Current Protocols . . . . . . . . . . . . . . . 7 69 4.1. Current Protocols for Vehicular Networking . . . . . . . 7 70 4.1.1. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . 7 71 4.1.2. IP Address Autoconfiguration . . . . . . . . . . . . 8 72 4.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.1.4. Mobility Management . . . . . . . . . . . . . . . . . 8 74 4.1.5. DNS Naming Service . . . . . . . . . . . . . . . . . 9 75 4.1.6. Service Discovery . . . . . . . . . . . . . . . . . . 9 76 4.1.7. Security and Privacy . . . . . . . . . . . . . . . . 9 77 4.2. General Problems . . . . . . . . . . . . . . . . . . . . 9 78 4.2.1. Vehicular Network Architecture . . . . . . . . . . . 9 79 4.2.2. Latency . . . . . . . . . . . . . . . . . . . . . . . 14 80 4.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 14 81 4.2.4. Pseudonym Handling . . . . . . . . . . . . . . . . . 14 82 5. Problem Exploration . . . . . . . . . . . . . . . . . . . . . 14 83 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 15 84 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 15 85 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 15 86 5.1.3. Prefix Dissemination/Exchange . . . . . . . . . . . . 16 87 5.1.4. Routing . . . . . . . . . . . . . . . . . . . . . . . 16 88 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 16 89 5.3. Security and Privacy . . . . . . . . . . . . . . . . . . 17 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 91 7. Informative References . . . . . . . . . . . . . . . . . . . 17 92 Appendix A. Relevant Work Items to IPWAVE . . . . . . . . . . . 25 93 A.1. Vehicle Identity Management . . . . . . . . . . . . . . . 25 94 A.2. Multihop V2X . . . . . . . . . . . . . . . . . . . . . . 25 95 A.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 25 96 A.4. DNS Naming Services and Service Discovery . . . . . . . . 26 97 A.5. IPv6 over Cellular Networks . . . . . . . . . . . . . . . 26 98 A.5.1. Cellular V2X (C-V2X) Using 4G-LTE . . . . . . . . . . 26 99 A.5.2. Cellular V2X (C-V2X) Using 5G . . . . . . . . . . . . 27 100 Appendix B. Changes from draft-ietf-ipwave-vehicular- 101 networking-03 . . . . . . . . . . . . . . . . . . . 27 102 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 27 103 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 27 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 106 1. Introduction 108 Vehicular networks have been focused on the driving safety, driving 109 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) made a law for radio spectrum for 117 safety-related applications of ITS with the frequency band of 5.875 - 118 5.905 GHz, which is called Commission Decision 2008/671/EC 119 [EU-2008-671-EC]. 121 For driving safety services based on the DSRC, IEEE has standardized 122 Wireless Access in Vehicular Environments (WAVE) standards, such as 123 IEEE 802.11p [IEEE-802.11p], IEEE 1609.2 [WAVE-1609.2], IEEE 1609.3 124 [WAVE-1609.3], and IEEE 1609.4 [WAVE-1609.4]. Note that IEEE 802.11p 125 has been published as IEEE 802.11 Outside the Context of a Basic 126 Service Set (OCB) [IEEE-802.11-OCB] in 2012. Along with these WAVE 127 standards, IPv6 and Mobile IP protocols (e.g., MIPv4 and MIPv6) can 128 be extended to vehicular networks [RFC8200][RFC5944][RFC6275]. Also, 129 ETSI has standardized a GeoNetworking (GN) protocol 130 [ETSI-GeoNetworking] and a protocol adaptation sub-layer from 131 GeoNetworking to IPv6 [ETSI-GeoNetwork-IP]. In addition, ISO has 132 standardized a standard specifying the IPv6 network protocols and 133 services for Communications Access for Land Mobiles (CALM) 134 [ISO-ITS-IPv6]. 136 This document discusses problem statements and use cases related to 137 IP-based vehicular networking for Intelligent Transportation Systems 138 (ITS), which is IP Wireless Access in Vehicular Environments 139 (IPWAVE). First, it surveys the use cases for using V2V, V2I, and 140 V2X networking in the ITS. Second, for literature review, it 141 analyzes proposed protocols for IP-based vehicular networking and 142 highlights the limitations and difficulties found on those protocols. 143 Third, for problem statement, it presents a problem exploration with 144 key aspects in IPWAVE, such as IPv6 Neighbor Discovery, Mobility 145 Management, and Security & Privacy. For each key aspect, it 146 discusses a problem statement to analyze the gap between the state- 147 of-the-art techniques and requirements in IP-based vehicular 148 networking. Also, it also discusses relevant work items to IPWAVE, 149 such as Vehicle Identities Management, Multihop V2X Communications, 150 Multicast, DNS Naming Services, Service Discovery, and IPv6 over 151 Cellular Networks. Therefore, with the problem statement, this 152 document will open a door to develop key protocols for IPWAVE that 153 will be essential to IP-based vehicular networks. 155 2. Terminology 157 This document uses the following definitions: 159 o WAVE: Acronym for "Wireless Access in Vehicular Environments" 160 [WAVE-1609.0]. 162 o DMM: Acronym for "Distributed Mobility Management" 163 [RFC7333][RFC7429]. 165 o Road-Side Unit (RSU): A node that has physical communication 166 devices (e.g., DSRC, Visible Light Communication, 802.15.4, LTE- 167 V2X, etc.) for wireless communications with vehicles and is also 168 connected to the Internet as a router or switch for packet 169 forwarding. An RSU is deployed either at an intersection or in a 170 road segment. 172 o On-Board Unit (OBU): A node that has a DSRC device for wireless 173 communications with other OBUs and RSUs. An OBU is mounted on a 174 vehicle. It is assumed that a radio navigation receiver (e.g., 175 Global Positioning System (GPS)) is included in a vehicle with an 176 OBU for efficient navigation. 178 o Vehicle Detection Loop (or Loop Detector): An inductive device 179 used for detecting vehicles passing or arriving at a certain 180 point, for instance approaching a traffic light or in motorway 181 traffic. The relatively crude nature of the loop's structure 182 means that only metal masses above a certain size are capable of 183 triggering the detection. 185 o Traffic Control Center (TCC): A node that maintains road 186 infrastructure information (e.g., RSUs, traffic signals, and loop 187 detectors), vehicular traffic statistics (e.g., average vehicle 188 speed and vehicle inter-arrival time per road segment), and 189 vehicle information (e.g., a vehicle's identifier, position, 190 direction, speed, and trajectory as a navigation path). TCC is 191 included in a vehicular cloud for vehicular networks. 193 3. Use Cases 195 This section provides use cases of V2V, V2I, and V2X networking. The 196 use cases of the V2X networking exclude the ones of the V2V and V2I 197 networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to- 198 Device (V2D). 200 3.1. V2V 202 The use cases of V2V networking discussed in this section include 204 o Context-aware navigation for driving safety and collision 205 avoidance; 207 o Cooperative adaptive cruise control in an urban roadway; 209 o Platooning in a highway; 211 o Cooperative environment sensing. 213 These four techniques will be important elements for self-driving 214 vehicles. 216 Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers 217 to drive safely by letting the drivers recognize dangerous obstacles 218 and situations. That is, CASD navigator displays obstables or 219 neighboring vehicles relevant to possible collisions in real-time 220 through V2V networking. CASD provides vehicles with a class-based 221 automatic safety action plan, which considers three situations, such 222 as the Line-of-Sight unsafe, Non-Line-of-Sight unsafe and safe 223 situations. This action plan can be performed among vehicles through 224 V2V networking. 226 Cooperative Adaptive Cruise Control (CACC) [CA-Cuise-Control] helps 227 vehicles to adapt their speed autonomously through V2V communication 228 among vehicles according to the mobility of their predecessor and 229 successor vehicles in an urban roadway or a highway. CACC can help 230 adjacent vehicles to efficiently adjust their speed in a cascade way 231 through V2V networking. 233 Platooning [Truck-Platooning] allows a series of vehicles (e.g., 234 trucks) to move together with a very short inter-distance. Trucks 235 can use V2V communication in addition to forward sensors in order to 236 maintain constant clearance between two consecutive vehicles at very 237 short gaps (from 3 meters to 10 meters). This platooning can 238 maximize the throughput of vehicular traffic in a highway and reduce 239 the gas consumption because the leading vehicle can help the 240 following vehicles to experience less air resistance. 242 Cooperative-environment-sensing use cases suggest that vehicles can 243 share environmental information from various sensors, such as radars, 244 LiDARs and cameras, mounted on them with other vehicles and 245 pedestrians. [Automotive-Sensing] introduces a millimeter-wave 246 vehicular communication for massive automotive sensing. Data 247 generated by those sensors can be substantially large, and these data 248 shall be routed to different destinations. In addition, from the 249 perspective of driverless vehicles, it is expected that driverless 250 vehicles can be mixed with driver vehicles. Through cooperative 251 environment sensing, driver vehicles can use environmental 252 information sensed by driverless vehicles for better interaction with 253 the context. 255 3.2. V2I 257 The use cases of V2I networking discussed in this section include 259 o Navigation service; 261 o Energy-efficient speed recommendation service; 263 o Accident notification service. 265 A navigation service, such as the Self-Adaptive Interactive 266 Navigation Tool (called SAINT) [SAINT], using V2I networking 267 interacts with TCC for the global road traffic optimization and can 268 guide individual vehicles for appropriate navigation paths in real 269 time. The enhanced SAINT (called SAINT+) [SAINTplus] can give the 270 fast moving paths for emergency vehicles (e.g., ambulance and fire 271 engine) toward accident spots while providing other vehicles with 272 efficient detour paths. 274 A TCC can recommend an energy-efficient speed to a vehicle driving in 275 different traffic environments. [Fuel-Efficient] studies fuel- 276 efficient route and speed plans for platooned trucks. 278 The emergency communication between accident vehicles (or emergency 279 vehicles) and TCC can be performed via either RSU or 4G-LTE networks. 280 The First Responder Network Authority (FirstNet) [FirstNet] is 281 provided by the US government to establish, operate, and maintain an 282 interoperable public safety broadband network for safety and security 283 network services, such as emergency calls. The construction of the 284 nationwide FirstNet network requires each state in the US to have a 285 Radio Access Network (RAN) that will connect to FirstNet's network 286 core. The current RAN is mainly constructed by 4G-LTE for the 287 communication between a vehicle and an infrastructure node (i.e., 288 V2I) [FirstNet-Report], but DSRC-based vehicular networks can be used 289 for V2I in near future [DSRC]. 291 3.3. V2X 293 The use case of V2X networking discussed in this section is 294 pedestrian protection service. 296 A pedestrian protection service, such as Safety-Aware Navigation 297 Application (called SANA) [SANA], using V2I2P networking can reduce 298 the collision of a pedestrian and a vehicle, which have a smartphone, 299 in a road network. Vehicles and pedestrians can communicate with 300 each other via an RSU that delivers scheduling information for 301 wireless communication to save the smartphones' battery. 303 4. Analysis for Current Protocols 305 4.1. Current Protocols for Vehicular Networking 307 We analyze the current protocols from the following aspects: 309 o IPv6 over 802.11-OCB; 311 o IP address autoconfiguration; 313 o Routing; 315 o Mobility management; 317 o DNS naming service; 319 o Service discovery; 321 o Security and privacy. 323 4.1.1. IPv6 over 802.11-OCB 325 For IPv6 packets transporting over IEEE 802.11-OCB, 326 [IPv6-over-802.11-OCB] specifies several details, such as Maximum 327 Transmission Unit (MTU), frame format, link-local address, address 328 mapping for unicast and multicast, stateless autoconfiguration, and 329 subnet structure. Especially, an Ethernet Adaptation (EA) layer is 330 in charge of transforming some parameters between IEEE 802.11 MAC 331 layer and IPv6 network layer, which is located between IEEE 332 802.11-OCB's logical link control layer and IPv6 network layer. 334 4.1.2. IP Address Autoconfiguration 336 For IP address autoconfiguration, Fazio et al. proposed a vehicular 337 address configuration (VAC) scheme using DHCP where elected leader- 338 vehicles provide unique identifiers for IP address configurations 339 [Address-Autoconf]. Kato et al. proposed an IPv6 address assignment 340 scheme using lane and position information [Address-Assignment]. 341 Baldessari et al. proposed an IPv6 scalable address autoconfiguration 342 scheme called GeoSAC for vehicular networks [GeoSAC]. Wetterwald et 343 al. conducted a comprehensive study of the cross-layer identities 344 management in vehicular networks using multiple access network 345 technologies, which constitutes a fundamental element of the ITS 346 architecture [Identity-Management]. 348 4.1.3. Routing 350 For routing, Tsukada et al. presented a work that aims at combining 351 IPv6 networking and a Car-to-Car Network routing protocol (called 352 C2CNet) proposed by the Car2Car Communication Consortium (C2C-CC), 353 which is an architecture using a geographic routing protocol 354 [VANET-Geo-Routing]. Abrougui et al. presented a gateway discovery 355 scheme for VANET, called Location-Aided Gateway Advertisement and 356 Discovery (LAGAD) mechanism [LAGAD]. 358 4.1.4. Mobility Management 360 For mobility management, Chen et al. tackled the issue of network 361 fragmentation in VANET environments [IP-Passing-Protocol] by 362 proposing a protocol that can postpone the time to release IP 363 addresses to the DHCP server and select a faster way to get the 364 vehicle's new IP address, when the vehicle density is low or the 365 speeds of vehicles are varied. Nguyen et al. proposed a hybrid 366 centralized-distributed mobility management called H-DMM to support 367 highly mobile vehicles [H-DMM]. [NEMO-LMS] proposed an architecture 368 to enable IP mobility for moving networks using a network-based 369 mobility scheme based on PMIPv6. Chen et al. proposed a network 370 mobility protocol to reduce handoff delay and maintain Internet 371 connectivity to moving vehicles in a highway [NEMO-VANET]. Lee et 372 al. proposed P-NEMO, which is a PMIPv6-based IP mobility management 373 scheme to maintain the Internet connectivity at the vehicle as a 374 mobile network, and provides a make-before-break mechanism when 375 vehicles switch to a new access network [PMIP-NEMO-Analysis]. Peng 376 et al. proposed a novel mobility management scheme for integration of 377 VANET and fixed IP networks [VNET-MM]. Nguyen et al. extended their 378 previous works on a vehicular adapted DMM considering a Software- 379 Defined Networking (SDN) architecture [SDN-DMM]. 381 4.1.5. DNS Naming Service 383 For DNS naming service, Multicast DNS (mDNS) [RFC6762] allows devices 384 in one-hop communication range to resolve each other's DNS name into 385 the corresponding IP address in multicast. DNS Name 386 Autoconfiguration (DNSNA) [ID-DNSNA] proposes a DNS naming service 387 for Internet-of-Things (IoT) devices in a large-scale network. 389 4.1.6. Service Discovery 391 For service discovery, as a popular existing service discovery 392 protocol, DNS-based Service Discovery (DNS-SD) [RFC6763] with mDNS 393 [RFC6762] provides service discovery. Vehicular ND [ID-Vehicular-ND] 394 proposes an extension of IPv6 ND for the prefix and service 395 discovery. 397 4.1.7. Security and Privacy 399 For security and privacy, Fernandez et al. proposed a secure 400 vehicular IPv6 communication scheme using Internet Key Exchange 401 version 2 (IKEv2) and Internet Protocol Security (IPsec) 402 [Securing-VCOMM]. Moustafa et al. proposed a security scheme 403 providing authentication, authorization, and accounting (AAA) 404 services in vehicular networks [VNET-AAA]. 406 4.2. General Problems 408 This section describes a vehicular network architecture for V2V, V2I, 409 and V2X communications. Then it analyzes the limitations of the 410 current protocols for vehicular networking. 412 4.2.1. Vehicular Network Architecture 414 Figure 1 shows an architecture for V2I and V2V networking in a road 415 network. The two RSUs (RSU1 and RSU2) are deployed in the road 416 network and are connected to a Vehicular Cloud through the Internet. 417 TCC is connected to the Vehicular Cloud and the two vehicles 418 (Vehicle1 and Vehicle2) are wirelessly connected to RSU1, and the 419 last vehicle (Vehicle3) is wirelessly connected to RSU2. Vehicle1 420 can communicate with Vehicle2 via V2V communication, and Vehicle2 can 421 communicate with Vehicle3 via V2V communication. Vehicle1 can 422 communicate with Vehicle3 via RSU1 and RSU2 via V2I communication. 424 In vehicular networks, unidirectional links exist and must be 425 considered for wireless communications. Also, in the vehicular 426 networks, control plane must be separated from data plane for 427 efficient mobility management and data forwarding. ID/Pseudonym 428 change for privacy requires a lightweight DAD. IP tunneling over the 429 wireless link should be avoided for performance efficiency. The 430 mobility information of a mobile device (e.g., vehicle), such as 431 trajectory, position, speed, and direction, can be used by the mobile 432 device and infrastructure nodes (e.g., TCC and RSU) for the 433 accommodation of proactive protocols because it is usually equipped 434 with a GPS receiver. Vehicles can use the TCC as its Home Network, 435 so the TCC maintains the mobility information of vehicles for 436 location management. 438 *-------------* 439 * * .-------. 440 * Vehicular Cloud *<------>| TCC | 441 * * ._______. 442 *-------------* 443 ^ ^ 444 | | 445 | | 446 v v 447 .--------. .--------. 448 | RSU1 |<----------->| RSU2 | 449 .________. .________. 450 ^ ^ ^ 451 : : : 452 : : : 453 v v v 454 .--------. .--------. .--------. 455 |Vehicle1|=> |Vehicle2|=> |Vehicle3|=> 456 | |<....>| |<....>| | 457 .________. .________. .________. 459 <----> Wired Link <....> Wireless Link => Moving Direction 461 Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 463 Cespedes et al. proposed a vehicular IP in WAVE called VIP-WAVE for 464 I2V and V2I networking [VIP-WAVE]. The standard WAVE does not 465 support both seamless communications for Internet services and multi- 466 hop communications between a vehicle and an infrastructure node 467 (e.g., RSU), either. To overcome these limitations of the standard 468 WAVE, VIP-WAVE enhances the standard WAVE by the following three 469 schemes: (i) an efficient mechanism for the IPv6 address assignment 470 and DAD, (ii) on-demand IP mobility based on Proxy Mobile IPv6 471 (PMIPv6), and (iii) one-hop and two-hop communications for I2V and 472 V2I networking. 474 Baccelli et al. provided an analysis of the operation of IPv6 as it 475 has been described by the IEEE WAVE standards 1609 [IPv6-WAVE]. This 476 analysis confirms that the use of the standard IPv6 protocol stack in 477 WAVE is not sufficient. It recommebs that the IPv6 addressing 478 assignment should follow considerations for ad-hoc link models, 479 defined in [RFC5889] for nodes' mobility and link variability. 481 Petrescu et al. proposed the joint IP networking and radio 482 architecture for V2V and V2I communication in [Joint-IP-Networking]. 483 The proposed architecture considers an IP topology in a similar way 484 as a radio link topology, in the sense that an IP subnet would 485 correspond to the range of 1-hop vehicular communication. This 486 architecture defines three types of vehicles: Leaf Vehicle, Range 487 Extending Vehicle, and Internet Vehicle. 489 4.2.1.1. V2I-based Internetworking 491 This section discusses the internetworking between a vehicle's moving 492 network and an RSU's fixed network. 494 (*)<..........>(*) 495 | | 2001:DB8:1:1::/64 496 .------------------------------. .---------------------------------. 497 | | | | | | 498 | .-------. .------. .-------. | | .-------. .------. .-------. | 499 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 500 | ._______. .______. ._______. | | ._______. .______. ._______. | 501 | ^ ^ ^ | | ^ ^ ^ | 502 | | | | | | | | | | 503 | v v v | | v v v | 504 | ---------------------------- | | ------------------------------- | 505 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 506 | | | | | | 507 | v | | v | 508 | .-------. .-------. | | .-------. .-------. .-------. | 509 | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | 510 | ._______. ._______. | | ._______. ._______. ._______. | 511 | ^ ^ | | ^ ^ ^ | 512 | | | | | | | | | 513 | v v | | v v v | 514 | ---------------------------- | | ------------------------------- | 515 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 516 .______________________________. ._________________________________. 517 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 519 <----> Wired Link <....> Wireless Link (*) Antenna 521 Figure 2: Internetworking between Vehicle Network and RSU Network 523 As shown in Figure 2, the vehicle's moving network and the RSU's 524 fixed network are self-contained networks having multiple subnets and 525 having an edge router for the communication with another vehicle or 526 RSU. The method of prefix assignment for each subnet inside the 527 vehicle's mobile network and the RSU's fixed network is out of scope 528 for this document. Internetworking between two internal networks via 529 either V2I or V2V communication requires an exchange of network 530 prefix and other parameters. 532 The network parameter discovery collects networking information for 533 an IP communication between a vehicle and an RSU or between two 534 neighboring vehicles, such as link layer, MAC layer, and IP layer 535 information. The link layer information includes wireless link layer 536 parameters, such as wireless media (e.g., IEEE 802.11-OCB, LTE D2D 537 (Device to Device), Bluetooth, and LiFi (Light Fidelity)) and a 538 transmission power level. Note that LiFi is a technology for light- 539 based wireless communication between devices in order to transmit 540 both data and position. The MAC layer information includes the MAC 541 address of an external network interface for the internetworking with 542 another vehicle or RSU. The IP layer information includes the IP 543 address and prefix of an external network interface for the 544 internetworking with another vehicle or RSU. 546 Once the network parameter discovery and prefix exchange operations 547 have been performed, packets can be transmitted between the vehicle's 548 moving network and the RSU's fixed network. DNS services should be 549 supported to enable name resolution for hosts or servers residing 550 either in the vehicle's moving network or the RSU's fixed network. 551 For these DNS services, a recursive DNS server (RDNSS) within each 552 internal network of a vehicle or RSU can be used for the hosts or 553 servers. 555 Figure 2 shows internetworking between the vehicle's moving network 556 and the RSU's fixed network. There exists an internal network 557 (Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server 558 (RDNSS1), the two hosts (Host1 and Host2), and the two routers 559 (Router1 and Router2). There exists another internal network (Fixed 560 Network1) inside RSU1. RSU1 has the DNS Server (RDNSS2), one host 561 (Host3), the two routers (Router3 and Router4), and the collection of 562 servers (Server1 to ServerN) for various services in the road 563 networks, such as the emergency notification and navigation. 564 Vehicle1's Router1 (called mobile router) and RSU1's Router3 (called 565 fixed router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) 566 for I2V networking. 568 4.2.1.2. V2V-based Internetworking 570 This section discusses the internetworking between the moving 571 networks of two neighboring vehicles. 573 Figure 3 shows internetworking between the moving networks of two 574 neighboring vehicles. There exists an internal network (Moving 575 Network1) inside Vehicle1. Vehicle1 has the DNS Server (RDNSS1), the 576 two hosts (Host1 and Host2), and the two routers (Router1 and 577 Router2). There exists another internal network (Moving Network2) 578 inside Vehicle2. Vehicle2 has the DNS Server (RDNSS2), the two hosts 579 (Host3 and Host4), and the two routers (Router3 and Router4). 580 Vehicle1's Router1 (called mobile router) and Vehicle2's Router3 581 (called mobile router) use 2001:DB8:1:1::/64 for an external link 582 (e.g., DSRC) for V2V networking. 584 (*)<..........>(*) 585 | | 2001:DB8:1:1::/64 586 .------------------------------. .---------------------------------. 587 | | | | | | 588 | .-------. .------. .-------. | | .-------. .------. .-------. | 589 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 590 | ._______. .______. ._______. | | ._______. .______. ._______. | 591 | ^ ^ ^ | | ^ ^ ^ | 592 | | | | | | | | | | 593 | v v v | | v v v | 594 | ---------------------------- | | ------------------------------- | 595 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:30:1::/64 | 596 | | | | | | 597 | v | | v | 598 | .-------. .-------. | | .-------. .-------. | 599 | | Host2 | |Router2| | | |Router4| | Host4 | | 600 | ._______. ._______. | | ._______. ._______. | 601 | ^ ^ | | ^ ^ | 602 | | | | | | | | 603 | v v | | v v | 604 | ---------------------------- | | ------------------------------- | 605 | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | 606 .______________________________. ._________________________________. 607 Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) 609 <----> Wired Link <....> Wireless Link (*) Antenna 611 Figure 3: Internetworking between Two Vehicle Networks 613 The differences between IPWAVE (including Vehicular Ad Hoc Networks 614 (VANET)) and Mobile Ad Hoc Networks (MANET) are as follows: 616 o IPWAVE is not power-constrained operation; 618 o Traffic can be sourced or sinked outside of IPWAVE; 620 o IPWAVE shall support both distributed and centralized operations; 622 o No "sleep" period operation is required for energy saving. 624 4.2.2. Latency 626 The communication delay (i.e., latency) between two vehicular nodes 627 (vehicle and RSU) should be bounded to a certain threshold. For IP- 628 based safety applications (e.g., context-aware navigation, adaptive 629 cruise control, and platooning) in vehicular network, this bounded 630 data delivery is critical. The real implementations for such 631 applications are not available, so the feasibility of IP-based safety 632 applications is not tested yet. 634 4.2.3. Security 636 Security protects vehicles roaming in road networks from the attacks 637 of malicious vehicular nodes, which are controlled by hackers. For 638 safety applications, the cooperation among vehicles is assumed. 639 Malicious vehicular nodes may disseminate wrong driving information 640 (e.g., location, speed, and direction) to make driving be unsafe. 641 Sybil attack, which tries to illude a vehicle with multiple false 642 identities, disturbs a vehicle in taking a safe maneuver. 643 Applications on IP-based vehicular networking, which are resilient to 644 such a sybil attack, are not developed and tested yet. 646 4.2.4. Pseudonym Handling 648 For the protection of privacy, pseudonym for a vehicle's network 649 interface is used, which the interface's identifier is changed 650 periodically. Such a pseudonym affects an IPv6 address based on the 651 network interface's identifier, and a transport-layer session with an 652 IPv6 address pair. The pseudonym handling is not implemented and 653 test yet for applications on IP-based vehicular networking. 655 5. Problem Exploration 657 This section discusses key work items for IPWAVE, such as neighbor 658 discovery, mobility management, and security & privacy. 660 5.1. Neighbor Discovery 662 Neighbor Discovery (ND) [RFC4861] is a core part of the IPv6 protocol 663 suite. This section discusses the need for modifying ND for use with 664 vehicular networking (e.g., V2V, V2I, and V2X). The vehicles are 665 moving fast within the communication coverage of a vehicular node 666 (e.g., vehicle and RSU). The external link between two vehicular 667 nodes can be used for vehicular networking, as shown in Figure 2 and 668 Figure 3. 670 ND time-related parameters such as router lifetime and Neighbor 671 Advertisement (NA) interval should be adjusted for high-speed 672 vehicles and vehicle density. As vehicles move faster, the NA 673 interval should decrease for the NA messages to reach the neighboring 674 vehicles promptly. Also, as vehicle density is higher, the NA 675 interval should increase for the NA messages to collide with other NA 676 messages with lower collision probability. 678 5.1.1. Link Model 680 IPv6 protocols work under certain assumptions for the link model that 681 do not necessarily hold in WAVE [IPv6-WAVE]. For instance, some IPv6 682 protocols assume symmetry in the connectivity among neighboring 683 interfaces. However, interference and different levels of 684 transmission power may cause unidirectional links to appear in a WAVE 685 link model. 687 Also, in an IPv6 link, it is assumed that all interfaces which are 688 configured with the same subnet prefix are on the same IP link. 689 Hence, there is a relationship between link and prefix, besides the 690 different scopes that are expected from the link-local and global 691 types of IPv6 addresses. Such a relationship does not hold in a WAVE 692 link model due to node mobility and highly dynamic topology. 694 Thus, IPv6 ND should be extended to support the concept of a link for 695 an IPv6 prefix in terms of multicast in VANET. 697 5.1.2. MAC Address Pseudonym 699 As the ETSI GeoNetworking, for the sake of security and privacy, an 700 ITS station (e.g., vehicle) can use pseudonyms for its network 701 interface identities (e.g., MAC address) and the corresponding IPv6 702 addresses [Identity-Management]. Whenever the network interface 703 identifier changes, the IPv6 address based on the network interface 704 identifier should be updated. For the continuity of an end-to-end 705 transport-layer (e.g., TCP, UDP, and SCTP) session, the IP addresses 706 of the transport-layer session should be notified to both the end 707 points and the packets of the session should be forwarded to their 708 destinations with the changed network interface identifier and IPv6 709 address. 711 5.1.3. Prefix Dissemination/Exchange 713 A vehicle and an RSU can have their internal network, as shown in 714 Figure 2 and Figure 3. In this case, nodes in within the internal 715 networks of two vehicular nodes (e.g., vehicle and RSU) want to 716 communicate with each other. For this communication, the network 717 prefix dissemination or exchange is required. It is assumed that a 718 vehicular node has an external network interface and its internal 719 network. The standard IPv6 ND needs to be extended for the 720 communication between the internal-network vehicular nodes by letting 721 each of them know the other side's prefix with a new ND option 722 [ID-Vehicular-ND]. 724 5.1.4. Routing 726 For Neighbor Discovery in vehicular networks (called vehicular ND), 727 Ad Hoc routing is required for either unicast or multicast in the 728 links in a connected VANET with the same IPv6 prefix [GeoSAC]. Also, 729 a rapid DAD should be supported to prevent or reduce IPv6 address 730 conflicts in such links. 732 5.2. Mobility Management 734 The seamless connectivity and timely data exchange between two end 735 points requires an efficient mobility management including location 736 management and handover. Most of vehicles are equipped with a GPS 737 navigator as a dedicated navigation system or a smartphone App. With 738 this GPS navigator, an efficient mobility management is possible by 739 vehicles periodically reporting their current position and trajectory 740 (i.e., navigation path) to TCC. TCC can predict the future positions 741 of the vehicles with their mobility information (i.e., the current 742 position, speed, direction, and trajectory) for location management. 744 With the prediction of the vehicle mobility, TCC can support RSUs to 745 perform DAD, data packet routing, and horizontal/vertical handover in 746 a proactive manner. When it is assigned a new IPv6 address belonging 747 to a different subnet,a vehicle can skip the DAD operation, reducing 748 IPv6 control traffic overhead. RSUs can efficiently forward data 749 packets from the wired network to a moving destination vehicle along 750 its trajectory. RSUs can smoothly perform handover for the sake of a 751 moving vehicle along its trajectory. 753 5.3. Security and Privacy 755 Security and privacy are paramount in the V2I, V2V, and V2X 756 networking in vehicular networks. Only authorized vehicles should be 757 allowed to use vehicular networking. Also, in-vehicle devices and 758 mobile devices in a vehicle need to communicate with other in-vehicle 759 devices and mobile devices in another vehicle, and other servers in 760 an RSU in a secure way. 762 A Vehicle Identification Number (VIN) and a user certificate along 763 with in-vehicle device's identifier generation can be used to 764 efficiently authenticate a vehicle or a user through a road 765 infrastructure node (e.g., RSU) connected to an authentication server 766 in TCC. Also, Transport Layer Security (TLS) certificates can be 767 used for secure end-to-end vehicle communications. 769 For secure V2I communication, a secure channel between a mobile 770 router in a vehicle and a fixed router in an RSU should be 771 established, as shown in Figure 2. Also, for secure V2V 772 communication, a secure channel between a mobile router in a vehicle 773 and a mobile router in another vehicle should be established, as 774 shown in Figure 3. 776 To prevent an adversary from tracking a vehicle with its MAC address 777 or IPv6 address, MAC address pseudonym should be provided to the 778 vehicle; that is, each vehicle should periodically update its MAC 779 address and the corresponding IPv6 address as suggested in 780 [RFC4086][RFC4941]. Such an update of the MAC and IPv6 addresses 781 should not interrupt the end-to-end communications between two 782 vehicular nodes (e.g., vehicle and RSU) in terms of transport layer. 784 6. Security Considerations 786 This document discussed security and privacy for IP-based vehicular 787 networking. 789 The security and privacy for key components in IP-based vehicular 790 networking, such as neighor discovery and mobility management, needs 791 to be analyzed in depth. 793 7. Informative References 795 [Address-Assignment] 796 Kato, T., Kadowaki, K., Koita, T., and K. Sato, "Routing 797 and Address Assignment using Lane/Position Information in 798 a Vehicular Ad-hoc Network", IEEE Asia-Pacific Services 799 Computing Conference, December 2008. 801 [Address-Autoconf] 802 Fazio, M., Palazzi, C., Das, S., and M. Gerla, "Automatic 803 IP Address Configuration in VANETs", ACM International 804 Workshop on Vehicular Inter-Networking, September 2016. 806 [Automotive-Sensing] 807 Choi, J., Va, V., Gonzalez-Prelcic, N., Daniels, R., R. 808 Bhat, C., and R. W. Heath, "Millimeter-Wave Vehicular 809 Communication to Support Massive Automotive Sensing", 810 IEEE Communications Magazine, December 2016. 812 [Broadcast-Storm] 813 Wisitpongphan, N., K. Tonguz, O., S. Parikh, J., Mudalige, 814 P., Bai, F., and V. Sadekar, "Broadcast Storm Mitigation 815 Techniques in Vehicular Ad Hoc Networks", IEEE Wireless 816 Communications, December 2007. 818 [CA-Cuise-Control] 819 California Partners for Advanced Transportation Technology 820 (PATH), "Cooperative Adaptive Cruise Control", [Online] 821 Available: 822 http://www.path.berkeley.edu/research/automated-and- 823 connected-vehicles/cooperative-adaptive-cruise-control, 824 2017. 826 [CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A 827 Framework of Context-Awareness Safety Driving in Vehicular 828 Networks", International Workshop on Device Centric Cloud 829 (DC2), March 2016. 831 [DSRC] ASTM International, "Standard Specification for 832 Telecommunications and Information Exchange Between 833 Roadside and Vehicle Systems - 5 GHz Band Dedicated Short 834 Range Communications (DSRC) Medium Access Control (MAC) 835 and Physical Layer (PHY) Specifications", 836 ASTM E2213-03(2010), October 2010. 838 [ETSI-GeoNetwork-IP] 839 ETSI Technical Committee Intelligent Transport Systems, 840 "Intelligent Transport Systems (ITS); Vehicular 841 Communications; GeoNetworking; Part 6: Internet 842 Integration; Sub-part 1: Transmission of IPv6 Packets over 843 GeoNetworking Protocols", ETSI EN 302 636-6-1, October 844 2013. 846 [ETSI-GeoNetworking] 847 ETSI Technical Committee Intelligent Transport Systems, 848 "Intelligent Transport Systems (ITS); Vehicular 849 Communications; GeoNetworking; Part 4: Geographical 850 addressing and forwarding for point-to-point and point-to- 851 multipoint communications; Sub-part 1: Media-Independent 852 Functionality", ETSI EN 302 636-4-1, May 2014. 854 [EU-2008-671-EC] 855 European Union, "Commission Decision of 5 August 2008 on 856 the Harmonised Use of Radio Spectrum in the 5875 - 5905 857 MHz Frequency Band for Safety-related Applications of 858 Intelligent Transport Systems (ITS)", EU 2008/671/EC, 859 August 2008. 861 [FirstNet] 862 U.S. National Telecommunications and Information 863 Administration (NTIA), "First Responder Network Authority 864 (FirstNet)", [Online] 865 Available: https://www.firstnet.gov/, 2012. 867 [FirstNet-Report] 868 First Responder Network Authority, "FY 2017: ANNUAL REPORT 869 TO CONGRESS, Advancing Public Safety Broadband 870 Communications", FirstNet FY 2017, December 2017. 872 [Fuel-Efficient] 873 van de Hoef, S., H. Johansson, K., and D. V. Dimarogonas, 874 "Fuel-Efficient En Route Formation of Truck Platoons", 875 IEEE Transactions on Intelligent Transportation Systems, 876 January 2018. 878 [GeoSAC] Baldessari, R., Bernardos, C., and M. Calderon, "GeoSAC - 879 Scalable Address Autoconfiguration for VANET Using 880 Geographic Networking Concepts", IEEE International 881 Symposium on Personal, Indoor and Mobile Radio 882 Communications, September 2008. 884 [H-DMM] Nguyen, T. and C. Bonnet, "A Hybrid Centralized- 885 Distributed Mobility Management for Supporting Highly 886 Mobile Users", IEEE International Conference on 887 Communications, June 2015. 889 [ID-DNSNA] 890 Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 891 Autoconfiguration for Internet of Things Devices", draft- 892 jeong-ipwave-iot-dns-autoconf-03 (work in progress), July 893 2018. 895 [ID-Vehicular-ND] 896 Jeong, J., Ed., Shen, Y., Jo, Y., Jeong, J., and J. Lee, 897 "IPv6 Neighbor Discovery for Prefix and Service Discovery 898 in Vehicular Networks", draft-jeong-ipwave-vehicular- 899 neighbor-discovery-03 (work in progress), July 2018. 901 [Identity-Management] 902 Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer 903 Identities Management in ITS Stations", The 10th 904 International Conference on ITS Telecommunications, 905 November 2010. 907 [IEEE-802.11-OCB] 908 IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium 909 Access Control (MAC) and Physical Layer (PHY) 910 Specifications", IEEE Std 802.11-2012, February 2012. 912 [IEEE-802.11p] 913 IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium 914 Access Control (MAC) and Physical Layer (PHY) 915 Specifications - Amendment 6: Wireless Access in Vehicular 916 Environments", IEEE Std 802.11p-2010, June 2010. 918 [IP-Passing-Protocol] 919 Chen, Y., Hsu, C., and W. Yi, "An IP Passing Protocol for 920 Vehicular Ad Hoc Networks with Network Fragmentation", 921 Elsevier Computers & Mathematics with Applications, 922 January 2012. 924 [IPv6-over-802.11-OCB] 925 Petrescu, A., Benamar, N., Haerri, J., Lee, J., and T. 926 Ernst, "Transmission of IPv6 Packets over IEEE 802.11 927 Networks operating in mode Outside the Context of a Basic 928 Service Set (IPv6-over-80211-OCB)", draft-ietf-ipwave- 929 ipv6-over-80211ocb-25 (work in progress), June 2018. 931 [IPv6-WAVE] 932 Baccelli, E., Clausen, T., and R. Wakikawa, "IPv6 933 Operation for WAVE - Wireless Access in Vehicular 934 Environments", IEEE Vehicular Networking Conference, 935 December 2010. 937 [ISO-ITS-IPv6] 938 ISO/TC 204, "Intelligent Transport Systems - 939 Communications Access for Land Mobiles (CALM) - IPv6 940 Networking", ISO 21210:2012, June 2012. 942 [Joint-IP-Networking] 943 Petrescu, A., Boc, M., and C. Ibars, "Joint IP Networking 944 and Radio Architecture for Vehicular Networks", 945 11th International Conference on ITS Telecommunications, 946 August 2011. 948 [LAGAD] Abrougui, K., Boukerche, A., and R. Pazzi, "Location-Aided 949 Gateway Advertisement and Discovery Protocol for VANets", 950 IEEE Transactions on Vehicular Technology, Vol. 59, No. 8, 951 October 2010. 953 [Multicast-802] 954 Perkins, C., Stanley, D., Kumari, W., and JC. Zuniga, 955 "Multicast Considerations over IEEE 802 Wireless Media", 956 draft-perkins-intarea-multicast-ieee802-03 (work in 957 progress), July 2017. 959 [Multicast-Alert] 960 Camara, D., Bonnet, C., Nikaein, N., and M. Wetterwald, 961 "Multicast and Virtual Road Side Units for Multi 962 Technology Alert Messages Dissemination", IEEE 8th 963 International Conference on Mobile Ad-Hoc and Sensor 964 Systems, October 2011. 966 [NEMO-LMS] 967 Soto, I., Bernardos, C., Calderon, M., Banchs, A., and A. 968 Azcorra, "NEMO-Enabled Localized Mobility Support for 969 Internet Access in Automotive Scenarios", 970 IEEE Communications Magazine, May 2009. 972 [NEMO-VANET] 973 Chen, Y., Hsu, C., and C. Cheng, "Network Mobility 974 Protocol for Vehicular Ad Hoc Networks", 975 Wiley International Journal of Communication Systems, 976 November 2014. 978 [PMIP-NEMO-Analysis] 979 Lee, J., Ernst, T., and N. Chilamkurti, "Performance 980 Analysis of PMIPv6-Based Network Mobility for Intelligent 981 Transportation Systems", IEEE Transactions on Vehicular 982 Technology, January 2012. 984 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 985 "Randomness Requirements for Security", RFC 4086, June 986 2005. 988 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 989 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 990 September 2007. 992 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 993 Address Autoconfiguration", RFC 4862, September 2007. 995 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 996 Extensions for Stateless Address Autoconfiguration in 997 IPv6", RFC 4941, September 2007. 999 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 1000 Hoc Networks", RFC 5889, September 2010. 1002 [RFC5944] Perkins, C., Ed., "IP Mobility Support in IPv4, Revised", 1003 RFC 5944, November 2010. 1005 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1006 Support in IPv6", RFC 6275, July 2011. 1008 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1009 February 2013. 1011 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1012 Discovery", RFC 6763, February 2013. 1014 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 1015 "Requirements for Distributed Mobility Management", 1016 RFC 7333, August 2014. 1018 [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. 1019 Bernardos, "Distributed Mobility Management: Current 1020 Practices and Gap Analysis", RFC 7429, January 2015. 1022 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1023 (IPv6) Specification", RFC 8200, July 2017. 1025 [SAINT] Jeong, J., Jeong, H., Lee, E., Oh, T., and D. Du, "SAINT: 1026 Self-Adaptive Interactive Navigation Tool for Cloud-Based 1027 Vehicular Traffic Optimization", IEEE Transactions on 1028 Vehicular Technology, Vol. 65, No. 6, June 2016. 1030 [SAINTplus] 1031 Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D. 1032 Du, "SAINT+: Self-Adaptive Interactive Navigation Tool+ 1033 for Emergency Service Delivery Optimization", 1034 IEEE Transactions on Intelligent Transportation Systems, 1035 June 2017. 1037 [SANA] Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation 1038 Application for Pedestrian Protection in Vehicular 1039 Networks", Springer Lecture Notes in Computer Science 1040 (LNCS), Vol. 9502, December 2015. 1042 [SDN-DMM] Nguyen, T., Bonnet, C., and J. Harri, "SDN-based 1043 Distributed Mobility Management for 5G Networks", 1044 IEEE Wireless Communications and Networking Conference, 1045 April 2016. 1047 [Securing-VCOMM] 1048 Fernandez, P., Santa, J., Bernal, F., and A. Skarmeta, 1049 "Securing Vehicular IPv6 Communications", 1050 IEEE Transactions on Dependable and Secure Computing, 1051 January 2016. 1053 [TR-22.886-3GPP] 1054 3GPP, "Study on Enhancement of 3GPP Support for 5G V2X 1055 Services", 3GPP TS 22.886, June 2018. 1057 [Truck-Platooning] 1058 California Partners for Advanced Transportation Technology 1059 (PATH), "Automated Truck Platooning", [Online] Available: 1060 http://www.path.berkeley.edu/research/automated-and- 1061 connected-vehicles/truck-platooning, 2017. 1063 [TS-23.285-3GPP] 1064 3GPP, "Architecture Enhancements for V2X Services", 3GPP 1065 TS 23.285, June 2018. 1067 [VANET-Geo-Routing] 1068 Tsukada, M., Jemaa, I., Menouar, H., Zhang, W., Goleva, 1069 M., and T. Ernst, "Experimental Evaluation for IPv6 over 1070 VANET Geographic Routing", IEEE International Wireless 1071 Communications and Mobile Computing Conference, June 2010. 1073 [VIP-WAVE] 1074 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 1075 Feasibility of IP Communications in 802.11p Vehicular 1076 Networks", IEEE Transactions on Intelligent Transportation 1077 Systems, March 2013. 1079 [VMaSC-LTE] 1080 Ucar, S., Ergen, S., and O. Ozkasap, "Multihop-Cluster- 1081 Based IEEE 802.11p and LTE Hybrid Architecture for VANET 1082 Safety Message Dissemination", IEEE Transactions on 1083 Vehicular Technology, April 2016. 1085 [VNET-AAA] 1086 Moustafa, H., Bourdon, G., and Y. Gourhant, "Providing 1087 Authentication and Access Control in Vehicular Network 1088 Environment", IFIP TC-11 International Information 1089 Security Conference, May 2006. 1091 [VNET-MM] Peng, Y. and J. Chang, "A Novel Mobility Management Scheme 1092 for Integration of Vehicular Ad Hoc Networks and Fixed IP 1093 Networks", Springer Mobile Networks and Applications, 1094 February 2010. 1096 [WAVE-1609.0] 1097 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 1098 in Vehicular Environments (WAVE) - Architecture", IEEE Std 1099 1609.0-2013, March 2014. 1101 [WAVE-1609.2] 1102 IEEE 1609 Working Group, "IEEE Standard for Wireless 1103 Access in Vehicular Environments - Security Services for 1104 Applications and Management Messages", IEEE Std 1105 1609.2-2016, March 2016. 1107 [WAVE-1609.3] 1108 IEEE 1609 Working Group, "IEEE Standard for Wireless 1109 Access in Vehicular Environments (WAVE) - Networking 1110 Services", IEEE Std 1609.3-2016, April 2016. 1112 [WAVE-1609.4] 1113 IEEE 1609 Working Group, "IEEE Standard for Wireless 1114 Access in Vehicular Environments (WAVE) - Multi-Channel 1115 Operation", IEEE Std 1609.4-2016, March 2016. 1117 Appendix A. Relevant Work Items to IPWAVE 1119 This section discusses relevant work items to IPWAVE: (i) vehicle 1120 identity management; (ii) multihop V2X; (iii) multicast; (iv) DNS 1121 naming services and service discovery; (v) IPv6 over cellular 1122 networks. 1124 A.1. Vehicle Identity Management 1126 A vehicle can have multiple network interfaces using different access 1127 network technologies [Identity-Management]. These multiple network 1128 interfaces mean multiple identities. To identify a vehicle with 1129 multiple indenties, a Vehicle Identification Number (VIN) can be used 1130 as a globally unique vehicle identifier. 1132 To support the seamless connectivity over the multiple identities, a 1133 cross-layer network architecture is required with vertical handover 1134 functionality [Identity-Management]. Also, an AAA service for 1135 multiple identities should be provided to vehicles in an efficient 1136 way to allow horizontal handover as well as vertical handover; note 1137 that AAA stands for Authentication, Authorization, and Accounting. 1139 A.2. Multihop V2X 1141 Multihop packet forwarding among vehicles in 802.11-OCB mode shows an 1142 unfavorable performance due to the common known broadcast-storm 1143 problem [Broadcast-Storm]. This broadcast-storm problem can be 1144 mitigated by the coordination (or scheduling) of a cluster head in a 1145 connected VANET or an RSU in an intersection area, which is a 1146 coordinator for the access to wireless channels. 1148 A.3. Multicast 1150 IP multicast in vehicular network environments is especially useful 1151 for various services. For instance, an automobile manufacturer can 1152 multicast a particular group/class/type of vehicles for service 1153 notification. As another example, a vehicle or an RSU can 1154 disseminate alert messages in a particular area [Multicast-Alert]. 1156 In general IEEE 802 wireless media, some performance issues about 1157 multicast are found in [Multicast-802]. Since serveral procedures 1158 and functions based on IPv6 use multicast for control-plane messages, 1159 such as Neighbor Discovery (called ND) and Service Discovery, 1160 [Multicast-802] describes that the ND process may fail due to 1161 unreliable wireless link, causing failure of the DAD process. Also, 1162 the Router Advertisement messages can be lost in multicasting. 1164 A.4. DNS Naming Services and Service Discovery 1166 When two vehicular nodes communicate with each other with the DNS 1167 name of the partner node, DNS naming service (i.e., DNS name 1168 resolution) is required. As shown in Figure 2 and Figure 3, a 1169 recursive DNS server (called RDNSS) within an internal network can 1170 perform such DNS name resolution for the sake of other vehicular 1171 nodes. 1173 A service discovery service is required for an application in a 1174 vehicular node to search for another application or server in another 1175 vehicular node, which resides in either the same internal network or 1176 the other internal network. In V2I or V2V networking, as shown in 1177 Figure 2 and Figure 3, such a service discovery service can be 1178 provided by either DNS-based Service Discovery (DNS-SD) [RFC6763] 1179 with mDNS [RFC6762] or the vehicular ND with a new option for service 1180 discovery [ID-Vehicular-ND]. 1182 A.5. IPv6 over Cellular Networks 1184 Recently, 3GPP has announced a new technical specification, Release 1185 14 (3GPP-R14), which proposes an architecture enhancements for V2X 1186 services using the modified sidelink interface that originally is 1187 designed for the LTE-D2D communications. 3GPP-R14 regulates that the 1188 V2X services only support IPv6 implementation. 3GPP is also 1189 investigating and discussing the evolved V2X services in the next 1190 generation cellular networks, i.e., 5G new radio (5G-NR), for 1191 advanced V2X communications and automated vehicles' applications. 1193 A.5.1. Cellular V2X (C-V2X) Using 4G-LTE 1195 Before 3GPP-R14, some researchers have studied the potential usage of 1196 C-V2X communications. For example, [VMaSC-LTE] explores a multihop 1197 cluster-based hybrid architecture using both DSRC and LTE for safety 1198 message dissemination. Most of the research consider a short message 1199 service for safety instead of IP datagram forwarding. In other C-V2X 1200 research, the standard IPv6 is assumed. 1202 The 3GPP technical specification [TS-23.285-3GPP] states that both IP 1203 based and non-IP based V2X messages are supported, and only IPv6 is 1204 supported for IP based messages. Moreover, [TS-23.285-3GPP] 1205 instructs that a UE autoconfigures a link- local IPv6 address by 1206 following [RFC4862], but without sending Neighbor Solicitation and 1207 Neighbor Advertisement messages for DAD. 1209 A.5.2. Cellular V2X (C-V2X) Using 5G 1211 The emerging services, functions and applications in automotive 1212 industry spurs ehhanced V2X (eV2X)-based services in the future 5G 1213 era. The 3GPP Technical Report [TR-22.886-3GPP] is studying new use 1214 cases for V2X using 5G in the future. 1216 Appendix B. Changes from draft-ietf-ipwave-vehicular-networking-03 1218 The following changes are made from draft-ietf-ipwave-vehicular- 1219 networking-03: 1221 o EU wireless channel allocation (frequency band 5.875 - 5.905 GHz) 1222 for vehicular networking was specified in Section 1. 1224 o Relevant work items to IPWAVE is discussed in Appendix A as 1225 follows: (i) vehicle identity management; (ii) multihop V2X; (iii) 1226 multicast; (iv) DNS naming services and service discovery; (v) 1227 IPv6 over cellular networks. 1229 Appendix C. Acknowledgments 1231 This work was supported by Basic Science Research Program through the 1232 National Research Foundation of Korea (NRF) funded by the Ministry of 1233 Education (2017R1D1A1B03035885). 1235 This work was supported in part by Global Research Laboratory Program 1236 through the NRF funded by the Ministry of Science and ICT (MSIT) 1237 (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT 1238 (18-EE-01). 1240 This work was supported in part by the French research project 1241 DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded 1242 by the European Commission I (636537-H2020). 1244 Appendix D. Contributors 1246 This document is a group work of IPWAVE working group, greatly 1247 benefiting from inputs and texts by Rex Buddenberg (Naval 1248 Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest 1249 University of Technology and Economics), Jose Santa Lozanoi 1250 (Universidad of Murcia), Richard Roy (MIT), Francois Simon (Pilot), 1251 and Sri Gundavelli (Cisco). The authors sincerely appreciate their 1252 contributions. 1254 The following are co-authors of this document: 1256 Nabil Benamar 1257 Department of Computer Sciences 1258 High School of Technology of Meknes 1259 Moulay Ismail University 1260 Morocco 1262 Phone: +212 6 70 83 22 36 1263 EMail: benamar73@gmail.com 1265 Sandra Cespedes 1266 Department of Electrical Engineering 1267 Universidad de Chile 1268 Av. Tupper 2007, Of. 504 1269 Santiago, 8370451 1270 Chile 1272 Phone: +56 2 29784093 1273 EMail: scespede@niclabs.cl 1275 Jerome Haerri 1276 Communication Systems Department 1277 EURECOM 1278 Sophia-Antipolis 1279 France 1281 Phone: +33 4 93 00 81 34 1282 EMail: jerome.haerri@eurecom.fr 1284 Dapeng Liu 1285 Alibaba 1286 Beijing, Beijing 100022 1287 China 1289 Phone: +86 13911788933 1290 EMail: max.ldp@alibaba-inc.com 1292 Tae (Tom) Oh 1293 Department of Information Sciences and Technologies 1294 Rochester Institute of Technology 1295 One Lomb Memorial Drive 1296 Rochester, NY 14623-5603 1297 USA 1299 Phone: +1 585 475 7642 1300 EMail: Tom.Oh@rit.edu 1302 Charles E. Perkins 1303 Futurewei Inc. 1304 2330 Central Expressway 1305 Santa Clara, CA 95050 1306 USA 1308 Phone: +1 408 330 4586 1309 EMail: charliep@computer.org 1311 Alexandre Petrescu 1312 CEA, LIST 1313 CEA Saclay 1314 Gif-sur-Yvette, Ile-de-France 91190 1315 France 1317 Phone: +33169089223 1318 EMail: Alexandre.Petrescu@cea.fr 1320 Yiwen Chris Shen 1321 Department of Computer Science & Engineering 1322 Sungkyunkwan University 1323 2066 Seobu-Ro, Jangan-Gu 1324 Suwon, Gyeonggi-Do 16419 1325 Republic of Korea 1327 Phone: +82 31 299 4106 1328 Fax: +82 31 290 7996 1329 EMail: chrisshen@skku.edu 1330 URI: http://iotlab.skku.edu/people-chris-shen.php 1332 Michelle Wetterwald 1333 FBConsulting 1334 21, Route de Luxembourg 1335 Wasserbillig, Luxembourg L-6633 1336 Luxembourg 1338 EMail: Michelle.Wetterwald@gmail.com 1340 Author's Address 1342 Jaehoon Paul Jeong (editor) 1343 Department of Software 1344 Sungkyunkwan University 1345 2066 Seobu-Ro, Jangan-Gu 1346 Suwon, Gyeonggi-Do 16419 1347 Republic of Korea 1349 Phone: +82 31 299 4957 1350 Fax: +82 31 290 7996 1351 EMail: pauljeong@skku.edu 1352 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php