Network Working Group J. Jeong Internet-Draft Y. Shen Intended status: Standards Track Y. Jo Expires: September 14, 2017 Sungkyunkwan University J. Jeong Samsung Electronics J. Lee Sangmyung University March 13, 2017 IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular Networks draft-jeong-ipwave-vehicular-neighbor-discovery-00 Abstract This document specifies an extension of IPv6 Neighbor Discovery (ND) for rapid network prefix and service discovery in vehicular networks. It is assumed that a vehicle or a Road-Side Unit (RSU) have an external network interface and their internal network. The extended IPv6 ND called vehicular ND can support vehicle-to-infrastructure communications as well as vehicle-to-vehicle communications. This document defines new ND options to allow a vehicle to announce the network prefixes and services inside its internal network to another vehicle or RSU. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Jeong, et al. Expires September 14, 2017 [Page 1] Internet-Draft Vehicular Neighbor Discovery March 2017 This Internet-Draft will expire on September 14, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. ND Extension for Prefix and Service Discovery . . . . . . . . 6 5.1. Vehicular Prefix Information Option . . . . . . . . . . . 6 5.2. Vehicular Service Information Option . . . . . . . . . . . 7 5.3. Vehicular Neighbor Discovery . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Jeong, et al. Expires September 14, 2017 [Page 2] Internet-Draft Vehicular Neighbor Discovery March 2017 1. Introduction Vehicular Ad Hoc Networks (VANET) have been researched for the networking on intelligent services in road networks, such as driving safety, efficient driving, and entertainment. To enable this VANET in road networks, Dedicated Short-Range Communications (DSRC) [DSRC-WAVE] has been standardized as IEEE 802.11p [IEEE-802.11p], which is an extension of IEEE 802.11a [IEEE-802.11a], considering the characteristics of vehicular networks, such as high-speed mobility and network fragmentation. For Wireless Access in Vehicular Environments (WAVE), the IEEE has standardized IEEE 1609 family standards, such as IEEE 1609.3 and 1609.4 [DSRC-WAVE]. The IEEE 1609 standards specify IPv6 as the network-layer protocol. With this trend, it is time to enable vehicular networking with IPv6 to let various Internet-based applications run on top of transport- layer protocols, such as TCP, UDP, and SCTP. IPv6 [RFC2460] is suitable for a network layer in vehicular networks in that the protocol has abundant address space, autoconfiguration features, and protocol extension ability through extension headers. To support the interaction between vehicles or between a vehicle and an RSU, this document specifies an extension of IPv6 ND [RFC4861] for rapid network prefix and service discovery in vehicular networks with new ND options. That is, the extended IPv6 ND in this document, which is called vehicular ND, can support not only vehicle-to- infrastructure (V2I) communications but also vehicle-to-vehicle (V2V) communications. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Terminology This document uses the terminology described in [RFC4861] and [RFC4862]. In addition, four new terms are defined below: o Road-Side Unit (RSU): A node that has a Dedicated Short-Range Communications (DSRC) device for wireless communications with the vehicles and is connected to the Internet. Every RSU is usually deployed at an intersection so that it can provide vehicles with the Internet connectivity. o Vehicle: A node that has the DSRC device for wireless communications with vehicles and RSUs. Every vehicle may also Jeong, et al. Expires September 14, 2017 [Page 3] Internet-Draft Vehicular Neighbor Discovery March 2017 have a GPS-navigation system for efficient driving. o Traffic Control Center (TCC): A node that maintains road infrastructure information (e.g., RSUs and traffic signals), vehicular traffic statistics (e.g., average vehicle speed and vehicle inter-arrival time per road segment), and vehicle information (e.g., a vehicle's identifier, position, direction, speed, and trajectory). TCC is included in a vehicular cloud for vehicular networks. 4. Overview This document specifies an IPv6 ND extension for vehicle-to-vehicle (V2V) or vehicle-to-infrastructure (V2I) networking. Figure 1 shows the V2V networking of two vehicles whose internal networks are Moving Network1 and Moving Network2, respectively. Vehicle1 has the DNS Server (RDNSS1), the two hosts (Host1 and Host2), and the two routers (Router1 and Router2). Vehicle2 has the DNS Server (RDNSS2), the two hosts (Host3 and Host4), and the two routers (Router3 and Router4). It is assumed that Host1 and Host3 are running a Cooperative Adaptive Cruise Control (C-ACC) program for physical collision avoidance. Also, it is assumed that Host2 and Host4 are running a Cooperative On-board Camera Sharing (C-OCS) program for sharing road hazards or obstacles to avoid road accidents. Vehicle1's Router1 and Vehicle2's Router3 use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for V2V networking for various vehicular services. The vehicular applications, such as C-ACC and C-BCS, can be registered into the DNS Server (i.e., RDNSS) through DNSNA protocol in [ID-DNSNA] along with IPv6 ND DNS options in [RFC6106]. Vehicle1's Router1 and Vehicle2's Router3 can know what vehicular applications exist in their internal network by referring to their own RDNSS through the DNSNA protocol [ID-DNSNA]. They can also know what network prefixes exist in their internal network through an intra-domain routing protocoli, such as OSFP. Each vehicle announces its network prefixes and services through ND options defined in Section 5. Jeong, et al. Expires September 14, 2017 [Page 4] Internet-Draft Vehicular Neighbor Discovery March 2017 (*)<..........>(*) | | 2001:DB8:1:1::/64 .------------------------------. .------------------------------. | | | | | | | .-------. .------. .-------. | | .-------. .------. .-------. | | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | | ._______. .______. ._______. | | ._______. .______. ._______. | | ^ ^ ^ | | ^ ^ ^ | | | | | | | | | | | | v v v | | v v v | | ---------------------------- | | ---------------------------- | | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | | | | | | | | v | | v | | .-------. .-------. | | .-------. .-------. | | | Host2 | |Router2| | | |Router4| | Host4 | | | ._______. ._______. | | ._______. ._______. | | ^ ^ | | ^ ^ | | | | | | | | | | v v | | v v | | ---------------------------- | | ---------------------------- | | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | .______________________________. .______________________________. Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) <----> Wired Link <....> Wireless Link (*) Antenna Figure 1: Internetworking between Vehicle Networks Figure 2 shows the V2I networking of a vehicle and an RSU whose internal networks are Moving Network1 and Fixed Network1, respectively. Vehicle1 has the DNS Server (RDNSS1), the two hosts (Host1 and Host2), and the two routers (Router1 and Router2). RSU1 has the DNS Server (RDNSS2), one host (Host3), the two routers (Router3 and Router4). It is assumed that RSU1 has a collection of servers (Server1 to ServerN) for various services in the road networks, such as road emergency notification and navigation services. Vehicle1's Router1 and RSU1's Router3 use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for I2V networking for various vehicular services. The vehicular applications, such as road emergency notification and navigation services, can be registered into the DNS Server (i.e., RDNSS) through DNSNA protocol in [ID-DNSNA] along with IPv6 ND DNS options in [RFC6106]. Vehicle1's Router1 and RSU1's Router3 can know what vehicular applications exist in their internal network by referring to their Jeong, et al. Expires September 14, 2017 [Page 5] Internet-Draft Vehicular Neighbor Discovery March 2017 own RDNSS through the DNSNA protocol [ID-DNSNA]. They can also know what network prefixes exist in their internal network through an intra-domain routing protocoli, such as OSFP. Each vehicle and each RSU announce their network prefixes and services through ND options defined in Section 5. (*)<..........>(*) | | 2001:DB8:1:1::/64 .------------------------------. .---------------------------------. | | | | | | | .-------. .------. .-------. | | .-------. .------. .-------. | | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | | ._______. .______. ._______. | | ._______. .______. ._______. | | ^ ^ ^ | | ^ ^ ^ | | | | | | | | | | | | v v v | | v v v | | ---------------------------- | | ------------------------------- | | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | | | | | | | | v | | v | | .-------. .-------. | | .-------. .-------. .-------. | | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | | ._______. ._______. | | ._______. ._______. ._______. | | ^ ^ | | ^ ^ ^ | | | | | | | | | | | v v | | v v v | | ---------------------------- | | ------------------------------- | | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | .______________________________. ._________________________________. Vehicle1 (Moving Network1) RSU1 (Fixed Network1) <----> Wired Link <....> Wireless Link (*) Antenna Figure 2: Internetworking between Vehicle Network and RSU Network 5. ND Extension for Prefix and Service Discovery This section defines two new ND options for prefix and service discovery: (i) the Vehicular Prefix Information (VPI) option and (ii) the Vehicular Service Information (VSI) option. It also describes the ND protocol for such prefix and service discovery. 5.1. Vehicular Prefix Information Option The VPI option contains one IPv6 prefix in the internal network. Figure 3 shows the format of the VPI option. Jeong, et al. Expires September 14, 2017 [Page 6] Internet-Draft Vehicular Neighbor Discovery March 2017 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length | Distance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Prefix : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Vehicular Prefix Information (VPI) Option Format Fields: Type 8-bit identifier of the VPI option type as assigned by the IANA: TBD Length 8-bit unsigned integer. The length of the option (including the Type and Length fields) is in units of 8 octets. The value is 3. Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. Distance 8-bit unsigned integer. The distance between the subnet announcing this prefix and the subnet corresponding to this prefix in terms of the number of hops. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Prefix An IP address or a prefix of an IP address. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. 5.2. Vehicular Service Information Option The VSI option contains one vehicular service in the internal network. Figure 4 shows the format of the VSI option. Jeong, et al. Expires September 14, 2017 [Page 7] Internet-Draft Vehicular Neighbor Discovery March 2017 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Reserved2 | Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Service Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Vehicular Service Information (VSI) Option Format Fields: Type 8-bit identifier of the VSI option type as assigned by the IANA: TBD Length 8-bit unsigned integer. The length of the option (including the Type and Length fields) is in units of 8 octets. The value is 3. Reserved1 This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Protocol 8-bit unsigned integer to indicate the upper-layer protocol, such as transport-layer protocol (e.g., TCP, UDP, and SCTP). Reserved2 This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Port Number 16-bit unsigned integer to indicate the port number for the protocol. Service Address 128-bit IPv6 address of a vehicular service. 5.3. Vehicular Neighbor Discovery With VPI and VSI options, a node (e.g., vehicle or RSU) can announce the network prefixes and services in its internal network via ND messages, such as Neighbor Solicitation (NS) and Neighbor Advertisement (NA) [RFC4861]. Jeong, et al. Expires September 14, 2017 [Page 8] Internet-Draft Vehicular Neighbor Discovery March 2017 A node periodically announces an NS message containing the VPI and VSI options with its prefixes and services in all-nodes multicast address to reach all neighboring nodes. When another neighboring node receives this NS message, it responds to this NS message by sending an NA message containing the VPI and VSI options with its prefixes and services via unicast toward the NS-originating node. Through this procedure, vehicles and RSUs can rapidly discover the network prefixes and services of the other party without any additional service discovery protocol. 6. Security Considerations This document shares all the security issues of the neighbor discovery protocol. This document can get benefits from secure neighbor discovery (SEND) [RFC3971] in order to protect ND from possible security attacks. 7. Acknowledgements This work was supported by Institute for Information & communications Technology Promotion (IITP) grant funded by the Korea government (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence Technology Development for the Customized Security Service Provisioning). This work was supported in part by ICT R&D program of MSIP/IITP (14-824-09-013, Resilient Cyber-Physical Systems Research) and the DGIST Research and Development Program (CPS Global Center) funded by the Ministry of Science, ICT & Future Planning. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. Jeong, et al. Expires September 14, 2017 [Page 9] Internet-Draft Vehicular Neighbor Discovery March 2017 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010. 8.2. Informative References [DSRC-WAVE] Morgan, Y., "Notes on DSRC & WAVE Standards Suite: Its Architecture, Design, and Characteristics", IEEE Communications Surveys & Tutorials, 12(4), 2012. [IEEE-802.11p] IEEE Std 802.11p, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 6: Wireless Access in Vehicular Environments", June 2010. [IEEE-802.11a] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: High-speed Physical Layer in the 5 GHZ Band", September 1999. [ID-DNSNA] Jeong, J., Ed., Lee, S., and J. Park, "DNS Name Autoconfiguration for Internet of Things Devices", draft-jeong-ipwave-iot-dns-autoconf-00 (work in progress), March 2017. [RFC3971] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. Authors' Addresses Jaehoon Paul Jeong Department of Software Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4957 Fax: +82 31 290 7996 EMail: pauljeong@skku.edu URI: http://iotlab.skku.edu/people-jaehoon-jeong.php Jeong, et al. Expires September 14, 2017 [Page 10] Internet-Draft Vehicular Neighbor Discovery March 2017 Yiwen Chris Shen Department of Computer Science and Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4106 Fax: +82 31 290 7996 EMail: chrisshen@skku.edu Younghwa Jo Department of Software Platform Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4106 Fax: +82 31 290 7996 EMail: movie_jo@naver.com Junsik Jeong Software R&D Center Samsung Electronics Seoul R&D Campus D-Tower, 56, Seongchon-Gil, Seocho-Gu Seoul 06765 Republic of Korea EMail: jun.jeong@samsung.com Jong-Hyouk Lee Sangmyung University Sangmyung University 31, Sangmyeongdae-gil, Dongnam-gu Cheonan, NY 31066 Republic of Korea EMail: jonghyouk@smu.ac.kr Jeong, et al. Expires September 14, 2017 [Page 11]