idnits 2.17.1 draft-ietf-ipwave-vehicular-networking-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 3, 2019) is 1660 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Online' is mentioned on line 1139, but not defined == Unused Reference: 'RFC3561' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: 'RFC7181' is defined on line 1100, but no explicit reference was found in the text == Unused Reference: 'Timing-Attack' is defined on line 1131, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-06 == Outdated reference: A later version (-11) exists of draft-jeong-ipwave-vehicular-mobility-management-01 == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-vehicular-neighbor-discovery-07 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPWAVE Working Group J. Jeong, Ed. 3 Internet-Draft Sungkyunkwan University 4 Intended status: Informational October 3, 2019 5 Expires: April 5, 2020 7 IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement 8 and Use Cases 9 draft-ietf-ipwave-vehicular-networking-12 11 Abstract 13 This document discusses the problem statement and use cases of IP- 14 based vehicular networking for Intelligent Transportation Systems 15 (ITS). The main scenarios of vehicular communications are vehicle- 16 to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to- 17 everything (V2X) communications. First, this document explains use 18 cases using V2V, V2I, and V2X networking. Next, it makes a problem 19 statement about key aspects in IP-based vehicular networking, such as 20 IPv6 Neighbor Discovery, Mobility Management, and Security & Privacy. 21 For each key aspect, this document specifies requirements in IP-based 22 vehicular networking, and suggests the direction of solutions 23 satisfying those requirements. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 5, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 9 67 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 11 68 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 13 69 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 14 70 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 15 71 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 16 72 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 17 73 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 18 74 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 19 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 76 7. Informative References . . . . . . . . . . . . . . . . . . . 21 77 Appendix A. Changes from draft-ietf-ipwave-vehicular- 78 networking-11 . . . . . . . . . . . . . . . . . . . 27 79 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 28 80 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 28 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 83 1. Introduction 85 Vehicular networking studies have mainly focused on improving safety 86 and efficiency, and also enabling entertainment in vehicular 87 networks. The Federal Communications Commission (FCC) in the US 88 allocated wireless channels for Dedicated Short-Range Communications 89 (DSRC) [DSRC] in the Intelligent Transportation Systems (ITS) with 90 the frequency band of 5.850 - 5.925 GHz (i.e., 5.9 GHz band). DSRC- 91 based wireless communications can support vehicle-to-vehicle (V2V), 92 vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) 93 networking. The European Union (EU) allocated radio spectrum for 94 safety-related and non-safety-related applications of ITS with the 95 frequency band of 5.875 - 5.905 GHz, as part of the Commission 96 Decision 2008/671/EC [EU-2008-671-EC]. 98 For direct inter-vehicular wireless connectivity, IEEE has amended 99 WiFi standard 802.11 to enable driving safety services based on DSRC 100 for the Wireless Access in Vehicular Environments (WAVE) system. The 101 Physical Layer (L1) and Data Link Layer (L2) issues are addressed in 102 IEEE 802.11p [IEEE-802.11p] for the PHY and MAC of the DSRC, while 103 IEEE 1609.2 [WAVE-1609.2] covers security aspects, IEEE 1609.3 104 [WAVE-1609.3] defines related services at network and transport 105 layers, and IEEE 1609.4 [WAVE-1609.4] specifies the multi-channel 106 operation. IEEE 802.11p was first a separate amendment, but was 107 later rolled into the base 802.11 standard (IEEE 802.11-2012) as IEEE 108 802.11 Outside the Context of a Basic Service Set (OCB) in 2012 109 [IEEE-802.11-OCB]. 111 Along with these WAVE standards, IPv6 [RFC8200] and Mobile IP 112 protocols (e.g., MIPv4 [RFC5944], MIPv6 [RFC6275], and Proxy MIPv6 113 (PMIPv6) [RFC5213][RFC5844]) can be applied to vehicular networks. 114 In addition, ISO has approved a standard specifying the IPv6 network 115 protocols and services to be used for Communications Access for Land 116 Mobiles (CALM) [ISO-ITS-IPv6]. 118 This document describes use cases and a problem statement about IP- 119 based vehicular networking for ITS, which is named IP Wireless Access 120 in Vehicular Environments (IPWAVE). First, it introduces the use 121 cases for using V2V, V2I, and V2X networking in ITS. Next, it makes 122 a problem statement about key aspects in IPWAVE, namely, IPv6 123 Neighbor Discovery, Mobility Management, and Security & Privacy. For 124 each key aspect of the problem statement, this document specifies 125 requirements in IP-based vehicular networking, and proposes the 126 direction of solutions fulfilling those requirements. This document 127 is intended to motivate development of key protocols for IPWAVE. 129 2. Terminology 131 This document uses the following definitions: 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 LiDAR: "Light Detection and Ranging". It is a scanning device to 145 measure a distance to an object by emitting pulsed laser light and 146 measuring the reflected pulsed light. 148 o Mobility Anchor (MA): A node that maintains IP addresses and 149 mobility information of vehicles in a road network to support 150 their address autoconfiguration and mobility management with a 151 binding table. An MA has end-to-end connections with RSUs under 152 its control. 154 o On-Board Unit (OBU): A node that has physical communication 155 devices (e.g., IEEE 802.11-OCB and Cellular V2X (C-V2X) 156 [TS-23.285-3GPP]) for wireless communications with other OBUs and 157 RSUs, and may be connected to in-vehicle devices or networks. An 158 OBU is mounted on a vehicle. 160 o OCB: "Outside the Context of a Basic Service Set". It is 161 differentiated from the Basic Service Set (BSS) mode in IEEE 162 802.11 standard. A node in OCB mode can directly transmit packets 163 to other nodes in its wireless range without the authentication or 164 association process defined in BSS mode [IEEE-802.11-OCB]. 166 o Platooning: Moving vehicles can be grouped together to reduce air- 167 resistance for energy efficiency and reduce the number of drivers 168 such that only the leading vehicle has a driver and the other 169 vehicles are autonomous vehicles without a driver and closely 170 following the leading vehicle [Truck-Platooning]. 172 o Road-Side Unit (RSU): A node that has physical communication 173 devices (e.g., IEEE 802.11-OCB and C-V2X) for wireless 174 communications with vehicles and is also connected to the Internet 175 through a router or switch for packet forwarding. An RSU can 176 accommodate multiple routers (or switches) and servers (e.g., DNS 177 server and edge computing server) in its internal network as an 178 edge computing system. An RSU is typically deployed on the road 179 infrastructure, either at an intersection or in a road segment, 180 but may also be located in a car parking area. 182 o Traffic Control Center (TCC): A node that maintains road 183 infrastructure information (e.g., RSUs, traffic signals, and loop 184 detectors), vehicular traffic statistics (e.g., average vehicle 185 speed and vehicle inter-arrival time per road segment), and 186 vehicle information (e.g., a vehicle's identifier, position, 187 direction, speed, and trajectory as a navigation path). TCC is 188 included in a vehicular cloud for vehicular networks. 190 o Vehicle: A Vehicle in this document is a node that has an OBU for 191 wireless communication with other vehicles and RSUs. It has a 192 radio navigation receiver of Global Positioning System (GPS) for 193 efficient navigation. 195 o Vehicular Ad Hoc Network (VANET): A network that consists of 196 vehicles interconnected by wireless communication. Two vehicles 197 in a VANET can communicate with each other using other vehicles as 198 relays even where they are out of one-hop wireless communication 199 range. 201 o Vehicular Cloud: A cloud infrastructure for vehicular networks, 202 having compute nodes, storage nodes, and network forwarding 203 elements (e.g., switch and router). 205 o Vehicle Detection Loop (i.e., Loop Detector): An inductive device 206 used for detecting vehicles passing or arriving at a certain 207 point, for instance, at an intersection with traffic lights or at 208 a ramp toward a highway. The relatively crude nature of the 209 loop's structure means that only metal masses above a certain size 210 are capable of triggering the detection. 212 o V2I2P: "Vehicle to Infrastructure to Pedestrian". 214 o V2I2V: "Vehicle to Infrastructure to Vehicle". 216 o WAVE: "Wireless Access in Vehicular Environments" [WAVE-1609.0]. 218 3. Use Cases 220 This section explains use cases of V2V, V2I, and V2X networking. The 221 use cases of the V2X networking exclude the ones of the V2V and V2I 222 networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to- 223 Device (V2D). 225 3.1. V2V 227 The use cases of V2V networking discussed in this section include 229 o Context-aware navigation for driving safety and collision 230 avoidance; 232 o Cooperative adaptive cruise control in an urban roadway; 234 o Platooning in a highway; 236 o Cooperative environment sensing. 238 These four techniques will be important elements for self-driving 239 vehicles. 241 Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers 242 to drive safely by alerting the drivers about dangerous obstacles and 243 situations. That is, CASD navigator displays obstacles or 244 neighboring vehicles relevant to possible collisions in real-time 245 through V2V networking. CASD provides vehicles with a class-based 246 automatic safety action plan, which considers three situations, 247 namely, the Line-of-Sight unsafe, Non-Line-of-Sight unsafe, and safe 248 situations. This action plan can be put into action among multiple 249 vehicles using V2V networking. 251 Cooperative Adaptive Cruise Control (CACC) [CA-Cruise-Control] helps 252 vehicles to adapt their speed autonomously through V2V communication 253 among vehicles according to the mobility of their predecessor and 254 successor vehicles in an urban roadway or a highway. Thus, CACC can 255 help adjacent vehicles to efficiently adjust their speed in an 256 interactive way through V2V networking in order to avoid collision. 258 Platooning [Truck-Platooning] allows a series of vehicles (e.g., 259 trucks) to follow each other very closely. Trucks can use V2V 260 communication in addition to forward sensors in order to maintain 261 constant clearance between two consecutive vehicles at very short 262 gaps (from 3 meters to 10 meters). Platooning can maximize the 263 throughput of vehicular traffic in a highway and reduce the gas 264 consumption because the leading vehicle can help the following 265 vehicles to experience less air resistance. 267 Cooperative-environment-sensing use cases suggest that vehicles can 268 share environmental information from various vehicle-mounted sensors, 269 such as radars, LiDARs, and cameras with other vehicles and 270 pedestrians. [Automotive-Sensing] introduces a millimeter-wave 271 vehicular communication for massive automotive sensing. A lot of 272 data can be generated by those sensors, and these data typically need 273 to be routed to different destinations. In addition, from the 274 perspective of driverless vehicles, it is expected that driverless 275 vehicles can be mixed with driver-operated vehicles. Through the 276 cooperative environment sensing, driver-operated vehicles can use 277 environmental information sensed by driverless vehicles for better 278 interaction with the other vehicles and environment. 280 3.2. V2I 282 The use cases of V2I networking discussed in this section include 284 o Navigation service; 286 o Energy-efficient speed recommendation service; 288 o Accident notification service. 290 A navigation service, for example, the Self-Adaptive Interactive 291 Navigation Tool (SAINT) [SAINT], using V2I networking interacts with 292 TCC for the large-scale/long-range road traffic optimization and can 293 guide individual vehicles for appropriate navigation paths in real 294 time. The enhanced version of SAINT [SAINTplus] can give fast moving 295 paths to emergency vehicles (e.g., ambulance and fire engine) to let 296 them reach an accident spot while redirecting other vehicles near the 297 accident spot into efficient detour paths. 299 A TCC can recommend an energy-efficient speed to a vehicle that 300 depends on its traffic environment. [Fuel-Efficient] studies fuel- 301 efficient route and speed plans for platooned trucks. 303 The emergency communication between accident vehicles (or emergency 304 vehicles) and TCC can be performed via either RSU or 4G-LTE networks. 305 The First Responder Network Authority (FirstNet) [FirstNet] is 306 provided by the US government to establish, operate, and maintain an 307 interoperable public safety broadband network for safety and security 308 network services, e.g., emergency calls. The construction of the 309 nationwide FirstNet network requires each state in the US to have a 310 Radio Access Network (RAN) that will connect to the FirstNet's 311 network core. The current RAN is mainly constructed by 4G-LTE for 312 the communication between a vehicle and an infrastructure node (i.e., 313 V2I) [FirstNet-Report], but it is expected that DSRC-based vehicular 314 networks [DSRC] will be available for V2I and V2V in near future. 316 3.3. V2X 318 The use case of V2X networking discussed in this section is 319 pedestrian protection service. 321 A pedestrian protection service, such as Safety-Aware Navigation 322 Application (SANA) [SANA], using V2I2P networking can reduce the 323 collision of a vehicle and a pedestrian carrying a smartphone 324 equipped with a network device for wireless communication (e.g., 325 WiFi) with an RSU. Vehicles and pedestrians can also communicate 326 with each other via an RSU that delivers scheduling information for 327 wireless communication in order to save the smartphones' battery 328 through sleeping mode. 330 For Vehicle-to-Pedestrian (V2P), a vehicle can directly communicate 331 with a pedestrian's smartphone by V2X without RSU relaying. Light- 332 weight mobile nodes such as bicycles may also communicate directly 333 with a vehicle for collision avoidance using V2V. 335 4. Vehicular Networks 337 This section describes a vehicular network architecture supporting 338 V2V, V2I, and V2X communications in vehicular networks. Also, it 339 describes an internal network within a vehicle or RSU, and the 340 internetworking between the internal networks via DSRC links. 342 Traffic Control Center in Vehicular Cloud 343 ******************************************* 344 * * 345 * +-----------------+ * 346 * | Mobility Anchor | * 347 * +-----------------+ * 348 * ^ * 349 * | Ethernet * 350 * v * 351 ******************************************* 352 ^ ^ ^ 353 | Ethernet | Ethernet | Ethernet 354 | | | 355 v v v 356 +--------+ Ethernet +--------+ Ethernet +--------+ 357 | RSU1 |<-------->| RSU2 |<---------->| RSU3 | 358 +--------+ +--------+ +--------+ 359 ^ ^ ^ 360 : : : 361 +-----------------+ +-----------------+ +-----------------+ 362 | : V2I | | : V2I | | : V2I | 363 | v | | v | | v | 364 +--------+ | +--------+ | | +--------+ | | +--------+ | 365 |Vehicle1|===> |Vehicle2|===>| | |Vehicle3|===>| | |Vehicle4|===>| 366 +--------+<...>+--------+<........>+--------+ | | +--------+ | 367 V2V ^ V2V ^ | | ^ | 368 | : V2V | | : V2V | | : V2V | 369 | v | | v | | v | 370 | +--------+ | | +--------+ | | +--------+ | 371 | |Vehicle5|===> | | |Vehicle6|===>| | |Vehicle7|==>| 372 | +--------+ | | +--------+ | | +--------+ | 373 +-----------------+ +-----------------+ +-----------------+ 374 Subnet1 Subnet2 Subnet3 375 (Prefix1) (Prefix2) (Prefix3) 377 <----> Wired Link <....> Wireless Link ===> Moving Direction 379 Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 381 4.1. Vehicular Network Architecture 383 Figure 1 shows an architecture for V2I and V2V networking in a road 384 network. The vehicular network architecture contains vehicles, RSUs, 385 Vehicular Cloud, Traffic Control Center, and Mobility Anchor as 386 components. However, some components in the vehicular network 387 architecture may not be needed for vehicular networking, such as 388 Vehicular Cloud, Traffic Control Center, and Mobility Anchor. 390 As shown in this figure, RSUs as routers and vehicles with OBU have 391 wireless media interfaces for VANET. Furthermore, the wireless media 392 interfaces are autoconfigured with a global IPv6 prefix (e.g., 393 2001:DB8:1:1::/64) to support both V2V and V2I networking. Note that 394 2001:DB8::/32 is a documentation prefix [RFC3849] for example 395 prefixes in this document, and also that any routable IPv6 address 396 needs to be routable in a VANET and a vehicular network including 397 RSUs. 399 For IPv6 packets transported over IEEE 802.11-OCB, 400 [IPv6-over-802.11-OCB] specifies several details, including Maximum 401 Transmission Unit (MTU), frame format, link-local address, address 402 mapping for unicast and multicast, stateless autoconfiguration, and 403 subnet structure. An Ethernet Adaptation (EA) layer is in charge of 404 transforming some parameters between IEEE 802.11 MAC layer and IPv6 405 network layer, which is located between IEEE 802.11-OCB's logical 406 link control layer and IPv6 network layer. This IPv6 over 802.11-OCB 407 can be used for both V2V and V2I in IP-based vehicular networks. 409 In Figure 1, three RSUs (RSU1, RSU2, and RSU3) are deployed in the 410 road network and are connected to a Vehicular Cloud through the 411 Internet. A Traffic Control Center (TCC) is connected to the 412 Vehicular Cloud for the management of RSUs and vehicles in the road 413 network. A Mobility Anchor (MA) can be located in the TCC as its key 414 component for the mobility management of vehicles. Vehicle2, 415 Vehicle3, and Vehicle4 are wirelessly connected to RSU1, RSU2, and 416 RSU3, respectively. The three wireless networks of RSU1, RSU2, and 417 RSU3 can belong to three different subnets (i.e., Subnet1, Subnet2, 418 and Subnet3), respectively. Those three subnets use three different 419 prefixes (i.e., Prefix1, Prefix2, and Prefix3). 421 A single subnet prefix can span multiple vehicles in VANET. For 422 example, in Figure 1, for Prefix 1, three vehicles (i.e., Vehicle1, 423 Vehicle2, and Vehicle5) can construct a connected VANET. Also, for 424 Prefix 2, two vehicles (i.e., Vehicle3 and Vehicle6) can construct 425 another connected VANET, and for Prefix 3, two vehicles (i.e., 426 Vehicle4 and Vehicle7) can construct another connected VANET. 428 In wireless subnets in vehicular networks (e.g., Subnet1 and Subnet2 429 in Figure 1), vehicles can construct a connected VANET (with an 430 arbitrary graph topology) and can communicate with each other via V2V 431 communication. Vehicle1 can communicate with Vehicle2 via V2V 432 communication, and Vehicle2 can communicate with Vehicle3 via V2V 433 communication because they are within the wireless communication 434 range for each other. On the other hand, Vehicle3 can communicate 435 with Vehicle4 via the vehicular infrastructure (i.e., RSU2 and RSU3) 436 by employing V2I (i.e., V2I2V) communication because they are not 437 within the wireless communication range for each other. 439 In vehicular networks, asymmetric links sometimes exist and must be 440 considered for wireless communications. In vehicular networks, the 441 control plane can be separated from the data plane for efficient 442 mobility management and data forwarding. The mobility information of 443 a GPS receiver mounted in its vehicle (e.g., position, speed, and 444 direction) can be used to accommodate mobility-aware proactive 445 protocols. Vehicles can use the TCC as their Home Network having a 446 home agent for mobility management as in MIPv6 [RFC6275] and PMIPv6 447 [RFC5213], so the TCC maintains the mobility information of vehicles 448 for location management. IP tunneling over the wireless link should 449 be avoided for performance efficiency. 451 +-----------------+ 452 (*)<........>(*) +----->| Vehicular Cloud | 453 2001:DB8:1:1::/64 | | | +-----------------+ 454 +------------------------------+ +---------------------------------+ 455 | v | | v v | 456 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 457 | | Host1 | | DNS1 | |Router1| | | |Router3| | DNS2 | | Host3 | | 458 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 459 | ^ ^ ^ | | ^ ^ ^ | 460 | | | | | | | | | | 461 | v v v | | v v v | 462 | ---------------------------- | | ------------------------------- | 463 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 464 | | | | | | 465 | v | | v | 466 | +-------+ +-------+ | | +-------+ +-------+ +-------+ | 467 | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | 468 | +-------+ +-------+ | | +-------+ +-------+ +-------+ | 469 | ^ ^ | | ^ ^ ^ | 470 | | | | | | | | | 471 | v v | | v v v | 472 | ---------------------------- | | ------------------------------- | 473 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 474 +------------------------------+ +---------------------------------+ 475 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 477 <----> Wired Link <....> Wireless Link (*) Antenna 479 Figure 2: Internetworking between Vehicle Network and RSU Network 481 4.2. V2I-based Internetworking 483 This section discusses the internetworking between a vehicle's 484 internal network (i.e., moving network) and an RSU's internal network 485 (i.e., fixed network) via V2I communication. Note that an RSU can 486 accommodate multiple routers (or switches) and servers (e.g., DNS 487 server and edge computing server) in its internal network as an edge 488 computing system. 490 A vehicle's internal network often uses Ethernet to interconnect 491 control units in the vehicle. The internal network also supports 492 WiFi and Bluetooth to accommodate a driver's and passenger's mobile 493 devices (e.g., smartphone or tablet). It is reasonable to consider 494 the interaction between the internal network and an external network 495 within another vehicle or RSU. 497 As shown in Figure 2, the vehicle's moving network and the RSU's 498 fixed network are self-contained networks having multiple subnets and 499 having an edge router for the communication with another vehicle or 500 RSU. Internetworking between two internal networks via V2I 501 communication requires an exchange of network prefix and other 502 parameters through a prefix discovery mechanism, such as ND-based 503 prefix discovery [ID-Vehicular-ND]. For ND-based prefix discovery, 504 network prefixes and parameters should be registered with a vehicle's 505 router and an RSU router with an external network interface in 506 advance. 508 For an IP communication between a vehicle and an RSU or between two 509 neighboring vehicles, the network parameter discovery collects 510 information relevant to the link layer, MAC layer, and IP layer. The 511 link layer information includes wireless link layer parameters and 512 transmission power level. The MAC layer information includes the MAC 513 address of an external network interface for the internetworking with 514 another vehicle or RSU. The IP layer information includes the IP 515 address and prefix of an external network interface for the 516 internetworking with another vehicle or RSU. 518 Once the network parameter discovery and prefix exchange operations 519 have been performed, packets can be transmitted between the vehicle's 520 moving network and the RSU's fixed network. A DNS service should be 521 supported for the DNS name resolution of in-vehicle devices within a 522 vehicle's internal network as well as for the DNS name resolution of 523 those devices from a remote host in the Internet (e.g., a customer's 524 web browser and an automotive service center system). The DNS names 525 of in-vehicle devices and their service names can be registered with 526 a DNS server in a vehicle or an RSU, as shown in Figure 2. 528 Figure 2 also shows internetworking between the vehicle's moving 529 network and the RSU's fixed network. There exists an internal 530 network (Moving Network1) inside Vehicle1. Vehicle1 has the DNS 531 Server (DNS1), the two hosts (Host1 and Host2), and the two routers 532 (Router1 and Router2). There exists another internal network (Fixed 533 Network1) inside RSU1. RSU1 has the DNS Server (DNS2), one host 534 (Host3), the two routers (Router3 and Router4), and the collection of 535 servers (Server1 to ServerN) for various services in the road 536 networks, such as the emergency notification and navigation. 537 Vehicle1's Router1 (a mobile router) and RSU1's Router3 (a fixed 538 router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for 539 V2I networking. Thus, one host (Host1) in Vehicle1 can communicate 540 with one server (Server1) in RSU1 for a vehicular service through 541 Vehicle1's moving network, a wireless link between Vehicle1 and RSU1, 542 and RSU1's fixed network. 544 (*)<..........>(*) 545 2001:DB8:1:1::/64 | | 546 +------------------------------+ +------------------------------+ 547 | v | | v | 548 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 549 | | Host1 | | DNS1 | |Router1| | | |Router5| | DNS3 | | Host4 | | 550 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 551 | ^ ^ ^ | | ^ ^ ^ | 552 | | | | | | | | | | 553 | v v v | | v v v | 554 | ---------------------------- | | ---------------------------- | 555 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:30:1::/64 | 556 | | | | | | 557 | v | | v | 558 | +-------+ +-------+ | | +-------+ +-------+ | 559 | | Host2 | |Router2| | | |Router6| | Host5 | | 560 | +-------+ +-------+ | | +-------+ +-------+ | 561 | ^ ^ | | ^ ^ | 562 | | | | | | | | 563 | v v | | v v | 564 | ---------------------------- | | ---------------------------- | 565 | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | 566 +------------------------------+ +------------------------------+ 567 Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) 569 <----> Wired Link <....> Wireless Link (*) Antenna 571 Figure 3: Internetworking between Two Vehicle Networks 573 4.3. V2V-based Internetworking 575 This section discusses the internetworking between the moving 576 networks of two neighboring vehicles via V2V communication. 578 Figure 3 shows internetworking between the moving networks of two 579 neighboring vehicles. There exists an internal network (Moving 580 Network1) inside Vehicle1. Vehicle1 has the DNS Server (DNS1), the 581 two hosts (Host1 and Host2), and the two routers (Router1 and 582 Router2). There exists another internal network (Moving Network2) 583 inside Vehicle2. Vehicle2 has the DNS Server (DNS3), the two hosts 584 (Host4 and Host5), and the two routers (Router5 and Router6). 585 Vehicle1's Router1 (a mobile router) and Vehicle2's Router5 (a mobile 586 router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for 587 V2V networking. Thus, one host (Host1) in Vehicle1 can communicate 588 with one host (Host4) in Vehicle1 for a vehicular service through 589 Vehicle1's moving network, a wireless link between Vehicle1 and 590 Vehicle2, and Vehicle2's moving network. 592 (*)<..................>(*)<..................>(*) 593 | | | 594 +-----------+ +-----------+ +-----------+ 595 | | | | | | 596 | +-------+ | | +-------+ | | +-------+ | 597 | |Router1| | | |Router5| | | |Router7| | 598 | +-------+ | | +-------+ | | +-------+ | 599 | | | | | | 600 | +-------+ | | +-------+ | | +-------+ | 601 | | Host1 | | | | Host4 | | | | Host6 | | 602 | +-------+ | | +-------+ | | +-------+ | 603 | | | | | | 604 +-----------+ +-----------+ +-----------+ 605 Vehicle1 Vehicle2 Vehicle3 607 <....> Wireless Link (*) Antenna 609 Figure 4: Multihop Internetworking between Two Vehicle Networks 611 Figure 4 shows multihop internetworking between the moving networks 612 of two vehicles in the same VANET. For example, Host1 in Vehicle1 613 can communicate with Host6 in Vehicle3 via Router 5 in Vehicle2 that 614 is an intermediate vehicle being connected to Vehicle1 and Vehicle3 615 in a linear topology as shown in the figure. 617 5. Problem Statement 619 In order to specify protocols using the abovementioned architecture 620 for VANETs, IPv6 core protocols have to be adapted to overcome 621 certain challenging aspects of vehicular networking. Since the 622 vehicles are likely to be moving at great speed, protocol exchanges 623 need to be completed in a time relatively small compared to the 624 lifetime of a link between a vehicle and an RSU, or between two 625 vehicles. This has a major impact on IPv6 neighbor discovery. 626 Mobility management is also vulnerable to disconnections that occur 627 before the completion of identity verification and tunnel management. 628 This is especially true given the unreliable nature of wireless 629 communications. Finally, and perhaps most importantly, proper 630 authorization for vehicular protocol messages must be assured in 631 order to prevent false reports of accidents or other mishaps on the 632 road, which would cause horrific misery in modern urban environments. 633 This section presents key topics such as neighbor discovery and 634 mobility management. 636 5.1. Neighbor Discovery 638 IPv6 Neighbor Discovery (IPv6 ND) [RFC4861][RFC4862] is a core part 639 of the IPv6 protocol suite. IPv6 ND is designed for point-to-point 640 links and transit links (e.g., Ethernet). It assumes an efficient 641 and reliable support of multicast from the link layer for various 642 network operations such as MAC Address Resolution (AR) and Duplicate 643 Address Detection (DAD). 645 DAD and ND-related parameters (e.g., Router Lifetime) need to be 646 extended to vehicular networking (e.g., V2V, V2I, and V2X). Vehicles 647 move quickly within the communication coverage of any particular 648 vehicle or RSU. Before the vehicles can exchange application 649 messages with each other, they need to be configured with a link- 650 local IPv6 address or a global IPv6 address, and run IPv6 ND. 652 The legacy DAD assumes that a node with an IPv6 address can reach any 653 other node with the scope of its address at the time it claims its 654 address, and can hear any future claim for that address by another 655 party within the scope of its address for the duration of the address 656 ownership. However, the partitioning and merging of VANETs makes 657 this assumption frequently invalid in vehicular networks. The 658 merging and partitioning of VANETs occurs frequently in vehicular 659 networks. This merging and partitioning should be considered for the 660 IPv6 Neighbor Discovery (e.g., SLAAC). Due to the merging of VANETs, 661 two IPv6 addresses may conflict with each other though they were 662 unique before the merging. Also, the partitioning of a VANET may 663 make vehicles with the same prefix be physically unreachable. Also, 664 SLAAC should be extended to prevent IPv6 address duplication due to 665 the merging of VANETs. According to the merging and partitioning, a 666 destination vehicle (as an IP host) should be distinguished as either 667 an on-link host or off-link host even though the source vehicle uses 668 the same prefix with the destination vehicle. 670 The vehicular networks need to support a vehicular-network-wide DAD 671 by defining a scope that is compatible with the legacy DAD, and two 672 vehicles can communicate with each other when there exists a 673 communication path over VANET or a combination of VANETs and RSUs, as 674 shown in Figure 1. By using the vehicular-network-wide DAD, vehicles 675 can assure that their IPv6 addresses are unique in the vehicular 676 network whenever they are connected to the vehicular infrastructure 677 or become disconnected from it in the form of VANET. A vehicular 678 infrastructure having RSUs and an MA can participate in the 679 vehicular-network-wide DAD for the sake of vehicles [RFC6775]. For 680 the vehicle as an IPv6 node, deriving a unique IPv6 address from a 681 globally unique MAC address creates a privacy issue. Refer to 682 Section 6 for the discussion about such a privacy issue. 684 ND time-related parameters such as router lifetime and Neighbor 685 Advertisement (NA) interval should be adjusted for high-speed 686 vehicles and vehicle density. As vehicles move faster, the NA 687 interval should decrease (e.g., from 1 sec to 0.5 sec) for the NA 688 messages to reach the neighboring vehicles promptly. Also, as 689 vehicle density is higher, the NA interval should increase (e.g., 690 from 0.5 sec to 1 sec) for the NA messages to reduce collision 691 probability with other NA messages. 693 According to a report from the National Highway Traffic Safety 694 Administration (NHTSA) [NHTSA-ACAS-Report], an extra 0.5 second of 695 warning time can prevent about 60% of the collisions of vehicles 696 moving closely in a roadway. A warning message should be exchanged 697 every 0.5 second. Thus, if the ND messages (e.g., NS and NA) are 698 used as warning messages, they should be exchanged every 0.5 second. 700 For IP-based safety applications (e.g., context-aware navigation, 701 adaptive cruise control, and platooning) in vehicular network, this 702 bounded data delivery is critical. Implementations for such 703 applications are not available yet. ND needs work to support IP- 704 based safety applications. 706 5.1.1. Link Model 708 IPv6 protocols work under certain assumptions for the link model that 709 do not necessarily hold in a vehicular wireless link [VIP-WAVE] 710 [RFC5889]. For instance, some IPv6 protocols assume symmetry in the 711 connectivity among neighboring interfaces [RFC6250]. However, 712 interference and different levels of transmission power may cause 713 asymmetric links to appear in vehicular wireless links. As a result, 714 a new vehicular link model should consider the asymmetry of 715 dynamically changing vehicular wireless links. 717 There is a relationship between a link and a prefix, besides the 718 different scopes that are expected from the link-local and global 719 types of IPv6 addresses. In an IPv6 link, it is assumed that all 720 interfaces which are configured with the same subnet prefix and with 721 on-link bit set can communicate with each other on an IP link. 722 However, the vehicular link model needs to define the relationship 723 between a link and a prefix, considering the dynamics of wireless 724 links and the characteristics of VANET. 726 A VANET can have multiple links between pairs of vehicles within 727 wireless communication range, as shown in Figure 4. When two 728 vehicles belong to the same VANET, but they are out of wireless 729 communication range, they cannot communicate directly with each 730 other. Suppose that a global-scope IPv6 prefix is assigned to VANETs 731 in vehicular networks. Even though two vehicles in the same VANET 732 configure their IPv6 addresses with the same IPv6 prefix, they may 733 not communicate with each other not in a one hop in the same VANET 734 because of the multihop network connectivity. Thus, in this case, 735 the concept of an on-link IPv6 prefix does not hold because two 736 vehicles with the same on-link IPv6 prefix cannot communicate 737 directly with each other. Also, when two vehicles are located in two 738 different VANETs with the same IPv6 prefix, they cannot communicate 739 with each other. When these two VANETs converge to one VANET, the 740 two vehicles can communicate with each other in a multihop fashion. 742 From the previous observation, a vehicular link model should consider 743 the frequent partitioning and merging of VANETs due to vehicle 744 mobility. Therefore, the vehicular link model needs to use an on- 745 link prefix and off-link prefix according to the one-hop reachability 746 among the vehicles in an appropriate way. If the vehicles with the 747 same prefix are reachable with each other in one hop, the prefix 748 should be on-link. On the other hand, if some of the vehicles with 749 the same prefix are not reachable with each other in one hop due to 750 either the multi-hop topology in the VANET or multiple partitions, 751 the prefix should be off-link. 753 The vehicular link model needs to support the multihop routing in a 754 connected VANET where the vehicles with the same global-scope IPv6 755 prefix are connected in one hop or multiple hops. It also needs to 756 support the multihop routing in multiple connected VANETs via an RSU 757 that has the wireless connectivity with each VANET. For example, in 758 Figure 1, suppose that Vehicle1, Vehicle2, and Vehicle3 are 759 configured with their IPv6 addresses based on the same global-scope 760 IPv6 prefix. Vehicle1 and Vehicle3 can also communicate with each 761 other via either multi-hop V2V or multi-hop V2I2V. When two vehicles 762 of Vehicle1 and Vehicle3 are connected in a VANET, it will be more 763 efficient for them to communicate with each other via VANET rather 764 than RSUs. On the other hand, when the two vehicles of Vehicle1 and 765 Vehicle3 are far away from the communication range in separate VANETs 766 and under two different RSUs, they can communicate with each other 767 through the relay of RSUs via V2I2V. Thus, two separate VANETs can 768 merge into one network via RSU(s). Also, newly arriving vehicles can 769 merge two separate VANETs into one VANET if they can play a role of a 770 relay node for those VANETs. 772 5.1.2. MAC Address Pseudonym 774 For the protection of drivers' privacy, a pseudonym of a MAC address 775 of a vehicle's network interface should be used, so that the MAC 776 address can be changed periodically. However, although such a 777 pseudonym of a MAC address can protect some extent of privacy of a 778 vehicle, it may not be able to resist attacks on vehicle 779 identification by other fingerprint information, for example, the 780 scrambler seed embedded in IEEE 802.11-OCB frames [Scrambler-Attack]. 781 The pseudonym of a MAC address affects an IPv6 address based on the 782 MAC address, and a transport-layer (e.g., TCP) session with an IPv6 783 address pair. However, the pseudonym handling is not implemented and 784 tested yet for applications on IP-based vehicular networking. 786 In the ETSI standards, for the sake of security and privacy, an ITS 787 station (e.g., vehicle) can use pseudonyms for its network interface 788 identities (e.g., MAC address) and the corresponding IPv6 addresses 789 [Identity-Management]. Whenever the network interface identifier 790 changes, the IPv6 address based on the network interface identifier 791 should be updated, and the uniqueness of the address should be 792 performed through the DAD procedure. For vehicular networks with 793 high mobility and density, this DAD should be performed efficiently 794 with minimum overhead so that the vehicles can exchange warning 795 messages with each other every 0.5 second [NHTSA-ACAS-Report]. 797 For the continuity of an end-to-end (E2E) transport-layer (e.g., TCP, 798 UDP, and SCTP) session, with a mobility management scheme (e.g., 799 MIPv6 and PMIPv6), the new IP address for the transport-layer session 800 can be notified to an appropriate end point, and the packets of the 801 session should be forwarded to their destinations with the changed 802 network interface identifier and IPv6 address. This mobility 803 management overhead for pseudonyms should be minimized for efficient 804 operations in vehicular networks having lots of vehicles. 806 5.1.3. Routing 808 For multihop V2V communications in either a VANET or VANETs via RSUs, 809 a vehicular ad hoc routing protocol (e.g., AODV and OLSRv2) may be 810 required to support both unicast and multicast in the links of the 811 subnet with the same IPv6 prefix. However, it will be costly to run 812 both vehicular ND and a vehicular ad hoc routing protocol in terms of 813 control traffic overhead [ID-Multicast-Problems]. 815 The merging of the IPv6 Neighbor Discovery and a VANET routing 816 protocol allows the efficient wireless channel utilization. A 817 routing protocol for VANET may cause redundant wireless frames in the 818 air to check the neighborhood of each vehicle and compute the routing 819 information in VANET with a dynamic network topology if the IPv6 ND 820 is used to check the neighborhood of each vehicle, and can be 821 extended to compute each vehicle's routing table in VANET. 823 Vehicular ND can be extended to accommodate routing functionality 824 with a prefix discovery option. The ND extension can allow vehicles 825 to exchange their prefixes in a multihop fashion [ID-Vehicular-ND]. 826 With the exchanged prefixes, they can compute their routing table (or 827 IPv6 ND's neighbor cache) for the VANETs with a distance-vector 828 algorithm [Intro-to-Algorithms]. 830 5.2. Mobility Management 832 The seamless connectivity and timely data exchange between two end 833 points requires an efficient mobility management including location 834 management and handover. Most of vehicles are equipped with a GPS 835 receiver as part of a dedicated navigation system or a corresponding 836 smartphone App. The GPS receiver may not provide vehicles with 837 accurate location information in adverse, local environments such as 838 building area and tunnel. The location precision can be improved by 839 the assistance from the RSUs or a cellular system with a GPS receiver 840 for location information. 842 With a GPS navigator, an efficient mobility management will be 843 possible by vehicles periodically reporting their current position 844 and trajectory (i.e., navigation path) to the vehicular 845 infrastructure (having RSUs and an MA in TCC) [ID-Vehicular-MM]. 846 This vehicular infrastructure can predict the future positions of the 847 vehicles with their mobility information (i.e., the current position, 848 speed, direction, and trajectory) for the efficient mobility 849 management (e.g., proactive handover). For a better proactive 850 handover, link-layer parameters, such as the signal strength of a 851 link-layer frame (e.g., Received Channel Power Indicator (RCPI) 852 [VIP-WAVE]), can be used to determine the moment of a handover 853 between RSUs along with mobility information. 855 By predicting a vehicle's mobility, the vehicular infrastructure can 856 better support RSUs to perform efficient DAD, data packet routing, 857 horizontal handover (i.e., handover in wireless links using a 858 homogeneous radio technology), and vertical handover (i.e., handover 859 in wireless links using heterogeneous radio technologies) in advance 860 along with the movement of the vehicle [ID-Vehicular-MM]. For 861 example, when a vehicle is moving into the wireless link under 862 another RSU belonging to a different subnet, the RSU can proactively 863 perform the DAD for the sake of the vehicle, reducing IPv6 control 864 traffic overhead in the wireless link. To prevent a hacker from 865 impersonating RSUs as bogus RSUs, RSUs and MA in the vehicular 866 infrastructure need to have secure channels via IPsec. 868 Therefore, with a proactive handover and a multihop DAD in vehicular 869 networks, RSUs needs to efficiently forward data packets from the 870 wired network (or the wireless network) to a moving destination 871 vehicle along its trajectory. 873 6. Security Considerations 875 This section discusses security and privacy for IP-based vehicular 876 networking. The security and privacy are one of key components in 877 IP-based vehicular networking, such as neighbor discovery and 878 mobility management, so they need to be analyzed in depth. 880 Strong security measures shall protect vehicles roaming in road 881 networks from the attacks of malicious nodes, which are controlled by 882 hackers. For safety applications, the cooperation among vehicles is 883 assumed. Malicious nodes may disseminate wrong driving information 884 (e.g., location, speed, and direction) to make driving be unsafe. 885 Sybil attack, which tries to confuse a vehicle with multiple false 886 identities, disturbs a vehicle in taking a safe maneuver. This sybil 887 attack should be prevented through the cooperation between good 888 vehicles and RSUs. Note that good vehicles are ones with valid 889 certificates that are determined by the authentication process with 890 an authentication server in the vehicular network. Applications on 891 IP-based vehicular networking, which are resilient to such a sybil 892 attack, are not developed and tested yet. 894 Security and privacy are paramount in the V2I, V2V, and V2X 895 networking in vehicular networks. Only authorized vehicles should be 896 allowed to use vehicular networking. Also, in-vehicle devices and 897 mobile devices in a vehicle need to communicate with other in-vehicle 898 devices and mobile devices in another vehicle, and other servers in 899 an RSU in a secure way. Even a perfectly authorized and legitimate 900 vehicle may be hacked to run malicious applications to track and 901 collect other vehicles' information. For this case, an attack 902 mitigation process may be required to reduce the aftermath of the 903 malicious behaviors. 905 A Vehicle Identification Number (VIN) and a user certificate along 906 with in-vehicle device's identifier generation can be used to 907 efficiently authenticate a vehicle or a user through a road 908 infrastructure node (e.g., RSU) connected to an authentication server 909 in TCC. Also, Transport Layer Security (TLS) certificates can be 910 used for secure E2E vehicle communications. 912 For secure V2I communication, a secure channel between a mobile 913 router in a vehicle and a fixed router in an RSU should be 914 established, as shown in Figure 2. Also, for secure V2V 915 communication, a secure channel between a mobile router in a vehicle 916 and a mobile router in another vehicle should be established, as 917 shown in Figure 3. 919 To prevent an adversary from tracking a vehicle with its MAC address 920 or IPv6 address, MAC address pseudonym should be provided to the 921 vehicle; that is, each vehicle should periodically update its MAC 922 address and the corresponding IPv6 address as suggested in 923 [RFC4086][RFC4941]. Such an update of the MAC and IPv6 addresses 924 should not interrupt the E2E communications between two vehicles (or 925 between a vehicle and an RSU) in terms of transport layer for a long- 926 living higher-layer session. However, if this pseudonym is performed 927 without strong E2E confidentiality, there will be no privacy benefit 928 from changing MAC and IP addresses, because an adversary can see the 929 change of the MAC and IP addresses and track the vehicle with those 930 addresses. 932 For the IPv6 ND, the vehicular-network-wide DAD is required for the 933 uniqueness of the IPv6 address of a vehicle's wireless interface. 934 This DAD can be used as a flooding attack that makes the DAD-related 935 ND packets are disseminated over the VANET and vehicular network 936 including the RSUs and the MA. The vehicles and RSUs need to filter 937 out suspicious ND traffic in advance. 939 For the mobility management, a malicious vehicle can construct 940 multiple virtual bogus vehicles, and register them with the RSU and 941 the MA. This registration makes the RSU and MA waste their 942 resources. The RSU and MA need to determine whether a vehicle is 943 genuine or bogus in the mobility management. 945 7. Informative References 947 [Automotive-Sensing] 948 Choi, J., Va, V., Gonzalez-Prelcic, N., Daniels, R., R. 949 Bhat, C., and R. W. Heath, "Millimeter-Wave Vehicular 950 Communication to Support Massive Automotive Sensing", 951 IEEE Communications Magazine, December 2016. 953 [CA-Cruise-Control] 954 California Partners for Advanced Transportation Technology 955 (PATH), "Cooperative Adaptive Cruise Control", [Online] 956 Available: 957 http://www.path.berkeley.edu/research/automated-and- 958 connected-vehicles/cooperative-adaptive-cruise-control, 959 2017. 961 [CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A 962 Framework of Context-Awareness Safety Driving in Vehicular 963 Networks", International Workshop on Device Centric Cloud 964 (DC2), March 2016. 966 [DSRC] ASTM International, "Standard Specification for 967 Telecommunications and Information Exchange Between 968 Roadside and Vehicle Systems - 5 GHz Band Dedicated Short 969 Range Communications (DSRC) Medium Access Control (MAC) 970 and Physical Layer (PHY) Specifications", 971 ASTM E2213-03(2010), October 2010. 973 [EU-2008-671-EC] 974 European Union, "Commission Decision of 5 August 2008 on 975 the Harmonised Use of Radio Spectrum in the 5875 - 5905 976 MHz Frequency Band for Safety-related Applications of 977 Intelligent Transport Systems (ITS)", EU 2008/671/EC, 978 August 2008. 980 [FirstNet] 981 U.S. National Telecommunications and Information 982 Administration (NTIA), "First Responder Network Authority 983 (FirstNet)", [Online] 984 Available: https://www.firstnet.gov/, 2012. 986 [FirstNet-Report] 987 First Responder Network Authority, "FY 2017: ANNUAL REPORT 988 TO CONGRESS, Advancing Public Safety Broadband 989 Communications", FirstNet FY 2017, December 2017. 991 [Fuel-Efficient] 992 van de Hoef, S., H. Johansson, K., and D. V. Dimarogonas, 993 "Fuel-Efficient En Route Formation of Truck Platoons", 994 IEEE Transactions on Intelligent Transportation Systems, 995 January 2018. 997 [ID-Multicast-Problems] 998 Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC. 999 Zuniga, "Multicast Considerations over IEEE 802 Wireless 1000 Media", draft-ietf-mboned-ieee802-mcast-problems-06 (work 1001 in progress), July 2019. 1003 [ID-Vehicular-MM] 1004 Jeong, J., Ed., Shen, Y., and Z. Xiang, "Vehicular 1005 Mobility Management for IP-Based Vehicular Networks", 1006 draft-jeong-ipwave-vehicular-mobility-management-01 (work 1007 in progress), July 2019. 1009 [ID-Vehicular-ND] 1010 Jeong, J., Ed., Shen, Y., and Z. Xiang, "Vehicular 1011 Neighbor Discovery for IP-Based Vehicular Networks", 1012 draft-jeong-ipwave-vehicular-neighbor-discovery-07 (work 1013 in progress), July 2019. 1015 [Identity-Management] 1016 Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer 1017 Identities Management in ITS Stations", The 10th 1018 International Conference on ITS Telecommunications, 1019 November 2010. 1021 [IEEE-802.11-OCB] 1022 "Part 11: Wireless LAN Medium Access Control (MAC) and 1023 Physical Layer (PHY) Specifications", IEEE Std 1024 802.11-2016, December 2016. 1026 [IEEE-802.11p] 1027 "Part 11: Wireless LAN Medium Access Control (MAC) and 1028 Physical Layer (PHY) Specifications - Amendment 6: 1029 Wireless Access in Vehicular Environments", IEEE Std 1030 802.11p-2010, June 2010. 1032 [Intro-to-Algorithms] 1033 H. Cormen, T., E. Leiserson, C., L. Rivest, R., and C. 1034 Stein, "Introduction to Algorithms, 3rd ed.", The 1035 MIT Press, July 2009. 1037 [IPv6-over-802.11-OCB] 1038 Benamar, N., Haerri, J., Lee, J., and T. Ernst, "Basic 1039 Support for IPv6 over IEEE Std 802.11 Networks Operating 1040 Outside the Context of a Basic Service Set (IPv6-over- 1041 80211-OCB)", draft-ietf-ipwave-ipv6-over-80211ocb-49 (work 1042 in progress), July 2019. 1044 [ISO-ITS-IPv6] 1045 ISO/TC 204, "Intelligent Transport Systems - 1046 Communications Access for Land Mobiles (CALM) - IPv6 1047 Networking", ISO 21210:2012, June 2012. 1049 [NHTSA-ACAS-Report] 1050 National Highway Traffic Safety Administration (NHTSA), 1051 "Final Report of Automotive Collision Avoidance Systems 1052 (ACAS) Program", DOT HS 809 080, August 2000. 1054 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 1055 Demand Distance Vector (AODV) Routing", RFC 3561, July 1056 2003. 1058 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 1059 Reserved for Documentation", RFC 3849, July 2004. 1061 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1062 "Randomness Requirements for Security", RFC 4086, June 1063 2005. 1065 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1066 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 1067 September 2007. 1069 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1070 Address Autoconfiguration", RFC 4862, September 2007. 1072 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1073 Extensions for Stateless Address Autoconfiguration in 1074 IPv6", RFC 4941, September 2007. 1076 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1077 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1078 RFC 5213, August 2008. 1080 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1081 Mobile IPv6", RFC 5844, May 2010. 1083 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 1084 Hoc Networks", RFC 5889, September 2010. 1086 [RFC5944] Perkins, C., Ed., "IP Mobility Support in IPv4, Revised", 1087 RFC 5944, November 2010. 1089 [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, May 1090 2011. 1092 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1093 Support in IPv6", RFC 6275, July 2011. 1095 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1096 "Neighbor Discovery Optimization for IPv6 over Low-Power 1097 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1098 November 2012. 1100 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 1101 "The Optimized Link State Routing Protocol Version 2", 1102 RFC 7181, April 2014. 1104 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1105 (IPv6) Specification", RFC 8200, July 2017. 1107 [SAINT] Jeong, J., Jeong, H., Lee, E., Oh, T., and D. Du, "SAINT: 1108 Self-Adaptive Interactive Navigation Tool for Cloud-Based 1109 Vehicular Traffic Optimization", IEEE Transactions on 1110 Vehicular Technology, Vol. 65, No. 6, June 2016. 1112 [SAINTplus] 1113 Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D. 1114 Du, "SAINT+: Self-Adaptive Interactive Navigation Tool+ 1115 for Emergency Service Delivery Optimization", 1116 IEEE Transactions on Intelligent Transportation Systems, 1117 June 2017. 1119 [SANA] Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation 1120 Application for Pedestrian Protection in Vehicular 1121 Networks", Springer Lecture Notes in Computer Science 1122 (LNCS), Vol. 9502, December 2015. 1124 [Scrambler-Attack] 1125 Bloessl, B., Sommer, C., Dressier, F., and D. Eckhoff, 1126 "The Scrambler Attack: A Robust Physical Layer Attack on 1127 Location Privacy in Vehicular Networks", IEEE 2015 1128 International Conference on Computing, Networking and 1129 Communications (ICNC), February 2015. 1131 [Timing-Attack] 1132 Matte, C., Cunche, M., Rousseau, F., and M. Vanhoef, 1133 "Defeating MAC Address Randomization Through Timing 1134 Attacks", ACM the 9th ACM Conference on Security & Privacy 1135 in Wireless and Mobile Networks (WiSec '16), July 2016. 1137 [Truck-Platooning] 1138 California Partners for Advanced Transportation Technology 1139 (PATH), "Automated Truck Platooning", [Online] Available: 1140 http://www.path.berkeley.edu/research/automated-and- 1141 connected-vehicles/truck-platooning, 2017. 1143 [TS-23.285-3GPP] 1144 3GPP, "Architecture Enhancements for V2X Services", 3GPP 1145 TS 23.285, June 2018. 1147 [VIP-WAVE] 1148 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 1149 Feasibility of IP Communications in 802.11p Vehicular 1150 Networks", IEEE Transactions on Intelligent Transportation 1151 Systems, vol. 14, no. 1, March 2013. 1153 [WAVE-1609.0] 1154 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 1155 in Vehicular Environments (WAVE) - Architecture", IEEE Std 1156 1609.0-2013, March 2014. 1158 [WAVE-1609.2] 1159 IEEE 1609 Working Group, "IEEE Standard for Wireless 1160 Access in Vehicular Environments - Security Services for 1161 Applications and Management Messages", IEEE Std 1162 1609.2-2016, March 2016. 1164 [WAVE-1609.3] 1165 IEEE 1609 Working Group, "IEEE Standard for Wireless 1166 Access in Vehicular Environments (WAVE) - Networking 1167 Services", IEEE Std 1609.3-2016, April 2016. 1169 [WAVE-1609.4] 1170 IEEE 1609 Working Group, "IEEE Standard for Wireless 1171 Access in Vehicular Environments (WAVE) - Multi-Channel 1172 Operation", IEEE Std 1609.4-2016, March 2016. 1174 Appendix A. Changes from draft-ietf-ipwave-vehicular-networking-11 1176 The following changes are made from draft-ietf-ipwave-vehicular- 1177 networking-11: 1179 o This version is revised based on the comments from Charlie Perkins 1180 and Sandra Cespedes. 1182 o In Section 5, the problem statement is revisd with easily 1183 identifiable problems. 1185 o In Section 1, the description of GeoNetworking (GN) protocols 1186 (i.e., geographic routing) is removed because the GN protocols are 1187 not relevant to the IPWAVE's use cases. 1189 o In Section 2, the terms of OCB, Context-Awareness, Platooning, and 1190 Class-Based Safety Plan are clarified. 1192 o In Section 2, the definition of an RSU is revised so that it can 1193 accommodate multiple routers (or switches) and servers (including 1194 DNS server and edge computing server) as an edge computing system 1195 because the RSU is regularly a router or switch. 1197 o In Section 4.1, a general vehicular network architecture is 1198 proposed for the problem statement along with Figure 1. This 1199 figure clarifies that a single subnet prefix can span multiple 1200 vehicles that construct a subnet. Also, some components in the 1201 vehicular network architecture may not be needed such as Vehicular 1202 Cloud, Traffic Control Center, and Mobility Anchor. 1204 o In Section 5.1.1, the motivation of a new link model as a 1205 vehicular link model is added. The "on-link" and "off-link" for 1206 prefixes are classified according to the subnet topology of VANET. 1208 o In Section 5.1.1, the merging and partitioning of VANETs is 1209 described, and the requirements of the IPv6 ND are addressed for 1210 the merging and partitioning as a problem statement. 1212 o In Section 5.1.2, a citation of [Scrambler-Attack], which uses the 1213 scrambler seed in the IEEE 802.11-OCB frames as fingerprint 1214 information, is added to show the insufficiency of the MAC address 1215 pseudonym for privacy. 1217 o In Section 5.1, the subsection of Prefix Dissemination/Exchange is 1218 removed because the Prefix Dissemination/Exchange subsection 1219 discusses a solution rather than a problem or requirement. 1221 o In Section 5.1.3, the motivation of merging the IPv6 ND and a 1222 VANET routing protocol is explained to improve wireless channel 1223 utilization by removing redundant neighbor information exchange. 1225 o The text of the problems and requirements of security and privacy 1226 in vehicular networks are moved to Section 6. 1228 o In Section 6, the compromise of a perfectly authorized and 1229 legitimate vehicle is described as a security problem to be 1230 considered. 1232 o In Section 3.3, the description of Vehicle-to-Pedestrian (V2P) is 1233 concised to deliver the clear concept of the direct communication 1234 between a vehicle and a pedestrian. 1236 Appendix B. Acknowledgments 1238 This work was supported by Basic Science Research Program through the 1239 National Research Foundation of Korea (NRF) funded by the Ministry of 1240 Education (2017R1D1A1B03035885). 1242 This work was supported in part by the MSIT (Ministry of Science and 1243 ICT), Korea, under the ITRC (Information Technology Research Center) 1244 support program (IITP-2019-2017-0-01633) supervised by the IITP 1245 (Institute for Information & communications Technology Promotion). 1247 This work was supported in part by the French research project 1248 DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded 1249 by the European Commission I (636537-H2020). 1251 Appendix C. Contributors 1253 This document is a group work of IPWAVE working group, greatly 1254 benefiting from inputs and texts by Rex Buddenberg (Naval 1255 Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest 1256 University of Technology and Economics), Jose Santa Lozanoi 1257 (Universidad of Murcia), Richard Roy (MIT), Francois Simon (Pilot), 1258 Sri Gundavelli (Cisco), Erik Nordmark, Dirk von Hugo (Deutsche 1259 Telekom), and Pascal Thubert (Cisco). The authors sincerely 1260 appreciate their contributions. 1262 The following are co-authors of this document: 1264 Nabil Benamar 1265 Department of Computer Sciences 1266 High School of Technology of Meknes 1267 Moulay Ismail University 1268 Morocco 1269 Phone: +212 6 70 83 22 36 1270 EMail: benamar73@gmail.com 1272 Sandra Cespedes 1273 NIC Chile Research Labs 1274 Universidad de Chile 1275 Av. Blanco Encalada 1975 1276 Santiago 1277 Chile 1279 Phone: +56 2 29784093 1280 EMail: scespede@niclabs.cl 1282 Jerome Haerri 1283 Communication Systems Department 1284 EURECOM 1285 Sophia-Antipolis 1286 France 1288 Phone: +33 4 93 00 81 34 1289 EMail: jerome.haerri@eurecom.fr 1291 Dapeng Liu 1292 Alibaba 1293 Beijing, Beijing 100022 1294 China 1296 Phone: +86 13911788933 1297 EMail: max.ldp@alibaba-inc.com 1299 Tae (Tom) Oh 1300 Department of Information Sciences and Technologies 1301 Rochester Institute of Technology 1302 One Lomb Memorial Drive 1303 Rochester, NY 14623-5603 1304 USA 1306 Phone: +1 585 475 7642 1307 EMail: Tom.Oh@rit.edu 1309 Charles E. Perkins 1310 Futurewei Inc. 1312 2330 Central Expressway 1313 Santa Clara, CA 95050 1314 USA 1316 Phone: +1 408 330 4586 1317 EMail: charliep@computer.org 1319 Alexandre Petrescu 1320 CEA, LIST 1321 CEA Saclay 1322 Gif-sur-Yvette, Ile-de-France 91190 1323 France 1325 Phone: +33169089223 1326 EMail: Alexandre.Petrescu@cea.fr 1328 Yiwen Chris Shen 1329 Department of Computer Science & Engineering 1330 Sungkyunkwan University 1331 2066 Seobu-Ro, Jangan-Gu 1332 Suwon, Gyeonggi-Do 16419 1333 Republic of Korea 1335 Phone: +82 31 299 4106 1336 Fax: +82 31 290 7996 1337 EMail: chrisshen@skku.edu 1338 URI: http://iotlab.skku.edu/people-chris-shen.php 1340 Michelle Wetterwald 1341 FBConsulting 1342 21, Route de Luxembourg 1343 Wasserbillig, Luxembourg L-6633 1344 Luxembourg 1346 EMail: Michelle.Wetterwald@gmail.com 1348 Author's Address 1349 Jaehoon Paul Jeong (editor) 1350 Department of Computer Science and Engineering 1351 Sungkyunkwan University 1352 2066 Seobu-Ro, Jangan-Gu 1353 Suwon, Gyeonggi-Do 16419 1354 Republic of Korea 1356 Phone: +82 31 299 4957 1357 Fax: +82 31 290 7996 1358 EMail: pauljeong@skku.edu 1359 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php