Internet-Draft ID/LOC Separation in Vehicular Networks October 2020
Sun & Kim Expires 18 April 2021 [Page]
Workgroup:
IPWAVE Working Group
Internet-Draft:
draft-kjsun-ipwave-id-loc-separation-03
Published:
Intended Status:
Informational
Expires:
Authors:
K. Sun
Soongsil University
Y. Kim
Soongsil University

Considerations for ID/Location Separation Protocols in IPv6-based Vehicular Networks

Abstract

ID/Location separation protocols are proposed for scalable routing, enhancing mobility and privacy in IPv6-based vehicular networks. In IPv6-based vehicular networks, ID/Location separation architecture is expected to offer benefits. This document analyzes how ID/Location separation protocols can adjust into IP based vehicular networks and suggests requirements for efficient ID/Location separation in vehicular networks.

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 18 April 2021.

Table of Contents

1. Introduction

For vehicular networks, it is required to provide connection to the Intelligent Transport Systems (ITS) for the driver's safety, efficient driving and entertainment with fast mobility management. Other scenarios besides V2I communication, like V2V and V2X communication are also considered. Link layer protocols such as IEEE 802.11-OCB [IEEE-802.11-OCB] are already defined for low-latency and alternative networks, and it is designed for enabling IPv6 as a network layer protocol. Nevertheless, for using IPv6 in the vehicular network, there are some requirements for optimization as described in [ietf-ipwave-vehicular-networking]. These issues are classified into IPv6 neighbor discovery, mobility management, security and privacy.

In IETF, there are two major ID/Location separation protocols such as LISP [RFC6830] and ILNP [RFC6740] for scalable routing, enhancing privacy and mobility management. Currently ID/Location separation concept is useful not only for decomposing ID/Location from an IP address, but also for control/data plane separation which is a major evolution of the Internet infrastructure. For the vehicular networks, ID/Location separation protocols can be expected to meet requirements and solve problem statements discussed in IPWAVE WG. This document describes use cases for applying ID/Location separation architecture to IPv6-based vehicular networks, and analyzes how such protocols can meet requirements for IPv6 in vehicular networks.

2. Terminology

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 [RFC2119]. This document uses the terminology described in [ietf-ipwave-vehicular-networking], [RFC6830], [RFC6740].

3. Vehicular Network Architecture with ID/Location Separation

                     Traffic Control Center in Vehicular Cloud
                    *******************************************
+-------------+    *                                           *
|Corresponding|   *             +-----------------+             *
|    Node     |<->*             |   ID/Location   |             *
+-------------+   *             |  Mapping System |             *
                  *             +--------^--------+             *
                  *                      |                      *
                   *                     v                     *
                    *******************************************
                    ^                   ^                     ^
                    |                   |                     |
                    |                   |                     |
                    v                   v                     v
              +----------+         +----------+         +----------+
              | LOC-RSU1 |<------->| LOC-RSU2 |<------->| LOC-RSU3 |
              +----------+         +----------+         +----------+
                  ^                     ^                    ^
                  :                     :                    :
              +-----------------+ +-----------------+   +-----------------+
              |      : V2I      | |        : V2I    |   |       : V2I     |
              |      v          | |        v        |   |       v         |
+-----------+ |   +-----------+ | |  +-----------+  |   | +-----------+   |
|ID-Vehicle1|===> |ID-Vehicle2|===>  |ID-Vehicle3|===>  | |ID-Vehicle4|==>|
+-----------+<...>+-----------+<....>+-----------+  |   | +-----------+   |
              V2V     ^         V2V        ^        |   |        ^        |
              |       : V2V     | |        : V2V    |   |        : V2V    |
              |       v         | |        v        |   |        v        |
              |   +-----------+ | |  +-----------+  |   | +-----------+   |
              |   |ID-Vehicle5|===>  |ID-Vehicle6|===>  | |ID-Vehicle7|==>|
              |   +-----------+ | |  +-----------+  |   | +-----------+   |
              +-----------------+ +-----------------+   +-----------------+
                   LOC site1           LOC site2              LOC site3

           <----> Wired Link   <....> Wireless Link   ===> Moving Direction
Figure 1: Vehicular Network Architecture with ID/Location Separation

Figure 1 shows a conceptional architecture of vehicular networks with ID/Location Separation. All components in the architecture can be mapped with components defined in [ietf-ipwave-vehicular-networking]. For ID, fixed values which is similar IP address are assigned to all network interfaces of vehicle. In the case of LISP [RFC6830], a 128-bit value which is the full length of IPv6 address can be defined as unique End-Point IDs (EIDs), which can communicate with other EIDs in the same LISP site same as a legacy IPv6 operation. On the other hand, ILNPv6 [RFC6740] uses just a 64-bit value in the IPv6 address field as an Identifier.

Since each RSU can represent the location of vehicles that are connected to the network, they can be defined as a locator. For LISP, which is a network-based approach, LISP router functions can be implemented inside of RSU. In the case of ILNPv6, as same as ID, the locator is configured in 64-bit length in the IPv6 address field and it can be represented subnet of each RSU. That is, in the ILNPv6, the general IPv6 address value is replaced with an Identifier-Locator Vector (I-LV) allowing it to be applied to the current IPv6 header without modification.

In ID/Location separation architectures, managing mapping information of ID and its allocated locator is necessary. With the mapping system, the corresponding node which is located external network or even inside the vehicular network can get the current location of the vehicle ID to communicate with and configure the routing path. Also, instead of the mobility anchor, the mapping system can support the mobility management of vehicles by updating the location value of ID according to changes in their location. The mapping system can be implemented in different ways depending on the protocol. For example, ILNPv6 defines new DNS resource record type for mapping I-LV values. A DNS server deployed in the vehicular cloud is accessible from both in ILNP site and the external Internet.

4. Gap Analysis

4.1. Neighbor Discovery

In both cases of LISP and ILNP, the usage of the existing neighbor discovery message defined in [RFC4861] is possible without modification. In LISP, Vehicles and RSUs in the same LISP site can exchange ND/NA messages for routing by EID configured as IPv6 format. Also, ILNP can operate the neighbor discovery for the configuration of an I-LV value as the I-LV for ILNPv6 occupies the same bits as the IPv6 address in the IPv6 header[RFC6740]. Thus, for vehicular networking, it is expected that the same solutions already mentioned in [ietf-ipwave-vehicular-networking] (e.g., new ND option [ID-Vehicular-ND]) can also be applicable in the ID/Location separation architecture.

4.2. Mobility Management

One of the advantages for using LISP is that mobility management can be provided efficiently, when a device is roaming across different LISP sites while maintaining its EID. The existing IP mobility management schemes such as MIP or PMIP require an anchor function (e.g., Home Agent and Local Mobility Anchor) to maintain the IP address of a mobile node when the mobile node moves. They can construct a non-optimized forwarding path between the anchor and current attachment point of the mobile node. In LISP, however, a forwarding path can be optimized by updating EID-RLOC mapping information and establishing an IP tunnel between the xTR of the corresponding node and the xTR of the current mobile node's attachment point. This provides advantages for easily optimizing a forwarding path especially the vehicular networks where the connection point of the mobile node can be move fast away from its initial attachment point. In the vehicular networks, a vehicle with an EID will roam much faster and it means that the mapped RLOC will be changed more frequently. For faster RLOC assignment, a predictive RLOC algorithm for roaming-EID is proposed in LISP WG [draft-ietf-lisp-predictive-rlocs]. Using this algorithm, it predicts the moving direction of a vehicle with a roaming-EID, registers predictive RLOCs as a list to the mapping system, and replicates packets to each RLOC in the list. It can minimize packet loss while maintaining transport session continuity.

In ILNP, mobility management is classified into host mobility and network (or site) mobility. For vehicular networks, host mobility scenario is suitable [RFC6740]. When the vehicle moves to its network attachment point and locator, it shortly becomes to belong to a new site, it may send a Locator Update (LU) message to the Corresponding Node (CN) and also send a request to the DNS server to change its entry. Even though LU procedure is necessary, it causes delay and packet loss during handover, and it may become a more critical issue in the vehicular networks where the locator of a vehicle is updated faster and more frequently. Therefore, ILNP needs to minimize LU process including DNS updates for seamless mobility management in vehicular networks. For example, [ILNP-Sol-Wireless-Net] may be one possible solution that defines a geological information server, which gives information of attachment points nearby to devices to prepare handover, deliver its predictive locator to the CN so that it can reduce packet loss and latency for updating DNS.

4.3. Security and Privacy

For supporting applications such as autonomous driving, the vehicular networks require not only low latency and high bandwidth but also a high level of security and privacy. The IPWAVE working group is facing a mobility management challenge due to latency and management complexity due to the exchange of signaling messages with mobility anchor to establish a tunnel. In the ID/Location separation approach, all vehicles maintain their unique ID while they are allocated a locator in the fastest way without binding update procedure. Nevertheless, a privacy problem still exists due to the easy access to the mapping system. Even though it is difficult to track a device using a single RLOC or locator value since its locator changes while moving across sites, on the other hand, since an EID or identifier is defined as permanent, additional methodologies need to be considered to secure device identifier information.

Another consideration is various communication links. In the vehicular networks, not only V2I communication but also V2X communication are required. It means that vehicles can directly communicate with each other only with an ID value without a locator which is allocated from the infrastructure. In this scenario, the exposure of vehicle IDs to others (including hackers) occurs frequently even though they do not access mapping system. In [draft-iannone-pidloc-privacy], they describe about privacy issues and requirements in ID/Location separation architecture.

Several existing works can provide enhanced privacy mechanisms in ID/Location separation architectures. For example, [draft-ietf-lisp-eid-anonymity] defines Ephemeral-EID which is frequently changed by the device. For ILNP, identity privacy supports using IPv6 privacy extensions for stateless address auto-configuration [RFC4941] and Locator Rewriting Relay (LRR) component for locator privacy [RFC6748], can be solutions for enhancing privacy in vehicular networks.

5. Acknkowledgement

We would like to thank Jahoon Paul Jeong as a contributor who reviewed and gave comments for this version.

6. Informative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[IEEE-802.11-OCB]
"Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2016, .
[ietf-ipwave-vehicular-networking]
Jeong, J., "IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases", Work in Progress, Internet-Draft, draft-ietf-ipwave-vehicular-networking-13(working on progress), , <https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-13(working on progress)>.
[RFC6830]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, , <https://www.rfc-editor.org/rfc/rfc6830>.
[RFC6740]
Atkinson, RJ., Bhatti, SN., and U. St Andrews, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, , <https://www.rfc-editor.org/rfc/rfc6740>.
[RFC6741]
Atkinson, RJ., Bhatti, SN., and U. St Andrews, "Identifier-Locator Network Protocol (ILNP) Engineering Considerations", RFC 6741, , <https://www.rfc-editor.org/rfc/rfc6741>.
[RFC4861]
Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, , <https://www.rfc-editor.org/rfc/rfc4861>.
[ID-Vehicular-ND]
Jeong, J., Shen, Y., and Z. Xiang, "Vehicular Neighbor Discovery for IP-Based Vehicular Network", Work in Progress, Internet-Draft, draft-jeong-ipwave-vehicular-neighbor-discovery-08(working on progress), , <https://tools.ietf.org/html/draft-jeong-ipwave-vehicular-neighbor-discovery-08(working on progress)>.
[draft-ietf-lisp-predictive-rlocs]
Farinacci, D. and P. Pillay-Esnault, "LISP Predictive RLOCs", Work in Progress, Internet-Draft, draft-ietf-lisp-predictive-rlocs-05(working on progress), , <https://tools.ietf.org/html/draft-ietf-lisp-predictive-rlocs-05(working on progress)>.
[ILNP-Sol-Wireless-Net]
Isah, M. and CJ. Edwards, "An ILNP-based solution for future heterogeneous wireless networks", PGNET 2013: Proceedings of the 14th Annual Postgraduate Symposium on the Convergence of Telecommunications, Networking and Broadcasting, .
[draft-ietf-lisp-eid-anonymity]
Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP EID Anonymity", Work in Progress, Internet-Draft, draft-ietf-lisp-eid-anonymity-07(working on progress), , <https://tools.ietf.org/html/draft-ietf-lisp-eid-anonymity-07(working on progress)>.
[RFC4941]
Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, , <https://www.rfc-editor.org/rfc/rfc4941>.
[RFC6748]
Atkinson, RJ., Bhatti, SN., and U. St Andrews, "Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)", RFC 6748, , <https://www.rfc-editor.org/rfc/rfc6748>.
[draft-iannone-pidloc-privacy]
Iannone, L., von Hugo, D., Sarikaya, B., and E. Nordmark, "Privacy issues in Identifier/Locator Separation Systems", Work in Progress, Internet-Draft, draft-iannone-pidloc-privacy-00 (working on progress), , <https://tools.ietf.org/html/draft-iannone-pidloc-privacy-00 (working on progress)>.

Authors' Addresses

Kyoungjae Sun
School of Electronic Engineering
Soongsil University
369, Sangdo-ro, Dongjak-gu
Seoul
Seoul
06978
Republic of Korea
Younghan Kim
School of Electronic Engineering
Soongsil University
369, Sangdo-ro, Dongjak-gu
Seoul
Seoul
06978
Republic of Korea