Internet DRAFT - draft-xiang-ipwave-vehicular-neighbor-discovery
draft-xiang-ipwave-vehicular-neighbor-discovery
IPWAVE Working Group Z. Xiang
Internet-Draft J. Jeong, Ed.
Intended status: Standards Track Y. Shen
Expires: May 8, 2019 Sungkyunkwan University
November 4, 2018
IPv6 Neighbor Discovery for IP-Based Vehicular Networks
draft-xiang-ipwave-vehicular-neighbor-discovery-00
Abstract
This document specifies a Vehicular Neighbor Discovery (VND) as an
extension of IPv6 Neighbor Discovery (ND) for IP-based vehicular
networks. An optimized Address Registration and a multihop Duplicate
Address Detection (DAD) mechanism are established for both operation
efficiency and the saving of wireless bandwidth and vehicle energy.
Also, the two new ND options for a rapid prefix and service discovery
are used to announce the network prefixes and services inside a
vehicle (i.e., a vehicle's internal network). Finally, a mobility
management scheme is proposed for moving vehicles in vehicular
environments to support seamless communication for the continuity of
transport-layer sessions (e.g., TCP connections).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 8, 2019.
Copyright Notice
Copyright (c) 2018 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
Xiang, et al. Expires May 8, 2019 [Page 1]
Internet-Draft Vehicular Neighbor Discovery November 2018
(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. ND Optimization . . . . . . . . . . . . . . . . . . . . . 5
4.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 6
5. Network Architecture . . . . . . . . . . . . . . . . . . . . 6
5.1. Vehicular Network Architecture . . . . . . . . . . . . . 6
5.2. Message Exchange Procedure . . . . . . . . . . . . . . . 8
6. ND Extension for Prefix and Service Discovery . . . . . . . . 9
6.1. New Options in Vehicular Neighbor Discovery . . . . . . . 9
6.2. Prefix and Service Discovery . . . . . . . . . . . . . . 9
7. Address Registration and Duplicate Address Detection . . . . 10
7.1. Address Autoconfiguration . . . . . . . . . . . . . . . . 10
7.2. Address Registration . . . . . . . . . . . . . . . . . . 10
7.3. Multihop Duplicate Address Detection . . . . . . . . . . 11
7.4. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 13
8. Mobility Management . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
Vehicular Ad Hoc Networks (VANET) have been researched for
Intelligent Transportation System (ITS) such as driving safety,
efficient driving and entertainment. Considering the high-speed
mobility of vehicular network based on Dedicated Short-Range
Communications (DSRC), IEEE 802.11p [IEEE-802.11p] has been
specialized and was renamed IEEE 802.11 Outside the Context of a
Basic Service Set (OCB) [IEEE-802.11-OCB] in 2012. IEEE has
standardized Wireless Access in Vehicular Environments (WAVE)
[DSRC-WAVE] standard which is considered as a key component in ITS.
The IEEE 1609 standards such as IEEE 1609.0 [WAVE-1609.0], 1609.2
Xiang, et al. Expires May 8, 2019 [Page 2]
Internet-Draft Vehicular Neighbor Discovery November 2018
[WAVE-1609.2], 1609.3 [WAVE-1609.3], 1609.4 [WAVE-1609.4] provide a
low-latency and alternative network for vehicular communications.
What is more, IP-based vehicular networks specialized as IP Wireless
Access in Vehicular Environments (IPWAVE) [IPWAVE-PS] can enable many
use cases over vehicle-to-vehicle (V2V), vehicle-to-infrastructure
(V2I), and vehicle-to-everything (V2X) communications.
VANET features high mobility dynamics, asymmetric and lossy
connections, and moderate power constraint (e.g., electric cars and
unmanned aerial vehicles). Links among hosts and routers in VANET
can be considered as undetermined connectivities with constantly
changing neighbors described in [RFC5889]. IPv6 [RFC8200] is
selected as the network-layer protocol for Internet applications by
IEEE 1609.0 and 1609.3. However, the relatively long-time Neighbor
Discovery (ND) process in IPv6 [RFC4861] is not suitable in VANET
scenarios.
To support the interaction between vehicles or between vehicles and
Rode-Side Unit (RSU), this document specifies a Vehicular Neighbor
Discovery (VND) as an extension of IPv6 ND for IP-based vehicular
networks. VND provides vehicles with an optimized Address
Registration, a multihop Duplicate Address Detection (DAD), and an
efficient mobility management scheme to support efficient V2V, V2I,
and V2X 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], [RFC4862],
and [RFC6775]. In addition, the following new terms are defined as
below:
o WAVE: Acronym for "Wireless Access in Vehicular Environments"
[WAVE-1609.0].
o Road-Side Unit (RSU): A node that has physical communication
devices (e.g., DSRC, Visible Light Communication, 802.15.4, LTE-
V2X, etc.) for wireless communications with vehicles and is also
connected to the Internet as a router or switch for packet
forwarding. An RSU is typically deployed on the road
infrastructure, either at an intersection or in a road segment,
but may also be located in car parking area.
Xiang, et al. Expires May 8, 2019 [Page 3]
Internet-Draft Vehicular Neighbor Discovery November 2018
o On-Board Unit (OBU): A node that has a DSRC device for wireless
communications with other OBUs and RSUs, and may be connected to
in-vehicle devices or networks. An OBU is mounted on a vehicle.
It is assumed that a radio navigation receiver (e.g., Global
Positioning System (GPS)) is included in a vehicle with an OBU for
efficient navigation.
o Mobility Anchor (MA): A node that maintains IP addresses and
mobility information of vehicles in a road network to support the
address autoconfiguration and mobility management of them. It has
end-to-end connections with RSUs under its control. It maintains
a DAD table having the IP addresses of the vehicles moving within
the communication coverage of its RSUs.
o Vehicular Cloud: A cloud infrastructure for vehicular networks,
having compute nodes, storage nodes, and network nodes.
o Traffic Control Center (TCC): A node that maintains road
infrastructure information (e.g., RSUs, traffic signals, and loop
detectors), 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 as a navigation path). TCC is
included in a vehicular cloud for vehicular networks and has MAs
under its management.
4. Overview
This document proposes an optimized ND, which has a more adaptive
structure for vehicular networks considering fast vehicle mobility
and wireless control traffic overhead related to the ND. Further
more, prefix and service discovery can be implemented as part of the
ND's process along with an efficient Address Registration procedure
and DAD mechanism for moving vehicles. This document specifies a set
of behaviors between vehicles and RSUs to accomplish these goals.
4.1. Link Model
There is a relationship between a link and a network prefix along
with reachability scopes, such as link-local and global scopes. The
legacy IPv6 ND protocol [RFC4861] has the following link model. All
IPv6 nodes in the same on-link subnet, which use the same subnet
prefix with on-link bit set, are reachable with each other by one-hop
link. The symmetry of the connectivity among the nodes is preserved,
that is, bidirectional connectivity among two on-link nodes. On the
other hand, a link model in vehicular networks (called vehicular link
model) should consider the asymmetry of the connectivity that
unidirectional links can exist due to interference in wireless
Xiang, et al. Expires May 8, 2019 [Page 4]
Internet-Draft Vehicular Neighbor Discovery November 2018
channels and the different levels of transmission power in wireless
network interfaces.
The on-link subnet can be constructed by one link (as a basic service
set) or multiple links (as an extended service set) called a multi-
link subnet [RFC6775]. In the legacy multi-link subnet, an all-node-
multicasted packet is copied and related to other links by an ND
proxy. On the other hand, in vehicular networks having fast moving
vehicles, multiple links can share the same subnet prefix for
operation efficiency. For example, if two wireless links under two
adjacent RSUs are in the same subnet, a vehicle as an IPv6 host does
not need to reconfigure its IPv6 address during handover between
those RSUs. However, the packet relay by an RSU as an ND proxy is
not required because such a relay can cause a broadcast storm in the
extended subnet. Thus, in the multi-link subnet, all-node-
multicasting needs to be well-calibrated to either being confined to
multicasting in the current link or being disseminated to other links
in the same subnet.
In a connected multihop VANET, for the efficient communication,
vehicles in the same link of an RSU can communicate directly with
each other, not through the relay of the RSU. This direct wireless
communication is similar to the direct wired communication in an on-
link subnet using Ethernet as a wired network. The vehicular link
model needs to accommodate both the ad-hoc communication between
vehicles and infrastructure communication between a vehicle and an
RSU in an efficient and flexible way.
Therefore, the IPv6 ND should be extended to accommodate the concept
of a new IPv6 link model in vehicular networks.
4.2. ND Optimization
This document takes advantage of the optimized ND for Low-Power
Wireless Personal Area Network (6LoWPAN) [RFC6775] because vehicular
environments have common parts with 6LoWPAN, such as the reduction of
unnecessary wireless traffic by multicasting and the energy saving in
battery. Note that vehicles tend to be electric vehicles whose
energy source is from their battery.
In the optimized IPv6 ND for 6LoWPAN, the connections among nodes are
assumed to be asymmetric and unidirectional because of changing radio
environment and loss signal. The authors proposed an improved IPv6
ND which greatly eliminates link-scope multicast to save energy by
constructing new options and a new scheme for address configurations.
Similarly, this document proposes an improved IPv6 ND by eliminating
many link-scope-multicast-based ND operations, such as DAD for IPv6
Stateless Address Autoconfiguration (SLAAC) [RFC4862].
Xiang, et al. Expires May 8, 2019 [Page 5]
Internet-Draft Vehicular Neighbor Discovery November 2018
Thus, this document suggests an extension of IPv6 ND as vehicular ND
tailored for vehicular networks along with new ND options (e.g.,
prefix discovery, service discovery, and mobility information
options).
4.3. Design Goals
The vehicular ND in this document has the following design goals:
o To perform prefix and service discovery through ND procedure;
o To implement host-initiated refresh of Router Advertisement (RA)
and remove the need for routers to use periodic or unsolicited
multicast RA to find hosts;
o To create Neighbor Cache Entries (NCE) for all registered vehicles
in RSUs by adding Address Registration Option (ARO) in Neighbor
Solicitation (NS), Neighbor Advertisement (NA) messages;
o To support a multihop DAD with two new ICMPv6 messages called
Duplicate Address Request(DAR) and Duplicate Address
Confirmation(DAC) to eliminate multicast storm and save energy;
and
o To provide a mobility management mechanism for seamless
communication during a vehicle's travel in subnets via RSUs.
5. Network Architecture
This section describes a vehicular network architecture for V2V and
V2I communication as well as an example message interaction for ND
scheme designed in this document.
5.1. Vehicular Network Architecture
A vehicular network architecture for V2V and V2I is illustrated in
Figure 1. Three RSUs are deployed along roadside and are connected
to an MA through wired links. There are two subnets such as Subnet1
and Subnet2. The wireless links of RSU1 and RSU2 belong to the same
subnet named Subnet1, but the wireless link of RSU3 belongs to
another subnet named Subnet2. Vehicle1 and Vehicle2 are wirelessly
connected to RSU1 while Vehicle3 and Vehicle4 are connected to RSU2
and RSU3, respectively. Vehicles can directly communicate with each
other through V2V connection (e.g., Vehicle1 and Vehicle2) to share
driving information. Vehicles are assumed to start the connection to
an RSU when they entered the coverage of the RSU.
Xiang, et al. Expires May 8, 2019 [Page 6]
Internet-Draft Vehicular Neighbor Discovery November 2018
Traffic Control Center in Vehicular Cloud
*-----------------------------------------*
* *
* +----------------+ *
* | Mobility Anchor| *
* +----------------+ *
* ^ *
* | *
*--------------------v--------------------*
^ ^ ^
| | |
+------------------ | -------------|-------------+ +------------------+
| v v | | v |
| +--------+ Ethernet +--------+ | | +--------+ |
| | RSU1 |<----------->| RSU2 |<---------->| RSU3 | |
| +--------+ +--------+ | | +--------+ |
| ^ ^ ^ | | ^ |
| : : : | | : |
| V2I : : V2I V2I : | | V2I : |
| v v v | | v |
| +--------+ +--------+ +--------+ | | +--------+ |
| |Vehicle1|===> |Vehicle2|===> |Vehicle3|===>| | |Vehicle4|===>|
| | |<....>| |<....>| | | | | | |
| +--------+ V2V +--------+ V2V +--------+ | | +--------+ |
| | | |
+-------------------------------------------------+ +------------------+
Subnet1 Subnet2
<----> Wired Link <....> Wireless Link ===> Moving Direction
Figure 1: A Vehicular Network Architecture for V2I and V2V Networking
The document recommends a multi-link subnet involving multiple RSUs,
as shown in Figure 1. This recommendation aims at the reduction of
the frequency with which vehicles have to change their IP address
during handover between two adjacent RSUs. When they pass through
RSUs in the same subnet, vehicles do not need to perform the Address
Registration and DAD again because they can use their current IP
address in the wireless coverage of the next RSU, belonging to the
same subnet. On the other hand, if they enter the wireless coverage
of an RSU belonging to another subnet with a different prefix,
vehicles repeat the Address Registration and DAD procedure to update
their IP address with the new prefix.
In Figure 1, RSU1 and RSU2 are deployed in the a multi-link subnet
with the same prefix in their address. When vehicle1 leaves the
coverage of RSU1 and enters RSU2, it maintains its address and
ignores Address Registration and DAD steps. If vehicle1 moves into
Xiang, et al. Expires May 8, 2019 [Page 7]
Internet-Draft Vehicular Neighbor Discovery November 2018
the coverage of RSU3, since RSU3 belongs to another subnet and holds
a different prefix from RSU1 and RSU2, so vehicles must do Address
Registration and DAD just as connecting to a new RSU. Note that
vehicles and RSUs have their internal networks having in-vehicle
devices and servers, respectively. The structures of the internal
networks are described in [IPWAVE-PS].
Vehicle RSU Mobility Anchor
| | |
|-RS with Mobility Info->| |
| | |
| | |
| |--------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 2: Message Interaction for Vehicular Neighbor Discovery
5.2. Message Exchange Procedure
Figure 2 shows an example of message exchange procedure in vehicular
networks. The detailed steps of the procedure are explained in
Section 6, Section 7, and Section 8.
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
Xiang, et al. Expires May 8, 2019 [Page 8]
Internet-Draft Vehicular Neighbor Discovery November 2018
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.
6. ND Extension for Prefix and Service Discovery
In this document, prefix and service discovery can be achieved via ND
messages (e.g., NS and NA) by vehicular ND, which eliminates an
additional prefix and service discovery scheme, such as DNS-based
Service Discovery [RFC6763] (e.g., Multicast DNS (mDNS) [RFC6762] and
DNSNA [ID-DNSNA]), other than ND.
6.1. New Options in Vehicular Neighbor Discovery
Two new ND options for prefix and service discovery are defined in
[Vehicular-ND-Discovery]: (i) the Vehicular Prefix Information (VPI)
Option and (ii) the Vehicular Service Information (VSI) Option are
employed in this process. The formats of VPI and VSI are defined in
Section 5.2 and Section 5.3 of [Vehicular-ND-Discovery].
6.2. Prefix and Service Discovery
Prefix discovery enables hosts (e.g., vehicles and in-vehicle
devices) to distinguish destinations on the same link from those only
reachable via RSUs. A vehicle (or its in-vehicle devices) can
directly communicate with on-link vehicles (or their in-vehicle
devices) without the relay of an RSU, but through V2V communications
along with VPI ND option. This VPI option contains IPv6 prefixes in
a vehicle's internal network.
Vehicles announce services in their internal networks to other
vehicles through an VSI ND option. The VSI option contains a list of
vehicular services in a vehicle's or an RSU's internal network.
A vehicle periodically announces an NS message containing VPI and VSI
options with its prefixes and services in all-nodes multicast address
to reach all neighboring nodes. When it receives this NS message,
another neighboring node responds to this NS message by sending an NA
message containing the VPI and VSI options with its prefixes and
services via unicast towards the NS-originating node.
Note that a vehicle could also perform the prefix and service
discovery simultaneously along with Address Registration procedure,
as shown in Figure 4.
Xiang, et al. Expires May 8, 2019 [Page 9]
Internet-Draft 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.
Xiang, et al. Expires May 8, 2019 [Page 10]
Internet-Draft Vehicular Neighbor Discovery November 2018
An example message exchange procedure of Address Registration is
presented in Figure 3. 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 3: 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.
Xiang, et al. Expires May 8, 2019 [Page 11]
Internet-Draft 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 4: Neighbor Discovery Address Registration with Multihop DAD
Figure 4 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.
Xiang, et al. Expires May 8, 2019 [Page 12]
Internet-Draft 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->| |
| | |
| | |
| |--------PBU------>|
| | |
| | |
| |<-------PBA-------|
| | |
| | |
| |===Bi-Dir Tunnel==|
| | |
| | |
|<----RA with prefix-----| |
| | |
Figure 5: 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.
Xiang, et al. Expires May 8, 2019 [Page 13]
Internet-Draft 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 6: Message Interaction for Vehicle Handoff
Figure 5 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 5) 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.
Xiang, et al. Expires May 8, 2019 [Page 14]
Internet-Draft 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 6, 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.
Xiang, et al. Expires May 8, 2019 [Page 15]
Internet-Draft Vehicular Neighbor Discovery November 2018
[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.
[Vehicular-ND-Discovery]
Jeong, J., Ed., "IPv6 Neighbor Discovery for Prefix and
Service Discovery in Vehicular Networks", draft-jeong-
ipwave-vehicular-neighbor-discovery-04 (work in progress),
October 2018.
Xiang, et al. Expires May 8, 2019 [Page 16]
Internet-Draft Vehicular Neighbor Discovery November 2018
[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.
[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.
Xiang, et al. Expires May 8, 2019 [Page 17]
Internet-Draft Vehicular Neighbor Discovery November 2018
Appendix A. 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
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
Jaehoon Paul Jeong (editor)
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
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
Xiang, et al. Expires May 8, 2019 [Page 18]
