idnits 2.17.1 draft-ietf-ipwave-vehicular-networking-13.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 (January 6, 2020) is 1571 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Online' is mentioned on line 1227, but not defined == Unused Reference: 'RFC3561' is defined on line 1129, but no explicit reference was found in the text == Unused Reference: 'RFC6775' is defined on line 1171, but no explicit reference was found in the text == Unused Reference: 'RFC7181' is defined on line 1180, but no explicit reference was found in the text == Unused Reference: 'Timing-Attack' is defined on line 1219, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-11 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 7 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 January 6, 2020 5 Expires: July 9, 2020 7 IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem 8 Statement and Use Cases 9 draft-ietf-ipwave-vehicular-networking-13 11 Abstract 13 This document discusses the problem statement and use cases of 14 IPv6-based vehicular networking for Intelligent Transportation 15 Systems (ITS). The main scenarios of vehicular communications are 16 vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and 17 vehicle-to-everything (V2X) communications. First, this document 18 explains use cases using V2V, V2I, and V2X networking. Next, it 19 makes a problem statement about key aspects in IPv6-based vehicular 20 networking, such as IPv6 Neighbor Discovery, Mobility Management, and 21 Security & Privacy. For each key aspect, this document specifies 22 requirements for IPv6-based vehicular networking. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 9, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 9 65 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 10 66 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 13 67 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 15 68 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 16 69 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 16 70 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 18 71 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 19 72 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 20 73 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 20 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 75 7. Informative References . . . . . . . . . . . . . . . . . . . 23 76 Appendix A. Changes from draft-ietf-ipwave-vehicular- 77 networking-12 . . . . . . . . . . . . . . . . . . . 29 78 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 29 79 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 29 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 82 1. Introduction 84 Vehicular networking studies have mainly focused on improving safety 85 and efficiency, and also enabling entertainment in vehicular 86 networks. The Federal Communications Commission (FCC) in the US 87 allocated wireless channels for Dedicated Short-Range Communications 88 (DSRC) [DSRC] in the Intelligent Transportation Systems (ITS) with 89 the frequency band of 5.850 - 5.925 GHz (i.e., 5.9 GHz band). DSRC- 90 based wireless communications can support vehicle-to-vehicle (V2V), 91 vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) 92 networking. The European Union (EU) allocated radio spectrum for 93 safety-related and non-safety-related applications of ITS with the 94 frequency band of 5.875 - 5.905 GHz, as part of the Commission 95 Decision 2008/671/EC [EU-2008-671-EC]. 97 For direct inter-vehicular wireless connectivity, IEEE has amended 98 WiFi standard 802.11 to enable driving safety services based on DSRC 99 for the Wireless Access in Vehicular Environments (WAVE) system. The 100 Physical Layer (L1) and Data Link Layer (L2) issues are addressed in 101 IEEE 802.11p [IEEE-802.11p] for the PHY and MAC of the DSRC, while 102 IEEE 1609.2 [WAVE-1609.2] covers security aspects, IEEE 1609.3 103 [WAVE-1609.3] defines related services at network and transport 104 layers, and IEEE 1609.4 [WAVE-1609.4] specifies the multi-channel 105 operation. IEEE 802.11p was first a separate amendment, but was 106 later rolled into the base 802.11 standard (IEEE 802.11-2012) as IEEE 107 802.11 Outside the Context of a Basic Service Set (OCB) in 2012 108 [IEEE-802.11-OCB]. 110 Along with these WAVE standards, IPv6 [RFC8200] and Mobile IPv6 111 protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], and Proxy MIPv6 112 (PMIPv6) [RFC5213]) can be applied to vehicular networks. In 113 addition, ISO has approved a standard specifying the IPv6 network 114 protocols and services to be used for Communications Access for Land 115 Mobiles (CALM) [ISO-ITS-IPv6]. 117 This document describes use cases and a problem statement about 118 IPv6-based vehicular networking for ITS, which is named IPv6 Wireless 119 Access in Vehicular Environments (IPWAVE). First, it introduces the 120 use cases for using V2V, V2I, and V2X networking in ITS. Next, it 121 makes a problem statement about key aspects in IPWAVE, namely, IPv6 122 Neighbor Discovery (ND), Mobility Management (MM), and Security & 123 Privacy (SP). For each key aspect of the problem statement, this 124 document specifies requirements for IPv6-based vehicular networking. 125 This document is intended to motivate development of key protocols 126 for IPWAVE. 128 2. Terminology 130 This document uses the terminology described in [RFC8691]. In 131 addition, the following terms are defined below: 133 o Class-Based Safety Plan: A vehicle can make safety plan by 134 classifying the surrounding vehicles into different groups for 135 safety purposes according to the geometrical relationship among 136 them. The vehicle groups can be classified as Line-of-Sight 137 Unsafe, Non-Line-of-Sight Unsafe, and Safe groups [CASD]. 139 o Context-Awareness: A vehicle can be aware of spatial-temporal 140 mobility information (e.g., position, speed, direction, and 141 acceleration/deceleration) of surrounding vehicles for both safety 142 and non-safety uses through sensing or communication [CASD]. 144 o Edge Computing (EC): It is the local computing near an access 145 network (i.e., edge network) for the sake of vehicles and 146 pedestrians. 148 o Edge Computing Device (ECD): It is a computing device (or server) 149 for edge computing for the sake of vehicles and pedestrians. 151 o Edge Network (EN): In is an access network that has an IP-RSU for 152 wireless communication with other vehicles having an IP-OBU and 153 wired communication with other network devices (e.g., routers, IP- 154 RSUs, ECDs, servers, and MA). It may have a radio receiver of 155 Global Positioning System (GPS) for its position recognition and 156 the localization service for the sake of vehicles. 158 o IP-OBU: "Internet Protocol On-Board Unit": An IP-OBU denotes a 159 computer situated in a vehicle such as a car, bicycle, or similar. 160 It has at least one IP interface that runs in mode OCB of 802.11 161 and has an "OBU" transceiver. Also, it may have an IP interface 162 that runs in Cellular V2X (C-V2X) [TS-23.285-3GPP]. See the 163 definition of the term "OBU" in [RFC8691]. 165 o IP-RSU: "IP Roadside Unit": An IP-RSU is situated along the road. 166 It has at least two distinct IP-enabled interfaces. The wireless 167 PHY/MAC layer of at least one of its IP-enabled interfaces is 168 configured to operate in 802.11-OCB mode. An IP-RSU communicates 169 with the IP-OBU over an 802.11 wireless link operating in OCB 170 mode. Also, it may have an IP interface that runs in C-V2X along 171 with an "RSU" transceiver. An IP-RSU is similar to an Access 172 Network Router (ANR), defined in [RFC3753], and a Wireless 173 Termination Point (WTP), defined in [RFC5415]. See the definition 174 of the term "RSU" in [RFC8691]. 176 o LiDAR: "Light Detection and Ranging". It is a scanning device to 177 measure a distance to an object by emitting pulsed laser light and 178 measuring the reflected pulsed light. 180 o Mobility Anchor (MA): A node that maintains IPv6 addresses and 181 mobility information of vehicles in a road network to support 182 their IPv6 address autoconfiguration and mobility management with 183 a binding table. An MA has End-to-End (E2E) connections with IP- 184 RSUs under its control for the address autoconfiguration and 185 mobility management of the vehicles. This MA can play a role of a 186 Local Mobility Anchor (LMA) in PMIPv6 [RFC5213] for vehicles 187 moving in the road network . 189 o OCB: "Outside the Context of a Basic Service Set - BSS". It is a 190 mode of operation in which a Station (STA) is not a member of a 191 BSS and does not utilize IEEE Std 802.11 authentication, 192 association, or data confidentiality [IEEE-802.11-OCB]. 194 o 802.11-OCB: It refers to the mode specified in IEEE Std 195 802.11-2016 [IEEE-802.11-OCB] when the MIB attribute 196 dot11OCBActivited is 'true'. 198 o Platooning: Moving vehicles can be grouped together to reduce air- 199 resistance for energy efficiency and reduce the number of drivers 200 such that only the leading vehicle has a driver and the other 201 vehicles are autonomous vehicles without a driver and closely 202 following the leading vehicle [Truck-Platooning]. 204 o Traffic Control Center (TCC): A node that maintains road 205 infrastructure information (e.g., IP-RSUs, traffic signals, and 206 loop detectors), vehicular traffic statistics (e.g., average 207 vehicle speed and vehicle inter-arrival time per road segment), 208 and vehicle information (e.g., a vehicle's identifier, position, 209 direction, speed, and trajectory as a navigation path). TCC is 210 included in a vehicular cloud for vehicular networks. 212 o Vehicle: A Vehicle in this document is a node that has an IP-OBU 213 for wireless communication with other vehicles and IP-RSUs. It 214 has a radio navigation receiver of Global Positioning System (GPS) 215 for efficient navigation. 217 o Vehicular Ad Hoc Network (VANET): A network that consists of 218 vehicles interconnected by wireless communication. Two vehicles 219 in a VANET can communicate with each other using other vehicles as 220 relays even where they are out of one-hop wireless communication 221 range. 223 o Vehicular Cloud: A cloud infrastructure for vehicular networks, 224 having compute nodes, storage nodes, and network forwarding 225 elements (e.g., switch and router). 227 o Vehicle Detection Loop (i.e., Loop Detector): An inductive device 228 used for detecting vehicles passing or arriving at a certain 229 point, for instance, at an intersection with traffic lights or at 230 a ramp toward a highway. The relatively crude nature of the 231 loop's structure means that only metal masses above a certain size 232 are capable of triggering the detection. 234 o V2D: "Vehicle to Device". It is the wireless communication 235 between a vehicle and a device (e.g., IoT device). 237 o V2P: "Vehicle to Pedestrian". It is the wireless communication 238 between a vehicle and a pedestrian's mobile device (e.g., 239 smartphone). 241 o V2I2P: "Vehicle to Infrastructure to Pedestrian". It is the 242 wireless communication between a vehicle and a pedestrian's mobile 243 device (e.g., smartphone) via an infrastructure node (e.g., IP- 244 RSU). 246 o V2I2V: "Vehicle to Infrastructure to Vehicle". It is the wireless 247 communication between a vehicle and another vehicle via an 248 infrastructure node (e.g., IP-RSU). 250 o VIP: "Vehicular Internet Protocol". It is an IPv6 extension for 251 vehicular networks including V2V, V2I, and V2X. 253 o VMM: "Vehicular Mobility Management". It is an IPv6-based 254 mobility management for vehicular networks. 256 o VND: "Vehicular Neighbor Discovery". It is an IPv6 ND extension 257 for vehicular networks. 259 o VSP: "Vehicular Security and Privacy". It is an IPv6-based 260 security and privacy for vehicular networks. 262 o WAVE: "Wireless Access in Vehicular Environments" [WAVE-1609.0]. 264 3. Use Cases 266 This section explains use cases of V2V, V2I, and V2X networking. The 267 use cases of the V2X networking exclude the ones of the V2V and V2I 268 networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to- 269 Device (V2D). 271 Since IP is widely used among various computing devices in the 272 Internet, it is expected that the use cases in this section need to 273 work on top of IPv6 as the network layer protocol. Thus, the IPv6 274 for these use cases should be extended for vehicular IPv6 such that 275 the IPv6 can support the functions of the network layer protocol such 276 as Vehicular Neighbor Discovery (VND), Vehicular Mobility Management 277 (VMM), and Vehicular Security and Privacy (VSP) in vehicular 278 networks. Refer to Section 5 for the problem statement of the 279 requirements of the vehicular IPv6. 281 3.1. V2V 283 The use cases of V2V networking discussed in this section include 285 o Context-aware navigation for driving safety and collision 286 avoidance; 288 o Cooperative adaptive cruise control in an urban roadway; 290 o Platooning in a highway; 292 o Cooperative environment sensing. 294 These four techniques will be important elements for self-driving 295 vehicles. 297 Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers 298 to drive safely by alerting the drivers about dangerous obstacles and 299 situations. That is, CASD navigator displays obstacles or 300 neighboring vehicles relevant to possible collisions in real-time 301 through V2V networking. CASD provides vehicles with a class-based 302 automatic safety action plan, which considers three situations, 303 namely, the Line-of-Sight unsafe, Non-Line-of-Sight unsafe, and safe 304 situations. This action plan can be put into action among multiple 305 vehicles using V2V networking. 307 Cooperative Adaptive Cruise Control (CACC) [CA-Cruise-Control] helps 308 vehicles to adapt their speed autonomously through V2V communication 309 among vehicles according to the mobility of their predecessor and 310 successor vehicles in an urban roadway or a highway. Thus, CACC can 311 help adjacent vehicles to efficiently adjust their speed in an 312 interactive way through V2V networking in order to avoid collision. 314 Platooning [Truck-Platooning] allows a series of vehicles (e.g., 315 trucks) to follow each other very closely. Trucks can use V2V 316 communication in addition to forward sensors in order to maintain 317 constant clearance between two consecutive vehicles at very short 318 gaps (from 3 meters to 10 meters). Platooning can maximize the 319 throughput of vehicular traffic in a highway and reduce the gas 320 consumption because the leading vehicle can help the following 321 vehicles to experience less air resistance. 323 Cooperative-environment-sensing use cases suggest that vehicles can 324 share environmental information from various vehicle-mounted sensors, 325 such as radars, LiDARs, and cameras with other vehicles and 326 pedestrians. [Automotive-Sensing] introduces a millimeter-wave 327 vehicular communication for massive automotive sensing. A lot of 328 data can be generated by those sensors, and these data typically need 329 to be routed to different destinations. In addition, from the 330 perspective of driverless vehicles, it is expected that driverless 331 vehicles can be mixed with driver-operated vehicles. Through the 332 cooperative environment sensing, driver-operated vehicles can use 333 environmental information sensed by driverless vehicles for better 334 interaction with the other vehicles and environment. 336 To support the applications of these V2V use cases, the functions of 337 IPv6 such as VND and VSP are prerequisite for the IPv6-based packet 338 exchange and the secure, safe communication between two vehicles. 340 3.2. V2I 342 The use cases of V2I networking discussed in this section include 344 o Navigation service; 346 o Energy-efficient speed recommendation service; 348 o Accident notification service. 350 A navigation service, for example, the Self-Adaptive Interactive 351 Navigation Tool (SAINT) [SAINT], using V2I networking interacts with 352 TCC for the large-scale/long-range road traffic optimization and can 353 guide individual vehicles for appropriate navigation paths in real 354 time. The enhanced version of SAINT [SAINTplus] can give fast moving 355 paths to emergency vehicles (e.g., ambulance and fire engine) to let 356 them reach an accident spot while redirecting other vehicles near the 357 accident spot into efficient detour paths. 359 A TCC can recommend an energy-efficient speed to a vehicle that 360 depends on its traffic environment. [Fuel-Efficient] studies fuel- 361 efficient route and speed plans for platooned trucks. 363 The emergency communication between accident vehicles (or emergency 364 vehicles) and TCC can be performed via either IP-RSU or 4G-LTE 365 networks. The First Responder Network Authority (FirstNet) 366 [FirstNet] is provided by the US government to establish, operate, 367 and maintain an interoperable public safety broadband network for 368 safety and security network services, e.g., emergency calls. The 369 construction of the nationwide FirstNet network requires each state 370 in the US to have a Radio Access Network (RAN) that will connect to 371 the FirstNet's network core. The current RAN is mainly constructed 372 by 4G-LTE for the communication between a vehicle and an 373 infrastructure node (i.e., V2I) [FirstNet-Report], but it is expected 374 that DSRC-based vehicular networks [DSRC] will be available for V2I 375 and V2V in near future. 377 To support the applications of these V2I use cases, the functions of 378 IPv6 such as VND, VMM, and VSP are prerequisite for the IPv6-based 379 packet exchange, the transport-layer session continuity, and the 380 secure, safe communication between a vehicle and a server in the 381 vehicular cloud. 383 3.3. V2X 385 The use case of V2X networking discussed in this section is 386 pedestrian protection service. 388 A pedestrian protection service, such as Safety-Aware Navigation 389 Application (SANA) [SANA], using V2I2P networking can reduce the 390 collision of a vehicle and a pedestrian carrying a smartphone 391 equipped with a network device for wireless communication (e.g., 392 WiFi) with an IP-RSU. Vehicles and pedestrians can also communicate 393 with each other via an IP-RSU. An edge computing device behind the 394 IP-RSU can collect the mobility information from vehicles and 395 pedestrians, compute wireless communication scheduling for the sake 396 of them. This scheduling can save the battery of each pedestrian's 397 smartphone by allowing it to work in sleeping mode before the 398 communication with vehicles, considering their mobility. 400 For Vehicle-to-Pedestrian (V2P), a vehicle can directly communicate 401 with a pedestrian's smartphone by V2X without IP-RSU relaying. 402 Light-weight mobile nodes such as bicycles may also communicate 403 directly with a vehicle for collision avoidance using V2V. 405 To support the applications of these V2X use cases, the functions of 406 IPv6 such as VND, VMM, and VSP are prerequisite for the IPv6-based 407 packet exchange, the transport-layer session continuity, and the 408 secure, safe communication between a vehicle and a pedestrian either 409 directly or indirectly via an IP-RSU. 411 4. Vehicular Networks 413 This section describes an exemplary vehicular network architecture 414 supporting V2V, V2I, and V2X communications in vehicular networks. 415 It describes an internal network within a vehicle or an edge network 416 (called EN). It explains not only the internetworking between the 417 internal networks of a vehicle and an EN via wireless links, but also 418 the internetworking between the internal networks of two vehicles via 419 wireless links. 421 Traffic Control Center in Vehicular Cloud 422 ******************************************* 423 +-------------+ * * 424 |Corresponding| * +-----------------+ * 425 | Node |<->* | Mobility Anchor | * 426 +-------------+ * +-----------------+ * 427 * ^ * 428 * | * 429 * v * 430 ******************************************* 431 ^ ^ ^ 432 | | | 433 | | | 434 v v v 435 +---------+ +---------+ +---------+ 436 | IP-RSU1 |<--------->| IP-RSU2 |<--------->| IP-RSU3 | 437 +---------+ +---------+ +---------+ 438 ^ ^ ^ 439 : : : 440 +-----------------+ +-----------------+ +-----------------+ 441 | : V2I | | : V2I | | : V2I | 442 | v | | v | | v | 443 +--------+ | +--------+ | | +--------+ | | +--------+ | 444 |Vehicle1|===> |Vehicle2|===>| | |Vehicle3|===>| | |Vehicle4|===>| 445 +--------+<...>+--------+<........>+--------+ | | +--------+ | 446 V2V ^ V2V ^ | | ^ | 447 | : V2V | | : V2V | | : V2V | 448 | v | | v | | v | 449 | +--------+ | | +--------+ | | +--------+ | 450 | |Vehicle5|===> | | |Vehicle6|===>| | |Vehicle7|==>| 451 | +--------+ | | +--------+ | | +--------+ | 452 +-----------------+ +-----------------+ +-----------------+ 453 Subnet1 Subnet2 Subnet3 454 (Prefix1) (Prefix2) (Prefix3) 456 <----> Wired Link <....> Wireless Link ===> Moving Direction 458 Figure 1: An Exemplary Vehicular Network Architecture for V2I and V2V 460 4.1. Vehicular Network Architecture 462 Figure 1 shows an exemplary vehicular network architecture for V2I 463 and V2V in a road network. The vehicular network architecture 464 contains vehicles, IP-RSUs, Vehicular Cloud, Traffic Control Center, 465 and Mobility Anchor as components. However, some components in the 466 vehicular network architecture may not be needed for vehicular 467 networks, such as Vehicular Cloud, Traffic Control Center, and 468 Mobility Anchor. 470 As shown in this figure, IP-RSUs as routers and vehicles with IP-OBU 471 have wireless media interfaces for VANET. Furthermore, the wireless 472 media interfaces are autoconfigured with a global IPv6 prefix (e.g., 473 2001:DB8:1:1::/64) to support both V2V and V2I networking. Note that 474 2001:DB8::/32 is a documentation prefix [RFC3849] for example 475 prefixes in this document, and also that any routable IPv6 address 476 needs to be routable in a VANET and a vehicular network including IP- 477 RSUs. 479 For IPv6 packets transported over IEEE 802.11-OCB, [RFC8691] 480 specifies several details, including Maximum Transmission Unit (MTU), 481 frame format, link-local address, address mapping for unicast and 482 multicast, stateless autoconfiguration, and subnet structure. An 483 Ethernet Adaptation (EA) layer is in charge of transforming some 484 parameters between IEEE 802.11 MAC layer and IPv6 network layer, 485 which is located between IEEE 802.11-OCB's logical link control layer 486 and IPv6 network layer. This IPv6 over 802.11-OCB can be used for 487 both V2V and V2I in IPv6-based vehicular networks. 489 In Figure 1, three IP-RSUs (IP-RSU1, IP-RSU2, and IP-RSU3) are 490 deployed in the road network and are connected with each other 491 through the wired networks (e.g., Ethernet), which are part of a 492 Vehicular Cloud. A Traffic Control Center (TCC) is connected to the 493 Vehicular Cloud for the management of IP-RSUs and vehicles in the 494 road network. A Mobility Anchor (MA) may be located in the TCC as a 495 mobility management controller, which is a controller for the 496 mobility management of vehicles. Vehicle2, Vehicle3, and Vehicle4 497 are wirelessly connected to IP-RSU1, IP-RSU2, and IP-RSU3, 498 respectively. The three wireless networks of IP-RSU1, IP-RSU2, and 499 IP-RSU3 can belong to three different subnets (i.e., Subnet1, 500 Subnet2, and Subnet3), respectively. Those three subnets use three 501 different prefixes (i.e., Prefix1, Prefix2, and Prefix3). 503 A single subnet prefix can span multiple vehicles in VANET. For 504 example, in Figure 1, for Prefix 1, three vehicles (i.e., Vehicle1, 505 Vehicle2, and Vehicle5) can construct a connected VANET. Also, for 506 Prefix 2, two vehicles (i.e., Vehicle3 and Vehicle6) can construct 507 another connected VANET, and for Prefix 3, two vehicles (i.e., 508 Vehicle4 and Vehicle7) can construct another connected VANET. 510 In wireless subnets in vehicular networks (e.g., Subnet1 and Subnet2 511 in Figure 1), vehicles can construct a connected VANET (with an 512 arbitrary graph topology) and can communicate with each other via V2V 513 communication. Vehicle1 can communicate with Vehicle2 via V2V 514 communication, and Vehicle2 can communicate with Vehicle3 via V2V 515 communication because they are within the wireless communication 516 range for each other. On the other hand, Vehicle3 can communicate 517 with Vehicle4 via the vehicular infrastructure (i.e., IP-RSU2 and IP- 518 RSU3) by employing V2I (i.e., V2I2V) communication because they are 519 not within the wireless communication range for each other. 521 An IPv6 mobility solution is needed in vehicular networks so that a 522 vehicle's TCP session can be continued while it moves from an IP- 523 RSU's wireless coverage to another IP-RSU's wireless coverage. In 524 Figure 1, assuming that Vehicle2 has a TCP session with a 525 corresponding node in the vehicular cloud, Vehicle2 can move from IP- 526 RSU1's wireless coverage to IP-RSU2's wireless coverage. In this 527 case, a handover for Vehicle2 needs to be performed by either a host- 528 based mobility management scheme (e.g., MIPv6 [RFC6275]) or a 529 network-based mobility management scheme (e.g., PMIPv6 [RFC5213]). 530 In the host-based mobility scheme, an IP-RSU plays a role of a home 531 agent in a visited network. On the other hand, in the network-based 532 mobility scheme, an MA plays a role of a mobility management 533 controller such as a Local Mobility Anchor (LMA) in PMIPv6, and an 534 IP-RSU plays a role of an access router such as a Mobile Access 535 Gateway (MAG) in PMIPv6 [RFC5213]. 537 In vehicular networks, the control plane can be separated from the 538 data plane for efficient mobility management and data forwarding. 539 The separation of the control plane and data plane can be performed 540 by the Software-Defined Networking (SDN) [RFC7149]. An MA can 541 configure and monitor its IP-RSUs and vehicles for mobility 542 management, location management, and security services in an 543 efficient way. 545 The mobility information of a GPS receiver mounted in its vehicle 546 (e.g., position, speed, and direction) can be used to accommodate 547 mobility-aware proactive handover schemes, which can perform the 548 handover of a vehicle according to its mobility and the wireless 549 signal strength of a vehicle and an IP-RSU in a proactive way. 551 Vehicles can use the TCC as their Home Network having a home agent 552 for mobility management as in MIPv6 [RFC6275] and PMIPv6 [RFC5213], 553 so the TCC maintains the mobility information of vehicles for 554 location management. IP tunneling over the wireless link should be 555 avoided for performance efficiency. Also, in vehicular networks, 556 asymmetric links sometimes exist and must be considered for wireless 557 communications such as V2V and V2I. 559 +-----------------+ 560 (*)<........>(*) +----->| Vehicular Cloud | 561 2001:DB8:1:1::/64 | | | +-----------------+ 562 +------------------------------+ +---------------------------------+ 563 | v | | v v | 564 | +-------+ +-------+ | | +-------+ +-------+ | 565 | | Host1 | |IP-OBU1| | | |IP-RSU1| | Host3 | | 566 | +-------+ +-------+ | | +-------+ +-------+ | 567 | ^ ^ | | ^ ^ | 568 | | | | | | | | 569 | v v | | v v | 570 | ---------------------------- | | ------------------------------- | 571 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 572 | | | | | | 573 | v | | v | 574 | +-------+ +-------+ | | +-------+ +-------+ +-------+ | 575 | | Host2 | |Router1| | | |Router2| |Server1|...|ServerN| | 576 | +-------+ +-------+ | | +-------+ +-------+ +-------+ | 577 | ^ ^ | | ^ ^ ^ | 578 | | | | | | | | | 579 | v v | | v v v | 580 | ---------------------------- | | ------------------------------- | 581 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 582 +------------------------------+ +---------------------------------+ 583 Vehicle1 (Moving Network1) EN1 (Fixed Network1) 585 <----> Wired Link <....> Wireless Link (*) Antenna 587 Figure 2: Internetworking between Vehicle and Edge Network 589 4.2. V2I-based Internetworking 591 This section discusses the internetworking between a vehicle's 592 internal network (i.e., moving network) and an EN's internal network 593 (i.e., fixed network) via V2I communication. Note that an EN can 594 accommodate multiple routers (or switches) and servers (e.g., ECDs, 595 navigation server, and DNS server) in its internal network. 597 A vehicle's internal network often uses Ethernet to interconnect 598 Electronic Control Units (ECUs) in the vehicle. The internal network 599 can support WiFi and Bluetooth to accommodate a driver's and 600 passenger's mobile devices (e.g., smartphone or tablet). The network 601 topology and subnetting depend on each vendor's network configuration 602 for a vehicle and an EN. It is reasonable to consider the 603 interaction between the internal network and an external network 604 within another vehicle or an EN. 606 As shown in Figure 2, as internal networks, a vehicle's moving 607 network and an EN's fixed network are self-contained networks having 608 multiple subnets and having an edge router (e.g., IP-OBU and IP-RSU) 609 for the communication with another vehicle or another EN. 610 Internetworking between two internal networks via V2I communication 611 requires the exchange of the network parameters and the network 612 prefixes of the internal networks. 614 Figure 2 also shows internetworking between the vehicle's moving 615 network and the EN's fixed network. There exists an internal network 616 (Moving Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and 617 Host2), and two routers (IP-OBU1 and Router1). There exists another 618 internal network (Fixed Network1) inside EN1. EN1 has one host 619 (Host3), two routers (IP-RSU1 and Router2), and the collection of 620 servers (Server1 to ServerN) for various services in the road 621 networks, such as the emergency notification and navigation. 622 Vehicle1's IP-OBU1 (as a mobile router) and EN1's IP-RSU1 (as a fixed 623 router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for 624 V2I networking. Thus, a host (Host1) in Vehicle1 can communicate 625 with a server (Server1) in EN1 for a vehicular service through 626 Vehicle1's moving network, a wireless link between IP-OBU1 and IP- 627 RSU1, and EN1's fixed network. 629 For an IPv6 communication between an IP-OBU and an IP-RSU or between 630 two neighboring IP-OBUs, network parameters need to be shared among 631 them, such as MAC layer and IPv6 layer information. The MAC layer 632 information includes wireless link layer parameters, transmission 633 power level, the MAC address of an external network interface for the 634 internetworking with another IP-OBU or IP-RSU. The IPv6 layer 635 information includes the IPv6 address and network prefix of an 636 external network interface for the internetworking with another IP- 637 OBU or IP-RSU. 639 Through the exchange of network parameters and network prefixes among 640 internal networks, packets can be transmitted between the vehicle's 641 moving network and the EN's fixed network. Thus, V2I requires an 642 efficient exchange protocol for network parameters and an efficient 643 routing protocol for network prefixes. 645 (*)<..........>(*) 646 2001:DB8:1:1::/64 | | 647 +------------------------------+ +------------------------------+ 648 | v | | v | 649 | +-------+ +-------+ | | +-------+ +-------+ | 650 | | Host1 | |IP-OBU1| | | |IP-OBU2| | Host3 | | 651 | +-------+ +-------+ | | +-------+ +-------+ | 652 | ^ ^ | | ^ ^ | 653 | | | | | | | | 654 | v v | | v v | 655 | ---------------------------- | | ---------------------------- | 656 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:30:1::/64 | 657 | | | | | | 658 | v | | v | 659 | +-------+ +-------+ | | +-------+ +-------+ | 660 | | Host2 | |Router1| | | |Router2| | Host4 | | 661 | +-------+ +-------+ | | +-------+ +-------+ | 662 | ^ ^ | | ^ ^ | 663 | | | | | | | | 664 | v v | | v v | 665 | ---------------------------- | | ---------------------------- | 666 | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | 667 +------------------------------+ +------------------------------+ 668 Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) 670 <----> Wired Link <....> Wireless Link (*) Antenna 672 Figure 3: Internetworking between Two Vehicles 674 4.3. V2V-based Internetworking 676 This section discusses the internetworking between the moving 677 networks of two neighboring vehicles via V2V communication. 679 Figure 3 shows internetworking between the moving networks of two 680 neighboring vehicles. There exists an internal network (Moving 681 Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and Host2), 682 and two routers (IP-OBU1 and Router1). There exists another internal 683 network (Moving Network2) inside Vehicle2. Vehicle2 has two hosts 684 (Host3 and Host4), and two routers (IP-OBU2 and Router2). Vehicle1's 685 IP-OBU1 (as a mobile router) and Vehicle2's IP-OBU2 (as a mobile 686 router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for 687 V2V networking. Thus, a host (Host1) in Vehicle1 can communicate 688 with another host (Host3) in Vehicle2 for a vehicular service through 689 Vehicle1's moving network, a wireless link between IP-OBU1 and IP- 690 OBU2, and Vehicle2's moving network. 692 (*)<..................>(*)<..................>(*) 693 | | | 694 +-----------+ +-----------+ +-----------+ 695 | | | | | | 696 | +-------+ | | +-------+ | | +-------+ | 697 | |IP-OBU1| | | |IP-OBU2| | | |IP-OBU3| | 698 | +-------+ | | +-------+ | | +-------+ | 699 | | | | | | 700 | +-------+ | | +-------+ | | +-------+ | 701 | | Host1 | | | | Host2 | | | | Host3 | | 702 | +-------+ | | +-------+ | | +-------+ | 703 | | | | | | 704 +-----------+ +-----------+ +-----------+ 705 Vehicle1 Vehicle2 Vehicle3 707 <....> Wireless Link (*) Antenna 709 Figure 4: Multihop Internetworking between Two Vehicle Networks 711 Figure 4 shows multihop internetworking between the moving networks 712 of two vehicles in the same VANET. For example, Host1 in Vehicle1 713 can communicate with Host3 in Vehicle3 via IP-OBU1 in Vehicle1, IP- 714 OBU2 in Vehicle2, and IP-OBU3 in Vehicle3 in a linear topology as 715 shown in the figure. 717 5. Problem Statement 719 In order to specify protocols using the abovementioned architecture 720 for VANETs, IPv6 core protocols have to be adapted to overcome 721 certain challenging aspects of vehicular networking. Since the 722 vehicles are likely to be moving at great speed, protocol exchanges 723 need to be completed in a time relatively small compared to the 724 lifetime of a link between a vehicle and an IP-RSU, or between two 725 vehicles. This has a major impact on IPv6 Neighbor Discovery (ND). 726 Mobility Management (MM) is also vulnerable to disconnections that 727 occur before the completion of identity verification and tunnel 728 management. This is especially true given the unreliable nature of 729 wireless communications. Thus, this section presents key topics such 730 as neighbor discovery and mobility management. 732 5.1. Neighbor Discovery 734 IPv6 ND [RFC4861][RFC4862] is a core part of the IPv6 protocol suite. 735 IPv6 ND is designed for point-to-point links and transit links (e.g., 736 Ethernet). It assumes an efficient and reliable support of multicast 737 from the link layer for various network operations such as MAC 738 Address Resolution (AR) and Duplicate Address Detection (DAD). 740 Vehicles move quickly within the communication coverage of any 741 particular vehicle or IP-RSU. Before the vehicles can exchange 742 application messages with each other, they need to be configured with 743 a link-local IPv6 address or a global IPv6 address, and run IPv6 ND. 745 The legacy DAD assumes that a node with an IPv6 address can reach any 746 other node with the scope of its address at the time it claims its 747 address, and can hear any future claim for that address by another 748 party within the scope of its address for the duration of the address 749 ownership. However, the partitioning and merging of VANETs makes 750 this assumption frequently invalid in vehicular networks. The 751 merging and partitioning of VANETs occurs frequently in vehicular 752 networks. This merging and partitioning should be considered for the 753 IPv6 ND such as IPv6 Stateless Address Autoconfiguration (SLAAC) 754 [RFC4862]. Due to the merging of VANETs, two IPv6 addresses may 755 conflict with each other though they were unique before the merging. 756 Also, the partitioning of a VANET may make vehicles with the same 757 prefix be physically unreachable. Also, SLAAC needs to prevent IPv6 758 address duplication due to the merging of VANETs. According to the 759 merging and partitioning, a destination vehicle (as an IPv6 host) 760 needs to be distinguished as either an on-link host or an off-link 761 host even though the source vehicle uses the same prefix with the 762 destination vehicle. 764 To efficiently prevent the IPv6 address duplication due to the VANET 765 partitioning and merging from happing in vehicular networks, the 766 vehicular networks need to support a vehicular-network-wide DAD by 767 defining a scope that is compatible with the legacy DAD. In this 768 case, two vehicles can communicate with each other when there exists 769 a communication path over VANET or a combination of VANETs and IP- 770 RSUs, as shown in Figure 1. By using the vehicular-network-wide DAD, 771 vehicles can assure that their IPv6 addresses are unique in the 772 vehicular network whenever they are connected to the vehicular 773 infrastructure or become disconnected from it in the form of VANET. 775 ND time-related parameters such as router lifetime and Neighbor 776 Advertisement (NA) interval need to be adjusted for high-speed 777 vehicles and vehicle density. As vehicles move faster, the NA 778 interval should decrease (e.g., from 1 sec to 0.5 sec) for the NA 779 messages to reach the neighboring vehicles promptly. Also, as 780 vehicle density is higher, the NA interval should increase (e.g., 781 from 0.5 sec to 1 sec) for the NA messages to reduce collision 782 probability with other NA messages. 784 For IPv6-based safety applications (e.g., context-aware navigation, 785 adaptive cruise control, and platooning) in vehicular networks, the 786 delay-bounded data delivery is critical. Implementations for such 787 applications are not available yet. IPv6 ND needs to efficiently 788 work to support IPv6-based safety applications. 790 5.1.1. Link Model 792 A prefix model for a vehicular network needs to facilitate the 793 communication between two vehicles with the same prefix regardless of 794 the vehicular network topology as long as there exist bidirectional 795 E2E paths between them in the vehicular network including VANETs and 796 IP-RSUs. This prefix model allows vehicles with the same prefix to 797 communicate with each other via a combination of multihop V2V and 798 multihop V2I with VANETs and IP-RSUs. 800 IPv6 protocols work under certain assumptions for the link model that 801 do not necessarily hold in a vehicular wireless link 802 [VIP-WAVE][RFC5889]. For instance, some IPv6 protocols assume 803 symmetry in the connectivity among neighboring interfaces [RFC6250]. 804 However, radio interference and different levels of transmission 805 power may cause asymmetric links to appear in vehicular wireless 806 links. As a result, a new vehicular link model needs to consider the 807 asymmetry of dynamically changing vehicular wireless links. 809 There is a relationship between a link and a prefix, besides the 810 different scopes that are expected from the link-local and global 811 types of IPv6 addresses. In an IPv6 link, it is assumed that all 812 interfaces which are configured with the same subnet prefix and with 813 on-link bit set can communicate with each other on an IPv6 link. 814 However, the vehicular link model needs to define the relationship 815 between a link and a prefix, considering the dynamics of wireless 816 links and the characteristics of VANET. 818 A VANET can have multiple links between pairs of vehicles within 819 wireless communication range, as shown in Figure 4. When two 820 vehicles belong to the same VANET, but they are out of wireless 821 communication range, they cannot communicate directly with each 822 other. Suppose that a global-scope IPv6 prefix is assigned to VANETs 823 in vehicular networks. Even though two vehicles in the same VANET 824 configure their IPv6 addresses with the same IPv6 prefix, they may 825 not communicate with each other not in a one hop in the same VANET 826 because of the multihop network connectivity between them. Thus, in 827 this case, the concept of an on-link IPv6 prefix does not hold 828 because two vehicles with the same on-link IPv6 prefix cannot 829 communicate directly with each other. Also, when two vehicles are 830 located in two different VANETs with the same IPv6 prefix, they 831 cannot communicate with each other. When these two VANETs converge 832 to one VANET, the two vehicles can communicate with each other in a 833 multihop fashion, for example, wheh they are Vehicle1 and Vehicle3, 834 as shown in Figure 4. 836 From the previous observation, a vehicular link model should consider 837 the frequent partitioning and merging of VANETs due to vehicle 838 mobility. Therefore, the vehicular link model needs to use an on- 839 link prefix and off-link prefix according to the network topology of 840 vehicles such as a one-hop reachable network and a multihop reachable 841 network (or partitioned networks). If the vehicles with the same 842 prefix are reachable with each other in one hop, the prefix should be 843 on-link. On the other hand, if some of the vehicles with the same 844 prefix are not reachable with each other in one hop due to either the 845 multihop topology in the VANET or multiple partitions, the prefix 846 should be off-link. 848 The vehicular link model needs to support the multihop routing in a 849 connected VANET where the vehicles with the same global-scope IPv6 850 prefix are connected in one hop or multiple hops. It also needs to 851 support the multihop routing in multiple connected VANETs through 852 infrastructure nodes (e.g., IP-RSU) where they are connected to the 853 infrastructure. For example, in Figure 1, suppose that Vehicle1, 854 Vehicle2, and Vehicle3 are configured with their IPv6 addresses based 855 on the same global-scope IPv6 prefix. Vehicle1 and Vehicle3 can also 856 communicate with each other via either multihop V2V or multihop 857 V2I2V. When the two vehicles of Vehicle1 and Vehicle3 are connected 858 in a VANET, it will be more efficient for them to directly 859 communicate with each other via VANET rather than indirectly via IP- 860 RSUs. On the other hand, when the two vehicles of Vehicle1 and 861 Vehicle3 are far away from the communication range in separate VANETs 862 and under two different IP-RSUs, they can communicate with each other 863 through the relay of IP-RSUs via V2I2V. Thus, two separate VANETs 864 can merge into one network via IP-RSU(s). Also, newly arriving 865 vehicles can merge two separate VANETs into one VANET if they can 866 play a role of a relay node for those VANETs. 868 5.1.2. MAC Address Pseudonym 870 For the protection of drivers' privacy, a pseudonym of a MAC address 871 of a vehicle's network interface should be used, so that the MAC 872 address can be changed periodically. However, although such a 873 pseudonym of a MAC address can protect some extent of privacy of a 874 vehicle, it may not be able to resist attacks on vehicle 875 identification by other fingerprint information, for example, the 876 scrambler seed embedded in IEEE 802.11-OCB frames [Scrambler-Attack]. 877 The pseudonym of a MAC address affects an IPv6 address based on the 878 MAC address, and a transport-layer (e.g., TCP and and SCTP) session 879 with an IPv6 address pair. However, the pseudonym handling is not 880 implemented and tested yet for applications on IP-based vehicular 881 networking. 883 In the ETSI standards, for the sake of security and privacy, an ITS 884 station (e.g., vehicle) can use pseudonyms for its network interface 885 identities (e.g., MAC address) and the corresponding IPv6 addresses 886 [Identity-Management]. Whenever the network interface identifier 887 changes, the IPv6 address based on the network interface identifier 888 needs to be updated, and the uniqueness of the address needs to be 889 checked through the DAD procedure. For vehicular networks with high 890 mobility and density, this DAD needs to be performed efficiently with 891 minimum overhead so that the vehicles can exchange application 892 messages (e.g., collision avoidance and accident notification) with 893 each other with a short interval (e.g., 0.5 second) 894 [NHTSA-ACAS-Report]. 896 5.1.3. Routing 898 For multihop V2V communications in either a VANET or VANETs via IP- 899 RSUs, a vehicular ad hoc routing protocol (e.g., AODV and OLSRv2) may 900 be required to support both unicast and multicast in the links of the 901 subnet with the same IPv6 prefix. However, it will be costly to run 902 both vehicular ND and a vehicular ad hoc routing protocol in terms of 903 control traffic overhead [ID-Multicast-Problems]. 905 A routing protocol for VANET may cause redundant wireless frames in 906 the air to check the neighborhood of each vehicle and compute the 907 routing information in VANET with a dynamic network topology because 908 the IPv6 ND is used to check the neighborhood of each vehicle. Thus, 909 the vehicular routing needs to take advantage of the IPv6 ND to 910 minimize its control overhead. 912 5.2. Mobility Management 914 The seamless connectivity and timely data exchange between two end 915 points requires an efficient mobility management including location 916 management and handover. Most of vehicles are equipped with a GPS 917 receiver as part of a dedicated navigation system or a corresponding 918 smartphone App. Note that The GPS receiver may not provide vehicles 919 with accurate location information in adverse environments such as a 920 building area and tunnel. The location precision can be improved by 921 the assistance from the IP-RSUs or a cellular system with a GPS 922 receiver for location information. 924 With a GPS navigator, an efficient mobility management can be 925 performed with the help of vehicles periodically reporting their 926 current position and trajectory (i.e., navigation path) to the 927 vehicular infrastructure (having IP-RSUs and an MA in TCC). This 928 vehicular infrastructure can predict the future positions of the 929 vehicles with their mobility information (i.e., the current position, 930 speed, direction, and trajectory) for the efficient mobility 931 management (e.g., proactive handover). For a better proactive 932 handover, link-layer parameters, such as the signal strength of a 933 link-layer frame (e.g., Received Channel Power Indicator (RCPI) 934 [VIP-WAVE]), can be used to determine the moment of a handover 935 between IP-RSUs along with mobility information. 937 By predicting a vehicle's mobility, the vehicular infrastructure 938 needs to better support IP-RSUs to perform efficient SLAAC, data 939 forwarding, horizontal handover (i.e., handover in wireless links 940 using a homogeneous radio technology), and vertical handover (i.e., 941 handover in wireless links using heterogeneous radio technologies) in 942 advance along with the movement of the vehicle. 944 For example, as shown in Figure 1, when a vehicle (e.g., Vehicle2) is 945 moving from the coverage of an IP-RSU (e.g., IP-RSU1) into the 946 coverage of another IP-RSU (e.g., IP-RSU2) belonging to a different 947 subnet, the IP-RSUs can proactively support the IPv6 mobility of the 948 vehicle, while performing the SLAAC, data forwarding, and handover 949 for the sake of the vehicle. 951 Therefore, for the proactive and seamless IPv6 mobility of vehicles, 952 the vehicular infrastructure (including IP-RSUs and MA) needs to 953 efficiently perform the mobility management of the vehicles with 954 their mobility information and link-layer information. 956 6. Security Considerations 958 This section discusses security and privacy for IPv6-based vehicular 959 networking. The security and privacy is one of key components in 960 IPv6-based vehicular networking along with neighbor discovery and 961 mobility management. 963 Security and privacy are paramount in the V2I, V2V, and V2X 964 networking. Only authorized vehicles need to be allowed to use the 965 vehicular networking. Also, in-vehicle devices (e.g., ECU) and 966 mobile devices (e.g., smartphone) in a vehicle need to communicate 967 with other in-vehicle devices and mobile devices in another vehicle, 968 and other servers in an IP-RSU in a secure way. Even a perfectly 969 authorized and legitimate vehicle may be hacked to run malicious 970 applications to track and collect its and other vehicles' 971 information. For this case, an attack mitigation process may be 972 required to reduce the aftermath of the malicious behaviors. 974 Strong security measures shall protect vehicles roaming in road 975 networks from the attacks of malicious nodes, which are controlled by 976 hackers. For safety applications, the cooperation among vehicles is 977 assumed. Malicious nodes may disseminate wrong driving information 978 (e.g., location, speed, and direction) to make driving be unsafe. 980 For example, Sybil attack, which tries to confuse a vehicle with 981 multiple false identities, disturbs a vehicle in taking a safe 982 maneuver. This sybil attack needs to be prevented through the 983 cooperation between good vehicles and IP-RSUs. Note that good 984 vehicles are ones with valid certificates that are determined by the 985 authentication process with an authentication server in the vehicular 986 cloud. However, applications on IPv6-based vehicular networking, 987 which are resilient to such a sybil attack, are not developed and 988 tested yet. 990 To identify the genuineness of vehicles against malicious vehicles, 991 an authentication method is required. A Vehicle Identification 992 Number (VIN) and a user certificate along with in-vehicle device's 993 identifier generation can be used to efficiently authenticate a 994 vehicle or a user through a road infrastructure node (e.g., IP-RSU) 995 connected to an authentication server in the vehicular cloud. Also, 996 Transport Layer Security (TLS) certificates can be used for the 997 vehicle authentication to allow secure E2E vehicle communications. 998 To identify the genuineness of vehicles against malicious vehicles, 999 an authentication method is required. For vehicle authentication, 1000 information available from a vehicle or a driver (e.g., Vehicle 1001 Identification Number (VIN) and Transport Layer Security (TLS) 1002 certificate [RFC8446]) needs to be used to efficiently authenticate a 1003 vehicle or a user with the help of a road infrastructure node (e.g., 1004 IP-RSU) connected to an authentication server in the vehicular cloud. 1006 For secure V2I communication, a secure channel between a mobile 1007 router (i.e., IP-OBU) in a vehicle and a fixed router (i.e., IP-RSU) 1008 in an EN needs to be established, as shown in Figure 2. Also, for 1009 secure V2V communication, a secure channel between a mobile router 1010 (i.e., IP-OBU) in a vehicle and a mobile router (i.e., IP-OBU) in 1011 another vehicle needs to be established, as shown in Figure 3. 1013 To prevent an adversary from tracking a vehicle with its MAC address 1014 or IPv6 address, MAC address pseudonym needs to be provided to the 1015 vehicle; that is, each vehicle periodically updates its MAC address 1016 and the corresponding IPv6 address [RFC4086][RFC4941]. Such an 1017 update of the MAC and IPv6 addresses should not interrupt the E2E 1018 communications between two vehicles (or between a vehicle and an IP- 1019 RSU) for a long-living transport-layer session. However, if this 1020 pseudonym is performed without strong E2E confidentiality, there will 1021 be no privacy benefit from changing MAC and IPv6 addresses, because 1022 an adversary can observe the change of the MAC and IPv6 addresses and 1023 track the vehicle with those addresses. 1025 For the IPv6 ND, the DAD is required for the uniqueness of the IPv6 1026 address of a vehicle's wireless interface. This DAD can be used as a 1027 flooding attack that makes the DAD-related ND packets are 1028 disseminated over the VANET or vehicular networks. Thus, the 1029 vehicles and IP-RSUs need to filter out suspicious ND traffic in 1030 advance. 1032 For the mobility management, a malicious vehicle can construct 1033 multiple virtual bogus vehicles, and register them with IP-RSUs and 1034 MA. This registration makes the IP-RSUs and MA waste their 1035 resources. The IP-RSUs and MA need to determine whether a vehicle is 1036 genuine or bogus in the mobility management. Also, the 1037 confidentiality of control packets and data packets among IP-RSUs and 1038 MA, the E2E paths (e.g., tunnels) need to be protected by secure 1039 communication channels. In addition, to prevent bogus IP-RSUs and MA 1040 from interfering IPv6 mobility of vehicles, the mutual authentication 1041 among them needs to be performed by certificates (e.g., TLS 1042 certificate). 1044 7. Informative References 1046 [Automotive-Sensing] 1047 Choi, J., Va, V., Gonzalez-Prelcic, N., Daniels, R., R. 1048 Bhat, C., and R. W. Heath, "Millimeter-Wave Vehicular 1049 Communication to Support Massive Automotive Sensing", 1050 IEEE Communications Magazine, December 2016. 1052 [CA-Cruise-Control] 1053 California Partners for Advanced Transportation Technology 1054 (PATH), "Cooperative Adaptive Cruise Control", [Online] 1055 Available: 1056 http://www.path.berkeley.edu/research/automated-and- 1057 connected-vehicles/cooperative-adaptive-cruise-control, 1058 2017. 1060 [CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A 1061 Framework of Context-Awareness Safety Driving in Vehicular 1062 Networks", International Workshop on Device Centric Cloud 1063 (DC2), March 2016. 1065 [DSRC] ASTM International, "Standard Specification for 1066 Telecommunications and Information Exchange Between 1067 Roadside and Vehicle Systems - 5 GHz Band Dedicated Short 1068 Range Communications (DSRC) Medium Access Control (MAC) 1069 and Physical Layer (PHY) Specifications", 1070 ASTM E2213-03(2010), October 2010. 1072 [EU-2008-671-EC] 1073 European Union, "Commission Decision of 5 August 2008 on 1074 the Harmonised Use of Radio Spectrum in the 5875 - 5905 1075 MHz Frequency Band for Safety-related Applications of 1076 Intelligent Transport Systems (ITS)", EU 2008/671/EC, 1077 August 2008. 1079 [FirstNet] 1080 U.S. National Telecommunications and Information 1081 Administration (NTIA), "First Responder Network Authority 1082 (FirstNet)", [Online] 1083 Available: https://www.firstnet.gov/, 2012. 1085 [FirstNet-Report] 1086 First Responder Network Authority, "FY 2017: ANNUAL REPORT 1087 TO CONGRESS, Advancing Public Safety Broadband 1088 Communications", FirstNet FY 2017, December 2017. 1090 [Fuel-Efficient] 1091 van de Hoef, S., H. Johansson, K., and D. V. Dimarogonas, 1092 "Fuel-Efficient En Route Formation of Truck Platoons", 1093 IEEE Transactions on Intelligent Transportation Systems, 1094 January 2018. 1096 [ID-Multicast-Problems] 1097 Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC. 1098 Zuniga, "Multicast Considerations over IEEE 802 Wireless 1099 Media", draft-ietf-mboned-ieee802-mcast-problems-11 (work 1100 in progress), December 2019. 1102 [Identity-Management] 1103 Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer 1104 Identities Management in ITS Stations", The 10th 1105 International Conference on ITS Telecommunications, 1106 November 2010. 1108 [IEEE-802.11-OCB] 1109 "Part 11: Wireless LAN Medium Access Control (MAC) and 1110 Physical Layer (PHY) Specifications", IEEE Std 1111 802.11-2016, December 2016. 1113 [IEEE-802.11p] 1114 "Part 11: Wireless LAN Medium Access Control (MAC) and 1115 Physical Layer (PHY) Specifications - Amendment 6: 1116 Wireless Access in Vehicular Environments", IEEE Std 1117 802.11p-2010, June 2010. 1119 [ISO-ITS-IPv6] 1120 ISO/TC 204, "Intelligent Transport Systems - 1121 Communications Access for Land Mobiles (CALM) - IPv6 1122 Networking", ISO 21210:2012, June 2012. 1124 [NHTSA-ACAS-Report] 1125 National Highway Traffic Safety Administration (NHTSA), 1126 "Final Report of Automotive Collision Avoidance Systems 1127 (ACAS) Program", DOT HS 809 080, August 2000. 1129 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 1130 Demand Distance Vector (AODV) Routing", RFC 3561, July 1131 2003. 1133 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1134 RFC 3753, June 2004. 1136 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 1137 Reserved for Documentation", RFC 3849, July 2004. 1139 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1140 "Randomness Requirements for Security", RFC 4086, June 1141 2005. 1143 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1144 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 1145 September 2007. 1147 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1148 Address Autoconfiguration", RFC 4862, September 2007. 1150 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1151 Extensions for Stateless Address Autoconfiguration in 1152 IPv6", RFC 4941, September 2007. 1154 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1155 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1156 RFC 5213, August 2008. 1158 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 1159 Provisioning of Wireless Access Points (CAPWAP) Protocol 1160 Specification", RFC 5415, March 2009. 1162 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 1163 Hoc Networks", RFC 5889, September 2010. 1165 [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, May 1166 2011. 1168 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1169 Support in IPv6", RFC 6275, July 2011. 1171 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1172 "Neighbor Discovery Optimization for IPv6 over Low-Power 1173 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1174 November 2012. 1176 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1177 Networking: A Perspective from within a Service Provider 1178 Environment", RFC 7149, March 2014. 1180 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 1181 "The Optimized Link State Routing Protocol Version 2", 1182 RFC 7181, April 2014. 1184 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1185 (IPv6) Specification", RFC 8200, July 2017. 1187 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1188 Version 1.3", RFC 8446, August 2018. 1190 [RFC8691] Benamar, N., Haerri, J., Lee, J., and T. Ernst, "Basic 1191 Support for IPv6 Networks Operating Outside the Context of 1192 a Basic Service Set over IEEE Std 802.11", RFC 8691, 1193 December 2019. 1195 [SAINT] Jeong, J., Jeong, H., Lee, E., Oh, T., and D. Du, "SAINT: 1196 Self-Adaptive Interactive Navigation Tool for Cloud-Based 1197 Vehicular Traffic Optimization", IEEE Transactions on 1198 Vehicular Technology, Vol. 65, No. 6, June 2016. 1200 [SAINTplus] 1201 Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D. 1202 Du, "SAINT+: Self-Adaptive Interactive Navigation Tool+ 1203 for Emergency Service Delivery Optimization", 1204 IEEE Transactions on Intelligent Transportation Systems, 1205 June 2017. 1207 [SANA] Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation 1208 Application for Pedestrian Protection in Vehicular 1209 Networks", Springer Lecture Notes in Computer Science 1210 (LNCS), Vol. 9502, December 2015. 1212 [Scrambler-Attack] 1213 Bloessl, B., Sommer, C., Dressier, F., and D. Eckhoff, 1214 "The Scrambler Attack: A Robust Physical Layer Attack on 1215 Location Privacy in Vehicular Networks", IEEE 2015 1216 International Conference on Computing, Networking and 1217 Communications (ICNC), February 2015. 1219 [Timing-Attack] 1220 Matte, C., Cunche, M., Rousseau, F., and M. Vanhoef, 1221 "Defeating MAC Address Randomization Through Timing 1222 Attacks", ACM the 9th ACM Conference on Security & Privacy 1223 in Wireless and Mobile Networks (WiSec '16), July 2016. 1225 [Truck-Platooning] 1226 California Partners for Advanced Transportation Technology 1227 (PATH), "Automated Truck Platooning", [Online] Available: 1228 http://www.path.berkeley.edu/research/automated-and- 1229 connected-vehicles/truck-platooning, 2017. 1231 [TS-23.285-3GPP] 1232 3GPP, "Architecture Enhancements for V2X Services", 3GPP 1233 TS 23.285, June 2018. 1235 [VIP-WAVE] 1236 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 1237 Feasibility of IP Communications in 802.11p Vehicular 1238 Networks", IEEE Transactions on Intelligent Transportation 1239 Systems, vol. 14, no. 1, March 2013. 1241 [WAVE-1609.0] 1242 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 1243 in Vehicular Environments (WAVE) - Architecture", IEEE Std 1244 1609.0-2013, March 2014. 1246 [WAVE-1609.2] 1247 IEEE 1609 Working Group, "IEEE Standard for Wireless 1248 Access in Vehicular Environments - Security Services for 1249 Applications and Management Messages", IEEE Std 1250 1609.2-2016, March 2016. 1252 [WAVE-1609.3] 1253 IEEE 1609 Working Group, "IEEE Standard for Wireless 1254 Access in Vehicular Environments (WAVE) - Networking 1255 Services", IEEE Std 1609.3-2016, April 2016. 1257 [WAVE-1609.4] 1258 IEEE 1609 Working Group, "IEEE Standard for Wireless 1259 Access in Vehicular Environments (WAVE) - Multi-Channel 1260 Operation", IEEE Std 1609.4-2016, March 2016. 1262 Appendix A. Changes from draft-ietf-ipwave-vehicular-networking-12 1264 The following changes are made from draft-ietf-ipwave-vehicular- 1265 networking-12: 1267 o This version is revised based on the comments from Carlos 1268 Bernardos. 1270 o This version focuses on problems rather than solutions for IPWAVE. 1271 Also, this version addresses the requirements of IPv6 neighbor 1272 discovery, mobility management, and security and privacy. 1274 o In Section 2, IP-OBU and IP-RSU are used instead of OBU and RSU, 1275 respectively. 1277 o In Section 4.1, an exemplary vehicular network architecture is 1278 illustrated for the problem statement as Figure 1. 1280 Appendix B. Acknowledgments 1282 This work was supported by Basic Science Research Program through the 1283 National Research Foundation of Korea (NRF) funded by the Ministry of 1284 Education (2017R1D1A1B03035885). 1286 This work was supported in part by the MSIT (Ministry of Science and 1287 ICT), Korea, under the ITRC (Information Technology Research Center) 1288 support program (IITP-2019-2017-0-01633) supervised by the IITP 1289 (Institute for Information & communications Technology Promotion). 1291 This work was supported in part by the French research project 1292 DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded 1293 by the European Commission I (636537-H2020). 1295 Appendix C. Contributors 1297 This document is a group work of IPWAVE working group, greatly 1298 benefiting from inputs and texts by Rex Buddenberg (Naval 1299 Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest 1300 University of Technology and Economics), Jose Santa Lozanoi 1301 (Universidad of Murcia), Richard Roy (MIT), Francois Simon (Pilot), 1302 Sri Gundavelli (Cisco), Erik Nordmark, Dirk von Hugo (Deutsche 1303 Telekom), Pascal Thubert (Cisco), Carlos Bernardos (UC3M), Russ 1304 Housley (Vigil Security), and Suresh Krishnan (Kaloom). The authors 1305 sincerely appreciate their contributions. 1307 The following are co-authors of this document: 1309 Nabil Benamar 1310 Department of Computer Sciences 1311 High School of Technology of Meknes 1312 Moulay Ismail University 1313 Morocco 1315 Phone: +212 6 70 83 22 36 1316 EMail: benamar73@gmail.com 1318 Sandra Cespedes 1319 NIC Chile Research Labs 1320 Universidad de Chile 1321 Av. Blanco Encalada 1975 1322 Santiago 1323 Chile 1325 Phone: +56 2 29784093 1326 EMail: scespede@niclabs.cl 1328 Jerome Haerri 1329 Communication Systems Department 1330 EURECOM 1331 Sophia-Antipolis 1332 France 1334 Phone: +33 4 93 00 81 34 1335 EMail: jerome.haerri@eurecom.fr 1337 Dapeng Liu 1338 Alibaba 1339 Beijing, Beijing 100022 1340 China 1342 Phone: +86 13911788933 1343 EMail: max.ldp@alibaba-inc.com 1345 Tae (Tom) Oh 1346 Department of Information Sciences and Technologies 1347 Rochester Institute of Technology 1348 One Lomb Memorial Drive 1349 Rochester, NY 14623-5603 1350 USA 1352 Phone: +1 585 475 7642 1353 EMail: Tom.Oh@rit.edu 1355 Charles E. Perkins 1356 Futurewei Inc. 1357 2330 Central Expressway 1358 Santa Clara, CA 95050 1359 USA 1361 Phone: +1 408 330 4586 1362 EMail: charliep@computer.org 1364 Alexandre Petrescu 1365 CEA, LIST 1366 CEA Saclay 1367 Gif-sur-Yvette, Ile-de-France 91190 1368 France 1370 Phone: +33169089223 1371 EMail: Alexandre.Petrescu@cea.fr 1373 Yiwen Chris Shen 1374 Department of Computer Science & Engineering 1375 Sungkyunkwan University 1376 2066 Seobu-Ro, Jangan-Gu 1377 Suwon, Gyeonggi-Do 16419 1378 Republic of Korea 1380 Phone: +82 31 299 4106 1381 Fax: +82 31 290 7996 1382 EMail: chrisshen@skku.edu 1383 URI: http://iotlab.skku.edu/people-chris-shen.php 1385 Michelle Wetterwald 1386 FBConsulting 1387 21, Route de Luxembourg 1388 Wasserbillig, Luxembourg L-6633 1389 Luxembourg 1391 EMail: Michelle.Wetterwald@gmail.com 1393 Author's Address 1395 Jaehoon Paul Jeong (editor) 1396 Department of Computer Science and Engineering 1397 Sungkyunkwan University 1398 2066 Seobu-Ro, Jangan-Gu 1399 Suwon, Gyeonggi-Do 16419 1400 Republic of Korea 1402 Phone: +82 31 299 4957 1403 Fax: +82 31 290 7996 1404 EMail: pauljeong@skku.edu 1405 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php