IPv6 Neighbor Discovery for IP-Based Vehicular Networks
draft-jeong-ipwave-vehicular-neighbor-discovery-05
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Jaehoon Paul Jeong , Yiwen Shen , Zhong Xiang | ||
| Last updated | 2018-11-08 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jeong-ipwave-vehicular-neighbor-discovery-05
Jeong, et al. Expires May 12, 2019 [Page 14] Internet-Draft IPv6 Vehicular Neighbor Discovery November 2018 Vehicle RSU Mobility Anchor | | | |-RS with Mobility Info->| | | [VMI] | | | | | | |--------PBU------>| | | | | | | | |<-------PBA-------| | | | | | | | |===Bi-Dir Tunnel==| | | | | | | |<----RA with prefix-----| | | | | | | | | | | |--NS with Address Reg-->| | | [ARO+VPI+VSI] | | | | | | |--------DAR------>| | | | | | | | |<-------DAC-------| | | | | | | |<--NA with Address Reg--| | | [ARO+VPI+VSI] | | Figure 7: Message Interaction for Vehicular Neighbor Discovery Note that a vehicle could also perform the prefix and service discovery simultaneously along with Address Registration procedure, as shown in Figure 9. Note that RSUs as routers do not transmit periodical and unsolicited multicast RA messages including a prefix for energy saving in vehicular networks. Vehicles as hosts periodically initiate an RS message according to a time interval (considering its position and an RSU's coverage). Note that since they have a digital road map with the information of RSUs (e.g., position and communication coverage), vehicles can know when they will go out of the communication range of an RSU along with the signal strength (e.g., Received Channel Power Indicator (RCPI) [VIP-WAVE]) from the RSU. RSUs replies with a solicited RA in unicast only when they receive an RS message. Jeong, et al. Expires May 12, 2019 [Page 15] Internet-Draft IPv6 Vehicular Neighbor Discovery November 2018 7. Address Registration and Duplicate Address Detection This section explains address configuration, consisting of IP Address Autoconfiguration, Address Registration, and multihop DAD. This document recommends a new Address Registration and DAD scheme in order to avoid multicast flooding and decrease link-scope multicast for energy and wireless channel conservation on a large-scale vehicular network. Host-initiated refresh of RA removes the need for routers to use periodic and unsolicited multicast RAs to accommodate hosts. This also enables the same IPv6 address prefix(es) to be used across a subnet. There are two scenarios about Address Registration part. If they have already configured their IP addresses with the prefix obtained from the previous RSU, and the current RSU located in the same subnet as the previous RSU, which means that they have the same prefix, then vehicles have no need to repeat the Address Registration and multihop DAD. However, if the current RSU belongs to another subnet, vehicles need to perform the Address Registration and multihop DAD in the following subsections. 7.1. Address Autoconfiguration A vehicle as an IPv6 host creates its link-local IPv6 address and global IPv6 address as follows [RFC4862]. When they receive RS messages from vehicles, RSUs send back RA messages containing prefix information. The vehicle makes its global IPv6 addresses by combining the prefix for its current link and its link-layer address. The address autoconfiguration does not perform the legacy DAD as defined in [RFC4862]. Instead, a new multihop DAD is performed in Section 7.3. 7.2. Address Registration After its IP tentative address autoconfiguration with the known prefix from an RSU and its link-layer address, a vehicle starts to register its IP address to the serving RSU along with multihop DAD. Address Register Option (ARO) is used in this step and its format is defined in [RFC6775]. ARO is always host-initiated by vehicles. The information contained in ARO becomes included in multihop Duplicate Address Request (DAR) and Duplicate Address Confirmation (DAC) messages used between RSU and MA, but ARO is not directly used in these two messages. Jeong, et al. Expires May 12, 2019 [Page 16] Internet-Draft IPv6 Vehicular Neighbor Discovery November 2018 An example message exchange procedure of Address Registration is presented in Figure 8. Since Address Registration is performed simultaneously with the multihop DAD, the specific procedure is together described with the DAD mechanism in Section 7.3. Vehicle RSU | | | | 1. |----NS with Address Reg--->| | [ARO] | | | | | | | 2. |<---NA with Address Reg----| | [ARO] | Figure 8: Neighbor Discovery Address Registration 7.3. Multihop Duplicate Address Detection Before it can exchange data, a node should determine whether its IP address is already used by another node or not. In the legacy IPv6 ND, hosts multicast NS messages to all nodes in the same on-link subnet for DAD. Instead of this, an optimized multihop DAD is designed to eliminate multicast messages for energy-saving purpose. For this multihop DAD, Neighbor Cache and DAD Table are maintained by each RSU and an MA, respectively, for the duplicate address inspection during the multihop DAD process. That is, each RSU makes Neighbor Cache Entries (NCE) of all the on-link hosts in its Neighbor Cache. Similarly, the MA stores all the NCEs reported by the RSUs in its DAD Table. With the multihop DAD, a vehicle can skip the multicast-based DAD in its current wireless link whenever it enters the coverage of another RSU in the same subset, leading to the reduction of traffic overhead in vehicular wireless links. For the multihop DAD, two new ICMPv6 message types are defined in [RFC6775], such as Duplicate Address Request (DAR) and the Duplicate Address Confirmation (DAC). Information carried by ARO options are copied into these two messages for the multihop DAD in the MA. Jeong, et al. Expires May 12, 2019 [Page 17] Internet-Draft IPv6 Vehicular Neighbor Discovery November 2018 Vehicle RSU Mobility Anchor | | | | | | 1. |--NS with Address Reg-->| | | [ARO+VPI+VSI] | | | | | | | | 2. | | -------DAR------>| | | | | | | 3. | |<-------DAC-------| | | | | | | | | | 4. |<--NA with Address Reg--| | | [ARO+VPI+VSI] | | Figure 9: Neighbor Discovery Address Registration with Multihop DAD Figure 9 presents the procedure of Address Registration and multihop DAD. The detailed steps are explained as follows. 1. A vehicle sends an NS message to the current RSU in unicast, containing the ARO to RSU to register its address. 2. The RSU receives the NS message, and then inspects its Neighbor Cache to check whether it is duplicate or not. If there is no duplicate NCE, a tentative NCE is created for this address, and then the RSU sends a DAR to the MA for the multicast DAD. 3. When the MA receives a DAR from an RSU, it checks whether the register-requested address exists in its DAD Table or not. If an entry with the same address exists in the DAD Table, which means that the address is considered "Duplicate Address", then MA returns a DAC message to notify the RSU of the address duplication. If no entry with the same address exists in the DAD Table, which means that an entry for the address is created, then MA replies a DAC message to the RSU to confirm the uniqueness of the register-requested address to the RSU. 4. If the address duplication is notified by the MA, the RSU deletes the tentative NCE, and sends back an NS to the address- registration vehicle to notify the registration failure. Otherwise, the RSU changes the tentative NCE into a registered NCE in its Neighbor Cache, and then send back an NS to the vehicle to notify the registration success. Jeong, et al. Expires May 12, 2019 [Page 18] Internet-Draft IPv6 Vehicular Neighbor Discovery November 2018 Thus, the multihop DAD is processed simultaneously with the Address Registration. Note that the tentative address is not considered assigned to the vehicle until the MA confirms the uniqueness of the register-requested address in the multihop DAD. 7.4. Pseudonym Handling Considering the privacy protection of a vehicle, a pseudonym mechanism for its link-layer address is requested. This mechanism periodically modifies the link-layer address, leading to the update of the corresponding IP address. A random MAC Address Generation mechanism is proposed in Appendix F.4 of [IEEE-802.11-OCB] by generating the 46 remaining bits of MAC address using a random number generator. When it changes its MAC address, a vehicle should ask the serving RSU to update its own NCE, and to register its IP address into the MA again. Vehicle RSU Mobility Anchor | | | |-RS with Mobility Info->| | | [VMI] | | | | | | |--------PBU------>| | | | | | | | |<-------PBA-------| | | | | | | | |===Bi-Dir Tunnel==| | | | | | | |<----RA with prefix-----| | | | | Figure 10: Message Interaction for Vehicle Attachment 8. Mobility Management A mobility management is required for the seamless communication of vehicles moving between the RSUs. When a vehicle moves into the coverage of another RSU, a different IP address is assigned to the vehicle, resulting in the reconfiguration of transport-layer session information (i.e., end-point IP address) to avoid service disruption. Considering this issue, this document proposes a handover mechanism for seamless communication. Jeong, et al. Expires May 12, 2019 [Page 19] Internet-Draft IPv6 Vehicular Neighbor Discovery November 2018 In [VIP-WAVE], the authors constructed a network-based mobility management scheme using Proxy Mobile IPv6 (PMIPv6) [RFC5213], which is highly suitable to vehicular networks. This document uses a mobility management procedure similar to PMIPv6 along with prefix discovery. Vehicle c-RSU Mobility Anchor n-RSU | | | | | |===Bi-Dir Tunnel==| | | | | | | | | | | |----DeReg PBU---->| | | | | | | | | | | |<-------PBA-------| | | | | | | | | | | | | | | | | | | | | | |---------------------------RS-------------------------->| | | | Registration step as shown in Figure 5 | | | | | |===Bi-Dir Tunnel==| | | |<--------------------------RA---------------------------| | | Figure 11: Message Interaction for Vehicle Handoff Figure 10 shows the binding update flow when a vehicle entered the subnet of an RSU. RSUs act as Mobility Anchor Gateway (MAG) defined in [VIP-WAVE]. When it receives RS messages from a vehicle containing its mobility information (e.g., position, speed, and direction), an RSU sends its MA a Proxy Binding Update (PBU) message [RFC5213][RFC3775], which contains a Mobility Option for the vehicle's mobility information. The MA receives the PBU and sets up a Binding Cache Entry (BCE) as well as a bi-directional tunnel (denoted as Bi-Dir Tunnel in Figure 10) between the serving RSU and itself. Through this tunnel, all traffic packets to the vehicle are encapsulated toward the RSU. Simultaneously, the MA sends back a Proxy Binding Acknowledgment (PBA) message to the serving RSU. This serving RSU receives the PBA and sets up a bi-directional tunnel with the MA. After this binding update, the RSU sends back an RA message to the vehicle including its own prefix for the address autoconfiguration. Jeong, et al. Expires May 12, 2019 [Page 20] Internet-Draft IPv6 Vehicular Neighbor Discovery November 2018 When the vehicle changes its location, the MA has to change the end- point of the tunnel for the vehicle into the new RSU's IP address. As shown in Figure 11, when the MA receives a new PBU from the new RSU, it changes the tunnel's end-point from the current RSU (c-RSU) to the new RSU (n-RSU). If there is ongoing IP packets toward the vehicle, the MA encapsulates the packets and then forwards them towards the new RSU. Through this network-based mobility management, the vehicle is not aware of any changes at its network layer and can maintain its transport-layer sessions without any disruption. 9. Security Considerations This document shares all the security issues of the neighbor discovery protocol and 6LoWPAN protocol. This document can get benefits from secure neighbor discovery (SEND) [RFC3971] in order to protect ND from possible security attacks. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3971] Arkko, J., "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [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. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., and K. Chowdhury, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad Hoc Networks", RFC 5889, September 2010. [RFC6775] Shelby, Z., Ed., "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012. Jeong, et al. Expires May 12, 2019 [Page 21] Internet-Draft IPv6 Vehicular Neighbor Discovery November 2018 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, March 2017. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 8200, July 2017. 10.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. [ID-DNSNA] Jeong, J., Ed., Lee, S., and J. Park, "DNS Name Autoconfiguration for Internet of Things Devices", draft- jeong-ipwave-iot-dns-autoconf-04 (work in progress), October 2018. [IEEE-802.11-OCB] IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2016, December 2016. [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. [IPWAVE-PS] Jeong, J., Ed., "IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases", draft-ietf-ipwave-vehicular-networking-07 (work in progress), November 2018. [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013. [VIP-WAVE] Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the Feasibility of IP Communications in 802.11p Vehicular Networks", IEEE Transactions on Intelligent Transportation Systems, vol. 14, no. 1, March 2013. Jeong, et al. Expires May 12, 2019 [Page 22] Internet-Draft IPv6 Vehicular Neighbor Discovery November 2018 [WAVE-1609.0] IEEE 1609 Working Group, "IEEE Guide for Wireless Access in Vehicular Environments (WAVE) - Architecture", IEEE Std 1609.0-2013, March 2014. [WAVE-1609.2] IEEE 1609 Working Group, "IEEE Standard for Wireless Access in Vehicular Environments - Security Services for Applications and Management Messages", IEEE Std 1609.2-2016, March 2016. [WAVE-1609.3] IEEE 1609 Working Group, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Networking Services", IEEE Std 1609.3-2016, April 2016. [WAVE-1609.4] IEEE 1609 Working Group, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Multi-Channel Operation", IEEE Std 1609.4-2016, March 2016. Jeong, et al. Expires May 12, 2019 [Page 23] Internet-Draft IPv6 Vehicular Neighbor Discovery November 2018 Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor- discovery-04 The following changes are made from draft-jeong-ipwave-vehicular- neighbor-discovery-04: o This version includes the contents of the IPv6 vehicular neighbor discovery in draft-xiang-ipwave-vehicular-neighbor-discovery-00 for IP-based vehicular networks. o In Section 6.3, a Vehicular Mobility Information (VMI) option is defined to report the mobility information of a vehicle or an RSU. Appendix B. Acknowledgments This work was supported by Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education (2017R1D1A1B03035885). This work was supported in part by Global Research Laboratory Program through the NRF funded by the Ministry of Science and ICT (MSIT) (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT (18-EE-01). 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 May 12, 2019 [Page 24] Internet-Draft IPv6 Vehicular Neighbor Discovery November 2018 Yiwen Chris Shen Department of Electrical and Computer 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 Zhong Xiang Department of Electrical and Computer Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea Phone: +82 10 9895 1211 Fax: +82 31 290 7996 EMail: xz618@skku.edu Jeong, et al. Expires May 12, 2019 [Page 25]