idnits 2.17.1 draft-ietf-ipwave-problem-statement-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2017) is 2489 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-iot-dns-autoconf-00 == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-vehicular-neighbor-discovery-00 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jeong 3 Internet-Draft Sungkyunkwan University 4 Intended status: Informational A. Petrescu 5 Expires: January 4, 2018 CEA, LIST 6 T. Oh 7 Rochester Institute of Technology 8 D. Liu 9 Alibaba 10 C. Perkins 11 Futurewei Inc. 12 July 3, 2017 14 Problem Statement for IP Wireless Access in Vehicular Environments 15 draft-ietf-ipwave-problem-statement-00 17 Abstract 19 This document provides a problem statement for IP Wireless Access in 20 Vehicular Environments (IPWAVE), that is, vehicular networks. This 21 document addresses the extension of IPv6 as the network layer 22 protocol in vehicular networks. It deals with networking issues in 23 one-hop communication between a Road-Side Unit (RSU) and a vehicle, 24 that is, "vehicle-to-infrastructure" (V2I) communication. It also 25 deals with one-hop communication between two neighboring vehicles, 26 that is, "vehicle-to-vehicle" (V2V) communication. Major issues 27 about IPv6 in vehicular networks include neighbor discovery protocol, 28 stateless address autoconfiguration, and DNS configuration for 29 Internet connectivity. When a vehicle and an RSU have an internal 30 network (respectively), the document discusses internetworking issues 31 between two internal networks through either V2I or V2V 32 communication. Those issues include prefix discovery, prefix 33 exchange, service discovery, security, and privacy. 35 Status of This Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 This Internet-Draft will expire on January 4, 2018. 57 Copyright Notice 59 Copyright (c) 2017 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 76 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 5. Internetworking between Vehicle Network and RSU Network . . . 6 79 5.1. V2I-Based Internetworking . . . . . . . . . . . . . . . . 6 80 5.2. The Use Cases of V2I-Based Internetworking . . . . . . . . 7 81 6. Internetworking between Two Vehicle Networks . . . . . . . . . 8 82 6.1. V2V-Based Internetworking . . . . . . . . . . . . . . . . 8 83 6.2. The Use Cases of V2V-Based Internetworking . . . . . . . . 9 84 7. IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . . . 10 85 8. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . 10 86 9. IP Address Autoconfiguration . . . . . . . . . . . . . . . . . 11 87 10. DNS Naming Service . . . . . . . . . . . . . . . . . . . . . . 11 88 11. IP Mobility Management . . . . . . . . . . . . . . . . . . . . 12 89 12. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 12 90 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 91 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 93 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 16.1. Normative References . . . . . . . . . . . . . . . . . . . 14 95 16.2. Informative References . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 Recently, Vehicular Ad Hoc Networks (VANET) have been focusing on 100 intelligent services in road networks, such as driving safety, 101 efficient driving, and entertainment. For VANET, Dedicated Short- 102 Range Communications (DSRC) [DSRC-WAVE] was standardized as Wireless 103 Access in Vehicular Environments (WAVE) standards by IEEE. The WAVE 104 standards include IEEE 802.11p [IEEE-802.11p] for WAVE Media Access 105 Control (MAC) and Physical Layer (PHY), IEEE 1609.0 for WAVE 106 architecture [WAVE-1609.0], IEEE 1609.2 for WAVE security services 107 [WAVE-1609.2], IEEE 1609.3 for WAVE networking services 108 [WAVE-1609.3], and IEEE 1609.4 for WAVE multi-channel operation 109 [WAVE-1609.4]. 802.11p extends IEEE 802.11a [IEEE-802.11a] by 110 consideration of vehicular characteristics such as a vehicle's 111 velocity and collision avoidance. IEEE 802.11p has been published as 112 IEEE 802.11 Outside the Context of a Basic Service Set (OCB) 113 [IEEE-802.11-OCB] in 2012. 115 Now the deployment of VANET is indicated in real road environments 116 along with the popularity of smart devices (e.g., smartphone and 117 tablet). Many automobile vendors (e.g., Benz, BMW, Ford, Honda, and 118 Toyota) now consider automobiles as computer systems instead of 119 mechanical machines, since many current vehicles are operating with 120 many sensors and software. Google has advanced self-driving vehicles 121 with many special software modules and hardware devices to support 122 computer-vision-based object recognition, machine-learning-based 123 decision-making, and GPS navigation. 125 Vehicular networking research is enabling vehicles to communicate 126 with each other and infrastructure nodes in the Internet by using 127 TCP/IP, IP address autoconfiguration, routing, handover, and mobility 128 management [ID-VN-Survey]. IPv6 [RFC2460] is suitable for vehicular 129 networks since the protocol has abundant address space and 130 autoconfiguration features, and can be extended by way of new 131 protocol headers. 133 This document identifies issues of IPv6-based vehicle-to- 134 infrastructure (V2I) networking and vehicle-to-vehicle (V2V) 135 networking, such as IPv6 addressing [RFC4291], neighbor discovery 136 [RFC4861], address autoconfiguration [RFC4862], and DNS naming 137 service [RFC8106][RFC3646][ID-DNSNA]. This document also identifies 138 issues of internetworking between two internal networks when a 139 vehicle and/or an RSU have an internal network. Those issues include 140 prefix discovery, prefix exchange, and service discovery in the 141 inter-connected internal networks. In addition, the document 142 analyzes the characteristics of vehicular networks to consider the 143 design of V2I or V2V networking. 145 2. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 3. Terminology 153 This document uses the terminology described in [RFC4861] and 154 [RFC4862]. In addition, five new terms are defined below: 156 o Road-Side Unit (RSU): A node that has a wireless communication 157 device (e.g., DSRC) to communicate with vehicles and is connected 158 to the Internet as a router or switch for packet forwarding. An 159 RSU is deployed either at an intersection or in a road segment. 161 o On-Board Unit (OBU): A node that has a wireless communication 162 device (e.g., DSRC) to communicate with other OBUs and RSUs. An 163 OBU is mounted on a vehicle. It is assumed that a radio 164 navigation receiver (e.g., Global Positioning System (GPS)) is 165 included in a vehicle with an OBU for efficient navigation. 167 o Fixed Network: An RSU can have an internal network consisting of 168 multiple subnets. This internal network is a fixed network since 169 the RSU is fixed in the road network. 171 o Moving Network: A vehicle can have an internal network consisting 172 of multiple subnets. This internal network is called a moving 173 network since the vehicle is moving in the road network. 175 o Traffic Control Center (TCC): A node that maintains road 176 infrastructure information (e.g., RSUs, traffic signals, and loop 177 detectors), vehicular traffic statistics (e.g., average vehicle 178 speed and vehicle inter-arrival time per road segment), and 179 vehicle information (e.g., a vehicle's identifier, position, 180 direction, speed, and trajectory as a navigation path). TCC is 181 included in a vehicular cloud for vehicular networks. Exemplary 182 functions of TCC include the management of evacuation routes, the 183 monitoring of pedestrians and bike traffic, the monitoring of 184 real-time transit operations, and real-time responsive traffic 185 signal systems. Thus, TCC is the nerve center of most freeway 186 management sytems such that data is collected, processed, and 187 fused with other operational and control data, and is also 188 synthesized to produce "information" distributed to stakeholders, 189 other agencies, and traveling public. TCC is called Traffic 190 Management Center (TMC) in the US. TCC can communicate with road 191 infrastructure nodes (e.g., RSUs, traffic signals, and loop 192 detectors) to share measurement data and management information by 193 an application-layer protocol. 195 4. Overview 197 This document provides a problem statement of IPv6-based V2I and V2V 198 networking. The main focus is one-hop networking between a vehicle 199 and an RSU or between two neighboring vehicles. However, this 200 document does not address all multi-hop networking scenarios of 201 vehicles and RSUs. Also, the problems focus on the network layer 202 (i.e., IPv6 protocol stack) rather than the MAC layer and the 203 transport layer (e.g., TCP, UDP, and SCTP). 205 Figure 1 shows a network configuration for V2I and V2V networking in 206 a road network. The two RSUs (RSU1 and RSU2) are deployed in the 207 road network and are connected to a Vehicular Cloud through the 208 Internet. TCC is connected to the Vehicular Cloud and the two 209 vehicles (Vehicle1 and Vehicle2) are wirelessly connected to RSU1, 210 and the last vehicle (Vehicle3) is wirelessly connected to RSU2. 211 Vehicle1 can communicate with Vehicle2 via V2V communication, and 212 Vehicle2 can communicate with Vehicle3 via V2V communication. 213 Vehicle1 can communicate with Vehicle3 via RSU1 and RSU2 via V2I 214 communication. 216 *-------------* 217 * * .-------. 218 * Vehicular Cloud *<------>| TCC | 219 * * ._______. 220 *-------------* 221 ^ ^ 222 | | 223 | | 224 v v 225 .--------. .--------. 226 | RSU1 |<----------->| RSU2 | 227 .________. .________. 228 ^ ^ ^ 229 : : : 230 : : : 231 v v v 232 .--------. .--------. .--------. 233 |Vehicle1|=> |Vehicle2|=> |Vehicle3|=> 234 | |<....>| |<....>| | 235 .________. .________. .________. 237 <----> Wired Link <....> Wireless Link => Moving Direction 239 Figure 1: The Network Configuration for Vehicular Networking 241 5. Internetworking between Vehicle Network and RSU Network 243 This section discusses the internetworking between a vehicle's moving 244 network and an RSU's fixed network. 246 5.1. V2I-Based Internetworking 248 As shown in Figure 2, the vehicle's moving network and the RSU's 249 fixed network are internal networks having multiple subnets and 250 having an edge router for the communication with another vehicle or 251 RSU. The method of prefix assignment for each subnet inside the 252 vehicle's mobile network and the RSU's fixed network is out of scope 253 for this document. The internetworking between two internal networks 254 via either V2I or V2V communication requires an exchange of network 255 prefix and other parameters. 257 The network parameter discovery collects networking information for 258 an IP communication between a vehicle and an RSU or between two 259 neighboring vehicles, such as link layer, MAC layer, and IP layer 260 information. The link layer information includes wireless link layer 261 parameters, such as wireless media (e.g., IEEE 802.11 OCB, LTE D2D, 262 Bluetooth, and LiFi) and a transmission power level. The MAC layer 263 information includes the MAC address of an external network interface 264 for the internetworking with another vehicle or RSU. The IP layer 265 information includes the IP address and prefix of an external network 266 interface for the internetworking with another vehicle or RSU. 268 Once the network parameter discovery and prefix exchange operations 269 are performed, unicast of packets can be supported between the 270 vehicle's moving network and the RSU's fixed network. The DNS naming 271 service should be supported for the DNS name resolution for hosts or 272 servers residing either in the vehicle's moving network or the RSU's 273 fixed network. 275 Figure 2 shows internetworking between the vehicle's moving network 276 and the RSU's fixed network. There exists an internal network 277 (Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server 278 (RDNSS1), the two hosts (Host1 and Host2), and the two routers 279 (Router1 and Router2). There exists another internal network (Fixed 280 Network1) inside RSU1. RSU1 has the DNS Server (RDNSS2), one host 281 (Host3), the two routers (Router3 and Router4), and the collection of 282 servers (Server1 to ServerN) for various services in the road 283 networks, such as the emergency notification and navigation. 284 Vehicle1's Router1 and RSU1's Router3 use 2001:DB8:1:1::/64 for an 285 external link (e.g., DSRC) for I2V networking. 287 This document addresses the internetworking between the vehicle's 288 moving network and the RSU's fixed network in Figure 2 and the 289 required enhancement of IPv6 protocol suite for the V2I networking 290 service. 292 (*)<..........>(*) 293 | | 2001:DB8:1:1::/64 294 .------------------------------. .---------------------------------. 295 | | | | | | 296 | .-------. .------. .-------. | | .-------. .------. .-------. | 297 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 298 | ._______. .______. ._______. | | ._______. .______. ._______. | 299 | ^ ^ ^ | | ^ ^ ^ | 300 | | | | | | | | | | 301 | v v v | | v v v | 302 | ---------------------------- | | ------------------------------- | 303 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 304 | | | | | | 305 | v | | v | 306 | .-------. .-------. | | .-------. .-------. .-------. | 307 | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | 308 | ._______. ._______. | | ._______. ._______. ._______. | 309 | ^ ^ | | ^ ^ ^ | 310 | | | | | | | | | 311 | v v | | v v v | 312 | ---------------------------- | | ------------------------------- | 313 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 314 .______________________________. ._________________________________. 315 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 317 <----> Wired Link <....> Wireless Link (*) Antenna 319 Figure 2: Internetworking between Vehicle Network and RSU Network 321 5.2. The Use Cases of V2I-Based Internetworking 323 The use cases of V2I networking include navigation service, fuel- 324 efficient speed recommendation service, and accident notification 325 service. 327 A navigation service, such as Self-Adaptive Interactive Navigation 328 Tool (called SAINT) [SAINT], using V2I networking interacts with TCC 329 for the global road traffic optimization and can guide individual 330 vehicles for appropriate navigation paths in real time. The enhanced 331 SAINT (called SAINT+) [SAINTplus] can give the fast moving paths for 332 emergency vehicles (e.g., ambulance and fire engine) toward accident 333 spots while providing efficient detour paths to vehicles around the 334 accidents spots. 336 The emergency communication between accident vehicles (or emergency 337 vehicles) and TCC can be performed via either RSU or 4G-LTE networks. 338 The First Responder Network Authority (FirstNet) [FirstNet] is 339 provided by the US government to establish, operate, and maintain an 340 interoperable public safety broadband network for safety and security 341 network services, such as emergency calls. The current RAN is mainly 342 constructed by 4G-LTE, but DSRC-based vehicular networks can be used 343 in near future. 345 A pedestrian protection service, such as Safety-Aware Navigation 346 Application (called SANA) [SANA], using V2I networking can reduce the 347 collision of a pedestrian and a vehicle, which have a smartphone, in 348 a road network. Vehicles and pedestrians can communicate with each 349 other via an RSU that delivers scheduling information for wireless 350 communication to save the smartphones' battery. 352 6. Internetworking between Two Vehicle Networks 354 This section discusses the internetworking between the moving 355 networks of two neighboring vehicles. 357 6.1. V2V-Based Internetworking 359 In Figure 3, the prefix assignment for each subnet inside each 360 vehicle's mobile network is done through a prefix delegation 361 protocol. 363 (*)<..........>(*) 364 | | 2001:DB8:1:1::/64 365 .------------------------------. .---------------------------------. 366 | | | | | | 367 | .-------. .------. .-------. | | .-------. .------. .-------. | 368 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 369 | ._______. .______. ._______. | | ._______. .______. ._______. | 370 | ^ ^ ^ | | ^ ^ ^ | 371 | | | | | | | | | | 372 | v v v | | v v v | 373 | ---------------------------- | | ------------------------------- | 374 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:30:1::/64 | 375 | | | | | | 376 | v | | v | 377 | .-------. .-------. | | .-------. .-------. | 378 | | Host2 | |Router2| | | |Router4| | Host4 | | 379 | ._______. ._______. | | ._______. ._______. | 380 | ^ ^ | | ^ ^ | 381 | | | | | | | | 382 | v v | | v v | 383 | ---------------------------- | | ------------------------------- | 384 | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | 385 .______________________________. ._________________________________. 386 Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) 388 <----> Wired Link <....> Wireless Link (*) Antenna 390 Figure 3: Internetworking between Two Vehicle Networks 392 Figure 3 shows internetworking between the moving networks of two 393 neighboring vehicles. There exists an internal network (Moving 394 Network1) inside Vehicle1. Vehicle1 has the DNS Server (RDNSS1), the 395 two hosts (Host1 and Host2), and the two routers (Router1 and 396 Router2). There exists another internal network (Moving Network2) 397 inside Vehicle2. Vehicle2 has the DNS Server (RDNSS2), the two hosts 398 (Host3 and Host4), and the two routers (Router3 and Router4). 399 Vehicle1's Router1 and Vehicle2's Router3 use 2001:DB8:1:1::/64 for 400 an external link (e.g., DSRC) for V2V networking. 402 This document describes the internetworking between the moving 403 networks of two neighboring vehicles in Figure 3 and the required 404 enhancement of IPv6 protocol suite for the V2V networking service. 406 6.2. The Use Cases of V2V-Based Internetworking 408 The use cases of V2V networking include context-aware navigator for 409 driving safety, cooperative adaptive cruise control in an urban 410 roadway, and platooning in a highway. These are three techniques 411 that will be important elements for self-driving. 413 Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers 414 to drive safely by letting the drivers recognize dangerous obstacles 415 and situations, including neighboring vehicles that might cause a 416 collision. 418 Cooperative Adaptive Cruise Control (CACC) [CA-Cuise-Control] helps 419 vehicles to adapt their speed autonomously according to the mobility 420 of their predecessor and successor vehicles in an urban roadway or a 421 highway. 423 Platooning [Truck-Platooning] allows a series of vehicles (e.g., 424 trucks) to move together with a very short inter-distance. This 425 platooning can maximize the throughput of vehicular traffic in a 426 highway. 428 7. IPv6 Addressing 430 This section discusses IP addressing for the V2I and V2V networking. 431 There are two approaches for IPv6 addressing in vehicular networks. 432 The first is to use unique local IPv6 unicast addresses (ULAs) for 433 vehicular networks [RFC4193]. The other is to use global IPv6 434 addresses for the interoperability with the Internet [RFC4291]. The 435 former approach is often used by Mobile Ad Hoc Networks (MANET) for 436 an isolated subnet. This approach can support the emergency 437 notification service and navigation service in road networks. 438 However, for general Internet services (e.g., email access, web 439 surfing and entertainment services), the latter approach is required. 441 For global IP addresses, there are two choices: a multi-link subnet 442 approach for multiple RSUs and a single subnet approach per RSU. In 443 the multi-link subnet approach, which is similar to ULA for MANET, 444 RSUs play a role of layer-2 (L2) switches and the router 445 interconnected with the RSUs is required. The router maintains the 446 location of each vehicle belonging to an RSU for L2 switching. In 447 the single subnet approach per RSU, which is similar to the legacy 448 subnet in the Internet, each RSU plays the role of a (layer-3) 449 router. 451 8. Neighbor Discovery 453 Neighbor Discovery (ND) is a core part of IPv6 protocol suite 454 [RFC4861]. This section discusses an extension of ND for V2I 455 networking. The vehicles are moving fast within the communication 456 coverage of an RSU. The external link between the vehicle and the 457 RSU can be used for V2I networking, as shown in Figure 2. 459 ND time-related parameters such as router lifetime and Neighbor 460 Advertisement (NA) interval should be adjusted for high-speed 461 vehicles and vehicle density. As vehicles move faster, the NA 462 interval should decrease for the NA messages to reach the neighboring 463 vehicles promptly. Also, as vehicle density is higher, the NA 464 interval should increase for the NA messages to collide with other NA 465 messages with lower collision probability. 467 9. IP Address Autoconfiguration 469 This section discusses IP address autoconfiguration for V2I 470 networking. For IP address autoconfiguration, high-speed vehicles 471 should also be considered. The legacy IPv6 stateless address 472 autoconfiguration [RFC4862], as shown in Figure 1, may not perform 473 well. This is because vehicles can travel through the communication 474 coverage of the RSU faster than the completion of address 475 autoconfiguration (with Router Advertisement and Duplicate Address 476 Detection (DAD) procedures). 478 To mitigate the impact of vehicle speed on address configuration, the 479 RSU can perform IP address autoconfiguration including the DAD 480 proactively as an ND proxy on behalf of the vehicles. If vehicles 481 periodically report their movement information (e.g., position, 482 trajectory, speed, and direction) to TCC, TCC can coordinate the RSUs 483 under its control for the proactive IP address configuration of the 484 vehicles with the mobility information of the vehicles. DHCPv6 (or 485 Stateless DHCPv6) can be used for the IP address autoconfiguration 486 [RFC3315][RFC3736]. 488 In the case of a single subnet per RSU, the delay to change IPv6 489 address through DHCPv6 procedure is not suitable since vehicles move 490 fast. Some modifications are required for the high-speed vehicles 491 that quickly crosses the communication coverages of multiple RSUs. 492 Some modifications are required for both stateless address 493 autoconfiguration and DHCPv6. Mobile IPv6 (MIPv6) can be used for 494 the fast update of a vehicle's care-of address for the current RSU to 495 communicate with the vehicle [RFC6275]. 497 10. DNS Naming Service 499 This section suggests a DNS naming service for V2I networking. The 500 DNS naming service consists of the DNS name resolution and DNS name 501 autoconfiguration. 503 The DNS name resolution translates a DNS name into the corresponding 504 IPv6 address through a recursive DNS server (RDNSS) within the 505 vehicle's moving network and DNS servers in the Internet 506 [RFC1034][RFC1035], which are located outside the VANET. The RDNSSes 507 can be advertised by RA DNS Option or DHCP DNS Option into the 508 subnets within the vehicle's moving network. 510 The DNS name autoconfiguration makes a unique DNS name for hosts 511 within a vehicle's moving network and registers it into a DNS server 512 within the vehicle's moving network [ID-DNSNA]. With Vehicle 513 Identification Number (VIN), a unique DNS suffix can be constructed 514 as a DNS domain for the vehicle's moving network. Each host can 515 generate its DNS name and register it into the local RDNSS in the 516 vehicle's moving network. 518 11. IP Mobility Management 520 This section discusses an IP mobility support in V2I networking. In 521 a single subnet per RSU, vehicles continually cross the communication 522 coverages of adjacent RSUs. During this crossing, TCP/UDP sessions 523 can be maintained through IP mobility support, such as MIPv6 524 [RFC6275], Proxy MIPv6 [RFC5213][RFC5949], and Distributed Mobility 525 Management (DMM) [RFC7333][RFC7429]. Since vehicles move fast along 526 roadways, high speed should be enabled by the parameter configuration 527 in the IP mobility management. With the periodic reports of the 528 movement information from the vehicles, TCC can coordinate RSUs and 529 other network compoments under its control for the proactive mobility 530 management of the vehicles along the movement of the vehicles. 532 To support the mobility of a vehicle's moving network, Network 533 Mobility Basic Support Protocol (NEMO) can be used [RFC3963]. Like 534 MIPv6, the high speed of vehicles should be considered for a 535 parameter configuration in NEMO. 537 12. Service Discovery 539 Vehicles need to discover services (e.g., road condition 540 notification, navigation service, and entertainment) provided by 541 infrastructure nodes in a fixed network via RSU, as shown in 542 Figure 2. During the passing of an intersection or road segment with 543 an RSU, vehicles should perform this service discovery quickly. 545 Since with the existing service discovery protocols, such as DNS- 546 based Service Discovery (DNS-SD) [RFC6763] and Multicast DNS (mDNS) 547 [RFC6762], the service discovery will be performed with message 548 exchanges, the discovery delay may hinder the prompt service usage of 549 the vehicles from the fixed network via RSU. One feasible approach 550 is a piggyback service discovery during the prefix exchange of 551 network prefixes for the networking between a vehicle's moving 552 network and an RSU's fixed network. That is, the message of the 553 prefix exchange can include service information, such as each 554 service's IP address, transport layer protocol, and port number. 556 IPv6 ND can be extended for the prefix and service discovery 557 [ID-Vehicular-ND]. Vehicles and RSUs can announce the network 558 prefixes and services in their internal network via ND messages 559 containing ND options with the prefix and service information. Since 560 it does not need any additional service discovery protocol in the 561 application layer, this ND-based approach can provide vehicles and 562 RSUs with the rapid discovery of the network prefixes and services. 564 13. Security Considerations 566 Security and privacy are paramount in the V2I and V2V networking in 567 VANET. Only authorized vehicles should be allowed to use the V2I and 568 V2V networking in VANET. A Vehicle Identification Number (VIN) and a 569 user certificate along with in-vehicle device's identifier generation 570 can be used to authenticate a vehicle and the user through a road 571 infrastructure node, such as an RSU connected to an authentication 572 server in TCC. Transport Layer Security (TLS) certificates can also 573 be used for secure vehicle communications. 575 A security scheme providing authentication and access control should 576 be provided in vehicular networks [VN-Security]. With this scheme, 577 the security and privacy can be supported for safe and reliable data 578 services in vehicular networks. 580 To prevent an adversary from tracking a vehicle by with its MAC 581 address or IPv6 address, each vehicle should periodically update its 582 MAC address and the corresponding IPv6 address as suggested in 583 [RFC4086][RFC4941]. Such an update of the MAC and IPv6 addresses 584 should not interrupt the communications between a vehicle and an RSU. 586 To protect packets exchanged between a vehicle and an RSU, packets 587 should be encrypted. To assure confidentiality, efficient encryption 588 and decryption algorithms can be used along with a key management 589 scheme such as Internet Key Exchange version 2 (IKEv2) and Internet 590 Protocol Security (IPsec) [Securing-VCOMM]. 592 14. Contributors 594 IPWAVE is a group effort. The following people actively contributed 595 to the problem statement text: Nabil Benamar (Moulay Ismail 596 University), Rex Buddenberg (Naval Postgraduate School), Sandra 597 Cespedes (Universidad de Chile), Thierry Ernst (YoGoKo), Jerome 598 Haerri (Eurecom), Richard Roy (MIT), and Francois Simon (Pilot). 600 15. Acknowledgments 602 This work was supported by Basic Science Research Program through the 603 National Research Foundation of Korea (NRF) funded by the Ministry of 604 Education (2017R1B1A1B03035885). This work was supported in part by 605 the Global Research Laboratory Program (2013K1A1A2A02078326) through 606 NRF and the DGIST Research and Development Program (CPS Global 607 Center) funded by the Ministry of Science, ICT & Future Planning. 609 16. References 611 16.1. Normative References 613 [RFC2119] Bradner, S., "Key words for use in RFCs to 614 Indicate Requirement Levels", BCP 14, RFC 2119, 615 March 1997. 617 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, 618 Version 6 (IPv6) Specification", RFC 2460, 619 December 1998. 621 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 622 Unicast Addresses", RFC 4193, October 2005. 624 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 625 Addressing Architecture", RFC 4291, 626 February 2006. 628 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. 629 Soliman, "Neighbor Discovery for IP Version 6 630 (IPv6)", RFC 4861, September 2007. 632 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 633 Stateless Address Autoconfiguration", RFC 4862, 634 September 2007. 636 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. 637 Madanapalli, "IPv6 Router Advertisement Options 638 for DNS Configuration", RFC 8106, March 2017. 640 [RFC3646] Droms, R., Ed., "DNS Configuration options for 641 Dynamic Host Configuration Protocol for IPv6 642 (DHCPv6)", RFC 3646, December 2003. 644 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., 645 Perkins, C., and M. Carney, "Dynamic Host 646 Configuration Protocol for IPv6 (DHCPv6)", 647 RFC 3315, July 2003. 649 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration 650 Protocol (DHCP) Service for IPv6", RFC 3736, 651 April 2004. 653 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, 654 "Mobility Support in IPv6", RFC 6275, July 2011. 656 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., 657 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 658 RFC 5213, August 2008. 660 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., 661 and F. Xia, "Fast Handovers for Proxy Mobile 662 IPv6", RFC 5949, September 2010. 664 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and 665 P. Thubert, "Network Mobility (NEMO) Basic 666 Support Protocol", RFC 3963, January 2005. 668 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. 669 Korhonen, "Requirements for Distributed Mobility 670 Management", RFC 7333, August 2014. 672 [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and 673 CJ. Bernardos, "Distributed Mobility Management: 674 Current Practices and Gap Analysis", RFC 7429, 675 January 2015. 677 [RFC1034] Mockapetris, P., "Domain Names - Concepts and 678 Facilities", RFC 1034, November 1987. 680 [RFC1035] Mockapetris, P., "Domain Names - Implementation 681 and Specification", RFC 1035, November 1987. 683 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 684 Discovery", RFC 6763, February 2013. 686 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", 687 RFC 6762, February 2013. 689 16.2. Informative References 691 [DSRC-WAVE] Morgan, Y., "Notes on DSRC & WAVE Standards 692 Suite: Its Architecture, Design, and 693 Characteristics", IEEE Communications Surveys & 694 Tutorials, 12(4), 2012. 696 [IEEE-802.11p] IEEE Std 802.11p, "Part 11: Wireless LAN Medium 697 Access Control (MAC) and Physical Layer (PHY) 698 Specifications Amendment 6: Wireless Access in 699 Vehicular Environments", June 2010. 701 [IEEE-802.11a] IEEE Std 802.11a, "Part 11: Wireless LAN Medium 702 Access Control (MAC) and Physical Layer (PHY) 703 specifications: High-speed Physical Layer in the 704 5 GHZ Band", September 1999. 706 [IEEE-802.11-OCB] IEEE Std 802.11, "Part 11: Wireless LAN Medium 707 Access Control (MAC) and Physical Layer (PHY) 708 Specifications", February 2012. 710 [WAVE-1609.0] IEEE 1609 Working Group, "IEEE Guide for Wireless 711 Access in Vehicular Environments (WAVE) - 712 Architecture", IEEE Std 1609.0-2013, March 2014. 714 [WAVE-1609.2] IEEE 1609 Working Group, "IEEE Standard for 715 Wireless Access in Vehicular Environments - 716 Security Services for Applications and Management 717 Messages", IEEE Std 1609.2-2016, March 2016. 719 [WAVE-1609.3] IEEE 1609 Working Group, "IEEE Standard for 720 Wireless Access in Vehicular Environments (WAVE) 721 - Networking Services", IEEE Std 1609.3-2016, 722 April 2016. 724 [WAVE-1609.4] IEEE 1609 Working Group, "IEEE Standard for 725 Wireless Access in Vehicular Environments (WAVE) 726 - Multi-Channel Operation", IEEE Std 1609.4-2016, 727 March 2016. 729 [ID-VN-Survey] Jeong, J., Ed., Cespedes, S., Benamar, N., 730 Haerri, J., and M. Wetterwald, "Survey on IP- 731 based Vehicular Networking for Intelligent 732 Transportation Systems", 733 draft-jeong-ipwave-vehicular-networking-survey-03 734 (work in progress), June 2017. 736 [ID-DNSNA] Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 737 Autoconfiguration for Internet of Things 738 Devices", draft-jeong-ipwave-iot-dns-autoconf-00 739 (work in progress), March 2017. 741 [ID-Vehicular-ND] Jeong, J., Ed., Shen, Y., Jo, Y., Jeong, J., and 742 J. Lee, "IPv6 Neighbor Discovery for Prefix and 743 Service Discovery in Vehicular Networks", draft- 744 jeong-ipwave-vehicular-neighbor-discovery-00 745 (work in progress), March 2017. 747 [VN-Security] Moustafa, H., Bourdon, G., and Y. Gourhant, 748 "Providing Authentication and Access Control in 749 Vehicular Network Environment", IFIP TC- 750 11 International Information Security Conference, 751 May 2006. 753 [Securing-VCOMM] Fernandez, P., Santa, J., Bernal, F., and A. 754 Skarmeta, "Securing Vehicular IPv6 755 Communications", IEEE Transactions on Dependable 756 and Secure Computing, January 2016. 758 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 759 "Randomness Requirements for Security", RFC 4086, 760 June 2005. 762 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 763 Extensions for Stateless Address 764 Autoconfiguration in IPv6", RFC 4941, 765 September 2007. 767 [SAINT] Jeong, J., Jeong, H., Lee, E., Oh, T., and D. Du, 768 "SAINT: Self-Adaptive Interactive Navigation Tool 769 for Cloud-Based Vehicular Traffic Optimization", 770 IEEE Transactions on Vehicular Technology, Vol. 771 65, No. 6, June 2016. 773 [SAINTplus] Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., 774 and D. Du, "SAINT+: Self-Adaptive Interactive 775 Navigation Tool+ for Emergency Service Delivery 776 Optimization", IEEE Transactions on Intelligent 777 Transportation Systems, June 2017. 779 [SANA] Hwang, T. and J. Jeong, "SANA: Safety-Aware 780 Navigation Application for Pedestrian Protection 781 in Vehicular Networks", Springer Lecture Notes in 782 Computer Science (LNCS), Vol. 9502, 783 December 2015. 785 [FirstNet] U.S. National Telecommunications and Information 786 Administration (NTIA), "First Responder Network 787 Authority (FirstNet)", [Online] 788 Available: https://www.firstnet.gov/, 2012. 790 [CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A 791 Framework of Context-Awareness Safety Driving in 792 Vehicular Networks", International Workshop on 793 Device Centric Cloud (DC2), March 2016. 795 [CA-Cuise-Control] California Partners for Advanced Transportation 796 Technology (PATH), "Cooperative Adaptive Cruise 797 Control", [Online] Available: http:// 798 www.path.berkeley.edu/research/ 799 automated-and-connected-vehicles/ 800 cooperative-adaptive-cruise-control, 2017. 802 [Truck-Platooning] California Partners for Advanced Transportation 803 Technology (PATH), "Automated Truck Platooning", 804 [Online] Available: http://www.path.berkeley.edu/ 805 research/automated-and-connected-vehicles/ 806 truck-platooning, 2017. 808 Authors' Addresses 810 Jaehoon Paul Jeong 811 Department of Software 812 Sungkyunkwan University 813 2066 Seobu-Ro, Jangan-Gu 814 Suwon, Gyeonggi-Do 440-746 815 Republic of Korea 817 Phone: +82 31 299 4957 818 Fax: +82 31 290 7996 819 EMail: pauljeong@skku.edu 820 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 822 Alex Petrescu 823 CEA, LIST 824 CEA Saclay 825 Gif-sur-Yvette, Ile-de-France 91190 826 France 828 Phone: +33169089223 829 EMail: Alexandre.Petrescu@cea.fr 831 Tae (Tom) Oh 832 Department of Information Sciences and Technologies 833 Rochester Institute of Technology 834 One Lomb Memorial Drive 835 Rochester, NY 14623-5603 836 USA 838 Phone: +1 585 475 7642 839 EMail: Tom.Oh@rit.edu 840 Dapeng Liu 841 Alibaba 842 Beijing, Beijing 100022 843 China 845 Phone: +86 13911788933 846 EMail: max.ldp@alibaba-inc.com 848 Charles E. Perkins 849 Futurewei Inc. 850 2330 Central Expressway 851 Santa Clara, CA 95050 852 USA 854 Phone: +1 408 330 4586 855 EMail: charliep@computer.org