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