idnits 2.17.1 draft-kjsun-ipwave-id-loc-separation-00.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 11, 2019) is 1873 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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 (~~), 2 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 12, 2019 March 11, 2019 7 Considerations for ID/Location Separation Protocols in IP-based 8 Vehicular Networks 9 draft-kjsun-ipwave-id-loc-separation-00 11 Abstract 13 ID/Location separation protocols are proposed for scalable routing, 14 enhancing mobility and privacy in IP based internet infrastructure. 15 When we consider IP based vehicular networks, ID/Location separation 16 architecture is expected to offer benefits. In this draft, we 17 analyze whether ID/Location separation protocols can adjust into IP 18 based vehicular networks and solve requirements. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 12, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Use Cases for ID/Location Separation Protocols . . . . . . . 3 57 3.1. LISP . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. ILNP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 6 61 4.2. Mobility Management . . . . . . . . . . . . . . . . . . . 6 62 4.3. Security and Privacy . . . . . . . . . . . . . . . . . . 7 63 5. Informative References . . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 For vehicular networks, it is required to provide connection to the 69 Intelligent Transport System (ITS) for the driver's safety, efficient 70 driving and entertaining with fast mobility management. Other 71 scenarios besides V2I communication, like V2V and V2X communication 72 are also considered. Link layer protocols such as IEEE 802.11 OCB 73 are already defined for low-latency and alternative networks, and it 74 is designed for enabling IPv6 as a network layer protocol. 75 Nevertheless, for using IPv6 in the vehicular network, there are some 76 requirements for optimization as described in 77 [ietf-ipwave-vehicular-networking]. These issues are classified into 78 neighbor/service discovery, mobility management, security and 79 privacy. 81 In IETF, there are several 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 network, 87 ID/Location separation protocols can be expected to meet requirements 88 and solve problem statements discussed in IPWAVE WG. In this draft, 89 we describe use cases for applying ID/Location separation 90 architecture into IP-based vehicular network, and analyze whether 91 such 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. Use Cases for ID/Location Separation Protocols 103 3.1. LISP 105 Traffic Control Center in Vehicular Cloud 106 *-----------------------------------------* 107 * * 108 * +----------------+ * 109 * | Mapping System | * 110 * +----------------+ * 111 * ^ * 112 * MS/MR | * 113 *--------------------v--------------------* 114 ^ ^ ^ 115 | | | 116 | | | 117 RLOC1 v v RLOC2 v RLOC3 118 +--------+ Ethernet +--------+ Tunneling +--------+ 119 | RSU1 |<---------->| RSU2 |<---------->| RSU3 | 120 | (xTR) | | (xTR) | | (xTR) | 121 +--------+ +--------+ +--------+ 122 ^ ^ ^ 123 +----:------------------:---------+ +--------:---------+ 124 | : V2I V2I : | | V2I : | 125 | v v | | v | 126 +--------+ | +--------+ +--------+ | | +--------+ | 127 |Vehicle1|===> |Vehicle2|===> |Vehicle3|===>| | |Vehicle4|===>| 128 | (EID) |<....>| (EID) |<....>| (EID) | | | | (EID) | | 129 +--------+ V2V +--------+ V2V +--------+ | | +--------+ | 130 | | | | 131 +---------------------------------+ +------------------+ 132 LISP Site-1 LISP Site-2 134 <----> Wired Link <....> Wireless Link ===> Moving Direction 136 Figure 1: LISP Use Case Scenario in IP-based Vehicular Network 137 Architecture 139 Figure 1 describes a vehicular network architecture with the LISP 140 protocol. A single LISP site can have multiple RSUs with xTR 141 function to communicate with other LISP sites. In the figure, we 142 assume that Vehicle 1, 2 and 3 belong to LISP site 1 and Vehicle 4 to 143 LISP site 2. IPv6 addresses for wireless interfaces of each vehicle 144 are mapped to unique EIDs, which can communicate with other EIDs in 145 the same LISP site same as a legacy IPv6 operation. That is, 146 vehicles are able to communicate with RSU as V2I communication at the 147 same time with other vehicles in the same LISP site as V2V 148 communication. 150 Traffic control center in the vehicular cloud is appropriate to 151 deploy a mapping system, since it is a point accessible from all 152 RSUs. When vehicles enter each LISP site and attach to the RSU, RSU 153 sends Map-Register message to the mapping system including vehicle's 154 EID and RLOC of attached RSU. After registration, the vehicle can be 155 provided reachability from other LISP sites or non-LISP sites. In 156 the figure, for communication between vehicle 4 and vehicle 3, RSU 3 157 which is the attachment point of vehicle 4 should request for the 158 RLOC of vehicle 3 from the mapping system by sending Map-Requests 159 message. After receiving mapping information of vehicle 3's EID and 160 its RLOC in Map-Reply message, RLOC 3 can forward packets via the IP 161 tunnel between xTR (e.g. RSU 2 in this figure) assigned to vehicle 162 3. Note that several data plane protocols (e.g. SRv6, etc.) can be 163 used with LISP control plane functions. 165 3.2. ILNP 166 Traffic Control Center in Vehicular Cloud 167 *-----------------------------------------* 168 * * 169 * +-----------------+ * 170 * | DNS Server | * 171 * +-----------------+ * 172 * ^ * 173 * | * 174 *--------------------v--------------------* 175 ^ ^ ^ 176 | | | 177 +---------------------+ | 178 | SBR | | 179 +---------------------+ | 180 | | | 181 v v v 182 +--------+ Ethernet +--------+ +--------+ 183 | RSU1 |<----------->| RSU2 |<------->|RSU3/SBR| 184 +--------+ +--------+ +--------+ 185 ^ ^ ^ 186 +----:------------------:---------+ +--------:---------+ 187 | : V2I V2I : | | V2I : | 188 | v v | | v | 189 +--------+ | +--------+ +--------+ | | +--------+ | 190 |Vehicle1|===> |Vehicle2|===> |Vehicle3|===>| | |Vehicle4|===>| 191 | (I-LV) |<....>| (I-LV) |<....>| (I-LV) | | | | (I-LV) | | 192 +--------+ V2V +--------+ V2V +--------+ | | +--------+ | 193 | | | | 194 +---------------------------------+ +------------------+ 195 Subnet-1 Subnet-2 197 <----> Wired Link <....> Wireless Link ===> Moving Direction 199 Figure 2: ILNP Use Case Scenario in IP-based Vehicular Network 200 Architecture 202 In the ILNPv6, IPv6 address is replaced with an I-LV value. The I-LV 203 has a 128-bit length allowing it to be applied to the current IPv6 204 header without modification. [RFC6740] describes in detail how I-LV 205 value can replace an IPv6 address at the same time how can it works 206 in current IPv6 based infrastructure. In [RFC6741], the details of 207 the ILNPv6 packet header, locator subnetting and new DNS resource 208 record type for mapping I-LV values are defined. 210 Vehicular network architecture design for supporting ILNP is shown in 211 Figure 2. Most of the components are similar with architecture 212 described in [ietf-ipwave-vehicular-networking]. Every vehicle can 213 have more than one NID to connect to a network, and the IPv6 address 214 for communication is represented as a combination of NID and Locator. 215 Site Border Router (SBR) can be implemented in the RSU or border of 216 ILNP subnet site, which should have a routing table mapped with I-LV 217 values for forwarding packets. A DNS server can be deployed in the 218 vehicular cloud which is accessible from both in ILNP site and 219 external internet. 221 4. Gap Analysis 223 4.1. Neighbor Discovery 225 In both cases of LISP and ILNP, usage of existing neighbor discovery 226 message defined in [RFC4861] is possible without modification. In 227 LISP, vehicles and RSUs in the same LISP site can exchange ND/NA 228 messages for routing via EID configured as IPv6 format. Also, ILNP 229 can operate Neighbor Discovery for configuration of I-LV value as the 230 I-LV for ILNPv6 occupies the same bits as the IPv6 address in the 231 IPv6 header[RFC6740]. Thus, for vehicular networking, we expect that 232 the same solutions already mentioned in 233 [ietf-ipwave-vehicular-networking] (e.g. new ND option 234 [ID-Vehicular-ND]) also can be applicable in ID/Location separation 235 architecture. 237 4.2. Mobility Management 239 One of the advantages for using LISP is that mobility management can 240 be provided efficiently, when a device is roaming across different 241 LISP sites while maintaining its EID. Existing IP mobilty management 242 schemes such as MIP or PMIP required an anchor function(e.g. Home 243 Agent, Local Mobility Anchor) to maintain the IP address of mobile 244 node when the mobile node moves so that it occurs non-optimized 245 forwarding path between anchor and current attachment point of mobile 246 node. In LISP, however, forwarding path can be optimized by updating 247 EID-RLOC mapping information and establishing IP tunnel between xTR 248 of coresponding node and xTR of current mobile node's attachement 249 point. This provides advantages for easly optimizing forwarding path 250 especially in the vehicular network where connection point of the 251 mobile node can be fastly moved away from its initial attachment 252 point. In the vehicular network, EID will roam much faster and it 253 means that the mapped RLOC will be changed more frequently. For 254 faster RLOC assignment, a predictive RLOC algorithm for roaming-EID 255 is proposed in LISP WG [draft-ietf-lisp-predictive-rlocs]. Using 256 this algorithm, it predicts moving direction of roaming-EID, 257 registers predictive RLOCs as a list to the mapping system, and 258 replicates packets to each RLOC in the list. It can minimize packet 259 loss while maintaining transport session continuity. 261 In ILNP, mobility management is classified into host mobility and 262 network(site) mobility. For a vehicular network, host mobility 263 scenario is suitable[RFC6740]. When the vehicle moves to its network 264 attachment point and locator, it is changed to belong to new site, it 265 may send Locator Update (LU) message to the Corresponding Node (CN) 266 and also send a request to the DNS server to change its entry. Even 267 though LU procedure is necessary, it causes delay and packet loss 268 during handover, and it may become a more critical issue in the 269 vehicular network which changes locator of vehicle faster and more 270 frequently. Therefore, ILNP needs to minimize LU process including 271 DNS updates for seamless mobility management in vehicular networks. 272 For example, [ILNP-Sol-Wireless-Net] may be one possible solution 273 that defines a geological information server, which gives information 274 of attachment points nearby to devices to prepare handover, deliver 275 its predictive locator to the CN so that it reduces packet loss and 276 latency for updating DNS. 278 4.3. Security and Privacy 280 ID/Location separation architecture can enhance privacy. It is 281 difficult to track a device using single RLOC or locator value since 282 its locator changes with movement across sites. Nevertheless, since 283 EID or identifier is defined as permanent, additional methodologies 284 may be considered for enhancing access security of device identifier 285 information. For example, [draft-ietf-lisp-eid-anonymity] defines 286 Ephemeral-EID which is frequently changed by the device. For ILNP, 287 identity privacy supports using IPv6 privacy extensions for stateless 288 address autoconfiguration[RFC4941] and Locator Rewriting Relay (LRR) 289 component for locator privacy[RFC6748], can be solutions for 290 enhancing privacy in vehicular network. 292 5. Informative References 294 [draft-ietf-lisp-eid-anonymity] 295 Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP 296 EID Anonymity", draft-ietf-lisp-eid-anonymity-04(working 297 on progress) (work in progress), October 2018. 299 [draft-ietf-lisp-predictive-rlocs] 300 Farinacci, D. and P. Pillay-Esnault, "LISP Predictive 301 RLOCs", draft-ietf-lisp-predictive-rlocs-03(working on 302 progress) (work in progress), November 2018. 304 [ID-Vehicular-ND] 305 Xiang, Z., Jeong, J., and Y. Shen, "IPv6 Neighbor 306 Discovery for IP-Based Vehicular Networks", draft-xiang- 307 ipwave-vehicular-neighbor-discovery-00(working on 308 progress) (work in progress), November 2018. 310 [ietf-ipwave-vehicular-networking] 311 Jeong, J., "IP Wireless Access in Vehicular Environments 312 (IPWAVE): Problem Statement and Use Cases", draft-ietf- 313 ipwave-vehicular-networking-07(working on progress) (work 314 in progress), July 2017. 316 [ILNP-Sol-Wireless-Net] 317 Isah, M. and CJ. Edwards, "An ILNP-based solution for 318 future heterogeneous wireless networks", PGNET 319 2013: Proceedings of the 14th Annual Postgraduate 320 Symposium on the Convergence of Telecommunications, 321 Networking and Broadcasting, June 2013. 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", RFC 2119, March 1997. 326 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 327 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 328 September 2007. 330 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 331 Extensions for Stateless Address Autoconfiguration in 332 IPv6", RFC 4941, September 2007. 334 [RFC6740] Atkinson, RJ., Bhatti, SN., and U. St Andrews, 335 "Identifier-Locator Network Protocol (ILNP) Architectural 336 Description", RFC 6740, November 2012. 338 [RFC6741] Atkinson, RJ., Bhatti, SN., and U. St Andrews, 339 "Identifier-Locator Network Protocol (ILNP) Engineering 340 Considerations", RFC 6741, November 2012. 342 [RFC6748] Atkinson, RJ., Bhatti, SN., and U. St Andrews, "Optional 343 Advanced Deployment Scenarios for the Identifier-Locator 344 Network Protocol (ILNP)", RFC 6748, November 2012. 346 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 347 Locator/ID Separation Protocol (LISP)", RFC 6830, January 348 2013. 350 Authors' Addresses 351 Kyoungjae Sun 352 School of Electronic Engineering 353 Soongsil University 354 369, Sangdo-ro, Dongjak-gu 355 Seoul, Seoul 06978 356 Republic of Korea 358 Phone: +82 10 3643 5627 359 EMail: gomjae@dcn.ssu.ac.kr 361 Younghan Kim 362 School of Electronic Engineering 363 Soongsil University 364 369, Sangdo-ro, Dongjak-gu 365 Seoul, Seoul 06978 366 Republic of Korea 368 Phone: +82 10 2691 0904 369 EMail: younghak@ssu.ac.kr