idnits 2.17.1 draft-ietf-lisp-introduction-12.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 17, 2015) is 3356 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) ** Obsolete normative reference: RFC 6834 (Obsoleted by RFC 9302) == Outdated reference: A later version (-09) exists of draft-ietf-lisp-ddt-02 == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-07 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-07 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-threats-11 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: August 21, 2015 INRIA 6 February 17, 2015 8 An Architectural Introduction to the Locator/ID Separation Protocol 9 (LISP) 10 draft-ietf-lisp-introduction-12.txt 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 RFC6830, the protocol 19 specification. 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 http://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 August 21, 2015. 38 Copyright Notice 40 Copyright (c) 2015 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 (http://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. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 57 3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Overview of the Architecture . . . . . . . . . . . . . . 6 60 3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 9 61 3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 9 62 3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 10 63 3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 10 64 3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 11 65 3.4.2. Mapping System Interface . . . . . . . . . . . . . . 11 66 3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 12 67 3.5. Internetworking Mechanisms . . . . . . . . . . . . . . . 15 68 4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 16 69 4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 16 70 4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 17 71 4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 18 72 4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 18 73 5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 20 77 7.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 21 78 7.3. LISP for Virtual Private Networks . . . . . . . . . . . . 21 79 7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 22 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 85 11.2. Informative References . . . . . . . . . . . . . . . . . 25 86 Appendix A. A Brief History of Location/Identity Separation . . 26 87 A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 27 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 90 1. Introduction 92 This document introduces the Locator/ID Separation Protocol (LISP) 93 [RFC6830] architecture, 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 the unpublished Internet 97 Draft by Noel Chiappa [Chiappa], currently IP addresses both identify 98 the topological location of a network attachment point as well as the 99 node's identity. However, nodes and routing have fundamentally 100 different requirements, routing systems require that addresses are 101 aggregatable and have topological meaning, while 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 typically syntactically identical 106 to the current IPv4 and IPv6 addresses. 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 and interconnected by LISP-capable routers. LISP also 113 introduces a database, called the Mapping System, to store and 114 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 o RLOCs have meaning only in the underlay network, that is the 121 underlying core routing system. 123 o EIDs have meaning only in the overlay network unless they are 124 leaked into the underlay network. The overlay is the 125 encapsulation relationship between LISP-capable routers. 126 Furthermore EIDs are not assigned from the reserved address 127 blocks. 129 o The LISP edge maps EIDs to RLOCs 131 o Within the underlay network, RLOCs have both locator and 132 identifier semantics 134 o An EID within a LISP site carries both identifier and locator 135 semantics to other nodes within that site 137 o An EID within a LISP site carries identifier and limited locator 138 semantics to nodes at other LISP sites (i.e., enough locator 139 information to tell that the EID is external to the site) 141 The relationship described above is not unique to LISP but it is 142 common to other overlay technologies. 144 The initial motivation in the LISP effort is to be found in the 145 routing scalability problem [RFC4984], where, if LISP is completely 146 deployed, the Internet core is populated with RLOCs while Traffic 147 Engineering mechanisms are pushed to the Mapping System. In such 148 scenario RLOCs are quasi-static (i.e., low churn), hence making the 149 routing system scalable [Quoitin], while EIDs can roam anywhere with 150 no churn to the underlying routing system. [RFC7215] discusses the 151 impact of LISP on the global routing system during the transition 152 period. However, the separation between location and identity that 153 LISP offers makes it suitable for use in additional scenarios such as 154 Traffic Engineering (TE), multihoming, and mobility among others. 156 This document describes the LISP architecture, its main operational 157 mechanisms as its design rationale. It is important to note that 158 this document does not specify or complement the LISP protocol. The 159 interested reader should refer to the main LISP specifications 160 [RFC6830] and the complementary documents [RFC6831], [RFC6832], 161 [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC7052] for the 162 protocol specifications along with the LISP deployment guidelines 163 [RFC7215]. 165 2. Definition of Terms 167 Endpoint IDentifier (EID): EIDs are IPv4 or IPv6 addresses used to 168 uniquely identify nodes irrespective of their topological location 169 and are typically routed intra-domain. 171 Routing LOcator (RLOC): RLOCs are IPv4 or IPv6 addresses assigned 172 topologically to network attachment points and typically routed 173 inter-domain. 175 Ingress Tunnel Router (ITR): A LISP-capable router that encapsulates 176 packets from a LISP site towards the core network. 178 Egress Tunnel Router (ETR): A LISP-capable router that decapsulates 179 packets from the core of the network towards a LISP site. 181 xTR: A router that implements both ITR and ETR functionalities. 183 Map-Request: A LISP signaling message used to request an EID-to-RLOC 184 mapping. 186 Map-Reply: A LISP signaling message sent in response to a Map- 187 Request that contains a resolved EID-to-RLOC mapping. 189 Map-Register: A LISP signaling message used to register an EID-to- 190 RLOC mapping. 192 Map-Notify: A LISP signaling message sent in response of a Map- 193 Register to acknowledge the correct reception of an EID-to-RLOC 194 mapping. 196 This document describes the LISP architecture and does not introduce 197 any new term. The reader is referred to [RFC6830], [RFC6831], 198 [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC7052], 199 [RFC7215] for the complete definition of terms. 201 3. LISP Architecture 203 This section presents the LISP architecture, it first details the 204 design principles of LISP and then it proceeds to describe its main 205 aspects: data-plane, control-plane, and internetworking mechanisms. 207 3.1. Design Principles 209 The LISP architecture is built on top of four basic design 210 principles: 212 o Locator/Identifier split: By decoupling the overloaded semantics 213 of the current IP addresses the Internet core can be assigned 214 identity meaningful addresses and hence, can use aggregation to 215 scale. Devices are assigned with relatively opaque identity 216 meaningful addresses that are independent of their topological 217 location. 219 o Overlay architecture: Overlays route packets over the current 220 Internet, allowing deployment of new protocols without changing 221 the current infrastructure hence, resulting into a low deployment 222 cost. 224 o Decoupled data and control-plane: Separating the data-plane from 225 the control-plane allows them to scale independently and use 226 different architectural approaches. This is important given that 227 they typically have different requirements and allows for other 228 data-planes to be added. While decoupled, data and control-plane 229 are not completely isolated because the LISP data-plane may 230 trigger control-plane activity. 232 o Incremental deployability: This principle ensures that the 233 protocol interoperates with the legacy Internet while providing 234 some of the targeted benefits to early adopters. 236 3.2. Overview of the Architecture 238 LISP splits architecturally the core from the edge of the Internet by 239 creating two separate namespaces: Endpoint Identifiers (EIDs) and 240 Routing LOCators (RLOCs). The edge consists of LISP sites (e.g., an 241 Autonomous System) that use EID addresses. EIDs are typically -but 242 not limited to- IPv4 or IPv6 addresses that uniquely identify 243 communication end-hosts and are assigned and configured by the same 244 mechanisms that exist at the time of this writing. EIDs do not 245 contain inter-domain topological information and because of this, 246 EIDs are usually routable at the edge (within LISP sites) or in the 247 non-LISP Internet; see Section 3.5 for discussion of LISP site 248 internetworking with non-LISP sites and domains in the Internet. 250 With LISP, LISP sites (edge) and the core of the Internet are 251 interconnected by means of LISP-capable routers (e.g., border 252 routers) using tunnels. 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 typically -but not limited 281 to- an IPv4 or IPv6 address assigned to an Internet-facing network 282 interface of an ITR or ETR. Typically RLOCs are numbered from 283 topologically aggregatable blocks assigned to a site at each point to 284 which it attaches to the global Internet, the topology is defined by 285 the connectivity of networks. 287 A typically distributed database, called the Mapping System, stores 288 mappings between EIDs and RLOCs. Such mappings relate the identity 289 of the devices attached to LISP sites (EIDs) to the set of RLOCs 290 configured at the LISP-capable routers servicing the site. 291 Furthermore, the mappings also include traffic engineering policies 292 and can be configured to achieve multihoming and load balancing. The 293 LISP Mapping System is conceptually similar to the DNS where it is 294 organized as a distributed multi-organization network database. With 295 LISP, ETRs register mappings while ITRs retrieve them. 297 Finally, the LISP architecture emphasizes incremental deployment. 298 Given that LISP represents an overlay to the current Internet 299 architecture, endhosts as well as intra and inter-domain routers 300 remain unchanged, and the only required changes to the existing 301 infrastructure are to routers connecting the EID with the RLOC space. 302 Such LISP capable routers, in most cases, only require a software 303 upgrade. Additionally, LISP requires the deployment of an 304 independent Mapping System, such distributed database is a new 305 network entity. 307 The following describes a simplified packet flow sequence between two 308 nodes that are attached to LISP sites. Please note that typical 309 LISP-capable routers are xTRs (both ITR and ETR). Client HostA wants 310 to send a packet to server HostB. 312 /----------------\ 313 | Mapping | 314 | System | 315 .| |- 316 ` \----------------/ `. 317 ,` \ 318 / `. 319 ,' _,..-..,, ', 320 / -` `-, \ 321 .' ,' \ `, 322 ` ' \ ' 323 +-----+ | | RLOC_B1+-----+ 324 HostA | | | RLOC |-------| | HostB 325 EID_A--|ITR_A|----| Space | |ETR_B|--EID_B 326 | | RLOC_A1 |-------| | 327 +-----+ | | RLOC_B2+-----+ 328 , / 329 \ / 330 `', ,-` 331 ``''-''`` 333 Figure 2.- Packet flow sequence in LISP 335 1. HostA retrieves the EID_B of HostB, typically querying the DNS 336 and obtaining an A or AAAA record. Then it generates an IP 337 packet as in the Internet, the packet has source address EID_A 338 and destination address EID_B. 340 2. The packet is routed towards ITR_A in the LISP site using 341 standard intra-domain mechanisms. 343 3. ITR_A upon receiving the packet queries the Mapping System to 344 retrieve the locator of ETR_B that is servicing HostB's EID_B. 345 In order to do so it uses a LISP control message called Map- 346 Request, the message contains EID_B as the lookup key. In turn 347 it receives another LISP control message called Map-Reply, the 348 message contains two locators: RLOC_B1 and RLOC_B2 along with 349 traffic engineering policies: priority and weight per locator. 350 Note that a Map-Reply can contain more locators if needed. ITR_A 351 also stores the mapping in a local cache to speed-up forwarding 352 of subsequent packets. 354 4. ITR_A encapsulates the packet towards RLOC_B1 (chosen according 355 to the priorities/weights specified in the mapping). The packet 356 contains two IP headers, the outer header has RLOC_A1 as source 357 and RLOC_B1 as destination, the inner original header has EID_A 358 as source and EID_B as destination. Furthermore ITR_A adds a 359 LISP header, more details about LISP encapsulation can be found 360 in Section 3.3.1. 362 5. The encapsulated packet is forwarded by the Internet core as a 363 normal IP packet, making the EID invisible from the Internet 364 core. 366 6. Upon reception of the encapsulated packet by ETR_B, it 367 decapsulates the packet and forwards it to HostB. 369 3.3. Data-Plane 371 This section provides a high-level description of the LISP data- 372 plane, which is specified in detail in [RFC6830]. The LISP data- 373 plane is responsible for encapsulating and decapsulating data packets 374 and caching the appropriate forwarding state. It includes two main 375 entities, the ITR and the ETR, both are LISP capable routers that 376 connect the EID with the RLOC space (ITR) and vice versa (ETR). 378 3.3.1. LISP Encapsulation 380 ITRs encapsulate data packets towards ETRs. LISP data packets are 381 encapsulated using UDP (port 4341), the source port is usually 382 selected by the ITR using a 5-tuple hash of the inner header (so to 383 be consistent in case of multi-path solutions such as ECMP [RFC2992]) 384 and ignored on reception. A particularity of LISP is that UDP 385 packets should include a zero checksum [RFC6935] [RFC6936] that it is 386 not verified in reception, LISP also supports non-zero checksums that 387 may be verified. This decision was made because the typical 388 transport protocols used by the applications already include a 389 checksum, by neglecting the additional UDP encapsulation checksum 390 xTRs can forward packets more efficiently. 392 LISP-encapsulated packets also include a LISP header (after the UDP 393 header and before the original IP header). The LISP header is 394 prepended by ITRs and striped by ETRs. It carries reachability 395 information (see more details in Section 4.2) and the Instance ID 396 field. The Instance ID field is used to distinguish traffic to/from 397 different tenant address spaces at the LISP site and that may use 398 overlapped but logically separated EID addressing. 400 Overall, LISP works on 4 headers, the inner header the source 401 constructed, and the 3 headers a LISP encapsulator prepends ("outer" 402 to "inner"): 404 1. Outer IP header containing RLOCs as source and destination 405 addresses. This header is originated by ITRs and stripped by 406 ETRs. 408 2. UDP header (port 4341) with zero checksum. This header is 409 originated by ITRs and stripped by ETRs. 411 3. LISP header that contains various forwarding-plane features (such 412 as reachability) and an Instance ID field. This header is 413 originated by ITRs and stripped by ETRs. 415 4. Inner IP header containing EIDs as source and destination 416 addresses. This header is created by the source end-host and is 417 left unchanged by LISP data plane processing on the ITR and ETR. 419 Finally, in some scenarios Re-encapsulating and/or Recursive tunnels 420 are useful to choose a specified path in the underlay network, for 421 instance to avoid congestion or failure. Re-encapsulating tunnels 422 are consecutive LISP tunnels and occur when a decapsulator (an ETR 423 action) removes a LISP header and then acts as an encapsultor (an ITR 424 action) to prepend another one. On the other hand, Recursive tunnels 425 are nested tunnels and are implemented by using multiple LISP 426 encapsulations on a packet. Such functions are implemented by 427 Reencapsulating Tunnel Routers (RTRs). An RTR can be thought of as a 428 router that first acts as an ETR by decapsulating packets and then as 429 an ITR by encapsulating them towards another locator, more 430 information can be found at [RFC6830]. 432 3.3.2. LISP Forwarding State 434 In the LISP architecture, ITRs keep just enough information to route 435 traffic flowing through them. Meaning that, ITRs retrieve from the 436 LISP Mapping System mappings between EID-prefixes (blocks of EIDs) 437 and RLOCs that are used to encapsulate packets. Such mappings are 438 stored in a local cache called the Map-Cache for subsequent packets 439 addressed to the same EID prefix. Note that, in case of overlapping 440 EID-prefixes, following a single request, the ITR may receive a set 441 of mappings, covering the requested EID-prefix and all more-specifics 442 (cf., Section 6.1.5 [RFC6830]). Mappings include a (Time-to-Live) 443 TTL (set by the ETR). More details about the Map-Cache management 444 can be found in Section 4.1. 446 3.4. Control-Plane 448 The LISP control-plane, specified in [RFC6833], provides a standard 449 interface to register and request mappings. The LISP Mapping System 450 is a database that stores such mappings. The following first 451 describes the mappings, then the standard interface to the Mapping 452 System, and finally its architecture. 454 3.4.1. LISP Mappings 456 Each mapping includes the bindings between EID prefix(es) and set of 457 RLOCs as well as traffic engineering policies, in the form of 458 priorities and weights for the RLOCs. Priorities allow the ETR to 459 configure active/backup policies while weights are used to load- 460 balance traffic among the RLOCs (on a per-flow basis). 462 Typical mappings in LISP bind EIDs in the form of IP prefixes with a 463 set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses are 464 encoded using the appropriate Address Family Identifier (AFI) 465 [RFC3232]. However LISP can also support more general address 466 encoding by means of the ongoing effort around the LISP Canonical 467 Address Format (LCAF) [I-D.ietf-lisp-lcaf]. 469 With such a general syntax for address encoding in place, LISP aims 470 to provide flexibility to current and future applications. For 471 instance LCAFs could support MAC addresses, geo-coordinates, ASCII 472 names and application specific data. 474 3.4.2. Mapping System Interface 476 LISP defines a standard interface between data and control planes. 477 The interface is specified in [RFC6833] and defines two entities: 479 Map-Server: A network infrastructure component that learns mappings 480 from ETRs and publishes them into the LISP Mapping System. 481 Typically Map-Servers are not authoritative to reply to queries 482 and hence, they forward them to the ETR. However they can also 483 operate in proxy-mode, where the ETRs delegate replying to queries 484 to Map-Servers. This setup is useful when the ETR has limited 485 resources (i.e., CPU or power). 487 Map-Resolver: A network infrastructure component that interfaces 488 ITRs with the Mapping System by proxying queries and in some cases 489 responses. 491 The interface defines four LISP control messages which are sent as 492 UDP datagrams (port 4342): 494 Map-Register: This message is used by ETRs to register mappings in 495 the Mapping System and it is authenticated using a shared key 496 between the ETR and the Map-Server. 498 Map-Notify: When requested by the ETR, this message is sent by the 499 Map-Server in response to a Map-Register to acknowledge the 500 correct reception of the mapping and convey the latest Map-Server 501 state on the EID to RLOC mapping. In some cases a Map-Notify can 502 be sent to the previous RLOCs when an EID is registered by a new 503 set of RLOCs. 505 Map-Request: This message is used by ITRs or Map-Resolvers to 506 resolve the mapping of a given EID. 508 Map-Reply: This message is sent by Map-Servers or ETRs in response 509 to a Map-Request and contains the resolved mapping. Please note 510 that a Map-Reply may contain a negative reply if, for example, the 511 queried EID is not part of the LISP EID space. In such cases the 512 ITR typically forwards the traffic natively (non encapsulated) to 513 the public Internet, this behavior is defined to support 514 incremental deployment of LISP. 516 3.4.3. Mapping System 518 LISP architecturally decouples control and data-plane by means of a 519 standard interface. This interface glues the data-plane, routers 520 responsible for forwarding data-packets, with the LISP Mapping 521 System, a database responsible for storing mappings. 523 With this separation in place the data and control-plane can use 524 different architectures if needed and scale independently. Typically 525 the data-plane is optimized to route packets according to 526 hierarchical IP addresses. However the control-plane may have 527 different requirements, for instance and by taking advantage of the 528 LCAFs, the Mapping System may be used to store non-hierarchical keys 529 (such as MAC addresses), requiring different architectural approaches 530 for scalability. Another important difference between the LISP 531 control and data-planes is that, and as a result of the local mapping 532 cache available at ITR, the Mapping System does not need to operate 533 at line-rate. 535 Many of the existing mechanisms to create distributed systems have 536 been explored and considered for the Mapping System architecture: 537 graph-based databases in the form of LISP+ALT [RFC6836], hierarchical 538 databases in the form of LISP-DDT [I-D.ietf-lisp-ddt], monolithic 539 databases in the form of LISP-NERD [RFC6837], flat databases in the 540 form of LISP-DHT [I-D.cheng-lisp-shdht],[Mathy] and, a multicast- 541 based database [I-D.curran-lisp-emacs]. Furthermore it is worth 542 noting that, in some scenarios such as private deployments, the 543 Mapping System can operate as logically centralized. In such cases 544 it is typically composed of a single Map-Server/Map-Resolver. 546 The following focuses on the two mapping systems that have been 547 implemented and deployed (LISP-ALT and LISP+DDT). 549 3.4.3.1. LISP+ALT 551 The LISP Alternative Topology (LISP+ALT) [RFC6836] was the first 552 Mapping System proposed, developed and deployed on the LISP pilot 553 network. It is based on a distributed BGP overlay participated by 554 Map-Servers and Map-Resolvers. The nodes connect to their peers 555 through static tunnels. Each Map-Server involved in the ALT topology 556 advertises the EID-prefixes registered by the serviced ETRs, making 557 the EID routable on the ALT topology. 559 When an ITR needs a mapping it sends a Map-Request to a Map-Resolver 560 that, using the ALT topology, forwards the Map-Request towards the 561 Map-Server responsible for the mapping. Upon reception the Map- 562 Server forwards the request to the ETR that in turn, replies directly 563 to the ITR using the native Internet core. 565 3.4.3.2. LISP-DDT 567 LISP-DDT [I-D.ietf-lisp-ddt] is conceptually similar to the DNS, a 568 hierarchical directory whose internal structure mirrors the 569 hierarchical nature of the EID address space. The DDT hierarchy is 570 composed of DDT nodes forming a tree structure, the leafs of the tree 571 are Map-Servers. On top of the structure there is the DDT root node 572 [DDT-ROOT], which is a particular instance of a DDT node and that 573 matches the entire address space. As in the case of DNS, DDT 574 supports multiple redundant DDT nodes and/or DDT roots. Finally, 575 Map-Resolvers are the clients of the DDT hierarchy and can query 576 either the DDT root and/or other DDT nodes. 578 /---------\ 579 | | 580 | DDT Root| 581 | /0 | 582 ,.\---------/-, 583 ,-'` | `'., 584 -'` | `- 585 /-------\ /-------\ /-------\ 586 | DDT | | DDT | | DDT | 587 | Node | | Node | | Note | ... 588 | 0/8 | | 1/8 | | 2/8 | 589 \-------/ \-------/ \-------/ 590 _. _. . -..,,,_ 591 -` -` \ ````''-- 592 +------------+ +------------+ +------------+ +------------+ 593 | Map-Server | | Map-Server | | Map-Server | | Map-Server | 594 | EID-prefix1| | EID-prefix2| | EID-prefix3| | EID-prefix4| 595 +------------+ +------------+ +------------+ +------------+ 597 Figure 3.- A schematic representation of the DDT tree structure, 598 please note that the prefixes and the structure depicted 599 should be only considered as an example. 601 The DDT structure does not actually index EID-prefixes but eXtended 602 EID-prefixes (XEID). An XEID-prefix is just the concatenation of the 603 following fields (from most significant bit to less significant bit): 604 Database-ID, Instance ID, Address Family Identifier and the actual 605 EID-prefix. The Database-ID is provided for possible future 606 requirements of higher levels in the hierarchy and to enable the 607 creation of multiple and separate database trees. 609 In order to resolve a query LISP-DDT operates in a similar way to the 610 DNS but only supports iterative lookups. DDT clients (usually Map- 611 Resolvers) generate Map-Requests to the DDT root node. In response 612 they receive a newly introduced LISP-control message: a Map-Referral. 613 A Map-Referral provides the list of RLOCs of the set of DDT nodes 614 matching a configured XEID delegation. That is, the information 615 contained in the Map-Referral points to the child of the queried DDT 616 node that has more specific information about the queried XEID- 617 prefix. This process is repeated until the DDT client walks the tree 618 structure (downwards) and discovers the Map-Server servicing the 619 queried XEID. At this point the client sends a Map-Request and 620 receives a Map-Reply containing the mappings. It is important to 621 note that DDT clients can also cache the information contained in 622 Map-Referrals, that is, they cache the DDT structure. This is used 623 to reduce the mapping retrieving latency[Jakab]. 625 The DDT Mapping System relies on manual configuration. That is Map- 626 Resolvers are manually configured with the set of available DDT root 627 nodes while DDT nodes are manually configured with the appropriate 628 XEID delegations. Configuration changes in the DDT nodes are only 629 required when the tree structure changes itself, but it doesn't 630 depend on EID dynamics (RLOC allocation or traffic engineering policy 631 changes). 633 3.5. Internetworking Mechanisms 635 EIDs are typically identical to either IPv4 or IPv6 addresses and 636 they are stored in the LISP Mapping System, however they are usually 637 not announced in the Internet global routing system. As a result 638 LISP requires an internetworking mechanism to allow LISP sites to 639 speak with non-LISP sites and vice versa. LISP internetworking 640 mechanisms are specified in [RFC6832]. 642 LISP defines two entities to provide internetworking: 644 Proxy Ingress Tunnel Router (PITR): PITRs provide connectivity from 645 the legacy Internet to LISP sites. PITRs announce in the global 646 routing system blocks of EID prefixes (aggregating when possible) 647 to attract traffic. For each incoming packet from a source not in 648 a LISP site (a non-EID), the PITR LISP-encapsulates it towards the 649 RLOC(s) of the appropriate LISP site. The impact of PITRs in the 650 routing table size of the Default-Free Zone (DFZ) is, in the 651 worst-case, similar to the case in which LISP is not deployed. 652 EID-prefixes will be aggregated as much as possible both by the 653 PITR and by the global routing system. 655 Proxy Egress Tunnel Router (PETR): PETRs provide connectivity from 656 LISP sites to the legacy Internet. In some scenarios, LISP sites 657 may be unable to send encapsulated packets with a local EID 658 address as a source to the legacy Internet. For instance when 659 Unicast Reverse Path Forwarding (uRPF) is used by Provider Edge 660 routers, or when an intermediate network between a LISP site and a 661 non-LISP site does not support the desired version of IP (IPv4 or 662 IPv6). In both cases the PETR overcomes such limitations by 663 encapsulating packets over the network. There is no specified 664 provision for the distribution of PETR RLOC addresses to the ITRs. 666 Additionally, LISP also defines mechanisms to operate with private 667 EIDs [RFC1918] by means of LISP-NAT [RFC6832]. In this case the xTR 668 replaces a private EID source address with a routable one. At the 669 time of this writing, work is ongoing to define NAT-traversal 670 capabilities, that is xTRs behind a NAT using non-routable RLOCs. 672 PITRs, PETRs and, LISP-NAT enable incremental deployment of LISP, by 673 providing significant flexibility in the placement of the boundaries 674 between the LISP and non-LISP portions of the network, and making it 675 easy to change those boundaries over time. 677 4. LISP Operational Mechanisms 679 This section details the main operational mechanisms defined in LISP. 681 4.1. Cache Management 683 LISP's decoupled control and data-plane, where mappings are stored in 684 the control-plane and used for forwarding in the data plane, requires 685 a local cache in ITRs to reduce signaling overhead (Map-Request/Map- 686 Reply) and increase forwarding speed. The local cache available at 687 the ITRs, called Map-Cache, is used by the router to LISP-encapsulate 688 packets. The Map-Cache is indexed by (Instance ID, EID-prefix) and 689 contains basically the set of RLOCs with the associated traffic 690 engineering policies (priorities and weights). 692 The Map-Cache, as any other cache, requires cache coherence 693 mechanisms to maintain up-to-date information. LISP defines three 694 main mechanisms for cache coherence: 696 Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon 697 expiration of the TTL the ITR has to refresh the mapping by 698 sending a new Map-Request. Typical values for TTL defined by LISP 699 are 24 hours. 701 Solicit-Map-Request (SMR): SMR is an explicit mechanism to update 702 mapping information. In particular a special type of Map-Request 703 can be sent on demand by ETRs to request refreshing a mapping. 704 Upon reception of a SMR message, the ITR must refresh the bindings 705 by sending a Map-Request to the Mapping System. Further uses of 706 SMRs are documented in [RFC6830]. 708 Map-Versioning: This optional mechanism piggybacks in the LISP 709 header of data-packets the version number of the mappings used by 710 an xTR. This way, when an xTR receives a LISP-encapsulated packet 711 from a remote xTR, it can check whether its own Map-Cache or the 712 one of the remote xTR is outdated. If its Map-Cache is outdated, 713 it sends a Map-Request for the remote EID so to obtain the newest 714 mappings. On the contrary, if it detects that the remote xTR Map- 715 Cache is outdated, it sends a SMR to notify it that a new mapping 716 is available. 718 Finally it is worth noting that in some cases an entry in the map- 719 cache can be proactively refreshed using the mechanisms described in 720 the section below. 722 4.2. RLOC Reachability 724 The LISP architecture is an edge to edge pull architecture, where the 725 network state is stored in the control-plane while the data-plane 726 pulls it on demand. This has consequences concerning the propagation 727 of xTRs reachability/liveness information. On the contrary BGP is a 728 push architecture, where the required network state is pushed by 729 means of BGP UPDATE messages to BGP speakers. In push architectures, 730 reachability information is also pushed to the interested routers. 731 However pull architectures require explicit mechanisms to propagate 732 reachability information. LISP defines a set of mechanisms to inform 733 ITRs and PITRS about the reachability of the cached RLOCs: 735 Locator Status Bits (LSB): LSB is a passive technique, the LSB field 736 is carried by data-packets in the LISP header and can be set by a 737 ETRs to specify which RLOCs of the ETR site are up/down. This 738 information can be used by the ITRs as a hint about the reachability 739 to perform additional checks. Also note that LSB does not provide 740 path reachability status, only hints on the status of RLOCs. 742 Echo-nonce: This is also a passive technique, that can only operate 743 effectively when data flows bi-directionally between two 744 communicating xTRs. Basically, an ITR piggybacks a random number 745 (called nonce) in LISP data packets, if the path and the probed 746 locator are up, the ETR will piggyback the same random number on the 747 next data-packet, if this is not the case the ITR can set the locator 748 as unreachable. When traffic flow is unidirectional or when the ETR 749 receiving the traffic is not the same as the ITR that transmits it 750 back, additional mechanisms are required. 752 RLOC-probing: This is an active probing algorithm where ITRs send 753 probes to specific locators, this effectively probes both the locator 754 and the path. In particular this is done by sending a Map-Request 755 (with certain flags activated) on the data-plane (RLOC space) and 756 waiting in return a Map-Reply, also sent on the data-plane. The 757 active nature of RLOC-probing provides an effective mechanism to 758 determine reachability and, in case of failure, switching to a 759 different locator. Furthermore the mechanism also provides useful 760 RTT estimates of the delay of the path that can be used by other 761 network algorithms. 763 It is worth noting that RLOC probing and Echo-nonce can work 764 together. Specifically if a nonce is not echoed, an ITR could RLOC- 765 probe to determine if the path is up when it cannot tell the 766 difference between a failed bidirectional path or the return path is 767 not used (a unidirectional path). 769 Additionally, LISP also recommends inferring reachability of locators 770 by using information provided by the underlay, in particular: 772 ICMP signaling: The LISP underlay -the current Internet- uses the 773 ICMP protocol to signal unreachability (among other things). LISP 774 can take advantage of this and the reception of a ICMP Network 775 Unreachable or ICMP Host Unreachable message can be seen as a hint 776 that a locator might be unreachable, this should lead to perform 777 additional checks. 779 Underlay routing: Both BGP and IBGP carry reachability information, 780 LISP-capable routers that have access to underlay routing information 781 can use it to determine if a given locator or path are reachable. 783 4.3. ETR Synchronization 785 All the ETRs that are authoritative to a particular EID-prefix must 786 announce the same mapping to the requesters, this means that ETRs 787 must be aware of the status of the RLOCs of the remaining ETRs. This 788 is known as ETR synchronization. 790 At the time of this writing LISP does not specify a mechanism to 791 achieve ETR synchronization. Although many well-known techniques 792 could be applied to solve this issue it is still under research, as a 793 result operators must rely on coherent manual configuration 795 4.4. MTU Handling 797 Since LISP encapsulates packets it requires dealing with packets that 798 exceed the MTU of the path between the ITR and the ETR. Specifically 799 LISP defines two mechanisms: 801 Stateless: With this mechanism the effective MTU is assumed from the 802 ITR's perspective. If a payload packet is too big for the 803 effective MTU, and can be fragmented, the payload packet is 804 fragmented on the ITR, such that reassembly is performed at the 805 destination host. 807 Stateful: With this mechanism ITRs keep track of the MTU of the 808 paths towards the destination locators by parsing the ICMP Too Big 809 packets sent by intermediate routers. ITRs will send ICMP Too Big 810 messages to inform the sources about the effective MTU. 811 Additionally ITRs can use mechanisms such as PMTUD [RFC1191] or 812 PLPMTUD [RFC4821] to keep track of the MTU towards the locators. 814 In both cases if the packet cannot be fragmented (IPv4 with DF=1 or 815 IPv6) then the ITR drops it and replies with a ICMP Too Big message 816 to the source. 818 5. Mobility 820 The separation between locators and identifiers in LISP was initially 821 proposed for traffic engineering purpose where LISP sites can change 822 their attachment points to the Internet (i.e., RLOCs) without 823 impacting endpoints or the Internet core. In this context, the 824 border routers operate the xTR functionality and endpoints are not 825 aware of the existence of LISP. This functionality is similar to 826 Network Mobility [RFC3963]. However, this mode of operation does not 827 allow seamless mobility of endpoints between different LISP sites as 828 the EID address might not be routable in a visited site. 829 Nevertheless, LISP can be used to enable seamless IP mobility when 830 LISP is directly implemented in the endpoint or when the endpoint 831 roams to an attached xTR. Each endpoint is then an xTR and the EID 832 address is the one presented to the network stack used by 833 applications while the RLOC is the address gathered from the network 834 when it is visited. This functionality is similar to Mobile IP 835 ([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. 863 At the core, ETRs build a new PIM Join/Prune message addressed to the 864 RLOC of the ITR servicing the source. An simplified sequence is 865 shown below 867 1. An end-host willing to join a multicast channel sends an IGMP 868 report. Multicast PIM routers at the LISP site propagate PIM 869 Join/Prune messages (S-EID, G) towards the ETR. 871 2. The join message flows to the ETR, upon reception the ETR builds 872 two join messages, the first one unicast LISP-encapsulates the 873 original join message towards the RLOC of the ITR servicing the 874 source. This message creates (S-EID, G) multicast state at the 875 source site. The second join message contains as destination 876 address the RLOC of the ITR servicing the source (S-RLOC, G) and 877 creates multicast state at the core. 879 3. Multicast data packets originated by the source (S-EID, G) flow 880 from the source to the ITR. The ITR LISP-encapsulates the 881 multicast packets, the outter header includes its own RLOC as the 882 source (S-RLOC) and the original multicast group address (G) as 883 the destination. Please note that multicast group address are 884 logical and are not resolved by the mapping system. Then the 885 multicast packet is transmitted through the core towards the 886 receiving ETRs that decapsulates the packets and sends them using 887 the receiver's site multicast state. 889 Please note that the inner and outer multicast addresses are in 890 general different, unless in specific cases where the underlay 891 provider implements a tight control on the overlay. LISP 892 specifications already support all PIM modes [RFC6831]. 893 Additionally, LISP can support as well non-PIM mechanisms in order to 894 maintain multicast state. 896 7. Use Cases 898 7.1. Traffic Engineering 900 BGP is the standard protocol to implement inter-domain routing. With 901 BGP, routing information are propagated along the network and each 902 autonomous system can implement its own routing policy that will 903 influence the way routing information are propagated. The direct 904 consequence is that an autonomous system cannot precisely control the 905 way the traffic will enter the network. 907 As opposed to BGP, a LISP site can strictly impose via which ETRs the 908 traffic must enter the the LISP site network even though the path 909 followed to reach the ETR is not under the control of the LISP site. 910 This fine control is implemented with the mappings. When a remote 911 site is willing to send traffic to a LISP site, it retrieves the 912 mapping associated to the destination EID via the mapping system. 913 The mapping is sent directly by an authoritative ETR of the EID and 914 is not altered by any intermediate network. 916 A mapping associates a list of RLOCs to an EID prefix. Each RLOC 917 corresponds to an interface of an ETR (or set of ETRs) that is able 918 to correctly forward packets to EIDs in the prefix. Each RLOC is 919 tagged with a priority and a weight in the mapping. The priority is 920 used to indicates which RLOCs should be preferred to send packets 921 (the least preferred ones being provided for backup purpose). The 922 weight permits to balance the load between the RLOCs with the same 923 priority, proportionally to the weight value. 925 As mappings are directly issued by the authoritative ETR of the EID 926 and are not altered while transmitted to the remote site, it offers 927 highly flexible incoming inter-domain traffic engineering with even 928 the possibility for a site to issue a different mapping for each 929 remote site, implementing so precise routing policies. 931 7.2. LISP for IPv6 Co-existence 933 LISP encapsulations allows to transport packets using EIDs from a 934 given address family (e.g., IPv6) with packets from other address 935 families (e.g., IPv4). The absence of correlation between the 936 address family of RLOCs and EIDs makes LISP a candidate to allow, 937 e.g., IPv6 to be deployed when all of the core network may not have 938 IPv6 enabled. 940 For example, two IPv6-only data centers could be interconnected via 941 the legacy IPv4 Internet. If their border routers are LISP capable, 942 sending packets between the data center is done without any form of 943 translation as the native IPv6 packets (in the EID space) will be 944 LISP encapsulated and transmitted over the IPv4 legacy Internet by 945 the mean of IPv4 RLOCs. 947 7.3. LISP for Virtual Private Networks 949 It is common to operate several virtual networks over the same 950 physical infrastructure. In such virtual private networks, it is 951 essential to distinguish which virtual network a packet belongs and 952 tags or labels are used for that purpose. When using LISP, the 953 distinction can be made with the Instance ID field. When an ITR 954 encapsulates a packet from a particular virtual network (e.g., known 955 via the VRF or VLAN), it tags the encapsulated packet with the 956 Instance ID corresponding to the virtual network of the packet. When 957 an ETR receives a packet tagged with an Instance ID it uses the 958 Instance ID to determine how to treat the packet. 960 The main usage of LISP for virtual private networks does not 961 introduce additional requirements on the underlying network, as long 962 as it is running IP. 964 7.4. LISP for Virtual Machine Mobility in Data Centers 966 A way to enable seamless virtual machine mobility in data center is 967 to conceive the datacenter backbone as the RLOC space and the subnet 968 where servers are hosted as forming the EID space. A LISP router is 969 placed at the border between the backbone and each subnet. When a 970 virtual machine is moved to another subnet, it can keep (temporarily) 971 the address it had before the move so to continue without a transport 972 layer connection reset. When an xTR detects a source address 973 received on a subnet to be an address not assigned to the subnet, it 974 registers the address to the Mapping System. 976 To inform the other LISP routers that the machine moved and where, 977 and then to avoid detours via the initial subnetwork, mechanisms such 978 as the Solicit-Map-Request messages are used. 980 8. Security Considerations 982 This section describes the security considerations associated to the 983 LISP protocol. 985 LISP uses a pull architecture to learn mappings. While in a push 986 system, the state necessary to forward packets is learned 987 independently of the traffic itself, with a pull architecture, the 988 system becomes reactive and data-plane events (e.g., the arrival of a 989 packet for an unknown destination) may trigger control-plane events. 990 This on-demand learning of mappings provides many advantages as 991 discussed above but may also affect the way security is enforced. 993 Usually, the data-plane is implemented in the fast path of routers to 994 provide high performance forwarding capabilities while the control- 995 plane features are implemented in the slow path to offer high 996 flexibility and a performance gap of several order of magnitude can 997 be observed between the slow and the fast paths. As a consequence, 998 the way data-plane events are notified to the control-plane must be 999 thought carefully so to not overload the slow path and rate limiting 1000 should be used as specified in [RFC6830]. 1002 Care must also be taken so to not overload the mapping system (i.e., 1003 the control plane infrastructure) as the operations to be performed 1004 by the mapping system may be more complex than those on the data- 1005 plane, for that reason [RFC6830] recommends to rate limit the sending 1006 of messages to the mapping system. 1008 To improve resiliency and reduce the overall number of messages 1009 exchanged, LISP offers the possibility to leak information, such as 1010 reachabilty of locators, directly into data plane packets. In 1011 environments that are not fully trusted, control information gleaned 1012 from data-plane packets should be verified before using them. 1014 Mappings are the centrepiece of LISP and all precautions must be 1015 taken to avoid them to be manipulated or misused by malicious 1016 entities. Using trustable Map-Servers that strictly respect 1017 [RFC6833] and the lightweight authentication mechanism proposed by 1018 LISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks to the 1019 mapping integrity. In more critical environments, secure measures 1020 may be needed. 1022 As with any other tunneling mechanism, middleboxes on the path 1023 between an ITR (or PITR) and an ETR (or PETR) must implement 1024 mechanisms to strip the LISP encapsulation to correctly inspect the 1025 content of LISP encapsulated packets. 1027 Like other map-and-encap mechanisms, LISP enables triangular routing 1028 (i.e., packets of a flow cross different border routers depending on 1029 their direction). This means that intermediate boxes may have 1030 incomplete view on the traffic they inspect or manipulate. Moreover, 1031 LISP-encapsulated packets are routed based on the outer IP address 1032 (i.e., the RLOC), and can be delivered to an ETR that is not 1033 responsible of the destination EID of the packet or even to a network 1034 element that is not an ETR. The mitigation consists in applying 1035 appropriate filtering techniques on the network elements that can 1036 potentially receive un-expected LISP-encapsulated packets 1038 More details about security implications of LISP are discussed in 1039 [I-D.ietf-lisp-threats]. 1041 9. IANA Considerations 1043 This memo includes no request to IANA. 1045 10. Acknowledgements 1047 This document was initiated by Noel Chiappa and much of the core 1048 philosophy came from him. The authors acknowledge the important 1049 contributions he has made to this work and thank him for his past 1050 efforts. 1052 The authors would also like to thank Dino Farinacci, Fabio Maino, 1053 Luigi Iannone, Sharon Barkai, Isidoros Kouvelas, Christian Cassar, 1054 Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald 1055 Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, 1056 David Black as well as every people acknowledged in [RFC6830]. 1058 11. References 1060 11.1. Normative References 1062 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1063 November 1990. 1065 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1066 E. Lear, "Address Allocation for Private Internets", BCP 1067 5, RFC 1918, February 1996. 1069 [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path 1070 Algorithm", RFC 2992, November 2000. 1072 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 1073 an On-line Database", RFC 3232, January 2002. 1075 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1076 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1077 RFC 3963, January 2005. 1079 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1080 Discovery", RFC 4821, March 2007. 1082 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 1083 Workshop on Routing and Addressing", RFC 4984, September 1084 2007. 1086 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 1087 5944, November 2010. 1089 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1090 in IPv6", RFC 6275, July 2011. 1092 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1093 Locator/ID Separation Protocol (LISP)", RFC 6830, January 1094 2013. 1096 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 1097 Locator/ID Separation Protocol (LISP) for Multicast 1098 Environments", RFC 6831, January 2013. 1100 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 1101 "Interworking between Locator/ID Separation Protocol 1102 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 1104 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 1105 Protocol (LISP) Map-Server Interface", RFC 6833, January 1106 2013. 1108 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 1109 Separation Protocol (LISP) Map-Versioning", RFC 6834, 1110 January 2013. 1112 [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation 1113 Protocol Internet Groper (LIG)", RFC 6835, January 2013. 1115 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1116 "Locator/ID Separation Protocol Alternative Logical 1117 Topology (LISP+ALT)", RFC 6836, January 2013. 1119 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 1120 Routing Locator (RLOC) Database", RFC 6837, January 2013. 1122 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1123 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 1125 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1126 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1127 RFC 6936, April 2013. 1129 [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID 1130 Separation Protocol (LISP) MIB", RFC 7052, October 2013. 1132 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 1133 Pascual, J., and D. Lewis, "Locator/Identifier Separation 1134 Protocol (LISP) Network Element Deployment 1135 Considerations", RFC 7215, April 2014. 1137 11.2. Informative References 1139 [Chiappa] Chiappa, J., "Endpoints and Endpoint names: A Propose 1140 Enhancement to the Internet Architecture, 1141 http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt", 1999. 1143 [DDT-ROOT] 1144 LISP DDT ROOT, , "http://ddt-root.org/", August 2013. 1146 [I-D.cheng-lisp-shdht] 1147 Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping 1148 Overlay", draft-cheng-lisp-shdht-04 (work in progress), 1149 July 2013. 1151 [I-D.curran-lisp-emacs] 1152 Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID 1153 Mappings Multicast Across Cooperating Systems for LISP", 1154 draft-curran-lisp-emacs-00 (work in progress), November 1155 2007. 1157 [I-D.ietf-lisp-ddt] 1158 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 1159 Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in 1160 progress), October 2014. 1162 [I-D.ietf-lisp-lcaf] 1163 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1164 Address Format (LCAF)", draft-ietf-lisp-lcaf-07 (work in 1165 progress), December 2014. 1167 [I-D.ietf-lisp-sec] 1168 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 1169 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07 1170 (work in progress), October 2014. 1172 [I-D.ietf-lisp-threats] 1173 Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats 1174 Analysis", draft-ietf-lisp-threats-11 (work in progress), 1175 December 2014. 1177 [Jakab] Jakab, L., Cabellos, A., Saucez, D., and O. Bonaventure, 1178 "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping 1179 System, IEEE Journal on Selected Areas in Communications, 1180 vol. 28, no. 8, pp. 1332-1343", October 2010. 1182 [Mathy] Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT: 1183 Towards a DHT to map identifiers onto locators. The ACM 1184 ReArch, Re-Architecting the Internet. Madrid (Spain)", 1185 December 2008. 1187 [Quoitin] Quoitin, B., Iannone, L., Launois, C., and O. Bonaventure, 1188 ""Evaluating the Benefits of the Locator/Identifier 1189 Separation" in Proceedings of 2Nd ACM/IEEE International 1190 Workshop on Mobility in the Evolving Internet 1191 Architecture", 2007. 1193 Appendix A. A Brief History of Location/Identity Separation 1195 The LISP system for separation of location and identity resulted from 1196 the discussions of this topic at the Amsterdam IAB Routing and 1197 Addressing Workshop, which took place in October 2006 [RFC4984]. 1199 A small group of like-minded personnel from various scattered 1200 locations within Cisco, spontaneously formed immediately after that 1201 workshop, to work on an idea that came out of informal discussions at 1202 the workshop and on various mailing lists. The first Internet-Draft 1203 on LISP appeared in January, 2007. 1205 Trial implementations started at that time, with initial trial 1206 deployments underway since June 2007; the results of early experience 1207 have been fed back into the design in a continuous, ongoing process 1208 over several years. LISP at this point represents a moderately 1209 mature system, having undergone a long organic series of changes and 1210 updates. 1212 LISP transitioned from an IRTF activity to an IETF WG in March 2009, 1213 and after numerous revisions, the basic specifications moved to 1214 becoming RFCs at the start of 2013 (although work to expand and 1215 improve it, and find new uses for it, continues, and undoubtly will 1216 for a long time to come). 1218 A.1. Old LISP Models 1220 LISP, as initially conceived, had a number of potential operating 1221 modes, named 'models'. Although they are not used anymore, one 1222 occasionally sees mention of them, so they are briefly described 1223 here. 1225 LISP 1: EIDs all appear in the normal routing and forwarding tables 1226 of the network (i.e. they are 'routable');this property is used to 1227 'bootstrap' operation, by using this to load EID->RLOC mappings. 1228 Packets were sent with the EID as the destination in the outer 1229 wrapper; when an ETR saw such a packet, it would send a Map-Reply 1230 to the source ITR, giving the full mapping. 1232 LISP 1.5: Similar to LISP 1, but the routability of EIDs happens on 1233 a separate network. 1235 LISP 2: EIDs are not routable; EID->RLOC mappings are available from 1236 the DNS. 1238 LISP 3: EIDs are not routable; and have to be looked up in in a new 1239 EID->RLOC mapping database (in the initial concept, a system using 1240 Distributed Hash Tables). Two variants were possible: a 'push' 1241 system, in which all mappings were distributed to all ITRs, and a 1242 'pull' system in which ITRs load the mappings they need, as 1243 needed. 1245 Authors' Addresses 1247 Albert Cabellos 1248 UPC-BarcelonaTech 1249 c/ Jordi Girona 1-3 1250 Barcelona, Catalonia 08034 1251 Spain 1253 Email: acabello@ac.upc.edu 1255 Damien Saucez (Ed.) 1256 INRIA 1257 2004 route des Lucioles BP 93 1258 Sophia Antipolis Cedex 06902 1259 France 1261 Email: damien.saucez@inria.fr