idnits 2.17.1 draft-ietf-ipwave-vehicular-networking-03.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 2, 2018) is 2125 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Online' is mentioned on line 1159, 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 == Outdated reference: A later version (-52) exists of draft-ietf-ipwave-ipv6-over-80211ocb-25 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 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 2, 2018 5 Expires: January 3, 2019 7 IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement 8 and Use Cases 9 draft-ietf-ipwave-vehicular-networking-03 11 Abstract 13 This document discusses problem statement and use cases on IP-based 14 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, this document analyzes current protocols for 20 vehicular networking and general problems on those current protocols. 21 Third, this document does problem exploration for key aspects in IP- 22 based vehicular networking, such as IPv6 over IEEE 802.11-OCB, IPv6 23 Neighbor Discovery, Mobility Management, Vehicle Identities 24 Management, Multihop V2X Communications, Multicast, DNS Naming 25 Services, Service Discovery, IPv6 over Cellular Networks, Security 26 and Privacy. For each key aspect, this document discusses problem 27 statement to analyze the gap between the state-of-the-art techniques 28 and requirements in IP-based vehicular networking. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 3, 2019. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4. Analysis for Current Protocols . . . . . . . . . . . . . . . 7 71 4.1. Current Protocols for Vehicular Networking . . . . . . . 7 72 4.1.1. IP Address Autoconfiguration . . . . . . . . . . . . 7 73 4.1.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.1.3. Mobility Management . . . . . . . . . . . . . . . . . 8 75 4.1.4. DNS Naming Service . . . . . . . . . . . . . . . . . 8 76 4.1.5. Service Discovery . . . . . . . . . . . . . . . . . . 8 77 4.1.6. Security and Privacy . . . . . . . . . . . . . . . . 9 78 4.2. General Problems . . . . . . . . . . . . . . . . . . . . 9 79 4.2.1. Vehicular Network Architecture . . . . . . . . . . . 9 80 4.2.2. Latency . . . . . . . . . . . . . . . . . . . . . . . 14 81 4.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 14 82 4.2.4. Pseudonym Handling . . . . . . . . . . . . . . . . . 14 83 5. Problem Exploration . . . . . . . . . . . . . . . . . . . . . 14 84 5.1. IPv6 over IEEE 802.11-OCB . . . . . . . . . . . . . . . . 15 85 5.2. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 15 86 5.2.1. Link Model . . . . . . . . . . . . . . . . . . . . . 15 87 5.2.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 16 88 5.2.3. Prefix Dissemination/Exchange . . . . . . . . . . . . 16 89 5.2.4. Routing . . . . . . . . . . . . . . . . . . . . . . . 16 90 5.3. Mobility Management . . . . . . . . . . . . . . . . . . . 16 91 5.4. Vehicle Identity Management . . . . . . . . . . . . . . . 17 92 5.5. Multihop V2X . . . . . . . . . . . . . . . . . . . . . . 17 93 5.6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 17 94 5.7. DNS Naming Services and Service Discovery . . . . . . . . 17 95 5.8. IPv6 over Cellular Networks . . . . . . . . . . . . . . . 18 96 5.8.1. Cellular V2X (C-V2X) Using 4G-LTE . . . . . . . . . . 19 97 5.8.2. Cellular V2X (C-V2X) Using 5G . . . . . . . . . . . . 19 98 5.9. Security and Privacy . . . . . . . . . . . . . . . . . . 19 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 100 7. Informative References . . . . . . . . . . . . . . . . . . . 20 101 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 28 102 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 28 103 Appendix C. Changes from draft-ietf-ipwave-vehicular- 104 networking-02 . . . . . . . . . . . . . . . . . . . 30 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 107 1. Introduction 109 Vehicular networks have been focused on the driving safety, driving 110 efficiency, and entertainment in road networks. The Federal 111 Communications Commission (FCC) in the US allocated wireless channels 112 for Dedicated Short-Range Communications (DSRC) [DSRC], service in 113 the Intelligent Transportation Systems (ITS) Radio Service in the 114 5.850 - 5.925 GHz band (5.9 GHz band). DSRC-based wireless 115 communications can support vehicle-to-vehicle (V2V), vehicle-to- 116 infrastructure (V2I), and vehicle-to-everything (V2X) networking. 118 For driving safety services based on the DSRC, IEEE has standardized 119 Wireless Access in Vehicular Environments (WAVE) standards, such as 120 IEEE 802.11p [IEEE-802.11p], IEEE 1609.2 [WAVE-1609.2], IEEE 1609.3 121 [WAVE-1609.3], and IEEE 1609.4 [WAVE-1609.4]. Note that IEEE 802.11p 122 has been published as IEEE 802.11 Outside the Context of a Basic 123 Service Set (OCB) [IEEE-802.11-OCB] in 2012. Along with these WAVE 124 standards, IPv6 and Mobile IP protocols (e.g., MIPv4 and MIPv6) can 125 be extended to vehicular networks [RFC2460][RFC5944][RFC6275]. Also, 126 ETSI has standardized a GeoNetworking (GN) protocol 127 [ETSI-GeoNetworking] and a protocol adaptation sub-layer from 128 GeoNetworking to IPv6 [ETSI-GeoNetwork-IP]. In addition, ISO has 129 standardized a standard specifying the IPv6 network protocols and 130 services for Communications Access for Land Mobiles (CALM) 131 [ISO-ITS-IPv6]. 133 This document discusses problem statements and use cases related to 134 IP-based vehicular networking for Intelligent Transportation Systems 135 (ITS). This document first surveys the use cases for using V2V and 136 V2I networking in the ITS. Second, for problem statement, this 137 document deals with critical aspects in vehicular networking, such as 138 IPv6 over IEEE 802.11-OCB, IPv6 Neighbor Discovery, Mobility 139 Management, Vehicle Identities Management, Multihop V2X 140 Communications, Multicast, DNS Naming Services, Service Discovery, 141 IPv6 over Cellular Networks, Security and Privacy. For each key 142 aspect, this document discusses problem statement to analyze the gap 143 between the state-of-the-art techniques and requirements in IP-based 144 vehicular networking. Finally, with the problem statement, this 145 document suggests demanding key standardization items for the 146 deployment of IPWAVE in road environments. As a consequence, this 147 will make it possible to design a network architecture and protocols 148 for vehicular networking. 150 2. Terminology 152 This document uses the following definitions: 154 o WAVE: Acronym for "Wireless Access in Vehicular Environments" 155 [WAVE-1609.0]. 157 o DMM: Acronym for "Distributed Mobility Management" 158 [RFC7333][RFC7429]. 160 o Road-Side Unit (RSU): A node that has physical communication 161 devices (e.g., DSRC, Visible Light Communication, 802.15.4, LTE- 162 V2X, etc.) for wireless communications with vehicles and is also 163 connected to the Internet as a router or switch for packet 164 forwarding. An RSU is deployed either at an intersection or in a 165 road segment. 167 o On-Board Unit (OBU): A node that has a DSRC device for wireless 168 communications with other OBUs and RSUs. An OBU is mounted on a 169 vehicle. It is assumed that a radio navigation receiver (e.g., 170 Global Positioning System (GPS)) is included in a vehicle with an 171 OBU for efficient navigation. 173 o Vehicle Detection Loop (or Loop Detector): An inductive device 174 used for detecting vehicles passing or arriving at a certain 175 point, for instance approaching a traffic light or in motorway 176 traffic. The relatively crude nature of the loop's structure 177 means that only metal masses above a certain size are capable of 178 triggering the detection. 180 o Traffic Control Center (TCC): A node that maintains road 181 infrastructure information (e.g., RSUs, traffic signals, and loop 182 detectors), vehicular traffic statistics (e.g., average vehicle 183 speed and vehicle inter-arrival time per road segment), and 184 vehicle information (e.g., a vehicle's identifier, position, 185 direction, speed, and trajectory as a navigation path). TCC is 186 included in a vehicular cloud for vehicular networks. 188 3. Use Cases 190 This section provides use cases of V2V, V2I, and V2X networking. The 191 use cases of the V2X networking exclude the ones of the V2V and V2I 192 networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to- 193 Device (V2D). 195 3.1. V2V 197 The use cases of V2V networking discussed in this section include 199 o Context-aware navigation for driving safety and collision 200 avoidance; 202 o Cooperative adaptive cruise control in an urban roadway; 204 o Platooning in a highway; 206 o Cooperative environment sensing. 208 These four techniques will be important elements for self-driving 209 vehicles. 211 Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers 212 to drive safely by letting the drivers recognize dangerous obstacles 213 and situations. That is, CASD navigator displays obstables or 214 neighboring vehicles relevant to possible collisions in real-time 215 through V2V networking. CASD provides vehicles with a class-based 216 automatic safety action plan, which considers three situations, such 217 as the Line-of-Sight unsafe, Non-Line-of-Sight unsafe and safe 218 situations. This action plan can be performed among vehicles through 219 V2V networking. 221 Cooperative Adaptive Cruise Control (CACC) [CA-Cuise-Control] helps 222 vehicles to adapt their speed autonomously through V2V communication 223 among vehicles according to the mobility of their predecessor and 224 successor vehicles in an urban roadway or a highway. CACC can help 225 adjacent vehicles to efficiently adjust their speed in a cascade way 226 through V2V networking. 228 Platooning [Truck-Platooning] allows a series of vehicles (e.g., 229 trucks) to move together with a very short inter-distance. Trucks 230 can use V2V communication in addition to forward sensors in order to 231 maintain constant clearance between two consecutive vehicles at very 232 short gaps (from 3 meters to 10 meters). This platooning can 233 maximize the throughput of vehicular traffic in a highway and reduce 234 the gas consumption because the leading vehicle can help the 235 following vehicles to experience less air resistance. 237 Cooperative-environment-sensing use cases suggest that vehicles can 238 share environment information from various sensors, such as radars, 239 LiDARs and cameras, mounted on them with other vehicles and 240 pedestrians. [Automotive-Sensing] introduces a millimeter-wave 241 vehicular communication for massive automotive sensing. Data 242 generated by those sensors can be substantially large, and these data 243 shall be routed to different destinations. In addition, from the 244 perspective of driverless vehicles, it is expected that driverless 245 vehicles can be mixed with driver vehicles. Through cooperative 246 enivronment sensing, driver vehicles can use enivronment information 247 sensed by driverless vehicles for better interaction with 248 environments. 250 3.2. V2I 252 The use cases of V2I networking discussed in this section include 254 o Navigation service; 256 o Energy-efficient speed recommendation service; 258 o Accident notification service. 260 A navigation service, such as the Self-Adaptive Interactive 261 Navigation Tool (called SAINT) [SAINT], using V2I networking 262 interacts with TCC for the global road traffic optimization and can 263 guide individual vehicles for appropriate navigation paths in real 264 time. The enhanced SAINT (called SAINT+) [SAINTplus] can give the 265 fast moving paths for emergency vehicles (e.g., ambulance and fire 266 engine) toward accident spots while providing other vehicles with 267 efficient detour paths. 269 A TCC can recommend an energy-efficient speed to a vehicle driving in 270 different traffic environments. [Fuel-Efficient] studys fuel- 271 efficient route and speed plans for platooned trucks. 273 The emergency communication between accident vehicles (or emergency 274 vehicles) and TCC can be performed via either RSU or 4G-LTE networks. 275 The First Responder Network Authority (FirstNet) [FirstNet] is 276 provided by the US government to establish, operate, and maintain an 277 interoperable public safety broadband network for safety and security 278 network services, such as emergency calls. The construction of the 279 nationwide FirstNet network requires each state in the US to have a 280 Radio Access Network (RAN) that will connect to FirstNet's network 281 core. The current RAN is mainly constructed by 4G-LTE for the 282 communication between a vehicle and an infrastructure node (i.e., 283 V2I) [FirstNet-Annual-Report-2017], but DSRC-based vehicular networks 284 can be used for V2I in near future [DSRC]. 286 3.3. V2X 288 The use case of V2X networking discussed in this section is 289 pedestrian protection service. 291 A pedestrian protection service, such as Safety-Aware Navigation 292 Application (called SANA) [SANA], using V2I2P networking can reduce 293 the collision of a pedestrian and a vehicle, which have a smartphone, 294 in a road network. Vehicles and pedestrians can communicate with 295 each other via an RSU that delivers scheduling information for 296 wireless communication to save the smartphones' battery. 298 4. Analysis for Current Protocols 300 4.1. Current Protocols for Vehicular Networking 302 We analyze the current protocols from the follow aspects: 304 o IP address autoconfiguration; 306 o Routing; 308 o Mobility management; 310 o DNS naming service; 312 o Service discovery; 314 o Security and privacy. 316 4.1.1. IP Address Autoconfiguration 318 For IP address autoconfiguration, Fazio et al. proposed a vehicular 319 address configuration (VAC) scheme using DHCP where elected leader- 320 vehicles provide unique identifiers for IP address configurations 321 [Address-Autoconf]. Kato et al. proposed an IPv6 address assignment 322 scheme using lane and position information [Address-Assignment]. 323 Baldessari et al. proposed an IPv6 scalable address autoconfiguration 324 scheme called GeoSAC for vehicular networks [GeoSAC]. Wetterwald et 325 al. conducted a comprehensive study of the cross-layer identities 326 management in vehicular networks using multiple access network 327 technologies, which constitutes a fundamental element of the ITS 328 architecture [Identity-Management]. 330 4.1.2. Routing 332 For routing, Tsukada et al. presented a work that aims at combining 333 IPv6 networking and a Car-to-Car Network routing protocol (called 334 C2CNet) proposed by the Car2Car Communication Consortium (C2C-CC), 335 which is an architecture using a geographic routing protocol 336 [VANET-Geo-Routing]. Abrougui et al. presented a gateway discovery 337 scheme for VANET, called Location-Aided Gateway Advertisement and 338 Discovery (LAGAD) mechanism [LAGAD]. 340 4.1.3. Mobility Management 342 For mobility management, Chen et al. tackled the issue of network 343 fragmentation in VANET environments [IP-Passing-Protocol] by 344 proposing a protocol that can postpone the time to release IP 345 addresses to the DHCP server and select a faster way to get the 346 vehicle's new IP address, when the vehicle density is low or the 347 speeds of vehicles are varied. Nguyen et al. proposed a hybrid 348 centralized-distributed mobility management called H-DMM to support 349 highly mobile vehicles [H-DMM]. [NEMO-LMS] proposed an architecture 350 to enable IP mobility for moving networks using a network-based 351 mobility scheme based on PMIPv6. Chen et al. proposed a network 352 mobility protocol to reduce handoff delay and maintain Internet 353 connectivity to moving vehicles in a highway [NEMO-VANET]. Lee et 354 al. proposed P-NEMO, which is a PMIPv6-based IP mobility management 355 scheme to maintain the Internet connectivity at the vehicle as a 356 mobile network, and provides a make-before-break mechanism when 357 vehicles switch to a new access network [PMIP-NEMO-Analysis]. Peng 358 et al. proposed a novel mobility management scheme for integration of 359 VANET and fixed IP networks [VNET-MM]. Nguyen et al. extended their 360 previous works on a vehicular adapted DMM considering a Software- 361 Defined Networking (SDN) architecture [SDN-DMM]. 363 4.1.4. DNS Naming Service 365 For DNS naming service, Multicast DNS (mDNS) [RFC6762] allows devices 366 in one-hop communication range to resolve each other's DNS name into 367 the corresponding IP address in multicast. DNS Name 368 Autoconfiguration (DNSNA) [ID-DNSNA] proposes a DNS naming service 369 for Internet-of-Things (IoT) devices in a large-scale network. 371 4.1.5. Service Discovery 373 For service discovery, as a popular existing service discovery 374 protocol, DNS-based Service Discovery (DNS-SD) [RFC6763] with mDNS 375 [RFC6762] provides service discovery. Vehicular ND [ID-Vehicular-ND] 376 proposes an extension of IPv6 ND for the prefix and service 377 discovery. 379 4.1.6. Security and Privacy 381 For security and privacy, Fernandez et al. proposed a secure 382 vehicular IPv6 communication scheme using Internet Key Exchange 383 version 2 (IKEv2) and Internet Protocol Security (IPsec) 384 [Securing-VCOMM]. Moustafa et al. proposed a security scheme 385 providing authentication, authorization, and accounting (AAA) 386 services in vehicular networks [VNET-AAA]. 388 4.2. General Problems 390 This section describes a vehicular network architecture for V2V and 391 V2I communications. Then it analyzes the limitations of the current 392 protocols for vehicular networking. 394 4.2.1. Vehicular Network Architecture 396 Figure 1 shows an architecture for V2I and V2V networking in a road 397 network. The two RSUs (RSU1 and RSU2) are deployed in the road 398 network and are connected to a Vehicular Cloud through the Internet. 399 TCC is connected to the Vehicular Cloud and the two vehicles 400 (Vehicle1 and Vehicle2) are wirelessly connected to RSU1, and the 401 last vehicle (Vehicle3) is wirelessly connected to RSU2. Vehicle1 402 can communicate with Vehicle2 via V2V communication, and Vehicle2 can 403 communicate with Vehicle3 via V2V communication. Vehicle1 can 404 communicate with Vehicle3 via RSU1 and RSU2 via V2I communication. 406 *-------------* 407 * * .-------. 408 * Vehicular Cloud *<------>| TCC | 409 * * ._______. 410 *-------------* 411 ^ ^ 412 | | 413 | | 414 v v 415 .--------. .--------. 416 | RSU1 |<----------->| RSU2 | 417 .________. .________. 418 ^ ^ ^ 419 : : : 420 : : : 421 v v v 422 .--------. .--------. .--------. 423 |Vehicle1|=> |Vehicle2|=> |Vehicle3|=> 424 | |<....>| |<....>| | 425 .________. .________. .________. 427 <----> Wired Link <....> Wireless Link => Moving Direction 429 Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 431 In vehicular networks, unidirectional links exist and must be 432 considered for wireless communications. Also, in the vehicular 433 networks, control plane must be separated from data plane for 434 efficient mobility management and data forwarding. ID/Pseudonym 435 change for privacy requires a lightweight DAD. IP tunneling should 436 be avoided for performance efficiency. The mobility information of a 437 mobile device (e.g., vehicle), such as trajectory, position, speed, 438 and direction, can be used by the mobile device and infrastructure 439 nodes (e.g., TCC and RSU) for the accommodation of proactive 440 protocols because it is usually equipped with a GPS receiver. 441 Vehicles can use the TCC as its Home Network, so the TCC maintains 442 the mobility information of vehicles for location management. 444 Cespedes et al. proposed a vehicular IP in WAVE called VIP-WAVE for 445 I2V and V2I networking [VIP-WAVE]. The standard WAVE does not 446 support both seamless communications for Internet services and multi- 447 hop communications between a vehicle and an infrastructure node 448 (e.g., RSU), either. To overcome these limitations of the standard 449 WAVE, VIP-WAVE enhances the standard WAVE by the following three 450 schemes: (i) an efficient mechanism for the IPv6 address assignment 451 and DAD, (ii) on-demand IP mobility based on Proxy Mobile IPv6 452 (PMIPv6), and (iii) one-hop and two-hop communications for I2V and 453 V2I networking. 455 Baccelli et al. provided an analysis of the operation of IPv6 as it 456 has been described by the IEEE WAVE standards 1609 [IPv6-WAVE]. This 457 analysis confirms that the use of the standard IPv6 protocol stack in 458 WAVE is not sufficient. It recommebs that the IPv6 addressing 459 assignment should follow considerations for ad-hoc link models, 460 defined in [RFC5889] for nodes' mobility and link variability. 462 Petrescu et al. proposed the joint IP networking and radio 463 architecture for V2V and V2I communication in [Joint-IP-Networking]. 464 The proposed architecture considers an IP topology in a similar way 465 as a radio link topology, in the sense that an IP subnet would 466 correspond to the range of 1-hop vehicular communication. This 467 architecture defines three types of vehicles: Leaf Vehicle, Range 468 Extending Vehicle, and Internet Vehicle. 470 4.2.1.1. V2I-based Internetworking 472 This section discusses the internetworking between a vehicle's moving 473 network and an RSU's fixed network. 475 As shown in Figure 2, the vehicle's moving network and the RSU's 476 fixed network are self-contained networks having multiple subnets and 477 having an edge router for the communication with another vehicle or 478 RSU. The method of prefix assignment for each subnet inside the 479 vehicle's mobile network and the RSU's fixed network is out of scope 480 for this document. Internetworking between two internal networks via 481 either V2I or V2V communication requires an exchange of network 482 prefix and other parameters. 484 The network parameter discovery collects networking information for 485 an IP communication between a vehicle and an RSU or between two 486 neighboring vehicles, such as link layer, MAC layer, and IP layer 487 information. The link layer information includes wireless link layer 488 parameters, such as wireless media (e.g., IEEE 802.11 OCB, LTE D2D, 489 Bluetooth, and LiFi) and a transmission power level. The MAC layer 490 information includes the MAC address of an external network interface 491 for the internetworking with another vehicle or RSU. The IP layer 492 information includes the IP address and prefix of an external network 493 interface for the internetworking with another vehicle or RSU. 495 (*)<..........>(*) 496 | | 2001:DB8:1:1::/64 497 .------------------------------. .---------------------------------. 498 | | | | | | 499 | .-------. .------. .-------. | | .-------. .------. .-------. | 500 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 501 | ._______. .______. ._______. | | ._______. .______. ._______. | 502 | ^ ^ ^ | | ^ ^ ^ | 503 | | | | | | | | | | 504 | v v v | | v v v | 505 | ---------------------------- | | ------------------------------- | 506 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 507 | | | | | | 508 | v | | v | 509 | .-------. .-------. | | .-------. .-------. .-------. | 510 | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | 511 | ._______. ._______. | | ._______. ._______. ._______. | 512 | ^ ^ | | ^ ^ ^ | 513 | | | | | | | | | 514 | v v | | v v v | 515 | ---------------------------- | | ------------------------------- | 516 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 517 .______________________________. ._________________________________. 518 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 520 <----> Wired Link <....> Wireless Link (*) Antenna 522 Figure 2: Internetworking between Vehicle Network and RSU Network 524 Once the network parameter discovery and prefix exchange operations 525 have been performed, packets can be transmitted between the vehicle's 526 moving network and the RSU's fixed network. DNS should be supported 527 to enable name resolution for hosts or servers residing either in the 528 vehicle's moving network or the RSU's fixed network. 530 Figure 2 shows internetworking between the vehicle's moving network 531 and the RSU's fixed network. There exists an internal network 532 (Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server 533 (RDNSS1), the two hosts (Host1 and Host2), and the two routers 534 (Router1 and Router2). There exists another internal network (Fixed 535 Network1) inside RSU1. RSU1 has the DNS Server (RDNSS2), one host 536 (Host3), the two routers (Router3 and Router4), and the collection of 537 servers (Server1 to ServerN) for various services in the road 538 networks, such as the emergency notification and navigation. 539 Vehicle1's Router1 (called mobile router) and RSU1's Router3 (called 540 fixed router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) 541 for I2V networking. 543 4.2.1.2. V2V-based Internetworking 545 This section discusses the internetworking between the moving 546 networks of two neighboring vehicles in Figure 3. 548 (*)<..........>(*) 549 | | 2001:DB8:1:1::/64 550 .------------------------------. .---------------------------------. 551 | | | | | | 552 | .-------. .------. .-------. | | .-------. .------. .-------. | 553 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 554 | ._______. .______. ._______. | | ._______. .______. ._______. | 555 | ^ ^ ^ | | ^ ^ ^ | 556 | | | | | | | | | | 557 | v v v | | v v v | 558 | ---------------------------- | | ------------------------------- | 559 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:30:1::/64 | 560 | | | | | | 561 | v | | v | 562 | .-------. .-------. | | .-------. .-------. | 563 | | Host2 | |Router2| | | |Router4| | Host4 | | 564 | ._______. ._______. | | ._______. ._______. | 565 | ^ ^ | | ^ ^ | 566 | | | | | | | | 567 | v v | | v v | 568 | ---------------------------- | | ------------------------------- | 569 | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | 570 .______________________________. ._________________________________. 571 Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) 573 <----> Wired Link <....> Wireless Link (*) Antenna 575 Figure 3: Internetworking between Two Vehicle Networks 577 In Figure 3, the prefix assignment for each subnet inside each 578 vehicle's mobile network is done through a prefix delegation 579 protocol. 581 Figure 3 shows internetworking between the moving networks of two 582 neighboring vehicles. There exists an internal network (Moving 583 Network1) inside Vehicle1. Vehicle1 has the DNS Server (RDNSS1), the 584 two hosts (Host1 and Host2), and the two routers (Router1 and 585 Router2). There exists another internal network (Moving Network2) 586 inside Vehicle2. Vehicle2 has the DNS Server (RDNSS2), the two hosts 587 (Host3 and Host4), and the two routers (Router3 and Router4). 588 Vehicle1's Router1 (called mobile router) and Vehicle2's Router3 589 (called mobile router) use 2001:DB8:1:1::/64 for an external link 590 (e.g., DSRC) for V2V networking. 592 The differences between IPWAVE (including Vehicular Ad Hoc Networks 593 (VANET)) and Mobile Ad Hoc Networks (MANET) are as follows: 595 o IPWAVE is not power-constrained operation; 597 o Traffic can be sourced or sinked outside of IPWAVE; 599 o IPWAVE shall support both distributed and centralized operations; 601 o No "sleep" period operation is required for energy saving. 603 4.2.2. Latency 605 The communication delay (i.e., latency) between two vehicular nodes 606 (vehicle and RSU) should be bounded to a certain threshold. For IP- 607 based safety applications (e.g., context-aware navigation, adaptive 608 cruise control, and platooning) in vehicular network, this bounded 609 data delivery is critical. The real implementations for such 610 applications are not available, so the feasibility of IP-based safety 611 applications is not tested yet. 613 4.2.3. Security 615 Security protects vehicles roaming in road networks from the attacks 616 of malicious vehicular nodes, which are controlled by hackers. For 617 safety applications, the cooperation among vehicles is assumed. 618 Malicious vehicular nodes may disseminate wrong driving information 619 (e.g., location, speed, and direction) to make driving be unsafe. 620 Sybil attack, which tries to illude a vehicle with multiple false 621 identities, disturbs a vehicle in taking a safe maneuver. 622 Applications on IP-based vehicular networking, which are resilient to 623 such a sybil attack, are not developed and tested yet. 625 4.2.4. Pseudonym Handling 627 For the protection of privacy, pseudonym for a vehicle's network 628 interface is used, which the interface's identifier is changed 629 periodically. Such a pseudonym affects an IPv6 address based on the 630 network interface's identifier, and a transport-layer session with an 631 IPv6 address pair. The pseudonym handling is not implemented and 632 test yet for applications on IP-based vehicular networking. 634 5. Problem Exploration 635 5.1. IPv6 over IEEE 802.11-OCB 637 IPv6 over IEEE 802.11-OCB generally follows the standard IPv6 638 procedure. [IPv6-over-80211-OCB] specifies several details for IPv6 639 packets transporting over IEEE 802.11-OCB. Especially, an Ethernet 640 Adaptation (EA) layer is suggested to be inserted between Logical 641 Link Control layer and Network layer. The EA layer is mainly in 642 charge of transforming some parameters between 802.11 MAC layer and 643 IPv6 layer. 645 5.2. Neighbor Discovery 647 Neighbor Discovery (ND) [RFC4861] is a core part of the IPv6 protocol 648 suite. This section discusses the need for modifying ND for use with 649 vehicular networking (e.g., V2V and V2I). The vehicles are moving 650 fast within the communication coverage of a vehicular node (e.g., 651 vehicle and RSU). The external link between two vehicular nodes can 652 be used for vehicular networking, as shown in Figure 2 and Figure 3. 654 ND time-related parameters such as router lifetime and Neighbor 655 Advertisement (NA) interval should be adjusted for high-speed 656 vehicles and vehicle density. As vehicles move faster, the NA 657 interval should decrease for the NA messages to reach the neighboring 658 vehicles promptly. Also, as vehicle density is higher, the NA 659 interval should increase for the NA messages to collide with other NA 660 messages with lower collision probability. 662 5.2.1. Link Model 664 IPv6 protocols work under certain assumptions for the link model that 665 do not necessarily hold in WAVE [IPv6-WAVE]. For instance, some IPv6 666 protocols assume symmetry in the connectivity among neighboring 667 interfaces. However, interference and different levels of 668 transmission power may cause unidirectional links to appear in a WAVE 669 link model. 671 Also, in an IPv6 link, it is assumed that all interfaces which are 672 configured with the same subnet prefix are on the same IP link. 673 Hence, there is a relationship between link and prefix, besides the 674 different scopes that are expected from the link-local and global 675 types of IPv6 addresses. Such a relationship does not hold in a WAVE 676 link model due to node mobility and highly dynamic topology. 678 Thus, IPv6 ND should be extended to support the concept of a link for 679 an IPv6 prefix in terms of multicast in VANET. 681 5.2.2. MAC Address Pseudonym 683 As the ETSI GeoNetworking, for the sake of security and privacy, an 684 ITS station (e.g., vehicle) can use pseudonyms for its network 685 interface identities (e.g., MAC address) and the corresponding IPv6 686 addresses [Identity-Management]. Whenever the network interface 687 identifier changes, the IPv6 address based on the network interface 688 identifier should be updated. For the continuity of an end-to-end 689 transport-layer (e.g., TCP, UDP, and SCTP) session, the IP addresses 690 of the transport-layer session should be notified to both the end 691 points and the packets of the session should be forwarded to their 692 destinations with the changed network interface identifier and IPv6 693 address. 695 5.2.3. Prefix Dissemination/Exchange 697 A vehicle and an RSU can have their internal network, as shown in 698 Figure 2 and Figure 3. In this case, nodes in within the internal 699 networks of two vehicular nodes (e.g., vehicle and RSU) want to 700 communicate with each other. For this communication, the network 701 prefix dissemination or exchange is required. It is assumed that a 702 vehicular node has an external network interface and its internal 703 network. The standard IPv6 ND needs to be extended for the 704 communication between the internal-network vehicular nodes by letting 705 each of them know the other side's prefix with a new ND option 706 [ID-Vehicular-ND]. 708 5.2.4. Routing 710 For Neighbor Discovery in vehicular networks (called vehicular ND), 711 Ad Hoc routing is required for either unicast or multicast in the 712 links in a connected VANET with the same IPv6 prefix [GeoSAC]. Also, 713 a rapid DAD should be supported to prevent or reduce IPv6 address 714 conflicts in such links. 716 5.3. Mobility Management 718 The seamless connectivity and timely data exchange between two end 719 points requires an efficient mobility management including location 720 management and handover. Most of vehicles are equipped with a GPS 721 navigator as a dedicated navigation system or a smartphone App. With 722 this GPS navigator, vehicles can share their current position and 723 trajectory (i.e., navigation path) with TCC. TCC can predict the 724 future positions of the vehicles with their mobility information 725 (i.e., the current position, speed, direction, and trajectory). With 726 the prediction of the vehicle mobility, TCC supports RSUs to perform 727 DAD, data packet routing, and handover in a proactive manner. 729 5.4. Vehicle Identity Management 731 A vehicle can have multiple network interfaces using different access 732 network technologies [Identity-Management]. These multiple network 733 interfaces mean multiple identities. To identify a vehicle with 734 multiple indenties, a Vehicle Identification Number (VIN) can be used 735 as a globally unique vehicle identifier. 737 To support the seamless connectivity over the multiple identities, a 738 cross-layer network architecture is required with vertical handover 739 functionality [Identity-Management]. 741 5.5. Multihop V2X 743 Multihop packet forwarding among vehicles in 802.11-OCB mode shows an 744 unfavorable performance due to the common known broadcast-storm 745 problem [Broadcast-Storm]. This broadcast-storm problem can be 746 mitigated by the coordination (or scheduling) of a cluster head in a 747 connected VANET or an RSU in an intersection area, which is a 748 coordinator for the access to wireless channels. 750 5.6. Multicast 752 IP multicast in vehicular network environments is especially useful 753 for various services. For instance, an automobile manufacturer can 754 multicast a particular group/class/type of vehicles for service 755 notification. As another example, a vehicle or an RSU can 756 disseminate alert messages in a particular area [Multicast-Alert]. 758 In general IEEE 802 wireless media, some performance issues about 759 multicast are found in [Multicast-Considerations-802]. Since 760 serveral procedures and functions based on IPv6 use multicast for 761 control-plane messages, such as Neighbor Discovery (called ND) and 762 Service Discovery, [Multicast-Considerations-802] describes that the 763 ND process may fail due to unreliable wireless link, causing failure 764 of the DAD process. Also, the Router Advertisement messages can be 765 lost in multicasting. 767 5.7. DNS Naming Services and Service Discovery 769 When two vehicular nodes communicate with each other with the DNS 770 name of the partner node, DNS naming service (i.e., DNS name 771 resolution) is required. As shown in Figure 2 and Figure 3, a 772 recursive DNS server (RDNSS) within an internal network can perform 773 such DNS name resolution for the sake of other vehicular nodes. 775 A service discovery service is required for an application in a 776 vehicular node to search for another application or server in another 777 vehicular node, which resides in either the same internal network or 778 the other internal network. In V2I or V2V networking, as shown in 779 Figure 2 and Figure 3, such a service discovery service can be 780 provided by either DNS-based Service Discovery (DNS-SD) [RFC6763] 781 with mDNS [RFC6762] or the vehicular ND with a new option for service 782 discovery [ID-Vehicular-ND]. 784 5.8. IPv6 over Cellular Networks 786 IP has been supported in celluar networks since the time of General 787 Packet Radio Service (GPRS) in the 2nd generation cellular networks 788 of Global System for Mobile communications (2G-GSM) developed and 789 maintained by the 3rd Generation Partnership Project (3GPP). The 2G 790 and 3G-based radio accesses separate end-user data traffic (User 791 Plane) from network transport traffic among network elements 792 (Transport Plane). The two planes run independently in terms of 793 addressing and the IP version. The Transport Plane forms tunnels to 794 transport user data traffic [IPv6-3GPP-Survey]. 796 The 4G-Long-Term-Evolution (4G-LTE) radio access simplifies the 797 complex architecture of GPRS core network by introduing the Evolved 798 Packet Core (EPC). Both 2G/3G and 4G-LTE system use Access Point 799 Name (APN) to bridge user data and outside network. User traffic is 800 transported via Packet Data Protocol (PDP) Contexts in GPRS, and 801 Packet Data Network (PDN) Connections in EPC. Different traffics at 802 a user equipment (UE) side need to connect to different APNs through 803 multiple PDP Contexts or PDN Connections. Each of the context or the 804 connection needs to have its own IP address. 806 IPv6 is partially supported in 2G/3G and 4G-LTE. In 2G/3G, a UE can 807 be allocated an IPv6 address via two different ways, IPv6 and IPv4v6 808 PDP Contexts. By IPv4v6 PDP Context, both an IPv4 address and an /64 809 IPv6 prefix are allocated. In 4G-LTE, the IPv6 address allocation 810 has a different process compared with that in 2G/3G networks. The 811 major difference is that 4G-LTE builds the IP connectivity at the 812 beginning of a UE attachment, whereas the IP connectivity of 2G/3G 813 networks is created on demand. All 3GPP networks (i.e., 2G/3G and 814 4G-LTE) only support SLAAC address allocation, and do not suggest 815 performing DAD. In addition, 3GPP networks remove link-layer address 816 resolution, e.g., ND Protocol for IPv6, due to the assumption that 817 the GGSN (Gateway GPRS Support Node) in 2G/3G networks or the P-GW 818 (Packet Data Network Gateway) in 4G-LTE network is always the first- 819 hop router for a UE. 821 Recently, 3GPP has announced a new technical specification, Release 822 14 (3GPP-R14), which proposes an architecture enhancements for 823 vehicle-to-everything (V2X) services using the modified sidelink 824 interface that originally is designed for the LTE Device-to-Device 825 (LTE-D2D) communications. 3GPP-R14 regulates that the V2X services 826 only support IPv6 implementation. 3GPP is also investigating and 827 discussing the evolved V2X services in the next generation cellular 828 networks, i.e., 5G new radio (5G-NR), for advanced V2X communications 829 and automated vehicles' applications. 831 5.8.1. Cellular V2X (C-V2X) Using 4G-LTE 833 Before 3GPP-R14, some researchers have studied the potential usage of 834 C-V2X communications. For example, [VMaSC-LTE] explores a multihop 835 cluster-based hybrid architecture using both DSRC and LTE for safety 836 message dissemination. Most of the research consider a short message 837 service for safety instead of IP datagram forwarding. In other C-V2X 838 research, the standard IPv6 is assumed. 840 The 3GPP technical specification [TS-23285-3GPP] states that both IP 841 based and non-IP based V2X messages are supported, and only IPv6 is 842 supported for IP based messages. Moreover, [TS-23285-3GPP] 843 instructes that a UE autoconfigures a link- local IPv6 address by 844 following [RFC4862], but without sending Neighbor Solicitation and 845 Neighbor Advertisement messages for DAD. 847 5.8.2. Cellular V2X (C-V2X) Using 5G 849 The emerging services, functions and applications in automotive 850 industry spurs ehhanced V2X (eV2X)-based services in the future 5G 851 era. The 3GPP Technical Report [TS-22886-3GPP] is studying new use 852 cases for V2X using 5G in the future. 854 5.9. Security and Privacy 856 Security and privacy are paramount in the V2I and V2V networking in 857 vehicular networks. Only authorized vehicles should be allowed to 858 use the V2I and V2V networking. Also, in-vehicle devices and mobile 859 devices in a vehicle need to communicate with other in-vehicle 860 devices and mobile devices in another vehicle, and other servers in 861 an RSU in a secure way. 863 A Vehicle Identification Number (VIN) and a user certificate along 864 with in-vehicle device's identifier generation can be used to 865 authenticate a vehicle and the user through a road infrastructure 866 node, such as an RSU connected to an authentication server in TCC. 867 Transport Layer Security (TLS) certificates can also be used for 868 secure vehicle communications. 870 For secure V2I communication, the secure channel between a mobile 871 router in a vehicle and a fixed router in an RSU should be 872 established, as shown in Figure 2. Also, for secure V2V 873 communication, the secure channel between a mobile router in a 874 vehicle and a mobile router in another vehicle should be established, 875 as shown in Figure 3. 877 The security for vehicular networks should provide vehicles with AAA 878 services in an efficient way. It should consider not only horizontal 879 handover, but also vertical handover since vehicles have multiple 880 wireless interfaces. 882 To prevent an adversary from tracking a vehicle by with its MAC 883 address or IPv6 address, each vehicle should periodically update its 884 MAC address and the corresponding IPv6 address as suggested in 885 [RFC4086][RFC4941]. Such an update of the MAC and IPv6 addresses 886 should not interrupt the communications between two vehicular nodes 887 (e.g., vehicle and RSU). 889 6. Security Considerations 891 This document discussed security and privacy for IP-based vehicular 892 networking. 894 The security and privacy for key components in vehicular networking, 895 such as IP address autoconfiguration, routing, mobility management, 896 DNS naming service, and service discovery, needs to be analyzed in 897 depth. 899 7. Informative References 901 [Address-Assignment] 902 Kato, T., Kadowaki, K., Koita, T., and K. Sato, "Routing 903 and Address Assignment using Lane/Position Information in 904 a Vehicular Ad-hoc Network", IEEE Asia-Pacific Services 905 Computing Conference, December 2008. 907 [Address-Autoconf] 908 Fazio, M., Palazzi, C., Das, S., and M. Gerla, "Automatic 909 IP Address Configuration in VANETs", ACM International 910 Workshop on Vehicular Inter-Networking, September 2016. 912 [Automotive-Sensing] 913 Choi, J., Va, V., Gonzalez-Prelcic, N., Daniels, R., R. 914 Bhat, C., and R. W. Heath, "Millimeter-Wave Vehicular 915 Communication to Support Massive Automotive Sensing", 916 IEEE Communications Magazine, December 2016. 918 [Broadcast-Storm] 919 Wisitpongphan, N., K. Tonguz, O., S. Parikh, J., Mudalige, 920 P., Bai, F., and V. Sadekar, "Broadcast Storm Mitigation 921 Techniques in Vehicular Ad Hoc Networks", IEEE Wireless 922 Communications, December 2007. 924 [CA-Cuise-Control] 925 California Partners for Advanced Transportation Technology 926 (PATH), "Cooperative Adaptive Cruise Control", [Online] 927 Available: 928 http://www.path.berkeley.edu/research/automated-and- 929 connected-vehicles/cooperative-adaptive-cruise-control, 930 2017. 932 [CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A 933 Framework of Context-Awareness Safety Driving in Vehicular 934 Networks", International Workshop on Device Centric Cloud 935 (DC2), March 2016. 937 [DSRC] ASTM International, "Standard Specification for 938 Telecommunications and Information Exchange Between 939 Roadside and Vehicle Systems - 5 GHz Band Dedicated Short 940 Range Communications (DSRC) Medium Access Control (MAC) 941 and Physical Layer (PHY) Specifications", 942 ASTM E2213-03(2010), October 2010. 944 [ETSI-GeoNetwork-IP] 945 ETSI Technical Committee Intelligent Transport Systems, 946 "Intelligent Transport Systems (ITS); Vehicular 947 Communications; GeoNetworking; Part 6: Internet 948 Integration; Sub-part 1: Transmission of IPv6 Packets over 949 GeoNetworking Protocols", ETSI EN 302 636-6-1, October 950 2013. 952 [ETSI-GeoNetworking] 953 ETSI Technical Committee Intelligent Transport Systems, 954 "Intelligent Transport Systems (ITS); Vehicular 955 Communications; GeoNetworking; Part 4: Geographical 956 addressing and forwarding for point-to-point and point-to- 957 multipoint communications; Sub-part 1: Media-Independent 958 Functionality", ETSI EN 302 636-4-1, May 2014. 960 [FirstNet] 961 U.S. National Telecommunications and Information 962 Administration (NTIA), "First Responder Network Authority 963 (FirstNet)", [Online] 964 Available: https://www.firstnet.gov/, 2012. 966 [FirstNet-Annual-Report-2017] 967 First Responder Network Authority, "FY 2017: ANNUAL REPORT 968 TO CONGRESS, Advancing Public Safety Broadband 969 Communications", FirstNet FY 2017, December 2017. 971 [Fuel-Efficient] 972 van de Hoef, S., H. Johansson, K., and D. V. Dimarogonas, 973 "Fuel-Efficient En Route Formation of Truck Platoons", 974 IEEE Transactions on Intelligent Transportation Systems, 975 January 2018. 977 [GeoSAC] Baldessari, R., Bernardos, C., and M. Calderon, "GeoSAC - 978 Scalable Address Autoconfiguration for VANET Using 979 Geographic Networking Concepts", IEEE International 980 Symposium on Personal, Indoor and Mobile Radio 981 Communications, September 2008. 983 [H-DMM] Nguyen, T. and C. Bonnet, "A Hybrid Centralized- 984 Distributed Mobility Management for Supporting Highly 985 Mobile Users", IEEE International Conference on 986 Communications, June 2015. 988 [ID-DNSNA] 989 Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 990 Autoconfiguration for Internet of Things Devices", draft- 991 jeong-ipwave-iot-dns-autoconf-03 (work in progress), July 992 2018. 994 [ID-Vehicular-ND] 995 Jeong, J., Ed., Shen, Y., Jo, Y., Jeong, J., and J. Lee, 996 "IPv6 Neighbor Discovery for Prefix and Service Discovery 997 in Vehicular Networks", draft-jeong-ipwave-vehicular- 998 neighbor-discovery-03 (work in progress), July 2018. 1000 [Identity-Management] 1001 Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer 1002 Identities Management in ITS Stations", The 10th 1003 International Conference on ITS Telecommunications, 1004 November 2010. 1006 [IEEE-802.11-OCB] 1007 IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium 1008 Access Control (MAC) and Physical Layer (PHY) 1009 Specifications", IEEE Std 802.11-2012, February 2012. 1011 [IEEE-802.11p] 1012 IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium 1013 Access Control (MAC) and Physical Layer (PHY) 1014 Specifications - Amendment 6: Wireless Access in Vehicular 1015 Environments", IEEE Std 802.11p-2010, June 2010. 1017 [IP-Passing-Protocol] 1018 Chen, Y., Hsu, C., and W. Yi, "An IP Passing Protocol for 1019 Vehicular Ad Hoc Networks with Network Fragmentation", 1020 Elsevier Computers & Mathematics with Applications, 1021 January 2012. 1023 [IPv6-3GPP-Survey] 1024 Soininen, J. and J. Korhonen, "Survey of IPv6 Support in 1025 3GPP Specifications and Implementations", 1026 IEEE Communications Surveys & Tutorials, January 2015. 1028 [IPv6-over-80211-OCB] 1029 Petrescu, A., Benamar, N., Haerri, J., Lee, J., and T. 1030 Ernst, "Transmission of IPv6 Packets over IEEE 802.11 1031 Networks operating in mode Outside the Context of a Basic 1032 Service Set (IPv6-over-80211-OCB)", draft-ietf-ipwave- 1033 ipv6-over-80211ocb-25 (work in progress), June 2018. 1035 [IPv6-WAVE] 1036 Baccelli, E., Clausen, T., and R. Wakikawa, "IPv6 1037 Operation for WAVE - Wireless Access in Vehicular 1038 Environments", IEEE Vehicular Networking Conference, 1039 December 2010. 1041 [ISO-ITS-IPv6] 1042 ISO/TC 204, "Intelligent Transport Systems - 1043 Communications Access for Land Mobiles (CALM) - IPv6 1044 Networking", ISO 21210:2012, June 2012. 1046 [Joint-IP-Networking] 1047 Petrescu, A., Boc, M., and C. Ibars, "Joint IP Networking 1048 and Radio Architecture for Vehicular Networks", 1049 11th International Conference on ITS Telecommunications, 1050 August 2011. 1052 [LAGAD] Abrougui, K., Boukerche, A., and R. Pazzi, "Location-Aided 1053 Gateway Advertisement and Discovery Protocol for VANets", 1054 IEEE Transactions on Vehicular Technology, Vol. 59, No. 8, 1055 October 2010. 1057 [Multicast-Alert] 1058 Camara, D., Bonnet, C., Nikaein, N., and M. Wetterwald, 1059 "Multicast and Virtual Road Side Units for Multi 1060 Technology Alert Messages Dissemination", IEEE 8th 1061 International Conference on Mobile Ad-Hoc and Sensor 1062 Systems, October 2011. 1064 [Multicast-Considerations-802] 1065 Perkins, C., Stanley, D., Kumari, W., and JC. Zuniga, 1066 "Multicast Considerations over IEEE 802 Wireless Media", 1067 draft-perkins-intarea-multicast-ieee802-03 (work in 1068 progress), July 2017. 1070 [NEMO-LMS] 1071 Soto, I., Bernardos, C., Calderon, M., Banchs, A., and A. 1072 Azcorra, "NEMO-Enabled Localized Mobility Support for 1073 Internet Access in Automotive Scenarios", 1074 IEEE Communications Magazine, May 2009. 1076 [NEMO-VANET] 1077 Chen, Y., Hsu, C., and C. Cheng, "Network Mobility 1078 Protocol for Vehicular Ad Hoc Networks", 1079 Wiley International Journal of Communication Systems, 1080 November 2014. 1082 [PMIP-NEMO-Analysis] 1083 Lee, J., Ernst, T., and N. Chilamkurti, "Performance 1084 Analysis of PMIPv6-Based Network Mobility for Intelligent 1085 Transportation Systems", IEEE Transactions on Vehicular 1086 Technology, January 2012. 1088 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1089 (IPv6) Specification", RFC 2460, December 1998. 1091 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1092 "Randomness Requirements for Security", RFC 4086, June 1093 2005. 1095 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1096 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 1097 September 2007. 1099 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1100 Address Autoconfiguration", RFC 4862, September 2007. 1102 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1103 Extensions for Stateless Address Autoconfiguration in 1104 IPv6", RFC 4941, September 2007. 1106 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 1107 Hoc Networks", RFC 5889, September 2010. 1109 [RFC5944] Perkins, C., Ed., "IP Mobility Support in IPv4, Revised", 1110 RFC 5944, November 2010. 1112 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1113 Support in IPv6", RFC 6275, July 2011. 1115 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1116 February 2013. 1118 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1119 Discovery", RFC 6763, February 2013. 1121 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 1122 "Requirements for Distributed Mobility Management", 1123 RFC 7333, August 2014. 1125 [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. 1126 Bernardos, "Distributed Mobility Management: Current 1127 Practices and Gap Analysis", RFC 7429, January 2015. 1129 [SAINT] Jeong, J., Jeong, H., Lee, E., Oh, T., and D. Du, "SAINT: 1130 Self-Adaptive Interactive Navigation Tool for Cloud-Based 1131 Vehicular Traffic Optimization", IEEE Transactions on 1132 Vehicular Technology, Vol. 65, No. 6, June 2016. 1134 [SAINTplus] 1135 Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D. 1136 Du, "SAINT+: Self-Adaptive Interactive Navigation Tool+ 1137 for Emergency Service Delivery Optimization", 1138 IEEE Transactions on Intelligent Transportation Systems, 1139 June 2017. 1141 [SANA] Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation 1142 Application for Pedestrian Protection in Vehicular 1143 Networks", Springer Lecture Notes in Computer Science 1144 (LNCS), Vol. 9502, December 2015. 1146 [SDN-DMM] Nguyen, T., Bonnet, C., and J. Harri, "SDN-based 1147 Distributed Mobility Management for 5G Networks", 1148 IEEE Wireless Communications and Networking Conference, 1149 April 2016. 1151 [Securing-VCOMM] 1152 Fernandez, P., Santa, J., Bernal, F., and A. Skarmeta, 1153 "Securing Vehicular IPv6 Communications", 1154 IEEE Transactions on Dependable and Secure Computing, 1155 January 2016. 1157 [Truck-Platooning] 1158 California Partners for Advanced Transportation Technology 1159 (PATH), "Automated Truck Platooning", [Online] Available: 1160 http://www.path.berkeley.edu/research/automated-and- 1161 connected-vehicles/truck-platooning, 2017. 1163 [TS-22886-3GPP] 1164 3GPP, "Study on Enhancement of 3GPP Support for 5G V2X 1165 Services", 3GPP TS 22.886, June 2018. 1167 [TS-23285-3GPP] 1168 3GPP, "Architecture Enhancements for V2X Services", 3GPP 1169 TS 23.285, June 2018. 1171 [VANET-Geo-Routing] 1172 Tsukada, M., Jemaa, I., Menouar, H., Zhang, W., Goleva, 1173 M., and T. Ernst, "Experimental Evaluation for IPv6 over 1174 VANET Geographic Routing", IEEE International Wireless 1175 Communications and Mobile Computing Conference, June 2010. 1177 [VIP-WAVE] 1178 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 1179 Feasibility of IP Communications in 802.11p Vehicular 1180 Networks", IEEE Transactions on Intelligent Transportation 1181 Systems, March 2013. 1183 [VMaSC-LTE] 1184 Ucar, S., Ergen, S., and O. Ozkasap, "Multihop-Cluster- 1185 Based IEEE 802.11p and LTE Hybrid Architecture for VANET 1186 Safety Message Dissemination", IEEE Transactions on 1187 Vehicular Technology, April 2016. 1189 [VNET-AAA] 1190 Moustafa, H., Bourdon, G., and Y. Gourhant, "Providing 1191 Authentication and Access Control in Vehicular Network 1192 Environment", IFIP TC-11 International Information 1193 Security Conference, May 2006. 1195 [VNET-MM] Peng, Y. and J. Chang, "A Novel Mobility Management Scheme 1196 for Integration of Vehicular Ad Hoc Networks and Fixed IP 1197 Networks", Springer Mobile Networks and Applications, 1198 February 2010. 1200 [WAVE-1609.0] 1201 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 1202 in Vehicular Environments (WAVE) - Architecture", IEEE Std 1203 1609.0-2013, March 2014. 1205 [WAVE-1609.2] 1206 IEEE 1609 Working Group, "IEEE Standard for Wireless 1207 Access in Vehicular Environments - Security Services for 1208 Applications and Management Messages", IEEE Std 1209 1609.2-2016, March 2016. 1211 [WAVE-1609.3] 1212 IEEE 1609 Working Group, "IEEE Standard for Wireless 1213 Access in Vehicular Environments (WAVE) - Networking 1214 Services", IEEE Std 1609.3-2016, April 2016. 1216 [WAVE-1609.4] 1217 IEEE 1609 Working Group, "IEEE Standard for Wireless 1218 Access in Vehicular Environments (WAVE) - Multi-Channel 1219 Operation", IEEE Std 1609.4-2016, March 2016. 1221 Appendix A. Acknowledgments 1223 This work was supported by Basic Science Research Program through the 1224 National Research Foundation of Korea (NRF) funded by the Ministry of 1225 Education (2017R1D1A1B03035885). 1227 This work was supported in part by Global Research Laboratory Program 1228 through the NRF funded by the Ministry of Science and ICT (MSIT) 1229 (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT 1230 (18-EE-01). 1232 This work was supported in part by the French research project 1233 DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded 1234 by the European Commission I (636537-H2020). 1236 Appendix B. Contributors 1238 This document is a group work of IPWAVE working group, greatly 1239 benefiting from inputs and texts by Rex Buddenberg (Naval 1240 Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest 1241 University of Technology and Economics), Jose Santa Lozanoi 1242 (Universidad of Murcia), Richard Roy (MIT), and Francois Simon 1243 (Pilot). The authors sincerely appreciate their contributions. 1245 The following are co-authors of this document: 1247 Nabil Benamar 1248 Department of Computer Sciences 1249 High School of Technology of Meknes 1250 Moulay Ismail University 1251 Morocco 1253 Phone: +212 6 70 83 22 36 1254 EMail: benamar73@gmail.com 1256 Sandra Cespedes 1257 Department of Electrical Engineering 1258 Universidad de Chile 1259 Av. Tupper 2007, Of. 504 1260 Santiago, 8370451 1261 Chile 1263 Phone: +56 2 29784093 1264 EMail: scespede@niclabs.cl 1265 Jerome Haerri 1266 Communication Systems Department 1267 EURECOM 1268 Sophia-Antipolis 1269 France 1271 Phone: +33 4 93 00 81 34 1272 EMail: jerome.haerri@eurecom.fr 1274 Dapeng Liu 1275 Alibaba 1276 Beijing, Beijing 100022 1277 China 1279 Phone: +86 13911788933 1280 EMail: max.ldp@alibaba-inc.com 1282 Tae (Tom) Oh 1283 Department of Information Sciences and Technologies 1284 Rochester Institute of Technology 1285 One Lomb Memorial Drive 1286 Rochester, NY 14623-5603 1287 USA 1289 Phone: +1 585 475 7642 1290 EMail: Tom.Oh@rit.edu 1292 Charles E. Perkins 1293 Futurewei Inc. 1294 2330 Central Expressway 1295 Santa Clara, CA 95050 1296 USA 1298 Phone: +1 408 330 4586 1299 EMail: charliep@computer.org 1301 Alexandre Petrescu 1302 CEA, LIST 1303 CEA Saclay 1304 Gif-sur-Yvette, Ile-de-France 91190 1305 France 1307 Phone: +33169089223 1308 EMail: Alexandre.Petrescu@cea.fr 1309 Yiwen Chris Shen 1310 Department of Computer Science & Engineering 1311 Sungkyunkwan University 1312 2066 Seobu-Ro, Jangan-Gu 1313 Suwon, Gyeonggi-Do 16419 1314 Republic of Korea 1316 Phone: +82 31 299 4106 1317 Fax: +82 31 290 7996 1318 EMail: chrisshen@skku.edu 1319 URI: http://iotlab.skku.edu/people-chris-shen.php 1321 Michelle Wetterwald 1322 FBConsulting 1323 21, Route de Luxembourg 1324 Wasserbillig, Luxembourg L-6633 1325 Luxembourg 1327 EMail: Michelle.Wetterwald@gmail.com 1329 Appendix C. Changes from draft-ietf-ipwave-vehicular-networking-02 1331 The following changes are made from draft-ietf-ipwave-vehicular- 1332 networking-02: 1334 o The overall structure of the document is reorganized for the 1335 problem statement for IPWAVE. 1337 Author's Address 1339 Jaehoon Paul Jeong (editor) 1340 Department of Software 1341 Sungkyunkwan University 1342 2066 Seobu-Ro, Jangan-Gu 1343 Suwon, Gyeonggi-Do 16419 1344 Republic of Korea 1346 Phone: +82 31 299 4957 1347 Fax: +82 31 290 7996 1348 EMail: pauljeong@skku.edu 1349 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php