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