idnits 2.17.1 draft-kjsun-ipwave-id-loc-separation-02.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.) 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 (March 09, 2020) is 1502 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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: 2 errors (**), 0 flaws (~~), 3 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: September 10, 2020 March 09, 2020 7 Considerations for ID/Location Separation Protocols in IPv6-based 8 Vehicular Networks 9 draft-kjsun-ipwave-id-loc-separation-02 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 September 10, 2020. 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. Use Cases for ID/Location Separation Protocols . . . . . . . 3 58 3.1. Locator/ID Separation Protocol (LISP) . . . . . . . . . . 3 59 3.2. Identifier-Locator Network Protocol (ILNP) . . . . . . . 4 60 4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 5 62 4.2. Mobility Management . . . . . . . . . . . . . . . . . . . 6 63 4.3. Security and Privacy . . . . . . . . . . . . . . . . . . 7 64 5. Acknkowledgement . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Informative References . . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 For vehicular networks, it is required to provide connection to the 71 Intelligent Transport Systems (ITS) for the driver's safety, 72 efficient driving and entertainment with fast mobility management. 73 Other scenarios besides V2I communication, like V2V and V2X 74 communication are also considered. Link layer protocols such as IEEE 75 802.11-OCB [IEEE-802.11-OCB] are already defined for low-latency and 76 alternative networks, and it is designed for enabling IPv6 as a 77 network layer protocol. Nevertheless, for using IPv6 in the 78 vehicular network, there are some requirements for optimization as 79 described in [ietf-ipwave-vehicular-networking]. These issues are 80 classified into IPv6 neighbor discovery, mobility management, 81 security and privacy. 83 In IETF, there are two major ID/Location separation protocols such as 84 LISP [RFC6830] and ILNP [RFC6740] for scalable routing, enhancing 85 privacy and mobility management. Currently ID/Location separation 86 concept is useful not only for decomposing ID/Location from an IP 87 address, but also for control/data plane separation which is a major 88 evolution of the Internet infrastructure. For the vehicular 89 networks, ID/Location separation protocols can be expected to meet 90 requirements and solve problem statements discussed in IPWAVE WG. 91 This document describes use cases for applying ID/Location separation 92 architecture to IPv6-based vehicular networks, and analyzes how such 93 protocols can meet requirements for IPv6 in vehicular networks. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. This 100 document uses the terminology described in 101 [ietf-ipwave-vehicular-networking], [RFC6830], [RFC6740]. 103 3. Use Cases for ID/Location Separation Protocols 105 3.1. Locator/ID Separation Protocol (LISP) 107 Traffic Control Center in Vehicular Cloud 108 *-----------------------------------------* 109 * * 110 * +----------------+ * 111 * | Mapping System | * 112 * +----------------+ * 113 * ^ * 114 * MS/MR | * 115 *--------------------v--------------------* 116 ^ ^ ^ 117 | | | 118 | | | 119 RLOC1 v v RLOC2 v RLOC3 120 +--------+ Ethernet +--------+ Tunneling +--------+ 121 | RSU1 |<---------->| RSU2 |<---------->| RSU3 | 122 | (xTR) | | (xTR) | | (xTR) | 123 +--------+ +--------+ +--------+ 124 ^ ^ ^ 125 +----:------------------:---------+ +--------:---------+ 126 | : V2I V2I : | | V2I : | 127 | v v | | v | 128 +--------+ | +--------+ +--------+ | | +--------+ | 129 |Vehicle1|===> |Vehicle2|===> |Vehicle3|===>| | |Vehicle4|===>| 130 | (EID) |<....>| (EID) |<....>| (EID) | | | | (EID) | | 131 +--------+ V2V +--------+ V2V +--------+ | | +--------+ | 132 | | | | 133 +---------------------------------+ +------------------+ 134 LISP Site-1 LISP Site-2 136 <----> Wired Link <....> Wireless Link ===> Moving Direction 138 Figure 1: LISP Use Case Scenario in IP-based Vehicular Network 139 Architecture 141 Figure 1 describes a vehicular network architecture with the LISP 142 protocol. A single LISP site can have multiple RSUs with the 143 function of LISP Tunnel Router (xTR) to communicate with other LISP 144 sites. In the figure, we assume that Vehicles 1, 2 and 3 belong to 145 LISP site 1 and Vehicle 4 to LISP site 2. IPv6 addresses for 146 wireless interfaces of each vehicle are mapped to unique End-Point 147 IDs (EIDs), which can communicate with other EIDs in the same LISP 148 site same as a legacy IPv6 operation. That is, vehicles are able to 149 communicate with an RSU by V2I communication at the same time with 150 other vehicles in the same LISP site by V2V communication. 152 Traffic control center in the vehicular cloud is appropriate to 153 deploy a mapping system, since it is a point accessible from all 154 RSUs. When vehicles enter each LISP site and attach to an RSU, the 155 RSU sends a Map-Register message to the mapping system including 156 vehicle's EID and RLOC of the attached RSU. After registration, the 157 vehicle can be provided with reachability from other LISP sites or 158 non-LISP sites. In the figure, for the communication between vehicle 159 4 and vehicle 3, RSU 3 which is the attachment point of Vehicle 4 160 should request for the RLOC of vehicle 3 from the mapping system by 161 sending Map-Requests message. After receiving mapping information of 162 Vehicle 3's EID and its RLOC in Map-Reply message, RLOC 3 can forward 163 packets via the IP tunnel between xTR (e.g., RSU 2 in this figure) 164 assigned to vehicle 3. Note that several data plane protocols (e.g., 165 SRv6, etc.) can be used with LISP control plane functions. 167 3.2. Identifier-Locator Network Protocol (ILNP) 169 In the ILNPv6, an IPv6 address is replaced with an Identifier-Locator 170 Vector (I-LV). The I-LV has a 128-bit length allowing it to be 171 applied to the current IPv6 header without modification. [RFC6740] 172 describes in detail how an I-LV value can replace an IPv6 address at 173 the same time how it can work in the current IPv6-based 174 infrastructure. In [RFC6741], the details of the ILNPv6 packet 175 header, locator subnetting and new DNS resource record type for 176 mapping I-LV values are defined. 178 A vehicular network architecture for supporting ILNP is shown in 179 Figure 2. Most of the components are similar with the architecture 180 described in [ietf-ipwave-vehicular-networking]. Every Vehicle can 181 have more than one NID to connect to a network, and the IPv6 address 182 for communication is represented as a combination of Node Identifier 183 (NID) and Locator. Site Border Router (SBR) can be implemented in an 184 RSU or border of ILNP subnet site, which should have a routing table 185 having the mapping information of I-LV values for forwarding packets. 186 A DNS server can be deployed in the vehicular cloud which is 187 accessible from both in ILNP site and external Internet. 189 Traffic Control Center in Vehicular Cloud 190 *-----------------------------------------* 191 * * 192 * +-----------------+ * 193 * | DNS Server | * 194 * +-----------------+ * 195 * ^ * 196 * | * 197 *--------------------v--------------------* 198 ^ ^ ^ 199 | | | 200 +---------------------+ | 201 | SBR | | 202 +---------------------+ | 203 | | | 204 v v v 205 +--------+ Ethernet +--------+ +--------+ 206 | RSU1 |<----------->| RSU2 |<------->|RSU3/SBR| 207 +--------+ +--------+ +--------+ 208 ^ ^ ^ 209 +----:------------------:---------+ +--------:---------+ 210 | : V2I V2I : | | V2I : | 211 | v v | | v | 212 +--------+ | +--------+ +--------+ | | +--------+ | 213 |Vehicle1|===> |Vehicle2|===> |Vehicle3|===>| | |Vehicle4|===>| 214 | (I-LV) |<....>| (I-LV) |<....>| (I-LV) | | | | (I-LV) | | 215 +--------+ V2V +--------+ V2V +--------+ | | +--------+ | 216 | | | | 217 +---------------------------------+ +------------------+ 218 Subnet-1 Subnet-2 220 <----> Wired Link <....> Wireless Link ===> Moving Direction 222 Figure 2: ILNP Use Case Scenario in IP-based Vehicular Network 223 Architecture 225 4. Gap Analysis 227 4.1. Neighbor Discovery 229 In both cases of LISP and ILNP, the usage of the existing neighbor 230 discovery message defined in [RFC4861] is possible without 231 modification. In LISP, Vehicles and RSUs in the same LISP site can 232 exchange ND/NA messages for routing by EID configured as IPv6 format. 233 Also, ILNP can operate the neighbor discovery for the configuration 234 of an I-LV value as the I-LV for ILNPv6 occupies the same bits as the 235 IPv6 address in the IPv6 header[RFC6740]. Thus, for vehicular 236 networking, it is expected that the same solutions already mentioned 237 in [ietf-ipwave-vehicular-networking] (e.g., new ND option 238 [ID-Vehicular-ND]) can also be applicable in the ID/Location 239 separation architecture. 241 4.2. Mobility Management 243 One of the advantages for using LISP is that mobility management can 244 be provided efficiently, when a device is roaming across different 245 LISP sites while maintaining its EID. The existing IP mobilty 246 management schemes such as MIP or PMIP require an anchor function 247 (e.g., Home Agent and Local Mobility Anchor) to maintain the IP 248 address of a mobile node when the mobile node moves. They can 249 construct a non-optimized forwarding path between the anchor and 250 current attachment point of the mobile node. In LISP, however, a 251 forwarding path can be optimized by updating EID-RLOC mapping 252 information and establishing an IP tunnel between the xTR of the 253 coresponding node and the xTR of the current mobile node's 254 attachement point. This provides advantages for easly optimizing a 255 forwarding path especially the vehicular networks where the 256 connection point of the mobile node can be move fast away from its 257 initial attachment point. In the vehicular networks, a vehicle with 258 an EID will roam much faster and it means that the mapped RLOC will 259 be changed more frequently. For faster RLOC assignment, a predictive 260 RLOC algorithm for roaming-EID is proposed in LISP WG 261 [draft-ietf-lisp-predictive-rlocs]. Using this algorithm, it 262 predicts the moving direction of a vehicle with a roaming-EID, 263 registers predictive RLOCs as a list to the mapping system, and 264 replicates packets to each RLOC in the list. It can minimize packet 265 loss while maintaining transport session continuity. 267 In ILNP, mobility management is classified into host mobility and 268 network (or site) mobility. For vehicular networks, host mobility 269 scenario is suitable [RFC6740]. When the vehicle moves to its 270 network attachment point and locator, it shortly becomes to belong to 271 a new site, it may send a Locator Update (LU) message to the 272 Corresponding Node (CN) and also send a request to the DNS server to 273 change its entry. Even though LU procedure is necessary, it causes 274 delay and packet loss during handover, and it may become a more 275 critical issue in the vehicular networks where the locator of a 276 vehicle is updated faster and more frequently. Therefore, ILNP needs 277 to minimize LU process including DNS updates for seamless mobility 278 management in vehicular networks. For example, 279 [ILNP-Sol-Wireless-Net] may be one possible solution that defines a 280 geological information server, which gives information of attachment 281 points nearby to devices to prepare handover, deliver its predictive 282 locator to the CN so that it can reduce packet loss and latency for 283 updating DNS. 285 4.3. Security and Privacy 287 For supporting applications such as autonomous driving, the vehicular 288 networks require not only low latency and high bandwidth but also a 289 high level of security and privacy. The IPWAVE working group is 290 facing a mobility management challenge due to latency and management 291 complexity due to the exchange of signaling messages with mobility 292 anchor to establish a tunnel. In the ID/Location separation 293 approach, all vehicles maintain their unique ID while they are 294 allocated a locator in the fastest way without binding update 295 procedure. Nevertheless, a privacy problem still exists due to the 296 eacy access to the mapping system. Even though it is difficult to 297 track a device using a single RLOC or locator value since its locator 298 changes while moving across sites, on the other hand, since an EID or 299 identifier is defined as permanent, additional methodologies need to 300 be considered to secure device identifier information. 302 Another consideration is various communication links. In the 303 vehicular networks, not only V2I communication but also V2X 304 communication are required. It means that vehicles can directly 305 communicate with each other only with an ID value without a locator 306 which is allocated from the infrastructure. In this scenario, the 307 exposure of vehicle IDs to others (including hackers) occurs 308 frequently even though they do not access mapping system. In 309 [draft-iannone-pidloc-privacy], they describe about privacy issues 310 and requirements in ID/Location separation architecture. 312 Several existing works can provide enhanced privacy mechanisms in ID/ 313 Location separation architectures. For example, 314 [draft-ietf-lisp-eid-anonymity] defines Ephemeral-EID which is 315 frequently changed by the device. For ILNP, identity privacy 316 supports using IPv6 privacy extensions for stateless address 317 autoconfiguration [RFC4941] and Locator Rewriting Relay (LRR) 318 component for locator privacy [RFC6748], can be solutions for 319 enhancing privacy in vehicular networks. 321 5. Acknkowledgement 323 We would like to thank Jahoon Paul Jeong as a contributor who 324 reviewed and gave comments for this version. 326 6. Informative References 328 [draft-iannone-pidloc-privacy] 329 Iannone, L., von Hugo, D., Sarikaya, B., and E. Nordmark, 330 "Privacy issues in Identifier/Locator Separation Systems", 331 draft-iannone-pidloc-privacy-00 (working on progress) 332 (work in progress), January 2020. 334 [draft-ietf-lisp-eid-anonymity] 335 Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP 336 EID Anonymity", draft-ietf-lisp-eid-anonymity-07(working 337 on progress) (work in progress), October 2019. 339 [draft-ietf-lisp-predictive-rlocs] 340 Farinacci, D. and P. Pillay-Esnault, "LISP Predictive 341 RLOCs", draft-ietf-lisp-predictive-rlocs-05(working on 342 progress) (work in progress), November 2019. 344 [ID-Vehicular-ND] 345 Jeong, J., Shen, Y., and Z. Xiang, "Vehicular Neighbor 346 Discovery for IP-Based Vehicular Network", draft-jeong- 347 ipwave-vehicular-neighbor-discovery-08(working on 348 progress) (work in progress), November 2019. 350 [IEEE-802.11-OCB] 351 "Part 11: Wireless LAN Medium Access Control (MAC) and 352 Physical Layer (PHY) Specifications", IEEE Std 353 802.11-2016, December 2016. 355 [ietf-ipwave-vehicular-networking] 356 Jeong, J., "IP Wireless Access in Vehicular Environments 357 (IPWAVE): Problem Statement and Use Cases", draft-ietf- 358 ipwave-vehicular-networking-13(working on progress) (work 359 in progress), January 2020. 361 [ILNP-Sol-Wireless-Net] 362 Isah, M. and CJ. Edwards, "An ILNP-based solution for 363 future heterogeneous wireless networks", PGNET 364 2013: Proceedings of the 14th Annual Postgraduate 365 Symposium on the Convergence of Telecommunications, 366 Networking and Broadcasting, June 2013. 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", RFC 2119, March 1997. 371 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 372 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 373 September 2007. 375 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 376 Extensions for Stateless Address Autoconfiguration in 377 IPv6", RFC 4941, September 2007. 379 [RFC6740] Atkinson, RJ., Bhatti, SN., and U. St Andrews, 380 "Identifier-Locator Network Protocol (ILNP) Architectural 381 Description", RFC 6740, November 2012. 383 [RFC6741] Atkinson, RJ., Bhatti, SN., and U. St Andrews, 384 "Identifier-Locator Network Protocol (ILNP) Engineering 385 Considerations", RFC 6741, November 2012. 387 [RFC6748] Atkinson, RJ., Bhatti, SN., and U. St Andrews, "Optional 388 Advanced Deployment Scenarios for the Identifier-Locator 389 Network Protocol (ILNP)", RFC 6748, November 2012. 391 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 392 Locator/ID Separation Protocol (LISP)", RFC 6830, January 393 2013. 395 Authors' Addresses 397 Kyoungjae Sun 398 School of Electronic Engineering 399 Soongsil University 400 369, Sangdo-ro, Dongjak-gu 401 Seoul, Seoul 06978 402 Republic of Korea 404 Phone: +82 10 3643 5627 405 EMail: gomjae@dcn.ssu.ac.kr 407 Younghan Kim 408 School of Electronic Engineering 409 Soongsil University 410 369, Sangdo-ro, Dongjak-gu 411 Seoul, Seoul 06978 412 Republic of Korea 414 Phone: +82 10 2691 0904 415 EMail: younghak@ssu.ac.kr