idnits 2.17.1 draft-jeong-ipwave-vehicular-networking-survey-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 5, 2017) is 2517 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5889 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jeong 3 Internet-Draft Sungkyunkwan University 4 Intended status: Standards Track S. Cespedes 5 Expires: December 7, 2017 Universidad de Chile 6 N. Benamar 7 Moulay Ismail University 8 J. Haerri 9 EURECOM 10 M. Wetterwald 11 FBConsulting 12 June 5, 2017 14 Survey on IP-based Vehicular Networking for Intelligent Transportation 15 Systems 16 draft-jeong-ipwave-vehicular-networking-survey-03 18 Abstract 20 This document surveys the IP-based vehicular networks, which are 21 considered a key component of Intelligent Transportation Systems 22 (ITS). The main topics of vehicular networking are vehicle-to- 23 vehicle (V2V), vehicle-to-infrastructure (V2I), and infrastructure- 24 to-vehicle (I2V) networking. This document deals with some critical 25 aspects in vehicular networking, such as IP address 26 autoconfiguration, vehicular network architecture, routing, mobility 27 management, and security. This document also surveys standard 28 activities for vehicular networks. Finally, this document summarizes 29 and analyzes the previous research activities that use IPv4 or IPv6 30 for vehicular networking. 32 Status of This Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on December 7, 2017. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 74 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 4. IP Address Autoconfiguration . . . . . . . . . . . . . . . . . 5 76 4.1. Automatic IP Address Configuration in VANETs . . . . . . . 5 77 4.2. Routing and Address Assignment using Lane/Position 78 Information in a Vehicular Ad-hoc Network . . . . . . . . 6 79 4.3. GeoSAC: Scalable Address Autoconfiguration for VANET 80 Using Geographic Networking Concepts . . . . . . . . . . . 6 81 4.4. Cross-layer Identities Management in ITS Stations . . . . 7 82 4.5. Key Observations . . . . . . . . . . . . . . . . . . . . . 8 83 5. Vehicular Network Architecture . . . . . . . . . . . . . . . . 8 84 5.1. VIP-WAVE: On the Feasibility of IP Communications in 85 802.11p Vehicular Networks . . . . . . . . . . . . . . . . 8 86 5.2. IPv6 Operation for WAVE - Wireless Access in Vehicular 87 Environments . . . . . . . . . . . . . . . . . . . . . . . 9 88 5.3. A Framework for IP and non-IP Multicast Services for 89 Vehicular Networks . . . . . . . . . . . . . . . . . . . . 10 90 5.4. Joint IP Networking and Radio Architecture for 91 Vehicular Networks . . . . . . . . . . . . . . . . . . . . 11 92 5.5. Mobile Internet Access in FleetNet . . . . . . . . . . . . 12 93 5.6. A Layered Architecture for Vehicular Delay-Tolerant 94 Networks . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 5.7. Key Observations . . . . . . . . . . . . . . . . . . . . . 13 96 6. Vehicular Network Routing . . . . . . . . . . . . . . . . . . 14 97 6.1. An IP Passing Protocol for Vehicular Ad Hoc Networks 98 with Network Fragmentation . . . . . . . . . . . . . . . . 14 99 6.2. Experimental Evaluation for IPv6 over VANET Geographic 100 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 15 101 6.3. Key Observations . . . . . . . . . . . . . . . . . . . . . 15 102 7. Mobility Management in Vehicular Networks . . . . . . . . . . 15 103 7.1. A Hybrid Centralized-Distributed Mobility Management 104 for Supporting Highly Mobile Users . . . . . . . . . . . . 16 105 7.2. A Hybrid Centralized-Distributed Mobility Management 106 Architecture for Network Mobility . . . . . . . . . . . . 16 107 7.3. NEMO-Enabled Localized Mobility Support for Internet 108 Access in Automotive Scenarios . . . . . . . . . . . . . . 17 109 7.4. Network Mobility Protocol for Vehicular Ad Hoc Networks . 18 110 7.5. Performance Analysis of PMIPv6-Based Network MObility 111 for Intelligent Transportation Systems . . . . . . . . . . 18 112 7.6. A Novel Mobility Management Scheme for Integration of 113 Vehicular Ad Hoc Networks and Fixed IP Networks . . . . . 19 114 7.7. SDN-based Distributed Mobility Management for 5G 115 Networks . . . . . . . . . . . . . . . . . . . . . . . . . 19 116 7.8. IP Mobility Management for Vehicular Communication 117 Networks: Challenges and Solutions . . . . . . . . . . . . 20 118 7.9. Key Observations . . . . . . . . . . . . . . . . . . . . . 22 119 8. Vehicular Network Security . . . . . . . . . . . . . . . . . . 22 120 8.1. Securing Vehicular IPv6 Communications . . . . . . . . . . 22 121 8.2. Providing Authentication and Access Control in 122 Vehicular Network Environment . . . . . . . . . . . . . . 23 123 8.3. Key Observations . . . . . . . . . . . . . . . . . . . . . 23 124 9. Standard Activities for Vehicular Networks . . . . . . . . . . 23 125 9.1. IEEE Guide for Wireless Access in Vehicular 126 Environments (WAVE) - Architecture . . . . . . . . . . . . 24 127 9.2. IEEE Standard for Wireless Access in Vehicular 128 Environments (WAVE) - Networking Services . . . . . . . . 24 129 9.3. ETSI Intelligent Transport Systems: Transmission of 130 IPv6 Packets over GeoNetworking Protocols . . . . . . . . 25 131 9.4. ISO Intelligent Transport Systems: Communications 132 Access for Land Mobiles (CALM) Using IPv6 Networking . . . 26 133 10. Summary and Analysis . . . . . . . . . . . . . . . . . . . . . 26 134 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 135 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 136 13. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 28 137 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 138 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 139 15.1. Normative References . . . . . . . . . . . . . . . . . . . 28 140 15.2. Informative References . . . . . . . . . . . . . . . . . . 28 141 Appendix A. Changes from 142 draft-jeong-ipwave-vehicular-networking-survey-02 . . 33 144 1. Introduction 146 Nowadays vehicular networks have been focused on the driving safety, 147 driving efficiency, and infotainment in road networks. For the 148 driving safety, IEEE has standardized Wireless Access in Vehicular 149 Environments (WAVE) standards, such as IEEE 802.11p [IEEE-802.11p], 150 IEEE 1609.2 [WAVE-1609.2], IEEE 1609.3 [WAVE-1609.3], and IEEE 1609.4 151 [WAVE-1609.4]. Note that IEEE 802.11p has been finalized as IEEE 152 802.11 Outside the Context of a Basic Service Set (OCB) 153 [IEEE-802.11-OCB] in 2012. Along with these WAVE standards, IPv6 and 154 Mobile IP protocols (e.g., MIPv4 and MIPv6) can be extended to 155 vehicular networks. 157 This document surveys the IP-based vehicular networking for 158 Intelligent Transportation Systems (ITS), such as IP address 159 autoconfiguration, vehicular network architecture, vehicular network 160 routing (for multi-hop V2V, V2I, and I2V), mobility management, and 161 security. This document summarizes and analyzes the previous 162 research activities using IPv4 or IPv6 for vehicular networking. 164 Based on the survey of this document, we can specify the requirements 165 for vehicular networks for the intended purposes, such as the driving 166 safety, driving efficiency, and infotainment. As a consequence, this 167 will make it possible to design the network architecture and 168 protocols for vehicular networking. 170 2. Requirements Language 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 176 3. Terminology 178 This document defines the following new terms: 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. An 183 RSU is deployed either at an intersection or in a road segment. 185 o On-Board Unit (OBU): A node that has a DSRC device for wireless 186 communications with other OBUs and RSUs. An OBU is mounted on a 187 vehicle. It is assumed that a Global Positioning System (GPS) is 188 included in a vehicle with an OBU for efficient navigation. 190 o Traffic Control Center (TCC): A node that maintains road 191 infrastructure information (e.g., RSUs and traffic signals), 192 vehicular traffic statistics (e.g., average vehicle speed and 193 vehicle inter-arrival time per road segment), and vehicle 194 information (e.g., a vehicle's identifier, position, direction, 195 speed, and trajectory as a navigation path). TCC is included in a 196 vehicular cloud for vehicular networks. Exemplary functions of 197 TCC include the management of evacuation routes, the monitoring of 198 pedestrians and bike traffic, the monitoring of real-time transit 199 operations, and real-time responsive traffic signal systems. 200 Thus, TCC is the nerve center of most freeway management sytems 201 such that data is collected, processed, and fused with other 202 operational and control data, and is also synthesized to produce 203 "information" distributed to stakeholders, other agencies, and 204 traveling public. TCC is called Traffic Management Center (TMC) 205 in the US. 207 4. IP Address Autoconfiguration 209 This section surveys IP address autoconfiguration schemes for 210 vehicular networks. 212 4.1. Automatic IP Address Configuration in VANETs 214 Fazio et al. proposed a vehicular address configuration called VAC 215 for automatic IP address configuration in Vehicular Ad Hoc Networks 216 (VANET) [Address-Autoconf]. VAC uses a distributed dynamic host 217 configuration protocol (DHCP). This scheme uses a leader playing a 218 role of a DHCP server within a cluster having connected vehicles 219 within a VANET. In a connected VANET, vehicles are connected with 220 each other with the communication range. In this VANET, VAC 221 dynamically elects a leader-vehicle to quickly provide vehicles with 222 unique IP addresses. The leader-vehicle maintains updated 223 information on configured addressed in its connected VANET. It aims 224 at the reduction of the frequency of IP address reconfiguration due 225 to mobility. 227 VAC defines the concept of SCOPE as a delimited geographic area where 228 IP addresses are guaranteed to be unique. When it is allocated an IP 229 address from a leader-vehicle with a scope, a vehicle is guaranteed 230 to have a unique IP address while moving within the scope of the 231 leader-vehicle. If it moves out of the scope of the leader vehicle, 232 it needs to ask for another IP address from another leader-vehicle so 233 that its IP address can be unique within the scope of the new leader- 234 vehicle. This approach may allow for less frequent change of an IP 235 address than the address allocation from a fixed Internet gateway. 237 Thus, VAC can support a feasible address autoconfiguration for V2V 238 scenarios, but the overhead to guarantee the uniqueness of IP 239 addresses is not ignorable under high-speed mobility. 241 4.2. Routing and Address Assignment using Lane/Position Information in 242 a Vehicular Ad-hoc Network 244 Kato et al. proposed an IPv6 address assignment scheme using lane and 245 position information [Address-Assignment]. In this addressing 246 scheme, each lane of a road segment has a unique IPv6 prefix. When 247 it moves in a lane in a road segment, a vehicle autoconfigures its 248 IPv6 address with its MAC address and the prefix assigned to the 249 lane. A group of vehicles constructs a connected VANET within the 250 same subnet such that their IPv6 addresses have the same prefix. 251 Whenever it moves to another lane, a vehicle updates its IPv6 address 252 with the prefix corresponding to the new lane and also joins the 253 group corresponding to the lane. 255 However, this address autoconfiguration scheme may have much overhead 256 in the case where vehicles change their lanes frequently in highway. 258 4.3. GeoSAC: Scalable Address Autoconfiguration for VANET Using 259 Geographic Networking Concepts 261 Baldessari et al. proposed an IPv6 scalable address autoconfiguration 262 scheme called GeoSAC for vehicular networks [GeoSAC]. GeoSAC uses 263 geographic networking concepts such that it combines the standard 264 IPv6 Neighbor Discovery (ND) and geographic routing functionality. 265 It matches geographically-scoped network partitions to individual 266 IPv6 multicast-capable links. In the standard IPv6, all nodes within 267 the same link must communicate with each other, but due to the 268 characteristics of wireless links, this concept of a link is not 269 clear in vehicular networks. GeoSAC defines a link as a geographic 270 area having a network partition. This geographic area can have a 271 connected VANET. Thus, vehicles within the same VANET in a specific 272 geographic area are regarded as staying in the same link, that is, an 273 IPv6 multicast link. 275 This paper identifies four key requirements of IPv6 address 276 autoconfiguration for vehicular networks: (i) the configuration of 277 globally valid addresses, (ii) a low complexity for address 278 autoconfiguration, (iii) a minimum signaling overhead of address 279 autoconfiguration, (iv) the support of network mobility through 280 movement detection, (v) an efficient gateway selection from multiple 281 RSUs, (vi) a fully distributed address autoconfiguration for network 282 security, (vii) the authentication and integrity of signaling 283 messages, and (viii) the privacy protection of vehicles' users. 285 To support the proposed link concept, GeoSAC performs ad hoc routing 286 for geographic networking in a sub-IP layer called Car-to-Car (C2C) 287 NET. Vehicles within the same link can receive an IPv6 router 288 advertisement (RA) message transmitted by an RSU as a router, so they 289 can autoconfigure their IPv6 address based on the IPv6 prefix 290 contained in the RA and perform Duplicate Address Detection (DAD) to 291 verify the uniqueness of the autoconfigured IP address by the help of 292 the geographic routing within the link. 294 For location-based applications, to translate between a geographic 295 area and an IPv6 prefix belonging to an RSU, this paper takes 296 advantage of an extended DNS service, using GPS-based addressing and 297 routing along with geographic IPv6 prefix format [GeoSAC]. 299 Thus, GeoSAC can support the IPv6 link concept through geographic 300 routing within a specific geographic area. 302 4.4. Cross-layer Identities Management in ITS Stations 304 ITS and vehicular networks are built on the concept of an ITS station 305 (e.g., vehicle and RSU), which is a common reference model inspired 306 from the Open Systems Interconnection (OSI) standard 307 [Identities-Management]. In vehicular networks using multiple access 308 network technologies through a cross-layer architecture, a vehicle 309 with an OBU may have multiple identities corresponding to the access 310 network interfaces. Wetterwald et al. conducted a comprehensive 311 study of the cross-layer identity management in vehicular networks 312 using multiple access network technologies, which constitutes a 313 fundamental element of the ITS architecture [Identities-Management]. 315 Besides considerations related to the case where ETSI GeoNetworking 316 [ETSI-GeoNetworking] is used, this paper analyzes the major 317 requirements and constraints weighing on the identities of ITS 318 stations, e.g., privacy and compatibility with safety applications 319 and communications. The concerns related to security and privacy of 320 the users need to be addressed for vehicular networking, considering 321 all the protocol layers simultaneously. In other words, for security 322 and privacy constraints to be met, the IPv6 address of a vehicle 323 should be derived from a pseudonym-based MAC address and renewed 324 simultaneously with that changing MAC address. This dynamically 325 changing IPv6 address can prevent the ITS station from being tracked 326 by a hacker. However, this address renewal cannot be applied at any 327 time because in some situations, the continuity of the knowledge 328 about the surrounding vehicles is required. 330 Also, this paper defines a cross-layer framework that fulfills the 331 requirements on the identities of ITS stations and analyzes 332 systematically, layer by layer, how an ITS station can be identified 333 uniquely and safely, whether it is a moving station (e.g., car and 334 bus using temporary trusted pseudonyms) or a static station (e.g., 335 RSU and central station). This paper has been applied to the 336 specific case of the ETSI GeoNetworking as the network layer, but an 337 identical reasoning should be applied to IPv6 over 802.11 in Outside 338 the Context of a Basic Service Set (OCB) mode now. 340 4.5. Key Observations 342 High-speed mobility should be considered for a light-overhead address 343 autoconfiguration. A cluster leader can have an IPv6 prefix 344 [Address-Autoconf]. Each lane in a road segment can have an IPv6 345 prefix [Address-Assignment]. A geographic region under the 346 communication range of an RSU can have an IPv6 prefix [GeoSAC]. 348 IPv6 ND should be extended to support the concept of a link for an 349 IPv6 prefix in terms of multicast. Ad Hoc routing is required for 350 the multicast in a connected VANET with the same IPv6 prefix 351 [GeoSAC]. A rapid DAD should be supported to prevent or reduce IPv6 352 address conflicts. 354 In the ETSI GeoNetworking, for the sake of security and privacy, an 355 ITS station (e.g., vehicle) can use pseudonyms for its network 356 interface identities and the corresponding IPv6 addresses 357 [Identities-Management]. For the continuity of an end-to-end 358 transport session, the cross-layer identity management should be 359 performed carefully. 361 5. Vehicular Network Architecture 363 This section surveys vehicular network architectures based on IP 364 along with various radio technologies. 366 5.1. VIP-WAVE: On the Feasibility of IP Communications in 802.11p 367 Vehicular Networks 369 Cespedes et al. proposed a vehicular IP in WAVE called VIP-WAVE for 370 I2V and V2I networking [VIP-WAVE]. IEEE 1609.3 specified a WAVE 371 stack of protocols and includes IPv6 as a network layer protocol in 372 data plane [WAVE-1609.3]. The standard WAVE does not support DAD, 373 seamless communications for Internet services, and multi-hop 374 communications between a vehicle and an infrastructure node (e.g., 375 RSU). To overcome these limitations of the standard WAVE for IP- 376 based networking, VIP-WAVE enhances the standard WAVE by the 377 following three schemes: (i) an efficient mechanism for the IPv6 378 address assignment and DAD, (ii) on-demand IP mobility based on Proxy 379 Mobile IPv6 (PMIPv6), and (iii) one-hop and two-hop communications 380 for I2V and V2I networking. 382 In WAVE, IPv6 ND protocol is not recommended due to the overhead of 383 ND against the timely and prompt communications in vehicular 384 networking. By WAVE service advertisement (WAS) management frame, an 385 RSU can provide vehicles with IP configuration information (e.g., 386 IPv6 prefix, prefix length, gateway, router lifetime, and DNS server) 387 without using ND. However, WAVE devices may support readdressing to 388 provide pseudonymity, so a MAC address of a vehicle may be changed or 389 randomly generated. This update of the MAC address may lead to the 390 collision of an IPv6 address based on a MAC address, so VIP-WAVE 391 includes a light-weight, on-demand ND to perform DAD. 393 For IP-based Internet services, VIP-WAVE adopts PMIPv6 for network- 394 based mobility management in vehicular networks. In VIP-WAVE, RSU 395 plays a role of mobile anchor gateway (MAG) of PMIPv6, which performs 396 the detection of a vehicle as a mobile node in a PMIPv6 domain and 397 registers it into the PMIPv6 domain. For PMIPv6 operations, VIP-WAVE 398 requires a central node called local mobility anchor (LMA), which 399 assigns IPv6 prefixes to vehicles as mobile nodes and forwards data 400 packets to the vehicles moving in the coverage of RSUs under its 401 control through tunnels between MAGs and itself. 403 For two-hop communications between a vehicle and an RSU, VIP-WAVE 404 allows an intermediate vehicle between the vehicle and the RSU to 405 play a role of a packet relay for the vehicle. When it becomes out 406 of the communication range of an RSU, a vehicle searches for another 407 vehicle as a packet relay by sending a relay service announcement. 408 When it receives this relay service announcement and is within the 409 communication range of an RSU, another vehicle registers itself into 410 the RSU as a relay and notifies the relay-requester vehicle of a 411 relay maintenance announcement. 413 Thus, VIP-WAVE is a good candidate for I2V and V2I networking, 414 supporting an enhanced ND, handover, and two-hop communications 415 through a relay. 417 5.2. IPv6 Operation for WAVE - Wireless Access in Vehicular 418 Environments 420 Baccelli et al. provided an analysis of the operation of IPv6 as it 421 has been described by the IEEE WAVE standards 1609 [IPv6-WAVE]. 422 Although the main focus of WAVE has been the timely delivery of 423 safety related information, the deployment of IP-based infotainment 424 applications is also considered. Thus, in order to support 425 infotainment traffic, WAVE supports IPv6 and transport protocols such 426 as TCP and UDP. 428 In the analysis provided in [IPv6-WAVE], it is identified that the 429 IEEE 1609.3 standard's recommendations for IPv6 operation over WAVE 430 are rather minimal. Protocols on which the operation of IPv6 relies 431 for IP address configuration and IP-to-link-layer address translation 432 (e.g., IPv6 NP protocol) are not recommended in the standard. 434 Additionally, IPv6 works under certain assumptions for the link model 435 that do not necessarily hold in WAVE. For instance, IPv6 assumes 436 symmetry in the connectivity among neighboring interfaces. However, 437 interference and different levels of transmission power may cause 438 unidirectional links to appear in a WAVE link model. Also, in an 439 IPv6 link, it is assumed that all interfaces which are configured 440 with the same subnet prefix are on the same IP link. Hence, there is 441 a relationship between link and prefix, besides the different scopes 442 that are expected from the link-local and global types of IPv6 443 addresses. Such a relationship does not hold in a WAVE link model 444 due to node mobility and highly dynamic topology. 446 Baccellii et al. concluded that the use of the standard IPv6 protocol 447 stack, as the IEEE 1609 family of specifications stipulate, is not 448 sufficient. Instead, the addressing assignment should follow 449 considerations for ad-hoc link models, defined in [RFC5889], which 450 are similar to the characteristics of the WAVE link model. In terms 451 of the supporting protocols for IPv6, such as ND, DHCP, or stateless 452 auto-configuration, which rely largely on multicast, do not operate 453 as expected in the case where the WAVE link model does not have the 454 same behavior expected for multicast IPv6 traffic due to nodes' 455 mobility and link variability. Additional challenges such as the 456 support of pseudonimity through MAC address change along with the 457 suitability of traditional TCP applications are discussed by the 458 authors since they require the design of appropriate solutions. 460 5.3. A Framework for IP and non-IP Multicast Services for Vehicular 461 Networks 463 Jemaa et al. presented a framework that enables deploying multicast 464 services for vehicular networks in Infrastructure-based scenarios 465 [Vehicular-Network-Framework]. This framework deals with two phases: 466 (i) Initialization or bootstrapping phase that includes a geographic 467 multicast auto-configuration process and a group membership building 468 method and (ii) Multicast traffic dissemination phase that includes a 469 network selecting mechanism on the transmission side and a receiver- 470 based multicast delivery in the reception side. To this end, authors 471 define a distributed mechanism that allows the vehicles to configure 472 a common multicast address: Geographic Multicast Address Auto- 473 configuration (GMAA), which allows a vehicle to configure its own 474 address without signaling. A vehicle may also be able to change the 475 multicast address to which it is subscribed when it changes its 476 location. 478 This framework suggests a network selecting approach that allows IP 479 and non-IP multicast data delivery in the sender side. Then, to meet 480 the challenges of multicast address auto-configuration, the authors 481 propose a distributed geographic multicast auto-addressing mechanism 482 for multicast groups of vehicles, and a simple multicast data 483 delivery scheme in hybrid networks from a server to the group of 484 moving vehicles. However, this study lacks simulations related to 485 performance assessment. 487 5.4. Joint IP Networking and Radio Architecture for Vehicular Networks 489 Petrescu et al. defined the joined IP networking and radio 490 architecture for V2V and V2I communication in [Joint-IP-Networking]. 491 The paper proposes to consider an IP topology in a similar way as a 492 radio link topology, in the sense that an IP subnet would correspond 493 to the range of 1-hop vehicular communication. The paper defines 494 three types of vehicles: Leaf Vehicle (LV), Range Extending Vehicle 495 (REV), and Internet Vehicle (IV). The first class corresponds to the 496 largest set of communicating vehicles (or network nodes within a 497 vehicle), while the role of the second class is to build an IP relay 498 between two IP-subnet and two sub-IP networks. Finally, the last 499 class corresponds to vehicles being connected to Internet. Based on 500 these three classes, the paper defines six types of IP topologies 501 corresponding to V2V communication between two LVs in direct range, 502 or two LVs over a range extending vehicle, or V2I communication again 503 either directly via an IV, via another vehicles being IV, or via an 504 REV connecting to an IV. 506 Considering a toy example of a vehicular train, where LV would be in- 507 wagon communicating nodes, REV would be inter-wagon relays, and IV 508 would be one node (e.g., train head) connected to Internet. Petrescu 509 et al. defined the required mechanisms to build subnetworks, and 510 evaluated the protocol time that is required to build such networks. 511 Although no simulation-based evaluation is conducted, the initial 512 analysis shows a long initial connection overhead, which should be 513 alleviated once the multi-wagon remains stable. However, this 514 approach does not describe what would happen in the case of a dynamic 515 multi-hop vehicular network, where such overhead would end up being 516 too high for V2V/V2I IP-based vehicular applications. 518 One other aspect described in this paper is to join the IP-layer 519 relaying with radio-link channels. This paper suggests to separate 520 different subnetworks in different WiFi/ITS-G5 channels, which could 521 be advertised by the REV. Accordingly, the overall interference 522 could be controlled within each subnetwork. This statement is 523 similar to multi-channel topology management proposals in multi-hop 524 sensor networks, yet adapted to an IP topology. 526 In conclusion, this paper proposes to classify an IP multi-hop 527 vehicular network in three classes of vehicles: Leaf Vehicle (LV), 528 Range Extending Vehicle (REV), and Internet Vehicle (IV). It 529 suggests that the generally complex multi-hop IP vehicular topology 530 could be represented by only six different topologies, which could be 531 further analyzed and optimized. A prefix dissemination protocol is 532 proposed for one of the topologies. 534 5.5. Mobile Internet Access in FleetNet 536 Bechler et al. described the FleetNet project approach to integrate 537 Internet Access in future vehicular networks [FleetNet]. The paper 538 is most probably one of the first paper to address this aspect, and 539 in many ways, introduces concepts that will be later used in MIPv6 or 540 other subsequent IP mobility management schemes. The paper describes 541 a V2I architecture consisting of Vehicles, Internet Gateways (IGW), 542 Proxy, and Corresponding Nodes (CN). Considering that vehicular 543 networks are required to use IPv6 addresses and also the new wireless 544 access technology ITS-G5 (new at that time), one of the challenges is 545 to bridge the two different networks (i.e., VANET and IP4/IPv6 546 Internet). Accordingly, the paper introduces a Fleetnet Gateway 547 (FGW), which allows vehicles in IPv6 to access the IPv4 Internet and 548 to bridge two types of networks and radio access technologies. 549 Another challenge is to keep the active addressing and flows while 550 vehicles move between FGWs. Accordingly, the paper introduces a 551 proxy node, a cranked-up MIP Home Agent, which can re-route flows to 552 the new FGW as well as acting as a local IPv4-IPv6 NAT. 554 The authors from the paper mostly observed two issues that VANET 555 brings into the traditional IP mobility. First, VANET vehicles must 556 mostly be addressed from the Internet directly, and do not 557 specifically have a Home Network. Accordingly, VANET vehicles 558 require a globally (predefined) unique IPv6 address, while an IPv6 559 co-located care-of address (CCoA) is a newly allocated IPv6 address 560 every time a vehicle would enter a new IGW radio range. Second, 561 VANET links are known to be unreliable and short, and the extensive 562 use of IP tunneling on-the-air was judged not efficient. 563 Accordingly, the first major architecture innovation proposed in this 564 paper is to re-introduce a foreign agent (FA) in MIP located at the 565 IGW, so that the IP-tunneling would be kept in the back-end (between 566 a Proxy and an IGW) and not on the air. Second, the proxy has been 567 extended to build an IP tunnel and be connected to the right FA/IWG 568 for an IP flow using a global IPv6 address. 570 This is a pioneer paper, which contributed to changing MIP and led to 571 the new IPv6 architecture currently known as Proxy-MIP and the 572 subsequent DMM-PMIP. Three key messages can be yet kept in mind. 573 First, unlike the Internet, vehicles can be more prominently directly 574 addressed than the Internet traffic, and do not have a Home Network 575 in the traditional MIP sense. Second, IP tunneling should be avoided 576 as much as possible over the air. Third, the protocol-based mobility 577 (induced by the physical mobility) must be kept hidden to both the 578 vehicle and the correspondent node (CN). 580 5.6. A Layered Architecture for Vehicular Delay-Tolerant Networks 582 Soares et al. addressed the case of delay tolerant vehicular network 583 [Vehicular-DTN]. For delay tolerant or disruption tolerant networks, 584 rather than building a complex VANET-IP multi-hop route, vehicles may 585 also be used to carry packets closer to the destination or directly 586 to the destination. The authors built the well-accepted DTN Bundle 587 architecture and protocol to propose a VANET extension. They 588 introduced three types of VANET nodes: (i) terminal nodes (requiring 589 data), (ii) mobile nodes (carrying data along their routes), and 590 (iii) relay nodes (storing data at cross-roads of mobile nodes as 591 data hotspot). 593 The major innovation in this paper is to propose a DTN VANET 594 architecture separating a Control plane and a Data plane. The 595 authors claimed it to be designed to allow full freedom to select the 596 most appropriate technology, as well as allow to use out-of-band 597 communication for small Control plane packets and use DTN in-band for 598 the Data plane. The paper then further describes the different 599 layers from the Control and the Data planes. One interesting aspect 600 is the positioning of the Bundle layer between L2 and L3, rather than 601 above TCP/IP as for the DTN Bundle architecture. The authors claimed 602 this to be required first to keep bundle aggregation/disaggregation 603 transparent to IP, as well as to allow bundle transmission over 604 multiple access technologies (described as MAC/PHY layers in the 605 paper). 607 Although the DTN architectures evolved since the paper has been 608 written, this paper addresses IP mobility management from a different 609 approach. An important aspect is to separate the Control plane from 610 the Data plane to allow a large flexibility in a Control plane to 611 coordinate a heterogeneous radio access technology (RAT) Data plane. 613 5.7. Key Observations 615 Unidirectional links exist and must be considered. Control Plane 616 must be separated from Data Plane. ID/Pseudonym change requires a 617 lightweight DAD. IP tunneling should be avoided. Vehicles do not 618 have a Home Network. Protocol-based mobility must be kept hidden to 619 both the vehicle and the correspondent node (CN). An ITS 620 architecture may be composed of three types of vehicles: Leaf 621 Vehicle, Range Extending Vehicle, and Internet Vehicle. 623 6. Vehicular Network Routing 625 This section surveys routing in vehicular networks. 627 6.1. An IP Passing Protocol for Vehicular Ad Hoc Networks with Network 628 Fragmentation 630 Chen et al. tackled the issue of network fragmentation in VANET 631 environments [IP-Passing-Protocol]. The paper proposes a protocol 632 that can postpone the time to release IP addresses to the DHCP server 633 and select a faster way to get the vehicle's new IP address, when the 634 vehicle density is low or the speeds of vehicles are varied. In such 635 circumstances, the vehicle may not be able to communicate with the 636 intended vehicle either directly or through multi-hop relays as a 637 consequence of network fragmentation. 639 The paper claims that although the existing IP passing and mobility 640 solutions may reduce handoff delay, but they cannot work properly on 641 VANET especially with network fragmentation. This is due to the fact 642 that messages cannot be transmitted to the intended vehicles. When 643 network fragmentation occurs, it may incur longer handoff latency and 644 higher packet loss rate. The main goal of this study is to improve 645 existing works by proposing an IP passing protocol for VANET with 646 network fragmentation. 648 The paper makes the assumption that on the highway, when a vehicle 649 moves to a new subnet, the vehicle will receive broadcast packet from 650 the target Base Station (BS), and then perform the handoff procedure. 651 The handoff procedure includes two parts, such as the layer-2 handoff 652 (new frequency channel) and the layer-3 handover (a new IP address). 653 The handoff procedure contains movement detection, DAD procedure, and 654 registration. In the case of IPv6, the DAD procedure is time 655 consuming and may cause the link to be disconnected. 657 This paper proposes another handoff mechanism. The handoff procedure 658 contains the following phases. The first is the information 659 collecting phase, where each mobile node (vehicle) will broadcast its 660 own and its neighboring vehicles' locations, moving speeds, and 661 directions periodically. The remaining phases are, the fast IP 662 acquiring phase, the cooperation of vehicle phase, the make before 663 break phase, and the route redirection phase. 665 Simulations results show that for the proposed protocol, network 666 fragmentation ratio incurs less impact. Vehicle speed and density 667 has great impact on the performance of the IP passing protocol 668 because vehicle speed and vehicle density will affect network 669 fragmentation ratio. A longer IP lifetime can provide a vehicle with 670 more chances to acquire its IP address through IP passing. 672 Simulation results show that the proposed scheme can reduce IP 673 acquisition time and packet loss rate, so extend IP lifetime with 674 extra message overhead. 676 6.2. Experimental Evaluation for IPv6 over VANET Geographic Routing 678 Tsukada et al. presented a work that aims at combining IPv6 679 networking and a Car-to-Car Network routing protocol (called C2CNet) 680 proposed by the Car2Car Communication Consortium (C2C-CC), which is 681 an architecture using a geographic routing protocol 682 [VANET-Geo-Routing]. In C2C-CC architecture, C2CNet layer is located 683 between IPv6 and link layers. Thus, an IPv6 packet is delivered with 684 outer C2CNet header, which introduces the challenge of how to support 685 the communication types defined in C2CNet in IPv6 layer. 687 The main goal of GeoNet is to enhance these specifications and create 688 a prototype software implementation interfacing with IPv6. C2CNet is 689 specified in C2C-CC as a geographic routing protocol. 691 In order to assess the performance of this protocol, the authors 692 measured the network performance with UDP and ICMPv6 traffic using 693 iperf and ping6. The test results show that IPv6 over C2CNet does 694 not have too much delay (less than 4ms with a single hop) and is 695 feasible for vehicle communication. In the outdoor testbed, they 696 developed AnaVANET to enable hop-by-hop performance measurement and 697 position trace of the vehicles. 699 The combination of IPv6 multicast and GeoBroadcast was implemented, 700 however, the authors did not evaluate the performance with such a 701 scenario. One of the reasons is that a sufficiently high number of 702 receivers are necessary to properly evaluate multicast but 703 experimental evaluation is limited in the number of vehicles (4 in 704 this study). 706 6.3. Key Observations 708 IP address autoconfiguration should be manipulated to support the 709 efficient networking. Due to network fragmentation, vehicles cannot 710 communicate with each other temporarily. IPv6 ND should consider the 711 temporary network fragmentation. IPv6 link concept can be supported 712 by Geographic routing to connect vehicles with the same IPv6 prefix. 714 7. Mobility Management in Vehicular Networks 716 This section surveys mobility management schemes in vehicular 717 networks to support handover. 719 7.1. A Hybrid Centralized-Distributed Mobility Management for 720 Supporting Highly Mobile Users 722 Nguyen et al. proposed a hybrid centralized-distributed mobility 723 management called H-DMM to support highly mobile vehicles [H-DMM]. 724 The legacy DMM is not suitable for high-speed scenarios because it 725 requires additional registration delay proportional to the distance 726 between a vehicle and its anchor network. H-DMM is designed to 727 satisfy a set of requirements, such as service disruption time, end- 728 to-end delay, packet delivery cost, and tunneling cost. 730 H-DMM adopts a central node called central mobility anchor (CMA), 731 which plays the role of a local mobility anchor (LMA) in PMIPv6. 732 When it enters a mobile access router (MAR) as an access router, a 733 vehicle obtains a prefix from the MAR (called MAR-prefix) according 734 to the legacy DMM protocol. In addition, it obtains another prefix 735 from the CMA (called LMA-prefix) for a PMIPv6 domain. Whenever it 736 performs a handover between the subnets for two adjacent MARs, a 737 vehicle keeps the LMA-prefix while obtaining a new prefix from the 738 new MAR. For a new data exchange with a new CN, the vehicle can 739 select the MAR-prefix or the LMA-prefix for its own source IPv6 740 address. If the number of active prefixes is greater than a 741 threshold, the vehicle uses the LMA-prefix-based IPv6 address as its 742 source address. In addition, it can continue receiving data packets 743 with the destination IPv6 addresses based on the previous prefixes 744 through the legacy DMM protocol. 746 Thus, H-DMM can support an efficient tunneling for a high-speed 747 vehicle that moves fast across the subnets of two adjacent MARs. 748 However, when H-DMM asks a vehicle to perform DAD for the uniqueness 749 test of its configured IPv6 address in the subnet of the next MAR, 750 the activation of the configured IPv6 address for networking will 751 take a delay. This indicates that a proactive DAD by a network 752 component (i.e., MAR and LMA) can shorten the address configuration 753 delay of the current DAD triggered by a vehicle. 755 7.2. A Hybrid Centralized-Distributed Mobility Management Architecture 756 for Network Mobility 758 Nguyen et al. proposed H-NEMO, a hybrid centralized-distributed 759 mobility management scheme to handle IP mobility of moving vehicles 760 [H-NEMO]. The standard Network Mobility (NEMO) basic support, which 761 is a centralized scheme for network mobility, provides IP mobility 762 for a group of users in a moving vehicle, but also inherits the 763 drawbacks from Mobile IPv6, such as suboptimal routing and signaling 764 overhead in nested scenarios as well as reliability and scalability 765 issues. On the contrary, distributed schemes such as the recently 766 proposed Distributed Mobility Management (DMM) locates the mobility 767 anchor at the network edge and enables mobility support only to 768 traffic flows that require such support. However, in high speed 769 moving vehicles, DMM may suffer from high signaling cost and high 770 handover latency. 772 The proposed H-NEMO architecture is not designed for a specific 773 wireless technology. Instead, it defines a general architecture and 774 signaling protocol so that a mobile node can obtain mobility from 775 fixed locations or mobile platforms, and also allows the use of DMM 776 or Proxy Mobile IPv6 (PMIPv6), depending on flow characteristics and 777 mobility patterns of the node. For IP addressing allocation, a 778 mobile router (MR) or the mobile node (MN) connected to an MR in a 779 NEMO obtain two sets of prefixes: one from the central mobility 780 anchor and one from the mobile access router (MAR). In this way, the 781 MR/MN may choose a more stable prefix for long-lived flows to be 782 routed via the central mobility anchor and the MAR-prefix for short- 783 lived flows to be routed following the DMM concept. The multi-hop 784 scenario is considered under the concept of a nested-NEMO. 786 Nguyen et al. did not provide simulation-based evaluations, but they 787 provided an analytical evaluation that considered signaling and 788 packet delivery costs, and showed that H-NEMO outperforms the 789 previous proposals, which are either centralized or distributed ones 790 with NEMO support. In particular cases, such as the signaling cost, 791 H-NEMO is more costly than centralized schemes when the velocity of 792 the node is increasing, but behaves better in terms of packet 793 delivery cost and handover delay. 795 7.3. NEMO-Enabled Localized Mobility Support for Internet Access in 796 Automotive Scenarios 798 In [NEMO-LMS], authors proposed an architecture to enable IP mobility 799 for moving networks in a network-based mobility scheme based on 800 PMIPv6. In PMIPv6, only mobile terminals are provided with IP 801 mobility. Different from host-based mobility, PMIPv6 shifts the 802 signaling to the network side, so that the mobile access gateway 803 (MAG) is in charge of detecting connection/disconnection of the 804 mobile node, upon which the signaling to the Local Mobility Anchor 805 (LMA) is triggered to guarantee a stable IP addressing assignment 806 when the mobile node performs handover to a new MAG. 808 Soto et al. proposed NEMO support in PMIPv6 (N-PMIP). In this 809 scheme, the functionality of the MAG is extended to the mobile router 810 (MR), also called a mobile MAG (mMAG). The functionality of the 811 mobile terminal remains unchanged, but it can receive an IPv6 prefix 812 belonging to the PMIPv6 domain through the new functionality of the 813 mMAG. Therefore, in N-PMIP, the mobile terminal connects to the MR 814 as if it is connecting to a fixed MAG, and the MR connects to the 815 fixed MAG with the standardized signaling of PMIPv6. When the mobile 816 terminal roams to a new MAG or a new MR, the network forwards the 817 packets through the LMA. Hence, N-PMIP defines an extended 818 functionality in the LMA that enables a recursive lookup. First, it 819 locates the binding entry corresponding to the mMAGr. Next, it 820 locates the entry corresponding to the fixed MAG, after which the LMA 821 can encapsulate packets to the mMAG to which the mobile terminal is 822 currently connected. 824 The performance of N-PMIP was evaluated through simulations and 825 compared to a NEMO+MIPv6+PMIPv6 scheme, with better results obtained 826 in N-PMIP. The work did not consider the case of multi-hop 827 connectivity in the vehicular scenario. In addition, since the MR 828 should be a trusted entity in the PMIP domain, it requires specific 829 security associations that were not addressed in [NEMO-LMS]. 831 7.4. Network Mobility Protocol for Vehicular Ad Hoc Networks 833 Chen et al. proposed a network mobility protocol to reduce handoff 834 delay and maintain Internet connectivity to moving vehicles in a 835 highway [NEMO-VANET]. In this work, vehicles can acquire IP 836 addresses from other vehicles through V2V communications. At the 837 time the vehicle goes out of the coverage of the base station, 838 another vehicle may assist the roaming car to acquire a new IP 839 address. Also, cars on the same or opposite lane are entitled to 840 assist the vehicle to perform a pre-handoff. 842 Authors assumed that the wireless connectivity is provided by WiFi 843 and WiMAX access networks. Also, they considered scenarios in which 844 a single vehicle, i.e., a bus, may need two mobile routers in order 845 to have an effective pre-handoff procedure. Evaluations are 846 performed through simulations and the comparison schemes are the 847 standard NEMO Basic Support protocol and the fast NEMO Basic Support 848 protocol. Authors did not mention applicability of the scheme in 849 other scenarios such as in urban transport schemes. 851 7.5. Performance Analysis of PMIPv6-Based Network MObility for 852 Intelligent Transportation Systems 854 Lee et al. proposed P-NEMO, which is an IP mobility management scheme 855 to maintain the Internet connectivity at the vehicle as a mobile 856 network, and provides a make-before-break mechanism when vehicles 857 switch to a new access network [PMIPv6-NEMO-Analysis]. Since the 858 standard PMIPv6 only supports mobility for a single node, the 859 solution in [PMIPv6-NEMO-Analysis] adapts the protocol to reduce the 860 signaling when a local network is to be served by the in-vehicle 861 mobile router. To achieve this, P-NEMO extends the binding update 862 lists at both MAG and LMA, so that the mobile router (MR) can receive 863 a home network prefix (HNP) and a mobile network prefix (MNP). The 864 latter prefix enables mobility for the moving network, instead of a 865 single node as in the standard PMIPv6. 867 An additional feature is proposed by Lee et al. named fast P-NEMO 868 (FP-NEMO). It adopts the fast handover approach standardized for 869 PMIPv6 in [RFC5949] with both predictive and reactive modes. The 870 difference of the proposed feature with the standard version is that 871 by using the extensions provided by P-NEMO, the predictive 872 transferring of the context from the old MAG to the new MAG also 873 includes information for the moving network, i.e., the MNP, so that 874 mobility support can be achieved not only for the mobile router, but 875 also for mobile nodes traveling with the vehicle. 877 The performance of P-NEMO and F-NEMO is only evaluated through an 878 analytical model that is compared to the standard NEMO-BS. No 879 comparison was provided to other schemes that enable network mobility 880 in PMIPv6 domains, such as the one presented in [NEMO-LMS]. 882 7.6. A Novel Mobility Management Scheme for Integration of Vehicular Ad 883 Hoc Networks and Fixed IP Networks 885 Peng et al. proposed a novel mobility management scheme for 886 integration of VANET and fixed IP networks [Vehicular-Network-MM]. 887 The proposed scheme deals with mobility of vehicles based on a street 888 layout instead of a general two dimensional ad hoc network. This 889 scheme makes use of the information provided by vehicular networks to 890 reduce mobility management overhead. It allows multiple base 891 stations that are close to a destination vehicle to discover the 892 connection to the vehicle simultaneously, which leads to an 893 improvement of the connectivity and data delivery ratio without 894 redundant messages. The performance was assessed by using a road 895 traffic simulator called SUMO (Simulation of Urban Mobility). 897 7.7. SDN-based Distributed Mobility Management for 5G Networks 899 Nguyen et al. extended their previous works on a vehicular adapted 900 DMM considering a Software-Defined Networking (SDN) architecture 901 [SDN-DMM]. On one hand, in their previous work, Nguyen et al. 902 proposed DMM-PMIP and DMM-MIP architectures for VANET. The major 903 innovation behind DMM is to distribute the Mobility Functions (MF) 904 through the network instead of concentrating them in one bottleneck 905 MF, or in a hierarchically organized backbone of MF. Highly mobile 906 vehicular networks impose frequent IP route optimizations that lead 907 to suboptimal routes (detours) between CN and vehicles. The 908 suboptimality critically increases by nested or hierarchical MF 909 nodes. Therefore, flattening the IP mobility architecture 910 significantly reduces detours, as it is the role of the last MF to 911 get the closest next MF (in most cases nearby). Yet, with an MF 912 being distributed throughout the network, a Control plane becomes 913 necessary in order to provide a solution for CN to address vehicles. 914 The various solutions developed by Nguyen at al. not only showed the 915 large benefit of a DMM approach for IPv6 mobility management, but 916 also emphasized the critical role of an efficient Control plane. 918 One the other hand, SDN recently appeared and gained a big attention 919 from the Internet Networking community due to its capacity to provide 920 a significantly higher scalability of highly dynamic flows, which is 921 required by future 5G dynamic networks. In particular, SDN also 922 suggests a strict separation between a Control plane (SDN-Controller) 923 and a Data plane (OpenFlow Switches) based on the OpenFlow standard. 924 Such an architecture has two advantages that are critical for IP 925 mobility management in VANET. First, unlike traditional routing 926 mechanisms, OpenFlow focuses on flows rather than optimized routes. 927 Accordingly, they can optimize routing based on flows (grouping 928 multiple flows in one route, or allowing one flow to have different 929 routes), and can detect broken flows much earlier than the 930 traditional networking solutions. Second, SDN controllers may 931 dynamically reprogram (reconfigure) OpenFlow Switches (OFS) to always 932 keep an optimal route between CN and a vehicular node. 934 Nguyen et. al observed the mutual benefits IPv6 DMM could obtain from 935 an SDN architecture, and then proposed an SDN-based DMM for VANET. 936 In their proposed architecture, a PMIP-DMM is used, where MF is OFS 937 for the Data plane, and one or more SDN controllers handle the 938 Control plane. The evaluation and prototype in the paper prove that 939 the proposed architecture can provide a higher scalability than the 940 standard DMM. 942 This paper makes several observations leading to a strong suggestions 943 that IP mobility management should be based on an SDN architecture. 944 First, SDN will be integrated into future Internet and 5G in a near 945 future. Second, after separating the Identity and Routing 946 addressing, IP mobility management further requires to separate the 947 Control from the Data plane if it needs to remain scalable for VANET. 948 Finally, Flow-based routing (in particular OpenFlow standard) will be 949 required in future heterogeneous vehicular networks (e.g., multi-RAT 950 and multi-protocol) and the SDN coupled with DMM provides a double 951 benefit of dynamic flow detection/reconfiguration and short(-er) 952 route optimizations. 954 7.8. IP Mobility Management for Vehicular Communication Networks: 955 Challenges and Solutions 957 Cespedes et al. provided a survey of the challenges for NEMO Basic 958 Support for VANET [Vehicular-IP-MM]. NEMO allows the management of a 959 group of nodes (a mobile network) rather than a single node. 960 However, although a vehicle and even a platoon of vehicles could be 961 seen as a group of nodes, NEMO has not been designed considering the 962 particularities of VANET. For example, NEMO builds a tunnel between 963 an MR (on board of a vehicle) and its HA, which in a VANET context is 964 suboptimal, for instance due to over-the-air tunneling cost, the 965 detour taken to pass by the MR's HA even if the CN is nearby, or the 966 route optimization when the MR moves to a new AR. 968 Cespedes et al. first summarize the requirements of IP mobility 969 management, such as reduced power at end-device, reduced handover 970 event, reduced complexity, or reduced bandwidth consumption. VANET 971 adds the following requirements, such as minimum signaling for route 972 optimization (RO), per-flow separability, security and binding 973 privacy protection, multi-homing, and switching HA. As observed, 974 these provide several challenges to IP mobility and NEMO BS for 975 VANET. 977 Cespedes et al. then describe various optimization schemes available 978 for NEMO BS. Considering a single hop connection to CN, one major 979 optimization direction is to avoid the HA detour and reach the CN 980 directly. In that direction, a few optimizations are proposed, such 981 as creating an IP tunnel between the MR and the CR directly, creating 982 an IP tunnel between the MR and a CR (rather than the HA), a 983 delegation mechanism allowing Visiting Nodes to use MIPv6 directly 984 rather than NEMO or finally intra-NEMO optimization for a direct path 985 within NEMO bypassing HAs. 987 Specific to VANET, multi-hop connection is possible to the fixed 988 network. In that case, NEMO BS must be enhanced to avoid that the 989 path to immediate neighbors must pass by the respective HAs instead 990 of directly. More specifically, two approaches are proposed to rely 991 on VANET sub-IP multi-hop routing to hide a NEMO complex topology 992 (e.g., Nested NEMO) and provide a direct route between two VANET 993 nodes. Generally, one major challenge is security and privacy when 994 opening a multi-hop route between a VANET and a CN. Heterogeneous 995 multi-hop in a VANET (e.g., relying on various access technologies) 996 corresponds to another challenge for NEMO BS as well. 998 Cespedes et al. conclude their paper with an overview of critical 999 research challenges, such as Anchor Point location, the optimized 1000 usage of geographic information at the subIP as well as at the IP 1001 level to improve NEMO BS, security and privacy, and the addressing 1002 allocation schema for NEMO. 1004 In summary, this paper illustrates that NEMO BS for VANET should 1005 avoid the HA detour as well as opening IP tunnels over the air. 1006 Also, NEMO BS could use geographic information for subIP routing when 1007 a direct link between vehicles is required to reach an AR, but also 1008 anticipate handovers and optimize ROs. From an addressing 1009 perspective, dynamic MNP assignments should be preferred, but should 1010 be secured in particular during binding update (BU). 1012 7.9. Key Observations 1014 Mobility Management (MM) solution design varies, depending on 1015 scenarios: highway vs. urban roadway. Hybrid schemes (NEMO + PMIP, 1016 PMIP + DMM, etc.) usually show better performance than pure schemes. 1017 Most schemes assume that IP address configuration is already set up. 1018 Most schemes have been tested only at either simulation or analytical 1019 level. SDN can be considered as a player in the MM solution. 1021 8. Vehicular Network Security 1023 This section surveys security in vehicular networks. 1025 8.1. Securing Vehicular IPv6 Communications 1027 Fernandez et al. proposed a secure vehicular IPv6 communication 1028 scheme using Internet Key Exchange version 2 (IKEv2) and Internet 1029 Protocol Security (IPsec) [Securing-VCOMM]. This scheme aims at the 1030 security support for IPv6 Network Mobility (NEMO) for in-vehicle 1031 devices inside a vehicle via a Mobile Router (MR). An MR has 1032 multiple wireless interfaces, such as 3G, IEEE 802.11p, WiFi, and 1033 WiMAX. The proposed architecture consists of Vehicle ITS Station 1034 (Vehicle ITS-S), Roadside ITS Station (Roadside ITS-S), and Central 1035 ITS Station (Central ITS-S). Vehicle ITS-S is a vehicle having a 1036 mobile Network along with an MR. Roadside ITS-S is an RSU as a 1037 gateway to connect vehicular networks to the Internet. Central ITS-S 1038 is a TCC as a Home Agent (HA) for the location management of vehicles 1039 having their MR. 1041 The proposed secure vehicular IPv6 communication scheme sets up IPsec 1042 secure sessions for control and data traffic between the MR in a 1043 Vehicle ITS-S and the HA in a Central ITS-S. Roadside ITS-S plays a 1044 role of an Access Router (AR) for Vehicle ITS-S's MR to provide the 1045 Internet connectivity for Vehicle ITS-S via wireless interfaces, such 1046 as IEEE 802.11p, WiFi, and WiMAX. In the case where Roadside ITS-S 1047 is not available to Vehicle ITS-S, Vehicle ITS-S communicates with 1048 Central ITS-S via cellular networks (e.g., 3G). The secure 1049 communication scheme enhances the NEMO protocol that interworks with 1050 IKEv2 and IPsec in network mobility in vehicular networks. 1052 The authors implemented their scheme and evaluated its performance in 1053 a real testbed. This testbed supports two wireless networks, such as 1054 IEEE 802.11p and 3G. The in-vehicle devices (or hosts) in Vehicle 1055 ITS-S are connected to an MR of Vehicle ITS-S via IEEE 802.11g. The 1056 test results show that their scheme supports promising secure IPv6 1057 communications with a low impact on communication performance. 1059 8.2. Providing Authentication and Access Control in Vehicular Network 1060 Environment 1062 Moustafa et al. proposed a security scheme providing authentication, 1063 authorization, and accounting (AAA) services in vehicular networks 1064 [VNET-AAA]. This secuirty scheme aims at the support of safe and 1065 reliable data services in vehicular networks. It authenticates 1066 vehicles as mobile clients to use the network access and various 1067 services that are provided by service providers. Also, it ensures a 1068 confidential data transfer between communicating parties (e.g., 1069 vehicle and infrastructure node) by using IEEE 802.11i (i.e., WPA2) 1070 for secure layer-2 links. 1072 The authors proposed a vehicular network architecture consisting of 1073 three entities, such as Access network, Wireless mobile ad hoc 1074 networks (MANETs), and Access Points (APs). Access network is the 1075 fixed network infrastructure forming the back-end of the 1076 architecture. Wireless MANETs are constructed by moving vehicles 1077 forming the front-end of the architecture. APs is the IEEE 802.11 1078 WLAN infrastructure forming the interface between the front-end and 1079 back-end of the architecture. 1081 For AAA services, the proposed architecture uses a Kerberos 1082 authentication model that authenticates vehicles at the entry point 1083 with the AP and also authorizes them to the access of various 1084 services. Since vehicles are authenticated by a Kerberos 1085 Authentication Server (AS) only once, the proposed security scheme 1086 can minimize the load on the AS and reduce the delay imposed by layer 1087 2 using IEEE 802.11i. 1089 8.3. Key Observations 1091 The security for vehicular networks should provide vehicles with AAA 1092 services in an efficient way. It should consider not only horizontal 1093 handover, but also vertical handover since vehicles have multiple 1094 wireless interfaces. 1096 9. Standard Activities for Vehicular Networks 1098 This section surveys standard activities for vehicular networks in 1099 standards developing organizations. 1101 9.1. IEEE Guide for Wireless Access in Vehicular Environments (WAVE) - 1102 Architecture 1104 IEEE 1609 is a suite of standards for Wireless Access in Vehicular 1105 Environments (WAVE) developed in the IEEE Vehicular Technology 1106 Society (VTS). They define an architecture and a complementary 1107 standardized set of services and interfaces that collectively enable 1108 secure vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) 1109 wireless communications. 1111 IEEE 1609.0 provides a description of the WAVE system architecture 1112 and operations (called WAVE reference model) [WAVE-1609.0]. The 1113 reference model of a typical WAVE device includes two data plane 1114 protocol stacks (sharing a common lower stack at the data link and 1115 physical layers): (i) the standard Internet Protocol Version 6 (IPv6) 1116 and (ii) the WAVE Short Message Protocol (WSMP) designed for 1117 optimized operation in a wireless vehicular environment. WAVE Short 1118 Messages (WSM) may be sent on any channel. IP traffic is only 1119 allowed on service channels (SCHs), so as to offload high-volume IP 1120 traffic from the control channel (CCH). 1122 The Layer 2 protocol stack distinguishes between the two upper stacks 1123 by the Ethertype field. Ethertype is a 2-octet field in the Logical 1124 Link Control (LLC) header, used to identify the networking protocol 1125 to be employed above the LLC protocol. In particular, it specifies 1126 the use of two Ethertype values (i.e., two networking protocols), 1127 such as IPv6 and WSMP. 1129 Regarding the upper layers, while WAVE communications use standard 1130 port numbers for IPv6-based protocols (e.g., TCP, UDP), they use a 1131 Provider Service Identifier (PSID) as an identifier in the context of 1132 WSMP. 1134 9.2. IEEE Standard for Wireless Access in Vehicular Environments (WAVE) 1135 - Networking Services 1137 IEEE 1609.3 defines services operating at the network and transport 1138 layers, in support of wireless connectivity among vehicle-based 1139 devices, and between fixed roadside devices and vehicle-based devices 1140 using the 5.9 GHz Dedicated Short-Range Communications/Wireless 1141 Access in Vehicular Environments (DSRC/WAVE) mode [WAVE-1609.3]. 1143 WAVE Networking Services represent layer 3 (networking) and layer 4 1144 (transport) of the OSI communications stack. The purpose is then to 1145 provide addressing and routing services within a WAVE system, 1146 enabling multiple stacks of upper layers above WAVE Networking 1147 Services and multiple lower layers beneath WAVE Networking Services. 1148 Upper layer support includes in-vehicle applications offering safety 1149 and convenience to users. 1151 The WAVE standards support IPv6. IPv6 was selected over IPv4 because 1152 IPv6 is expected to be a viable protocol into the foreseeable future. 1153 Although not described in the WAVE standards, IPv4 has been tunnelled 1154 over IPv6 in some WAVE trials. 1156 The document provides requirements for IPv6 configuration, in 1157 particular for the address setting. It specifies the details of the 1158 different service primitives, among which is the WAVE Routing 1159 Advertisement (WRA), part of the WAVE Service Advertisement (WSA). 1160 When present, the WRA provides information about infrastructure 1161 internetwork connectivity, allowing receiving devices to be 1162 configured to participate in the advertised IPv6 network. For 1163 example, an RSU can broadcast in the WRA portion of its WSA all the 1164 information necessary for an OBU to access an application-service 1165 available over IPv6 through the RSU as a router. This feature 1166 removes the need for an IPv6 Router Advertisement message, which are 1167 based on ICMPv6. 1169 9.3. ETSI Intelligent Transport Systems: Transmission of IPv6 Packets 1170 over GeoNetworking Protocols 1172 ETSI published a standard specifing the transmission of IPv6 packets 1173 over the ETSI GeoNetworking (GN) protocol [ETSI-GeoNetworking] 1174 [ETSI-GeoNetwork-IPv6]. IPv6 packet transmission over GN is defined 1175 in ETSI EN 302 636-6-1 [ETSI-GeoNetwork-IPv6] using a protocol 1176 adaptation sub-layer called "GeoNetworking to IPv6 Adaptation Sub- 1177 Layer (GN6ASL)". It enables an ITS station (ITS-S) running the GN 1178 protocol and an IPv6-compliant protocol layer to: (i) exchange IPv6 1179 packets with other ITS-S; (ii) acquire globally routable IPv6 unicast 1180 addresses and communicate with any IPv6 host located in the Internet 1181 by having the direct connectivity to the Internet or via other relay 1182 ITS stations; (iii) perform operations as a Mobile Router for network 1183 mobility [RFC3963]. 1185 The document introduces three types of virtual link, the first one 1186 providing symmetric reachability by means of stable geographically 1187 scoped boundaries and two others that can be used when the dynamic 1188 definition of the broadcast domain is required. The combination of 1189 these three types of virtual link in the same station allows running 1190 the IPv6 ND protocol including Stateless Address Autoconfiguration 1191 (SLAAC) [RFC4862] as well as distributing other IPv6 link-local 1192 multicast traffic and, at the same time, reaching nodes that are 1193 outside specific geographic boundaries. The IPv6 virtual link types 1194 are provided by the GN6ASL to IPv6 in the form of virtual network 1195 interfaces. 1197 The document also describes how to support bridging on top of the 1198 GN6ASL, how IPv6 packets are encapsulated IN GN packets and 1199 delivered, as well as the support of IPv6 multicast and anycast 1200 traffic, and neighbor discovery. For latency reasons, the standard 1201 strongly recommends to use SLAAC for the address configuration. 1203 Finally, the document includes the required operations to support the 1204 change of pseudonym, e.g., changing IPv6 addresses when the GN 1205 address is changed, in order to prevent attackers from tracking the 1206 ITS-S. 1208 9.4. ISO Intelligent Transport Systems: Communications Access for Land 1209 Mobiles (CALM) Using IPv6 Networking 1211 ISO published a standard specifying the IPv6 network protocols and 1212 services [ISO-ITS-IPv6]. These services are necessary to support the 1213 global reachability of ITS-S, the continuous Internet connectivity 1214 for ITS-S, and the handover functionality required to maintain such 1215 connectivity. This functionality also allows legacy devices to 1216 effectively use an ITS-S as an access router to connect to the 1217 Internet. Essentially, this specification describes how IPv6 is 1218 configured to support ITS-S and provides the associated management 1219 functionality. 1221 The requirements apply to all types of nodes implementing IPv6: 1222 personal, vehicle, roadside, or central node. The standard defines 1223 IPv6 functional modules that are necessary in an IPv6 ITS-S, covering 1224 IPv6 forwarding, interface between IPv6 and lower layers (e.g., LAN 1225 interface), mobility management, and IPv6 security. It defines the 1226 mechanisms to be used to configure the IPv6 address for static nodes 1227 as well as for mobile nodes, while maintaining the addressing 1228 reachability from the Internet. 1230 10. Summary and Analysis 1232 This document surveyed state-of-the-arts technologies for IP-based 1233 vehicular networks, such as IP address autoconfiguration, vehicular 1234 network architecture, vehicular network routing, and mobility 1235 management. 1237 Through this survey, it is learned that IPv6-based vehicular 1238 networking can be well-aligned with IEEE WAVE standards for various 1239 vehicular network applications, such as driving safety, efficient 1240 driving, and infotainment. However, since the IEEE WAVE standards do 1241 not recommend to use the IPv6 ND protocol for the communication 1242 efficiency under high-speed mobility, it is necessary to adapt the ND 1243 for vehicular networks with such high-speed mobility. 1245 The concept of a link in IPv6 does not match that of a link in VANET 1246 because of the physical separation of communication ranges of 1247 vehicles in a connected VANET. That is, in a linear topology of 1248 three vehicles (Vehicle-1, Vehicle-2, and Vehicle-3), Vehicle-1 and 1249 Vehicle-2 can communicate directly with each other. Vehicle-2 and 1250 Vehicle-3 can communicate directly with each other. However, 1251 Vehicle-1 and Vehicle-3 cannot communicate directly with each other 1252 due to the out-of-communication range. For the link in IPv6, all of 1253 three vehicles are on a link, so they can communicate directly with 1254 each other. On the other hand, in VANET, this on-link communication 1255 concept is not valid in VANET. Thus, the IPv6 ND should be extended 1256 to support this multi-link subnet of a connected VANET through either 1257 ND proxy or VANET routing. 1259 For IP-based networking, IP address autoconfiguration is a 1260 prerequisite function. Since vehicles can communicate intermittently 1261 with TCC via RSUs through V2I communications, TCC can play a role of 1262 a DHCP server to allocate unique IPv6 addresses to the vehicles. 1263 This centralized address allocation can remove the delay of the DAD 1264 procedure for testing the uniqueness of IPv6 addresses. 1266 For routing and mobility management, most of vehicles are equipped 1267 with a GPS navigator as a dedicated navigation system or a smartphone 1268 App. With this GPS navigator, vehicles can share their current 1269 position and trajectory (i.e., navigation path) with TCC. TCC can 1270 predict the future positions of the vehicles with their mobility 1271 information (i.e., the current position, speed, direction, and 1272 trajectory). With the prediction of the vehicle mobility, TCC 1273 supports RSUs to perform data packet routing and handover 1274 proactively. 1276 11. Security Considerations 1278 Security and privacy are important aspects in vehicular networks. 1279 Only valid vehicles should be allowed to participate in vehicular 1280 networking. Vehicle Identification Number (VIN) and user certificate 1281 can be used to authenticate a vehicle and user through road 1282 infrastructure, such as Road-Side Unit (RSU) connected to an 1283 authentication server in Traffic Control Center (TCC). 1285 12. Contributors 1287 IPWAVE is a group effort. The following people actively contributed 1288 to the problem statement text: Thierry Ernst (YoGoKo), Richard Roy 1289 (MIT), Rex Buddenberg (Naval Postgraduate School), Jose Santa Lozanoi 1290 (Universidad of Murcia), and Bokor Laszlo (Budapest University of 1291 Technology and Economics). 1293 13. Contributing Authors 1295 IPWAVE has had a number of contributing authors. The following are 1296 contributing authors: 1298 o Francois Simon (Pilot): Clarification of the definitions of RSU, 1299 OBU, and TCC in Section 3 and other text. 1301 14. Acknowledgements 1303 This work was supported by Institute for Information & communications 1304 Technology Promotion (IITP) grant funded by the Korea government 1305 (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence 1306 Technology Development for the Customized Security Service 1307 Provisioning). This work was supported in part by ICT R&D program of 1308 MSIP/IITP (14-824-09-013, Resilient Cyber-Physical Systems Research) 1309 and the DGIST Research and Development Program (CPS Global Center) 1310 funded by the Ministry of Science, ICT & Future Planning. This work 1311 was supported in part by the French research project DataTweet (ANR- 1312 13-INFR-0008) and in part by the HIGHTS project funded by the 1313 European Commission I (636537-H2020). 1315 15. References 1317 15.1. Normative References 1319 [RFC2119] Bradner, S., "Key words for use in 1320 RFCs to Indicate Requirement Levels", 1321 BCP 14, RFC 2119, March 1997. 1323 [RFC5889] Baccelli, E. and M. Townsley, "IP 1324 Addressing Model in Ad Hoc Networks", 1325 RFC 5889, September 2010. 1327 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., 1328 Patil, B., and F. Xia, "Fast Handovers 1329 for Proxy Mobile IPv6", RFC 5949, 1330 September 2010. 1332 15.2. Informative References 1334 [Address-Autoconf] Fazio, M., Palazzi, C., Das, S., and 1335 M. Gerla, "Automatic IP Address 1336 Configuration in VANETs", 1337 ACM International Workshop on 1338 Vehicular Inter-Networking, 1339 September 2016. 1341 [Address-Assignment] Kato, T., Kadowaki, K., Koita, T., and 1342 K. Sato, "Routing and Address 1343 Assignment using Lane/Position 1344 Information in a Vehicular Ad-hoc 1345 Network", IEEE Asia-Pacific Services 1346 Computing Conference, December 2008. 1348 [GeoSAC] Baldessari, R., Bernardos, C., and M. 1349 Calderon, "GeoSAC - Scalable Address 1350 Autoconfiguration for VANET Using 1351 Geographic Networking Concepts", 1352 IEEE International Symposium on 1353 Personal, Indoor and Mobile Radio 1354 Communications, September 2008. 1356 [Identities-Management] Wetterwald, M., Hrizi, F., and P. 1357 Cataldi, "Cross-layer Identities 1358 Management in ITS Stations", 1359 10th International Conference on ITS 1360 Telecommunications, November 2010. 1362 [VIP-WAVE] Cespedes, S., Lu, N., and X. Shen, 1363 "VIP-WAVE: On the Feasibility of IP 1364 Communications in 802.11p Vehicular 1365 Networks", IEEE Transactions on 1366 Intelligent Transportation Systems, 1367 March 2013. 1369 [IPv6-WAVE] Baccelli, E., Clausen, T., and R. 1370 Wakikawa, "IPv6 Operation for WAVE - 1371 Wireless Access in Vehicular 1372 Environments", IEEE Vehicular 1373 Networking Conference, December 2010. 1375 [Vehicular-Network-Framework] Jemaa, I., Shagdar, O., and T. Ernst, 1376 "A Framework for IP and non-IP 1377 Multicast Services for Vehicular 1378 Networks", Third International 1379 Conference on the Network of the 1380 Future, November 2012. 1382 [Joint-IP-Networking] Petrescu, A., Boc, M., and C. Ibars, 1383 "Joint IP Networking and Radio 1384 Architecture for Vehicular Networks", 1385 11th International Conference on ITS 1386 Telecommunications, August 2011. 1388 [FleetNet] Bechler, M., Franz, W., and L. Wolf, 1389 "Mobile Internet Access in FleetNet", 1390 13th Fachtagung Kommunikation in 1391 verteilten Systemen, February 2001. 1393 [Vehicular-DTN] Soares, V., Farahmand, F., and J. 1394 Rodrigues, "A Layered Architecture for 1395 Vehicular Delay-Tolerant Networks", 1396 IEEE Symposium on Computers and 1397 Communications, July 2009. 1399 [IP-Passing-Protocol] Chen, Y., Hsu, C., and W. Yi, "An IP 1400 Passing Protocol for Vehicular Ad Hoc 1401 Networks with Network Fragmentation", 1402 Elsevier Computers & Mathematics with 1403 Applications, January 2012. 1405 [VANET-Geo-Routing] Tsukada, M., Jemaa, I., Menouar, H., 1406 Zhang, W., Goleva, M., and T. Ernst, 1407 "Experimental Evaluation for IPv6 over 1408 VANET Geographic Routing", 1409 IEEE International Wireless 1410 Communications and Mobile Computing 1411 Conference, June 2010. 1413 [H-DMM] Nguyen, T. and C. Bonnet, "A Hybrid 1414 Centralized-Distributed Mobility 1415 Management for Supporting Highly 1416 Mobile Users", IEEE International 1417 Conference on Communications, 1418 June 2015. 1420 [H-NEMO] Nguyen, T. and C. Bonnet, "A Hybrid 1421 Centralized-Distributed Mobility 1422 Management Architecture for Network 1423 Mobility", IEEE International 1424 Symposium on a World of Wireless, 1425 Mobile and Multimedia Networks, 1426 June 2015. 1428 [NEMO-LMS] Soto, I., Bernardos, C., Calderon, M., 1429 Banchs, A., and A. Azcorra, "NEMO- 1430 Enabled Localized Mobility Support for 1431 Internet Access in Automotive 1432 Scenarios", IEEE Communications 1433 Magazine, May 2009. 1435 [NEMO-VANET] Chen, Y., Hsu, C., and C. Cheng, 1436 "Network Mobility Protocol for 1437 Vehicular Ad Hoc Networks", 1438 Wiley International Journal of 1439 Communication Systems, November 2014. 1441 [PMIPv6-NEMO-Analysis] Lee, J., Ernst, T., and N. 1442 Chilamkurti, "Performance Analysis of 1443 PMIPv6-Based Network MObility for 1444 Intelligent Transportation Systems", 1445 IEEE Transactions on Vehicular 1446 Technology, January 2012. 1448 [Vehicular-Network-MM] Peng, Y. and J. Chang, "A Novel 1449 Mobility Management Scheme for 1450 Integration of Vehicular Ad Hoc 1451 Networks and Fixed IP Networks", 1452 Springer Mobile Networks and 1453 Applications, February 2010. 1455 [SDN-DMM] Nguyen, T., Bonnet, C., and J. Harri, 1456 "SDN-based Distributed Mobility 1457 Management for 5G Networks", 1458 IEEE Wireless Communications and 1459 Networking Conference, April 2016. 1461 [Vehicular-IP-MM] Cespedes, S., Shen, X., and C. Lazo, 1462 "IP Mobility Management for Vehicular 1463 Communication Networks: Challenges and 1464 Solutions", IEEE Communications 1465 Magazine, May 2011. 1467 [Securing-VCOMM] Fernandez, P., Santa, J., Bernal, F., 1468 and A. Skarmeta, "Securing Vehicular 1469 IPv6 Communications", 1470 IEEE Transactions on Dependable and 1471 Secure Computing, January 2016. 1473 [VNET-AAA] Moustafa, H., Bourdon, G., and Y. 1474 Gourhant, "Providing Authentication 1475 and Access Control in Vehicular 1476 Network Environment", IFIP TC- 1477 11 International Information Security 1478 Conference, May 2006. 1480 [IEEE-802.11p] IEEE Std 802.11p, "Part 11: Wireless 1481 LAN Medium Access Control (MAC) and 1482 Physical Layer (PHY) Specifications 1483 Amendment 6: Wireless Access in 1484 Vehicular Environments", June 2010. 1486 [IEEE-802.11-OCB] IEEE Std 802.11, "Part 11: Wireless 1487 LAN Medium Access Control (MAC) and 1488 Physical Layer (PHY) Specifications", 1489 February 2012. 1491 [WAVE-1609.0] IEEE 1609 Working Group, "IEEE Guide 1492 for Wireless Access in Vehicular 1493 Environments (WAVE) - Architecture", 1494 IEEE Std 1609.0-2013, March 2014. 1496 [WAVE-1609.2] IEEE 1609.2 Working Group, "IEEE 1497 Standard for Wireless Access in 1498 Vehicular Environments - Security 1499 Services for Applications and 1500 Management Messages", IEEE Std 1609.2- 1501 2016, March 2016. 1503 [WAVE-1609.3] IEEE 1609.3 Working Group, "IEEE 1504 Standard for Wireless Access in 1505 Vehicular Environments (WAVE) - 1506 Networking Services", IEEE Std 1609.3- 1507 2016, April 2016. 1509 [WAVE-1609.4] IEEE 1609.4 Working Group, "IEEE 1510 Standard for Wireless Access in 1511 Vehicular Environments (WAVE) - Multi- 1512 Channel Operation", IEEE Std 1609.4- 1513 2016, March 2016. 1515 [ETSI-GeoNetworking] ETSI Technical Committee Intelligent 1516 Transport Systems, "Intelligent 1517 Transport Systems (ITS); Vehicular 1518 Communications; GeoNetworking; Part 4: 1519 Geographical addressing and forwarding 1520 for point-to-point and point-to- 1521 multipoint communications; Sub-part 1: 1522 Media-Independent Functionality", 1523 ETSI EN 302 636-4-1, May 2014. 1525 [ETSI-GeoNetwork-IPv6] ETSI Technical Committee Intelligent 1526 Transport Systems, "Intelligent 1527 Transport Systems (ITS); Vehicular 1528 Communications; GeoNetworking; Part 6: 1529 Internet Integration; Sub-part 1: 1530 Transmission of IPv6 Packets over 1531 GeoNetworking Protocols", ETSI EN 302 1532 636-6-1, October 2013. 1534 [RFC3963] Devarapalli, V., Wakikawa, R., 1535 Petrescu, A., and P. Thubert, "Network 1536 Mobility (NEMO) Basic Support 1537 Protocol", RFC 3963, January 2005. 1539 [RFC4862] Thomson, S., Narten, T., and T. 1540 Jinmei, "IPv6 Stateless Address 1541 Autoconfiguration", RFC 4862, 1542 September 2007. 1544 [ISO-ITS-IPv6] ISO/TC 204, "Intelligent Transport 1545 Systems - Communications Access for 1546 Land Mobiles (CALM) - IPv6 1547 Networking", ISO 21210:2012, 1548 June 2012. 1550 Appendix A. Changes from 1551 draft-jeong-ipwave-vehicular-networking-survey-02 1553 The following changes are made from 1554 draft-jeong-ipwave-vehicular-networking-survey-02: 1556 o In Section 3, On-Board Unit (OBU) is defined as a new term and 1557 Traffic Control Center (TCC) is defined in more detail. 1559 o The contents are clarified with typo corrections. 1561 Authors' Addresses 1563 Jaehoon Paul Jeong 1564 Department of Software 1565 Sungkyunkwan University 1566 2066 Seobu-Ro, Jangan-Gu 1567 Suwon, Gyeonggi-Do 440-746 1568 Republic of Korea 1570 Phone: +82 31 299 4957 1571 Fax: +82 31 290 7996 1572 EMail: pauljeong@skku.edu 1573 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1574 Sandra Cespedes 1575 Department of Electrical Engineering 1576 Universidad de Chile 1577 Av. Tupper 2007, Of. 504 1578 Santiago, 8370451 1579 Chile 1581 Phone: +56 2 29784093 1582 EMail: scespede@niclabs.cl 1584 Nabil Benamar 1585 Department of Computer Sciences 1586 High School of Technology of Meknes 1587 Moulay Ismail University 1588 Morocco 1590 Phone: +212 6 70 83 22 36 1591 EMail: benamar73@gmail.com 1593 Jerome Haerri 1594 Communication Systems Department 1595 EURECOM 1596 Sophia-Antipolis 1597 France 1599 Phone: +33 4 93 00 81 34 1600 EMail: jerome.haerri@eurecom.fr 1602 Michelle Wetterwald 1603 FBConsulting 1604 21, Route de Luxembourg 1605 Wasserbillig, Luxembourg L-6633 1606 Luxembourg 1608 EMail: Michelle.Wetterwald@gmail.com