[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08                                    
IPWAVE Working Group                                              Z. Yan
Internet-Draft                                                     CNNIC
Intended status: Standards Track                                 J. Weng
Expires: May 19, 2021                                            G. Geng
                                                        Jinan University
                                                                  J. Lee
                                                    Sangmyung University
                                                                J. Jeong
                                                 Sungkyunkwan University
                                                       November 15, 2020


Service and Neighbor Vehicle Discovery in IPv6-Based Vehicular Networks
                       draft-yan-ipwave-nd-07.txt

Abstract

   For Cooperative Adaptive Cruise Control (C-ACC), platooning and other
   typical use cases in Intelligent Transportation System (ITS), IPv6
   communication between neighbor vehicles and between vehicle and
   server pose the following two issues: 1) how to discover a neighbor
   vehicle and the demanded service; and 2) how to discover the link-
   layer address and other metadata of the neighbor vehicle and selected
   server.  This document presents a solution to these problems based on
   DNS-SD/mDNS [RFC6762][RFC6763].

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.

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 19, 2021.



Yan, et al.               Expires May 19, 2021                  [Page 1]


Internet-Draft                 ITS SeNeDis                 November 2020


Copyright Notice

   Copyright (c) 2020 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
   (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.  Name and address configurations . . . . . . . . . . . . . . .   3
   3.  Service and neighbor vehicle discovery  . . . . . . . . . . .   3
   4.  Mobility support  . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Signaling messages  . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security considerations . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   As illustrated in [DNS-Autoconf], a naming scheme is needed for the
   vehicle devices to support the unique name auto-configuration.  This
   can support the location based communication and scalable information
   organization in Intelligent Transportation Systems (ITS).  Based on
   the naming scheme like this and the widely-used DNS-SD/mDNS protocol,
   this document illustrates how to discover a neighbor vehicle or the
   required services with DNS resolution logic.  Before this, we make
   the following assumptions:

   o  Name: A vehicle SHOULD have at least one temporary name which may
      be related with its geo-location or provided services.  This name
      is related with the service or identifier of the particular
      vehicle.

   o  Address: A vehicle SHOULD have at least one global IP address
      which is routable for the IPv6 communications.  This address acts
      as the Home Address (HoA) of vehicle to facilitate its mobility.




Yan, et al.               Expires May 19, 2021                  [Page 2]


Internet-Draft                 ITS SeNeDis                 November 2020


   In this way, a standardized, efficient and scalable scheme should be
   used to retrieve the necessary information of the corresponding node
   (domain name, IP address, geo-location, link-layer address, key and
   so on) for the further communications based on the DNS-SD/mDNS
   functions.  In addition, the IPv6 Neighbor Discovery (ND)'s messages
   (e.g., RA and RS messages) can also be used to exchange some required
   information (e.g., mobile network prefixes) in ITS in combination
   with DNS-SD/mDNS [MNPP].

2.  Name and address configurations

   Typically, the Road-Side Unit (RSU) acts as an Access Router (AR) to
   serve for the static and moving vehicles which want to be connected
   into the networks locally or publically.

   Based on [RFC3646], [RFC6106] or extended WAVE Service Announcement
   (WSA) message, the RSU can announce its location based name prefix to
   the vehicles covered by the RSU.  This location based prefix may
   contain information such as country, city, street and so on, which
   will act as the "domain_name" of the vehicle device name as specified
   in [DNS-Autoconf].

   The RSU may also advertise the IPv6 prefix to support the IPv6
   Stateless Address Auto-configuration (SLAAC) operation of vehicle
   devices and movement detection (in the IP layer).  If the DHCPv6 is
   used for the address configuration, RSU also acts as functional
   entity such as a DHCP proxy and DHCP server.

3.  Service and neighbor vehicle discovery

   Vehicular network is a dynamic environment, then the following two
   modes should be supported based on different connection conditions of
   the vehicle.

   (1) RSU based

   Vehicles may have direct connection with the serving RSU and join the
   same link with the serving RSU.  Then the RSU can maintain the
   registered vehicles and services in its serving domain.  Otherwise,
   the RSU acts as a proxy node for discovering in a proxy manner
   [DNSSD-Hybrid].

   When a vehicle wants to locate the potential service or the nearby
   neighbor and further establish the communication, the vehicle will
   trigger the direct unicast query to port 5353 or legacy unicast DNS
   query to the RSU.  RSU may respond directly if it has the related
   information, otherwise, the RSU multicasts the DNS query to the
   multicast group to retrieve the related information.  A unicast



Yan, et al.               Expires May 19, 2021                  [Page 3]


Internet-Draft                 ITS SeNeDis                 November 2020


   response is the first recommendation here because it can suppress the
   flooding, but of course, the DNS response message can also be
   multicasted as an active announcement of the vehicle or service
   existence.

   (2) Ad-hoc based

   Vehicles may communicate with each other or sense the front and rear
   neighbor vehicles with DSRC, WiFi, Bluetooth or other short-distance
   communication technologies, connecting each other in the Ad-hoc
   manner.  Then the discovery can also be executed in an
   infrastructure-less manner with the following phases, as specified in
   the plain mDNS.

   o  Probing: When a vehicle starts up, wakes up from sleeping mode or
      the Vehicular Ad Hoc Networks (VANET) topology changes (after
      configuration of the name and address), it should probe the
      availability of the service with which it can provide other
      vehicles.  Then the vehicle periodically announces the service and
      its existence with unsolicited multicast DNS response containing,
      in the Answer Section, all of its service name, DNS name, IP
      address and other information.  The vehicle also updates the
      related information actively if there is any change.

   o  Discovering: To support the service and neighbor vehicle discovery
      in the dynamic and fragmentation-possible environment in VANET,
      different query modes of mDNS can be used for different scenarios:
      1) One-Short Multicast DNS Query can be used to locate a specific
      vehicle. 2) Continuous Multicast DNS Query can be used to locate
      the nearby vehicles which are moving.

   o  Refreshing: After the neighbor discovery as illustrated above, the
      vehicles should continually exchange their DNS name, IP address,
      geo-location and other information in order to refresh the
      established communications.  For example, the Multiple Questions
      Multicast Responses can be used to update the caches of receivers
      efficiently and Multiple Questions Unicast Responses can be used
      to support the fast bootstrapping when a new vehicle joins.

   o  Goodbye: When the vehicle arrives at its destination, stops
      temporarily or shuts down its communication or sensing devices, it
      will announce the service suspending and its inexistence with an
      unsolicited multicast DNS response packet, giving the same
      Resource Records (RRs) (containing its DNS name and IP address),
      but with zero Time-To-Live (TTL).






Yan, et al.               Expires May 19, 2021                  [Page 4]


Internet-Draft                 ITS SeNeDis                 November 2020


4.  Mobility support

   During the movement of the vehicle, it may cross different RSUs.
   When a vehicle enters the coverage of a new RSU, the new domain
   prefix and new IPv6 prefix may be learned.  Generally, there are the
   following three main cases for the mobility:

   o  The domain name changes and the IP prefix remains.  The vehicle
      will configure a new DNS name from the new RSU.  Then the vehicle
      should update the new DNS name in the local database (e.g., RSU)
      with DNS Update [RFC2136], DNS Push Notifications [DNSSD-Push],
      Service Registration Protocol (SRP) [DNSSD-SRP] or just actively
      announce its new name information with plain mDNS notification
      scheme.  If the service is registered in the RSU, then the stale
      service should be withdrawn in order to reduce the management load
      [DNSSD-Lease].

   o  The domain name remains and the IP prefix changes.  The vehicle
      will configure a new IPv6 temporary address (e.g., CoA) form the
      new RSU.  Then the IP-layer mobility management protocols should
      be used to update the binding entry of the vehicle (e.g., Mobile
      IPv6 [RFC6275]).

   o  Both the domain name and IP prefix change, the name information
      should be updated as in the first case and then the IP-layer
      mobility management protocols (e.g., Mobile IPv6 [RFC6275] and
      Proxy Mobile IPv6 [RFC5213]) as in the second case should also be
      triggered.

5.  Signaling messages

   To facilitate the further communication, the link-layer address,
   public Key, geo-information and other metadata may be included in the
   DNS message in a piggyback manner.  Specially, the TXT RR in DNS-SD
   can be used to include these information with multiple key: value
   pairs.

   Besides, this kind of information may be obtained through the
   following IPv6 Neighbor Discovery Protocol (NDP) or other procedures
   (e.g., DHCP and WSA).

6.  Security considerations

   In order to reduce the DNS traffic on the wireless link and avoid the
   unnecessary flooding, the related schemes in mDNS can be used, such
   as: Known-Answer Suppression, Multipacket Known-Answer Suppression,
   Duplicate Question Suppression and Duplicate Answer Suppression.




Yan, et al.               Expires May 19, 2021                  [Page 5]


Internet-Draft                 ITS SeNeDis                 November 2020


   In order to guarantee the origination of the DNS message and avoid
   the DNS message tampering, the security consideration in mDNS should
   also be adopted.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, DOI 10.17487/RFC2136, April 1997,
              <https://www.rfc-editor.org/info/rfc2136>.

   [RFC3646]  Droms, R., Ed., "DNS Configuration options for Dynamic
              Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
              DOI 10.17487/RFC3646, December 2003,
              <https://www.rfc-editor.org/info/rfc3646>.

   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
              Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
              RFC 5213, DOI 10.17487/RFC5213, August 2008,
              <https://www.rfc-editor.org/info/rfc5213>.

   [RFC6106]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
              "IPv6 Router Advertisement Options for DNS Configuration",
              RFC 6106, DOI 10.17487/RFC6106, November 2010,
              <https://www.rfc-editor.org/info/rfc6106>.

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
              2011, <https://www.rfc-editor.org/info/rfc6275>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <https://www.rfc-editor.org/info/rfc6762>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/info/rfc6763>.







Yan, et al.               Expires May 19, 2021                  [Page 6]


Internet-Draft                 ITS SeNeDis                 November 2020


7.2.  Informative References

   [DNS-Autoconf]
              Jeong, J., Lee, S., and J. Park, "DNS Name
              Autoconfiguration for Internet-of-Things Devices in IP-
              Based Vehicular Networks",  draft-jeong-ipwave-iot-dns-
              autoconf-07, November 2019.

   [DNSSD-Hybrid]
              Cheshire, S., "Discovery Proxy for Multicast DNS-Based
              Service Discovery",   draft-ietf-dnssd-hybrid-10, March
              2019.

   [DNSSD-Lease]
              Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases",
              draft-sekar-dns-ul-02, August 2018.

   [DNSSD-Push]
              Pusateri, T. and S. Cheshire, "DNS Push Notifications",
              draft-ietf-dnssd-push-25, October 2019.

   [DNSSD-SRP]
              Cheshire, S. and T. Lemon, "Service Registration Protocol
              for DNS-Based Service Discovery",   draft-ietf-dnssd-srp-
              02, July 2019.

   [MNPP]     Lee, J., Tsukada, M., and T. Ernst, "Mobile Network Prefix
              Provisioning",  draft-jhlee-mext-mnpp-00, October 2009.

Authors' Addresses

   Zhiwei Yan
   CNNIC
   No.4 South 4th Street, Zhongguancun
   Beijing  100190
   China

   EMail: yan@cnnic.cn


   Jian Weng
   Jinan University
   No.601, West Huangpu Avenue
   Guangzhou  510632
   China

   EMail: cryptjweng@gmail.com




Yan, et al.               Expires May 19, 2021                  [Page 7]


Internet-Draft                 ITS SeNeDis                 November 2020


   Guanggang Geng
   Jinan University
   No.601, West Huangpu Avenue
   Guangzhou  510632
   China

   EMail: gggeng@jnu.edu.cn


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

   EMail: jonghyouk@smu.ac.kr


   Jaehoon Paul Jeong
   Department of Computer Science and Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do
   Republic of Korea

   EMail: pauljeong@skku.edu

























Yan, et al.               Expires May 19, 2021                  [Page 8]