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