idnits 2.17.1 draft-ietf-lisp-introduction-06.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 (October 23, 2014) is 3472 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'DFZ' is defined on line 1017, 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: April 26, 2015 INRIA 6 October 23, 2014 8 An Architectural Introduction to the Locator/ID Separation Protocol 9 (LISP) 10 draft-ietf-lisp-introduction-06.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 April 26, 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 . . . . . . . . . . . . . . 4 66 3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 7 68 3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 8 69 3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 8 70 3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 9 71 3.4.2. Mapping System Interface . . . . . . . . . . . . . . 9 72 3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 10 73 3.5. Interworking Mechanisms . . . . . . . . . . . . . . . . . 13 74 4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 13 75 4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 14 76 4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 14 77 4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 16 78 4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 16 79 5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 7. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 8.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 19 84 8.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 19 85 8.3. LISP for Virtual Private Networks . . . . . . . . . . . . 20 86 8.4. LISP for Virtual Machine Mobility in Data Centers . . . . 20 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 89 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 92 12.2. Informative References . . . . . . . . . . . . . . . . . 22 93 Appendix A. A Brief History of Location/Identity Separation . . 23 94 A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 24 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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 By taking advantage of such separation between location and identity 126 LISP offers Traffic Engineering, multihoming, and mobility among 127 others benefits. Additionally, LISP's approach to solve the routing 128 scalability problem [RFC4984] is that with LISP the Internet core is 129 populated with RLOCs while Traffic Engineering mechanisms are pushed 130 to the Mapping System. With this RLOCs are quasi-static (i.e., low 131 churn) and hence, the routing system scalable [Quoitin]. 133 This document describes the LISP architecture, its main operational 134 mechanisms as its design rationale. It is important to note that 135 this document does not specify or complement the LISP protocol. The 136 interested reader should refer to the main LISP specifications 137 [RFC6830] and the complementary documents [RFC6831],[RFC6832], 138 [RFC6833],[RFC6834],[RFC6835], [RFC6836] for the protocol 139 specifications along with the LISP deployment guidelines [RFC7215]. 141 2. Definition of Terms 143 This document describes the LISP architecture and does not define or 144 introduce any new term. The reader is referred to 145 [RFC6830],[RFC6831],[RFC6832],[RFC6833],[RFC6834],[RFC6835], 146 [RFC6836],[RFC7215] for the LISP definition of terms. 148 3. LISP Architecture 150 This section presents the LISP architecture, it first details the 151 design principles of LISP and then it proceeds to describe its main 152 aspects: data-plane, control-plane, and inetrworking mechanisms. 154 3.1. Design Principles 156 The LISP architecture is built on top of four basic design 157 principles: 159 o Locator/Identifier split: By decoupling the overloaded semantics 160 of the current IP addresses the Internet core can be assigned 161 identity meaningful addresses and hence, can use aggregation to 162 scale. Devices are assigned with identity meaningful addresses 163 that are independent of their topological location. 165 o Overlay architecture: Overlays route packets over the current 166 Internet, allowing deployment of new protocols without changing 167 the current infrastructure hence, resulting into a low deployment 168 cost. 170 o Decoupled data and control-plane: Separating the data-plane from 171 the control-plane allows them to scale independently and use 172 different architectural approaches. This is important given that 173 they typically have different requirements. 175 o Incremental deployability: This principle ensures that the 176 protocol interoperates with the legacy Internet while providing 177 some of the targeted benefits to early adopters. 179 3.2. Overview of the Architecture 181 LISP splits architecturally the core from the edge of the Internet by 182 creating two separate namespaces: Endpoint Identifiers (EIDs) and 183 Routing LOCators (RLOC). The edge consists of LISP sites (e.g., an 184 Autonomous System) that use EID addresses. EIDs are typically -but 185 not limited to- IPv4 or IPv6 addresses that uniquely identify 186 communication end-hosts and are assigned and configured by the same 187 mechanisms that exist at the time of this writing. EIDs do not 188 contain inter-domain topological information and can be thought as an 189 analogy to Provider Independent (PI [RFC4116]) addresses. Because of 190 this, EIDs are usually only routable at the edge. 192 With LISP, LISP sites (edge) and the core of the Internet are 193 interconnected by means of LISP-capable routers (e.g., border 194 routers) using tunnels. When packets originated from a LISP site are 195 flowing towards the core network, they ingress into an encapsulated 196 tunnel via an Ingress Tunnel Router (ITR). When packets flow from 197 the core network to a LISP site, they egress from an encapsulated 198 tunnel to an Egress Tunnel Router (ETR). An xTR is a router with can 199 perform both ITR and ETR operations. In this context ITRs 200 encapsulate packets while ETRs decapsulate them, hence LISP operates 201 as an overlay to the current Internet core. 203 /-----------------\ --- 204 | Mapping | | 205 . System | | Control 206 -| |`, | Plane 207 ,' \-----------------/ . | 208 / \ --- 209 ,.., - _,..--..,, `, ,.., | 210 / ` ,' ,-` `', . / ` | 211 / \ +-----+ ,' `, +--'--+ / \ | 212 | EID |-| xTR |---/ RLOC ,---| xTR |-| EID | | Data 213 | Space |-| |---| Space |---| |-| Space | | Plane 214 \ / +-----+ . / +-----+ \ / | 215 `. .' `. ,' `. .' | 216 `'-` `., ,.' `'-` --- 217 ``''--''`` 218 LISP Site (Edge) Core LISP Site (Edge) 220 Figure 1.- A schema of the LISP Architecture 222 With LISP, the core uses RLOCs, an RLOC is typically -but not limited 223 to- an IPv4 or IPv6 address assigned to an Internet-facing network 224 interface of an ITR or ETR. Typically RLOCs are numbered from 225 topologically aggregatable blocks assigned to a site at each point to 226 which it attaches to the global Internet. The topology is defined by 227 the connectivity of networks, in this context RLOCs can be though as 228 Provider Aggregatable addresses [RFC4116]. 230 A typically distributed database, called the Mapping System, stores 231 mappings between EIDs and RLOCs. Such mappings relate the identity 232 of the devices attached to LISP sites (EIDs) to the set of RLOCs 233 configured at the LISP-capable routers servicing the site. 234 Furthermore, the mappings also include traffic engineering policies 235 and can be configured to achieve multihoming and load balancing. The 236 LISP Mapping System is conceptually similar to the DNS that would be 237 accessed by ETRs to register mappings and by ITRs to retrieve them. 239 Finally, the LISP architecture emphasizes a cost effective 240 incremental deployment. Given that LISP represents an overlay to the 241 current Internet architecture, endhosts as well as intra and inter- 242 domain routers remain unchanged, and the only required changes to the 243 existing infrastructure are to routers connecting the EID with the 244 RLOC space. Such LISP capable routers, in most cases, only require a 245 software upgrade. Additionally, LISP requires the deployment of an 246 independent Mapping System, such distributed database is a new 247 network entity. 249 The following describes a simplified packet flow sequence between two 250 nodes that are attached to LISP sites. Client hostA wants to send a 251 packet to server hostB. 253 /----------------\ 254 | Mapping | 255 | System | 256 .| |- 257 ` \----------------/ `. 258 ,` \ 259 / `. 260 ,' _,..-..,, ', 261 / -` `-, \ 262 .' ,' \ `, 263 ` ' \ ' 264 +-----+ | | RLOC_B1+-----+ 265 HostA | | | RLOC |-------| | HostB 266 EID_A--|ITR_A|----| Space | |ETR_B|--EID_B 267 | | RLOC_A1 |-------| | 268 +-----+ | | RLOC_B2+-----+ 269 , / 270 \ / 271 `', ,-` 272 ``''-''`` 274 Figure 2.- Packet flow sequence in LISP 276 1. HostA retrieves the EID_B of HostB (typically querying the DNS) 277 and generates an IP packet as in the Internet, the packet has 278 source address EID_A and destination address EID_B. 280 2. The packet is routed towards ITR_A in the LISP site using 281 standard intra-domain mechanisms. 283 3. ITR_A upon receiving the packet queries the Mapping System to 284 retrieve the locator of ETR_B that is servicing hostB's EID_B. 285 In order to do so it uses a LISP control message called Map- 286 Request, the message contains EID_B as the lookup key. In turn 287 it receives another LISP control message called Map-Reply, the 288 message contains two locators: RLOC_B1 and RLOC_B2 along with 289 traffic engineering policies: priority and weight per locator. 290 ITR_A also stores the mapping in a local cache to speed-up 291 forwarding of subsequent packets. 293 4. ITR_A encapsulates the packet towards RLOC_B1 (chosen according 294 to the priorities/weights specified in the mapping). The packet 295 contains two IP headers, the outer header has RLOC_A1 as source 296 and RLOC_B2 as destination, the inner original header has EID_A 297 as source and EID_B as destination. Furthermore ITR_A adds a 298 LISP header, more details about LISP encapsulation can be found 299 in Section 3.3.1. 301 5. The encapsulated packet is forwarded by the Internet core as a 302 normal IP packet, making the EID invisible from the Internet 303 core. 305 6. Upon reception of the encapsulated packet by ETR_B, it 306 decapsulates the packet and forwards it to hostB. 308 3.3. Data-Plane 310 This section provides a high-level description of the LISP data- 311 plane, which is specified in detail in [RFC6830]. The LISP data- 312 plane is responsible for encapsulating and decapsulating data packets 313 and caching the appropriate forwarding state. It includes two main 314 entities, the ITR and the ETR, both are LISP capable routers that 315 connect the EID with the RLOC space (ITR) and vice versa (ETR). 317 3.3.1. LISP Encapsulation 319 ITRs encapsulate data packets towards ETRs. LISP data packets are 320 encapsulated using UDP (port 4341). A particularity of LISP is that 321 UDP packets should include a zero checksum [RFC6935] [RFC6936] that 322 it is not verified in reception, LISP also supports non-zero 323 checksums that may be verified. This decision was made because the 324 typical transport protocols used by the applications already include 325 a checksum, by neglecting the additional UDP encapsulation checksum 326 xTRs can forward packets more efficiently. 328 LISP-encapsulated packets also include a LISP header (after the UDP 329 header and before the original IP header). The LISP header is 330 prepended by ITRs and striped by ETRs. It carries reachability 331 information (see more details in Section 4.2) and the Instance ID 332 field. The Instance ID field is used to distinguish traffic to/from 333 different tenant address spaces at the LISP site and that may use 334 overlapped but logically separated EID addressing. 336 Overall, LISP encapsulated data packets carry 4 headers [RFC6830] 337 ("outer" to "inner"): 339 1. Outer IP header containing RLOCs as source and destination 340 addresses. This header is originated by ITRs and stripped by 341 ETRs. 343 2. UDP header (port 4341) with zero checksum. This header is 344 originated by ITRs and stripped by ETRs. 346 3. LISP header that contains various forwarding-plane features (such 347 as reachability) and an Instance ID field. This header is 348 originated by ITRs and stripped by ETRs. 350 4. Inner IP header containing EIDs as source and destination 351 addresses. This header is created by the source end-host and is 352 left unchanged by LISP data plane processing on the ITR and ETR. 354 Finally, in some scenarios Recursive and/or Re-encapsulating tunnels 355 can be used for Traffic Engineering and re-routing. Re-encapsulating 356 tunnels are consecutive LISP tunnels and occur when an ETR removes a 357 LISP header and then acts as an ITR to prepend another one. On the 358 other hand, Recursive tunnels are nested tunnels and are implemented 359 by using multiple LISP encapsulations on a packet. Typically such 360 functions are implemented by Reencapsulating Tunnel Routers (RTRs). 362 3.3.2. LISP Forwarding State 364 ITRs retrieve from the LISP Mapping System mappings between EID 365 prefixes and RLOCs that are used to encapsulate packets. Such 366 mappings are stored in a local cache -called the Map-Cache- for 367 subsequent packets addressed to the same EID prefix. Mappings 368 include a (Time-to-Live) TTL (set by the ETR). More details about 369 the Map-Cache management can be found in Section 4.1. 371 3.4. Control-Plane 373 The LISP control-plane, specified in [RFC6833], provides a standard 374 interface to register, request, and resolve mappings. The LISP 375 Mapping System is a database that stores such mappings. The 376 following first describes the mappings, then the standard interface 377 to the Mapping System, and finally its architecture. 379 3.4.1. LISP Mappings 381 Each mapping includes the bindings between EID prefix(es) and set of 382 RLOCs as well as traffic engineering policies, in the form of 383 priorities and weights for the RLOCs. Priorities allow the ETR to 384 configure active/backup policies while weights are used to load- 385 balance traffic among the RLOCs (on a per-flow basis). 387 Typical mappings in LISP bind EIDs in the form of IP prefixes with a 388 set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses are 389 encoded using the appropriate Address Family Identifier (AFI) 390 [RFC3232]. However LISP can also support more general address 391 encoding by means of the ongoing effort around the LISP Canonical 392 Address Format (LCAF) [I-D.ietf-lisp-lcaf]. 394 With such a general syntax for address encoding in place, LISP aims 395 to provide flexibility to current and future applications. For 396 instance LCAFs could support MAC addresses, geo-coordinates, ASCII 397 names and application specific data. 399 3.4.2. Mapping System Interface 401 LISP defines a standard interface between data and control planes. 402 The interface is specified in [RFC6833] and defines two entities: 404 Map-Server: A network infrastructure component that learns mappings 405 from ETRs and publishes them into the LISP Mapping System. 406 Typically Map-Servers are not authoritative to reply to queries 407 and hence, they forward them to the ETR. However they can also 408 operate in proxy-mode, where the ETRs delegate replying to queries 409 to Map-Servers. This setup is useful when the ETR has limited 410 resources (i.e., CPU or power). 412 Map-Resolver: A network infrastructure component that interfaces 413 ITRs with the Mapping System by proxying queries and -in some 414 cases- responses. 416 The interface defines four LISP control messages which are sent as 417 UDP datagrams (port 4342): 419 Map-Register: This message is used by ETRs to register mappings in 420 the Mapping System and it is authenticated using a shared key 421 between the ETR and the Map-Server. 423 Map-Notify: When requested by the ETR, this message is sent by the 424 Map-Server in response to a Map-Register to acknowledge the 425 correct reception of the mapping and convey the latest Map-Server 426 state on the EID to RLOC mapping. 428 Map-Request: This message is used by ITRs or Map-Resolvers to 429 resolve the mapping of a given EID. 431 Map-Reply: This message is sent by Map-Servers or ETRs in response 432 to a Map-Request and contains the resolved mapping. Please note 433 that a Map-Reply may contain a negative reply if, for example, the 434 queried EID is not part of the LISP EID space. In such cases the 435 ITR typically forwards the traffic natively (non encapsulated) to 436 the public Internet, this behavior is defined to support 437 incremental deployment of LISP. 439 3.4.3. Mapping System 441 LISP architecturally decouples control and data-plane by means of a 442 standard interface. This interface glues the data-plane, routers 443 responsible for forwarding data-packets, with the LISP Mapping 444 System, a database responsible for storing mappings. 446 With this separation in place the data and control-plane can use 447 different architectures if needed and scale independently. Typically 448 the data-plane is optimized to route packets according to 449 hierarchical IP addresses. However the control-plane may have 450 different requirements, for instance and by taking advantage of the 451 LCAFs, the Mapping System may be used to store non-hierarchical keys 452 (such as MAC addresses), requiring different architectural approaches 453 for scalability. Another important difference between the LISP 454 control and data-planes is that, and as a result of the local mapping 455 cache available at ITR, the Mapping System does not need to operate 456 at line-rate. 458 The LISP WG has explored application of the following distributed 459 system techniques to the Mapping System architecture: graph-based 460 databases in the form of LISP+ALT [RFC6836], hierarchical databases 461 in the form of LISP-DDT [I-D.ietf-lisp-ddt], monolithic databases in 462 the form of LISP-NERD [RFC6837] and flat databases in the form of 463 LISP-DHT [I-D.cheng-lisp-shdht],[I-D.mathy-lisp-dht]. Furthermore it 464 is worth noting that, in some scenarios such as private deployments, 465 the Mapping System can operate as logically centralized. In such 466 cases it is typically composed of a single Map-Server/Map-Resolver. 468 The following focuses on the two mapping systems that have been 469 implemented and deployed (LISP-ALT and LISP+DDT). 471 3.4.3.1. LISP+ALT 473 The LISP Alternative Topology (LISP+ALT) [RFC6836] was the first 474 Mapping System proposed, developed and deployed on the LISP pilot 475 network. It is based on a distributed BGP overlay participated by 476 Map-Servers and Map-Resolvers. The nodes connect to their peers 477 through static tunnels. Each Map-Server involved in the ALT topology 478 advertises the EID-prefixes registered by the serviced ETRs, making 479 the EID routable on the ALT topology. 481 When an ITR needs a mapping it sends a Map-Request to a Map-Resolver 482 that, using the ALT topology, forwards the Map-Request towards the 483 Map-Server responsible for the mapping. Upon reception the Map- 484 Server forwards the request to the ETR that in turn, replies directly 485 to the ITR using the native Internet core. 487 3.4.3.2. LISP-DDT 489 LISP-DDT [I-D.ietf-lisp-ddt] is conceptually similar to the DNS, a 490 hierarchical directory whose internal structure mirrors the 491 hierarchical nature of the EID address space. The DDT hierarchy is 492 composed of DDT nodes forming a tree structure, the leafs of the tree 493 are Map-Servers. On top of the structure there is the DDT root node 494 [DDT-ROOT], which is a particular instance of a DDT node and that 495 matches the entire address space. As in the case of DNS, DDT 496 supports multiple redundant DDT nodes and/or DDT roots. Finally, 497 Map-Resolvers are the clients of the DDT hierarchy and can query 498 either the DDT root and/or other DDT nodes. 500 /---------\ 501 | | 502 | DDT Root| 503 | /0 | 504 ,.\---------/-, 505 ,-'` | `'., 506 -'` | `- 507 /-------\ /-------\ /-------\ 508 | DDT | | DDT | | DDT | 509 | Node | | Node | | Note | ... 510 | 0/8 | | 1/8 | | 2/8 | 511 \-------/ \-------/ \-------/ 512 _. _. . -..,,,_ 513 -` -` \ ````''-- 514 +------------+ +------------+ +------------+ +------------+ 515 | Map-Server | | Map-Server | | Map-Server | | Map-Server | 516 | EID-prefix1| | EID-prefix2| | EID-prefix3| | EID-prefix4| 517 +------------+ +------------+ +------------+ +------------+ 519 Figure 3.- A schematic representation of the DDT tree structure, 520 please note that the prefixes and the structure depicted 521 should be only considered as an example. 523 The DDT structure does not actually index EID-prefixes but eXtended 524 EID-prefixes (XEID). An XEID-prefix is just the concatenation of the 525 following fields (from most significant bit to less significant bit): 526 Database-ID, Instance ID, Address Family Identifier and the actual 527 EID-prefix. The Database-ID is provided for possible future 528 requirements of higher levels in the hierarchy and to enable the 529 creation of multiple and separate database trees. 531 In order to resolve a query LISP-DDT operates in a similar way to the 532 DNS but only supports iterative lookups. DDT clients (usually Map- 533 Resolvers) generate Map-Requests to the DDT root node. In response 534 they receive a newly introduced LISP-control message: a Map-Referral. 535 A Map-Referral provides the list of RLOCs of the set of DDT nodes 536 matching a configured XEID delegation. That is, the information 537 contained in the Map-Referral points to the child of the queried DDT 538 node that has more specific information about the queried XEID- 539 prefix. This process is repeated until the DDT client walks the tree 540 structure (downwards) and discovers the Map-Server servicing the 541 queried XEID. At this point the client sends a Map-Request and 542 receives a Map-Reply containing the mappings. It is important to 543 note that DDT clients can also cache the information contained in 544 Map-Referrals, that is, they cache the DDT structure. This is used 545 to reduce the mapping retrieving latency[Jakab]. 547 The DDT Mapping System relies on manual configuration. That is Map- 548 Resolvers are manually configured with the set of available DDT root 549 nodes while DDT nodes are manually configured with the appropriate 550 XEID delegations. Configuration changes in the DDT nodes are only 551 required when the tree structure changes itself, but it doesn't 552 depend on EID dynamics (RLOC allocation or traffic engineering policy 553 changes). 555 3.5. Interworking Mechanisms 557 EIDs are typically identical to either IPv4 or IPv6 addresses and 558 they are stored in the LISP Mapping System, however they are usually 559 not announced in the Internet global routing system. As a result 560 LISP requires an inetrworking mechanism to allow LISP sites to speak 561 with non-LISP sites and vice versa. LISP inetrworking mechanisms are 562 specified in [RFC6832]. 564 LISP defines two entities to provide inetrworking: 566 Proxy Ingress Tunnel Router (PITR): PITRs provide connectivity from 567 the legacy Internet to LISP sites. PITRs announce in the global 568 routing system blocks of EID prefixes (aggregating when possible) 569 to attract traffic. For each incoming data-packet, the PITR LISP- 570 encapsulates it towards the RLOC(s) of the appropriate LISP site. 571 The impact of PITRs in the routing table size of the DFZ is, in 572 the worst-case, similar to the case in which LISP is not deployed. 573 EID-prefixes will be aggregated as much as possible both by the 574 PITR and by the global routing system. 576 Proxy Egress Tunnel Router (PETR): PETRs provide connectivity from 577 LISP sites to the legacy Internet. In some scenarios, LISP sites 578 may be unable to send encapsulated packets with a local EID 579 address as a source to the legacy Internet. For instance when 580 Unicast Reverse Path Forwarding (uRPF) is used by Provider Edge 581 routers, or when an intermediate network between a LISP site and a 582 non-LISP site does not support the desired version of IP (IPv4 or 583 IPv6). In both cases the PETR overcomes such limitations by 584 encapsulating packets over the network. There is no specified 585 provision for the distribution of PETR RLOC addresses to the ITRs. 587 4. LISP Operational Mechanisms 589 This section details the main operational mechanisms defined in LISP. 591 4.1. Cache Management 593 LISP's decoupled control and data-plane, where mappings are stored in 594 the control-plane and used for forwarding in the data plane, requires 595 of a local cache in ITRs to reduce signaling overhead (Map-Request/ 596 Map-Reply) and increase forwarding speed. The local cache available 597 at the ITRs, called Map-Cache, is used by the router to LISP- 598 encapsulate packets. The Map-Cache is indexed by (Instance ID, EID- 599 prefix) and contains basically the set of RLOCs with the associated 600 traffic engineering policies (priorities and weights). 602 The Map-Cache, as any other cache, requires cache coherence 603 mechanisms to maintain up-to-date information. LISP defines three 604 main mechanisms for cache coherence: 606 Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon 607 expiration of the TTL the ITR has to refresh the mapping by 608 sending a new Map-Request. Typical values for TTL defined by LISP 609 are 24h. 611 Solicit-Map-Request (SMR): SMR is an explicit mechanism to update 612 mapping information. In particular a special type of Map-Request 613 can be sent on demand by ETRs to request refreshing a mapping. 614 Upon reception of a SMR message, the ITR must refresh the bindings 615 by sending a Map-Request to the Mapping System. 617 Map-Versioning: This optional mechanism piggybacks in the LISP 618 header of data-packets the version number of the mappings used by 619 an xTR. This way, when an xTR receives a LISP-encapsulated packet 620 from a remote xTR, it can check whether its own Map-Cache or the 621 one of the remote xTR is outdated. If its Map-Cache is outdated, 622 it sends a Map-Request for the remote EID so to obtain the newest 623 mappings. On the contrary, if it detects that the remote xTR Map- 624 Cache is outdated, it sends a SMR to notify it that a new mapping 625 is available. 627 Finally it is worth noting that in some cases an entry in the map- 628 cache can be proactively refreshed using the mechanisms described in 629 the section below. 631 4.2. RLOC Reachability 633 The LISP architecture is an edge to edge pull architecture, where the 634 network state is stored in the control-plane while the data-plane 635 pulls it on demand. On the contrary BGP is a push architecture, 636 where the required network state is pushed by means of BGP UPDATE 637 messages to BGP speakers. In push architectures, reachability 638 information is also pushed to the interested routers. However pull 639 architectures require explicit mechanisms to propagate reachability 640 information. LISP defines a set of mechanisms to inform ITRs and 641 PITRS about the reachability of the cached RLOCs: 643 Locator Status Bits (LSB): LSB is a passive technique, the LSB field 644 is carried by data-packets in the LISP header and can be set by a 645 ETRs to specify which RLOCs of the ETR site are up/down. This 646 information can be used by the ITRs as a hint about the reachability 647 to perform additional checks. Also note that LSB does not provide 648 path reachability status, only hints on the status of RLOCs. 650 Echo-nonce: This is also a passive technique, that can only operate 651 effectively when data flows bi-directionally between two 652 communicating xTRs. Basically, an ITR piggybacks a random number 653 (called nonce) in LISP data packets, if the path and the probed 654 locator are up, the ETR will piggyback the same random number on the 655 next data-packet, if this is not the case the ITR can set the locator 656 as unreachable. When traffic flow is unidirectional or when the ETR 657 receiving the traffic is not the same as the ITR that transmits it 658 back, additional mechanisms are required. 660 RLOC-probing: This is an active probing algorithm where ITRs send 661 probes to specific locators, this effectively probes both the locator 662 and the path. In particular this is done by sending a Map-Request 663 (with certain flags activated) on the data-plane (RLOC space) and 664 waiting in return a Map-Reply, also sent on the data-plane. The 665 active nature of RLOC-probing provides an effective mechanism to 666 determine reachability and, in case of failure, switching to a 667 different locator. Furthermore the mechanism also provides useful 668 RTT estimates of the delay of the path that can be used by other 669 network algorithms. 671 Additionally, LISP also recommends inferring reachability of locators 672 by using information provided by the underlay, in particular: 674 It is worth noting that RLOC probing and Echo-nonce can work 675 together. Specifically if a nonce is not echoed, an ITR could RLOC- 676 probe to determine if the path is up because the return bidirectional 677 path may have failed or the return path is not used, that is there is 678 only a unidirectional path. 680 ICMP signaling: The LISP underlay -the current Internet- uses the 681 ICMP protocol to signal unreachability (among other things). LISP 682 can take advantage of this and the reception of a ICMP Network 683 Unreachable or ICMP Host Unreachable message can be seen as a hint 684 that a locator might be unreachable, this should lead to perform 685 additional checks. 687 Underlay routing: Both BGP and IBGP carry reachability information, 688 LISP-capable routers that have access to underlay routing information 689 can use it to determine if a given locator or path are reachable. 691 4.3. ETR Synchronization 693 All the ETRs that are authoritative to a particular EID-prefix must 694 announce the same mapping to the requesters, this means that ETRs 695 must be aware of the status of the RLOCs of the remaining ETRs. This 696 is known as ETR synchronization. 698 At the time of this writing LISP does not specify a mechanism to 699 achieve ETR synchronization. Although many well-known techniques 700 could be applied to solve this issue it is still under research, as a 701 result operators must rely on coherent manual configuration 703 4.4. MTU Handling 705 Since LISP encapsulates packets it requires dealing with packets that 706 exceed the MTU of the path between the ITR and the ETR. Specifically 707 LISP defines two mechanisms: 709 Stateless: With this mechanism the effective MTU is assumed from the 710 ITR's perspective. If a payload packet is too big for the 711 effective MTU, and can be fragmented, the payload packet is 712 fragmented on the ITR, such that reassembly is performed at the 713 destination host. 715 Stateful: With this mechanism ITRs keep track of the MTU of the 716 paths towards the destination locators by parsing the ICMP Too Big 717 packets sent by intermediate routers. Additionally ITRs will send 718 ICMP Too Big messages to inform the sources about the effective 719 MTU. 721 In both cases if the packet cannot be fragmented (IPv4 with DF=1 or 722 IPv6) then the ITR drops it and replies with a ICMP Too Big message 723 to the source. 725 5. Mobility 727 The separation between locators and identifiers in LISP was initially 728 proposed for traffic engineering purpose where LISP sites can change 729 their attachment points to the Internet (i.e., RLOCs) without 730 impacting endpoints or the Internet core. In this context, the 731 border routers operate the xTR functionality and endpoints are not 732 aware of the existence of LISP. However, this mode of operation does 733 not allow seamless mobility of endpoints between different LISP sites 734 as the EID address might not be routable in a visited site. 736 Nevertheless, LISP can be used to enable seamless IP mobility when 737 LISP is directly implemented in the endpoint. Each endpoint is then 738 an xTR and the EID address is the one presented to the network stack 739 used by applications while the RLOC is the address gathered from the 740 network when it is visited. 742 Whenever the device changes of RLOC, the ITR updates the RLOC of its 743 local mapping and registers it to its Map-Server. To avoid the need 744 of a home gateway, the ITR also indicates the RLOC change to all 745 remote devices that have ongoing communications with the device that 746 moved. The combination of both methods ensures the scalability of 747 the system as signaling is strictly limited the Map-Server and to 748 hosts with which communications are ongoing. 750 6. Multicast 752 LISP also supports transporting IP multicast packets sent from the 753 EID space, the operational changes required to the multicast 754 protocols are documented in [RFC6831]. 756 In such scenarios, LISP may create multicast state both at the core 757 and at the sites (both source and receiver). When signaling is used 758 create multicast state at the sites, LISP routers unicast encapsulate 759 PIM Join/Prune messages from receiver to source sites. At the core, 760 ETRs build a new PIM Join/Prune message addressed to the RLOC of the 761 ITR servicing the source. An simplified sequence is shown below 763 1. An end-host willing to join a multicast channel sends an IGMP 764 report. Multicast PIM routers at the LISP site propagate PIM 765 Join/Prune messages (S-EID, G) towards the ETR. 767 2. The join message flows to the ETR, upon reception the ETR builds 768 two join messages, the first one unicast LISP-encapsulates the 769 original join message towards the RLOC of the ITR servicing the 770 source. This message creates multicast state at the source site. 771 The second join message contains as destination address the RLOC 772 of the ITR servicing the source (S-RLOC, G) and creates multicast 773 state at the core. 775 3. Multicast data packets originated by the source (S-EID, G) flow 776 from the source to the ITR. The ITR LISP-encapsulates the 777 multicast packets, the outter header includes its own RLOC as the 778 source (S-RLOC) and the original multicast group address (G) as 779 the destination. Please note that multicast group address are 780 logical and are not resolved by the mapping system. Then the 781 multicast packet is transmitted through the core towards the 782 receiving ETRs that decapsulates the packets and sends them using 783 the receiver's site multicast state. 785 LISP also support non-PIM mechanisms to maintain multicast state. 787 7. Security 789 LISP uses a pull architecture to learn mappings. While in a push 790 system, the state necessary to forward packets is learned 791 independently of the traffic itself, with a pull architecture, the 792 system becomes reactive and data-plane events (e.g., the arrival of a 793 packet for an unknown destination) may trigger control-plane events. 794 This on-demand learning of mappings provides many advantages as 795 discussed above but may also affect the way security is enforced. 797 Usually, the data-plane is implemented in the fast path of routers to 798 provide high performance forwarding capabilities while the control- 799 plane features are implemented in the slow path to offer high 800 flexibility and a performance gap of several order of magnitude can 801 be observed between the slow and the fast paths. As a consequence, 802 the way data-plane events are notified to the control-plane must be 803 though carefully so to not overload the slow path and rate limiting 804 should be used as specified in [RFC6830]. 806 Care must also be taken so to not overload the mapping system (i.e., 807 the control plane infrastructure) as the operations to be performed 808 by the mapping system may be more complex than those on the data- 809 plane, for that reason [RFC6830] recommends to rate limit the sending 810 of messages to the mapping system. 812 To improve resiliency and reduce the overall number of messages 813 exchanged, LISP offers the possibility to leak control informations, 814 such as reachabilty of locators, directly into data plane packets. 815 In environments that are not fully trusted, control informations 816 gleaned from data-plane packets should be verified before using them. 818 Mappings are the centrepiece of LISP and all precautions must be 819 taken to avoid them to be manipulated or misused by malicious 820 entities. Using trustable Map-Servers that strictly respect 821 [RFC6833] and the lightweight authentication mechanism proposed by 822 LISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks to the 823 mapping integrity. In more critical environments, secure measures 824 may be needed. 826 As with any other tunneling mechanism, middleboxes on the path 827 between an ITR (or PITR) and an ETR (or PETR) must implement 828 mechanisms to strip the LISP encapsulation to correctly inspect the 829 content of LISP encapsulated packets. 831 Like other map-and-encap mechanisms, LISP enables triangular routing 832 (i.e., packets of a flow cross different border routers depending on 833 their direction). This means that intermediate boxes may have 834 incomplete view on the traffic they inspect or manipulate. 836 More details about security implications of LISP are discussed in 837 [I-D.ietf-lisp-threats]. 839 8. Use Cases 841 8.1. Traffic Engineering 843 BGP is the standard protocol to implement inter-domain routing. With 844 BGP, routing informations are propagated along the network and each 845 autonomous system can implement its own routing policy that will 846 influence the way routing information are propagated. The direct 847 consequence is that an autonomous system cannot precisely control the 848 way the traffic will enter the network. 850 As opposed to BGP, a LISP site can strictly impose via which ETRs the 851 traffic must enter the network even though the path followed to reach 852 the ETR is not under the control of the LISP site. This fine control 853 is implemented with the mappings. When a remote site is willing to 854 send traffic to a LISP site, it retrieves the mapping associated to 855 the destination EID via the mapping system. The mapping is sent 856 directly by an authoritative ETR of the EID and is not altered by any 857 intermediate network. 859 A mapping associates a list of RLOCs to an EID prefix. Each RLOC 860 corresponds to an interface of an ETR that is able to correctly 861 forward packets to EIDs in the prefix. Each RLOC is tagged with a 862 priority and a weight in the mapping. The priority is used to 863 indicates which RLOCs should be preferred to send packets (the least 864 preferred ones being provided for backup purpose). The weight 865 permits to balance the load between the RLOCs with the same priority, 866 proportionally to the weight value. 868 As mappings are directly issued by the authoritative ETR of the EID 869 and are not altered while transmitted to the remote site, it offers 870 highly flexible incoming inter-domain traffic engineering with even 871 the possibility for a site to issue a different mapping for each 872 remote site, implementing so precise routing policies. 874 8.2. LISP for IPv6 Co-existence 876 LISP encapsulations permits to transport packets using EIDs from a 877 given address family (e.g., IPv6) with packets with addresses 878 belonging to another address family (e.g., IPv4). The absence of 879 correlation between the address family of RLOCs and EIDs makes LISP a 880 candidate to allow, e.g., IPv6 to be deployed when all of the core 881 network may not have IPv6 enabled. 883 For example, two IPv6-only data centers could be interconnected via 884 the legacy IPv4 Internet. If their border routers are LISP capable, 885 sending packets between the data center is done without any form of 886 translation as the native IPv6 packets (in the EID space) will be 887 LISP encapsulated and transmitted over the IPv4 legacy Internet by 888 the mean of IPv4 RLOCs. 890 8.3. LISP for Virtual Private Networks 892 It is common to operate several virtual networks over the same 893 physical infrastructure. In such virtual private networks, it is 894 essential to distinguish to which virtual network a packet belongs 895 and tags or labels are used for that purpose. With LISP, the 896 distinction can be made with the Instance ID field. When an ITR 897 encapsulates a packet from a particular virtual network (e.g., known 898 via the VRF or VLAN), it tags the encapsulated packet with the 899 Instance ID corresponding to the virtual network of the packet. When 900 an ETR receives a packet tagged with an Instance ID it uses the 901 Instance ID to determine how to treat the packet. 903 The main advantage of using LISP for virtual networks, on top of the 904 simplicity of managing the mappings, is that it does not impose any 905 requirement on the underlying network, as long as it is running IP. 907 8.4. LISP for Virtual Machine Mobility in Data Centers 909 A way to enable seamless virtual machine mobility in data center is 910 to conceive the datacenter backbone as the RLOC space and the subnet 911 where servers are hosted as forming the EID space. A LISP router is 912 placed at the border between the backbone and each subnet. When a 913 virtual machine is moved to another subnet, it can (temporarily) keep 914 the address of the subnet it was hosted before the move so to allow 915 ongoing communications to subsist. When a subnet detects the 916 presence of a host with an address that does not belong to the subnet 917 (e.g., via a message sent by the hypervisor or traffic inspection), 918 the LISP router of the new subnet registers the IP address of the 919 virtual machine as an EID to the Map-Server of the subnet and 920 associates its own address as RLOC. 922 To inform the other LISP routers that the machine moved and where, 923 and then to avoid detours via the initial subnetwork, mechanisms such 924 as the Solicit-Map-Request messages are used. 926 9. Security Considerations 928 This document does not specify any protocol or operational practices 929 and hence, does not have any security considerations. 931 10. IANA Considerations 933 This memo includes no request to IANA. 935 11. Acknowledgements 937 This document was initiated by Noel Chiappa and much of the core 938 philosophy came from him. The authors acknowledge the important 939 contributions he has made to this work and thank him for his past 940 efforts. 942 The authors would also like to thank Dino Farinacci, Fabio Maino, 943 Luigi Iannone, Sharon Barakai, Isidoros Kouvelas, Christian Cassar, 944 Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald 945 Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, as 946 well as every people acknowledged in [RFC6830]. 948 12. References 950 12.1. Normative References 952 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 953 Requirement Levels", BCP 14, RFC 2119, March 1997. 955 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 956 an On-line Database", RFC 3232, January 2002. 958 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 959 Gill, "IPv4 Multihoming Practices and Limitations", RFC 960 4116, July 2005. 962 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 963 Workshop on Routing and Addressing", RFC 4984, September 964 2007. 966 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 967 Locator/ID Separation Protocol (LISP)", RFC 6830, January 968 2013. 970 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 971 Locator/ID Separation Protocol (LISP) for Multicast 972 Environments", RFC 6831, January 2013. 974 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 975 "Interworking between Locator/ID Separation Protocol 976 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 978 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 979 Protocol (LISP) Map-Server Interface", RFC 6833, January 980 2013. 982 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 983 Separation Protocol (LISP) Map-Versioning", RFC 6834, 984 January 2013. 986 [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation 987 Protocol Internet Groper (LIG)", RFC 6835, January 2013. 989 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 990 "Locator/ID Separation Protocol Alternative Logical 991 Topology (LISP+ALT)", RFC 6836, January 2013. 993 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 994 Routing Locator (RLOC) Database", RFC 6837, January 2013. 996 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 997 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 999 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1000 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1001 RFC 6936, April 2013. 1003 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 1004 Pascual, J., and D. Lewis, "Locator/Identifier Separation 1005 Protocol (LISP) Network Element Deployment 1006 Considerations", RFC 7215, April 2014. 1008 12.2. Informative References 1010 [Chiappa] Chiappa, J., "Endpoints and Endpoint names: A Propose 1011 Enhancement to the Internet Architecture, 1012 http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt", 1999. 1014 [DDT-ROOT] 1015 LISP DDT ROOT, , "http://ddt-root.org/", August 2013. 1017 [DFZ] Huston, Geoff., "Growth of the BGP Table - 1994 to Present 1018 http://bgp.potaroo.net/", August 2013. 1020 [I-D.cheng-lisp-shdht] 1021 Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping 1022 Overlay", draft-cheng-lisp-shdht-04 (work in progress), 1023 July 2013. 1025 [I-D.ietf-lisp-ddt] 1026 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 1027 Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in 1028 progress), October 2014. 1030 [I-D.ietf-lisp-lcaf] 1031 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1032 Address Format (LCAF)", draft-ietf-lisp-lcaf-06 (work in 1033 progress), October 2014. 1035 [I-D.ietf-lisp-sec] 1036 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 1037 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07 1038 (work in progress), October 2014. 1040 [I-D.ietf-lisp-threats] 1041 Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats 1042 Analysis", draft-ietf-lisp-threats-10 (work in progress), 1043 July 2014. 1045 [I-D.mathy-lisp-dht] 1046 Mathy, L., Iannone, L., and O. Bonaventure, ""LISP-DHT: 1047 Towards a DHT to map identifiers onto locators" draft- 1048 mathy-lisp-dht-00 (work in progress)", April 2008. 1050 [Jakab] Jakab, L., Cabellos, A., Saucez, D., and O. Bonaventure, 1051 "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping 1052 System, IEEE Journal on Selected Areas in Communications, 1053 vol. 28, no. 8, pp. 1332-1343", October 2010. 1055 [Quoitin] Quoitin, B., Iannone, L., Launois, C., and O. Bonaventure, 1056 ""Evaluating the Benefits of the Locator/Identifier 1057 Separation" in Proceedings of 2Nd ACM/IEEE International 1058 Workshop on Mobility in the Evolving Internet 1059 Architecture", 2007. 1061 Appendix A. A Brief History of Location/Identity Separation 1063 The LISP system for separation of location and identity resulted from 1064 the discussions of this topic at the Amsterdam IAB Routing and 1065 Addressing Workshop, which took place in October 2006 [RFC4984]. 1067 A small group of like-minded personnel from various scattered 1068 locations within Cisco, spontaneously formed immediately after that 1069 workshop, to work on an idea that came out of informal discussions at 1070 the workshop and on various mailing lists. The first Internet-Draft 1071 on LISP appeared in January, 2007. 1073 Trial implementations started at that time, with initial trial 1074 deployments underway since June 2007; the results of early experience 1075 have been fed back into the design in a continuous, ongoing process 1076 over several years. LISP at this point represents a moderately 1077 mature system, having undergone a long organic series of changes and 1078 updates. 1080 LISP transitioned from an IRTF activity to an IETF WG in March 2009, 1081 and after numerous revisions, the basic specifications moved to 1082 becoming RFCs at the start of 2013 (although work to expand and 1083 improve it, and find new uses for it, continues, and undoubtly will 1084 for a long time to come). 1086 A.1. Old LISP Models 1088 LISP, as initially conceived, had a number of potential operating 1089 modes, named 'models'. Although they are note used anymore, one 1090 occasionally sees mention of them, so they are briefly described 1091 here. 1093 LISP 1: EIDs all appear in the normal routing and forwarding tables 1094 of the network (i.e. they are 'routable');this property is used to 1095 'bootstrap' operation, by using this to load EID->RLOC mappings. 1096 Packets were sent with the EID as the destination in the outer 1097 wrapper; when an ETR saw such a packet, it would send a Map-Reply 1098 to the source ITR, giving the full mapping. 1100 LISP 1.5: Similar to LISP 1, but the routability of EIDs happens on 1101 a separate network. 1103 LISP 2: EIDs are not routable; EID->RLOC mappings are available from 1104 the DNS. 1106 LISP 3: EIDs are not routable; and have to be looked up in in a new 1107 EID->RLOC mapping database (in the initial concept, a system using 1108 Distributed Hash Tables). Two variants were possible: a 'push' 1109 system, in which all mappings were distributed to all ITRs, and a 1110 'pull' system in which ITRs load the mappings they need, as 1111 needed. 1113 Authors' Addresses 1115 Albert Cabellos 1116 UPC-BarcelonaTech 1117 c/ Jordi Girona 1-3 1118 Barcelona, Catalonia 08034 1119 Spain 1121 Email: acabello@ac.upc.edu 1123 Damien Saucez (Ed.) 1124 INRIA 1125 2004 route des Lucioles BP 93 1126 Sophia Antipolis Cedex 06902 1127 France 1129 Email: damien.saucez@inria.fr