idnits 2.17.1 draft-ietf-ipwave-vehicular-networking-09.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 (May 24, 2019) is 1799 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Online' is mentioned on line 1079, but not defined == Outdated reference: A later version (-11) exists of draft-jeong-ipwave-vehicular-mobility-management-00 == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-vehicular-neighbor-discovery-06 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPWAVE Working Group J. Jeong, Ed. 3 Internet-Draft Sungkyunkwan University 4 Intended status: Informational May 24, 2019 5 Expires: November 25, 2019 7 IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement 8 and Use Cases 9 draft-ietf-ipwave-vehicular-networking-09 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 November 25, 2019. 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 . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 8 67 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 9 68 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 11 69 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 13 70 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 13 71 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 14 72 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 16 73 5.1.3. Prefix Dissemination/Exchange . . . . . . . . . . . . 16 74 5.1.4. Routing . . . . . . . . . . . . . . . . . . . . . . . 17 75 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 17 76 5.3. Security and Privacy . . . . . . . . . . . . . . . . . . 18 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 78 7. Informative References . . . . . . . . . . . . . . . . . . . 19 79 Appendix A. Changes from draft-ietf-ipwave-vehicular- 80 networking-08 . . . . . . . . . . . . . . . . . . . 25 81 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 25 82 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 25 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 85 1. Introduction 87 Vehicular networking studies have mainly focused on improving safety 88 and efficiency, and also enabling entertainment in vehicular 89 networks. The Federal Communications Commission (FCC) in the US 90 allocated wireless channels for Dedicated Short-Range Communications 91 (DSRC) [DSRC] in the Intelligent Transportation Systems (ITS) with 92 the frequency band of 5.850 - 5.925 GHz (i.e., 5.9 GHz band). DSRC- 93 based wireless communications can support vehicle-to-vehicle (V2V), 94 vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) 95 networking. Also, the European Union (EU) passed a decision to 96 allocate a radio spectrum for safety-related and non-safety-related 97 applications of ITS with the frequency band of 5.875 - 5.905 GHz, 98 which is called Commission Decision 2008/671/EC [EU-2008-671-EC]. 100 For direct inter-vehicular wireless connectivity, IEEE has amended 101 WiFi standard 802.11 to enable driving safety services based on the 102 DSRC in terms of standards for the Wireless Access in Vehicular 103 Environments (WAVE) system. The Physical Layer (L1) and Data Link 104 Layer (L2) issues are addressed in IEEE 802.11p [IEEE-802.11p] for 105 the PHY and MAC of the DSRC, while IEEE 1609.2 [WAVE-1609.2] covers 106 security aspects, IEEE 1609.3 [WAVE-1609.3] defines related services 107 at network and transport layers, and IEEE 1609.4 [WAVE-1609.4] 108 specifies the multi-channel operation. Note that IEEE 802.11p was a 109 separate standard, but was later enrolled into the base 802.11 110 standard (IEEE 802.11-2012) as IEEE 802.11 Outside the Context of a 111 Basic Service Set in 2012 [IEEE-802.11-OCB]. 113 Along with these WAVE standards, IPv6 [RFC8200] and Mobile IP 114 protocols (e.g., MIPv4 [RFC5944], MIPv6 [RFC6275], and Proxy MIPv6 115 (PMIPv6) [RFC5213][RFC5844]) can be applied (or easily modified) to 116 vehicular networks. In Europe, ETSI has standardized a GeoNetworking 117 (GN) protocol [ETSI-GeoNetworking] and a protocol adaptation sub- 118 layer from GeoNetworking to IPv6 [ETSI-GeoNetwork-IP]. Note that a 119 GN protocol is useful to route an event or notification message to 120 vehicles around a geographic position, such as an acciendent area in 121 a roadway. In addition, ISO has approved a standard specifying the 122 IPv6 network protocols and services to be used for Communications 123 Access for Land Mobiles (CALM) [ISO-ITS-IPv6]. 125 This document explains use cases and a problem statement about IP- 126 based vehicular networking for ITS, which is named IP Wireless Access 127 in Vehicular Environments (IPWAVE). First, it introduces the use 128 cases for using V2V, V2I, and V2X networking in the ITS. Next, it 129 makes a problem statement about key aspects in IPWAVE, such as IPv6 130 Neighbor Discovery, Mobility Management, and Security & Privacy. For 131 each key aspect of the problem statement, this document specifies 132 requirements in IP-based vehicular networking, and proposes the 133 direction of solutions fulfilling those requirements. Therefore, 134 with the problem statement, this document will open a door to develop 135 key protocols for IPWAVE that will be essential to IP-based vehicular 136 networks in near future. 138 2. Terminology 140 This document uses the following definitions: 142 o DMM: Acronym for "Distributed Mobility Management" 143 [RFC7333][RFC7429]. 145 o LiDAR: Acronym for "Light Detection and Ranging". It is a 146 scanning device to measure a distance to an object by emitting 147 pulsed laser light and measuring the reflected pulsed light. 149 o Mobility Anchor (MA): A node that maintains IP addresses and 150 mobility information of vehicles in a road network to support 151 their address autoconfiguration and mobility management with a 152 binding table. It has end-to-end connections with RSUs under its 153 control. 155 o On-Board Unit (OBU): A node that has physical communication 156 devices (e.g., IEEE 802.11-OCB and Cellular V2X (C-V2X) 157 [TS-23.285-3GPP]) for wireless communications with other OBUs and 158 RSUs, and may be connected to in-vehicle devices or networks. An 159 OBU is mounted on a vehicle. 161 o OCB: Acronym for "Outside the Context of a Basic Service Set" 162 [IEEE-802.11-OCB]. 164 o Road-Side Unit (RSU): A node that has physical communication 165 devices (e.g., IEEE 802.11-OCB and C-V2X) for wireless 166 communications with vehicles and is also connected to the Internet 167 as a router or switch for packet forwarding. An RSU is typically 168 deployed on the road infrastructure, either at an intersection or 169 in a road segment, but may also be located in car parking area. 171 o Traffic Control Center (TCC): A node that maintains road 172 infrastructure information (e.g., RSUs, traffic signals, and loop 173 detectors), vehicular traffic statistics (e.g., average vehicle 174 speed and vehicle inter-arrival time per road segment), and 175 vehicle information (e.g., a vehicle's identifier, position, 176 direction, speed, and trajectory as a navigation path). TCC is 177 included in a vehicular cloud for vehicular networks. 179 o Vehicle: A node that has an OBU for wireless communication with 180 other vehicles and RSUs. It has a radio navigation receiver of 181 Global Positioning System (GPS) for efficient navigation. 183 o Vehicular Ad Hoc Network (VANET): A network that consists of 184 vehicles interconnected by wireless communication. Since VANET is 185 a connected network component, two vehicles in a VANET can 186 communicate with each other through ad hoc routing via other 187 vehicles as relays even where they are out of one-hop wireless 188 communication range. 190 o Vehicular Cloud: A cloud infrastructure for vehicular networks, 191 having compute nodes, storage nodes, and network nodes. 193 o Vehicle Detection Loop (i.e., Loop Detector): An inductive device 194 used for detecting vehicles passing or arriving at a certain 195 point, for instance, at an intersection with traffic lights or at 196 a ramp toward a highway. The relatively crude nature of the 197 loop's structure means that only metal masses above a certain size 198 are capable of triggering the detection. 200 o V2I2P: Acronym for "Vehicle to Infrastructure to Pedestrian". 202 o V2I2V: Acronym for "Vehicle to Infrastructure to Vehicle". 204 o WAVE: Acronym for "Wireless Access in Vehicular Environments" 205 [WAVE-1609.0]. 207 3. Use Cases 209 This section explains use cases of V2V, V2I, and V2X networking. The 210 use cases of the V2X networking exclude the ones of the V2V and V2I 211 networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to- 212 Device (V2D). 214 3.1. V2V 216 The use cases of V2V networking discussed in this section include 218 o Context-aware navigation for driving safety and collision 219 avoidance; 221 o Cooperative adaptive cruise control in an urban roadway; 223 o Platooning in a highway; 225 o Cooperative environment sensing. 227 These four techniques will be important elements for self-driving 228 vehicles. 230 Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers 231 to drive safely by letting the drivers recognize dangerous obstacles 232 and situations. That is, CASD navigator displays obstables or 233 neighboring vehicles relevant to possible collisions in real-time 234 through V2V networking. CASD provides vehicles with a class-based 235 automatic safety action plan, which considers three situations, such 236 as the Line-of-Sight unsafe, Non-Line-of-Sight unsafe, and safe 237 situations. This action plan can be performed among vehicles through 238 V2V networking. 240 Cooperative Adaptive Cruise Control (CACC) [CA-Cruise-Control] helps 241 vehicles to adapt their speed autonomously through V2V communication 242 among vehicles according to the mobility of their predecessor and 243 successor vehicles in an urban roadway or a highway. Thus, CACC can 244 help adjacent vehicles to efficiently adjust their speed in an 245 interactive way through V2V networking in order to avoid collision. 247 Platooning [Truck-Platooning] allows a series of vehicles (e.g., 248 trucks) to move together with a very short inter-distance. Trucks 249 can use V2V communication in addition to forward sensors in order to 250 maintain constant clearance between two consecutive vehicles at very 251 short gaps (from 3 meters to 10 meters). This platooning can 252 maximize the throughput of vehicular traffic in a highway and reduce 253 the gas consumption because the leading vehicle can help the 254 following vehicles to experience less air resistance. 256 Cooperative-environment-sensing use cases suggest that vehicles can 257 share environmental information from various vehicle-mounted sensors, 258 such as radars, LiDARs, and cameras with other vehicles and 259 pedestrians. [Automotive-Sensing] introduces a millimeter-wave 260 vehicular communication for massive automotive sensing. Data 261 generated by those sensors can be substantially large, and these data 262 shall be routed to different destinations. In addition, from the 263 perspective of driverless vehicles, it is expected that driverless 264 vehicles can be mixed with driver-operated vehicles. Through the 265 cooperative environment sensing, driver-operated vehicles can use 266 environmental information sensed by driverless vehicles for better 267 interaction with the context. 269 3.2. V2I 271 The use cases of V2I networking discussed in this section include 273 o Navigation service; 275 o Energy-efficient speed recommendation service; 277 o Accident notification service. 279 A navigation service, such as the Self-Adaptive Interactive 280 Navigation Tool (called SAINT) [SAINT], using V2I networking 281 interacts with TCC for the large-scale/long-range road traffic 282 optimization and can guide individual vehicles for appropriate 283 navigation paths in real time. The enhanced version of SAINT 284 [SAINTplus] can give the fast moving paths to emergency vehicles 285 (e.g., ambulance and fire engine) to let them reach an accident spot 286 while providing other vehicles near the accident spot with efficient 287 detour paths. 289 A TCC can recommend an energy-efficient speed to a vehicle driving in 290 different traffic environments. [Fuel-Efficient] studies fuel- 291 efficient route and speed plans for platooned trucks. 293 The emergency communication between accident vehicles (or emergency 294 vehicles) and TCC can be performed via either RSU or 4G-LTE networks. 295 The First Responder Network Authority (FirstNet) [FirstNet] is 296 provided by the US government to establish, operate, and maintain an 297 interoperable public safety broadband network for safety and security 298 network services, such as emergency calls. The construction of the 299 nationwide FirstNet network requires each state in the US to have a 300 Radio Access Network (RAN) that will connect to the FirstNet's 301 network core. The current RAN is mainly constructed by 4G-LTE for 302 the communication between a vehicle and an infrastructure node (i.e., 303 V2I) [FirstNet-Report], but it is expected that DSRC-based vehicular 304 networks [DSRC] will be available for V2I and V2V in near future. 306 3.3. V2X 308 The use case of V2X networking discussed in this section is 309 pedestrian protection service. 311 A pedestrian protection service, such as Safety-Aware Navigation 312 Application (called SANA) [SANA], using V2I2P networking can reduce 313 the collision of a vehicle and a pedestrian carrying a smartphone 314 equipped with a network device for wireless communication (e.g., 315 WiFi) with an RSU. Vehicles and pedestrians can also communicate 316 with each other via an RSU that delivers scheduling information for 317 wireless communication in order to save the smartphones' battery 318 through sleeping mode. 320 For Vehicle-to-Pedestrian (V2P), a vehicle and a pedestrian's 321 smartphone can directly communicate with each other via V2X without 322 the relaying of an RSU as in the V2V scenario that the pedestrian's 323 smartphone is regarded as a vehicle with a wireless media interface 324 to be able to communicate with another vehicle. In Vehicle-to-Device 325 (V2D), a device can be a mobile node such as bicycle and motorcycle, 326 and can communicate directly with a vehicle for collision avoidance. 328 4. Vehicular Networks 330 This section describes a vehicular network architecture supporting 331 V2V, V2I, and V2X communications in vehicular networks. Also, it 332 describes an internal network within a vehicle or RSU, and the 333 internetworking between the internal networks via DSRC links. 335 Traffic Control Center in Vehicular Cloud 336 *-----------------------------------------* 337 * * 338 * +----------------+ * 339 * | Mobility Anchor| * 340 * +----------------+ * 341 * ^ * 342 * | * 343 *--------------------v--------------------* 344 ^ ^ ^ 345 | | | 346 | | | 347 v v v 348 +--------+ Ethernet +--------+ +--------+ 349 | RSU1 |<-------->| RSU2 |<---------->| RSU3 | 350 +--------+ +--------+ +--------+ 351 ^ ^ ^ 352 : : : 353 +-----------------+ +-----------------+ +-----------------+ 354 | : V2I | | V2I : | | V2I : | 355 | v | | v | | v | 356 +--------+ | +--------+ | | +--------+ | | +--------+ | 357 |Vehicle1|===> |Vehicle2|===>| | |Vehicle3|===>| | |Vehicle4|===>| 358 | |<...>| |<........>| | | | | | | 359 +--------+ V2V +--------+ V2V +--------+ | | +--------+ | 360 | | | | | | 361 +-----------------+ +-----------------+ +-----------------+ 362 Subnet1 Subnet2 Subnet3 364 <----> Wired Link <....> Wireless Link ===> Moving Direction 366 Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 368 4.1. Vehicular Network Architecture 370 Figure 1 shows an architecture for V2I and V2V networking in a road 371 network. As shown in this figure, RSUs as routers and vehicles with 372 OBU have wireless media interfaces for VANET. Also, it is assumed 373 that such the wireless media interfaces are autoconfigured with a 374 global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to support both V2V and 375 V2I networking. 377 Especially, for IPv6 packets transporting over IEEE 802.11-OCB, 378 [IPv6-over-802.11-OCB] specifies several details, such as Maximum 379 Transmission Unit (MTU), frame format, link-local address, address 380 mapping for unicast and multicast, stateless autoconfiguration, and 381 subnet structure. Especially, an Ethernet Adaptation (EA) layer is 382 in charge of transforming some parameters between IEEE 802.11 MAC 383 layer and IPv6 network layer, which is located between IEEE 384 802.11-OCB's logical link control layer and IPv6 network layer. This 385 IPv6 over 802.11-OCB can be used for both V2V and V2I in IP-based 386 vehicular networks. 388 In Figure 1, three RSUs (RSU1, RSU2, and RSU3) are deployed in the 389 road network and are connected to a Vehicular Cloud through the 390 Internet. A Traffic Control Center (TCC) is connected to the 391 Vehicular Cloud for the management of RSUs and vehicles in the road 392 network. A Mobility Anchor (MA) is located in the TCC as its key 393 component for the mobility management of vehicles. Two vehicles 394 (Vehicle1 and Vehicle2) are wirelessly connected to RSU1, and one 395 vehicle (Vehicle3) is wirelessly connected to RSU2. The wireless 396 networks of RSU1 and RSU2 belong to two different subnets (denoted as 397 Subnet1 and Subnet2), respectively. Also, another vehicle (Vehicle4) 398 is wireless connected to RSU3, belonging to another subnet (denoted 399 as Subnet3). 401 In wireless subnets in vehicular networks (e.g., Subnet1 and Subnet2 402 in Figure 1), vehicles can construct a connected VANET (with an 403 arbitrary graph topology) and can communicate with each other via V2V 404 communication. Vehicle1 can communicate with Vehicle2 via V2V 405 communication, and Vehicle2 can communicate with Vehicle3 via V2V 406 communication because they are within the wireless communication 407 range for each other. On the other hand, Vehicle3 can communicate 408 with Vehicle4 via the vehicular infrastructure (i.e., RSU2 and RSU3) 409 by employing V2I (i.e., V2I2V) communication because they are not 410 within the wireless communication range for each other. 412 In vehicular networks, unidirectional links exist and must be 413 considered for wireless communications. Also, in the vehicular 414 networks, control plane can be separated from data plane for 415 efficient mobility management and data forwarding using Software- 416 Defined Networking (SDN) [SDN-DMM]. The mobility information of a 417 GPS receiver mounted in its vehicle (e.g., trajectory, position, 418 speed, and direction) can be used for the accommodation of mobility- 419 aware proactive protocols. Vehicles can use the TCC as their Home 420 Network having a home agent for mobility management as in MIPv6 421 [RFC6275] and PMIPv6 [RFC5213], so the TCC maintains the mobility 422 information of vehicles for location management. Also, IP tunneling 423 over the wireless link should be avoided for performance efficiency. 425 4.2. V2I-based Internetworking 427 This section discusses the internetworking between a vehicle's 428 internal network (i.e., moving network) and an RSU's internal network 429 (i.e., fixed network) via V2I communication. 431 +-----------------+ 432 (*)<........>(*) +----->| Vehicular Cloud | 433 2001:DB8:1:1::/64 | | | +-----------------+ 434 +------------------------------+ +---------------------------------+ 435 | v | | v v | 436 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 437 | | Host1 | | DNS1 | |Router1| | | |Router3| | DNS2 | | Host3 | | 438 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 439 | ^ ^ ^ | | ^ ^ ^ | 440 | | | | | | | | | | 441 | v v v | | v v v | 442 | ---------------------------- | | ------------------------------- | 443 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 444 | | | | | | 445 | v | | v | 446 | +-------+ +-------+ | | +-------+ +-------+ +-------+ | 447 | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | 448 | +-------+ +-------+ | | +-------+ +-------+ +-------+ | 449 | ^ ^ | | ^ ^ ^ | 450 | | | | | | | | | 451 | v v | | v v v | 452 | ---------------------------- | | ------------------------------- | 453 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 454 +------------------------------+ +---------------------------------+ 455 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 457 <----> Wired Link <....> Wireless Link (*) Antenna 459 Figure 2: Internetworking between Vehicle Network and RSU Network 461 Nowadays, a vehicle's internal network tends to be Ethernet to 462 interconnect electronic control units in a vehicle. It can also 463 support WiFi and Bluetooth to accommodate a driver's and passenger's 464 mobile devices (e.g., smartphone and tablet). In this trend, it is 465 reasonable to consider a vehicle's internal network (i.e., moving 466 network) and also the interaction between the internal network and an 467 external network within another vehicle or RSU. 469 As shown in Figure 2, the vehicle's moving network and the RSU's 470 fixed network are self-contained networks having multiple subnets and 471 having an edge router for the communication with another vehicle or 472 RSU. Internetworking between two internal networks via V2I 473 communication requires an exchange of network prefix and other 474 parameters through a prefix discovery mechanism, such as ND-based 475 prefix discovery [ID-Vehicular-ND]. For the ND-based prefix 476 discovery, network prefixs and parameters should be registered into a 477 vehicle's router and an RSU router with an external network interface 478 in advance. 480 The network parameter discovery collects networking information for 481 an IP communication between a vehicle and an RSU or between two 482 neighboring vehicles, such as link layer, MAC layer, and IP layer 483 information. The link layer information includes wireless link layer 484 parameters, such as wireless media (e.g., IEEE 802.11-OCB and LTE- 485 V2X) and a transmission power level. The MAC layer information 486 includes the MAC address of an external network interface for the 487 internetworking with another vehicle or RSU. The IP layer 488 information includes the IP address and prefix of an external network 489 interface for the internetworking with another vehicle or RSU. 491 Once the network parameter discovery and prefix exchange operations 492 have been performed, packets can be transmitted between the vehicle's 493 moving network and the RSU's fixed network. DNS services should be 494 supported to enable name resolution for hosts or servers residing 495 either in the vehicle's moving network or the RSU's fixed network. 496 It is assumed that the DNS names of in-vehicle devices and their 497 service names are registered into a DNS server in a vehicle or an 498 RSU, as shown in Figure 2. 500 Figure 2 shows internetworking between the vehicle's moving network 501 and the RSU's fixed network. There exists an internal network 502 (Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server 503 (DNS1), the two hosts (Host1 and Host2), and the two routers (Router1 504 and Router2). There exists another internal network (Fixed Network1) 505 inside RSU1. RSU1 has the DNS Server (DNS2), one host (Host3), the 506 two routers (Router3 and Router4), and the collection of servers 507 (Server1 to ServerN) for various services in the road networks, such 508 as the emergency notification and navigation. Vehicle1's Router1 509 (called mobile router) and RSU1's Router3 (called fixed router) use 510 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for I2V 511 networking. Thus, one host (Host1) in Vehicle1 can communicate with 512 one server (Server1) in RSU1 for a vehicular service through 513 Vehicle1's moving network, a wireless link between Vehicle1 and RSU1, 514 and RSU1's fixed network. 516 4.3. V2V-based Internetworking 518 This section discusses the internetworking between the moving 519 networks of two neighboring vehicles via V2V communication. 521 (*)<..........>(*) 522 2001:DB8:1:1::/64 | | 523 +------------------------------+ +------------------------------+ 524 | v | | v | 525 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 526 | | Host1 | | DNS1 | |Router1| | | |Router5| | DNS3 | | Host4 | | 527 | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | 528 | ^ ^ ^ | | ^ ^ ^ | 529 | | | | | | | | | | 530 | v v v | | v v v | 531 | ---------------------------- | | ---------------------------- | 532 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:30:1::/64 | 533 | | | | | | 534 | v | | v | 535 | +-------+ +-------+ | | +-------+ +-------+ | 536 | | Host2 | |Router2| | | |Router6| | Host5 | | 537 | +-------+ +-------+ | | +-------+ +-------+ | 538 | ^ ^ | | ^ ^ | 539 | | | | | | | | 540 | v v | | v v | 541 | ---------------------------- | | ---------------------------- | 542 | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | 543 +------------------------------+ +------------------------------+ 544 Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) 546 <----> Wired Link <....> Wireless Link (*) Antenna 548 Figure 3: Internetworking between Two Vehicle Networks 550 Figure 3 shows internetworking between the moving networks of two 551 neighboring vehicles. There exists an internal network (Moving 552 Network1) inside Vehicle1. Vehicle1 has the DNS Server (DNS1), the 553 two hosts (Host1 and Host2), and the two routers (Router1 and 554 Router2). There exists another internal network (Moving Network2) 555 inside Vehicle2. Vehicle2 has the DNS Server (DNS3), the two hosts 556 (Host4 and Host5), and the two routers (Router5 and Router6). 557 Vehicle1's Router1 (called mobile router) and Vehicle2's Router5 558 (called mobile router) use 2001:DB8:1:1::/64 for an external link 559 (e.g., DSRC) for V2V networking. Thus, one host (Host1) in Vehicle1 560 can communicate with one host (Host4) in Vehicle1 for a vehicular 561 service through Vehicle1's moving network, a wireless link between 562 Vehicle1 and Vehicle2, and Vehicle2's moving network. 564 (*)<..................>(*)<..................>(*) 565 | | | 566 +-----------+ +-----------+ +-----------+ 567 | | | | | | 568 | +-------+ | | +-------+ | | +-------+ | 569 | |Router1| | | |Router5| | | |Router7| | 570 | +-------+ | | +-------+ | | +-------+ | 571 | | | | | | 572 | +-------+ | | +-------+ | | +-------+ | 573 | | Host1 | | | | Host4 | | | | Host6 | | 574 | +-------+ | | +-------+ | | +-------+ | 575 | | | | | | 576 +-----------+ +-----------+ +-----------+ 577 Vehicle1 Vehicle2 Vehicle3 579 <....> Wireless Link (*) Antenna 581 Figure 4: Multihop Internetworking between Two Vehicle Networks 583 Figure 4 shows multihop internetworking between the moving networks 584 of two vehicles in the same VANET. For example, Host1 in Vehicle1 585 can communicate with Host6 in Vehicle3 via Router 5 in Vehicle2 that 586 is an intermediate vehicle being connected to Vehicle1 and Vehicle3 587 in a linear topology as shown in the figure. 589 5. Problem Statement 591 This section makes a problem statement about key topics for IPWAVE 592 WG, such as neighbor discovery, mobility management, and security & 593 privacy. 595 5.1. Neighbor Discovery 597 IPv6 Neighbor Discovery (IPv6 ND) [RFC4861][RFC4862] is a core part 598 of the IPv6 protocol suite. IPv6 ND is designed for point-to-point 599 links and transit links (e.g., Ethernet). It assumes an efficient 600 and reliable support of multicast from the link layer for various 601 network operations such as MAC Address Resolution (AR) and Duplicate 602 Address Detection (DAD). 604 IPv6 ND needs to be extended to vehicular networking (e.g., V2V, V2I, 605 and V2X) in terms of DAD and ND-related parameters (e.g., Router 606 Lifetime). The vehicles are moving fast within the communication 607 coverage of a vehicular node (e.g., vehicle and RSU). Before the 608 vehicles can exchange application messages with each other, they need 609 to be configured with a link-local IPv6 address or a global IPv6 610 address, and recognize each other in the aspect of IPv6 ND. 612 The legacy DAD assumes that a node with an IPv6 address can reach any 613 other node with the scope of its address at the time it claims its 614 address, and can hear any future claim for that address by another 615 party within the scope of its address for the duration of the address 616 ownership. However, the partioning and merging of VANETs makes this 617 assumption frequently invalid in vehicular networks. 619 The vehicular networks need to support a vehicular-network-wide DAD 620 by defining a scope that is compatible with the legacy DAD, and two 621 vehicles can communicate with each other when there exists a 622 communication path over VANET or a combination of VANETs and RSUs, as 623 shown in Figure 1. By using the vehicular-network-wide DAD, vehicles 624 can assure that their IPv6 addresses are unique in the vehicular 625 network whenever they are connected to the vehicular infrastructure 626 or become disconnected from it in the form of VANET. Even though a 627 unique IPv6 address can be derived from a globally unique MAC 628 address, this derivation yields a privacy issue of a vehicle as an 629 IPv6 node. The vehicular infrastructure having RSUs and an MA can 630 participate in the vehicular-network-wide DAD for the sake of 631 vehicles [RFC6775][RFC8505]. 633 ND time-related parameters such as router lifetime and Neighbor 634 Advertisement (NA) interval should be adjusted for high-speed 635 vehicles and vehicle density. As vehicles move faster, the NA 636 interval should decrease (e.g., from 1 sec to 0.5 sec) for the NA 637 messages to reach the neighboring vehicles promptly. Also, as 638 vehicle density is higher, the NA interval should increase (e.g., 639 from 0.5 sec to 1 sec) for the NA messages to reduce collision 640 probability with other NA messages. 642 When ND is used in vehicular networks, the communication delay (i.e., 643 latency) between two vehicles should be bounded to a certain 644 threshold (e.g., 500 ms) for collision-avoidance message exchange 645 [CASD]. For IP-based safety applications (e.g., context-aware 646 navigation, adaptive cruise control, and platooning) in vehicular 647 network, this bounded data delivery is critical. The real 648 implementations for such applications are not available yet. Thus, 649 ND needs to appropriately operate to support IP-based safety 650 applications. 652 5.1.1. Link Model 654 IPv6 protocols work under certain assumptions for the link model that 655 do not necessarily hold in a vehicular wireless link [VIP-WAVE] 656 [RFC5889]. For instance, some IPv6 protocols assume symmetry in the 657 connectivity among neighboring interfaces. However, interference and 658 different levels of transmission power may cause unidirectional links 659 to appear in vehicular wireless links. As a result, a new vehicular 660 link model is required for a dynamically changing vehicular wireless 661 link. 663 There is a relationship between a link and prefix, besides the 664 different scopes that are expected from the link-local and global 665 types of IPv6 addresses. In an IPv6 link, it is assumed that all 666 interfaces which are configured with the same subnet prefix and with 667 on-link bit set can communicate with each other on an IP link. 669 A VANET can have multiple links between pairs of vehicles within 670 wireless communication range, as shown in Figure 4. When two 671 vehicles belong to the same VANET, but they are out of wireless 672 communication range, they cannot communicate directly with each 673 other. Assume that a global-scope IPv6 prefix is assigned to VANETs 674 in vehicular networks. Even though two vehicles in the same VANET 675 configure their IPv6 addresses with the same IPv6 prefix, they may 676 not communicate with each other not in a one hop in the same VANET 677 because of the multihop network connectivity. Thus, in this case, 678 the concept of a on-link IPv6 prefix does not hold because two 679 vehicles with the same on-link IPv6 prefix cannot communicate 680 directly with each other. Also, when two vehicles are located in two 681 different VANETs with the same IPv6 prefix, they cannot communicate 682 with each other. When these two VANETs are converged into one VANET, 683 the two vehicles can communicate with each other in a multihop 684 fashion. Therefore, a vehicular link model should consider the 685 frequent partitioning and merging of VANETs due to vehicle mobility. 687 An IPv6 prefix can be used in a multi-link subnet as an extended 688 subnet. IPv6 Stateless Address Autoconfiguration (SLAAC) needs to be 689 performed even in the multiple links where all of the links are 690 configured with the same subnet prefix [RFC4861][RFC4862]. Thus, a 691 vehicular link model can consider a multi-hop V2V (or V2I) over a 692 multi-link subnet in a vehicular network having multiple VANETs and 693 RSUs, as shown in Figure 1. For example, in this figure, vehicles 694 (i.e., Vehicle1, Vehicle2, and Vehicle3) in Subnet1 and Subnet2 695 having RSU1 and RSU2, respectively, construct a multi-link subnet 696 with VANETs and RSUs. Vehicle1 and Vehicle3 can also communicate 697 with each other via either multi-hop V2V or multi-hop V2I2V. When 698 two vehicles (e.g., Vehicle1 and Vehicle3 in Figure 1) are connected 699 in a VANET, it will be more efficient for them to communicate with 700 each other via VANET rather than RSUs. On the other hand, when two 701 vehicles (e.g., Vehicle1 and Vehicle3) are far away from the 702 communication range in separate VANETs and under two different RSUs, 703 they can communicate with each other through the relay of RSUs via 704 V2I2V. 706 Therefore, IPv6 ND needs to be extended for an efficient Vehicular 707 Neighbor Discovey (VND) to support the concept of an IPv6 link 708 corresponding to an IPv6 prefix even in a multi-link subnet 709 consisting of multiple vehicles and RSUs [ID-Vehicular-ND]. 711 5.1.2. MAC Address Pseudonym 713 For the protection of drivers' privacy, the pseudonym of a MAC 714 address of a vehicle's network interface should be used, with the 715 help of which the MAC address can be changed periodically. The 716 pseudonym of a MAC address affects an IPv6 address based on the MAC 717 address, and a transport-layer (e.g., TCP) session with an IPv6 718 address pair. However, the pseudonym handling is not implemented and 719 tested yet for applications on IP-based vehicular networking. 721 In the ETSI standards, for the sake of security and privacy, an ITS 722 station (e.g., vehicle) can use pseudonyms for its network interface 723 identities (e.g., MAC address) and the corresponding IPv6 addresses 724 [Identity-Management]. Whenever the network interface identifier 725 changes, the IPv6 address based on the network interface identifier 726 should be updated, and the uniqueness of the address should be 727 performed through the DAD procedure. For vehicular networks with 728 high-mobility, this DAD should be performed efficiently with minimum 729 overhead. 731 For the continuity of an end-to-end (E2E) transport-layer (e.g., TCP, 732 UDP, and SCTP) session, with a mobility management scheme (e.g., 733 MIPv6 and PMIPv6), the new IP address for the transport-layer session 734 can be notified to an appropriate end point, and the packets of the 735 session should be forwarded to their destinations with the changed 736 network interface identifier and IPv6 address. This mobiliy 737 management overhead for pseudonyms should be minimized for efficient 738 operations in vehicular networks having lots of vehicles. 740 5.1.3. Prefix Dissemination/Exchange 742 A vehicle and an RSU can have their internal network, as shown in 743 Figure 2 and Figure 3. In this case, nodes in within the internal 744 networks of two vehicular nodes (e.g., vehicle and RSU) want to 745 communicate with each other. For this communication on the wireless 746 link, the network prefix dissemination or exchange is required. It 747 is assumed that a vehicular node has an external network interface 748 and its internal network, as shown in Figure 2 and Figure 3. The 749 vehicular ND (VND) [ID-Vehicular-ND] can support the communication 750 between the internal-network nodes (e.g., an in-vehicle device in a 751 vehicle and a server in an RSU) of vehicular nodes with a vehicular 752 prefix information option. Thus, this ND extension for routing 753 functionality can reduce control traffic for routing in vehicular 754 networks without a vehicular ad hoc routing protocol (e.g., AODV 755 [RFC3561] and OLSRv2 [RFC7181]). 757 5.1.4. Routing 759 For multihop V2V communications in a VANET (or a multi-link subnet), 760 a vehicular ad hoc routing protocol (e.g., AODV and OLSRv2) may be 761 required to support both unicast and multicast in the links of the 762 subnet with the same IPv6 prefix. However, it will be costly to run 763 both vehicular ND and a vehicular ad hoc routing protocol in terms of 764 control traffic overhead. As a feasible approach, Vehicular ND can 765 be extended to accommodate routing functionality with a prefix 766 discovery option. In this case, there is no need to run a separate 767 vehicular ad hoc routing protocol in VANETs. The ND extension can 768 allow vehicles to exchange their prefixes in a multihop fashion 769 [ID-Vehicular-ND]. With the exchanged prefixes, they can compute 770 their routing table (or IPv6 ND's neighbor cache) for the multi-link 771 subnet with a distance-vector algorithm [Intro-to-Algorithms]. 773 Also, an efficient, rapid DAD needs to be supported in a vehicular 774 network having multiple VANETs (or a multi-link subnet) to prevent or 775 reduce IPv6 address conflicts in such a subnet. A feasible approach 776 is to use a multi-hop DAD optimization for the efficient vehicular- 777 network-wide DAD [RFC6775][RFC8505]. 779 5.2. Mobility Management 781 The seamless connectivity and timely data exchange between two end 782 points requires an efficient mobility management including location 783 management and handover. Most of vehicles are equipped with a GPS 784 receiver as part of a dedicated navigation system or a corresponding 785 smartphone App. The GPS receiver may not provide vehicles with 786 accurate location information in adverse, local environments such as 787 building area and tunnel. The location precision can be improved by 788 the assistance from the RSUs or a cellular system with a GPS receiver 789 for location information. 791 With a GPS navigator, an efficient mobility management will be 792 possible by vehicles periodically reporting their current position 793 and trajectory (i.e., navigation path) to the vehicular 794 infrastructure (having RSUs and an MA in TCC) [ID-Vehicular-MM]. 795 This vehicular infrastructure can predict the future positions of the 796 vehicles with their mobility information (i.e., the current position, 797 speed, direction, and trajectory) for the efficient mobility 798 management (e.g., proactive handover). For a better proactive 799 handover, link-layer parameters, such as the signal strength of a 800 link-layer frame (e.g., Received Channel Power Indicator (RCPI) 801 [VIP-WAVE]), can be used to determine the moment of a handover 802 between RSUs along with mobility information. 804 With the prediction of the vehicle mobility, the vehicular 805 infrastructure needs to support RSUs to perform efficient DAD, data 806 packet routing, horizontal handover (i.e., handover in wireless links 807 using a homogeneous radio technology), and vertical handover (i.e., 808 handover in wireless links using heterogeneous radio technologies) in 809 a proactive manner [ID-Vehicular-MM]. For example, when a vehicle is 810 moving into the wireless link under another RSU belonging to a 811 different subnet, the RSU can proactively perform the DAD for the 812 sake of the vehicle, reducing IPv6 control traffic overhead in the 813 wireless link. To prevent a hacker from impersonating RSUs as bogus 814 RSUs, RSUs and MA in the vehicular infrastructure need to have secure 815 channels via IPsec. 817 Therefore, with a proactive handover and a multihop DAD in vehicular 818 networks, RSUs needs to efficiently forward data packets from the 819 wired network (or the wireless network) to a moving destination 820 vehicle along its trajectory. As a result, a moving vehicle can 821 communicate with its corresponding vehicle in the vehicular network 822 or a host/server in the Internet along its trajectory. 824 5.3. Security and Privacy 826 Strong security measures shall protect vehicles roaming in road 827 networks from the attacks of malicious nodes, which are controlled by 828 hackers. For safety applications, the cooperation among vehicles is 829 assumed. Malicious nodes may disseminate wrong driving information 830 (e.g., location, speed, and direction) to make driving be unsafe. 831 Sybil attack, which tries to illude a vehicle with multiple false 832 identities, disturbs a vehicle in taking a safe maneuver. This sybil 833 attack should be prevented through the cooperation between good 834 vehicles and RSUs. Applications on IP-based vehicular networking, 835 which are resilient to such a sybil attack, are not developed and 836 tested yet. 838 Security and privacy are paramount in the V2I, V2V, and V2X 839 networking in vehicular networks. Only authorized vehicles should be 840 allowed to use vehicular networking. Also, in-vehicle devices and 841 mobile devices in a vehicle need to communicate with other in-vehicle 842 devices and mobile devices in another vehicle, and other servers in 843 an RSU in a secure way. 845 A Vehicle Identification Number (VIN) and a user certificate along 846 with in-vehicle device's identifier generation can be used to 847 efficiently authenticate a vehicle or a user through a road 848 infrastructure node (e.g., RSU) connected to an authentication server 849 in TCC. Also, Transport Layer Security (TLS) certificates can be 850 used for secure E2E vehicle communications. 852 For secure V2I communication, a secure channel between a mobile 853 router in a vehicle and a fixed router in an RSU should be 854 established, as shown in Figure 2. Also, for secure V2V 855 communication, a secure channel between a mobile router in a vehicle 856 and a mobile router in another vehicle should be established, as 857 shown in Figure 3. 859 To prevent an adversary from tracking a vehicle with its MAC address 860 or IPv6 address, MAC address pseudonym should be provided to the 861 vehicle; that is, each vehicle should periodically update its MAC 862 address and the corresponding IPv6 address as suggested in 863 [RFC4086][RFC4941]. Such an update of the MAC and IPv6 addresses 864 should not interrupt the E2E communications between two vehicular 865 nodes (e.g., vehicle and RSU) in terms of transport layer for a long- 866 living higher-layer session. However, if this pseudonym is performed 867 without strong E2E confidentiality, there will be no privacy benefit 868 from changing MAC and IP addresses, because an adversary can see the 869 change of the MAC and IP addresses and track the vehicle with those 870 addresses. 872 6. Security Considerations 874 This document discussed security and privacy for IP-based vehicular 875 networking. 877 The security and privacy for key components in IP-based vehicular 878 networking, such as neighbor discovery and mobility management, need 879 to be analyzed in depth. 881 7. Informative References 883 [Automotive-Sensing] 884 Choi, J., Va, V., Gonzalez-Prelcic, N., Daniels, R., R. 885 Bhat, C., and R. W. Heath, "Millimeter-Wave Vehicular 886 Communication to Support Massive Automotive Sensing", 887 IEEE Communications Magazine, December 2016. 889 [CA-Cruise-Control] 890 California Partners for Advanced Transportation Technology 891 (PATH), "Cooperative Adaptive Cruise Control", [Online] 892 Available: 893 http://www.path.berkeley.edu/research/automated-and- 894 connected-vehicles/cooperative-adaptive-cruise-control, 895 2017. 897 [CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A 898 Framework of Context-Awareness Safety Driving in Vehicular 899 Networks", International Workshop on Device Centric Cloud 900 (DC2), March 2016. 902 [DSRC] ASTM International, "Standard Specification for 903 Telecommunications and Information Exchange Between 904 Roadside and Vehicle Systems - 5 GHz Band Dedicated Short 905 Range Communications (DSRC) Medium Access Control (MAC) 906 and Physical Layer (PHY) Specifications", 907 ASTM E2213-03(2010), October 2010. 909 [ETSI-GeoNetwork-IP] 910 ETSI Technical Committee Intelligent Transport Systems, 911 "Intelligent Transport Systems (ITS); Vehicular 912 Communications; GeoNetworking; Part 6: Internet 913 Integration; Sub-part 1: Transmission of IPv6 Packets over 914 GeoNetworking Protocols", ETSI EN 302 636-6-1, October 915 2013. 917 [ETSI-GeoNetworking] 918 ETSI Technical Committee Intelligent Transport Systems, 919 "Intelligent Transport Systems (ITS); Vehicular 920 Communications; GeoNetworking; Part 4: Geographical 921 addressing and forwarding for point-to-point and point-to- 922 multipoint communications; Sub-part 1: Media-Independent 923 Functionality", ETSI EN 302 636-4-1, May 2014. 925 [EU-2008-671-EC] 926 European Union, "Commission Decision of 5 August 2008 on 927 the Harmonised Use of Radio Spectrum in the 5875 - 5905 928 MHz Frequency Band for Safety-related Applications of 929 Intelligent Transport Systems (ITS)", EU 2008/671/EC, 930 August 2008. 932 [FirstNet] 933 U.S. National Telecommunications and Information 934 Administration (NTIA), "First Responder Network Authority 935 (FirstNet)", [Online] 936 Available: https://www.firstnet.gov/, 2012. 938 [FirstNet-Report] 939 First Responder Network Authority, "FY 2017: ANNUAL REPORT 940 TO CONGRESS, Advancing Public Safety Broadband 941 Communications", FirstNet FY 2017, December 2017. 943 [Fuel-Efficient] 944 van de Hoef, S., H. Johansson, K., and D. V. Dimarogonas, 945 "Fuel-Efficient En Route Formation of Truck Platoons", 946 IEEE Transactions on Intelligent Transportation Systems, 947 January 2018. 949 [ID-Vehicular-MM] 950 Jeong, J., Ed., Shen, Y., and Z. Xiang, "Vehicular 951 Mobility Management for IP-Based Vehicular Networks", 952 draft-jeong-ipwave-vehicular-mobility-management-00 (work 953 in progress), March 2019. 955 [ID-Vehicular-ND] 956 Jeong, J., Ed., Shen, Y., and Z. Xiang, "IPv6 Neighbor 957 Discovery for IP-Based Vehicular Networks", draft-jeong- 958 ipwave-vehicular-neighbor-discovery-06 (work in progress), 959 March 2019. 961 [Identity-Management] 962 Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer 963 Identities Management in ITS Stations", The 10th 964 International Conference on ITS Telecommunications, 965 November 2010. 967 [IEEE-802.11-OCB] 968 "Part 11: Wireless LAN Medium Access Control (MAC) and 969 Physical Layer (PHY) Specifications", IEEE Std 970 802.11-2016, December 2016. 972 [IEEE-802.11p] 973 "Part 11: Wireless LAN Medium Access Control (MAC) and 974 Physical Layer (PHY) Specifications - Amendment 6: 975 Wireless Access in Vehicular Environments", IEEE Std 976 802.11p-2010, June 2010. 978 [Intro-to-Algorithms] 979 H. Cormen, T., E. Leiserson, C., L. Rivest, R., and C. 980 Stein, "Introduction to Algorithms, 3rd ed.", The 981 MIT Press, July 2009. 983 [IPv6-over-802.11-OCB] 984 Benamar, N., Haerri, J., Lee, J., and T. Ernst, 985 "Transmission of IPv6 Packets over IEEE 802.11 Networks 986 operating in mode Outside the Context of a Basic Service 987 Set (IPv6-over-80211-OCB)", draft-ietf-ipwave-ipv6-over- 988 80211ocb-45 (work in progress), April 2019. 990 [ISO-ITS-IPv6] 991 ISO/TC 204, "Intelligent Transport Systems - 992 Communications Access for Land Mobiles (CALM) - IPv6 993 Networking", ISO 21210:2012, June 2012. 995 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 996 Demand Distance Vector (AODV) Routing", RFC 3561, July 997 2003. 999 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1000 "Randomness Requirements for Security", RFC 4086, June 1001 2005. 1003 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1004 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 1005 September 2007. 1007 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1008 Address Autoconfiguration", RFC 4862, September 2007. 1010 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1011 Extensions for Stateless Address Autoconfiguration in 1012 IPv6", RFC 4941, September 2007. 1014 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1015 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1016 RFC 5213, August 2008. 1018 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1019 Mobile IPv6", RFC 5844, May 2010. 1021 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 1022 Hoc Networks", RFC 5889, September 2010. 1024 [RFC5944] Perkins, C., Ed., "IP Mobility Support in IPv4, Revised", 1025 RFC 5944, November 2010. 1027 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1028 Support in IPv6", RFC 6275, July 2011. 1030 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1031 "Neighbor Discovery Optimization for IPv6 over Low-Power 1032 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1033 November 2012. 1035 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 1036 "The Optimized Link State Routing Protocol Version 2", 1037 RFC 7181, April 2014. 1039 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 1040 "Requirements for Distributed Mobility Management", 1041 RFC 7333, August 2014. 1043 [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. 1044 Bernardos, "Distributed Mobility Management: Current 1045 Practices and Gap Analysis", RFC 7429, January 2015. 1047 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1048 (IPv6) Specification", RFC 8200, July 2017. 1050 [RFC8505] Thubert, P., Nordmark, E., Chakrabarti, S., and C. 1051 Perkins, "Registration Extensions for IPv6 over Low-Power 1052 Wireless Personal Area Network (6LoWPAN) Neighbor 1053 Discovery", RFC 8505, November 2018. 1055 [SAINT] Jeong, J., Jeong, H., Lee, E., Oh, T., and D. Du, "SAINT: 1056 Self-Adaptive Interactive Navigation Tool for Cloud-Based 1057 Vehicular Traffic Optimization", IEEE Transactions on 1058 Vehicular Technology, Vol. 65, No. 6, June 2016. 1060 [SAINTplus] 1061 Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D. 1062 Du, "SAINT+: Self-Adaptive Interactive Navigation Tool+ 1063 for Emergency Service Delivery Optimization", 1064 IEEE Transactions on Intelligent Transportation Systems, 1065 June 2017. 1067 [SANA] Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation 1068 Application for Pedestrian Protection in Vehicular 1069 Networks", Springer Lecture Notes in Computer Science 1070 (LNCS), Vol. 9502, December 2015. 1072 [SDN-DMM] Nguyen, T., Bonnet, C., and J. Harri, "SDN-based 1073 Distributed Mobility Management for 5G Networks", 1074 IEEE Wireless Communications and Networking Conference, 1075 April 2016. 1077 [Truck-Platooning] 1078 California Partners for Advanced Transportation Technology 1079 (PATH), "Automated Truck Platooning", [Online] Available: 1080 http://www.path.berkeley.edu/research/automated-and- 1081 connected-vehicles/truck-platooning, 2017. 1083 [TS-23.285-3GPP] 1084 3GPP, "Architecture Enhancements for V2X Services", 3GPP 1085 TS 23.285, June 2018. 1087 [VIP-WAVE] 1088 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 1089 Feasibility of IP Communications in 802.11p Vehicular 1090 Networks", IEEE Transactions on Intelligent Transportation 1091 Systems, vol. 14, no. 1, March 2013. 1093 [WAVE-1609.0] 1094 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 1095 in Vehicular Environments (WAVE) - Architecture", IEEE Std 1096 1609.0-2013, March 2014. 1098 [WAVE-1609.2] 1099 IEEE 1609 Working Group, "IEEE Standard for Wireless 1100 Access in Vehicular Environments - Security Services for 1101 Applications and Management Messages", IEEE Std 1102 1609.2-2016, March 2016. 1104 [WAVE-1609.3] 1105 IEEE 1609 Working Group, "IEEE Standard for Wireless 1106 Access in Vehicular Environments (WAVE) - Networking 1107 Services", IEEE Std 1609.3-2016, April 2016. 1109 [WAVE-1609.4] 1110 IEEE 1609 Working Group, "IEEE Standard for Wireless 1111 Access in Vehicular Environments (WAVE) - Multi-Channel 1112 Operation", IEEE Std 1609.4-2016, March 2016. 1114 Appendix A. Changes from draft-ietf-ipwave-vehicular-networking-08 1116 The following changes are made from draft-ietf-ipwave-vehicular- 1117 networking-08: 1119 o This version is revised based on the comments from Charlie Perkins 1120 and Sri Gundavelli. 1122 o This version focuses on the problem statement about IP-based 1123 vehicular networking, such as IPv6 neighbor discovery, mobility 1124 management, and security & privacy. 1126 Appendix B. Acknowledgments 1128 This work was supported by Basic Science Research Program through the 1129 National Research Foundation of Korea (NRF) funded by the Ministry of 1130 Education (2017R1D1A1B03035885). 1132 This work was supported in part by the MSIT (Ministry of Science and 1133 ICT), Korea, under the ITRC (Information Technology Research Center) 1134 support program (IITP-2019-2017-0-01633) supervised by the IITP 1135 (Institute for Information & communications Technology Promotion). 1137 This work was supported in part by the French research project 1138 DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded 1139 by the European Commission I (636537-H2020). 1141 Appendix C. Contributors 1143 This document is a group work of IPWAVE working group, greatly 1144 benefiting from inputs and texts by Rex Buddenberg (Naval 1145 Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest 1146 University of Technology and Economics), Jose Santa Lozanoi 1147 (Universidad of Murcia), Richard Roy (MIT), Francois Simon (Pilot), 1148 Sri Gundavelli (Cisco), Erik Nordmark, Dirk von Hugo (Deutsche 1149 Telekom), and Pascal Thubert (Cisco). The authors sincerely 1150 appreciate their contributions. 1152 The following are co-authors of this document: 1154 Nabil Benamar 1155 Department of Computer Sciences 1156 High School of Technology of Meknes 1157 Moulay Ismail University 1158 Morocco 1160 Phone: +212 6 70 83 22 36 1161 EMail: benamar73@gmail.com 1162 Sandra Cespedes 1163 NIC Chile Research Labs 1164 Universidad de Chile 1165 Av. Blanco Encalada 1975 1166 Santiago 1167 Chile 1169 Phone: +56 2 29784093 1170 EMail: scespede@niclabs.cl 1172 Jerome Haerri 1173 Communication Systems Department 1174 EURECOM 1175 Sophia-Antipolis 1176 France 1178 Phone: +33 4 93 00 81 34 1179 EMail: jerome.haerri@eurecom.fr 1181 Dapeng Liu 1182 Alibaba 1183 Beijing, Beijing 100022 1184 China 1186 Phone: +86 13911788933 1187 EMail: max.ldp@alibaba-inc.com 1189 Tae (Tom) Oh 1190 Department of Information Sciences and Technologies 1191 Rochester Institute of Technology 1192 One Lomb Memorial Drive 1193 Rochester, NY 14623-5603 1194 USA 1196 Phone: +1 585 475 7642 1197 EMail: Tom.Oh@rit.edu 1199 Charles E. Perkins 1200 Futurewei Inc. 1201 2330 Central Expressway 1202 Santa Clara, CA 95050 1203 USA 1204 Phone: +1 408 330 4586 1205 EMail: charliep@computer.org 1207 Alexandre Petrescu 1208 CEA, LIST 1209 CEA Saclay 1210 Gif-sur-Yvette, Ile-de-France 91190 1211 France 1213 Phone: +33169089223 1214 EMail: Alexandre.Petrescu@cea.fr 1216 Yiwen Chris Shen 1217 Department of Computer Science & Engineering 1218 Sungkyunkwan University 1219 2066 Seobu-Ro, Jangan-Gu 1220 Suwon, Gyeonggi-Do 16419 1221 Republic of Korea 1223 Phone: +82 31 299 4106 1224 Fax: +82 31 290 7996 1225 EMail: chrisshen@skku.edu 1226 URI: http://iotlab.skku.edu/people-chris-shen.php 1228 Michelle Wetterwald 1229 FBConsulting 1230 21, Route de Luxembourg 1231 Wasserbillig, Luxembourg L-6633 1232 Luxembourg 1234 EMail: Michelle.Wetterwald@gmail.com 1236 Author's Address 1237 Jaehoon Paul Jeong (editor) 1238 Department of Software 1239 Sungkyunkwan University 1240 2066 Seobu-Ro, Jangan-Gu 1241 Suwon, Gyeonggi-Do 16419 1242 Republic of Korea 1244 Phone: +82 31 299 4957 1245 Fax: +82 31 290 7996 1246 EMail: pauljeong@skku.edu 1247 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php