idnits 2.17.1 draft-kjsun-ipwave-id-loc-separation-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 14 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 15, 2020) is 1289 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6741' is defined on line 333, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-vehicular-neighbor-discovery-08 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPWAVE Working Group K. Sun 3 Internet-Draft Y. Kim 4 Intended status: Informational Soongsil University 5 Expires: April 18, 2021 October 15, 2020 7 Considerations for ID/Location Separation Protocols in IPv6-based 8 Vehicular Networks 9 draft-kjsun-ipwave-id-loc-separation-03 11 Abstract 13 ID/Location separation protocols are proposed for scalable routing, 14 enhancing mobility and privacy in IPv6-based vehicular networks. In 15 IPv6-based vehicular networks, ID/Location separation architecture is 16 expected to offer benefits. This document analyzes how ID/Location 17 separation protocols can adjust into IP based vehicular networks and 18 suggests requirements for efficient ID/Location separation in 19 vehicular networks. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 18, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Vehicular Network Architecture with ID/Location Separation . 3 58 4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 4 60 4.2. Mobility Management . . . . . . . . . . . . . . . . . . . 5 61 4.3. Security and Privacy . . . . . . . . . . . . . . . . . . 6 62 5. Acknkowledgement . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Informative References . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 For vehicular networks, it is required to provide connection to the 69 Intelligent Transport Systems (ITS) for the driver's safety, 70 efficient driving and entertainment with fast mobility management. 71 Other scenarios besides V2I communication, like V2V and V2X 72 communication are also considered. Link layer protocols such as IEEE 73 802.11-OCB [IEEE-802.11-OCB] are already defined for low-latency and 74 alternative networks, and it is designed for enabling IPv6 as a 75 network layer protocol. Nevertheless, for using IPv6 in the 76 vehicular network, there are some requirements for optimization as 77 described in [ietf-ipwave-vehicular-networking]. These issues are 78 classified into IPv6 neighbor discovery, mobility management, 79 security and privacy. 81 In IETF, there are two major ID/Location separation protocols such as 82 LISP [RFC6830] and ILNP [RFC6740] for scalable routing, enhancing 83 privacy and mobility management. Currently ID/Location separation 84 concept is useful not only for decomposing ID/Location from an IP 85 address, but also for control/data plane separation which is a major 86 evolution of the Internet infrastructure. For the vehicular 87 networks, ID/Location separation protocols can be expected to meet 88 requirements and solve problem statements discussed in IPWAVE WG. 89 This document describes use cases for applying ID/Location separation 90 architecture to IPv6-based vehicular networks, and analyzes how such 91 protocols can meet requirements for IPv6 in vehicular networks. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. This 98 document uses the terminology described in 99 [ietf-ipwave-vehicular-networking], [RFC6830], [RFC6740]. 101 3. Vehicular Network Architecture with ID/Location Separation 103 Traffic Control Center in Vehicular Cloud 104 ******************************************* 105 +-------------+ * * 106 |Corresponding| * +-----------------+ * 107 | Node |<->* | ID/Location | * 108 +-------------+ * | Mapping System | * 109 * +--------^--------+ * 110 * | * 111 * v * 112 ******************************************* 113 ^ ^ ^ 114 | | | 115 | | | 116 v v v 117 +----------+ +----------+ +----------+ 118 | LOC-RSU1 |<------->| LOC-RSU2 |<------->| LOC-RSU3 | 119 +----------+ +----------+ +----------+ 120 ^ ^ ^ 121 : : : 122 +-----------------+ +-----------------+ +-----------------+ 123 | : V2I | | : V2I | | : V2I | 124 | v | | v | | v | 125 +-----------+ | +-----------+ | | +-----------+ | | +-----------+ | 126 |ID-Vehicle1|===> |ID-Vehicle2|===> |ID-Vehicle3|===> | |ID-Vehicle4|==>| 127 +-----------+<...>+-----------+<....>+-----------+ | | +-----------+ | 128 V2V ^ V2V ^ | | ^ | 129 | : V2V | | : V2V | | : V2V | 130 | v | | v | | v | 131 | +-----------+ | | +-----------+ | | +-----------+ | 132 | |ID-Vehicle5|===> |ID-Vehicle6|===> | |ID-Vehicle7|==>| 133 | +-----------+ | | +-----------+ | | +-----------+ | 134 +-----------------+ +-----------------+ +-----------------+ 135 LOC site1 LOC site2 LOC site3 137 <----> Wired Link <....> Wireless Link ===> Moving Direction 139 Figure 1: Vehicular Network Architecture with ID/Location Separation 140 Figure 1 shows a conceptional architecture of vehicular networks with 141 ID/Location Separation. All components in the architecture can be 142 mapped with components defined in [ietf-ipwave-vehicular-networking]. 143 For ID, fixed values which is similar IP address are assigned to all 144 network interfaces of vehicle. In the case of LISP [RFC6830], a 145 128-bit value which is the full length of IPv6 address can be defined 146 as unique End-Point IDs (EIDs), which can communicate with other EIDs 147 in the same LISP site same as a legacy IPv6 operation. On the other 148 hand, ILNPv6 [RFC6740] uses just a 64-bit value in the IPv6 address 149 field as an Identifier. 151 Since each RSU can represent the location of vehicles that are 152 connected to the network, they can be defined as a locator. For 153 LISP, which is a network-based approach, LISP router functions can be 154 implemented inside of RSU. In the case of ILNPv6, as same as ID, the 155 locator is configured in 64-bit length in the IPv6 address field and 156 it can be represented subnet of each RSU. That is, in the ILNPv6, 157 the general IPv6 address value is replaced with an Identifier-Locator 158 Vector (I-LV) allowing it to be applied to the current IPv6 header 159 without modification. 161 In ID/Location separation architectures, managing mapping information 162 of ID and its allocated locator is necessary. With the mapping 163 system, the corresponding node which is located external network or 164 even inside the vehicular network can get the current location of the 165 vehicle ID to communicate with and configure the routing path. Also, 166 instead of the mobility anchor, the mapping system can support the 167 mobility management of vehicles by updating the location value of ID 168 according to changes in their location. The mapping system can be 169 implemented in different ways depending on the protocol. For 170 example, ILNPv6 defines new DNS resource record type for mapping I-LV 171 values. A DNS server deployed in the vehicular cloud is accessible 172 from both in ILNP site and the external Internet. 174 4. Gap Analysis 176 4.1. Neighbor Discovery 178 In both cases of LISP and ILNP, the usage of the existing neighbor 179 discovery message defined in [RFC4861] is possible without 180 modification. In LISP, Vehicles and RSUs in the same LISP site can 181 exchange ND/NA messages for routing by EID configured as IPv6 format. 182 Also, ILNP can operate the neighbor discovery for the configuration 183 of an I-LV value as the I-LV for ILNPv6 occupies the same bits as the 184 IPv6 address in the IPv6 header[RFC6740]. Thus, for vehicular 185 networking, it is expected that the same solutions already mentioned 186 in [ietf-ipwave-vehicular-networking] (e.g., new ND option 188 [ID-Vehicular-ND]) can also be applicable in the ID/Location 189 separation architecture. 191 4.2. Mobility Management 193 One of the advantages for using LISP is that mobility management can 194 be provided efficiently, when a device is roaming across different 195 LISP sites while maintaining its EID. The existing IP mobility 196 management schemes such as MIP or PMIP require an anchor function 197 (e.g., Home Agent and Local Mobility Anchor) to maintain the IP 198 address of a mobile node when the mobile node moves. They can 199 construct a non-optimized forwarding path between the anchor and 200 current attachment point of the mobile node. In LISP, however, a 201 forwarding path can be optimized by updating EID-RLOC mapping 202 information and establishing an IP tunnel between the xTR of the 203 corresponding node and the xTR of the current mobile node's 204 attachment point. This provides advantages for easily optimizing a 205 forwarding path especially the vehicular networks where the 206 connection point of the mobile node can be move fast away from its 207 initial attachment point. In the vehicular networks, a vehicle with 208 an EID will roam much faster and it means that the mapped RLOC will 209 be changed more frequently. For faster RLOC assignment, a predictive 210 RLOC algorithm for roaming-EID is proposed in LISP WG 211 [draft-ietf-lisp-predictive-rlocs]. Using this algorithm, it 212 predicts the moving direction of a vehicle with a roaming-EID, 213 registers predictive RLOCs as a list to the mapping system, and 214 replicates packets to each RLOC in the list. It can minimize packet 215 loss while maintaining transport session continuity. 217 In ILNP, mobility management is classified into host mobility and 218 network (or site) mobility. For vehicular networks, host mobility 219 scenario is suitable [RFC6740]. When the vehicle moves to its 220 network attachment point and locator, it shortly becomes to belong to 221 a new site, it may send a Locator Update (LU) message to the 222 Corresponding Node (CN) and also send a request to the DNS server to 223 change its entry. Even though LU procedure is necessary, it causes 224 delay and packet loss during handover, and it may become a more 225 critical issue in the vehicular networks where the locator of a 226 vehicle is updated faster and more frequently. Therefore, ILNP needs 227 to minimize LU process including DNS updates for seamless mobility 228 management in vehicular networks. For example, 229 [ILNP-Sol-Wireless-Net] may be one possible solution that defines a 230 geological information server, which gives information of attachment 231 points nearby to devices to prepare handover, deliver its predictive 232 locator to the CN so that it can reduce packet loss and latency for 233 updating DNS. 235 4.3. Security and Privacy 237 For supporting applications such as autonomous driving, the vehicular 238 networks require not only low latency and high bandwidth but also a 239 high level of security and privacy. The IPWAVE working group is 240 facing a mobility management challenge due to latency and management 241 complexity due to the exchange of signaling messages with mobility 242 anchor to establish a tunnel. In the ID/Location separation 243 approach, all vehicles maintain their unique ID while they are 244 allocated a locator in the fastest way without binding update 245 procedure. Nevertheless, a privacy problem still exists due to the 246 easy access to the mapping system. Even though it is difficult to 247 track a device using a single RLOC or locator value since its locator 248 changes while moving across sites, on the other hand, since an EID or 249 identifier is defined as permanent, additional methodologies need to 250 be considered to secure device identifier information. 252 Another consideration is various communication links. In the 253 vehicular networks, not only V2I communication but also V2X 254 communication are required. It means that vehicles can directly 255 communicate with each other only with an ID value without a locator 256 which is allocated from the infrastructure. In this scenario, the 257 exposure of vehicle IDs to others (including hackers) occurs 258 frequently even though they do not access mapping system. In 259 [draft-iannone-pidloc-privacy], they describe about privacy issues 260 and requirements in ID/Location separation architecture. 262 Several existing works can provide enhanced privacy mechanisms in ID/ 263 Location separation architectures. For example, 264 [draft-ietf-lisp-eid-anonymity] defines Ephemeral-EID which is 265 frequently changed by the device. For ILNP, identity privacy 266 supports using IPv6 privacy extensions for stateless address auto- 267 configuration [RFC4941] and Locator Rewriting Relay (LRR) component 268 for locator privacy [RFC6748], can be solutions for enhancing privacy 269 in vehicular networks. 271 5. Acknkowledgement 273 We would like to thank Jahoon Paul Jeong as a contributor who 274 reviewed and gave comments for this version. 276 6. Informative References 278 [draft-iannone-pidloc-privacy] 279 Iannone, L., von Hugo, D., Sarikaya, B., and E. Nordmark, 280 "Privacy issues in Identifier/Locator Separation Systems", 281 draft-iannone-pidloc-privacy-00 (working on progress) 282 (work in progress), January 2020. 284 [draft-ietf-lisp-eid-anonymity] 285 Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP 286 EID Anonymity", draft-ietf-lisp-eid-anonymity-07(working 287 on progress) (work in progress), October 2019. 289 [draft-ietf-lisp-predictive-rlocs] 290 Farinacci, D. and P. Pillay-Esnault, "LISP Predictive 291 RLOCs", draft-ietf-lisp-predictive-rlocs-05(working on 292 progress) (work in progress), November 2019. 294 [ID-Vehicular-ND] 295 Jeong, J., Shen, Y., and Z. Xiang, "Vehicular Neighbor 296 Discovery for IP-Based Vehicular Network", draft-jeong- 297 ipwave-vehicular-neighbor-discovery-08(working on 298 progress) (work in progress), November 2019. 300 [IEEE-802.11-OCB] 301 "Part 11: Wireless LAN Medium Access Control (MAC) and 302 Physical Layer (PHY) Specifications", IEEE Std 303 802.11-2016, December 2016. 305 [ietf-ipwave-vehicular-networking] 306 Jeong, J., "IP Wireless Access in Vehicular Environments 307 (IPWAVE): Problem Statement and Use Cases", draft-ietf- 308 ipwave-vehicular-networking-13(working on progress) (work 309 in progress), January 2020. 311 [ILNP-Sol-Wireless-Net] 312 Isah, M. and CJ. Edwards, "An ILNP-based solution for 313 future heterogeneous wireless networks", PGNET 314 2013: Proceedings of the 14th Annual Postgraduate 315 Symposium on the Convergence of Telecommunications, 316 Networking and Broadcasting, June 2013. 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", RFC 2119, March 1997. 321 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 322 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 323 September 2007. 325 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 326 Extensions for Stateless Address Autoconfiguration in 327 IPv6", RFC 4941, September 2007. 329 [RFC6740] Atkinson, RJ., Bhatti, SN., and U. St Andrews, 330 "Identifier-Locator Network Protocol (ILNP) Architectural 331 Description", RFC 6740, November 2012. 333 [RFC6741] Atkinson, RJ., Bhatti, SN., and U. St Andrews, 334 "Identifier-Locator Network Protocol (ILNP) Engineering 335 Considerations", RFC 6741, November 2012. 337 [RFC6748] Atkinson, RJ., Bhatti, SN., and U. St Andrews, "Optional 338 Advanced Deployment Scenarios for the Identifier-Locator 339 Network Protocol (ILNP)", RFC 6748, November 2012. 341 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 342 Locator/ID Separation Protocol (LISP)", RFC 6830, January 343 2013. 345 Authors' Addresses 347 Kyoungjae Sun 348 School of Electronic Engineering 349 Soongsil University 350 369, Sangdo-ro, Dongjak-gu 351 Seoul, Seoul 06978 352 Republic of Korea 354 Phone: +82 10 3643 5627 355 EMail: gomjae@dcn.ssu.ac.kr 357 Younghan Kim 358 School of Electronic Engineering 359 Soongsil University 360 369, Sangdo-ro, Dongjak-gu 361 Seoul, Seoul 06978 362 Republic of Korea 364 Phone: +82 10 2691 0904 365 EMail: younghak@ssu.ac.kr