idnits 2.17.1 draft-ietf-lisp-introduction-09.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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 12, 2014) is 3446 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'DFZ' is defined on line 1063, but no explicit reference was found in the text ** 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-06 == 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-10 -- No information found for draft-mathy-lisp-dht - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Cabellos 3 Internet-Draft UPC-BarcelonaTech 4 Intended status: Informational D. Saucez (Ed.) 5 Expires: May 16, 2015 INRIA 6 November 12, 2014 8 An Architectural Introduction to the Locator/ID Separation Protocol 9 (LISP) 10 draft-ietf-lisp-introduction-09.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 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 16, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 63 3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 4 65 3.2. Overview of the Architecture . . . . . . . . . . . . . . 5 66 3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 8 68 3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 9 69 3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 9 70 3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 10 71 3.4.2. Mapping System Interface . . . . . . . . . . . . . . 10 72 3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 11 73 3.5. Interworking Mechanisms . . . . . . . . . . . . . . . . . 14 74 4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 14 75 4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 15 76 4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 15 77 4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 17 78 4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 17 79 5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 82 8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 8.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 20 84 8.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 20 85 8.3. LISP for Virtual Private Networks . . . . . . . . . . . . 21 86 8.4. LISP for Virtual Machine Mobility in Data Centers . . . . 21 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 89 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 92 12.2. Informative References . . . . . . . . . . . . . . . . . 23 93 Appendix A. A Brief History of Location/Identity Separation . . 25 94 A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 25 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 97 1. Introduction 99 This document introduces the Locator/ID Separation Protocol (LISP) 100 [RFC6830] architecture, its main operational mechanisms and its 101 design rationale. Fundamentally, LISP is built following a well- 102 known architectural idea: decoupling the IP address overloaded 103 semantics. Indeed and as pointed out by [Chiappa], currently IP 104 addresses both identify the topological location of a network 105 attachment point as well as the node's identity. However, nodes and 106 routing have fundamentally different requirements, routing systems 107 require that addresses are aggregatable and have topological meaning, 108 while nodes require to be identified independently of their current 109 location [RFC4984]. 111 LISP creates two separate namespaces, EIDs (End-host IDentifiers) and 112 RLOCs (Routing LOCators), both are typically syntactically identical 113 to the current IPv4 and IPv6 addresses. EIDs are used to uniquely 114 identify nodes irrespective of their topological location and are 115 typically routed intra-domain. RLOCs are assigned topologically to 116 network attachment points and are typically routed inter-domain. 117 With LISP, the edge of the Internet (where the nodes are connected) 118 and the core (where inter-domain routing occurs) can be logically 119 separated and interconnected by LISP-capable routers. LISP also 120 introduces a database, called the Mapping System, to store and 121 retrieve mappings between identity and location. LISP-capable 122 routers exchange packets over the Internet core by encapsulating them 123 to the appropriate location. 125 In summary: 127 o RLOCs have meaning only in the underlay network 129 o EIDs have meaning only in the overlay network (unless they are 130 leaked into the underlay network) 132 o The LISP edge maps EIDs to RLOCs 134 o Within the underlay network, RLOCs have both locator and 135 identifier semantics 137 o An EID within a LISP site carries both identifier and locator 138 semantics to other nodes within that site 140 o An EID within a LISP site carries identifier and limited locator 141 semantics to nodes at other LISP sites (i.e., enough locator 142 information to tell that the EID is external to the site) 144 The relationship described above is not unique to LISP but it is 145 common to other overlay technologies. 147 The initial motivation in the LISP effort is to be find in the 148 routing scalability problem [RFC4984], where, if LISP is completely 149 deployed, the Internet core is populated with RLOCs while Traffic 150 Engineering mechanisms are pushed to the Mapping System. In such 151 scenario RLOCs are quasi-static (i.e., low churn), hence making the 152 routing system scalable [Quoitin], while EIDs can roam anywhere with 153 no churn to the underlying routing system. [RFC7215] discusses the 154 impact of LISP on the global routing system during the transition 155 period. However, the separation between location and identity that 156 LISP offers makes it suitable for use in additional scenarios such as 157 Traffic Engineering (TE), multihoming, and mobility among others. 159 This document describes the LISP architecture, its main operational 160 mechanisms as its design rationale. It is important to note that 161 this document does not specify or complement the LISP protocol. The 162 interested reader should refer to the main LISP specifications 163 [RFC6830] and the complementary documents [RFC6831], [RFC6832], 164 [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC7052] for the 165 protocol specifications along with the LISP deployment guidelines 166 [RFC7215]. 168 2. Definition of Terms 170 This document describes the LISP architecture and does not define or 171 introduce any new term. The reader is referred to [RFC6830], 172 [RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], 173 [RFC7052], [RFC7215] for the LISP definition of terms. 175 3. LISP Architecture 177 This section presents the LISP architecture, it first details the 178 design principles of LISP and then it proceeds to describe its main 179 aspects: data-plane, control-plane, and inetrworking mechanisms. 181 3.1. Design Principles 183 The LISP architecture is built on top of four basic design 184 principles: 186 o Locator/Identifier split: By decoupling the overloaded semantics 187 of the current IP addresses the Internet core can be assigned 188 identity meaningful addresses and hence, can use aggregation to 189 scale. Devices are assigned with relatively opaque identity 190 meaningful addresses that are independent of their topological 191 location. 193 o Overlay architecture: Overlays route packets over the current 194 Internet, allowing deployment of new protocols without changing 195 the current infrastructure hence, resulting into a low deployment 196 cost. 198 o Decoupled data and control-plane: Separating the data-plane from 199 the control-plane allows them to scale independently and use 200 different architectural approaches. This is important given that 201 they typically have different requirements and allows for other 202 data-planes to be added. While decoupled, data and control-plane 203 are not completely isolated because the LISP data-plane may 204 trigger control-plane activity. 206 o Incremental deployability: This principle ensures that the 207 protocol interoperates with the legacy Internet while providing 208 some of the targeted benefits to early adopters. 210 3.2. Overview of the Architecture 212 LISP splits architecturally the core from the edge of the Internet by 213 creating two separate namespaces: Endpoint Identifiers (EIDs) and 214 Routing LOCators (RLOCs). The edge consists of LISP sites (e.g., an 215 Autonomous System) that use EID addresses. EIDs are typically -but 216 not limited to- IPv4 or IPv6 addresses that uniquely identify 217 communication end-hosts and are assigned and configured by the same 218 mechanisms that exist at the time of this writing. EIDs do not 219 contain inter-domain topological information and can be thought as an 220 analogy to Provider Independent (PI [RFC4116]) addresses. Because of 221 this, EIDs are usually only routable at the edge with a LISP site. 223 With LISP, LISP sites (edge) and the core of the Internet are 224 interconnected by means of LISP-capable routers (e.g., border 225 routers) using tunnels. When packets originated from a LISP site are 226 flowing towards the core network, they ingress into an encapsulated 227 tunnel via an Ingress Tunnel Router (ITR). When packets flow from 228 the core network to a LISP site, they egress from an encapsulated 229 tunnel to an Egress Tunnel Router (ETR). An xTR is a router which 230 can perform both ITR and ETR operations. In this context ITRs 231 encapsulate packets while ETRs decapsulate them, hence LISP operates 232 as an overlay on top of the current Internet core. 234 /-----------------\ --- 235 | Mapping | | 236 . System | | Control 237 -| |`, | Plane 238 ,' \-----------------/ . | 239 / \ --- 240 ,.., - _,..--..,, `, ,.., | 241 / ` ,' ,-` `', . / ` | 242 / \ +-----+ ,' `, +--'--+ / \ | 243 | EID |-| xTR |---/ RLOC ,---| xTR |-| EID | | Data 244 | Space |-| |---| Space |---| |-| Space | | Plane 245 \ / +-----+ . / +-----+ \ / | 246 `. .' `. ,' `. .' | 247 `'-` `., ,.' `'-` --- 248 ``''--''`` 249 LISP Site (Edge) Core LISP Site (Edge) 251 Figure 1.- A schema of the LISP Architecture 253 With LISP, the core uses RLOCs, an RLOC is typically -but not limited 254 to- an IPv4 or IPv6 address assigned to an Internet-facing network 255 interface of an ITR or ETR. Typically RLOCs are numbered from 256 topologically aggregatable blocks assigned to a site at each point to 257 which it attaches to the global Internet. The topology is defined by 258 the connectivity of networks, in this context RLOCs can be thought of 259 Provider Aggregatable addresses [RFC4116]. 261 A typically distributed database, called the Mapping System, stores 262 mappings between EIDs and RLOCs. Such mappings relate the identity 263 of the devices attached to LISP sites (EIDs) to the set of RLOCs 264 configured at the LISP-capable routers servicing the site. 265 Furthermore, the mappings also include traffic engineering policies 266 and can be configured to achieve multihoming and load balancing. The 267 LISP Mapping System is conceptually similar to the DNS where it is 268 organized as a distributed multi-organization network database. With 269 LISP, ETRs register mappings while ITRs retrieve them. 271 Finally, the LISP architecture emphasizes a cost effective 272 incremental deployment. Given that LISP represents an overlay to the 273 current Internet architecture, endhosts as well as intra and inter- 274 domain routers remain unchanged, and the only required changes to the 275 existing infrastructure are to routers connecting the EID with the 276 RLOC space. Such LISP capable routers, in most cases, only require a 277 software upgrade. Additionally, LISP requires the deployment of an 278 independent Mapping System, such distributed database is a new 279 network entity. 281 The following describes a simplified packet flow sequence between two 282 nodes that are attached to LISP sites. Client HostA wants to send a 283 packet to server HostB. 285 /----------------\ 286 | Mapping | 287 | System | 288 .| |- 289 ` \----------------/ `. 290 ,` \ 291 / `. 292 ,' _,..-..,, ', 293 / -` `-, \ 294 .' ,' \ `, 295 ` ' \ ' 296 +-----+ | | RLOC_B1+-----+ 297 HostA | | | RLOC |-------| | HostB 298 EID_A--|ITR_A|----| Space | |ETR_B|--EID_B 299 | | RLOC_A1 |-------| | 300 +-----+ | | RLOC_B2+-----+ 301 , / 302 \ / 303 `', ,-` 304 ``''-''`` 306 Figure 2.- Packet flow sequence in LISP 308 1. HostA retrieves the EID_B of HostB (typically querying the DNS) 309 and generates an IP packet as in the Internet, the packet has 310 source address EID_A and destination address EID_B. 312 2. The packet is routed towards ITR_A in the LISP site using 313 standard intra-domain mechanisms. 315 3. ITR_A upon receiving the packet queries the Mapping System to 316 retrieve the locator of ETR_B that is servicing HostB's EID_B. 317 In order to do so it uses a LISP control message called Map- 318 Request, the message contains EID_B as the lookup key. In turn 319 it receives another LISP control message called Map-Reply, the 320 message contains two locators: RLOC_B1 and RLOC_B2 along with 321 traffic engineering policies: priority and weight per locator. 322 ITR_A also stores the mapping in a local cache to speed-up 323 forwarding of subsequent packets. 325 4. ITR_A encapsulates the packet towards RLOC_B1 (chosen according 326 to the priorities/weights specified in the mapping). The packet 327 contains two IP headers, the outer header has RLOC_A1 as source 328 and RLOC_B2 as destination, the inner original header has EID_A 329 as source and EID_B as destination. Furthermore ITR_A adds a 330 LISP header, more details about LISP encapsulation can be found 331 in Section 3.3.1. 333 5. The encapsulated packet is forwarded by the Internet core as a 334 normal IP packet, making the EID invisible from the Internet 335 core. 337 6. Upon reception of the encapsulated packet by ETR_B, it 338 decapsulates the packet and forwards it to HostB. 340 3.3. Data-Plane 342 This section provides a high-level description of the LISP data- 343 plane, which is specified in detail in [RFC6830]. The LISP data- 344 plane is responsible for encapsulating and decapsulating data packets 345 and caching the appropriate forwarding state. It includes two main 346 entities, the ITR and the ETR, both are LISP capable routers that 347 connect the EID with the RLOC space (ITR) and vice versa (ETR). 349 3.3.1. LISP Encapsulation 351 ITRs encapsulate data packets towards ETRs. LISP data packets are 352 encapsulated using UDP (port 4341). A particularity of LISP is that 353 UDP packets should include a zero checksum [RFC6935] [RFC6936] that 354 it is not verified in reception, LISP also supports non-zero 355 checksums that may be verified. This decision was made because the 356 typical transport protocols used by the applications already include 357 a checksum, by neglecting the additional UDP encapsulation checksum 358 xTRs can forward packets more efficiently. 360 LISP-encapsulated packets also include a LISP header (after the UDP 361 header and before the original IP header). The LISP header is 362 prepended by ITRs and striped by ETRs. It carries reachability 363 information (see more details in Section 4.2) and the Instance ID 364 field. The Instance ID field is used to distinguish traffic to/from 365 different tenant address spaces at the LISP site and that may use 366 overlapped but logically separated EID addressing. 368 Overall, LISP works on 4 headers, the inner header the source 369 constructed, and the 3 headers a LISP encapsulator prepends ("outer" 370 to "inner"): 372 1. Outer IP header containing RLOCs as source and destination 373 addresses. This header is originated by ITRs and stripped by 374 ETRs. 376 2. UDP header (port 4341) with zero checksum. This header is 377 originated by ITRs and stripped by ETRs. 379 3. LISP header that contains various forwarding-plane features (such 380 as reachability) and an Instance ID field. This header is 381 originated by ITRs and stripped by ETRs. 383 4. Inner IP header containing EIDs as source and destination 384 addresses. This header is created by the source end-host and is 385 left unchanged by LISP data plane processing on the ITR and ETR. 387 Finally, in some scenarios Recursive and/or Re-encapsulating tunnels 388 can be used for Traffic Engineering and re-routing. Re-encapsulating 389 tunnels are consecutive LISP tunnels and occur when a decapsulator 390 (an ETR action) removes a LISP header and then acts as an encapsultor 391 (an ITR action) to prepend another one. On the other hand, Recursive 392 tunnels are nested tunnels and are implemented by using multiple LISP 393 encapsulations on a packet. Typically such functions are implemented 394 by Reencapsulating Tunnel Routers (RTRs). 396 3.3.2. LISP Forwarding State 398 In the LISP architecture, ITRs keep just enough information to route 399 traffic flowing through it. Meaning that, ITRs retrieve from the 400 LISP Mapping System mappings between EID prefixes and RLOCs that are 401 used to encapsulate packets. Such mappings are stored in a local 402 cache called the Map-Cache for subsequent packets addressed to the 403 same EID prefix. Note that, in case of overlapping EID-prefixes, 404 following a single request, the ITR may receive a set of mappings, 405 covering the requested EID-prefix and all more-specifics (cf., 406 Section 6.1.5 [RFC6830]). Mappings include a (Time-to-Live) TTL (set 407 by the ETR). More details about the Map-Cache management can be 408 found in Section 4.1. 410 3.4. Control-Plane 412 The LISP control-plane, specified in [RFC6833], provides a standard 413 interface to register and request mappings. The LISP Mapping System 414 is a database that stores such mappings. The following first 415 describes the mappings, then the standard interface to the Mapping 416 System, and finally its architecture. 418 3.4.1. LISP Mappings 420 Each mapping includes the bindings between EID prefix(es) and set of 421 RLOCs as well as traffic engineering policies, in the form of 422 priorities and weights for the RLOCs. Priorities allow the ETR to 423 configure active/backup policies while weights are used to load- 424 balance traffic among the RLOCs (on a per-flow basis). 426 Typical mappings in LISP bind EIDs in the form of IP prefixes with a 427 set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses are 428 encoded using the appropriate Address Family Identifier (AFI) 429 [RFC3232]. However LISP can also support more general address 430 encoding by means of the ongoing effort around the LISP Canonical 431 Address Format (LCAF) [I-D.ietf-lisp-lcaf]. 433 With such a general syntax for address encoding in place, LISP aims 434 to provide flexibility to current and future applications. For 435 instance LCAFs could support MAC addresses, geo-coordinates, ASCII 436 names and application specific data. 438 3.4.2. Mapping System Interface 440 LISP defines a standard interface between data and control planes. 441 The interface is specified in [RFC6833] and defines two entities: 443 Map-Server: A network infrastructure component that learns mappings 444 from ETRs and publishes them into the LISP Mapping System. 445 Typically Map-Servers are not authoritative to reply to queries 446 and hence, they forward them to the ETR. However they can also 447 operate in proxy-mode, where the ETRs delegate replying to queries 448 to Map-Servers. This setup is useful when the ETR has limited 449 resources (i.e., CPU or power). 451 Map-Resolver: A network infrastructure component that interfaces 452 ITRs with the Mapping System by proxying queries and in some cases 453 responses. 455 The interface defines four LISP control messages which are sent as 456 UDP datagrams (port 4342): 458 Map-Register: This message is used by ETRs to register mappings in 459 the Mapping System and it is authenticated using a shared key 460 between the ETR and the Map-Server. 462 Map-Notify: When requested by the ETR, this message is sent by the 463 Map-Server in response to a Map-Register to acknowledge the 464 correct reception of the mapping and convey the latest Map-Server 465 state on the EID to RLOC mapping. In some cases a Map-Notify can 466 be sent to the previous RLOCs when an EID is registered by a new 467 set of RLOCs. 469 Map-Request: This message is used by ITRs or Map-Resolvers to 470 resolve the mapping of a given EID. 472 Map-Reply: This message is sent by Map-Servers or ETRs in response 473 to a Map-Request and contains the resolved mapping. Please note 474 that a Map-Reply may contain a negative reply if, for example, the 475 queried EID is not part of the LISP EID space. In such cases the 476 ITR typically forwards the traffic natively (non encapsulated) to 477 the public Internet, this behavior is defined to support 478 incremental deployment of LISP. 480 3.4.3. Mapping System 482 LISP architecturally decouples control and data-plane by means of a 483 standard interface. This interface glues the data-plane, routers 484 responsible for forwarding data-packets, with the LISP Mapping 485 System, a database responsible for storing mappings. 487 With this separation in place the data and control-plane can use 488 different architectures if needed and scale independently. Typically 489 the data-plane is optimized to route packets according to 490 hierarchical IP addresses. However the control-plane may have 491 different requirements, for instance and by taking advantage of the 492 LCAFs, the Mapping System may be used to store non-hierarchical keys 493 (such as MAC addresses), requiring different architectural approaches 494 for scalability. Another important difference between the LISP 495 control and data-planes is that, and as a result of the local mapping 496 cache available at ITR, the Mapping System does not need to operate 497 at line-rate. 499 The LISP WG has explored application of the following distributed 500 system techniques to the Mapping System architecture: graph-based 501 databases in the form of LISP+ALT [RFC6836], hierarchical databases 502 in the form of LISP-DDT [I-D.ietf-lisp-ddt], monolithic databases in 503 the form of LISP-NERD [RFC6837], flat databases in the form of LISP- 504 DHT [I-D.cheng-lisp-shdht],[I-D.mathy-lisp-dht] and, a multicast- 505 based database [I-D.curran-lisp-emacs]. Furthermore it is worth 506 noting that, in some scenarios such as private deployments, the 507 Mapping System can operate as logically centralized. In such cases 508 it is typically composed of a single Map-Server/Map-Resolver. 510 The following focuses on the two mapping systems that have been 511 implemented and deployed (LISP-ALT and LISP+DDT). 513 3.4.3.1. LISP+ALT 515 The LISP Alternative Topology (LISP+ALT) [RFC6836] was the first 516 Mapping System proposed, developed and deployed on the LISP pilot 517 network. It is based on a distributed BGP overlay participated by 518 Map-Servers and Map-Resolvers. The nodes connect to their peers 519 through static tunnels. Each Map-Server involved in the ALT topology 520 advertises the EID-prefixes registered by the serviced ETRs, making 521 the EID routable on the ALT topology. 523 When an ITR needs a mapping it sends a Map-Request to a Map-Resolver 524 that, using the ALT topology, forwards the Map-Request towards the 525 Map-Server responsible for the mapping. Upon reception the Map- 526 Server forwards the request to the ETR that in turn, replies directly 527 to the ITR using the native Internet core. 529 3.4.3.2. LISP-DDT 531 LISP-DDT [I-D.ietf-lisp-ddt] is conceptually similar to the DNS, a 532 hierarchical directory whose internal structure mirrors the 533 hierarchical nature of the EID address space. The DDT hierarchy is 534 composed of DDT nodes forming a tree structure, the leafs of the tree 535 are Map-Servers. On top of the structure there is the DDT root node 536 [DDT-ROOT], which is a particular instance of a DDT node and that 537 matches the entire address space. As in the case of DNS, DDT 538 supports multiple redundant DDT nodes and/or DDT roots. Finally, 539 Map-Resolvers are the clients of the DDT hierarchy and can query 540 either the DDT root and/or other DDT nodes. 542 /---------\ 543 | | 544 | DDT Root| 545 | /0 | 546 ,.\---------/-, 547 ,-'` | `'., 548 -'` | `- 549 /-------\ /-------\ /-------\ 550 | DDT | | DDT | | DDT | 551 | Node | | Node | | Note | ... 552 | 0/8 | | 1/8 | | 2/8 | 553 \-------/ \-------/ \-------/ 554 _. _. . -..,,,_ 555 -` -` \ ````''-- 556 +------------+ +------------+ +------------+ +------------+ 557 | Map-Server | | Map-Server | | Map-Server | | Map-Server | 558 | EID-prefix1| | EID-prefix2| | EID-prefix3| | EID-prefix4| 559 +------------+ +------------+ +------------+ +------------+ 561 Figure 3.- A schematic representation of the DDT tree structure, 562 please note that the prefixes and the structure depicted 563 should be only considered as an example. 565 The DDT structure does not actually index EID-prefixes but eXtended 566 EID-prefixes (XEID). An XEID-prefix is just the concatenation of the 567 following fields (from most significant bit to less significant bit): 568 Database-ID, Instance ID, Address Family Identifier and the actual 569 EID-prefix. The Database-ID is provided for possible future 570 requirements of higher levels in the hierarchy and to enable the 571 creation of multiple and separate database trees. 573 In order to resolve a query LISP-DDT operates in a similar way to the 574 DNS but only supports iterative lookups. DDT clients (usually Map- 575 Resolvers) generate Map-Requests to the DDT root node. In response 576 they receive a newly introduced LISP-control message: a Map-Referral. 577 A Map-Referral provides the list of RLOCs of the set of DDT nodes 578 matching a configured XEID delegation. That is, the information 579 contained in the Map-Referral points to the child of the queried DDT 580 node that has more specific information about the queried XEID- 581 prefix. This process is repeated until the DDT client walks the tree 582 structure (downwards) and discovers the Map-Server servicing the 583 queried XEID. At this point the client sends a Map-Request and 584 receives a Map-Reply containing the mappings. It is important to 585 note that DDT clients can also cache the information contained in 586 Map-Referrals, that is, they cache the DDT structure. This is used 587 to reduce the mapping retrieving latency[Jakab]. 589 The DDT Mapping System relies on manual configuration. That is Map- 590 Resolvers are manually configured with the set of available DDT root 591 nodes while DDT nodes are manually configured with the appropriate 592 XEID delegations. Configuration changes in the DDT nodes are only 593 required when the tree structure changes itself, but it doesn't 594 depend on EID dynamics (RLOC allocation or traffic engineering policy 595 changes). 597 3.5. Interworking Mechanisms 599 EIDs are typically identical to either IPv4 or IPv6 addresses and 600 they are stored in the LISP Mapping System, however they are usually 601 not announced in the Internet global routing system. As a result 602 LISP requires an inetrworking mechanism to allow LISP sites to speak 603 with non-LISP sites and vice versa. LISP inetrworking mechanisms are 604 specified in [RFC6832]. 606 LISP defines two entities to provide inetrworking: 608 Proxy Ingress Tunnel Router (PITR): PITRs provide connectivity from 609 the legacy Internet to LISP sites. PITRs announce in the global 610 routing system blocks of EID prefixes (aggregating when possible) 611 to attract traffic. For each incoming packet from a source not in 612 a LISP site (a non-EID), the PITR LISP-encapsulates it towards the 613 RLOC(s) of the appropriate LISP site. The impact of PITRs in the 614 routing table size of the DFZ is, in the worst-case, similar to 615 the case in which LISP is not deployed. EID-prefixes will be 616 aggregated as much as possible both by the PITR and by the global 617 routing system. 619 Proxy Egress Tunnel Router (PETR): PETRs provide connectivity from 620 LISP sites to the legacy Internet. In some scenarios, LISP sites 621 may be unable to send encapsulated packets with a local EID 622 address as a source to the legacy Internet. For instance when 623 Unicast Reverse Path Forwarding (uRPF) is used by Provider Edge 624 routers, or when an intermediate network between a LISP site and a 625 non-LISP site does not support the desired version of IP (IPv4 or 626 IPv6). In both cases the PETR overcomes such limitations by 627 encapsulating packets over the network. There is no specified 628 provision for the distribution of PETR RLOC addresses to the ITRs. 630 4. LISP Operational Mechanisms 632 This section details the main operational mechanisms defined in LISP. 634 4.1. Cache Management 636 LISP's decoupled control and data-plane, where mappings are stored in 637 the control-plane and used for forwarding in the data plane, requires 638 of a local cache in ITRs to reduce signaling overhead (Map-Request/ 639 Map-Reply) and increase forwarding speed. The local cache available 640 at the ITRs, called Map-Cache, is used by the router to LISP- 641 encapsulate packets. The Map-Cache is indexed by (Instance ID, EID- 642 prefix) and contains basically the set of RLOCs with the associated 643 traffic engineering policies (priorities and weights). 645 The Map-Cache, as any other cache, requires cache coherence 646 mechanisms to maintain up-to-date information. LISP defines three 647 main mechanisms for cache coherence: 649 Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon 650 expiration of the TTL the ITR has to refresh the mapping by 651 sending a new Map-Request. Typical values for TTL defined by LISP 652 are 24 hours. 654 Solicit-Map-Request (SMR): SMR is an explicit mechanism to update 655 mapping information. In particular a special type of Map-Request 656 can be sent on demand by ETRs to request refreshing a mapping. 657 Upon reception of a SMR message, the ITR must refresh the bindings 658 by sending a Map-Request to the Mapping System. 660 Map-Versioning: This optional mechanism piggybacks in the LISP 661 header of data-packets the version number of the mappings used by 662 an xTR. This way, when an xTR receives a LISP-encapsulated packet 663 from a remote xTR, it can check whether its own Map-Cache or the 664 one of the remote xTR is outdated. If its Map-Cache is outdated, 665 it sends a Map-Request for the remote EID so to obtain the newest 666 mappings. On the contrary, if it detects that the remote xTR Map- 667 Cache is outdated, it sends a SMR to notify it that a new mapping 668 is available. 670 Finally it is worth noting that in some cases an entry in the map- 671 cache can be proactively refreshed using the mechanisms described in 672 the section below. 674 4.2. RLOC Reachability 676 The LISP architecture is an edge to edge pull architecture, where the 677 network state is stored in the control-plane while the data-plane 678 pulls it on demand. This has consequences concerning the propagation 679 of xTRs reachability/liveness information. On the contrary BGP is a 680 push architecture, where the required network state is pushed by 681 means of BGP UPDATE messages to BGP speakers. In push architectures, 682 reachability information is also pushed to the interested routers. 683 However pull architectures require explicit mechanisms to propagate 684 reachability information. LISP defines a set of mechanisms to inform 685 ITRs and PITRS about the reachability of the cached RLOCs: 687 Locator Status Bits (LSB): LSB is a passive technique, the LSB field 688 is carried by data-packets in the LISP header and can be set by a 689 ETRs to specify which RLOCs of the ETR site are up/down. This 690 information can be used by the ITRs as a hint about the reachability 691 to perform additional checks. Also note that LSB does not provide 692 path reachability status, only hints on the status of RLOCs. 694 Echo-nonce: This is also a passive technique, that can only operate 695 effectively when data flows bi-directionally between two 696 communicating xTRs. Basically, an ITR piggybacks a random number 697 (called nonce) in LISP data packets, if the path and the probed 698 locator are up, the ETR will piggyback the same random number on the 699 next data-packet, if this is not the case the ITR can set the locator 700 as unreachable. When traffic flow is unidirectional or when the ETR 701 receiving the traffic is not the same as the ITR that transmits it 702 back, additional mechanisms are required. 704 RLOC-probing: This is an active probing algorithm where ITRs send 705 probes to specific locators, this effectively probes both the locator 706 and the path. In particular this is done by sending a Map-Request 707 (with certain flags activated) on the data-plane (RLOC space) and 708 waiting in return a Map-Reply, also sent on the data-plane. The 709 active nature of RLOC-probing provides an effective mechanism to 710 determine reachability and, in case of failure, switching to a 711 different locator. Furthermore the mechanism also provides useful 712 RTT estimates of the delay of the path that can be used by other 713 network algorithms. 715 Additionally, LISP also recommends inferring reachability of locators 716 by using information provided by the underlay, in particular: 718 It is worth noting that RLOC probing and Echo-nonce can work 719 together. Specifically if a nonce is not echoed, an ITR could RLOC- 720 probe to determine if the path is up when it cannot tell the 721 difference between a failed bidirectional path or the return path is 722 not used (a unidirectional path). 724 ICMP signaling: The LISP underlay -the current Internet- uses the 725 ICMP protocol to signal unreachability (among other things). LISP 726 can take advantage of this and the reception of a ICMP Network 727 Unreachable or ICMP Host Unreachable message can be seen as a hint 728 that a locator might be unreachable, this should lead to perform 729 additional checks. 731 Underlay routing: Both BGP and IBGP carry reachability information, 732 LISP-capable routers that have access to underlay routing information 733 can use it to determine if a given locator or path are reachable. 735 4.3. ETR Synchronization 737 All the ETRs that are authoritative to a particular EID-prefix must 738 announce the same mapping to the requesters, this means that ETRs 739 must be aware of the status of the RLOCs of the remaining ETRs. This 740 is known as ETR synchronization. 742 At the time of this writing LISP does not specify a mechanism to 743 achieve ETR synchronization. Although many well-known techniques 744 could be applied to solve this issue it is still under research, as a 745 result operators must rely on coherent manual configuration 747 4.4. MTU Handling 749 Since LISP encapsulates packets it requires dealing with packets that 750 exceed the MTU of the path between the ITR and the ETR. Specifically 751 LISP defines two mechanisms: 753 Stateless: With this mechanism the effective MTU is assumed from the 754 ITR's perspective. If a payload packet is too big for the 755 effective MTU, and can be fragmented, the payload packet is 756 fragmented on the ITR, such that reassembly is performed at the 757 destination host. 759 Stateful: With this mechanism ITRs keep track of the MTU of the 760 paths towards the destination locators by parsing the ICMP Too Big 761 packets sent by intermediate routers. Additionally ITRs will send 762 ICMP Too Big messages to inform the sources about the effective 763 MTU. 765 In both cases if the packet cannot be fragmented (IPv4 with DF=1 or 766 IPv6) then the ITR drops it and replies with a ICMP Too Big message 767 to the source. 769 5. Mobility 771 The separation between locators and identifiers in LISP was initially 772 proposed for traffic engineering purpose where LISP sites can change 773 their attachment points to the Internet (i.e., RLOCs) without 774 impacting endpoints or the Internet core. In this context, the 775 border routers operate the xTR functionality and endpoints are not 776 aware of the existence of LISP. However, this mode of operation does 777 not allow seamless mobility of endpoints between different LISP sites 778 as the EID address might not be routable in a visited site. 780 Nevertheless, LISP can be used to enable seamless IP mobility when 781 LISP is directly implemented in the endpoint or when the endpoint 782 roams to an attached xTR. Each endpoint is then an xTR and the EID 783 address is the one presented to the network stack used by 784 applications while the RLOC is the address gathered from the network 785 when it is visited. 787 Whenever the device changes of RLOC, the xTR updates the RLOC of its 788 local mapping and registers it to its Map-Server. To avoid the need 789 of a home gateway, the ITR also indicates the RLOC change to all 790 remote devices that have ongoing communications with the device that 791 moved. The combination of both methods ensures the scalability of 792 the system as signaling is strictly limited the Map-Server and to 793 hosts with which communications are ongoing. 795 6. Multicast 797 LISP also supports transporting IP multicast packets sent from the 798 EID space, the operational changes required to the multicast 799 protocols are documented in [RFC6831]. 801 In such scenarios, LISP may create multicast state both at the core 802 and at the sites (both source and receiver). When signaling is used 803 to create multicast state at the sites, LISP routers unicast 804 encapsulate PIM Join/Prune messages from receiver to source sites. 805 At the core, ETRs build a new PIM Join/Prune message addressed to the 806 RLOC of the ITR servicing the source. An simplified sequence is 807 shown below 809 1. An end-host willing to join a multicast channel sends an IGMP 810 report. Multicast PIM routers at the LISP site propagate PIM 811 Join/Prune messages (S-EID, G) towards the ETR. 813 2. The join message flows to the ETR, upon reception the ETR builds 814 two join messages, the first one unicast LISP-encapsulates the 815 original join message towards the RLOC of the ITR servicing the 816 source. This message creates (S-EID, G) multicast state at the 817 source site. The second join message contains as destination 818 address the RLOC of the ITR servicing the source (S-RLOC, G) and 819 creates multicast state at the core. 821 3. Multicast data packets originated by the source (S-EID, G) flow 822 from the source to the ITR. The ITR LISP-encapsulates the 823 multicast packets, the outter header includes its own RLOC as the 824 source (S-RLOC) and the original multicast group address (G) as 825 the destination. Please note that multicast group address are 826 logical and are not resolved by the mapping system. Then the 827 multicast packet is transmitted through the core towards the 828 receiving ETRs that decapsulates the packets and sends them using 829 the receiver's site multicast state. 831 LISP can also support non-PIM mechanisms to maintain multicast state. 833 7. Security Considerations 835 LISP uses a pull architecture to learn mappings. While in a push 836 system, the state necessary to forward packets is learned 837 independently of the traffic itself, with a pull architecture, the 838 system becomes reactive and data-plane events (e.g., the arrival of a 839 packet for an unknown destination) may trigger control-plane events. 840 This on-demand learning of mappings provides many advantages as 841 discussed above but may also affect the way security is enforced. 843 Usually, the data-plane is implemented in the fast path of routers to 844 provide high performance forwarding capabilities while the control- 845 plane features are implemented in the slow path to offer high 846 flexibility and a performance gap of several order of magnitude can 847 be observed between the slow and the fast paths. As a consequence, 848 the way data-plane events are notified to the control-plane must be 849 thought carefully so to not overload the slow path and rate limiting 850 should be used as specified in [RFC6830]. 852 Care must also be taken so to not overload the mapping system (i.e., 853 the control plane infrastructure) as the operations to be performed 854 by the mapping system may be more complex than those on the data- 855 plane, for that reason [RFC6830] recommends to rate limit the sending 856 of messages to the mapping system. 858 To improve resiliency and reduce the overall number of messages 859 exchanged, LISP offers the possibility to leak information, such as 860 reachabilty of locators, directly into data plane packets. In 861 environments that are not fully trusted, control informations gleaned 862 from data-plane packets should be verified before using them. 864 Mappings are the centrepiece of LISP and all precautions must be 865 taken to avoid them to be manipulated or misused by malicious 866 entities. Using trustable Map-Servers that strictly respect 867 [RFC6833] and the lightweight authentication mechanism proposed by 868 LISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks to the 869 mapping integrity. In more critical environments, secure measures 870 may be needed. 872 As with any other tunneling mechanism, middleboxes on the path 873 between an ITR (or PITR) and an ETR (or PETR) must implement 874 mechanisms to strip the LISP encapsulation to correctly inspect the 875 content of LISP encapsulated packets. 877 Like other map-and-encap mechanisms, LISP enables triangular routing 878 (i.e., packets of a flow cross different border routers depending on 879 their direction). This means that intermediate boxes may have 880 incomplete view on the traffic they inspect or manipulate. 882 More details about security implications of LISP are discussed in 883 [I-D.ietf-lisp-threats]. 885 8. Use Cases 887 8.1. Traffic Engineering 889 BGP is the standard protocol to implement inter-domain routing. With 890 BGP, routing informations are propagated along the network and each 891 autonomous system can implement its own routing policy that will 892 influence the way routing information are propagated. The direct 893 consequence is that an autonomous system cannot precisely control the 894 way the traffic will enter the network. 896 As opposed to BGP, a LISP site can strictly impose via which ETRs the 897 traffic must enter the the LISP site network even though the path 898 followed to reach the ETR is not under the control of the LISP site. 899 This fine control is implemented with the mappings. When a remote 900 site is willing to send traffic to a LISP site, it retrieves the 901 mapping associated to the destination EID via the mapping system. 902 The mapping is sent directly by an authoritative ETR of the EID and 903 is not altered by any intermediate network. 905 A mapping associates a list of RLOCs to an EID prefix. Each RLOC 906 corresponds to an interface of an ETR (or set of ETRs) that is able 907 to correctly forward packets to EIDs in the prefix. Each RLOC is 908 tagged with a priority and a weight in the mapping. The priority is 909 used to indicates which RLOCs should be preferred to send packets 910 (the least preferred ones being provided for backup purpose). The 911 weight permits to balance the load between the RLOCs with the same 912 priority, proportionally to the weight value. 914 As mappings are directly issued by the authoritative ETR of the EID 915 and are not altered while transmitted to the remote site, it offers 916 highly flexible incoming inter-domain traffic engineering with even 917 the possibility for a site to issue a different mapping for each 918 remote site, implementing so precise routing policies. 920 8.2. LISP for IPv6 Co-existence 922 LISP encapsulations allows to transport packets using EIDs from a 923 given address family (e.g., IPv6) with packets from other address 924 families (e.g., IPv4). The absence of correlation between the 925 address family of RLOCs and EIDs makes LISP a candidate to allow, 926 e.g., IPv6 to be deployed when all of the core network may not have 927 IPv6 enabled. 929 For example, two IPv6-only data centers could be interconnected via 930 the legacy IPv4 Internet. If their border routers are LISP capable, 931 sending packets between the data center is done without any form of 932 translation as the native IPv6 packets (in the EID space) will be 933 LISP encapsulated and transmitted over the IPv4 legacy Internet by 934 the mean of IPv4 RLOCs. 936 8.3. LISP for Virtual Private Networks 938 It is common to operate several virtual networks over the same 939 physical infrastructure. In such virtual private networks, it is 940 essential to distinguish which virtual network a packet belongs and 941 tags or labels are used for that purpose. When using LISP, the 942 distinction can be made with the Instance ID field. When an ITR 943 encapsulates a packet from a particular virtual network (e.g., known 944 via the VRF or VLAN), it tags the encapsulated packet with the 945 Instance ID corresponding to the virtual network of the packet. When 946 an ETR receives a packet tagged with an Instance ID it uses the 947 Instance ID to determine how to treat the packet. 949 The main usage of LISP for virtual private networks does not 950 introduce additional requirements on the underlying network, as long 951 as it is running IP. 953 8.4. LISP for Virtual Machine Mobility in Data Centers 955 A way to enable seamless virtual machine mobility in data center is 956 to conceive the datacenter backbone as the RLOC space and the subnet 957 where servers are hosted as forming the EID space. A LISP router is 958 placed at the border between the backbone and each subnet. When a 959 virtual machine is moved to another subnet, it can keep (temporarily) 960 the address it had before the move so to continue without a transport 961 layer connection reset. When an xTR detects a source address 962 received on a subnet to be an address not assigned to the subnet, it 963 registers the address to the Mapping System. 965 To inform the other LISP routers that the machine moved and where, 966 and then to avoid detours via the initial subnetwork, mechanisms such 967 as the Solicit-Map-Request messages are used. 969 9. Security Considerations 971 This document does not specify any protocol or operational practices 972 and hence, does not have any security considerations. 974 10. IANA Considerations 976 This memo includes no request to IANA. 978 11. Acknowledgements 980 This document was initiated by Noel Chiappa and much of the core 981 philosophy came from him. The authors acknowledge the important 982 contributions he has made to this work and thank him for his past 983 efforts. 985 The authors would also like to thank Dino Farinacci, Fabio Maino, 986 Luigi Iannone, Sharon Barakai, Isidoros Kouvelas, Christian Cassar, 987 Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald 988 Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, as 989 well as every people acknowledged in [RFC6830]. 991 12. References 993 12.1. Normative References 995 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 996 Requirement Levels", BCP 14, RFC 2119, March 1997. 998 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 999 an On-line Database", RFC 3232, January 2002. 1001 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 1002 Gill, "IPv4 Multihoming Practices and Limitations", RFC 1003 4116, July 2005. 1005 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 1006 Workshop on Routing and Addressing", RFC 4984, September 1007 2007. 1009 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1010 Locator/ID Separation Protocol (LISP)", RFC 6830, January 1011 2013. 1013 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 1014 Locator/ID Separation Protocol (LISP) for Multicast 1015 Environments", RFC 6831, January 2013. 1017 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 1018 "Interworking between Locator/ID Separation Protocol 1019 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 1021 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 1022 Protocol (LISP) Map-Server Interface", RFC 6833, January 1023 2013. 1025 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 1026 Separation Protocol (LISP) Map-Versioning", RFC 6834, 1027 January 2013. 1029 [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation 1030 Protocol Internet Groper (LIG)", RFC 6835, January 2013. 1032 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1033 "Locator/ID Separation Protocol Alternative Logical 1034 Topology (LISP+ALT)", RFC 6836, January 2013. 1036 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 1037 Routing Locator (RLOC) Database", RFC 6837, January 2013. 1039 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1040 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 1042 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1043 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1044 RFC 6936, April 2013. 1046 [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID 1047 Separation Protocol (LISP) MIB", RFC 7052, October 2013. 1049 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 1050 Pascual, J., and D. Lewis, "Locator/Identifier Separation 1051 Protocol (LISP) Network Element Deployment 1052 Considerations", RFC 7215, April 2014. 1054 12.2. Informative References 1056 [Chiappa] Chiappa, J., "Endpoints and Endpoint names: A Propose 1057 Enhancement to the Internet Architecture, 1058 http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt", 1999. 1060 [DDT-ROOT] 1061 LISP DDT ROOT, , "http://ddt-root.org/", August 2013. 1063 [DFZ] Huston, Geoff., "Growth of the BGP Table - 1994 to Present 1064 http://bgp.potaroo.net/", August 2013. 1066 [I-D.cheng-lisp-shdht] 1067 Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping 1068 Overlay", draft-cheng-lisp-shdht-04 (work in progress), 1069 July 2013. 1071 [I-D.curran-lisp-emacs] 1072 Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID 1073 Mappings Multicast Across Cooperating Systems for LISP", 1074 draft-curran-lisp-emacs-00 (work in progress), November 1075 2007. 1077 [I-D.ietf-lisp-ddt] 1078 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 1079 Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in 1080 progress), October 2014. 1082 [I-D.ietf-lisp-lcaf] 1083 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1084 Address Format (LCAF)", draft-ietf-lisp-lcaf-06 (work in 1085 progress), October 2014. 1087 [I-D.ietf-lisp-sec] 1088 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 1089 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07 1090 (work in progress), October 2014. 1092 [I-D.ietf-lisp-threats] 1093 Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats 1094 Analysis", draft-ietf-lisp-threats-10 (work in progress), 1095 July 2014. 1097 [I-D.mathy-lisp-dht] 1098 Mathy, L., Iannone, L., and O. Bonaventure, ""LISP-DHT: 1099 Towards a DHT to map identifiers onto locators" draft- 1100 mathy-lisp-dht-00 (work in progress)", April 2008. 1102 [Jakab] Jakab, L., Cabellos, A., Saucez, D., and O. Bonaventure, 1103 "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping 1104 System, IEEE Journal on Selected Areas in Communications, 1105 vol. 28, no. 8, pp. 1332-1343", October 2010. 1107 [Quoitin] Quoitin, B., Iannone, L., Launois, C., and O. Bonaventure, 1108 ""Evaluating the Benefits of the Locator/Identifier 1109 Separation" in Proceedings of 2Nd ACM/IEEE International 1110 Workshop on Mobility in the Evolving Internet 1111 Architecture", 2007. 1113 Appendix A. A Brief History of Location/Identity Separation 1115 The LISP system for separation of location and identity resulted from 1116 the discussions of this topic at the Amsterdam IAB Routing and 1117 Addressing Workshop, which took place in October 2006 [RFC4984]. 1119 A small group of like-minded personnel from various scattered 1120 locations within Cisco, spontaneously formed immediately after that 1121 workshop, to work on an idea that came out of informal discussions at 1122 the workshop and on various mailing lists. The first Internet-Draft 1123 on LISP appeared in January, 2007. 1125 Trial implementations started at that time, with initial trial 1126 deployments underway since June 2007; the results of early experience 1127 have been fed back into the design in a continuous, ongoing process 1128 over several years. LISP at this point represents a moderately 1129 mature system, having undergone a long organic series of changes and 1130 updates. 1132 LISP transitioned from an IRTF activity to an IETF WG in March 2009, 1133 and after numerous revisions, the basic specifications moved to 1134 becoming RFCs at the start of 2013 (although work to expand and 1135 improve it, and find new uses for it, continues, and undoubtly will 1136 for a long time to come). 1138 A.1. Old LISP Models 1140 LISP, as initially conceived, had a number of potential operating 1141 modes, named 'models'. Although they are note used anymore, one 1142 occasionally sees mention of them, so they are briefly described 1143 here. 1145 LISP 1: EIDs all appear in the normal routing and forwarding tables 1146 of the network (i.e. they are 'routable');this property is used to 1147 'bootstrap' operation, by using this to load EID->RLOC mappings. 1148 Packets were sent with the EID as the destination in the outer 1149 wrapper; when an ETR saw such a packet, it would send a Map-Reply 1150 to the source ITR, giving the full mapping. 1152 LISP 1.5: Similar to LISP 1, but the routability of EIDs happens on 1153 a separate network. 1155 LISP 2: EIDs are not routable; EID->RLOC mappings are available from 1156 the DNS. 1158 LISP 3: EIDs are not routable; and have to be looked up in in a new 1159 EID->RLOC mapping database (in the initial concept, a system using 1160 Distributed Hash Tables). Two variants were possible: a 'push' 1161 system, in which all mappings were distributed to all ITRs, and a 1162 'pull' system in which ITRs load the mappings they need, as 1163 needed. 1165 Authors' Addresses 1167 Albert Cabellos 1168 UPC-BarcelonaTech 1169 c/ Jordi Girona 1-3 1170 Barcelona, Catalonia 08034 1171 Spain 1173 Email: acabello@ac.upc.edu 1175 Damien Saucez (Ed.) 1176 INRIA 1177 2004 route des Lucioles BP 93 1178 Sophia Antipolis Cedex 06902 1179 France 1181 Email: damien.saucez@inria.fr