idnits 2.17.1 draft-ietf-ipwave-vehicular-networking-01.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 (November 13, 2017) is 2349 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Online' is mentioned on line 2106, but not defined == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-iot-dns-autoconf-01 == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-vehicular-neighbor-discovery-01 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jeong, Ed. 3 Internet-Draft Sungkyunkwan University 4 Intended status: Informational November 13, 2017 5 Expires: May 17, 2018 7 IP-based Vehicular Networking: Use Cases, Survey and Problem Statement 8 draft-ietf-ipwave-vehicular-networking-01 10 Abstract 12 This document discusses use cases, survey, and problem statement on 13 IP-based vehicular networks, which are considered a key component of 14 Intelligent Transportation Systems (ITS). The main topics of 15 vehicular networking are vehicle-to-vehicle (V2V), vehicle-to- 16 infrastructure (V2I), and infrastructure-to-vehicle (I2V) networking. 17 First, this document surveys use cases using V2V and V2I networking. 18 Second, this document deals with some critical aspects in vehicular 19 networking, such as vehicular network architectures, standardization 20 activities, IP address autoconfiguration, routing, mobility 21 management, DNS naming service, service discovery, and security and 22 privacy. For each aspect, this document discusses problem statement 23 to analyze the gap between the state-of-the-art techniques and 24 requirements in IP-based vehicular networking. Finally, this 25 document articulates discussions including the summary and analysis 26 of vehicular networking aspects and raises deployment issues. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 17, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. V2I Use Cases . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. V2V Use Cases . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Vehicular Network Architectures . . . . . . . . . . . . . . . 7 68 4.1. Existing Architectures . . . . . . . . . . . . . . . . . 7 69 4.1.1. VIP-WAVE: IP in 802.11p Vehicular Networks . . . . . 7 70 4.1.2. IPv6 Operation for WAVE . . . . . . . . . . . . . . . 8 71 4.1.3. Multicast Framework for Vehicular Networks . . . . . 9 72 4.1.4. Joint IP Networking and Radio Architecture . . . . . 9 73 4.1.5. Mobile Internet Access in FleetNet . . . . . . . . . 10 74 4.1.6. A Layered Architecture for Vehicular DTNs . . . . . . 11 75 4.2. V2I and V2V Internetworking Problem Statement . . . . . . 12 76 4.2.1. V2I-based Internetworking . . . . . . . . . . . . . . 13 77 4.2.2. V2V-based Internetworking . . . . . . . . . . . . . . 16 78 5. Standardization Activities . . . . . . . . . . . . . . . . . 16 79 5.1. IEEE Guide for WAVE - Architecture . . . . . . . . . . . 16 80 5.2. IEEE Standard for WAVE - Networking Services . . . . . . 17 81 5.3. ETSI Intelligent Transport Systems: GeoNetwork-IPv6 . . . 18 82 5.4. ISO Intelligent Transport Systems: IPv6 over CALM . . . . 18 83 6. IP Address Autoconfiguration . . . . . . . . . . . . . . . . 19 84 6.1. Existing Protocols for Address Autoconfiguration . . . . 19 85 6.1.1. Automatic IP Address Configuration in VANETs . . . . 19 86 6.1.2. Using Lane/Position Information . . . . . . . . . . . 20 87 6.1.3. GeoSAC: Scalable Address Autoconfiguration . . . . . 20 88 6.1.4. Cross-layer Identities Management in ITS Stations . . 21 89 6.2. Problem Statement for IP Address Autoconfiguration . . . 22 90 6.2.1. Neighbor Discovery . . . . . . . . . . . . . . . . . 22 91 6.2.2. IP Address Autoconfiguration . . . . . . . . . . . . 22 92 7. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 7.1. Existing Routing Protocols . . . . . . . . . . . . . . . 24 94 7.1.1. Experimental Evaluation for IPv6 over GeoNet . . . . 24 95 7.1.2. Location-Aided Gateway Advertisement and Discovery . 24 96 7.2. Routing Problem Statement . . . . . . . . . . . . . . . . 25 97 8. Mobility Management . . . . . . . . . . . . . . . . . . . . . 25 98 8.1. Existing Protocols . . . . . . . . . . . . . . . . . . . 25 99 8.1.1. Vehicular Ad Hoc Networks with Network Fragmentation 25 100 8.1.2. Hybrid Centralized-Distributed Mobility Management . 26 101 8.1.3. Hybrid Architecture for Network Mobility Management . 27 102 8.1.4. NEMO-Enabled Localized Mobility Support . . . . . . . 28 103 8.1.5. Network Mobility for Vehicular Ad Hoc Networks . . . 29 104 8.1.6. Performance Analysis of P-NEMO for ITS . . . . . . . 29 105 8.1.7. Integration of VANets and Fixed IP Networks . . . . . 30 106 8.1.8. SDN-based Mobility Management for 5G Networks . . . . 30 107 8.1.9. IP Mobility for VANETs: Challenges and Solutions . . 31 108 8.2. Problem Statement for Mobility-Management . . . . . . . . 32 109 9. DNS Naming Service . . . . . . . . . . . . . . . . . . . . . 33 110 9.1. Existing Protocols . . . . . . . . . . . . . . . . . . . 33 111 9.1.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 33 112 9.1.2. DNS Name Autoconfiguration for IoT Devices . . . . . 33 113 9.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 34 114 10. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 35 115 10.1. Existing Protocols . . . . . . . . . . . . . . . . . . . 35 116 10.1.1. mDNS-based Service Discovery . . . . . . . . . . . . 35 117 10.1.2. ND-based Service Discovery . . . . . . . . . . . . . 35 118 10.2. Problem Statement . . . . . . . . . . . . . . . . . . . 35 119 11. Security and Privacy . . . . . . . . . . . . . . . . . . . . 36 120 11.1. Existing Protocols . . . . . . . . . . . . . . . . . . . 36 121 11.1.1. Securing Vehicular IPv6 Communications . . . . . . . 36 122 11.1.2. Authentication and Access Control . . . . . . . . . 37 123 11.2. Problem Statement . . . . . . . . . . . . . . . . . . . 37 124 12. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 38 125 12.1. Summary and Analysis . . . . . . . . . . . . . . . . . . 38 126 12.2. Deployment Issues . . . . . . . . . . . . . . . . . . . 39 127 13. Security Considerations . . . . . . . . . . . . . . . . . . . 39 128 14. Informative References . . . . . . . . . . . . . . . . . . . 40 129 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 47 130 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 47 131 Appendix C. Changes from draft-ietf-ipwave-vehicular- 132 networking-00 . . . . . . . . . . . . . . . . . . . 49 133 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49 135 1. Introduction 137 Vehicular networks have been focused on the driving safety, driving 138 efficiency, and entertainment in road networks. The Federal 139 Communications Commission (FCC) in the US allocated wireless channels 140 for Dedicated Short-Range Communications (DSRC) service in the 141 Intelligent Transportation Systems (ITS) Radio Service in the 142 5.850-5.925 GHz band (5.9 GHz band). DSRC-based wireless 143 communications can support vehicle-to-vehicle (V2V), vehicle-to- 144 infrastructure (V2I), and infrastructure-to-vehicle (I2V) networking. 146 For driving safety services based on the DSRC, IEEE has standardized 147 Wireless Access in Vehicular Environments (WAVE) standards, such as 148 IEEE 802.11p [IEEE-802.11p], IEEE 1609.2 [WAVE-1609.2], IEEE 1609.3 149 [WAVE-1609.3], and IEEE 1609.4 [WAVE-1609.4]. Note that IEEE 802.11p 150 has been published as IEEE 802.11 Outside the Context of a Basic 151 Service Set (OCB) [IEEE-802.11-OCB] in 2012. Along with these WAVE 152 standards, IPv6 and Mobile IP protocols (e.g., MIPv4 and MIPv6) can 153 be extended to vehicular networks [RFC2460][RFC6275]. 155 This document discusses use cases, survey, and problem statements 156 related to IP-based vehicular networking for Intelligent 157 Transportation Systems (ITS). This document first surveys the use 158 cases for using V2V and V2I networking in the ITS. Second, this 159 document deals with some critical aspects in vehicular networking, 160 such as vehicular network architectures, standardization activities, 161 IP address autoconfiguration, routing, mobility management, DNS 162 naming service, service discovery, and security and privacy. For 163 each aspect, this document shows problem statement to analyze the gap 164 between the state-of-the-art techniques and requirements in IP-based 165 vehicular networking. Finally, this document addresses discussions 166 including the summary and analysis of vehicular networking aspects, 167 raising deployment issues in road environments. 169 Based on the use cases, survey, and problem statement of this 170 document, we can specify the requirements for vehicular networks for 171 the intended purposes, such as the driving safety, driving 172 efficiency, and entertainment. As a consequence, this will make it 173 possible to design a network architecture and protocols for vehicular 174 networking. 176 2. Terminology 178 This document uses the following definitions: 180 o Road-Side Unit (RSU): A node that has Dedicated Short-Range 181 Communications (DSRC) device for wireless communications with 182 vehicles and is also connected to the Internet as a router or 183 switch for packet forwarding. An RSU is deployed either at an 184 intersection or in a road segment. 186 o On-Board Unit (OBU): A node that has a DSRC device for wireless 187 communications with other OBUs and RSUs. An OBU is mounted on a 188 vehicle. It is assumed that a radio navigation receiver (e.g., 189 Global Positioning System (GPS)) is included in a vehicle with an 190 OBU for efficient navigation. 192 o Vehicle Detection Loop (or Loop Detector): An inductive device 193 used for detecting vehicles passing or arriving at a certain 194 point, for instance approaching a traffic light or in motorway 195 traffic. The relatively crude nature of the loop's structure 196 means that only metal masses above a certain size are capable of 197 triggering the detection. 199 o Traffic Control Center (TCC): A node that maintains road 200 infrastructure information (e.g., RSUs, traffic signals, and loop 201 detectors), vehicular traffic statistics (e.g., average vehicle 202 speed and vehicle inter-arrival time per road segment), and 203 vehicle information (e.g., a vehicle's identifier, position, 204 direction, speed, and trajectory as a navigation path). TCC is 205 included in a vehicular cloud for vehicular networks. Example 206 functions of TCC include the management of evacuation routes, the 207 monitoring of real-time mass transit operations, and real-time 208 responsive traffic signal systems. Thus, TCC is the nerve center 209 of most freeway management sytems such that data is collected, 210 processed, and fused with other operational and control data, and 211 is also synthesized to produce "information" distributed to 212 stakeholders, other agencies, and traveling public. TCC is called 213 Traffic Management Center (TMC) in the US. TCC can communicate 214 with road infrastructure nodes (e.g., RSUs, traffic signals, and 215 loop detectors) to share measurement data and management 216 information by an application-layer protocol. 218 o WAVE: Acronym for "Wireless Access in Vehicular Environments" 220 3. Use Cases 222 This section provides use cases of V2V and V2I networking. 224 3.1. V2I Use Cases 226 The use cases of V2I networking include navigation service, fuel- 227 efficient speed recommendation service, and accident notification 228 service. 230 A navigation service, such as the Self-Adaptive Interactive 231 Navigation Tool (called SAINT) [SAINT], using V2I networking 232 interacts with TCC for the global road traffic optimization and can 233 guide individual vehicles for appropriate navigation paths in real 234 time. The enhanced SAINT (called SAINT+) [SAINTplus] can give the 235 fast moving paths for emergency vehicles (e.g., ambulance and fire 236 engine) toward accident spots while providing other vehicles with 237 efficient detour paths. 239 The emergency communication between accident vehicles (or emergency 240 vehicles) and TCC can be performed via either RSU or 4G-LTE networks. 241 The First Responder Network Authority (FirstNet) [FirstNet] is 242 provided by the US government to establish, operate, and maintain an 243 interoperable public safety broadband network for safety and security 244 network services, such as emergency calls. The construction of the 245 nationwide FirstNet network requires each state in the US to have a 246 Radio Access Network (RAN) that will connect to FirstNet's network 247 core. The current RAN is mainly constructed by 4G-LTE, but DSRC- 248 based vehicular networks can be used in near future. 250 A pedestrian protection service, such as Safety-Aware Navigation 251 Application (called SANA) [SANA], using V2I networking can reduce the 252 collision of a pedestrian and a vehicle, which have a smartphone, in 253 a road network. Vehicles and pedestrians can communicate with each 254 other via an RSU that delivers scheduling information for wireless 255 communication to save the smartphones' battery. 257 3.2. V2V Use Cases 259 The use cases of V2V networking include context-aware navigation for 260 driving safety, cooperative adaptive cruise control in an urban 261 roadway, and platooning in a highway. These three techniques will be 262 important elements for self-driving vehicles. 264 Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers 265 to drive safely by letting the drivers recognize dangerous obstacles 266 and situations. That is, CASD navigator displays obstables or 267 neighboring vehicles relevant to possible collisions in real-time 268 through V2V networking. CASD provides vehicles with a class-based 269 automatic safety action plan, which considers three situations, such 270 as the Line-of-Sight unsafe, Non-Line-of-Sight unsafe and safe 271 situations. This action plan can be performed among vehicles through 272 V2V networking. 274 Cooperative Adaptive Cruise Control (CACC) [CA-Cuise-Control] helps 275 vehicles to adapt their speed autonomously through V2V communication 276 among vehicles according to the mobility of their predecessor and 277 successor vehicles in an urban roadway or a highway. CACC can help 278 adjacent vehicles to efficiently adjust their speed in a cascade way 279 through V2V networking. 281 Platooning [Truck-Platooning] allows a series of vehicles (e.g., 282 trucks) to move together with a very short inter-distance. Trucks 283 can use V2V communication in addition to forward sensors in order to 284 maintain constant clearance between two consecutive vehicles at very 285 short gaps (from 3 meters to 10 meters). This platooning can 286 maximize the throughput of vehicular traffic in a highway and reduce 287 the gas consumption because the leading vehicle can help the 288 following vehicles to experience less air resistance. 290 4. Vehicular Network Architectures 292 This section surveys vehicular network architectures based on IP 293 along with various radio technologies, and then discusses problem 294 statement for a vehicular network architecture for IP-based vehicular 295 networking. 297 4.1. Existing Architectures 299 4.1.1. VIP-WAVE: IP in 802.11p Vehicular Networks 301 Cespedes et al. proposed a vehicular IP in WAVE called VIP-WAVE for 302 I2V and V2I networking [VIP-WAVE]. IEEE 1609.3 specified a WAVE 303 stack of protocols and includes IPv6 as a network layer protocol in 304 data plane [WAVE-1609.3]. The standard WAVE does not support 305 Duplicate Address Detection (DAD) of IPv6 Stateless Address 306 Autoconfiguration (SLAAC) [RFC4862] due to its own efficient IP 307 address configuration based on a WAVE Service Advertisement (WSA) 308 management frame [WAVE-1609.3], seamless communications for Internet 309 services, and multi-hop communications between a vehicle and an 310 infrastructure node (e.g., RSU). To overcome these limitations of 311 the standard WAVE for IP-based networking, VIP-WAVE enhances the 312 standard WAVE by the following three schemes: (i) an efficient 313 mechanism for the IPv6 address assignment and DAD, (ii) on-demand IP 314 mobility based on Proxy Mobile IPv6 (PMIPv6), and (iii) one-hop and 315 two-hop communications for I2V and V2I networking. 317 In WAVE, IPv6 Neighbor Discovery (ND) protocol is not recommended due 318 to the overhead of ND against the timely and prompt communications in 319 vehicular networking. By WAVE service advertisement (WAS) management 320 frame, an RSU can provide vehicles with IP configuration information 321 (e.g., IPv6 prefix, prefix length, gateway, router lifetime, and DNS 322 server) without using ND. However, WAVE devices may support 323 readdressing to provide pseudonymity, so a MAC address of a vehicle 324 may be changed or randomly generated. This update of the MAC address 325 may lead to the collision of an IPv6 address based on a MAC address, 326 so VIP-WAVE includes a light-weight, on-demand ND to perform DAD. 328 For IP-based Internet services, VIP-WAVE adopts PMIPv6 for network- 329 based mobility management in vehicular networks. In VIP-WAVE, RSU 330 plays a role of mobile anchor gateway (MAG) of PMIPv6, which performs 331 the detection of a vehicle as a mobile node in a PMIPv6 domain and 332 registers it into the PMIPv6 domain. For PMIPv6 operations, VIP-WAVE 333 requires a central node called local mobility anchor (LMA), which 334 assigns IPv6 prefixes to vehicles as mobile nodes and forwards data 335 packets to the vehicles moving in the coverage of RSUs under its 336 control through tunnels between MAGs and itself. 338 For two-hop communications between a vehicle and an RSU, VIP-WAVE 339 allows an intermediate vehicle between the vehicle and the RSU to 340 play a role of a packet relay for the vehicle. When it becomes out 341 of the communication range of an RSU, a vehicle searches for another 342 vehicle as a packet relay by sending a relay service announcement. 343 When it receives this relay service announcement and is within the 344 communication range of an RSU, another vehicle registers itself into 345 the RSU as a relay and notifies the relay-requester vehicle of a 346 relay maintenance announcement. 348 Thus, VIP-WAVE is a good candidate for I2V and V2I networking, 349 supporting an enhanced ND, handover, and two-hop communications 350 through a relay. 352 4.1.2. IPv6 Operation for WAVE 354 Baccelli et al. provided an analysis of the operation of IPv6 as it 355 has been described by the IEEE WAVE standards 1609 [IPv6-WAVE]. 356 Although the main focus of WAVE has been the timely delivery of 357 safety related information, the deployment of IP-based entertainment 358 applications is also considered. Thus, in order to support 359 entertainment traffic, WAVE supports IPv6 and transport protocols 360 such as TCP and UDP. 362 In the analysis provided in [IPv6-WAVE], it is identified that the 363 IEEE 1609.3 standard's recommendations for IPv6 operation over WAVE 364 are rather minimal. Protocols on which the operation of IPv6 relies 365 for IP address configuration and IP-to-link-layer address translation 366 (e.g., IPv6 ND protocol) are not recommended in the standard. 367 Additionally, IPv6 implementations work under certain assumptions for 368 the link model that do not necessarily hold in WAVE. For instance, 369 some IPv6 implementations assume symmetry in the connectivity among 370 neighboring interfaces. However, interference and different levels 371 of transmission power may cause unidirectional links to appear in a 372 WAVE link model. Also, in an IPv6 link, it is assumed that all 373 interfaces which are configured with the same subnet prefix are on 374 the same IP link. Hence, there is a relationship between link and 375 prefix, besides the different scopes that are expected from the link- 376 local and global types of IPv6 addresses. Such a relationship does 377 not hold in a WAVE link model due to node mobility and highly dynamic 378 topology. 380 Baccelli et al. concluded that the use of the standard IPv6 protocol 381 stack, as the IEEE 1609 family of specifications stipulate, is not 382 sufficient. Instead, the addressing assignment should follow 383 considerations for ad-hoc link models, defined in [RFC5889], which 384 are similar to the characteristics of the WAVE link model. In terms 385 of the supporting protocols for IPv6, such as ND, DHCP, or stateless 386 auto-configuration, which rely largely on multicast, do not operate 387 as expected in the case where the WAVE link model does not have the 388 same behavior expected for multicast IPv6 traffic due to nodes' 389 mobility and link variability. Additional challenges such as the 390 support of pseudonimity through MAC address change along with the 391 suitability of traditional TCP applications are discussed by the 392 authors since those challenges require the design of appropriate 393 solutions. 395 4.1.3. Multicast Framework for Vehicular Networks 397 Jemaa et al. presented a framework that enables deploying multicast 398 services for vehicular networks in Infrastructure-based scenarios 399 [VNET-Framework]. This framework deals with two phases: (i) 400 Initialization or bootstrapping phase that includes a geographic 401 multicast auto-configuration process and a group membership building 402 method and (ii) Multicast traffic dissemination phase that includes a 403 network selecting mechanism on the transmission side and a receiver- 404 based multicast delivery in the reception side. To this end, the 405 authors define a distributed mechanism that allows the vehicles to 406 configure a common multicast address: Geographic Multicast Address 407 Auto-configuration (GMAA), which allows a vehicle to configure its 408 own address without signaling. A vehicle may also be able to change 409 the multicast address to which it is subscribed when it changes its 410 location. 412 This framework suggests a network selecting approach that allows IP 413 and non-IP multicast data delivery on the sender side. Then, to meet 414 the challenges of multicast address auto-configuration, the authors 415 propose a distributed geographic multicast auto-addressing mechanism 416 for multicast groups of vehicles, and a simple multicast data 417 delivery scheme in hybrid networks from a server to the group of 418 moving vehicles. However, the GMAA study lacks simulations related 419 to performance assessment. 421 4.1.4. Joint IP Networking and Radio Architecture 423 Petrescu et al. defined the joint IP networking and radio 424 architecture for V2V and V2I communication in [Joint-IP-Networking]. 425 The paper proposes to consider an IP topology in a similar way as a 426 radio link topology, in the sense that an IP subnet would correspond 427 to the range of 1-hop vehicular communication. The paper defines 428 three types of vehicles: Leaf Vehicle (LV), Range Extending Vehicle 429 (REV), and Internet Vehicle (IV). The first class corresponds to the 430 largest set of communicating vehicles (or network nodes within a 431 vehicle), while the role of the second class is to build an IP relay 432 between two IP-subnet and two sub-IP networks. Finally, the last 433 class corresponds to vehicles being connected to Internet. Based on 434 these three classes, the paper defines six types of IP topologies 435 corresponding to V2V communication between two LVs in direct range, 436 or two LVs over a range extending vehicle, or V2I communication again 437 either directly via an IV, via another vehicles being IV, or via an 438 REV connecting to an IV. 440 Consider a simplified example of a vehicular train, where LV would be 441 in-wagon communicating nodes, REV would be inter-wagon relays, and IV 442 would be one node (e.g., train head) connected to Internet. Petrescu 443 et al. defined the required mechanisms to build subnetworks, and 444 evaluated the protocol time that is required to build such networks. 445 Although no simulation-based evaluation is conducted, the initial 446 analysis shows a long initial connection overhead, which should be 447 alleviated once the multi-wagon remains stable. However, this 448 approach does not describe what would happen in the case of a dynamic 449 multi-hop vehicular network, where such overhead would end up being 450 too high for V2V/V2I IP-based vehicular applications. 452 One other aspect described in their paper is to join the IP-layer 453 relaying with radio-link channels. Their paper proposes separating 454 different subnetworks in different WiFi/ITS-G5 channels, which could 455 be advertised by the REV. Accordingly, the overall interference 456 could be controlled within each subnetwork. This approach is similar 457 to multi-channel topology management proposals in multi-hop sensor 458 networks, yet adapted to an IP topology. 460 Their paper concludes that the generally complex multi-hop IP 461 vehicular topology could be represented by only six different 462 topologies, which could be further analyzed and optimized. A prefix 463 dissemination protocol is proposed for one of the topologies. 465 4.1.5. Mobile Internet Access in FleetNet 467 Bechler et al. described the FleetNet project approach to integrate 468 Internet Access in future vehicular networks [FleetNet]. The 469 FleetNet paper is probably one of the first papers to address this 470 aspect, and in many ways, introduces concepts that will be later used 471 in MIPv6 or other subsequent IP mobility management schemes. The 472 paper describes a V2I architecture consisting of Vehicles, Internet 473 Gateways (IGW), Proxy, and Corresponding Nodes (CN). Considering 474 that vehicular networks are required to use IPv6 addresses and also 475 the new wireless access technology ITS-G5 (new at that time), one of 476 the challenges is to bridge the two different networks (i.e., VANET 477 and IPv4/IPv6 Internet). Accordingly, the paper introduces a 478 Fleetnet Gateway (FGW), which allows vehicles in IPv6 to access the 479 IPv4 Internet and to bridge two types of networks and radio access 480 technologies. Another challenge is to keep the active addressing and 481 flows while vehicles move between FGWs. Accordingly, the paper 482 introduces a proxy node, a hybrid MIP Home Agent, which can re-route 483 flows to the new FGW as well as acting as a local IPv4-IPv6 NAT. 485 The authors from the paper mostly observed two issues that VANET 486 brings into the traditional IP mobility. First, VANET vehicles must 487 mostly be addressed from the Internet directly, and do not 488 specifically have a Home Network. Accordingly, VANET vehicles 489 require a globally (predefined) unique IPv6 address, while an IPv6 490 co-located care-of address (CCoA) is a newly allocated IPv6 address 491 every time a vehicle would enter a new IGW radio range. Second, 492 VANET links are known to be unreliable and short, and the extensive 493 use of IP tunneling on-the-air was judged not efficient. 494 Accordingly, the first major architecture innovation proposed in this 495 paper is to re-introduce a foreign agent (FA) in MIP located at the 496 IGW, so that the IP-tunneling would be kept in the back-end (between 497 a Proxy and an IGW) and not on the air. Second, the proxy has been 498 extended to build an IP tunnel and be connected to the right FA/IWG 499 for an IP flow using a global IPv6 address. 501 This is a pioneer paper, which contributed to changing MIP and led to 502 the new IPv6 architecture currently known as Proxy-MIP and the 503 subsequent DMM-PMIP. Three key messages can be yet kept in mind. 504 First, unlike the Internet, vehicles can be more prominently directly 505 addressed than the Internet traffic, and do not have a Home Network 506 in the traditional MIP sense. Second, IP tunneling should be avoided 507 as much as possible over the air. Third, the protocol-based mobility 508 (induced by the physical mobility) must be kept hidden to both the 509 vehicle and the correspondent node (CN). 511 4.1.6. A Layered Architecture for Vehicular DTNs 513 Soares et al. addressed the case of delay tolerant vehicular network 514 [Vehicular-DTN]. For delay tolerant or disruption tolerant networks, 515 rather than building a complex VANET-IP multi-hop route, vehicles may 516 also be used to carry packets closer to the destination or directly 517 to the destination. The authors built the well-accepted DTN Bundle 518 architecture and protocol to propose a VANET extension. They 519 introduced three types of VANET nodes: (i) terminal nodes (requiring 520 data), (ii) mobile nodes (carrying data along their routes), and 521 (iii) relay nodes (storing data at cross-roads of mobile nodes as 522 data hotspot). 524 The major innovation in this paper is to propose a DTN VANET 525 architecture separating a Control plane and a Data plane. The 526 authors claimed it to be designed to allow full freedom to select the 527 most appropriate technology, as well as allow to use out-of-band 528 communication for small Control plane packets and use DTN in-band for 529 the Data plane. The paper then further describes the different 530 layers from the Control and the Data planes. One interesting aspect 531 is the positioning of the Bundle layer between L2 and L3, rather than 532 above TCP/IP as for the DTN Bundle architecture. The authors claimed 533 this to be required first to keep bundle aggregation/disaggregation 534 transparent to IP, as well as to allow bundle transmission over 535 multiple access technologies (described as MAC/PHY layers in the 536 paper). 538 Although DTN architectures have evolved since the paper was written, 539 the Vehicular-DTN paper takes a different approach to IP mobility 540 management. An important aspect is to separate the Control plane 541 from the Data plane to allow a large flexibility in a Control plane 542 to coordinate a heterogeneous radio access technology (RAT) Data 543 plane. 545 4.2. V2I and V2V Internetworking Problem Statement 547 This section provides a problem statement of a vehicular network 548 architecture of IPv6-based V2I and V2V networking. The main focus in 549 this document is one-hop networking between a vehicle and an RSU or 550 between two neighboring vehicles. However, this document does not 551 address all multi-hop networking scenarios of vehicles and RSUs. 552 Also, the focus is on the network layer (i.e., IPv6 protocol stack) 553 rather than the MAC layer and the transport layer (e.g., TCP, UDP, 554 and SCTP). 556 Figure 1 shows an architecture for V2I and V2V networking in a road 557 network. The two RSUs (RSU1 and RSU2) are deployed in the road 558 network and are connected to a Vehicular Cloud through the Internet. 559 TCC is connected to the Vehicular Cloud and the two vehicles 560 (Vehicle1 and Vehicle2) are wirelessly connected to RSU1, and the 561 last vehicle (Vehicle3) is wirelessly connected to RSU2. Vehicle1 562 can communicate with Vehicle2 via V2V communication, and Vehicle2 can 563 communicate with Vehicle3 via V2V communication. Vehicle1 can 564 communicate with Vehicle3 via RSU1 and RSU2 via V2I communication. 566 *-------------* 567 * * .-------. 568 * Vehicular Cloud *<------>| TCC | 569 * * ._______. 570 *-------------* 571 ^ ^ 572 | | 573 | | 574 v v 575 .--------. .--------. 576 | RSU1 |<----------->| RSU2 | 577 .________. .________. 578 ^ ^ ^ 579 : : : 580 : : : 581 v v v 582 .--------. .--------. .--------. 583 |Vehicle1|=> |Vehicle2|=> |Vehicle3|=> 584 | |<....>| |<....>| | 585 .________. .________. .________. 587 <----> Wired Link <....> Wireless Link => Moving Direction 589 Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 591 In vehicular networks, unidirectional links exist and must be 592 considered. The control plane must be separated from data plane. 593 ID/Pseudonym change requires a lightweight DAD. IP tunneling should 594 be avoided. The mobility information of a mobile device (e.g., 595 vehicle), such as trajectory, position, speed, and direction, can be 596 used by the mobile device and infrastructure nodes (e.g., TCC and 597 RSU) for the accommodation of proactive protocols because it is 598 usually equipped with a GPS receiver. Vehicles can use the TCC as 599 its Home Network, so the TCC maintains the mobility information of 600 vehicles for location management. A vehicular network architecture 601 may be composed of three types of vehicles in Figure 1: Leaf Vehicle, 602 Range Extending Vehicle, and Internet Vehicle[Joint-IP-Networking]. 604 This section also discusses the internetworking between a vehicle's 605 moving network and an RSU's fixed network. 607 4.2.1. V2I-based Internetworking 609 As shown in Figure 2, the vehicle's moving network and the RSU's 610 fixed network are self-contained networks having multiple subnets and 611 having an edge router for the communication with another vehicle or 612 RSU. The method of prefix assignment for each subnet inside the 613 vehicle's mobile network and the RSU's fixed network is out of scope 614 for this document. Internetworking between two internal networks via 615 either V2I or V2V communication requires an exchange of network 616 prefix and other parameters. 618 The network parameter discovery collects networking information for 619 an IP communication between a vehicle and an RSU or between two 620 neighboring vehicles, such as link layer, MAC layer, and IP layer 621 information. The link layer information includes wireless link layer 622 parameters, such as wireless media (e.g., IEEE 802.11 OCB, LTE D2D, 623 Bluetooth, and LiFi) and a transmission power level. The MAC layer 624 information includes the MAC address of an external network interface 625 for the internetworking with another vehicle or RSU. The IP layer 626 information includes the IP address and prefix of an external network 627 interface for the internetworking with another vehicle or RSU. 629 (*)<..........>(*) 630 | | 2001:DB8:1:1::/64 631 .------------------------------. .---------------------------------. 632 | | | | | | 633 | .-------. .------. .-------. | | .-------. .------. .-------. | 634 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 635 | ._______. .______. ._______. | | ._______. .______. ._______. | 636 | ^ ^ ^ | | ^ ^ ^ | 637 | | | | | | | | | | 638 | v v v | | v v v | 639 | ---------------------------- | | ------------------------------- | 640 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 641 | | | | | | 642 | v | | v | 643 | .-------. .-------. | | .-------. .-------. .-------. | 644 | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | 645 | ._______. ._______. | | ._______. ._______. ._______. | 646 | ^ ^ | | ^ ^ ^ | 647 | | | | | | | | | 648 | v v | | v v v | 649 | ---------------------------- | | ------------------------------- | 650 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 651 .______________________________. ._________________________________. 652 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 654 <----> Wired Link <....> Wireless Link (*) Antenna 656 Figure 2: Internetworking between Vehicle Network and RSU Network 658 Once the network parameter discovery and prefix exchange operations 659 have been performed, packets can be transmitted between the vehicle's 660 moving network and the RSU's fixed network. DNS should be supported 661 to enable name resolution for hosts or servers residing either in the 662 vehicle's moving network or the RSU's fixed network. 664 Figure 2 shows internetworking between the vehicle's moving network 665 and the RSU's fixed network. There exists an internal network 666 (Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server 667 (RDNSS1), the two hosts (Host1 and Host2), and the two routers 668 (Router1 and Router2). There exists another internal network (Fixed 669 Network1) inside RSU1. RSU1 has the DNS Server (RDNSS2), one host 670 (Host3), the two routers (Router3 and Router4), and the collection of 671 servers (Server1 to ServerN) for various services in the road 672 networks, such as the emergency notification and navigation. 673 Vehicle1's Router1 (called mobile router) and RSU1's Router3 (called 674 fixed router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) 675 for I2V networking. 677 This document addresses the internetworking between the vehicle's 678 moving network and the RSU's fixed network in Figure 2 and the 679 required enhancement of IPv6 protocol suite for the V2I networking. 681 (*)<..........>(*) 682 | | 2001:DB8:1:1::/64 683 .------------------------------. .---------------------------------. 684 | | | | | | 685 | .-------. .------. .-------. | | .-------. .------. .-------. | 686 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 687 | ._______. .______. ._______. | | ._______. .______. ._______. | 688 | ^ ^ ^ | | ^ ^ ^ | 689 | | | | | | | | | | 690 | v v v | | v v v | 691 | ---------------------------- | | ------------------------------- | 692 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:30:1::/64 | 693 | | | | | | 694 | v | | v | 695 | .-------. .-------. | | .-------. .-------. | 696 | | Host2 | |Router2| | | |Router4| | Host4 | | 697 | ._______. ._______. | | ._______. ._______. | 698 | ^ ^ | | ^ ^ | 699 | | | | | | | | 700 | v v | | v v | 701 | ---------------------------- | | ------------------------------- | 702 | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | 703 .______________________________. ._________________________________. 704 Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) 706 <----> Wired Link <....> Wireless Link (*) Antenna 708 Figure 3: Internetworking between Two Vehicle Networks 710 4.2.2. V2V-based Internetworking 712 In Figure 3, the prefix assignment for each subnet inside each 713 vehicle's mobile network is done through a prefix delegation 714 protocol. 716 Figure 3 shows internetworking between the moving networks of two 717 neighboring vehicles. There exists an internal network (Moving 718 Network1) inside Vehicle1. Vehicle1 has the DNS Server (RDNSS1), the 719 two hosts (Host1 and Host2), and the two routers (Router1 and 720 Router2). There exists another internal network (Moving Network2) 721 inside Vehicle2. Vehicle2 has the DNS Server (RDNSS2), the two hosts 722 (Host3 and Host4), and the two routers (Router3 and Router4). 723 Vehicle1's Router1 (called mobile router) and Vehicle2's Router3 724 (called mobile router) use 2001:DB8:1:1::/64 for an external link 725 (e.g., DSRC) for V2V networking. 727 This document describes the internetworking between the moving 728 networks of two neighboring vehicles in Figure 3 and the required 729 enhancement of IPv6 protocol suite for the V2V networking. 731 5. Standardization Activities 733 This section surveys standard activities for vehicular networks in 734 standards developing organizations. 736 5.1. IEEE Guide for WAVE - Architecture 738 IEEE 1609 is a suite of standards for Wireless Access in Vehicular 739 Environments (WAVE) developed in the IEEE Vehicular Technology 740 Society (VTS). They define an architecture and a complementary 741 standardized set of services and interfaces that collectively enable 742 secure vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) 743 wireless communications. 745 IEEE 1609.0 provides a description of the WAVE system architecture 746 and operations (called WAVE reference model) [WAVE-1609.0]. The 747 reference model of a typical WAVE device includes two data plane 748 protocol stacks (sharing a common lower stack at the data link and 749 physical layers): (i) the standard Internet Protocol Version 6 (IPv6) 750 and (ii) the WAVE Short Message Protocol (WSMP) designed for 751 optimized operation in a wireless vehicular environment. WAVE Short 752 Messages (WSM) may be sent on any channel. IP traffic is only 753 allowed on service channels (SCHs), so as to offload high-volume IP 754 traffic from the control channel (CCH). 756 The Layer 2 protocol stack distinguishes between the two upper stacks 757 by the Ethertype field. Ethertype is a 2-octet field in the Logical 758 Link Control (LLC) header, used to identify the networking protocol 759 to be employed above the LLC protocol. In particular, it specifies 760 the use of two Ethertype values (i.e., two networking protocols), 761 such as IPv6 and WSMP. 763 Regarding the upper layers, while WAVE communications use standard 764 port numbers for IPv6-based protocols (e.g., TCP, UDP), they use a 765 Provider Service Identifier (PSID) as an identifier in the context of 766 WSMP. 768 5.2. IEEE Standard for WAVE - Networking Services 770 IEEE 1609.3 defines services operating at the network and transport 771 layers, in support of wireless connectivity among vehicle-based 772 devices, and between fixed roadside devices and vehicle-based devices 773 using the 5.9 GHz Dedicated Short-Range Communications/Wireless 774 Access in Vehicular Environments (DSRC/WAVE) mode [WAVE-1609.3]. 776 WAVE Networking Services represent layer 3 (networking) and layer 4 777 (transport) of the OSI communications stack. The purpose is then to 778 provide addressing and routing services within a WAVE system, 779 enabling multiple stacks of upper layers above WAVE Networking 780 Services and multiple lower layers beneath WAVE Networking Services. 781 Upper layer support includes in-vehicle applications offering safety 782 and convenience to users. 784 The WAVE standards support IPv6. IPv6 was selected over IPv4 because 785 IPv6 is expected to be a viable protocol into the foreseeable future. 786 Although not described in the WAVE standards, IPv4 has been tunnelled 787 over IPv6 in some WAVE trials. 789 The document provides requirements for IPv6 configuration, in 790 particular for the address setting. It specifies the details of the 791 different service primitives, among which is the WAVE Routing 792 Advertisement (WRA), part of the WAVE Service Advertisement (WSA). 793 When present, the WRA provides information about infrastructure 794 internetwork connectivity, allowing receiving devices to be 795 configured to participate in the advertised IPv6 network. For 796 example, an RSU can broadcast in the WRA portion of its WSA all the 797 information necessary for an OBU to access an application-service 798 available over IPv6 through the RSU as a router. This feature 799 removes the need for IPv6 Router Advertisement messages, which are 800 based on ICMPv6. 802 5.3. ETSI Intelligent Transport Systems: GeoNetwork-IPv6 804 ETSI published a standard specifying the transmission of IPv6 packets 805 over the ETSI GeoNetworking (GN) protocol [ETSI-GeoNetworking] 806 [ETSI-GeoNetwork-IP]. IPv6 packet transmission over GN is defined in 807 ETSI EN 302 636-6-1 [ETSI-GeoNetwork-IP] using a protocol adaptation 808 sub-layer called "GeoNetworking to IPv6 Adaptation Sub-Layer 809 (GN6ASL)". It enables an ITS station (ITS-S) running the GN protocol 810 and an IPv6-compliant protocol layer to: (i) exchange IPv6 packets 811 with other ITS-S; (ii) acquire globally routable IPv6 unicast 812 addresses and communicate with any IPv6 host located in the Internet 813 by having the direct connectivity to the Internet or via other relay 814 ITS stations; (iii) perform operations as a Mobile Router for network 815 mobility [RFC3963]. 817 The document introduces three types of virtual link, the first one 818 providing symmetric reachability by means of stable geographically 819 scoped boundaries and two others that can be used when the dynamic 820 definition of the broadcast domain is required. The combination of 821 these three types of virtual link in the same station allows running 822 the IPv6 ND protocol including SLAAC [RFC4862] as well as 823 distributing other IPv6 link-local multicast traffic and, at the same 824 time, reaching nodes that are outside specific geographic boundaries. 825 The IPv6 virtual link types are provided by the GN6ASL to IPv6 in the 826 form of virtual network interfaces. 828 The document also describes how to support bridging on top of the 829 GN6ASL, how IPv6 packets are encapsulated in GN packets and 830 delivered, as well as the support of IPv6 multicast and anycast 831 traffic, and neighbor discovery. For latency reasons, the standard 832 strongly recommends to use SLAAC for the address configuration. 834 Finally, the document includes the required operations to support the 835 change of pseudonym, e.g., changing IPv6 addresses when the GN 836 address is changed, in order to prevent attackers from tracking the 837 ITS-S. 839 5.4. ISO Intelligent Transport Systems: IPv6 over CALM 841 ISO published a standard specifying the IPv6 network protocols and 842 services for Communications Access for Land Mobiles (CALM) 843 [ISO-ITS-IPv6]. These services are necessary to support the global 844 reachability of ITS-S, the continuous Internet connectivity for ITS- 845 S, and the handover functionality required to maintain such 846 connectivity. This functionality also allows legacy devices to 847 effectively use an ITS-S as an access router to connect to the 848 Internet. Essentially, this specification describes how IPv6 is 849 configured to support ITS-S and provides the associated management 850 functionality. 852 The requirements apply to all types of nodes implementing IPv6: 853 personal, vehicle, roadside, or central node. The standard defines 854 IPv6 functional modules that are necessary in an IPv6 ITS-S, covering 855 IPv6 forwarding, interface between IPv6 and lower layers (e.g., LAN 856 interface), mobility management, and IPv6 security. It defines the 857 mechanisms to be used to configure the IPv6 address for static nodes 858 as well as for mobile nodes, while maintaining reachability from the 859 Internet. 861 6. IP Address Autoconfiguration 863 This section surveys IP address autoconfiguration schemes for 864 vehicular networks, and then discusses problem statement for IP 865 addressing and address autoconfiguration for vehicular networking. 867 6.1. Existing Protocols for Address Autoconfiguration 869 6.1.1. Automatic IP Address Configuration in VANETs 871 Fazio et al. proposed a vehicular address configuration called VAC 872 for automatic IP address configuration in Vehicular Ad Hoc Networks 873 (VANET) [Address-Autoconf]. VAC uses a distributed dynamic host 874 configuration protocol (DHCP). This scheme uses a leader playing a 875 role of a DHCP server within a cluster having connected vehicles 876 within a VANET. In a connected VANET, vehicles are connected with 877 each other within communication range. In this VANET, VAC 878 dynamically elects a leader-vehicle to quickly provide vehicles with 879 unique IP addresses. The leader-vehicle maintains updated 880 information on configured addresses in its connected VANET. It aims 881 at the reduction of the frequency of IP address reconfiguration due 882 to mobility. 884 VAC defines "SCOPE" to be a delimited geographic area within which IP 885 addresses are guaranteed to be unique. When a vehicle is allocated 886 an IP address from a leader-vehicle with a scope, it is guaranteed to 887 have a unique IP address while moving within the scope of the leader- 888 vehicle. If it moves out of the scope of the leader vehicle, it 889 needs to ask for another IP address from another leader-vehicle so 890 that its IP address can be unique within the scope of the new leader- 891 vehicle. This approach may allow for less frequent change of an IP 892 address than the address allocation from a fixed Internet gateway. 894 Thus, VAC can support a feasible address autoconfiguration for V2V 895 scenarios, but the overhead to guarantee the uniqueness of IP 896 addresses is not ignorable under high-speed mobility. 898 6.1.2. Using Lane/Position Information 900 Kato et al. proposed an IPv6 address assignment scheme using lane and 901 position information [Address-Assignment]. In this addressing 902 scheme, each lane of a road segment has a unique IPv6 prefix. When 903 it moves in a lane in a road segment, a vehicle autoconfigures its 904 IPv6 address with its MAC address and the prefix assigned to the 905 lane. A group of vehicles constructs a connected VANET within the 906 same subnet such that their IPv6 addresses have the same prefix. 907 Whenever it moves to another lane, a vehicle updates its IPv6 address 908 with the prefix corresponding to the new lane and also joins the 909 group corresponding to the lane. 911 However, this address autoconfiguration scheme may have too much 912 overhead when vehicles change their lanes frequently on the highway. 914 6.1.3. GeoSAC: Scalable Address Autoconfiguration 916 Baldessari et al. proposed an IPv6 scalable address autoconfiguration 917 scheme called GeoSAC for vehicular networks [GeoSAC]. GeoSAC uses 918 geographic networking concepts such that it combines the standard 919 IPv6 Neighbor Discovery (ND) and geographic routing functionality. 920 It matches geographically-scoped network partitions to individual 921 IPv6 multicast-capable links. In the standard IPv6, all nodes within 922 the same link must communicate with each other, but due to the 923 characteristics of wireless links, this concept of a link is not 924 clear in vehicular networks. GeoSAC defines a link as a geographic 925 area having a network partition. This geographic area can have a 926 connected VANET. Thus, vehicles within the same VANET in a specific 927 geographic area are regarded as staying in the same link, that is, an 928 IPv6 multicast link. 930 The GeoSAC paper identifies eight key requirements of IPv6 address 931 autoconfiguration for vehicular networks: (i) the configuration of 932 globally valid addresses, (ii) a low complexity for address 933 autoconfiguration, (iii) a minimum signaling overhead of address 934 autoconfiguration, (iv) the support of network mobility through 935 movement detection, (v) an efficient gateway selection from multiple 936 RSUs, (vi) a fully distributed address autoconfiguration for network 937 security, (vii) the authentication and integrity of signaling 938 messages, and (viii) the privacy protection of vehicles' users. 940 To support the proposed link concept, GeoSAC performs ad hoc routing 941 for geographic networking in a sub-IP layer called Car-to-Car (C2C) 942 NET. Vehicles within the same link can receive an IPv6 router 943 advertisement (RA) message transmitted by an RSU as a router, so they 944 can autoconfigure their IPv6 address based on the IPv6 prefix 945 contained in the RA and perform Duplicate Address Detection (DAD) to 946 verify the uniqueness of the autoconfigured IP address by the help of 947 the geographic routing within the link. 949 For location-based applications, to translate between a geographic 950 area and an IPv6 prefix belonging to an RSU, this paper takes 951 advantage of an extended DNS service, using GPS-based addressing and 952 routing along with geographic IPv6 prefix format [GeoSAC]. 954 Thus, GeoSAC can support the IPv6 link concept through geographic 955 routing within a specific geographic area. 957 6.1.4. Cross-layer Identities Management in ITS Stations 959 ITS and vehicular networks are built on the concept of an ITS station 960 (ITS-S) (e.g., vehicle and RSU), which is a common reference model 961 inspired from the Open Systems Interconnection (OSI) standard 962 [Identity-Management]. In vehicular networks using multiple access 963 network technologies through a cross-layer architecture, a vehicle 964 with an OBU may have multiple identities corresponding to the access 965 network interfaces. Wetterwald et al. conducted a comprehensive 966 study of the cross-layer identity management in vehicular networks 967 using multiple access network technologies, which constitutes a 968 fundamental element of the ITS architecture [Identity-Management]. 970 Besides considerations related to the case where ETSI GeoNetworking 971 [ETSI-GeoNetworking] is used, this paper analyzes the major 972 requirements and constraints weighing on the identities of ITS 973 stations, e.g., privacy and compatibility with safety applications 974 and communications. The concerns related to security and privacy of 975 the users need to be addressed for vehicular networking, considering 976 all the protocol layers. In other words, for security and privacy 977 constraints to be met, the IPv6 address of a vehicle should be 978 derived from a pseudonym-based MAC address and renewed simultaneously 979 with that changing MAC address. By dynamically changing its IPv6 980 address, an ITS-S can avoid being tracked by a hacker. However, 981 sometimes this address update cannot be applied; in some situations, 982 continuous knowledge about the surrounding vehicles is required. 984 Also, the ITS-S Identity Management paper defines a cross-layer 985 framework that fulfills the requirements on the identities of ITS 986 stations and analyzes systematically, layer by layer, how an ITS 987 station can be identified uniquely and safely, whether it is a moving 988 station (e.g., car or bus using temporary trusted pseudonyms) or a 989 static station (e.g., RSU and central station). This paper has been 990 applied to the specific case of the ETSI GeoNetworking as the network 991 layer, but an identical reasoning should be applied to IPv6 over 992 802.11 in Outside the Context of a Basic Service Set (OCB) mode now. 994 6.2. Problem Statement for IP Address Autoconfiguration 996 This section discusses IP addressing for the V2I and V2V networking. 997 There are two approaches for IPv6 addressing in vehicular networks. 998 The first is to use unique local IPv6 unicast addresses (ULAs) for 999 vehicular networks [RFC4193]. The other is to use global IPv6 1000 addresses for the interoperability with the Internet [RFC4291]. The 1001 former approach has been used sometimes by Mobile Ad Hoc Networks 1002 (MANET) for an isolated subnet. This approach can support the 1003 emergency notification service and navigation service in road 1004 networks. However, for general Internet services (e.g., email 1005 access, web surfing and entertainment services), the latter approach 1006 is required. 1008 For global IP addresses, there are two choices: a multi-link subnet 1009 approach for multiple RSUs and a single subnet approach per RSU. In 1010 the multi-link subnet approach, which is similar to ULA for MANET, 1011 RSUs play a role of layer-2 (L2) switches and the router 1012 interconnected with the RSUs is required. The router maintains the 1013 location of each vehicle belonging to an RSU for L2 switching. In 1014 the single subnet approach per RSU, which is similar to the legacy 1015 subnet in the Internet, each RSU plays the role of a (layer-3) 1016 router. 1018 6.2.1. Neighbor Discovery 1020 Neighbor Discovery (ND) [RFC4861] is a core part of the IPv6 protocol 1021 suite. This section discusses the need for modifying ND for use with 1022 V2I networking. The vehicles are moving fast within the 1023 communication coverage of an RSU. The external link between the 1024 vehicle and the RSU can be used for V2I networking, as shown in 1025 Figure 2. 1027 ND time-related parameters such as router lifetime and Neighbor 1028 Advertisement (NA) interval should be adjusted for high-speed 1029 vehicles and vehicle density. As vehicles move faster, the NA 1030 interval should decrease for the NA messages to reach the neighboring 1031 vehicles promptly. Also, as vehicle density is higher, the NA 1032 interval should increase for the NA messages to collide with other NA 1033 messages with lower collision probability. 1035 6.2.2. IP Address Autoconfiguration 1037 This section discusses IP address autoconfiguration for vehicular 1038 networking. For IP address autoconfiguration, high-speed vehicles 1039 should also be considered. For V2I networking, the legacy IPv6 1040 stateless address autoconfiguration [RFC4862], as shown in Figure 1, 1041 may not perform well. This is because vehicles can travel through 1042 the communication coverage of the RSU faster than the completion of 1043 address autoconfiguration (with Router Advertisement and Duplicate 1044 Address Detection (DAD) procedures). 1046 To mitigate the impact of vehicle speed on address configuration, the 1047 RSU can perform IP address autoconfiguration including the DAD 1048 proactively as an ND proxy on behalf of the vehicles. If vehicles 1049 periodically report their movement information (e.g., position, 1050 trajectory, speed, and direction) to TCC, TCC can coordinate the RSUs 1051 under its control for the proactive IP address configuration of the 1052 vehicles with the mobility information of the vehicles. DHCPv6 (or 1053 Stateless DHCPv6) can be used for the IP address autoconfiguration 1054 [RFC3315][RFC3736]. 1056 In the case of a single subnet per RSU, the delay to change IPv6 1057 address through DHCPv6 procedure is not suitable since vehicles move 1058 fast. Some modifications are required for the high-speed vehicles 1059 that quickly traverses the communication coverages of multiple RSUs. 1060 Some modifications are required for both stateless address 1061 autoconfiguration and DHCPv6. Mobile IPv6 (MIPv6) can be used for 1062 the fast update of a vehicle's care-of address for the current RSU to 1063 communicate with the vehicle [RFC6275]. 1065 For IP address autoconfiguration in V2V, vehicles can autoconfigure 1066 their address using prefixes for ULAs for vehicular networks 1067 [RFC4193]. 1069 High-speed mobility should be considered for a light-overhead address 1070 autoconfiguration. A cluster leader can have an IPv6 prefix 1071 [Address-Autoconf]. Each lane in a road segment can have an IPv6 1072 prefix [Address-Assignment]. A geographic region under the 1073 communication range of an RSU can have an IPv6 prefix [GeoSAC]. 1075 IPv6 ND should be extended to support the concept of a link for an 1076 IPv6 prefix in terms of multicast. Ad Hoc routing is required for 1077 the multicast in a connected VANET with the same IPv6 prefix 1078 [GeoSAC]. A rapid DAD should be supported to prevent or reduce IPv6 1079 address conflicts. 1081 In the ETSI GeoNetworking, for the sake of security and privacy, an 1082 ITS station (e.g., vehicle) can use pseudonyms for its network 1083 interface identities and the corresponding IPv6 addresses 1084 [Identity-Management]. For the continuity of an end-to-end transport 1085 session, the cross-layer identity management has to be performed 1086 carefully. 1088 7. Routing 1090 This section surveys routing in vehicular networks, and then 1091 discusses problem statement for routing in vehicular networks. 1093 7.1. Existing Routing Protocols 1095 7.1.1. Experimental Evaluation for IPv6 over GeoNet 1097 Tsukada et al. presented a work that aims at combining IPv6 1098 networking and a Car-to-Car Network routing protocol (called C2CNet) 1099 proposed by the Car2Car Communication Consortium (C2C-CC), which is 1100 an architecture using a geographic routing protocol 1101 [VANET-Geo-Routing]. In the C2C-CC architecture, the C2CNet layer is 1102 located between IPv6 and link layers. Thus, an IPv6 packet is 1103 delivered with an outer C2CNet header, which introduces the challenge 1104 of how to support the communication types defined in C2CNet in IPv6 1105 layer. 1107 The main goal of GeoNet is to enhance the C2C specifications and 1108 create a prototype software implementation interfacing with IPv6. 1109 C2CNet is specified in C2C-CC as a geographic routing protocol. 1111 In order to assess the performance of C2CNet, the authors measured 1112 the network performance with UDP and ICMPv6 traffic using iperf and 1113 ping6. The test results show that IPv6 over C2CNet does not have too 1114 much delay (less than 4ms with a single hop) and is feasible for 1115 vehicle communication. In the outdoor testbed, they developed 1116 AnaVANET to enable hop-by-hop performance measurement and position 1117 trace of the vehicles. 1119 The combination of IPv6 multicast and GeoBroadcast was implemented; 1120 however, the authors did not evaluate the performance with such a 1121 scenario. One of the reasons is that a sufficiently high number of 1122 receivers are necessary to properly evaluate multicast but 1123 experimental evaluation is limited in the number of vehicles (4 in 1124 this study). 1126 7.1.2. Location-Aided Gateway Advertisement and Discovery 1128 Abrougui et al. presented a gateway discovery scheme for VANET, 1129 called Location-Aided Gateway Advertisement and Discovery (LAGAD) 1130 mechanism[LAGAD]. LAGAD enables vehicles to route packets toward the 1131 closest gateway quickly by discovering nearby gateways. The major 1132 problem that LAGAD tackles is to determine the radius of 1133 advertisement zone of a gateway, which depends on the location and 1134 velocity of a vehicle. 1136 A gateway sends advertisement (GAdv) messages perodically to 1137 neighboring vehicles. When receiving a request message from a 1138 vehicle, the gateway replies to the source vehicle by a gateway reply 1139 (GRep) message. The GRep message contains the location information 1140 of the gateway and the subnet prefix of the gateway by which the 1141 source vehicle can send data packet via the gateway. The gateway 1142 sends GAdv messages through all vehicles within an advertisement zone 1143 built based on the velocity of the source vehicle. 1145 The source vehicle starts gateway discovery process by sending 1146 routing request packets. The routing request packet is encapsulated 1147 into a Gateway Reactive Discovery (GRD) packet or a GReq message to 1148 send to the surrounding vehicles. The GRD contains both discovery 1149 and routing information as well as the location and the velocity of 1150 the source vehicle. Meanwhile, the intermediate vehicles in an 1151 advertisement zone of the gateway forward packets sent from the 1152 source vehicle. The gateway continuously updates the advertisement 1153 zone whenever receiving a new data packet from the source vehicle. 1155 7.2. Routing Problem Statement 1157 IP address autoconfiguration should be modified to support the 1158 efficient networking. Due to network fragmentation, vehicles 1159 sometimes cannot communicate with each other temporarily. IPv6 ND 1160 should consider the temporary network fragmentation. IPv6 link 1161 concept can be supported by Geographic routing to connect vehicles 1162 with the same IPv6 prefix. 1164 The gateway advertisement and discovery process for routing in VANET 1165 can probably work when the density of vehicle in a road network is 1166 not sparse. A sparse vehicular network challenges the gateway 1167 discovery since network fragmentation interrupts the discovery 1168 process. 1170 8. Mobility Management 1172 This section surveys mobility management schemes in vehicular 1173 networks to support handover, and then discusses problem statement 1174 for mobility management in vehicular networks. 1176 8.1. Existing Protocols 1178 8.1.1. Vehicular Ad Hoc Networks with Network Fragmentation 1180 Chen et al. tackled the issue of network fragmentation in VANET 1181 environments [IP-Passing-Protocol]. The paper proposes a protocol 1182 that can postpone the time to release IP addresses to the DHCP server 1183 and select a faster way to get the vehicle's new IP address, when the 1184 vehicle density is low or the speeds of vehicles are varied. In such 1185 circumstances, the vehicle may not be able to communicate with the 1186 intended vehicle either directly or through multi-hop relays as a 1187 consequence of network fragmentation. 1189 The paper claims that although the existing IP passing and mobility 1190 solutions may reduce handoff delay, but they cannot work properly on 1191 VANET especially with network fragmentation. This is due to the fact 1192 that messages cannot be transmitted to the intended vehicles. When 1193 network fragmentation occurs, it may incur longer handoff latency and 1194 higher packet loss rate. The main goal of this study is to improve 1195 existing works by proposing an IP passing protocol for VANET with 1196 network fragmentation. 1198 The paper makes the assumption that on the highway, when a vehicle 1199 moves to a new subnet, the vehicle will receive broadcast packet from 1200 the target Base Station (BS), and then perform the handoff procedure. 1201 The handoff procedure includes two parts, such as the layer-2 handoff 1202 (new frequency channel) and the layer-3 handover (a new IP address). 1203 The handoff procedure contains movement detection, DAD procedure, and 1204 registration. In the case of IPv6, the DAD procedure is time 1205 consuming and may cause the link to be disconnected. 1207 This paper proposes another handoff mechanism. The handoff procedure 1208 contains the following phases. The first is the information 1209 collecting phase, where each mobile node (vehicle) will broadcast its 1210 own and its neighboring vehicles' locations, moving speeds, and 1211 directions periodically. The remaining phases are, the fast IP 1212 acquiring phase, the cooperation of vehicle phase, the make before 1213 break phase, and the route redirection phase. 1215 Simulations results show that for the proposed protocol, network 1216 fragmentation ratio incurs less impact. Vehicle speed and density 1217 has great impact on the performance of the IP passing protocol 1218 because vehicle speed and vehicle density will affect network 1219 fragmentation ratio. A longer IP lifetime can provide a vehicle with 1220 more chances to acquire its IP address through IP passing. 1221 Simulation results show that the proposed scheme can reduce IP 1222 acquisition time and packet loss rate, so extend IP lifetime with 1223 extra message overhead. 1225 8.1.2. Hybrid Centralized-Distributed Mobility Management 1227 Nguyen et al. proposed a hybrid centralized-distributed mobility 1228 management called H-DMM to support highly mobile vehicles [H-DMM]. 1229 Legacy mobility management systems are not suitable for high-speed 1230 scenarios because a registration delay is imposed proportional to the 1231 distance between a vehicle and its anchor network. H-DMM is designed 1232 to satisfy requirements such as service disruption time, end-to-end 1233 delay, packet delivery cost, and tunneling cost. 1235 H-DMM proposes a central node called central mobility anchor (CMA), 1236 which plays the role of a local mobility anchor (LMA) in PMIPv6. 1237 When it enters a mobile access router (MAR) as an access router, a 1238 vehicle obtains a prefix from the MAR (called MAR-prefix) according 1239 to the legacy DMM protocol. In addition, it obtains another prefix 1240 from the CMA (called LMA-prefix) for a PMIPv6 domain. Whenever it 1241 performs a handover between the subnets for two adjacent MARs, a 1242 vehicle keeps the LMA-prefix while obtaining a new prefix from the 1243 new MAR. For a new data exchange with a new CN, the vehicle can 1244 select the MAR-prefix or the LMA-prefix for its own source IPv6 1245 address. If the number of active prefixes is greater than a 1246 threshold, the vehicle uses the LMA-prefix-based IPv6 address as its 1247 source address. In addition, it can continue receiving data packets 1248 with the destination IPv6 addresses based on the previous prefixes 1249 through the legacy DMM protocol. 1251 Thus, H-DMM can support an efficient tunneling for a high-speed 1252 vehicle that moves fast across the subnets of two adjacent MARs. 1253 However, when H-DMM asks a vehicle to perform DAD for the uniqueness 1254 test of its configured IPv6 address in the subnet of the next MAR, 1255 the activation of the configured IPv6 address for networking will be 1256 delayed. This indicates that a proactive DAD by a network component 1257 (i.e., MAR and LMA) can shorten the address configuration delay of 1258 the current DAD triggered by a vehicle. 1260 8.1.3. Hybrid Architecture for Network Mobility Management 1262 Nguyen et al. proposed H-NEMO, a hybrid centralized-distributed 1263 mobility management scheme to handle IP mobility of moving vehicles 1264 [H-NEMO]. The standard Network Mobility (NEMO) basic support, which 1265 is a centralized scheme for network mobility, provides IP mobility 1266 for a group of users in a moving vehicle, but also inherits the 1267 drawbacks from Mobile IPv6, such as suboptimal routing and signaling 1268 overhead in nested scenarios as well as reliability and scalability 1269 issues. On the contrary, distributed schemes such as the recently 1270 proposed Distributed Mobility Management (DMM) locates the mobility 1271 anchor at the network edge and enables mobility support only to 1272 traffic flows that require such support. However, in high speed 1273 moving vehicles, DMM may suffer from high signaling cost and high 1274 handover latency. 1276 The proposed H-NEMO architecture is not designed for a specific 1277 wireless technology. Instead, it defines a general architecture and 1278 signaling protocol so that a mobile node can obtain mobility from 1279 fixed locations or mobile platforms, and also allows the use of DMM 1280 or Proxy Mobile IPv6 (PMIPv6), depending on flow characteristics and 1281 mobility patterns of the node. For IP addressing allocation, a 1282 mobile router (MR) or the mobile node (MN) connected to an MR in a 1283 NEMO obtain two sets of prefixes: one from the central mobility 1284 anchor and one from the mobile access router (MAR). In this way, the 1285 MR/MN may choose a more stable prefix for long-lived flows to be 1286 routed via the central mobility anchor and the MAR-prefix for short- 1287 lived flows to be routed following the DMM concept. The multi-hop 1288 scenario is considered under the concept of a nested-NEMO. 1290 Nguyen et al. did not provide simulation-based evaluations, but they 1291 provided an analytical evaluation that considered signaling and 1292 packet delivery costs, and showed that H-NEMO outperforms the 1293 previous proposals, which are either centralized or distributed ones 1294 with NEMO support. For some measures, such as the signaling cost, 1295 H-NEMO may be more costly than centralized schemes when the velocity 1296 of the node is increasing, but behaves better in terms of packet 1297 delivery cost and handover delay. 1299 8.1.4. NEMO-Enabled Localized Mobility Support 1301 In [NEMO-LMS], the authors proposed an architecture to enable IP 1302 mobility for moving networks using a network-based mobility scheme 1303 based on PMIPv6. In PMIPv6, only mobile terminals are provided with 1304 IP mobility. In contrast to from host-based mobility, PMIPv6 shifts 1305 the signaling to the network side, so that the mobile access gateway 1306 (MAG) is in charge of detecting connection/disconnection of the 1307 mobile node, upon which the signaling to the Local Mobility Anchor 1308 (LMA) is triggered to guarantee a stable IP addressing assignment 1309 when the mobile node performs handover to a new MAG. 1311 Soto et al. proposed NEMO support in PMIPv6 (N-PMIP). In this 1312 scheme, the functionality of the MAG is extended to the mobile router 1313 (MR), also called a mobile MAG (mMAG). The functionality of the 1314 mobile terminal remains unchanged, but it can receive an IPv6 prefix 1315 belonging to the PMIPv6 domain through the new functionality of the 1316 mMAG. Therefore, in N-PMIP, the mobile terminal connects to the MR 1317 as if it is connecting to a fixed MAG, and the MR connects to the 1318 fixed MAG using PMIPv6 signaling. When the mobile terminal roams to 1319 a new MAG or a new MR, the network forwards the packets through the 1320 LMA. Hence, N-PMIP defines an extended functionality in the LMA that 1321 enables a recursive lookup. First, it locates the binding entry 1322 corresponding to the mMAG. Next, it locates the entry corresponding 1323 to the fixed MAG, after which the LMA can encapsulate packets to the 1324 mMAG to which the mobile terminal is currently connected. 1326 The performance of N-PMIP was evaluated through simulations and 1327 compared to a NEMO+MIPv6+PMIPv6 scheme, with better results obtained 1328 in N-PMIP. The work did not consider the case of multi-hop 1329 connectivity in the vehicular scenario. In addition, since the MR 1330 should be a trusted entity in the PMIP domain, it requires specific 1331 security associations that were not addressed in [NEMO-LMS]. 1333 8.1.5. Network Mobility for Vehicular Ad Hoc Networks 1335 Chen et al. proposed a network mobility protocol to reduce handoff 1336 delay and maintain Internet connectivity to moving vehicles in a 1337 highway [NEMO-VANET]. In this work, vehicles can acquire IP 1338 addresses from other vehicles through V2V communications. At the 1339 time the vehicle goes out of the coverage of the base station, 1340 another vehicle may assist the roaming car to acquire a new IP 1341 address. Also, cars on the same or opposite lane are authorized to 1342 assist the vehicle to perform a pre-handoff. 1344 The authors assumed that the wireless connectivity is provided by 1345 WiFi and WiMAX access networks. Also, they considered scenarios in 1346 which a single vehicle, i.e., a bus, may need two mobile routers in 1347 order to have an effective pre-handoff procedure. Evaluations are 1348 performed through simulations and the comparison schemes are the 1349 standard NEMO Basic Support protocol and the fast NEMO Basic Support 1350 protocol. Authors did not mention applicability of the scheme in 1351 other scenarios such as in urban transport schemes. 1353 8.1.6. Performance Analysis of P-NEMO for ITS 1355 Lee et al. proposed P-NEMO, which is a PMIPv6-based IP mobility 1356 management scheme to maintain the Internet connectivity at the 1357 vehicle as a mobile network, and provides a make-before-break 1358 mechanism when vehicles switch to a new access network 1359 [PMIP-NEMO-Analysis]. Since the standard PMIPv6 only supports 1360 mobility for a single node, the solution in [PMIP-NEMO-Analysis] 1361 adapts the protocol to reduce the signaling when a local network is 1362 to be served by an in-vehicle mobile router. To achieve this, P-NEMO 1363 extends the binding update lists at both MAG and LMA, so that the 1364 mobile router (MR) can receive a home network prefix (HNP) and a 1365 mobile network prefix (MNP). The latter prefix enables mobility for 1366 the moving network, instead of a single node as in the standard 1367 PMIPv6. 1369 An additional feature is proposed by Lee et al. named fast P-NEMO 1370 (FP-NEMO). It adopts the fast handover approach standardized for 1371 PMIPv6 in [RFC5949] with both predictive and reactive modes. The 1372 difference of the proposed feature with the standard version is that 1373 by using the extensions provided by P-NEMO, the predictive 1374 transferring of the context from the old MAG to the new MAG also 1375 includes information for the moving network, i.e., the MNP. In that 1376 way, mobility support can be achieved not only for the mobile router, 1377 but also for mobile nodes traveling with the vehicle. 1379 The performance of P-NEMO and F-NEMO is evaluated through an 1380 analytical model that is compared only to the standard NEMO-BS. No 1381 comparison was provided to other schemes that enable network mobility 1382 in PMIPv6 domains, such as the one presented in [NEMO-LMS]. 1384 8.1.7. Integration of VANets and Fixed IP Networks 1386 Peng et al. proposed a novel mobility management scheme for 1387 integration of VANET and fixed IP networks [VNET-MM]. The proposed 1388 scheme deals with mobility of vehicles based on a street layout 1389 instead of a general two dimensional ad hoc network. This scheme 1390 makes use of the information provided by vehicular networks to reduce 1391 mobility management overhead. It allows multiple base stations that 1392 are close to a destination vehicle to discover the connection to the 1393 vehicle simultaneously, which leads to an improvement of the 1394 connectivity and data delivery ratio without redundant messages. The 1395 performance was assessed by using a road traffic simulator called 1396 SUMO (Simulation of Urban Mobility). 1398 8.1.8. SDN-based Mobility Management for 5G Networks 1400 Nguyen et al. extended their previous works on a vehicular adapted 1401 DMM considering a Software-Defined Networking (SDN) architecture 1402 [SDN-DMM]. On one hand, in their previous work, Nguyen et al. 1403 proposed DMM-PMIP and DMM-MIP architectures for VANET. The major 1404 innovation behind DMM is to distribute the Mobility Functions (MFs) 1405 through the network instead of concentrating them in one bottleneck 1406 MF, or in a hierarchically organized backbone of MFs. Highly mobile 1407 vehicular networks impose frequent IP route optimizations that lead 1408 to suboptimal routes (detours) between CN and vehicles. The 1409 suboptimality critically increases when there are nested or 1410 hierarchical MF nodes. Therefore, flattening the IP mobility 1411 architecture significantly reduces detours, as it is the role of the 1412 last MF to get the closest next MF (in most cases nearby). Yet, with 1413 an MF being distributed throughout the network, a Control plane 1414 becomes necessary in order to provide a solution for CN to address 1415 vehicles. The various solutions developed by Nguyen at al. not only 1416 showed the large benefit of a DMM approach for IPv6 mobility 1417 management, but also emphasized the critical role of an efficient 1418 Control plane. 1420 One the other hand, SDN has recently gained attention from the 1421 Internet Networking community due to its capacity to provide a 1422 significantly higher scalability of highly dynamic flows, which is 1423 required by future 5G dynamic networks In particular, SDN also 1424 suggests a strict separation between a Control plane (SDN-Controller) 1425 and a Data plane (OpenFlow Switches) based on the OpenFlow standard. 1426 Such an architecture has two advantages that are critical for IP 1427 mobility management in VANET. First, unlike traditional routing 1428 mechanisms, OpenFlow focuses on flows rather than optimized routes. 1429 Accordingly, they can optimize routing based on flows (grouping 1430 multiple flows in one route, or allowing one flow to have different 1431 routes), and can detect broken flows much earlier than the 1432 traditional networking solutions. Second, SDN controllers may 1433 dynamically reprogram (reconfigure) OpenFlow Switches (OFS) to always 1434 keep an optimal route between CN and a vehicular node. 1436 Nguyen et. al observed the mutual benefits IPv6 DMM could obtain from 1437 an SDN architecture, and then proposed an SDN-based DMM for VANET. 1438 In their proposed architecture, a PMIP-DMM is used, where MF is OFS 1439 for the Data plane, and one or more SDN controllers handle the 1440 Control plane. The evaluation and prototype in the paper prove that 1441 the proposed architecture can provide a higher scalability than the 1442 standard DMM. 1444 The SDN-DMM paper makes several observations leading to a strong 1445 suggestion that IP mobility management should be based on an SDN 1446 architecture. First, SDN will be integrated into future Internet and 1447 5G in the near future. Second, after separating the Identity and 1448 Routing addressing, IP mobility management further requires to 1449 separate the Control from the Data plane if it needs to remain 1450 scalable for VANET. Finally, Flow-based routing (in particular 1451 OpenFlow standard) will be required in future heterogeneous vehicular 1452 networks (e.g., multi-RAT and multi-protocol) and the SDN coupled 1453 with DMM provides a double benefit of dynamic flow detection/ 1454 reconfiguration and short(-er) route optimizations. 1456 8.1.9. IP Mobility for VANETs: Challenges and Solutions 1458 Cespedes et al. provided a survey of the challenges for NEMO Basic 1459 Support for VANET [Vehicular-IP-MM]. NEMO allows the management of a 1460 group of nodes (a mobile network) rather than a single node. 1461 However, although a vehicle and even a platoon of vehicles could be 1462 seen as a group of nodes, NEMO has not been designed considering the 1463 particularities of VANET. For example, NEMO builds a tunnel between 1464 an MR (on board of a vehicle) and its HA, which in a VANET context is 1465 suboptimal, for instance due to over-the-air tunneling cost. Also, a 1466 detour may be taken by the MR's HA, even if the CN is nearby. 1467 Furthermore, route optimization is needed when the MR moves to a new 1468 AR. 1470 Cespedes et al. first summarize the requirements of IP mobility 1471 management, such as reduced power at end-device, reduced handover 1472 event, reduced complexity, or reduced bandwidth consumption. VANET 1473 adds the following requirements, such as minimum signaling for route 1474 optimization (RO), per-flow separability, security and binding 1475 privacy protection, multi-homing, and switching HA. As observed, 1476 these provide several challenges to IP mobility and NEMO BS for 1477 VANET. 1479 Cespedes et al. then describe various optimization schemes available 1480 for NEMO BS. Considering a single hop connection to CN, one major 1481 optimization direction is to avoid the HA detour and reach the CN 1482 directly. In that direction, a few optimizations are proposed, such 1483 as creating an IP tunnel between the MR and the CR directly, creating 1484 an IP tunnel between the MR and a CR (rather than the HA), a 1485 delegation mechanism allowing visiting nodes to use MIPv6 directly 1486 rather than NEMO or finally intra-NEMO optimization for a direct path 1487 within NEMO bypassing HAs. 1489 Specific to VANET, multi-hop connection is possible to the fixed 1490 network. In that case, NEMO BS must be enhanced to avoid requiring 1491 that the path to immediate neighbors must pass by the respective HAs 1492 instead of directly. More specifically, two approaches are proposed 1493 to rely on VANET sub-IP multi-hop routing to hide a NEMO complex 1494 topology (e.g., Nested NEMO) and provide a direct route between two 1495 VANET nodes. Generally, one major challenge is security and privacy 1496 when opening a multi-hop route between a VANET and a CN. 1497 Heterogeneous multi-hop in a VANET (e.g., relying on various access 1498 technologies) corresponds to another challenge for NEMO BS as well. 1500 Cespedes et al. conclude their paper with an overview of critical 1501 research challenges, such as Anchor Point location, the optimized 1502 usage of geographic information at the subIP as well as at the IP 1503 level to improve NEMO BS, security and privacy, and the addressing 1504 allocation schema for NEMO. 1506 In summary, this paper illustrates that NEMO BS for VANET should 1507 avoid the HA detour as well as opening IP tunnels over the air. 1508 Also, NEMO BS could use geographic information for subIP routing when 1509 a direct link between vehicles is required to reach an AR, but also 1510 anticipate handovers and optimize ROs. From an addressing 1511 perspective, dynamic MNP assignments should be preferred, but should 1512 be secured in particular during binding update (BU). 1514 8.2. Problem Statement for Mobility-Management 1516 This section discusses an IP mobility support in V2I networking. In 1517 a single subnet per RSU, vehicles continually cross the communication 1518 coverages of adjacent RSUs. During this crossing, TCP/UDP sessions 1519 can be maintained through IP mobility support, such as MIPv6 1521 [RFC6275], Proxy MIPv6 [RFC5213][RFC5949], and Distributed Mobility 1522 Management (DMM) [RFC7333][RFC7429]. Since vehicles move fast along 1523 roadways, high speed should be enabled by the parameter configuration 1524 in the IP mobility management. With the periodic reports of the 1525 movement information from the vehicles, TCC can coordinate RSUs and 1526 other network compoments under its control for the proactive mobility 1527 management of the vehicles along the movement of the vehicles. 1529 To support the mobility of a vehicle's moving network, Network 1530 Mobility Basic Support Protocol (NEMO) can be used [RFC3963]. Like 1531 MIPv6, the high speed of vehicles should be considered for a 1532 parameter configuration in NEMO. 1534 Mobility Management (MM) solution design varies, depending on 1535 scenarios: highway vs. urban roadway. Hybrid schemes (NEMO + PMIP, 1536 PMIP + DMM, etc.) usually show better performance than pure schemes. 1537 Most schemes assume that IP address configuration is already set up. 1538 Most schemes have been tested only at either simulation or analytical 1539 level. SDN can be considered as a player in the MM solution. 1541 9. DNS Naming Service 1543 This section surveys and analyzes DNS naming service to translate a 1544 device's DNS name into the corresponding IP address, and then 1545 discusses problem statement for DNS naming service in vehicular 1546 networks. 1548 9.1. Existing Protocols 1550 9.1.1. Multicast DNS 1552 Multicast DNS (mDNS)[RFC6762] allows devices in one-hop communication 1553 range to resolve each other's DNS name into the corresponding IP 1554 address in multicast. Each device has a DNS resolver and a DNS 1555 server. The DNS resolver generates a DNS query for the device's 1556 application and the DNS server responds to a DNS query corresponding 1557 to its device's DNS name. 1559 9.1.2. DNS Name Autoconfiguration for IoT Devices 1561 DNS Name Autoconfiguration (DNSNA) [ID-DNSNA] proposes a DNS naming 1562 service for Internet-of-Things (IoT) devices in a large-scale 1563 network. 1565 The DNS naming service of DNSNA consists of four steps, such as DNS 1566 name generation, DNS name duplication detection, DNS name 1567 registration, and DNS name list retrieval. 1569 First, in DNS name generation, DNSNA allows each IoT device to 1570 generate its own DNS name with a DNS suffix (acquired from ND or 1571 DHCP) and its device information (e.g., vendor, model, and serial 1572 number). 1574 Second, in DNS name duplication detection, each device checks whether 1575 its generated DNS name is used by another IoT device in the same 1576 subnet. 1578 Third, in DNS name registration, each device registers its DNS name 1579 and the corresponding IPv6 address into a designated DNS server via a 1580 router. The router periodically collects DNS information of IoT 1581 devices in its the subnets corresponding ot its network interfaces. 1583 Last, in DNS name list retrieval, a user can retrieve the DNS name 1584 list of IoT devices available to the user through the designated DNS 1585 server. Once the user retrieves the list having a DNS name and the 1586 corresponding IP address(es), it can monitor and remote-control an 1587 IoT device. 1589 9.2. Problem Statement 1591 The DNS name resolution translates a DNS name into the corresponding 1592 IPv6 address through a recursive DNS server (RDNSS) within the 1593 vehicle's moving network and DNS servers in the Internet 1594 [RFC1034][RFC1035], which are located outside the VANET. The RDNSSes 1595 can be advertised by RA DNS Option or DHCP DNS Option into the 1596 subnets within the vehicle's moving network. 1598 mDNS is designed for a small ad hoc network with wireless/wired one- 1599 hop communication range. If it is used in a vehicle's mobile network 1600 having multiple subnets, mDNS cannot effectively work in such a 1601 multi-hop network. This is because the DNS query message of each DNS 1602 resolver should be multicasted into the whole mobile network, leading 1603 to a large volume of DNS traffic. 1605 DNSNA is designed for a large-scale network with multiple subnets. 1606 If it is used in a vehicle's mobile network having multiple subnets, 1607 DNSNA can effectively work in such a multi-hop network. This is 1608 because the DNS query message of each DNS resolver should be 1609 unicasted to the designated DNS server. 1611 DNSNA allows each host (e.g., in-vehicle device and a user's mobile 1612 device) within a vehicle's moving network to generate its unique DNS 1613 name and registers it into a DNS server within the vehicle's moving 1614 network [ID-DNSNA]. With Vehicle Identification Number (VIN), a 1615 unique DNS suffix can be constructed as a DNS domain for the 1616 vehicle's moving network. Each host can generate its DNS name and 1617 register it into the local RDNSS in the vehicle's moving network. 1619 10. Service Discovery 1621 This section surveys and analyzes service discovery to translate a 1622 required service into an IP address of a device to provide such a 1623 service, and then discusses problem statement for service discovery 1624 in vehicular networks. 1626 10.1. Existing Protocols 1628 10.1.1. mDNS-based Service Discovery 1630 As a popular existing service discovery protocol, DNS-based Service 1631 Discovery (DNS-SD) [RFC6763] with mDNS [RFC6762] provides service 1632 discovery. 1634 DNS-SD uses a DNS service (SRV) resource record (RR) [RFC2782] to 1635 support the service discovery of services provided by a device or 1636 server. An SRV RR contains a service instance name, consisting of an 1637 instance name (i.e., device), a service name, a transport layer 1638 protocol, a domain name, the corresponding port number, and the DNS 1639 name of the device eligible for the requested service. With this 1640 DNS-SD, a host can search for a service instance with the SRV RR to 1641 discover a list of devices corresponding to the searched service 1642 type. 1644 10.1.2. ND-based Service Discovery 1646 Vehicular ND [ID-Vehicular-ND] proposes an extension of IPv6 ND for 1647 the prefix and service discovery. Vehicles and RSUs can announce the 1648 network prefixes and services in their internal network via ND 1649 messages containing ND options with the prefix and service 1650 information. Since it does not need any additional service discovery 1651 protocol in the application layer, this ND-based approach can provide 1652 vehicles and RSUs with the rapid discovery of the network prefixes 1653 and services. 1655 10.2. Problem Statement 1657 Vehicles need to discover services (e.g., road condition 1658 notification, navigation service, and entertainment) provided by 1659 infrastructure nodes in a fixed network via RSU, as shown in 1660 Figure 2. During the passing of an intersection or road segment with 1661 an RSU, vehicles should perform this service discovery quickly. For 1662 these purposes, service discovery should be performed quickly. 1664 mDNS-based DNS-SD [RFC6762][RFC6763] can be used for service 1665 discovery between vehicles or between a vehicle and an RSU by using a 1666 multicast protocol, the service discovery requires a nonnegligible 1667 service delay due to service discovery. This is because the service 1668 discovery message should traverse the mobile network or fixed network 1669 through multicasting. This may hinder the prompt service usage of 1670 the vehicles from the fixed network via RSU. 1672 One feasible approach is a piggyback service discovery during the 1673 prefix exchange of network prefixes for the networking between a 1674 vehicle's moving network and an RSU's fixed network. That is, the 1675 message of the prefix exchange can include service information, such 1676 as each service's IP address, transport layer protocol, and port 1677 number. The Vehicular ND [ID-Vehicular-ND] can support this approach 1678 efficiently. 1680 11. Security and Privacy 1682 This section surveys security and privacy in vehicular networks, and 1683 then discusses problem statement for security and privacy in 1684 vehicular networks. 1686 11.1. Existing Protocols 1688 11.1.1. Securing Vehicular IPv6 Communications 1690 Fernandez et al. proposed a secure vehicular IPv6 communication 1691 scheme using Internet Key Exchange version 2 (IKEv2) and Internet 1692 Protocol Security (IPsec) [Securing-VCOMM]. This scheme aims at the 1693 security support for IPv6 Network Mobility (NEMO) for in-vehicle 1694 devices inside a vehicle via a Mobile Router (MR). An MR has 1695 multiple wireless interfaces, such as 3G, IEEE 802.11p, WiFi, and 1696 WiMAX. The proposed architecture consists of Vehicle ITS Station 1697 (Vehicle ITS-S), Roadside ITS Station (Roadside ITS-S), and Central 1698 ITS Station (Central ITS-S). Vehicle ITS-S is a vehicle having a 1699 mobile Network along with an MR. Roadside ITS-S is an RSU as a 1700 gateway to connect vehicular networks to the Internet. Central ITS-S 1701 is a TCC as a Home Agent (HA) for the location management of vehicles 1702 having their MR. 1704 The proposed secure vehicular IPv6 communication scheme sets up IPsec 1705 secure sessions for control and data traffic between the MR in a 1706 Vehicle ITS-S and the HA in a Central ITS-S. Roadside ITS-S plays a 1707 role of an Access Router (AR) for Vehicle ITS-S's MR to provide the 1708 Internet connectivity for Vehicle ITS-S via wireless interfaces, such 1709 as IEEE 802.11p, WiFi, and WiMAX. In the case where Roadside ITS-S 1710 is not available to Vehicle ITS-S, Vehicle ITS-S communicates with 1711 Central ITS-S via cellular networks (e.g., 3G). The secure 1712 communication scheme enhances the NEMO protocol that interworks with 1713 IKEv2 and IPsec in network mobility in vehicular networks. 1715 The authors implemented their scheme and evaluated its performance in 1716 a real testbed. This testbed supports two wireless networks, such as 1717 IEEE 802.11p and 3G. The in-vehicle devices (or hosts) in Vehicle 1718 ITS-S are connected to an MR of Vehicle ITS-S via IEEE 802.11g. The 1719 test results show that their scheme supports promising secure IPv6 1720 communications with a low impact on communication performance. 1722 11.1.2. Authentication and Access Control 1724 Moustafa et al. proposed a security scheme providing authentication, 1725 authorization, and accounting (AAA) services in vehicular networks 1726 [VNET-AAA]. This secuirty scheme aims at the support of safe and 1727 reliable data services in vehicular networks. It authenticates 1728 vehicles as mobile clients to use the network access and various 1729 services that are provided by service providers. Also, it ensures a 1730 confidential data transfer between communicating parties (e.g., 1731 vehicle and infrastructure node) by using IEEE 802.11i (i.e., WPA2) 1732 for secure layer-2 links. 1734 The authors proposed a vehicular network architecture consisting of 1735 three entities, such as Access network, Wireless mobile ad hoc 1736 networks (MANETs), and Access Points (APs). Access network is the 1737 fixed network infrastructure forming the back-end of the 1738 architecture. Wireless MANETs are constructed by moving vehicles 1739 forming the front-end of the architecture. APs is the IEEE 802.11 1740 WLAN infrastructure forming the interface between the front-end and 1741 back-end of the architecture. 1743 For AAA services, the proposed architecture uses a Kerberos 1744 authentication model that authenticates vehicles at the entry point 1745 with the AP and also authorizes them to the access of various 1746 services. Since vehicles are authenticated by a Kerberos 1747 Authentication Server (AS) only once, the proposed security scheme 1748 can minimize the load on the AS and reduce the delay imposed by layer 1749 2 using IEEE 802.11i. 1751 11.2. Problem Statement 1753 Security and privacy are paramount in the V2I and V2V networking in 1754 vehicular networks. Only authorized vehicles should be allowed to 1755 use the V2I and V2V networking. Also, in-vehicle devices and mobile 1756 devices in a vehicle need to communicate with other in-vehicle 1757 devices and mobile devices in another vehicle, and other servers in 1758 an RSU in a secure way. 1760 A Vehicle Identification Number (VIN) and a user certificate along 1761 with in-vehicle device's identifier generation can be used to 1762 authenticate a vehicle and the user through a road infrastructure 1763 node, such as an RSU connected to an authentication server in TCC. 1764 Transport Layer Security (TLS) certificates can also be used for 1765 secure vehicle communications. 1767 For secure V2I communication, the secure channel between a mobile 1768 router in a vehicle and a fixed router in an RSU should be 1769 established, as shown in Figure 2. Also, for secure V2V 1770 communication, the secure channel between a mobile router in a 1771 vehicle and a mobile router in another vehicle should be established, 1772 as shown in Figure 3. 1774 The security for vehicular networks should provide vehicles with AAA 1775 services in an efficient way. It should consider not only horizontal 1776 handover, but also vertical handover since vehicles have multiple 1777 wireless interfaces. 1779 To prevent an adversary from tracking a vehicle by with its MAC 1780 address or IPv6 address, each vehicle should periodically update its 1781 MAC address and the corresponding IPv6 address as suggested in 1782 [RFC4086][RFC4941]. Such an update of the MAC and IPv6 addresses 1783 should not interrupt the communications between a vehicle and an RSU. 1785 12. Discussions 1787 12.1. Summary and Analysis 1789 This document surveyed state-of-the-arts technologies for IP-based 1790 vehicular networks, such as IP address autoconfiguration, vehicular 1791 network architecture, vehicular network routing, and mobility 1792 management. 1794 Through this survey, it is learned that IPv6-based vehicular 1795 networking can be well-aligned with IEEE WAVE standards for various 1796 vehicular network applications, such as driving safety, efficient 1797 driving, and entertainment. However, since the IEEE WAVE standards 1798 do not recommend to use the IPv6 ND protocol for the communication 1799 efficiency under high-speed mobility, it is necessary to adapt the ND 1800 for vehicular networks with such high-speed mobility. 1802 The concept of a link in IPv6 does not match that of a link in VANET 1803 because of the physical separation of communication ranges of 1804 vehicles in a connected VANET. That is, in a linear topology of 1805 three vehicles (Vehicle-1, Vehicle-2, and Vehicle-3), Vehicle-1 and 1806 Vehicle-2 can communicate directly with each other. Vehicle-2 and 1807 Vehicle-3 can communicate directly with each other. However, 1808 Vehicle-1 and Vehicle-3 cannot communicate directly with each other 1809 due to the out-of-communication range. For the link in IPv6, all of 1810 three vehicles are on a link, so they can communicate directly with 1811 each other. On the other hand, in VANET, this on-link communication 1812 concept is not valid in VANET. Thus, the IPv6 ND should be extended 1813 to support this multi-link subnet of a connected VANET through either 1814 ND proxy or VANET routing. 1816 For IP-based networking, IP address autoconfiguration is a 1817 prerequisite function. Since vehicles can communicate intermittently 1818 with TCC via RSUs through V2I communications, TCC can play a role of 1819 a DHCP server to allocate unique IPv6 addresses to the vehicles. 1820 This centralized address allocation can remove the delay of the DAD 1821 procedure for testing the uniqueness of IPv6 addresses. 1823 For routing and mobility management, most of vehicles are equipped 1824 with a GPS navigator as a dedicated navigation system or a smartphone 1825 App. With this GPS navigator, vehicles can share their current 1826 position and trajectory (i.e., navigation path) with TCC. TCC can 1827 predict the future positions of the vehicles with their mobility 1828 information (i.e., the current position, speed, direction, and 1829 trajectory). With the prediction of the vehicle mobility, TCC 1830 supports RSUs to perform data packet routing and handover 1831 proactively. 1833 12.2. Deployment Issues 1835 Some automobile companies (e.g., BMW and Hyundai) started to use 1836 Ethernet for a vehicle's internal network instead of the traditional 1837 Contoller Area Network (CAN) for high-speed interconnectivity among 1838 electronic control units. With this trend, the IP-based vehicular 1839 networking in this document will be popular in near future. 1841 Self-driving technologies are being developed by many automobile 1842 companies (e.g., Tesla, BMW, GM, Honda, Toyota, and Hyundai) and IT 1843 companies (e.g., Google and Apple). Since they require high-speed 1844 interaction among vehicles, infrastructure nodes (e.g., RSU), and 1845 cloud, IP-based networking will be mandatory. 1847 Therefore, key component technologies for the IP-based vehicular 1848 networking need to be developed for future demands along with an 1849 efficient vehicular network architecture. 1851 13. Security Considerations 1853 Section 11 discusses security and privacy for IP-based vehicular 1854 networking. 1856 The security for key components in vehicular networking, such as IP 1857 address autoconfiguration, routing, mobility management, DNS naming 1858 service, and service discovery, needs to be analyzed in depth. 1860 14. Informative References 1862 [Address-Assignment] 1863 Kato, T., Kadowaki, K., Koita, T., and K. Sato, "Routing 1864 and Address Assignment using Lane/Position Information in 1865 a Vehicular Ad-hoc Network", IEEE Asia-Pacific Services 1866 Computing Conference, December 2008. 1868 [Address-Autoconf] 1869 Fazio, M., Palazzi, C., Das, S., and M. Gerla, "Automatic 1870 IP Address Configuration in VANETs", ACM International 1871 Workshop on Vehicular Inter-Networking, September 2016. 1873 [CA-Cuise-Control] 1874 California Partners for Advanced Transportation Technology 1875 (PATH), "Cooperative Adaptive Cruise Control", [Online] 1876 Available: 1877 http://www.path.berkeley.edu/research/automated-and- 1878 connected-vehicles/cooperative-adaptive-cruise-control, 1879 2017. 1881 [CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A 1882 Framework of Context-Awareness Safety Driving in Vehicular 1883 Networks", International Workshop on Device Centric Cloud 1884 (DC2), March 2016. 1886 [ETSI-GeoNetwork-IP] 1887 ETSI Technical Committee Intelligent Transport Systems, 1888 "Intelligent Transport Systems (ITS); Vehicular 1889 Communications; GeoNetworking; Part 6: Internet 1890 Integration; Sub-part 1: Transmission of IPv6 Packets over 1891 GeoNetworking Protocols", ETSI EN 302 636-6-1, October 1892 2013. 1894 [ETSI-GeoNetworking] 1895 ETSI Technical Committee Intelligent Transport Systems, 1896 "Intelligent Transport Systems (ITS); Vehicular 1897 Communications; GeoNetworking; Part 4: Geographical 1898 addressing and forwarding for point-to-point and point-to- 1899 multipoint communications; Sub-part 1: Media-Independent 1900 Functionality", ETSI EN 302 636-4-1, May 2014. 1902 [FirstNet] 1903 U.S. National Telecommunications and Information 1904 Administration (NTIA), "First Responder Network Authority 1905 (FirstNet)", [Online] 1906 Available: https://www.firstnet.gov/, 2012. 1908 [FleetNet] 1909 Bechler, M., Franz, W., and L. Wolf, "Mobile Internet 1910 Access in FleetNet", 13th Fachtagung Kommunikation in 1911 verteilten Systemen, February 2001. 1913 [GeoSAC] Baldessari, R., Bernardos, C., and M. Calderon, "GeoSAC - 1914 Scalable Address Autoconfiguration for VANET Using 1915 Geographic Networking Concepts", IEEE International 1916 Symposium on Personal, Indoor and Mobile Radio 1917 Communications, September 2008. 1919 [H-DMM] Nguyen, T. and C. Bonnet, "A Hybrid Centralized- 1920 Distributed Mobility Management for Supporting Highly 1921 Mobile Users", IEEE International Conference on 1922 Communications, June 2015. 1924 [H-NEMO] Nguyen, T. and C. Bonnet, "A Hybrid Centralized- 1925 Distributed Mobility Management Architecture for Network 1926 Mobility", IEEE International Symposium on a World of 1927 Wireless, Mobile and Multimedia Networks, June 2015. 1929 [ID-DNSNA] 1930 Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 1931 Autoconfiguration for Internet of Things Devices", draft- 1932 jeong-ipwave-iot-dns-autoconf-01 (work in progress), 1933 October 2017. 1935 [ID-Vehicular-ND] 1936 Jeong, J., Ed., Shen, Y., Jo, Y., Jeong, J., and J. Lee, 1937 "IPv6 Neighbor Discovery for Prefix and Service Discovery 1938 in Vehicular Networks", draft-jeong-ipwave-vehicular- 1939 neighbor-discovery-01 (work in progress), October 2017. 1941 [Identity-Management] 1942 Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer 1943 Identities Management in ITS Stations", The 10th 1944 International Conference on ITS Telecommunications, 1945 November 2010. 1947 [IEEE-802.11-OCB] 1948 IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium 1949 Access Control (MAC) and Physical Layer (PHY) 1950 Specifications", IEEE Std 802.11-2012, February 2012. 1952 [IEEE-802.11p] 1953 IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium 1954 Access Control (MAC) and Physical Layer (PHY) 1955 Specifications - Amendment 6: Wireless Access in Vehicular 1956 Environments", IEEE Std 802.11p-2010, June 2010. 1958 [IP-Passing-Protocol] 1959 Chen, Y., Hsu, C., and W. Yi, "An IP Passing Protocol for 1960 Vehicular Ad Hoc Networks with Network Fragmentation", 1961 Elsevier Computers & Mathematics with Applications, 1962 January 2012. 1964 [IPv6-WAVE] 1965 Baccelli, E., Clausen, T., and R. Wakikawa, "IPv6 1966 Operation for WAVE - Wireless Access in Vehicular 1967 Environments", IEEE Vehicular Networking Conference, 1968 December 2010. 1970 [ISO-ITS-IPv6] 1971 ISO/TC 204, "Intelligent Transport Systems - 1972 Communications Access for Land Mobiles (CALM) - IPv6 1973 Networking", ISO 21210:2012, June 2012. 1975 [Joint-IP-Networking] 1976 Petrescu, A., Boc, M., and C. Ibars, "Joint IP Networking 1977 and Radio Architecture for Vehicular Networks", 1978 11th International Conference on ITS Telecommunications, 1979 August 2011. 1981 [LAGAD] Abrougui, K., Boukerche, A., and R. Pazzi, "Location-Aided 1982 Gateway Advertisement and Discovery Protocol for VANets", 1983 IEEE Transactions on Vehicular Technology, Vol. 59, No. 8, 1984 October 2010. 1986 [NEMO-LMS] 1987 Soto, I., Bernardos, C., Calderon, M., Banchs, A., and A. 1988 Azcorra, "NEMO-Enabled Localized Mobility Support for 1989 Internet Access in Automotive Scenarios", 1990 IEEE Communications Magazine, May 2009. 1992 [NEMO-VANET] 1993 Chen, Y., Hsu, C., and C. Cheng, "Network Mobility 1994 Protocol for Vehicular Ad Hoc Networks", 1995 Wiley International Journal of Communication Systems, 1996 November 2014. 1998 [PMIP-NEMO-Analysis] 1999 Lee, J., Ernst, T., and N. Chilamkurti, "Performance 2000 Analysis of PMIPv6-Based Network Mobility for Intelligent 2001 Transportation Systems", IEEE Transactions on Vehicular 2002 Technology, January 2012. 2004 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 2005 RFC 1034, November 1987. 2007 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 2008 Specification", RFC 1035, November 1987. 2010 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2011 (IPv6) Specification", RFC 2460, December 1998. 2013 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2014 Specifying the Location of Services (DNS SRV)", RFC 2782, 2015 February 2000. 2017 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2018 C., and M. Carney, "Dynamic Host Configuration Protocol 2019 for IPv6 (DHCPv6)", RFC 3315, July 2003. 2021 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 2022 (DHCP) Service for IPv6", RFC 3736, April 2004. 2024 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 2025 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 2026 RFC 3963, January 2005. 2028 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2029 "Randomness Requirements for Security", RFC 4086, June 2030 2005. 2032 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2033 Addresses", RFC 4193, October 2005. 2035 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2036 Architecture", RFC 4291, February 2006. 2038 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2039 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 2040 September 2007. 2042 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2043 Address Autoconfiguration", RFC 4862, September 2007. 2045 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 2046 Extensions for Stateless Address Autoconfiguration in 2047 IPv6", RFC 4941, September 2007. 2049 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 2050 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 2052 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 2053 Hoc Networks", RFC 5889, September 2010. 2055 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 2056 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 2057 September 2010. 2059 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 2060 Support in IPv6", RFC 6275, July 2011. 2062 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2063 February 2013. 2065 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2066 Discovery", RFC 6763, February 2013. 2068 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 2069 "Requirements for Distributed Mobility Management", 2070 RFC 7333, August 2014. 2072 [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. 2073 Bernardos, "Distributed Mobility Management: Current 2074 Practices and Gap Analysis", RFC 7429, January 2015. 2076 [SAINT] Jeong, J., Jeong, H., Lee, E., Oh, T., and D. Du, "SAINT: 2077 Self-Adaptive Interactive Navigation Tool for Cloud-Based 2078 Vehicular Traffic Optimization", IEEE Transactions on 2079 Vehicular Technology, Vol. 65, No. 6, June 2016. 2081 [SAINTplus] 2082 Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D. 2083 Du, "SAINT+: Self-Adaptive Interactive Navigation Tool+ 2084 for Emergency Service Delivery Optimization", 2085 IEEE Transactions on Intelligent Transportation Systems, 2086 June 2017. 2088 [SANA] Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation 2089 Application for Pedestrian Protection in Vehicular 2090 Networks", Springer Lecture Notes in Computer Science 2091 (LNCS), Vol. 9502, December 2015. 2093 [SDN-DMM] Nguyen, T., Bonnet, C., and J. Harri, "SDN-based 2094 Distributed Mobility Management for 5G Networks", 2095 IEEE Wireless Communications and Networking Conference, 2096 April 2016. 2098 [Securing-VCOMM] 2099 Fernandez, P., Santa, J., Bernal, F., and A. Skarmeta, 2100 "Securing Vehicular IPv6 Communications", 2101 IEEE Transactions on Dependable and Secure Computing, 2102 January 2016. 2104 [Truck-Platooning] 2105 California Partners for Advanced Transportation Technology 2106 (PATH), "Automated Truck Platooning", [Online] Available: 2107 http://www.path.berkeley.edu/research/automated-and- 2108 connected-vehicles/truck-platooning, 2017. 2110 [VANET-Geo-Routing] 2111 Tsukada, M., Jemaa, I., Menouar, H., Zhang, W., Goleva, 2112 M., and T. Ernst, "Experimental Evaluation for IPv6 over 2113 VANET Geographic Routing", IEEE International Wireless 2114 Communications and Mobile Computing Conference, June 2010. 2116 [Vehicular-DTN] 2117 Soares, V., Farahmand, F., and J. Rodrigues, "A Layered 2118 Architecture for Vehicular Delay-Tolerant Networks", 2119 IEEE Symposium on Computers and Communications, July 2009. 2121 [Vehicular-IP-MM] 2122 Cespedes, S., Shen, X., and C. Lazo, "IP Mobility 2123 Management for Vehicular Communication Networks: 2124 Challenges and Solutions", IEEE Communications Magazine, 2125 May 2011. 2127 [VIP-WAVE] 2128 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 2129 Feasibility of IP Communications in 802.11p Vehicular 2130 Networks", IEEE Transactions on Intelligent Transportation 2131 Systems, March 2013. 2133 [VNET-AAA] 2134 Moustafa, H., Bourdon, G., and Y. Gourhant, "Providing 2135 Authentication and Access Control in Vehicular Network 2136 Environment", IFIP TC-11 International Information 2137 Security Conference, May 2006. 2139 [VNET-Framework] 2140 Jemaa, I., Shagdar, O., and T. Ernst, "A Framework for IP 2141 and non-IP Multicast Services for Vehicular Networks", 2142 Third International Conference on the Network of the 2143 Future, November 2012. 2145 [VNET-MM] Peng, Y. and J. Chang, "A Novel Mobility Management Scheme 2146 for Integration of Vehicular Ad Hoc Networks and Fixed IP 2147 Networks", Springer Mobile Networks and Applications, 2148 February 2010. 2150 [WAVE-1609.0] 2151 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 2152 in Vehicular Environments (WAVE) - Architecture", IEEE Std 2153 1609.0-2013, March 2014. 2155 [WAVE-1609.2] 2156 IEEE 1609 Working Group, "IEEE Standard for Wireless 2157 Access in Vehicular Environments - Security Services for 2158 Applications and Management Messages", IEEE Std 2159 1609.2-2016, March 2016. 2161 [WAVE-1609.3] 2162 IEEE 1609 Working Group, "IEEE Standard for Wireless 2163 Access in Vehicular Environments (WAVE) - Networking 2164 Services", IEEE Std 1609.3-2016, April 2016. 2166 [WAVE-1609.4] 2167 IEEE 1609 Working Group, "IEEE Standard for Wireless 2168 Access in Vehicular Environments (WAVE) - Multi-Channel 2169 Operation", IEEE Std 1609.4-2016, March 2016. 2171 Appendix A. Acknowledgments 2173 This work was supported by Basic Science Research Program through the 2174 National Research Foundation of Korea (NRF) funded by the Ministry of 2175 Education (2017R1D1A1B03035885). This work was supported in part by 2176 the Global Research Laboratory Program (2013K1A1A2A02078326) through 2177 NRF and the DGIST Research and Development Program (CPS Global 2178 Center) funded by the Ministry of Science and ICT. This work was 2179 supported in part by the French research project DataTweet (ANR-13- 2180 INFR-0008) and in part by the HIGHTS project funded by the European 2181 Commission I (636537-H2020). 2183 Appendix B. Contributors 2185 This document is a group work of IPWAVE working group, greatly 2186 benefiting from inputs and texts by Rex Buddenberg (Naval 2187 Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest 2188 University of Technology and Economics), Jose Santa Lozanoi 2189 (Universidad of Murcia), Richard Roy (MIT), and Francois Simon 2190 (Pilot). The authors sincerely appreciate their contributions. 2192 The following are co-authors of this document: 2194 Nabil Benamar 2195 Department of Computer Sciences 2196 High School of Technology of Meknes 2197 Moulay Ismail University 2198 Morocco 2200 Phone: +212 6 70 83 22 36 2201 EMail: benamar73@gmail.com 2203 Sandra Cespedes 2204 Department of Electrical Engineering 2205 Universidad de Chile 2206 Av. Tupper 2007, Of. 504 2207 Santiago, 8370451 2208 Chile 2210 Phone: +56 2 29784093 2211 EMail: scespede@niclabs.cl 2213 Jerome Haerri 2214 Communication Systems Department 2215 EURECOM 2216 Sophia-Antipolis 2217 France 2219 Phone: +33 4 93 00 81 34 2220 EMail: jerome.haerri@eurecom.fr 2222 Dapeng Liu 2223 Alibaba 2224 Beijing, Beijing 100022 2225 China 2227 Phone: +86 13911788933 2228 EMail: max.ldp@alibaba-inc.com 2230 Tae (Tom) Oh 2231 Department of Information Sciences and Technologies 2232 Rochester Institute of Technology 2233 One Lomb Memorial Drive 2234 Rochester, NY 14623-5603 2235 USA 2237 Phone: +1 585 475 7642 2238 EMail: Tom.Oh@rit.edu 2240 Charles E. Perkins 2241 Futurewei Inc. 2242 2330 Central Expressway 2243 Santa Clara, CA 95050 2244 USA 2246 Phone: +1 408 330 4586 2247 EMail: charliep@computer.org 2249 Alex Petrescu 2250 CEA, LIST 2251 CEA Saclay 2252 Gif-sur-Yvette, Ile-de-France 91190 2253 France 2255 Phone: +33169089223 2256 EMail: Alexandre.Petrescu@cea.fr 2258 Yiwen Chris Shen 2259 Department of Computer Science & Engineering 2260 Sungkyunkwan University 2261 2066 Seobu-Ro, Jangan-Gu 2262 Suwon, Gyeonggi-Do 16419 2263 Republic of Korea 2265 Phone: +82 31 299 4106 2266 Fax: +82 31 290 7996 2267 EMail: chrisshen@skku.edu 2268 URI: http://iotlab.skku.edu/people-chris-shen.php 2270 Michelle Wetterwald 2271 FBConsulting 2272 21, Route de Luxembourg 2273 Wasserbillig, Luxembourg L-6633 2274 Luxembourg 2276 EMail: Michelle.Wetterwald@gmail.com 2278 Appendix C. Changes from draft-ietf-ipwave-vehicular-networking-00 2280 The following changes are made from draft-ietf-ipwave-vehicular- 2281 networking-00: 2283 o In Section 4.2, The mobility information of a mobile device (e.g., 2284 vehicle) can be used by the mobile device and infrastructure nodes 2285 (e.g., TCC and RSU) for enhancing protocol performance. 2287 o In Section 4.2, Vehicles can use the TCC as its Home Network, so 2288 the TCC maintains the mobility information of vehicles for 2289 location management. 2291 o The contents are clarified with typo corrections and rephrasing. 2293 Author's Address 2294 Jaehoon Paul Jeong (editor) 2295 Department of Software 2296 Sungkyunkwan University 2297 2066 Seobu-Ro, Jangan-Gu 2298 Suwon, Gyeonggi-Do 16419 2299 Republic of Korea 2301 Phone: +82 31 299 4957 2302 Fax: +82 31 290 7996 2303 EMail: pauljeong@skku.edu 2304 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php