Skip to main content

IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular Networks
draft-jeong-ipwave-vehicular-neighbor-discovery-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Junsik Jeong , Yiwen Shen , Younghwa Jo , Jaehoon Paul Jeong , Jong-Hyouk Lee
Last updated 2017-10-30
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-jeong-ipwave-vehicular-neighbor-discovery-01
Network Working Group                                           J. Jeong
Internet-Draft                                                   Y. Shen
Intended status: Standards Track                                   Y. Jo
Expires: May 3, 2018                             Sungkyunkwan University
                                                                J. Jeong
                                                     Samsung Electronics
                                                                  J. Lee
                                                    Sangmyung University
                                                        October 30, 2017

 IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular
                                Networks
           draft-jeong-ipwave-vehicular-neighbor-discovery-01

Abstract

   This document specifies an extension of IPv6 Neighbor Discovery (ND)
   for rapid network prefix and service discovery in vehicular networks.
   It is assumed that a vehicle or a Road-Side Unit (RSU) have an
   external network interface and their internal network.  The extended
   IPv6 ND called vehicular ND can support vehicle-to-infrastructure
   communications as well as vehicle-to-vehicle communications.  This
   document defines new ND options to allow a vehicle to announce the
   network prefixes and services inside its internal network to another
   vehicle or RSU.

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Jeong, et al.              Expires May 3, 2018                  [Page 1]
Internet-Draft        Vehicular Neighbor Discovery          October 2017

   This Internet-Draft will expire on May 3, 2018.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  ND Extension for Prefix and Service Discovery  . . . . . . . .  6
     5.1.  Vehicular Prefix Information Option  . . . . . . . . . . .  6
     5.2.  Vehicular Service Information Option . . . . . . . . . . .  7
     5.3.  Vehicular Neighbor Discovery . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Changes from
                draft-jeong-ipwave-vehicular-neighbor-discovery-00  . 10

Jeong, et al.              Expires May 3, 2018                  [Page 2]
Internet-Draft        Vehicular Neighbor Discovery          October 2017

1.  Introduction

   Vehicular Ad Hoc Networks (VANET) have been researched for the
   networking on intelligent services in road networks, such as driving
   safety, efficient driving, and entertainment.  To enable this VANET
   in road networks, Dedicated Short-Range Communications (DSRC)
   [DSRC-WAVE] has been standardized as IEEE 802.11p [IEEE-802.11p],
   which is an extension of IEEE 802.11a [IEEE-802.11a], considering the
   characteristics of vehicular networks, such as high-speed mobility
   and network fragmentation.  For Wireless Access in Vehicular
   Environments (WAVE), the IEEE has standardized IEEE 1609 family
   standards, such as IEEE 1609.3 and 1609.4 [DSRC-WAVE].  The IEEE 1609
   standards specify IPv6 as the network-layer protocol.

   Many automobile vendors are replacing Controller Area Networks (CANs)
   with Ethernet for high-speed interconnectivity among Electronic
   Control Units (ECUs) in a vehicle.  The sensing information of the
   ECUs can be delivered to the service centers of those automobile
   ventors for remote diagnosis for driving safety using DSRC between
   vehicles and Road-Side Units (RSUs) having the Internet connectivity
   toward the service centers in a vehicular cloud.

   With this trend, it is time to enable vehicular networking with IPv6
   to let various Internet-based applications (e.g., remote vehicle
   diagnosis) run on top of transport-layer protocols, such as TCP, UDP,
   and SCTP.  IPv6 [RFC2460] is suitable for a network layer in
   vehicular networks in that the protocol has abundant address space,
   autoconfiguration features, and protocol extension ability through
   extension headers.

   To support the interaction between vehicles or between a vehicle and
   an RSU, this document specifies an extension of IPv6 ND [RFC4861] for
   rapid network prefix and service discovery in vehicular networks with
   new ND options.  That is, the extended IPv6 ND in this document,
   which is called vehicular ND, can support not only vehicle-to-
   infrastructure (V2I) communications but also vehicle-to-vehicle (V2V)
   communications.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Terminology

   This document uses the terminology described in [RFC4861] and
   [RFC4862].  In addition, four new terms are defined below:

Jeong, et al.              Expires May 3, 2018                  [Page 3]
Internet-Draft        Vehicular Neighbor Discovery          October 2017

   o  Road-Side Unit (RSU): A node that has a Dedicated Short-Range
      Communications (DSRC) device for wireless communications with the
      vehicles and is connected to the Internet.  Every RSU is usually
      deployed at an intersection so that it can provide vehicles with
      the Internet connectivity.

   o  Vehicle: A node that has the DSRC device for wireless
      communications with vehicles and RSUs.  Every vehicle may also
      have a GPS-navigation system for efficient driving.

   o  Traffic Control Center (TCC): A node that maintains road
      infrastructure information (e.g., RSUs and traffic signals),
      vehicular traffic statistics (e.g., average vehicle speed and
      vehicle inter-arrival time per road segment), and vehicle
      information (e.g., a vehicle's identifier, position, direction,
      speed, and trajectory).  TCC is included in a vehicular cloud for
      vehicular networks.

4.  Overview

   This document specifies an IPv6 ND extension for vehicle-to-vehicle
   (V2V) or vehicle-to-infrastructure (V2I) networking.

   Figure 1 shows the V2V networking of two vehicles whose internal
   networks are Moving Network1 and Moving Network2, respectively.
   Vehicle1 has the DNS Server (RDNSS1), the two hosts (Host1 and
   Host2), and the two routers (Router1 and Router2).  Vehicle2 has the
   DNS Server (RDNSS2), the two hosts (Host3 and Host4), and the two
   routers (Router3 and Router4).

   It is assumed that Host1 and Host3 are running a Cooperative Adaptive
   Cruise Control (C-ACC) program for physical collision avoidance.
   Also, it is assumed that Host2 and Host4 are running a Cooperative
   On-board Camera Sharing (C-OCS) program for sharing road hazards or
   obstacles to avoid road accidents.  Vehicle1's Router1 and Vehicle2's
   Router3 use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for
   V2V networking for various vehicular services.  The vehicular
   applications, such as C-ACC and C-BCS, can be registered into the DNS
   Server (i.e., RDNSS) through DNSNA protocol in [ID-DNSNA] along with
   IPv6 ND DNS options in [RFC6106].

   Vehicle1's Router1 and Vehicle2's Router3 can know what vehicular
   applications exist in their internal network by referring to their
   own RDNSS through the DNSNA protocol [ID-DNSNA].  They can also know
   what network prefixes exist in their internal network through an
   intra-domain routing protocoli, such as OSFP.  Each vehicle announces
   its network prefixes and services through ND options defined in
   Section 5.

Jeong, et al.              Expires May 3, 2018                  [Page 4]
Internet-Draft        Vehicular Neighbor Discovery          October 2017

                           (*)<..........>(*)
                            |              | 2001:DB8:1:1::/64
   .------------------------------.  .------------------------------.
   |                        |     |  |     |                        |
   | .-------. .------. .-------. |  | .-------. .------. .-------. |
   | | Host1 | |RDNSS1| |Router1| |  | |Router3| |RDNSS2| | Host3 | |
   | ._______. .______. ._______. |  | ._______. .______. ._______. |
   |     ^        ^         ^     |  |     ^         ^        ^     |
   |     |        |         |     |  |     |         |        |     |
   |     v        v         v     |  |     v         v        v     |
   | ---------------------------- |  | ---------------------------- |
   | 2001:DB8:10:1::/64 ^         |  |     ^ 2001:DB8:20:1::/64     |
   |                    |         |  |     |                        |
   |                    v         |  |     v                        |
   | .-------.      .-------.     |  | .-------.      .-------.     |
   | | Host2 |      |Router2|     |  | |Router4|      | Host4 |     |
   | ._______.      ._______.     |  | ._______.      ._______.     |
   |     ^              ^         |  |     ^              ^         |
   |     |              |         |  |     |              |         |
   |     v              v         |  |     v              v         |
   | ---------------------------- |  | ---------------------------- |
   |  2001:DB8:10:2::/64          |  |       2001:DB8:20:2::/64     |
   .______________________________.  .______________________________.
      Vehicle1 (Moving Network1)        Vehicle2 (Moving Network2)

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

            Figure 1: Internetworking between Vehicle Networks

   Figure 2 shows the V2I networking of a vehicle and an RSU whose
   internal networks are Moving Network1 and Fixed Network1,
   respectively.  Vehicle1 has the DNS Server (RDNSS1), the two hosts
   (Host1 and Host2), and the two routers (Router1 and Router2).  RSU1
   has the DNS Server (RDNSS2), one host (Host3), the two routers
   (Router3 and Router4).

   It is assumed that RSU1 has a collection of servers (Server1 to
   ServerN) for various services in the road networks, such as road
   emergency notification and navigation services.  Vehicle1's Router1
   and RSU1's Router3 use 2001:DB8:1:1::/64 for an external link (e.g.,
   DSRC) for I2V networking for various vehicular services.  The
   vehicular applications, such as road emergency notification and
   navigation services, can be registered into the DNS Server (i.e.,
   RDNSS) through DNSNA protocol in [ID-DNSNA] along with IPv6 ND DNS
   options in [RFC6106].

   Vehicle1's Router1 and RSU1's Router3 can know what vehicular
   applications exist in their internal network by referring to their

Jeong, et al.              Expires May 3, 2018                  [Page 5]
Internet-Draft        Vehicular Neighbor Discovery          October 2017

   own RDNSS through the DNSNA protocol [ID-DNSNA].  They can also know
   what network prefixes exist in their internal network through an
   intra-domain routing protocoli, such as OSFP.  Each vehicle and each
   RSU announce their network prefixes and services through ND options
   defined in Section 5.

                           (*)<..........>(*)
                            |              | 2001:DB8:1:1::/64
   .------------------------------.  .---------------------------------.
   |                        |     |  |     |                           |
   | .-------. .------. .-------. |  | .-------. .------. .-------.    |
   | | Host1 | |RDNSS1| |Router1| |  | |Router3| |RDNSS2| | Host3 |    |
   | ._______. .______. ._______. |  | ._______. .______. ._______.    |
   |     ^        ^         ^     |  |     ^         ^        ^        |
   |     |        |         |     |  |     |         |        |        |
   |     v        v         v     |  |     v         v        v        |
   | ---------------------------- |  | ------------------------------- |
   | 2001:DB8:10:1::/64 ^         |  |     ^ 2001:DB8:20:1::/64        |
   |                    |         |  |     |                           |
   |                    v         |  |     v                           |
   | .-------.      .-------.     |  | .-------. .-------.   .-------. |
   | | Host2 |      |Router2|     |  | |Router4| |Server1|...|ServerN| |
   | ._______.      ._______.     |  | ._______. ._______.   ._______. |
   |     ^              ^         |  |     ^         ^           ^     |
   |     |              |         |  |     |         |           |     |
   |     v              v         |  |     v         v           v     |
   | ---------------------------- |  | ------------------------------- |
   |  2001:DB8:10:2::/64          |  |       2001:DB8:20:2::/64        |
   .______________________________.  ._________________________________.
      Vehicle1 (Moving Network1)            RSU1 (Fixed Network1)

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

     Figure 2: Internetworking between Vehicle Network and RSU Network

5.  ND Extension for Prefix and Service Discovery

   This section defines two new ND options for prefix and service
   discovery: (i) the Vehicular Prefix Information (VPI) option and (ii)
   the Vehicular Service Information (VSI) option.  It also describes
   the ND protocol for such prefix and service discovery.

5.1.  Vehicular Prefix Information Option

   The VPI option contains one IPv6 prefix in the internal network.
   Figure 3 shows the format of the VPI option.

Jeong, et al.              Expires May 3, 2018                  [Page 6]
Internet-Draft        Vehicular Neighbor Discovery          October 2017

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     | Prefix Length |   Distance    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                            Prefix                             :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 3: Vehicular Prefix Information (VPI) Option Format

   Fields:
    Type           8-bit identifier of the VPI option type as assigned
                   by the IANA: TBD

    Length         8-bit unsigned integer.  The length of the option
                   (including the Type and Length fields) is in units of
                   8 octets.  The value is 3.

    Prefix Length  8-bit unsigned integer.  The number of leading bits
                   in the Prefix that are valid.  The value ranges
                   from 0 to 128.

    Distance       8-bit unsigned integer. The distance between the
                   subnet announcing this prefix and the subnet
                   corresponding to this prefix in terms of the number
                   of hops.

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

    Prefix         An IP address or a prefix of an IP address.  The
                   Prefix Length field contains the number of valid
                   leading bits in the prefix.  The bits in the prefix
                   after the prefix length are reserved and MUST be
                   initialized to zero by the sender and ignored by
                   the receiver.

5.2.  Vehicular Service Information Option

   The VSI option contains one vehicular service in the internal
   network.  Figure 4 shows the format of the VSI option.

Jeong, et al.              Expires May 3, 2018                  [Page 7]
Internet-Draft        Vehicular Neighbor Discovery          October 2017

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Length    |           Reserved1           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Protocol    |   Reserved2   |          Port Number          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                          Node Address                         :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 4: Vehicular Service Information (VSI) Option Format

   Fields:
    Type           8-bit identifier of the VSI option type as assigned
                   by the IANA: TBD

    Length         8-bit unsigned integer.  The length of the option
                   (including the Type and Length fields) is in units of
                   8 octets.  The value is 3.

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

    Protocol       8-bit unsigned integer to indicate the upper-layer
                   protocol, such as transport-layer protocol (e.g.,
                   TCP, UDP, and SCTP).

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

    Port Number    16-bit unsigned integer to indicate the port number
                   for the protocol.

    Service Address
                   128-bit IPv6 address of a node proving this vehicular
                   service.

5.3.  Vehicular Neighbor Discovery

   With VPI and VSI options, a node (e.g., vehicle or RSU) can announce
   the network prefixes and services in its internal network via ND
   messages, such as Neighbor Solicitation (NS) and Neighbor
   Advertisement (NA) [RFC4861].

Jeong, et al.              Expires May 3, 2018                  [Page 8]
Internet-Draft        Vehicular Neighbor Discovery          October 2017

   A node periodically announces an NS message containing the VPI and
   VSI options with its prefixes and services in all-nodes multicast
   address to reach all neighboring nodes.  When another neighboring
   node receives this NS message, it responds to this NS message by
   sending an NA message containing the VPI and VSI options with its
   prefixes and services via unicast toward the NS-originating node.

   Through this procedure, vehicles and RSUs can rapidly discover the
   network prefixes and services of the other party without any
   additional service discovery protocol.

6.  Security Considerations

   This document shares all the security issues of the neighbor
   discovery protocol.  This document can get benefits from secure
   neighbor discovery (SEND) [RFC3971] in order to protect ND from
   possible security attacks.

7.  Acknowledgements

   This work was supported by 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
   the Global Research Laboratory Program (2013K1A1A2A02078326) through
   NRF and the DGIST Research and Development Program (CPS Global
   Center) funded by the Ministry of Science and ICT.

8.  References

8.1.  Normative References

   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]       Deering, S. and R. Hinden, "Internet Protocol,
                   Version 6 (IPv6) Specification", RFC 2460,
                   December 1998.

   [RFC4861]       Narten, T., Nordmark, E., Simpson, W., and H.
                   Soliman, "Neighbor Discovery for IP Version 6
                   (IPv6)", RFC 4861, September 2007.

   [RFC4862]       Thomson, S., Narten, T., and T. Jinmei, "IPv6
                   Stateless Address Autoconfiguration", RFC 4862,
                   September 2007.

   [RFC6106]       Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
                   "IPv6 Router Advertisement Options for DNS

Jeong, et al.              Expires May 3, 2018                  [Page 9]
Internet-Draft        Vehicular Neighbor Discovery          October 2017

                   Configuration", RFC 6106, November 2010.

8.2.  Informative References

   [DSRC-WAVE]     Morgan, Y., "Notes on DSRC & WAVE Standards Suite:
                   Its Architecture, Design, and Characteristics",
                   IEEE Communications Surveys & Tutorials, 12(4), 2012.

   [IEEE-802.11p]  IEEE Std 802.11p, "Part 11: Wireless LAN Medium
                   Access Control (MAC) and Physical Layer (PHY)
                   Specifications Amendment 6: Wireless Access in
                   Vehicular Environments", June 2010.

   [IEEE-802.11a]  IEEE Std 802.11a, "Part 11: Wireless LAN Medium
                   Access Control (MAC) and Physical Layer (PHY)
                   specifications: High-speed Physical Layer in the 5
                   GHZ Band", September 1999.

   [ID-DNSNA]      Jeong, J., Ed., Lee, S., and J. Park, "DNS Name
                   Autoconfiguration for Internet of Things Devices",
                   draft-jeong-ipwave-iot-dns-autoconf-01 (work in
                   progress), October 2017.

   [RFC3971]       Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)",
                   RFC 3971, March 2005.

Appendix A.  Changes from
             draft-jeong-ipwave-vehicular-neighbor-discovery-00

   The following changes are made from
   draft-jeong-ipwave-vehicular-neighbor-discovery-00:

   o  In Section 1, the trend of Ethernet installation in a vehicle for
      remote diagnosis is introduced.

Jeong, et al.              Expires May 3, 2018                 [Page 10]
Internet-Draft        Vehicular Neighbor Discovery          October 2017

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

   Yiwen Chris Shen
   Department of Computer Science and Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do  16419
   Republic of Korea

   Phone: +82 31 299 4106
   Fax:   +82 31 290 7996
   EMail: chrisshen@skku.edu

   Younghwa Jo
   Department of Software Platform
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do  16419
   Republic of Korea

   Phone: +82 31 299 4106
   Fax:   +82 31 290 7996
   EMail: movie_jo@naver.com

   Junsik Jeong
   Software R&D Center
   Samsung Electronics
   Seoul R&D Campus D-Tower, 56, Seongchon-Gil, Seocho-Gu
   Seoul  06765
   Republic of Korea

   EMail: jun.jeong@samsung.com

Jeong, et al.              Expires May 3, 2018                 [Page 11]
Internet-Draft        Vehicular Neighbor Discovery          October 2017

   Jong-Hyouk Lee
   Sangmyung University
   Sangmyung University
   31, Sangmyeongdae-gil, Dongnam-gu
   Cheonan, NY  31066
   Republic of Korea

   EMail: jonghyouk@smu.ac.kr

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