idnits 2.17.00 (12 Aug 2021) /tmp/idnits48663/draft-ietf-lisp-introduction-15.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 abstract seems to contain references ([I-D.ietf-lisp-RFC6830bis], [I-D.ietf-lisp-RFC6833bis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (20 September 2021) is 236 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-ietf-lisp-6834bis - is the name correct? -- No information found for draft-ietf-lisp-rfc6830bis - is the name correct? -- No information found for draft-ietf-lisp-rfc6833bis - is the name correct? -- No information found for draft-ietf-lisp-sec - is the name correct? Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Cabellos 3 Internet-Draft UPC-BarcelonaTech 4 Intended status: Informational D. Saucez (Ed.) 5 Expires: 24 March 2022 Inria 6 20 September 2021 8 An Architectural Introduction to the Locator/ID Separation Protocol 9 (LISP) 10 draft-ietf-lisp-introduction-15 12 Abstract 14 This document describes the architecture of the Locator/ID Separation 15 Protocol (LISP), making it easier to read the rest of the LISP 16 specifications and providing a basis for discussion about the details 17 of the LISP protocols. This document is used for introductory 18 purposes, more details can be found in [I-D.ietf-lisp-rfc6830bis] and 19 [I-D.ietf-lisp-rfc6833bis], the protocol specifications. 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 24 March 2022. 38 Copyright Notice 40 Copyright (c) 2021 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 (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 56 3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 5 58 3.2. Overview of the Architecture . . . . . . . . . . . . . . 6 59 3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 9 61 3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 10 62 3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 10 63 3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 10 64 3.4.2. Mapping System Interface . . . . . . . . . . . . . . 11 65 3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 12 66 3.5. Internetworking Mechanisms . . . . . . . . . . . . . . . 14 67 4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 15 68 4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 15 69 4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 16 70 4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 17 71 4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 17 72 5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 20 75 7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 20 76 7.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 20 77 7.3. LISP for Virtual Private Networks . . . . . . . . . . . . 21 78 7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 21 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 84 11.2. Informative References . . . . . . . . . . . . . . . . . 26 85 Appendix A. A Brief History of Location/Identity Separation . . 27 86 A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 28 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 89 1. Introduction 91 This document introduces the Locator/ID Separation Protocol (LISP) 92 architecture ([I-D.ietf-lisp-rfc6830bis], 93 [I-D.ietf-lisp-rfc6833bis]), its main operational mechanisms and its 94 design rationale. Fundamentally, LISP is built following a well- 95 known architectural idea: decoupling the IP address overloaded 96 semantics. Indeed and as pointed out by Noel Chiappa [RFC4984], 97 currently IP addresses both identify the topological location of a 98 network attachment point as well as the node's identity. However, 99 nodes and routing have fundamentally different requirements. On the 100 one hand, routing systems require that addresses are aggregatable and 101 have topological meaning, on the other hand, nodes require to be 102 identified independently of their current location [RFC4984]. 104 LISP creates two separate namespaces, EIDs (End-host IDentifiers) and 105 RLOCs (Routing LOCators), both are syntactically identical to the 106 current IPv4 and IPv6 addresses. However, EIDs are used to uniquely 107 identify nodes irrespective of their topological location and are 108 typically routed intra-domain. RLOCs are assigned topologically to 109 network attachment points and are typically routed inter-domain. 110 With LISP, the edge of the Internet (where the nodes are connected) 111 and the core (where inter-domain routing occurs) can be logically 112 separated. LISP-capable routers interconnect the two logical spaces. 113 LISP also introduces a database, called the Mapping System, to store 114 and retrieve mappings between identity and location. LISP-capable 115 routers exchange packets over the Internet core by encapsulating them 116 to the appropriate location. 118 In summary: 120 * RLOCs have meaning only in the underlay network, that is the 121 underlying core routing system. 123 * EIDs have meaning only in the overlay network, which is the 124 encapsulation relationship between LISP-capable routers. 126 * The LISP edge maps EIDs to RLOCs 128 * Within the underlay network, RLOCs have both locator and 129 identifier semantics 131 * An EID within a LISP site carries both identifier and locator 132 semantics to other nodes within that site 134 * An EID within a LISP site carries identifier and limited locator 135 semantics to nodes at other LISP sites (i.e., enough locator 136 information to tell that the EID is external to the site) 138 The relationship described above is not unique to LISP and it is 139 common to other overlay technologies. 141 The initial motivation in the LISP effort is to be found in the 142 routing scalability problem [RFC4984], where, if LISP were to be 143 completely deployed, the Internet core would be populated with RLOCs 144 while Traffic Engineering mechanisms would be pushed to the Mapping 145 System. In such scenario RLOCs are quasi-static (i.e., low churn), 146 hence making the routing system scalable [Quoitin], while EIDs can 147 roam anywhere with no churn to the underlying global routing system. 148 [RFC7215] discusses the impact of LISP on the global routing system 149 during the transition period. However, the separation between 150 location and identity that LISP offers makes it suitable for use in 151 additional scenarios such as Traffic Engineering (TE), multihoming, 152 and mobility among others. 154 This document describes the LISP architecture and its main 155 operational mechanisms as well as its design rationale. It is 156 important to note that this document does not specify or complement 157 the LISP protocol. The interested reader should refer to the main 158 LISP specifications [I-D.ietf-lisp-rfc6830bis] and 159 [I-D.ietf-lisp-rfc6833bis], as well as the complementary documents 160 [RFC6831], [RFC6832], [I-D.ietf-lisp-6834bis], [RFC6835], [RFC6836], 161 [RFC7052] for the protocol specifications along with the LISP 162 deployment guidelines [RFC7215]. 164 2. Definition of Terms 166 Endpoint IDentifier (EID): EIDs are addresses used to uniquely 167 identify nodes irrespective of their topological location and are 168 typically routed intra-domain. 170 Routing LOcator (RLOC): RLOCs are addresses assigned topologically 171 to network attachment points and typically routed inter-domain. 173 Ingress Tunnel Router (ITR): A LISP-capable router that encapsulates 174 packets from a LISP site towards the core network. 176 Egress Tunnel Router (ETR): A LISP-capable router that decapsulates 177 packets from the core of the network towards a LISP site. 179 xTR: A router that implements both ITR and ETR functionalities. 181 Map-Request: A LISP signaling message used to request an EID-to-RLOC 182 mapping. 184 Map-Reply: A LISP signaling message sent in response to a Map- 185 Request that contains a resolved EID-to-RLOC mapping. 187 Map-Register: A LISP signaling message used to register an EID-to- 188 RLOC mapping. 190 Map-Notify: A LISP signaling message sent in response of a Map- 191 Register to acknowledge the correct reception of an EID-to-RLOC 192 mapping. 194 This document describes the LISP architecture and does not introduce 195 any new term. The reader is referred to [I-D.ietf-lisp-rfc6830bis] 196 and [I-D.ietf-lisp-rfc6833bis], [RFC6831], [RFC6832], 197 [I-D.ietf-lisp-6834bis], [RFC6835], [RFC6836], [RFC7052], [RFC7215] 198 for the complete definition of terms. 200 3. LISP Architecture 202 This section presents the LISP architecture, it first details the 203 design principles of LISP and then it proceeds to describe its main 204 aspects: data-plane, control-plane, and internetworking mechanisms. 206 3.1. Design Principles 208 The LISP architecture is built on top of four basic design 209 principles: 211 * Locator/Identifier split: By decoupling the overloaded semantics 212 of the current IP addresses the Internet core can be assigned 213 identity meaningful addresses and hence, can use aggregation to 214 scale. Devices are assigned with relatively opaque topologically 215 meaningful addresses that are independent of their topological 216 location. 218 * Overlay architecture: Overlays route packets over the current 219 Internet, allowing deployment of new protocols without changing 220 the current infrastructure hence, resulting into a low deployment 221 cost. 223 * Decoupled data-plane and control-plane: Separating the data-plane 224 from the control-plane allows them to scale independently and use 225 different architectural approaches. This is important given that 226 they typically have different requirements and allows for other 227 data-planes to be added. Even though the data-plane and the 228 control-plane are decoupled, they are not completely isolated 229 because the LISP data-plane may trigger control-plane activity. 231 * Incremental deployability: This principle ensures that the 232 protocol interoperates with the legacy Internet while providing 233 some of the targeted benefits to early adopters. 235 3.2. Overview of the Architecture 237 LISP splits architecturally the core from the edge of the Internet by 238 creating two separate namespaces: Endpoint Identifiers (EIDs) and 239 Routing LOCators (RLOCs). The edge consists of LISP sites (e.g., an 240 Autonomous System) that use EID addresses. EIDs are IPv4 or IPv6 241 addresses that uniquely identify communication end-hosts and are 242 assigned and configured by the same mechanisms that exist at the time 243 of this writing. EIDs do not contain inter-domain topological 244 information and because of this, EIDs are usually routable at the 245 edge (within LISP sites) but not in the core; see Section Section 3.5 246 for discussion of LISP site internetworking with non-LISP sites and 247 domains in the Internet. 249 LISP sites (at the edge) are connected to the interconnecting core by 250 means of LISP-capable routers (e.g., border routers). LISP sites are 251 connected across the interconnecting core using tunnels between the 252 LISP-capable routers. When packets originated from a LISP site are 253 flowing towards the core network, they ingress into an encapsulated 254 tunnel via an Ingress Tunnel Router (ITR). When packets flow from 255 the core network to a LISP site, they egress from an encapsulated 256 tunnel to an Egress Tunnel Router (ETR). An xTR is a router which 257 can perform both ITR and ETR operations. In this context ITRs 258 encapsulate packets while ETRs decapsulate them, hence LISP operates 259 as an overlay on top of the current Internet core. 261 /-----------------\ --- 262 | Mapping | | 263 . System | | Control 264 -| |`, | Plane 265 ,' \-----------------/ . | 266 / | --- 267 ,.., - _,....,, | ,.., | 268 / ` ,' ,-` `', | / ` | 269 / \ +-----+ ,' `, +-----+ / \ | 270 | EID |-| xTR |--/ RLOC ,--| xTR |-| EID | | Data 271 | Space |-| |--| Space |--| |-| Space | | Plane 272 \ / +-----+ . / +-----+ \ / | 273 `. .' `. ,' `. .' | 274 `'-` `., ,.' `'-` --- 275 ``'''`` 276 LISP Site (Edge) Core LISP Site (Edge) 278 Figure 1: A schema of the LISP Architecture. 280 With LISP, the core uses RLOCs, an RLOC is an IPv4 or IPv6 address 281 assigned to an core-facing network interface of an ITR or ETR. 283 A database which is typically distributed, called the Mapping System, 284 stores mappings between EIDs and RLOCs. Such mappings relate the 285 identity of the devices attached to LISP sites (EIDs) to the set of 286 RLOCs configured at the LISP-capable routers servicing the site. 287 Furthermore, the mappings also include traffic engineering policies 288 and can be configured to achieve multihoming and load balancing. The 289 LISP Mapping System is conceptually similar to the DNS where it is 290 organized as a distributed multi-organization network database. With 291 LISP, ETRs register mappings while ITRs retrieve them. 293 Finally, the LISP architecture emphasizes incremental deployment. 294 Given that LISP represents an overlay to the current Internet 295 architecture, end hosts as well as intra and inter-domain routers 296 remain unchanged, and the only required changes to the existing 297 infrastructure are to routers connecting the EID space with the RLOC 298 space. Additionally, LISP requires the deployment of an independent 299 Mapping System, such distributed database is a new network entity. 301 The following describes a simplified packet flow sequence between two 302 nodes that are attached to LISP sites. Please note that typical 303 LISP-capable routers are xTRs (both ITR and ETR). Client HostA wants 304 to send a packet to server HostB. 306 /----------------\ 307 | Mapping | 308 | System | 309 .| |- 310 ` \----------------/ `. 311 ,` \ 312 / `. 313 ,' _,..-..,, ', 314 / -` `-, \ 315 .' ,' \ `, 316 ` ' \ ' 317 +-----+ | | RLOC_B1+-----+ 318 HostA | | | RLOC |-------| | HostB 319 EID_A--|ITR_A|----| Space | |ETR_B|--EID_B 320 | | RLOC_A1 |-------| | 321 +-----+ | | RLOC_B2+-----+ 322 , / 323 \ / 324 `', ,-` 325 ``''-''`` 327 Figure 2: Packet flow sequence in LISP. 329 1. HostA retrieves the EID_B of HostB, typically querying the DNS 330 and obtaining an A or AAAA record. Then it generates an IP 331 packet as in the Internet, the packet has source address EID_A 332 and destination address EID_B. 334 2. The packet is forwarded towards ITR_A in the LISP site using 335 standard intra-domain mechanisms. 337 3. ITR_A upon receiving the packet queries the Mapping System to 338 retrieve the locator of ETR_B that is servicing HostB's EID_B. 339 In order to do so it uses a LISP control message called Map- 340 Request, the message contains EID_B as the lookup key. In turn 341 it receives another LISP control message called Map-Reply, the 342 message contains two locators: RLOC_B1 and RLOC_B2 along with 343 traffic engineering policies: priority and weight per locator. 344 Note that a Map-Reply can contain more locators if needed. ITR_A 345 can cache the mapping in a local storage to speed-up forwarding 346 of subsequent packets. 348 4. ITR_A encapsulates the packet towards RLOC_B1 (chosen according 349 to the priorities/weights specified in the mapping). The packet 350 contains two IP headers, the outer header has RLOC_A1 as source 351 and RLOC_B1 as destination, the inner original header has EID_A 352 as source and EID_B as destination. Furthermore ITR_A adds a 353 LISP header, more details about LISP encapsulation can be found 354 in Section 3.3.1. 356 5. The encapsulated packet is forwarded over the interconnecting 357 core as a normal IP packet, making the EID invisible from the 358 core. 360 6. Upon reception of the encapsulated packet by ETR_B, it 361 decapsulates the packet and forwards it to HostB. 363 3.3. Data-Plane 365 This section provides a high-level description of the LISP data- 366 plane, which is specified in detail in [I-D.ietf-lisp-rfc6830bis]. 367 The LISP data-plane is responsible for encapsulating and 368 decapsulating data packets and caching the appropriate forwarding 369 state. It includes two main entities, the ITR and the ETR, both are 370 LISP capable routers that connect the EID with the RLOC space (ITR) 371 and vice versa (ETR). 373 3.3.1. LISP Encapsulation 375 ITRs encapsulate data packets towards ETRs. LISP data packets are 376 encapsulated using UDP (port 4341), the source port is usually 377 selected by the ITR using a 5-tuple hash of the inner header (so to 378 be consistent in case of multi-path solutions such as ECMP [RFC2992]) 379 and ignored on reception. LISP data packets are often encapsulated 380 in UDP packets that include a zero checksum [RFC6935] [RFC6936] that 381 may not be verified when it is received, because LISP data packets 382 typically include an inner transport protocol header with a non-zero 383 checksum. The use of UDP zero checksums over IPv6 for all tunneling 384 protocols like LISP is subject to the applicability statement in 385 [RFC6936]. If LISP data packets are encapsulated in UDP packets with 386 non-zero checksums, the outer UDP checksums are verified when the UDP 387 packets are received, as part of normal UDP processing. 389 LISP-encapsulated packets also include a LISP header (after the UDP 390 header and before the original IP header). The LISP header is 391 prepended by ITRs and striped by ETRs. It carries reachability 392 information (see more details in Section 4.2) and the Instance ID 393 field. The Instance ID field is used to distinguish traffic to/from 394 different tenant address spaces at the LISP site and that may use 395 overlapped but logically separated EID addressing. 397 Overall, LISP works on 4 headers, the inner header the source 398 constructed, and the 3 headers a LISP encapsulator prepends ("outer" 399 to "inner"): 401 1. Outer IP header containing RLOCs as source and destination 402 addresses. This header is originated by ITRs and stripped by 403 ETRs. 405 2. UDP header (port 4341), usually with zero checksum. This header 406 is originated by ITRs and stripped by ETRs. 408 3. LISP header that contains various forwarding-plane features (such 409 as reachability) and an Instance ID field. This header is 410 originated by ITRs and stripped by ETRs. 412 4. Inner IP header containing EIDs as source and destination 413 addresses. This header is created by the source end-host and is 414 left unchanged by LISP data plane processing on the ITR and ETR. 416 Finally, in some scenarios Re-encapsulating and/or Recursive tunnels 417 are useful to choose a specified path in the underlay network, for 418 instance to avoid congestion or failure. Re-encapsulating tunnels 419 are consecutive LISP tunnels and occur when a decapsulator (an ETR 420 action) removes a LISP header and then acts as an encapsultor (an ITR 421 action) to prepend another one. On the other hand, Recursive tunnels 422 are nested tunnels and are implemented by using multiple LISP 423 encapsulations on a packet. Such functions are implemented by 424 Reencapsulating Tunnel Routers (RTRs). An RTR can be thought of as a 425 router that first acts as an ETR by decapsulating packets and then as 426 an ITR by encapsulating them towards another locator, more 427 information can be found at [I-D.ietf-lisp-rfc6830bis] and 428 [I-D.ietf-lisp-rfc6833bis]. 430 3.3.2. LISP Forwarding State 432 In the LISP architecture, ITRs keep just enough information to route 433 traffic flowing through them. Meaning that, ITRs retrieve from the 434 LISP Mapping System mappings between EID-prefixes (blocks of EIDs) 435 and RLOCs that are used to encapsulate packets. Such mappings are 436 stored in a local cache called the LISP Map-Cache for subsequent 437 packets addressed to the same EID prefix. Note that, in case of 438 overlapping EID-prefixes, following a single request, the ITR may 439 receive a set of mappings, covering the requested EID-prefix and all 440 more-specifics (cf., Section 5.5 [I-D.ietf-lisp-rfc6833bis]). 441 Mappings include a (Time-to-Live) TTL (set by the ETR). More details 442 about the Map-Cache management can be found in Section 4.1. 444 3.4. Control-Plane 446 The LISP control-plane, specified in [I-D.ietf-lisp-rfc6833bis], 447 provides a standard interface to register and request mappings. The 448 LISP Mapping System is a database that stores such mappings. The 449 following first describes the mappings, then the standard interface 450 to the Mapping System, and finally its architecture. 452 3.4.1. LISP Mappings 454 Each mapping includes the bindings between EID prefix(es) and set of 455 RLOCs as well as traffic engineering policies, in the form of 456 priorities and weights for the RLOCs. Priorities allow the ETR to 457 configure active/backup policies while weights are used to load- 458 balance traffic among the RLOCs (on a per-flow basis). 460 Typical mappings in LISP bind EIDs in the form of IP prefixes with a 461 set of RLOCs, also in the form of IP addresses. IPv4 and IPv6 462 addresses are encoded using the appropriate Address Family Identifier 463 (AFI) [RFC3232]. However LISP can also support more general address 464 encoding by means of the ongoing effort around the LISP Canonical 465 Address Format (LCAF) [RFC8060]. 467 With such a general syntax for address encoding in place, LISP aims 468 to provide flexibility to current and future applications. For 469 instance LCAFs could support MAC addresses, geo-coordinates, ASCII 470 names and application specific data. 472 3.4.2. Mapping System Interface 474 LISP defines a standard interface between data and control planes. 475 The interface is specified in [I-D.ietf-lisp-rfc6833bis] and defines 476 two entities: 478 Map-Server: A network infrastructure component that learns mappings 479 from ETRs and publishes them into the LISP Mapping System. 480 Typically Map-Servers are not authoritative to reply to queries 481 and hence, they forward them to the ETR. However, they can also 482 operate in proxy-mode, where the ETRs delegate replying to queries 483 to Map-Servers. This setup is useful when the ETR has limited 484 resources (e.g., CPU or power). 486 Map-Resolver: A network infrastructure component that interfaces 487 ITRs with the Mapping System by proxying queries and in some cases 488 responses. 490 The interface defines four LISP control messages which are sent as 491 UDP datagrams (port 4342): 493 Map-Register: This message is used by ETRs to register mappings in 494 the Mapping System and it is authenticated using a shared key 495 between the ETR and the Map-Server. 497 Map-Notify: When requested by the ETR, this message is sent by the 498 Map-Server in response to a Map-Register to acknowledge the 499 correct reception of the mapping and convey the latest Map-Server 500 state on the EID to RLOC mapping. In some cases a Map-Notify can 501 be sent to the previous RLOCs when an EID is registered by a new 502 set of RLOCs. 504 Map-Request: This message is used by ITRs or Map-Resolvers to 505 resolve the mapping of a given EID. 507 Map-Reply: This message is sent by Map-Servers or ETRs in response 508 to a Map-Request and contains the resolved mapping. Please note 509 that a Map-Reply may contain a negative reply if, for example, the 510 queried EID is not part of the LISP EID space. In such cases the 511 ITR typically forwards the traffic natively (non encapsulated) to 512 the public Internet, this behavior is defined to support 513 incremental deployment of LISP. 515 3.4.3. Mapping System 517 LISP architecturally decouples control and data-plane by means of a 518 standard interface. This interface glues the data-plane - routers 519 responsible for forwarding data-packets - with the LISP Mapping 520 System - a database responsible for storing mappings. 522 With this separation in place, the data and control-plane can use 523 different architectures if needed and scale independently. Typically 524 the data-plane is optimized to route packets according to 525 hierarchical IP addresses. However the control-plane may have 526 different requirements, for instance and by taking advantage of the 527 LCAF, the Mapping System may be used to store non-hierarchical keys 528 (such as MAC addresses), requiring different architectural approaches 529 for scalability. Another important difference between the LISP 530 control- and data- planes is that, as a result of the local mapping 531 cache available at ITR, the Mapping System does not need to operate 532 at line-rate. 534 Many of the existing mechanisms to create distributed systems have 535 been explored and considered for the Mapping System architecture: 536 graph-based databases in the form of LISP+ALT [RFC6836], hierarchical 537 databases in the form of LISP-DDT [RFC8111], monolithic databases in 538 the form of LISP-NERD [RFC6837], flat databases in the form of LISP- 539 DHT [I-D.cheng-lisp-shdht], [Mathy], and a multicast-based database 540 [I-D.curran-lisp-emacs]. Furthermore it is worth noting that, in 541 some scenarios such as private deployments, the Mapping System can 542 operate as logically centralized. In such cases it is typically 543 composed of a single Map-Server/Map-Resolver. 545 The following focuses on the two mapping systems that have been 546 implemented and deployed (LISP+ALT and LISP-DDT). 548 3.4.3.1. LISP+ALT 550 The LISP Alternative Topology (LISP+ALT) [RFC6836] was the first 551 Mapping System proposed, developed and deployed on the LISP pilot 552 network. It is based on a distributed BGP overlay participated by 553 Map-Servers and Map-Resolvers. The nodes connect to their peers 554 through static tunnels. Each Map-Server involved in the ALT topology 555 advertises the EID-prefixes registered by the serviced ETRs, making 556 the EID routable on the ALT topology. 558 When an ITR needs a mapping it sends a Map-Request to a Map-Resolver 559 that, using the ALT topology, forwards the Map-Request towards the 560 Map-Server responsible for the mapping. Upon reception the Map- 561 Server forwards the request to the ETR that in turn, replies directly 562 to the ITR. 564 3.4.3.2. LISP-DDT 566 LISP-DDT [RFC8111] is conceptually similar to the DNS, a hierarchical 567 directory whose internal structure mirrors the hierarchical nature of 568 the EID address space. The DDT hierarchy is composed of DDT nodes 569 forming a tree structure, the leafs of the tree are Map-Servers. On 570 top of the structure there is the DDT root node, which is a 571 particular instance of a DDT node and that matches the entire address 572 space. As in the case of DNS, DDT supports multiple redundant DDT 573 nodes and/or DDT roots. Finally, Map-Resolvers are the clients of 574 the DDT hierarchy and can query either the DDT root and/or other DDT 575 nodes. 577 /---------\ 578 | | 579 | DDT Root| 580 | /0 | 581 ,.\---------/-, 582 ,-'` | `'., 583 -'` | `- 584 /-------\ /-------\ /-------\ 585 | DDT | | DDT | | DDT | 586 | Node | | Node | | Note | ... 587 | 0/8 | | 1/8 | | 2/8 | 588 \-------/ \-------/ \-------/ 589 _. _. . -..,,,_ 590 -` -` \ ````''-- 591 +------------+ +------------+ +------------+ +------------+ 592 | Map-Server | | Map-Server | | Map-Server | | Map-Server | 593 | EID-prefix1| | EID-prefix2| | EID-prefix3| | EID-prefix4| 594 +------------+ +------------+ +------------+ +------------+ 596 Figure 3: A schematic representation of the DDT tree structure, 597 please note that the prefixes and the structure depicted should 598 be only considered as an example. 600 The DDT structure does not actually index EID-prefixes but eXtended 601 EID-prefixes (XEID). An XEID-prefix is just the concatenation of the 602 following fields (from most significant bit to less significant bit): 603 Database-ID, Instance ID, Address Family Identifier and the actual 604 EID-prefix. The Database-ID is provided for possible future 605 requirements of higher levels in the hierarchy and to enable the 606 creation of multiple and separate database trees. 608 In order to resolve a query LISP-DDT operates in a similar way to the 609 DNS but only supports iterative lookups. DDT clients (usually Map- 610 Resolvers) generate Map-Requests to the DDT root node. In response 611 they receive a newly introduced LISP-control message: a Map-Referral. 612 A Map-Referral provides the list of RLOCs of the set of DDT nodes 613 matching a configured XEID delegation. That is, the information 614 contained in the Map-Referral points to the child of the queried DDT 615 node that has more specific information about the queried XEID- 616 prefix. This process is repeated until the DDT client walks the tree 617 structure (downwards) and discovers the Map-Server servicing the 618 queried XEID. At this point the client sends a Map-Request and 619 receives a Map-Reply containing the mappings. It is important to 620 note that DDT clients can also cache the information contained in 621 Map-Referrals, that is, they cache the DDT structure. This is used 622 to reduce the mapping retrieving latency [Jakab]. 624 The DDT Mapping System relies on manual configuration. That is Map- 625 Resolvers are configured with the set of available DDT root nodes 626 while DDT nodes are configured with the appropriate XEID delegations. 627 Configuration changes in the DDT nodes are only required when the 628 tree structure changes itself, but it doesn't depend on EID dynamics 629 (RLOC allocation or traffic engineering policy changes). 631 3.5. Internetworking Mechanisms 633 EIDs are typically identical to either IPv4 or IPv6 addresses and 634 they are stored in the LISP Mapping System, however they are usually 635 not announced in the routing system beyond the local LISP domain. As 636 a result LISP requires an internetworking mechanism to allow LISP 637 sites to speak with non-LISP sites and vice versa. LISP 638 internetworking mechanisms are specified in [RFC6832]. 640 LISP defines two entities to provide internetworking: 642 Proxy Ingress Tunnel Router (PITR): PITRs provide connectivity from 643 the legacy Internet to LISP sites. PITRs announce in the global 644 routing system blocks of EID prefixes (aggregating when possible) 645 to attract traffic. For each incoming packet from a source not in 646 a LISP site (a non-EID), the PITR LISP-encapsulates it towards the 647 RLOC(s) of the appropriate LISP site. The impact of PITRs in the 648 routing table size of the Default-Free Zone (DFZ) is, in the 649 worst-case, similar to the case in which LISP is not deployed. 650 EID-prefixes will be aggregated as much as possible both by the 651 PITR and by the global routing system. 653 Proxy Egress Tunnel Router (PETR): PETRs provide connectivity from 654 LISP sites to the legacy Internet. In some scenarios, LISP sites 655 may be unable to send encapsulated packets with a local EID 656 address as a source to the legacy Internet. For instance when 657 Unicast Reverse Path Forwarding (uRPF) is used by Provider Edge 658 routers, or when an intermediate network between a LISP site and a 659 non-LISP site does not support the desired version of IP (IPv4 or 660 IPv6). In both cases the PETR overcomes such limitations by 661 encapsulating packets over the network. There is no specified 662 provision for the distribution of PETR RLOC addresses to the ITRs. 664 Additionally, LISP also defines mechanisms to operate with private 665 EIDs [RFC1918] by means of LISP-NAT [RFC6832]. In this case the xTR 666 replaces a private EID source address with a routable one. At the 667 time of this writing, work is ongoing to define NAT-traversal 668 capabilities, that is xTRs behind a NAT using non-routable RLOCs. 670 PITRs, PETRs and, LISP-NAT enable incremental deployment of LISP, by 671 providing significant flexibility in the placement of the boundaries 672 between the LISP and non-LISP portions of the network, and making it 673 easy to change those boundaries over time. 675 4. LISP Operational Mechanisms 677 This section details the main operational mechanisms defined in LISP. 679 4.1. Cache Management 681 LISP's decoupled control and data-plane, where mappings are stored in 682 the control-plane and used for forwarding in the data-plane, requires 683 a local cache in ITRs to reduce signaling overhead (Map-Request/Map- 684 Reply) and increase forwarding speed. The local cache available at 685 the ITRs, called Map-Cache, is used by the router to LISP-encapsulate 686 packets. The Map-Cache is indexed by (Instance ID, EID-prefix) and 687 contains basically the set of RLOCs with the associated traffic 688 engineering policies (priorities and weights). 690 The Map-Cache, as any other cache, requires cache coherence 691 mechanisms to maintain up-to-date information. LISP defines three 692 main mechanisms for cache coherence: 694 Record Time-To-Live (TTL): Each mapping record contains a TTL set by 695 the ETR, upon expiration of the TTL the ITR can't use the mapping 696 until it is refreshed by sending a new Map-Request. 698 Solicit-Map-Request (SMR): SMR is an explicit mechanism to update 699 mapping information. In particular a special type of Map-Request 700 can be sent on demand by ETRs to request refreshing a mapping. 701 Upon reception of a SMR message, the ITR must refresh the bindings 702 by sending a Map-Request to the Mapping System. Further uses of 703 SMRs are documented in [I-D.ietf-lisp-rfc6833bis]. 705 Map-Versioning: This optional mechanism piggybacks in the LISP 706 header of data-packets the version number of the mappings used by 707 an xTR. This way, when an xTR receives a LISP-encapsulated packet 708 from a remote xTR, it can check whether its own Map-Cache or the 709 one of the remote xTR is outdated. If its Map-Cache is outdated, 710 it sends a Map-Request for the remote EID so to obtain the newest 711 mappings. On the contrary, if it detects that the remote xTR Map- 712 Cache is outdated, it sends a SMR to notify it that a new mapping 713 is available. Further details are available in 714 [I-D.ietf-lisp-6834bis]. 716 Finally it is worth noting that in some cases an entry in the map- 717 cache can be proactively refreshed using the mechanisms described in 718 the section below. 720 4.2. RLOC Reachability 722 In most cases LISP operates with a pull-based Mapping System (e.g., 723 DDT), this results in an edge to edge pull architecture. In such 724 scenario the network state is stored in the control-plane while the 725 data-plane pulls it on demand. This has consequences concerning the 726 propagation of xTRs reachability/liveness information since pull 727 architectures require explicit mechanisms to propagate this 728 information. As a result LISP defines a set of mechanisms to inform 729 ITRs and PITRS about the reachability of the cached RLOCs: 731 Locator Status Bits (LSB): LSB is a passive technique, the LSB field 732 is carried by data-packets in the LISP header and can be set by a 733 ETRs to specify which RLOCs of the ETR site are up/down. This 734 information can be used by the ITRs as a hint about the reachability 735 to perform additional checks. Also note that LSB does not provide 736 path reachability status, only hints on the status of RLOCs as such 737 they must not be used over the public Internet and should be coupled 738 with Map-Versioning to prevent race conditions where LSB are 739 interpreted as referring to different RLOCs than intended. 741 Echo-nonce: This is also a passive technique, that can only operate 742 effectively when data flows bi-directionally between two 743 communicating xTRs. Basically, an ITR piggybacks a random number 744 (called nonce) in LISP data packets, if the path and the probed 745 locator are up, the ETR will piggyback the same random number on the 746 next data-packet, if this is not the case the ITR can set the locator 747 as unreachable. When traffic flow is unidirectional or when the ETR 748 receiving the traffic is not the same as the ITR that transmits it 749 back, additional mechanisms are required. The echo-nonce mechanism 750 must be used in trusted environments only, not over the public 751 Internet. 753 RLOC-probing: This is an active probing algorithm where ITRs send 754 probes to specific locators, this effectively probes both the locator 755 and the path. In particular this is done by sending a Map-Request 756 (with certain flags activated) on the data-plane (RLOC space) and 757 waiting in return a Map-Reply, also sent on the data-plane. The 758 active nature of RLOC-probing provides an effective mechanism to 759 determine reachability and, in case of failure, switching to a 760 different locator. Furthermore the mechanism also provides useful 761 RTT estimates of the delay of the path that can be used by other 762 network algorithms. 764 It is worth noting that RLOC probing and Echo-nonce can work 765 together. Specifically if a nonce is not echoed, an ITR could RLOC- 766 probe to determine if the path is up when it cannot tell the 767 difference between a failed bidirectional path or the return path is 768 not used (a unidirectional path). 770 Additionally, LISP also recommends inferring reachability of locators 771 by using information provided by the underlay, in particular: 773 ICMP signaling: The LISP underlay -the current Internet- uses the 774 ICMP protocol to signal unreachability (among other things). LISP 775 can take advantage of this and the reception of a ICMP Network 776 Unreachable or ICMP Host Unreachable message can be seen as a hint 777 that a locator might be unreachable, this should lead to perform 778 additional checks. 780 Underlay routing: Both BGP and IGP carry reachability information, 781 LISP-capable routers that have access to underlay routing information 782 can use it to determine if a given locator or path are reachable. 784 4.3. ETR Synchronization 786 All the ETRs that are authoritative to a particular EID-prefix must 787 announce the same mapping to the requesters, this means that ETRs 788 must be aware of the status of the RLOCs of the remaining ETRs. This 789 is known as ETR synchronization. 791 At the time of this writing LISP does not specify a mechanism to 792 achieve ETR synchronization. Although many well-known techniques 793 could be applied to solve this issue it is still under research, as a 794 result operators must rely on coherent manual configuration 796 4.4. MTU Handling 798 Since LISP encapsulates packets it requires dealing with packets that 799 exceed the MTU of the path between the ITR and the ETR. Specifically 800 LISP defines two mechanisms: 802 Stateless: With this mechanism the effective MTU is assumed from the 803 ITR's perspective. If a payload packet is too big for the 804 effective MTU, and can be fragmented, the payload packet is 805 fragmented on the ITR, such that reassembly is performed at the 806 destination host. 808 Stateful: With this mechanism ITRs keep track of the MTU of the 809 paths towards the destination locators by parsing the ICMP Too Big 810 packets sent by intermediate routers. ITRs will send ICMP Too Big 811 messages to inform the sources about the effective MTU. 812 Additionally ITRs can use mechanisms such as PMTUD [RFC1191] or 813 PLPMTUD [RFC4821] to keep track of the MTU towards the locators. 815 In both cases if the packet cannot be fragmented (IPv4 with DF=1 or 816 IPv6) then the ITR drops it and replies with a ICMP Too Big message 817 to the source. 819 5. Mobility 821 The separation between locators and identifiers in LISP is suitable 822 for traffic engineering purpose where LISP sites can change their 823 attachment points to the Internet (i.e., RLOCs) without impacting 824 endpoints or the Internet core. In this context, the border routers 825 operate the xTR functionality and endpoints are not aware of the 826 existence of LISP. This functionality is similar to Network Mobility 827 [RFC3963]. However, this mode of operation does not allow seamless 828 mobility of endpoints between different LISP sites as the EID address 829 might not be routable in a visited site. Nevertheless, LISP can be 830 used to enable seamless IP mobility when LISP is directly implemented 831 in the endpoint or when the endpoint roams to an attached xTR. Each 832 endpoint is then an xTR and the EID address is the one presented to 833 the network stack used by applications while the RLOC is the address 834 gathered from the network when it is visited. This functionality is 835 similar to Mobile IP ([RFC5944] and [RFC6275]). 837 Whenever the device changes of RLOC, the xTR updates the RLOC of its 838 local mapping and registers it to its Map-Server, typically with a 839 low TTL value (1min). To avoid the need of a home gateway, the ITR 840 also indicates the RLOC change to all remote devices that have 841 ongoing communications with the device that moved. The combination 842 of both methods ensures the scalability of the system as signaling is 843 strictly limited the Map-Server and to hosts with which 844 communications are ongoing. In the mobility case the EID-prefix can 845 be as small as a full /32 or /128 (IPv4 or IPv6 respectively) 846 depending on the specific use-case (e.g., subnet mobility vs single 847 VM/Mobile node mobility). 849 The decoupled identity and location provided by LISP allows it to 850 operate with other layer 2 and layer 3 mobility solutions. 852 6. Multicast 854 LISP also supports transporting IP multicast packets sent from the 855 EID space, the operational changes required to the multicast 856 protocols are documented in [RFC6831]. 858 In such scenarios, LISP may create multicast state both at the core 859 and at the sites (both source and receiver). When signaling is used 860 to create multicast state at the sites, LISP routers unicast 861 encapsulate PIM Join/Prune messages from receiver to source sites. 862 At the core, ETRs build a new PIM Join/Prune message addressed to the 863 RLOC of the ITR servicing the source. An simplified sequence is 864 shown below 866 1. An end-host willing to join a multicast channel sends an IGMP 867 report. Multicast PIM routers at the LISP site propagate PIM 868 Join/Prune messages (S-EID, G) towards the ETR. 870 2. The join message flows to the ETR, upon reception the ETR builds 871 two join messages, the first one unicast LISP-encapsulates the 872 original join message towards the RLOC of the ITR servicing the 873 source. This message creates (S-EID, G) multicast state at the 874 source site. The second join message contains as destination 875 address the RLOC of the ITR servicing the source (S-RLOC, G) and 876 creates multicast state at the core. 878 3. Multicast data packets originated by the source (S-EID, G) flow 879 from the source to the ITR. The ITR LISP-encapsulates the 880 multicast packets, the outter header includes its own RLOC as the 881 source (S-RLOC) and the original multicast group address (G) as 882 the destination. Please note that multicast group address are 883 logical and are not resolved by the mapping system. Then the 884 multicast packet is transmitted through the core towards the 885 receiving ETRs that decapsulates the packets and sends them using 886 the receiver's site multicast state. 888 Please note that the inner and outer multicast addresses are in 889 general different, unless in specific cases where the underlay 890 provider implements a tight control on the overlay. LISP 891 specifications already support all PIM modes [RFC6831]. 892 Additionally, LISP can support as well non-PIM mechanisms in order to 893 maintain multicast state. 895 When multicast sources and receivers are active at LISP sites, and 896 the core network between the sites does not provide multicast 897 support, a signal-free mechanism can be used to create an overlay 898 that will allow multicast traffic to flow between sites and connect 899 the multicast trees at the different sites [RFC8378]. Registrations 900 from the different receiver sites will be merged at the mapping 901 system to assemble a multicast-replication-list inclusive of all 902 Routing Locators (RLOCs) that lead to receivers for a particular 903 multicast group or multicast channel. The replication list for each 904 specific multicast entry is maintained as a database mapping entry in 905 the LISP mapping system. 907 7. Use Cases 909 7.1. Traffic Engineering 911 A LISP site can strictly impose via which ETRs the traffic must 912 enters the LISP site network even though the path followed to reach 913 the ETR is not under the control of the LISP site. This fine control 914 is implemented with the mappings. When a remote site is willing to 915 send traffic to a LISP site, it retrieves the mapping associated to 916 the destination EID via the mapping system. The mapping is sent 917 directly by an authoritative ETR of the EID and is not altered by any 918 intermediate network. 920 A mapping associates a list of RLOCs to an EID prefix. Each RLOC 921 corresponds to an interface of an ETR (or set of ETRs) that is able 922 to correctly forward packets to EIDs in the prefix. Each RLOC is 923 tagged with a priority and a weight in the mapping. The priority is 924 used to indicates which RLOCs should be preferred to send packets 925 (the least preferred ones being provided for backup purpose). The 926 weight permits to balance the load between the RLOCs with the same 927 priority, proportionally to the weight value. 929 As mappings are directly issued by the authoritative ETR of the EID 930 and are not altered while transmitted to the remote site, it offers 931 highly flexible incoming inter-domain traffic engineering with even 932 the possibility for a site to support a different mapping policy for 933 each remote site. 935 7.2. LISP for IPv6 Co-existence 937 LISP encapsulations allows to transport packets using EIDs from a 938 given address family (e.g., IPv6) with packets from other address 939 families (e.g., IPv4). The absence of correlation between the 940 address family of RLOCs and EIDs makes LISP a candidate to allow, 941 e.g., IPv6 to be deployed when all of the core network may not have 942 IPv6 enabled. 944 For example, two IPv6-only data centers could be interconnected via 945 the legacy IPv4 Internet. If their border routers are LISP capable, 946 sending packets between the data center is done without any form of 947 translation as the native IPv6 packets (in the EID space) will be 948 LISP encapsulated and transmitted over the IPv4 legacy Internet by 949 the mean of IPv4 RLOCs. 951 7.3. LISP for Virtual Private Networks 953 It is common to operate several virtual networks over the same 954 physical infrastructure. In such virtual private networks, it is 955 essential to distinguish which virtual network a packet belongs and 956 tags or labels are used for that purpose. When using LISP, the 957 distinction can be made with the Instance ID field. When an ITR 958 encapsulates a packet from a particular virtual network (e.g., known 959 via the VRF or VLAN), it tags the encapsulated packet with the 960 Instance ID corresponding to the virtual network of the packet. When 961 an ETR receives a packet tagged with an Instance ID it uses the 962 Instance ID to determine how to treat the packet. 964 The main usage of LISP for virtual private networks does not 965 introduce additional requirements on the underlying network, as long 966 as it runs IP. 968 7.4. LISP for Virtual Machine Mobility in Data Centers 970 A way to enable seamless virtual machine mobility in data center is 971 to conceive the datacenter backbone as the RLOC space and the subnet 972 where servers are hosted as forming the EID space. A LISP router is 973 placed at the border between the backbone and each subnet. When a 974 virtual machine is moved to another subnet, it can keep (temporarily) 975 the address it had before the move so to continue without a transport 976 layer connection reset. When an xTR detects a source address 977 received on a subnet to be an address not assigned to the subnet, it 978 registers the address to the Mapping System. 980 To inform the other LISP routers that the machine moved and where, 981 and then to avoid detours via the initial subnetwork, mechanisms such 982 as the Solicit-Map-Request messages are used. 984 8. Security Considerations 986 This section describes the security considerations associated to the 987 LISP protocol. 989 While in a push mapping system, the state necessary to forward 990 packets is learned independently of the traffic itself, with a pull 991 architecture, the system becomes reactive and data-plane events 992 (e.g., the arrival of a packet for an unknown destination) may 993 trigger control-plane events. This on-demand learning of mappings 994 provides many advantages as discussed above but may also affect the 995 way security is enforced. 997 Usually, the data-plane is implemented in the fast path of routers to 998 provide high performance forwarding capabilities while the control- 999 plane features are implemented in the slow path to offer high 1000 flexibility and a performance gap of several order of magnitude can 1001 be observed between the slow and the fast paths. As a consequence, 1002 the way data-plane events are notified to the control-plane must be 1003 thought carefully so to not overload the slow path and rate limiting 1004 should be used as specified in [I-D.ietf-lisp-rfc6830bis] and 1005 [I-D.ietf-lisp-rfc6833bis]. 1007 Care must also be taken so to not overload the mapping system (i.e., 1008 the control plane infrastructure) as the operations to be performed 1009 by the mapping system may be more complex than those on the data- 1010 plane, for that reason [I-D.ietf-lisp-rfc6830bis] and 1011 [I-D.ietf-lisp-rfc6833bis] recommends to rate limit the sending of 1012 messages to the mapping system. 1014 To improve resiliency and reduce the overall number of messages 1015 exchanged, LISP offers the possibility to leak information, such as 1016 reachabilty of locators, directly into data plane packets. In 1017 environments that are not fully trusted, like the open Internet, 1018 control information gleaned from data-plane packets must not be used 1019 or must be verified before using it. 1021 Mappings are the centrepiece of LISP and all precautions must be 1022 taken to avoid them to be manipulated or misused by malicious 1023 entities. Using trustable Map-Servers that strictly respect 1024 [I-D.ietf-lisp-rfc6833bis] and the authentication mechanism proposed 1025 by LISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks to the 1026 mapping integrity. In more critical environments, secure measures 1027 may be needed. The way security is implemented for a given mapping 1028 system strongly depends on the architecture of the mapping system 1029 itself and the threat model assumed for the deployment. Thus, the 1030 mapping system security has to be discussed in the relevant documents 1031 proposing the mapping system architecture. 1033 As with any other tunneling mechanism, middleboxes on the path 1034 between an ITR (or PITR) and an ETR (or PETR) must implement 1035 mechanisms to strip the LISP encapsulation to correctly inspect the 1036 content of LISP encapsulated packets. 1038 Like other map-and-encap mechanisms, LISP enables triangular routing 1039 (i.e., packets of a flow cross different border routers depending on 1040 their direction). This means that intermediate boxes may have 1041 incomplete view on the traffic they inspect or manipulate. Moreover, 1042 LISP-encapsulated packets are routed based on the outer IP address 1043 (i.e., the RLOC), and can be delivered to an ETR that is not 1044 responsible of the destination EID of the packet or even to a network 1045 element that is not an ETR. The mitigation consists in applying 1046 appropriate filtering techniques on the network elements that can 1047 potentially receive un-expected LISP-encapsulated packets 1049 More details about security implications of LISP are discussed in 1050 [RFC7835]. 1052 9. IANA Considerations 1054 This memo includes no requests to IANA. 1056 10. Acknowledgements 1058 This document was initiated by Noel Chiappa and much of the core 1059 philosophy came from him. The authors acknowledge the important 1060 contributions he has made to this work and thank him for his past 1061 efforts. 1063 The authors would also like to thank Dino Farinacci, Fabio Maino, 1064 Luigi Iannone, Sharon Barkai, Isidoros Kouvelas, Christian Cassar, 1065 Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald 1066 Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, 1067 David Black. 1069 11. References 1071 11.1. Normative References 1073 [I-D.ietf-lisp-6834bis] 1074 Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 1075 Separation Protocol (LISP) Map-Versioning", Work in 1076 Progress, Internet-Draft, draft-ietf-lisp-6834bis-09, 31 1077 August 2021, . 1080 [I-D.ietf-lisp-rfc6830bis] 1081 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 1082 Cabellos-Aparicio, "The Locator/ID Separation Protocol 1083 (LISP)", Work in Progress, Internet-Draft, draft-ietf- 1084 lisp-rfc6830bis-36, 18 November 2020, 1085 . 1088 [I-D.ietf-lisp-rfc6833bis] 1089 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 1090 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 1091 Plane", Work in Progress, Internet-Draft, draft-ietf-lisp- 1092 rfc6833bis-30, 18 November 2020, . 1095 [I-D.ietf-lisp-sec] 1096 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 1097 Saucez, "LISP-Security (LISP-SEC)", Work in Progress, 1098 Internet-Draft, draft-ietf-lisp-sec-22, 12 January 2021, 1099 . 1102 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1103 DOI 10.17487/RFC1191, November 1990, 1104 . 1106 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 1107 J., and E. Lear, "Address Allocation for Private 1108 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 1109 February 1996, . 1111 [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path 1112 Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, 1113 . 1115 [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced 1116 by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, 1117 January 2002, . 1119 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1120 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1121 RFC 3963, DOI 10.17487/RFC3963, January 2005, 1122 . 1124 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1125 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1126 . 1128 [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report 1129 from the IAB Workshop on Routing and Addressing", 1130 RFC 4984, DOI 10.17487/RFC4984, September 2007, 1131 . 1133 [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", 1134 RFC 5944, DOI 10.17487/RFC5944, November 2010, 1135 . 1137 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1138 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1139 2011, . 1141 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 1142 Locator/ID Separation Protocol (LISP) for Multicast 1143 Environments", RFC 6831, DOI 10.17487/RFC6831, January 1144 2013, . 1146 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 1147 "Interworking between Locator/ID Separation Protocol 1148 (LISP) and Non-LISP Sites", RFC 6832, 1149 DOI 10.17487/RFC6832, January 2013, 1150 . 1152 [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation 1153 Protocol Internet Groper (LIG)", RFC 6835, 1154 DOI 10.17487/RFC6835, January 2013, 1155 . 1157 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1158 "Locator/ID Separation Protocol Alternative Logical 1159 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 1160 January 2013, . 1162 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 1163 Routing Locator (RLOC) Database", RFC 6837, 1164 DOI 10.17487/RFC6837, January 2013, 1165 . 1167 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1168 UDP Checksums for Tunneled Packets", RFC 6935, 1169 DOI 10.17487/RFC6935, April 2013, 1170 . 1172 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1173 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1174 RFC 6936, DOI 10.17487/RFC6936, April 2013, 1175 . 1177 [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID 1178 Separation Protocol (LISP) MIB", RFC 7052, 1179 DOI 10.17487/RFC7052, October 2013, 1180 . 1182 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 1183 Pascual, J., and D. Lewis, "Locator/Identifier Separation 1184 Protocol (LISP) Network Element Deployment 1185 Considerations", RFC 7215, DOI 10.17487/RFC7215, April 1186 2014, . 1188 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 1189 Separation Protocol (LISP) Threat Analysis", RFC 7835, 1190 DOI 10.17487/RFC7835, April 2016, 1191 . 1193 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1194 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 1195 February 2017, . 1197 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 1198 Smirnov, "Locator/ID Separation Protocol Delegated 1199 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 1200 May 2017, . 1202 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 1203 Separation Protocol (LISP) Multicast", RFC 8378, 1204 DOI 10.17487/RFC8378, May 2018, 1205 . 1207 11.2. Informative References 1209 [I-D.cheng-lisp-shdht] 1210 Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping 1211 Overlay", Work in Progress, Internet-Draft, draft-cheng- 1212 lisp-shdht-04, 15 July 2013, . 1215 [I-D.curran-lisp-emacs] 1216 Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID 1217 Mappings Multicast Across Cooperating Systems for LISP", 1218 Work in Progress, Internet-Draft, draft-curran-lisp-emacs- 1219 00, 9 November 2007, 1220 . 1222 [Jakab] Jakab, L., Cabellos, A., Saucez, D., and O. Bonaventure, 1223 "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping 1224 System, IEEE Journal on Selected Areas in Communications, 1225 vol. 28, no. 8, pp. 1332-1343", October 2010. 1227 [Mathy] Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT: 1228 Towards a DHT to map identifiers onto locators. The ACM 1229 ReArch, Re-Architecting the Internet. Madrid (Spain)", 1230 December 2008. 1232 [Quoitin] Quoitin, B., Iannone, L., Launois, C., and O. Bonaventure, 1233 ""Evaluating the Benefits of the Locator/Identifier 1234 Separation" in Proceedings of 2Nd ACM/IEEE International 1235 Workshop on Mobility in the Evolving Internet 1236 Architecture", 2007. 1238 Appendix A. A Brief History of Location/Identity Separation 1240 The LISP architecture for separation of location and identity 1241 resulted from the discussions of this topic at the Amsterdam IAB 1242 Routing and Addressing Workshop, which took place in October 2006 1243 [RFC4984]. 1245 A small group of like-minded personnel spontaneously formed 1246 immediately after that workshop, to work on an idea that came out of 1247 informal discussions at the workshop and on various mailing lists. 1248 The first Internet-Draft on LISP appeared in January, 2007. 1250 Trial implementations started at that time, with initial trial 1251 deployments underway since June 2007; the results of early experience 1252 have been fed back into the design in a continuous, ongoing process 1253 over several years. LISP at this point represents a moderately 1254 mature system, having undergone a long organic series of changes and 1255 updates. 1257 LISP transitioned from an IRTF activity to an IETF WG in March 2009, 1258 and after numerous revisions, the basic specifications moved to 1259 becoming RFCs at the start of 2013 (although work to expand and 1260 improve it, and find new uses for it, continues, and undoubtly will 1261 for a long time to come). The LISP WG was rechartered in 2018 to 1262 continue work on the LISP base protocol and produce standard-track 1263 documents. 1265 A.1. Old LISP Models 1267 LISP, as initially conceived, had a number of potential operating 1268 modes, named 'models'. Although they are no used anymore, one 1269 occasionally sees mention of them, so they are briefly described 1270 here. 1272 LISP 1: EIDs all appear in the normal routing and forwarding tables 1273 of the network (i.e. they are 'routable');this property is used to 1274 'bootstrap' operation, by using this to load EID->RLOC mappings. 1275 Packets were sent with the EID as the destination in the outer 1276 wrapper; when an ETR saw such a packet, it would send a Map-Reply 1277 to the source ITR, giving the full mapping. 1279 LISP 1.5: Similar to LISP 1, but the routability of EIDs happens on 1280 a separate network. 1282 LISP 2: EIDs are not routable; EID->RLOC mappings are available from 1283 the DNS. 1285 LISP 3: EIDs are not routable; and have to be looked up in in a new 1286 EID->RLOC mapping database (in the initial concept, a system using 1287 Distributed Hash Tables). Two variants were possible: a 'push' 1288 system, in which all mappings were distributed to all ITRs, and a 1289 'pull' system in which ITRs load the mappings they need, as 1290 needed. 1292 Authors' Addresses 1294 Albert Cabellos 1295 UPC-BarcelonaTech 1296 c/ Jordi Girona 1-3 1297 08034 Barcelona Catalonia 1298 Spain 1300 Email: acabello@ac.upc.edu 1302 Damien Saucez (Ed.) 1303 Inria 1304 2004 route des Lucioles BP 93 1305 06902 Sophia Antipolis Cedex 1306 France 1308 Email: damien.saucez@inria.fr