IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular Networks
Department of Software
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4957+82 31 290 7996pauljeong@skku.eduhttp://iotlab.skku.edu/people-jaehoon-jeong.php
Department of Computer Science and Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4106+82 31 290 7996chrisshen@skku.edu
Department of Software Platform
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4106+82 31 290 7996movie_jo@naver.com
Software R&D Center
Samsung ElectronicsSeoul R&D Campus D-Tower, 56, Seongchon-Gil, Seocho-GuSeoul06765Republic of Koreajun.jeong@samsung.com
Sangmyung University
Sangmyung University31, Sangmyeongdae-gil, Dongnam-guCheonanNY31066Republic of Koreajonghyouk@smu.ac.kr
Internet
IPWAVE Working GroupInternet-Draft
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.
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)
has been standardized as IEEE 802.11p , which is an extension of IEEE 802.11a , considering the characteristics of vehicular networks, such as high-speed mobility and network fragmentation. Note that IEEE 802.11p was renamed IEEE 802.11 Outside the Context of a Basic Service Set (OCB) in 2012.
For Wireless Access in Vehicular Environments (WAVE) , the IEEE has standardized IEEE 1609 family standards, such as IEEE 1609.2, 1609.3, and 1609.4 .
The IEEE 1609 standards specify IPv6 as the network-layer protocol .
Many automobile vendors are replacing Controller Area Networks (CANs) with
Ethernet for high-speed interconnectivity among Electronic Control Units (ECUs)
in a vehicle. The sensing information of the ECUs can be delivered to the
service centers of those automobile ventors for remote diagnosis for
driving safety using DSRC between vehicles and Road-Side Units (RSUs)
having the Internet connectivity toward the service centers in a vehicular cloud.
With this trend, it is time to enable vehicular networking with IPv6 to let
various Internet-based applications (e.g., remote vehicle diagnosis) run on top of transport-layer protocols,
such as TCP, UDP, and SCTP.
IPv6 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
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.
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 .
This document uses the terminology described in and .
In addition, four new terms are defined below:
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.
Vehicle: A node that has the DSRC device for wireless communications with vehicles and RSUs.
Every vehicle may also have a GPS-navigation system for efficient driving.
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.
This document specifies an IPv6 ND extension for vehicle-to-vehicle (V2V) or vehicle-to-infrastructure (V2I) networking.
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 along with IPv6 ND DNS options in .
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 . 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 .
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 (RDNSS3), one host (Host5), the two routers (Router5 and Router6).
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 along with IPv6 ND DNS options in .
Vehicle1's Router1 and RSU1's Router5 can know what vehicular applications exist in their internal network by referring to their own RDNSS through the DNSNA protocol . 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 .
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.
The VPI option contains one IPv6 prefix in the internal network.
shows the format of the VPI option.
The VSI option contains one vehicular service in the internal network.
shows the format of the VSI option.
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) .
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.
This document shares all the security issues of the neighbor discovery
protocol. This document can get benefits from secure neighbor discovery
(SEND) in order to protect ND from possible
security attacks.
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).
Key words for use in RFCs to Indicate Requirement LevelsInternet Protocol, Version 6 (IPv6) SpecificationNeighbor Discovery for IP Version 6 (IPv6)IPv6 Stateless Address AutoconfigurationIPv6 Router Advertisement Options for DNS ConfigurationNotes on DSRC & WAVE Standards Suite: Its Architecture, Design, and CharacteristicsPart 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 6: Wireless Access in Vehicular EnvironmentsPart 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) SpecificationsPart 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: High-speed Physical Layer in the 5 GHZ BandIEEE Guide for Wireless Access in Vehicular Environments (WAVE) - ArchitectureIEEE Standard for Wireless Access in Vehicular Environments - Security Services for Applications and Management MessagesIEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Networking ServicesIEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Multi-Channel OperationDNS Name Autoconfiguration for Internet of Things DevicesSEcure Neighbor Discovery (SEND)
The following changes are made from draft-jeong-ipwave-vehicular-neighbor-discovery-03:
In and
, the vehicle networks and RSU network are updated.
In Informative References, the reference to IEEE 802.11-OCB is updated.