[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

IPWAVE Working Group                                            J. Jeong
Internet-Draft                                                   Y. Shen
Intended status: Standards Track                                Z. Xiang
Expires: May 12, 2019                            Sungkyunkwan University
                                                        November 8, 2018


        IPv6 Neighbor Discovery for IP-Based Vehicular Networks
           draft-jeong-ipwave-vehicular-neighbor-discovery-05

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 three new ND options for prefix discovery, service
   discovery, and mobility information report 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 12, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Jeong, et al.             Expires May 12, 2019                  [Page 1]


Internet-Draft      IPv6 Vehicular Neighbor Discovery      November 2018


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Link Model  . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  ND Optimization . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Vehicular Network Architecture  . . . . . . . . . . . . . . .   6
     5.1.  Vehicular Network . . . . . . . . . . . . . . . . . . . .   6
     5.2.  V2I Internetworking . . . . . . . . . . . . . . . . . . .   9
     5.3.  V2V Internetworking . . . . . . . . . . . . . . . . . . .   9
   6.  ND Extension for Prefix and Service Discovery . . . . . . . .  11
     6.1.  Vehicular Prefix Information Option . . . . . . . . . . .  11
     6.2.  Vehicular Service Information Option  . . . . . . . . . .  12
     6.3.  Vehicular Mobility Information Option . . . . . . . . . .  13
     6.4.  Vehicular Neighbor Discovery  . . . . . . . . . . . . . .  14
     6.5.  Message Exchange Procedure for V2I Networking . . . . . .  14
   7.  Address Registration and Duplicate Address Detection  . . . .  16
     7.1.  Address Autoconfiguration . . . . . . . . . . . . . . . .  16
     7.2.  Address Registration  . . . . . . . . . . . . . . . . . .  16
     7.3.  Multihop Duplicate Address Detection  . . . . . . . . . .  17
     7.4.  Pseudonym Handling  . . . . . . . . . . . . . . . . . . .  19
   8.  Mobility Management . . . . . . . . . . . . . . . . . . . . .  19
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     10.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Appendix A.  Changes from draft-jeong-ipwave-vehicular-neighbor-
                discovery-04 . . . . . . . . . . . . . . . . . . . .  24
   Appendix B.  Acknowledgments  . . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24








Jeong, et al.             Expires May 12, 2019                  [Page 2]


Internet-Draft      IPv6 Vehicular Neighbor Discovery      November 2018


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
   [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:



Jeong, et al.             Expires May 12, 2019                  [Page 3]


Internet-Draft      IPv6 Vehicular Neighbor Discovery      November 2018


   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.

   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.





Jeong, et al.             Expires May 12, 2019                  [Page 4]


Internet-Draft      IPv6 Vehicular Neighbor Discovery      November 2018


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
   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



Jeong, et al.             Expires May 12, 2019                  [Page 5]


Internet-Draft      IPv6 Vehicular Neighbor Discovery      November 2018


   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].  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.  Vehicular Network Architecture

   This section describes a vehicular network architecture for V2V and
   V2I communication.  A vehicle and an RSU have their internal networks
   having in-vehicle devices or servers, respectively.

5.1.  Vehicular Network

   A vehicular network architecture for V2I and V2V 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



Jeong, et al.             Expires May 12, 2019                  [Page 6]


Internet-Draft      IPv6 Vehicular Neighbor Discovery      November 2018


   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.

                     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



Jeong, et al.             Expires May 12, 2019                  [Page 7]


Internet-Draft      IPv6 Vehicular Neighbor Discovery      November 2018


   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
   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].

                                                    +-----------------+
                           (*)<........>(*)  +----->| Vehicular Cloud |
          2001:DB8:1:1::/64 |            |   |      +-----------------+
   +------------------------------+  +---------------------------------+
   |                        v     |  |   v   v                         |
   | +-------+ +------+ +-------+ |  | +-------+ +------+ +-------+    |
   | | 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






Jeong, et al.             Expires May 12, 2019                  [Page 8]


Internet-Draft      IPv6 Vehicular Neighbor Discovery      November 2018


5.2.  V2I Internetworking

   This subsection explains V2I internteworking between vehicle network
   and RSU network where vehicle network is an internal network in a
   vehicle, and RSU network is an internal network in an RSU, as shown
   in Figure 2.

   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 (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 [ID-DNSNA] along with IPv6 ND DNS
   options in [RFC8106].

   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 [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 6.

5.3.  V2V Internetworking

   This subsection explains V2V internteworking between vehicle
   networks, which are internal networks in vehicles, as shown in
   Figure 3.














Jeong, et al.             Expires May 12, 2019                  [Page 9]


Internet-Draft      IPv6 Vehicular Neighbor Discovery      November 2018


                           (*)<..........>(*)
          2001:DB8:1:1::/64 |              |
   +------------------------------+  +------------------------------+
   |                        v     |  |     v                        |
   | +-------+ +------+ +-------+ |  | +-------+ +------+ +-------+ |
   | | Host1 | |RDNSS1| |Router1| |  | |Router5| |RDNSS3| | Host4 | |
   | +-------+ +------+ +-------+ |  | +-------+ +------+ +-------+ |
   |     ^        ^         ^     |  |     ^         ^        ^     |
   |     |        |         |     |  |     |         |        |     |
   |     v        v         v     |  |     v         v        v     |
   | ---------------------------- |  | ---------------------------- |
   | 2001:DB8:10:1::/64 ^         |  |         ^ 2001:DB8:30:1::/64 |
   |                    |         |  |         |                    |
   |                    v         |  |         v                    |
   | +-------+      +-------+     |  |     +-------+      +-------+ |
   | | Host2 |      |Router2|     |  |     |Router6|      | Host5 | |
   | +-------+      +-------+     |  |     +-------+      +-------+ |
   |     ^              ^         |  |         ^              ^     |
   |     |              |         |  |         |              |     |
   |     v              v         |  |         v              v     |
   | ---------------------------- |  | ---------------------------- |
   |      2001:DB8:10:2::/64      |  |       2001:DB8:30:2::/64     |
   +------------------------------+  +------------------------------+
      Vehicle1 (Moving Network1)        Vehicle2 (Moving Network2)

      <----> Wired Link   <....> Wireless Link   (*) Antenna

            Figure 3: Internetworking between Vehicle Networks

   Figure 3 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 [RFC8106].





Jeong, et al.             Expires May 12, 2019                 [Page 10]


Internet-Draft      IPv6 Vehicular Neighbor Discovery      November 2018


   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 6.

6.  ND Extension for Prefix and Service Discovery

   This section specifies an IPv6 ND extension for vehicle-to-vehicle
   (V2V) or vehicle-to-infrastructure (V2I) networking.  This section
   also defines three new ND options for prefix discovery, service
   discovery, and mobility information report: (i) Vehicular Prefix
   Information (VPI) option, (ii) Vehicular Service Information (VSI)
   option, and (iii) Vehicular Mobility Information (VMI) option.  It
   also describes the procedure of the ND protocol with those options.

6.1.  Vehicular Prefix Information Option

   The VPI option contains IPv6 prefix information in the internal
   network.  Figure 4 shows the format of the VPI option.

      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 4: 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.



Jeong, et al.             Expires May 12, 2019                 [Page 11]


Internet-Draft      IPv6 Vehicular Neighbor Discovery      November 2018


    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.

6.2.  Vehicular Service Information Option

   The VSI option contains vehicular service information in the internal
   network.  Figure 5 shows the format of the VSI option.

      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          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                          Node Address                         :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 5: 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.





Jeong, et al.             Expires May 12, 2019                 [Page 12]


Internet-Draft      IPv6 Vehicular Neighbor Discovery      November 2018


    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 node proving this vehicular
                   service.

6.3.  Vehicular Mobility Information Option

   The VMI option contains one vehicular mobility information of a
   vehicle or an RSU.  Figure 6 shows the format of the VMI option.

      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           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Reserved2                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                      Mobility Information                     :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 6: Vehicular Mobility Information (VMI) Option Format

   Fields:
    Type           8-bit identifier of the VMI 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.






Jeong, et al.             Expires May 12, 2019                 [Page 13]


Internet-Draft      IPv6 Vehicular Neighbor Discovery      November 2018


    Reserved2      This field is unused.  It MUST be initialized to
                   zero by the sender and MUST be ignored by the
                   receiver.

    Mobility Information
                   128-bit mobility information, such as position,
                   speed, and direction.

6.4.  Vehicular Neighbor 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.

   Therefore, prefix and service discovery can be achieved via ND
   messages (e.g., NS and NA) by vehicular ND with VPI and VSI options.
   This VND-based discovery 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.  That is, vehicles and RSUs can rapidly discover the network
   prefixes and services of the other party without any additional
   service discovery protocol.

6.5.  Message Exchange Procedure for V2I Networking

   This subsection explains a message exchange procedure for vehicular
   neighbor discovery in V2I networking, where a vehicle communicates
   with its correponding node in the Internet via an RSU.

   Figure 7 shows an example of message exchange procedure in V2I
   networkging.  The detailed steps of the procedure are explained in
   Section 7 and Section 8.




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]


Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/