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