idnits 2.17.1 draft-jeong-ipwave-v2i-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 (March 13, 2017) is 2599 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 7333 ** Downref: Normative reference to an Informational RFC: RFC 7429 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 7 errors (**), 0 flaws (~~), 2 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: Standards Track T. Oh 5 Expires: September 14, 2017 Rochester Institute of Technology 6 March 13, 2017 8 Problem Statement for Vehicle-to-Infrastructure Networking 9 draft-jeong-ipwave-v2i-problem-statement-00 11 Abstract 13 This document specifies the problem statement for IPv6-based vehicle- 14 to-infrastructure networking. Dedicated Short-Range Communications 15 (DSRC) is standardized as IEEE 802.11p for the wireless media access 16 in vehicular networks. This document addresses the extension of IPv6 17 as the network layer protocol in vehicular networks and is focused on 18 the networking issues in one-hop communication between a Road-Side 19 Unit (RSU) and vehicle. The RSU is connected to the Internet and 20 allows vehicles to have the Internet access if connected. The major 21 issues of including IPv6 in vehicular networks are neighbor discovery 22 protocol, stateless address autoconfiguration, and DNS configuration 23 for the Internet connectivity over DSRC. Also, when a vehicle and an 24 RSU have an internal network, respectively, the document discusses 25 the issues of the internetworking between the vehicle's internal 26 network and the RSU's internal network (e.g., prefix discovery, 27 prefix exchange, and service discovery), and also security and 28 privacy issues. 30 Status of This Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt. 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 This Internet-Draft will expire on September 14, 2017. 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 72 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 5. Internetworking between the Vehicle and RSU Networks . . . . . 6 75 6. IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . . . 7 76 7. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . 7 77 8. IP Address Autoconfiguration . . . . . . . . . . . . . . . . . 7 78 9. DNS Naming Service . . . . . . . . . . . . . . . . . . . . . . 8 79 10. IP Mobility Management . . . . . . . . . . . . . . . . . . . . 8 80 11. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 9 81 12. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 83 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 14.1. Normative References . . . . . . . . . . . . . . . . . . 10 85 14.2. Informative References . . . . . . . . . . . . . . . . . 12 86 Appendix A. Changes from 87 draft-jeong-its-v2i-problem-statement-02 . . . . . . 13 89 1. Introduction 91 Recently, Vehicular Ad Hoc Networks (VANET) have been focusing on 92 intelligent services in road networks, such as driving safety, 93 efficient driving, and entertainment. For this VANET, Dedicated 94 Short-Range Communications (DSRC) [DSRC-WAVE] has been standardized 95 as IEEE 802.11p [IEEE-802.11p], which is an extension of IEEE 802.11a 96 [IEEE-802.11a] with a consideration of the vehicular network's 97 characteristics such as a vehicle's velocity and collision avoidance. 99 Now the deployment of VANET is demanded into real road environments 100 along with the popularity of smart devices (e.g., smartphone and 101 tablet). Many automobile vendors (e.g., Benz, BMW, Ford, Honda, and 102 Toyota) started to consider automobiles as computers instead of 103 mechanical machines since many current vehicles are operating with 104 many sensors and software. Also, Google made a great advancement in 105 self-driving vehicles with many special software modules and hardware 106 devices to support computer-vision-based object recognition, machine- 107 learning-based decision-making, and GPS navigation. 109 With this trend, vehicular networking has been researched to enable 110 vehicles to communicate with other vehicles and infrastructure nodes 111 in the Internet by using TCP/IP technologies [ID-VN-Survey], such as 112 IP address autoconfiguration, routing, handover, and mobility 113 management. IPv6 [RFC2460] is suitable for vehicular networks since 114 the protocol has abundant address space, autoconfiguration features, 115 and protocol extension ability through extension headers. 117 This document specifies the problem statement of IPv6-based vehicle- 118 to-infrastructure (V2I) networking, such as IPv6 addressing 119 [RFC4291], neighbor discovery [RFC4861], address autoconfiguration 120 [RFC4862], and DNS naming service [RFC6106][RFC3646][ID-DNSNA]. This 121 document also specifies the problem statement of the internetworking 122 between a vehicle's internal network and an RSU's internal network, 123 such as prefix discovery, prefix exchange, and service discovery, in 124 the case where the vehicle and the RSU have their own internal 125 network. In addition, the document analyzes the characteristics of 126 vehicular networks to consider the design of V2I networking. 128 2. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 3. Terminology 136 This document uses the terminology described in [RFC4861] and 137 [RFC4862]. In addition, four new terms are defined below: 139 o Road-Side Unit (RSU): A node that has a Dedicated Short-Range 140 Communications (DSRC) device for wireless communications with the 141 vehicles and is connected to the Internet. Every RSU is usually 142 deployed at an intersection so that it can provide vehicles with 143 the Internet connectivity. 145 o Vehicle: A node that has the DSRC device for wireless 146 communications with vehicles and RSUs. Every vehicle may also 147 have a GPS-navigation system for efficient driving. 149 o Traffic Control Center (TCC): A node that maintains road 150 infrastructure information (e.g., RSUs and traffic signals), 151 vehicular traffic statistics (e.g., average vehicle speed and 152 vehicle inter-arrival time per road segment), and vehicle 153 information (e.g., a vehicle's identifier, position, direction, 154 speed, and trajectory). TCC is included in a vehicular cloud for 155 vehicular networks. 157 4. Overview 159 This document specifies the problem statement of vehicle-to- 160 infrastructure (V2I) networking based on IPv6. The main focus is 161 one-hop networking between a vehicle and an RSU or between vehicles 162 via an RSU. However, this document does not address multi-hop 163 networking scenarios of vehicles and RSUs. Also, the problems focus 164 on the network layer (i.e., IPv6 protocol stack) rather than the 165 media access control (MAC) layer and the transport layer (e.g., TCP, 166 UDP, and SCTP). 168 Figure 1 shows the network configuration for V2I networking in a road 169 network. The two RSUs (RSU1 and RSU2) are deployed in the road 170 network and are connected to the Vehicular Cloud through the 171 Internet. The TCC is connected to the Vehicular Cloud and the two 172 vehicles (Vehicle1 and Vehicle2) are wirelessly connected to RSU1, 173 and the last vehicle (Vehicle3) is wirelessly connected to RSU2. 174 Vehicle1 can communicate with Vehicle2 via RSU1. Vehicle1 can 175 communicate with Vehicle3 via RSU1 and RSU2. 177 *-------------* 178 * * .-------. 179 * Vehicular Cloud *<------>| TCC | 180 * * ._______. 181 *-------------* 182 ^ ^ 183 | | 184 | | 185 v v 186 .--------. .--------. 187 | RSU1 |<----------->| RSU2 | 188 .________. .________. 189 ^ ^ ^ 190 . . . 191 . . . 192 v v v 193 .--------. .--------. .--------. 194 |Vehicle1|=> |Vehicle2|=> |Vehicle3|=> 195 .________. .________. .________. 197 <----> Wired Link <....> Wireless Link => Moving Direction 199 Figure 1: The Network Configuration for V2I Networking 201 Figure 2 shows internetworking between the vehicle's moving network 202 and the RSU's fixed network. There exists an internal network 203 (Moving Network1), which is located inside Vehicle1. Vehicle1 has 204 the DNS Server (RDNSS1), the two hosts (Host1 and Host2), and the two 205 routers (Router1 and Router2). The internal network (Fixed Network1) 206 is located inside RSU1. RSU1 has the DNS Server (RDNSS2), one host 207 (Host3), the two routers (Router3 and Router4), and the collection of 208 servers (Server1 to ServerN) for various services in the road 209 networks, such as the emergency notification and navigation. 210 Vehicle1's Router1 and RSU1's Router3 use 2001:DB8:1:1::/64 for an 211 external link (e.g., DSRC) for I2V networking. 213 This document addresses the internetworking between the vehicle's 214 moving network and the RSU's fixed network in Figure 2 and the 215 required enhancement of IPv6 protocol suite for the V2I networking 216 service. 218 (*)<..........>(*) 219 | | 2001:DB8:1:1::/64 220 .------------------------------. .---------------------------------. 221 | | | | | | 222 | .-------. .------. .-------. | | .-------. .------. .-------. | 223 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 224 | ._______. .______. ._______. | | ._______. .______. ._______. | 225 | ^ ^ ^ | | ^ ^ ^ | 226 | | | | | | | | | | 227 | v v v | | v v v | 228 | ---------------------------- | | ------------------------------- | 229 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 230 | | | | | | 231 | v | | v | 232 | .-------. .-------. | | .-------. .-------. .-------. | 233 | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | 234 | ._______. ._______. | | ._______. ._______. ._______. | 235 | ^ ^ | | ^ ^ ^ | 236 | | | | | | | | | 237 | v v | | v v v | 238 | ---------------------------- | | ------------------------------- | 239 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 240 .______________________________. ._________________________________. 241 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 243 <----> Wired Link <....> Wireless Link (*) Antenna 245 Figure 2: Internetworking between Vehicle Network and RSU Network 247 5. Internetworking between the Vehicle and RSU Networks 249 This section discusses the internetworking between the vehicle's 250 moving network and the RSU's fixed network. As shown in Figure 2, it 251 is assumed that the prefix assignment for each subnet inside the 252 vehicle's mobile network and the RSU's fixed network through a prefix 253 delegation protocol. Problems are a prefix discovery and prefix 254 exchange. The prefix discovery is defined as how routers in a moving 255 network discover the prefixes of the subnets in the moving network, 256 as shown in Figure 2. The prefix exchange is defined as how a 257 vehicle and an RSU exchange their prefixes with each other. Once 258 these prefix discovery and prefix exchange are established, the 259 unicast of packets should be supported between the vehicle's moving 260 network and the RSU's fixed network. Also, the DNS naming service 261 should be supported for the DNS name resolution for a host or server 262 in either the vehicle's moving network or the RSU's fixed network. 264 6. IPv6 Addressing 266 This section discusses IP addressing for V2I networking. There are 267 two policies for IPv6 addressing in vehicular networks. The one 268 policy is to use unique local IPv6 unicast addresses (ULAs) for 269 vehicular networks [RFC4193]. The other policy is to use global IPv6 270 addresses for the interoperability with the Internet [RFC4291]. The 271 former approach is usually used by Mobile Ad Hoc Networks (MANET) for 272 a separate multi-link subnet. This approach can support the 273 emergency notification service and navigation service in road 274 networks. However, for general Internet services (e.g., email 275 access, web surfing and entertainment services), the latter approach 276 is required. 278 For the global IP addresses, there are two policies, which are a 279 multi-link subnet approach for multiple RSUs and a single subnet 280 approach per RSU. In the multi-link subnet approach, which is 281 similar to ULA for MANET, RSUs play a role of L2 switches and the 282 router interconnected with the RSUs is required. The router 283 maintains the location of each vehicle belonging to an RSU for L2 284 switching. In the single subnet approach per RSU, which is similar 285 to the legacy subnet in the Internet, RSUs play a role of L3 router. 287 7. Neighbor Discovery 289 The Neighbor Discovery (ND) is a core part of IPv6 protocol suite 290 [RFC4861]. This section discusses the extension of ND for V2I 291 networking. The vehicles are moving fast within the communication 292 coverage of an RSU. The external link between the vehicle and the 293 RSU can be used for V2I networking, as shown in Figure 2. 295 ND time-related parameters such as router lifetime and Neighbor 296 Advertisement (NA) interval should be adjusted for high-speed 297 vehicles and vehicle density. As vehicles move faster, the NA 298 interval should decrease for the NA messages to reach the neighboring 299 vehicles promptly. Also, as vehicle density is higher, the NA 300 interval should increase for the NA messages to collide with other NA 301 messages with lower collision probability. 303 8. IP Address Autoconfiguration 305 This section discusses the IP address autoconfiguration for V2I 306 networking. For the IP address autoconfiguration, the high-speed 307 vehicles should also be considered. The legacy IPv6 stateless 308 address autoconfiguration [RFC4862], as shown in Figure 1, may not 309 perform well because vehicles can pass through the communication 310 coverage of the RSU before the address autoconfiguration with the 311 Router Advertisement and Duplicate Address Detection (DAD) 312 procedures. 314 To mitigate the impact of vehicle speed on the address configuration, 315 RSU can perform IP address autoconfiguration includig the DAD 316 proactively for the sake of the vehicles as an ND proxy. If vehicles 317 periodically report their mobility information (e.g., position, 318 trajectory, speed, and direction) to TCC, TCC can coordinate RSUs 319 under its control for the proactive IP address configuration of the 320 vehicles with the mobility information of the vehicles. DHCPv6 (or 321 Stateless DHCPv6) can be used for the IP address autoconfiguration 322 [RFC3315][RFC3736]. 324 In the case of a single subnet per RSU, the delay to change IPv6 325 address through DHCPv6 procedure is not suitable since vehicles move 326 fast. Some modifications are required for the high-speed vehicles 327 that quickly crosses the communication coverages of multiple RSUs. 328 Some modifications are required for both stateless address 329 autoconfiguration and DHCPv6. 331 9. DNS Naming Service 333 This section discusses a DNS naming service for V2I networking. The 334 DNS naming service can consist of the DNS name resolution and DNS 335 name autoconfiguration. 337 The DNS name resolution translates a DNS name into the corresponding 338 IPv6 address through a recursive DNS server (RDNSS) within the 339 vehicle's moving network and DNS servers in the Internet 340 [RFC1034][RFC1035], which are distributed in the world. The RDNSSes 341 can be advertised by RA DNS Option or DHCP DNS Option into the 342 subnets within the vehicle's moving network. 344 The DNS name autoconfiguration makes a unique DNS name for hosts 345 within a vehicle's moving network and registers it into a DNS server 346 within the vehicle's moving network [ID-DNSNA]. With Vehicle 347 Identification Number (VIN), a unique DNS suffix can be constructed 348 as a DNS domain for the vehicle's moving network. Each host can 349 generate its DNS name and register it into the local RDNSS in the 350 vehicle's moving network. 352 10. IP Mobility Management 354 This section discusses an IP mobility support in V2I networking. In 355 a single subnet per RSU, vehicles keep crossing the communication 356 coverages of adjacent RSUs. During this crossing, TCP/UDP sessions 357 can be maintained through IP mobility support, such as Mobile IPv6 358 (MIPv6) [RFC6275], Proxy MIPv6 [RFC5213][RFC5949], and Distributed 359 Mobility Management (DMM) [RFC7333][RFC7429]. Since vehicles move 360 fast along roadways, this high speed should be considered for a 361 parameter configuration in the IP mobility management. With the 362 periodic reports of the mobility information from the vehicles, TCC 363 can coordinate RSUs and other network compoments under its control 364 for the proactive mobility management of the vehicles along the 365 movement of the vehicles. 367 To support the mobility of a vehicle's moving network, Network 368 Mobility Basic Support Protocol (NEMO) can be used [RFC3963]. Like 369 Mobile IPv6, the high speed of vehicles should be considered for a 370 parameter configuration in NEMO. 372 11. Service Discovery 374 Vehicles need to discover services (e.g., road condition 375 notification, navigation service, and infotainment) provided by 376 infrastructure nodes in a fixed network via RSU, as shown in 377 Figure 2. During the passing of an intersection or road segment with 378 an RSU, vehicles should perform this service discovery quickly. 380 Since with the existing service discovery protocols, such as DNS- 381 based Service Discovery (DNS-SD) [RFC6763] and Multicast DNS (mDNS) 382 [RFC6762], the service discovery will be performed with message 383 exchanges, the discovery delay may hinder the prompt service usage of 384 the vehicles from the fixed network via RSU. One feasible approach 385 is a piggyback service discovery during the prefix exchange of 386 network prefixes for the networking between a vehicle's moving 387 network and an RSU's fixed network. That is, the message of the 388 prefix exchange can include service information, such as each 389 service's IP address, transport layer protocol, and port number. 391 IPv6 ND can be extended for the prefix and service discovery 392 [ID-Vehicular-ND]. Vehicles and RSUs can announce the network 393 prefixes and services in their internal network via ND messages 394 containing ND options with the prefix and service information. Since 395 it does not need any additional service discovery protocol in the 396 application layer, this ND-based approach can provide vehicles and 397 RSUs with the rapid discovery of the network prefixes and services. 399 12. Security Considerations 401 The security and privacy are very important in secure vehicular 402 networks for V2I networking. Only valid vehicles should be allowed 403 to use V2I networking in vehicular networks. A Vehicle 404 Identification Number (VIN) and a user certificate along with in- 405 vehicle device's identifier generation can be used to authenticate a 406 vehicle and the user through a road infrastructure node, such as an 407 RSU connected to an authentication server in TCC. Also, TLS 408 certificates can be used for secure vehicle communications. 410 A security scheme providing authentication and access control should 411 be provided in vehicular networks [VN-Security]. With this scheme, 412 the secuirty and privacy can be supported for safe and reliable data 413 services in vehicular networks. 415 To prevent a vehicle from being tracked by an adversary with its 416 Media Access Control (MAC) address or IPv6 address, each vehicle 417 needs to periodically update its MAC address and the corresponding 418 IPv6 address using randomness [RFC4086][RFC4941]. Such an update of 419 the MAC and IPv6 addresses should not interrupt the communications 420 between a vehicle and an RSU in the level of network layer (i.e., IP) 421 or transport layer (e.g., TCP and UDP). 423 To protect data packets exchanged between a vehicle and an RSU, they 424 should be encrypted by a cryptography algorithm. For this 425 confidentiality, efficient encryption and decryption algorithms can 426 be used along with an efficient key management scheme through 427 Internet Key Exchange version 2 (IKEv2) and Internet Protocol 428 Security (IPsec) [Securing-VCOMM]. 430 This document shares all the security issues of the neighbor 431 discovery protocol. This document can get benefits from secure 432 neighbor discovery (SEND) [RFC3971]. 434 13. Acknowledgements 436 This work was supported by Institute for Information & communications 437 Technology Promotion (IITP) grant funded by the Korea government 438 (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence 439 Technology Development for the Customized Security Service 440 Provisioning). This work was supported in part by ICT R&D program of 441 MSIP/IITP (14-824-09-013, Resilient Cyber-Physical Systems Research) 442 and the DGIST Research and Development Program (CPS Global Center) 443 funded by the Ministry of Science, ICT & Future Planning. 445 This document has greatly benefited from inputs by Alexandre 446 Petrescu, Thierry Ernst, Nabil Benamar, Jerome Haerri, Richard Roy, 447 and Sandra Cespedes. The authors sincerely appreciate their 448 contributions. 450 14. References 452 14.1. Normative References 454 [RFC2119] Bradner, S., "Key words for use in RFCs to 455 Indicate Requirement Levels", BCP 14, RFC 2119, 456 March 1997. 458 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, 459 Version 6 (IPv6) Specification", RFC 2460, 460 December 1998. 462 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 463 Unicast Addresses", RFC 4193, October 2005. 465 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 466 Addressing Architecture", RFC 4291, February 2006. 468 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. 469 Soliman, "Neighbor Discovery for IP Version 6 470 (IPv6)", RFC 4861, September 2007. 472 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 473 Stateless Address Autoconfiguration", RFC 4862, 474 September 2007. 476 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. 477 Madanapalli, "IPv6 Router Advertisement Options 478 for DNS Configuration", RFC 6106, November 2010. 480 [RFC3646] Droms, R., Ed., "DNS Configuration options for 481 Dynamic Host Configuration Protocol for IPv6 482 (DHCPv6)", RFC 3646, December 2003. 484 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., 485 Perkins, C., and M. Carney, "Dynamic Host 486 Configuration Protocol for IPv6 (DHCPv6)", 487 RFC 3315, July 2003. 489 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration 490 Protocol (DHCP) Service for IPv6", RFC 3736, 491 April 2004. 493 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, 494 "Mobility Support in IPv6", RFC 6275, July 2011. 496 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., 497 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 498 RFC 5213, August 2008. 500 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., 501 and F. Xia, "Fast Handovers for Proxy Mobile 502 IPv6", RFC 5949, September 2010. 504 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and 505 P. Thubert, "Network Mobility (NEMO) Basic Support 506 Protocol", RFC 3963, January 2005. 508 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. 509 Korhonen, "Requirements for Distributed Mobility 510 Management", RFC 7333, August 2014. 512 [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. 513 Bernardos, "Distributed Mobility Management: 514 Current Practices and Gap Analysis", RFC 7429, 515 January 2015. 517 [RFC1034] Mockapetris, P., "Domain Names - Concepts and 518 Facilities", RFC 1034, November 1987. 520 [RFC1035] Mockapetris, P., "Domain Names - Implementation 521 and Specification", RFC 1035, November 1987. 523 [RFC3971] Arkko, J., Ed., "SEcure Neighbor Discovery 524 (SEND)", RFC 3971, March 2005. 526 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 527 Discovery", RFC 6763, February 2013. 529 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", 530 RFC 6762, February 2013. 532 14.2. Informative References 534 [DSRC-WAVE] Morgan, Y., "Notes on DSRC & WAVE Standards Suite: 535 Its Architecture, Design, and Characteristics", 536 IEEE Communications Surveys & Tutorials, 12(4), 537 2012. 539 [IEEE-802.11p] IEEE Std 802.11p, "Part 11: Wireless LAN Medium 540 Access Control (MAC) and Physical Layer (PHY) 541 Specifications Amendment 6: Wireless Access in 542 Vehicular Environments", June 2010. 544 [IEEE-802.11a] IEEE Std 802.11a, "Part 11: Wireless LAN Medium 545 Access Control (MAC) and Physical Layer (PHY) 546 specifications: High-speed Physical Layer in the 5 547 GHZ Band", September 1999. 549 [ID-VN-Survey] Jeong, J., Ed., Cespedes, S., Benamar, N., and J. 550 Haerri, "Survey on IP-based Vehicular Networking 551 for Intelligent Transportation Systems", 552 (work in progress), July 2016. 554 [ID-DNSNA] Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 555 Autoconfiguration for Internet of Things Devices", 556 draft-jeong-its-iot-dns-autoconf-01 (work in 557 progress), July 2016. 559 [ID-Vehicular-ND] Jeong, J., Ed., Shen, Y., Jo, Y., Jeong, J., and 560 J. Lee, "IPv6 Neighbor Discovery for Prefix and 561 Service Discovery in Vehicular Networks", 562 draft-jeong-its-vehicular-neighbor-discovery-00 563 (work in progress), July 2016. 565 [VN-Security] Moustafa, H., Bourdon, G., and Y. Gourhant, 566 "Providing Authentication and Access Control in 567 Vehicular Network Environment", IFIP TC- 568 11 International Information Security Conference, 569 May 2006. 571 [Securing-VCOMM] Fernandez, P., Santa, J., Bernal, F., and A. 572 Skarmeta, "Securing Vehicular IPv6 573 Communications", IEEE Transactions on Dependable 574 and Secure Computing, January 2016. 576 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 577 "Randomness Requirements for Security", RFC 4086, 578 June 2005. 580 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 581 Extensions for Stateless Address Autoconfiguration 582 in IPv6", RFC 4941, September 2007. 584 Appendix A. Changes from draft-jeong-its-v2i-problem-statement-02 586 The following changes are made from 587 draft-jeong-its-v2i-problem-statement-02: 589 o In Section 12, the considerations on security and privacy are 590 enhanced. 592 Authors' Addresses 594 Jaehoon Paul Jeong 595 Department of Software 596 Sungkyunkwan University 597 2066 Seobu-Ro, Jangan-Gu 598 Suwon, Gyeonggi-Do 440-746 599 Republic of Korea 601 Phone: +82 31 299 4957 602 Fax: +82 31 290 7996 603 EMail: pauljeong@skku.edu 604 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 606 Tae (Tom) Oh 607 Department of Information Sciences and Technologies 608 Rochester Institute of Technology 609 One Lomb Memorial Drive 610 Rochester, NY 14623-5603 611 USA 613 Phone: +1 585 475 7642 614 EMail: Tom.Oh@rit.edu