idnits 2.17.1 draft-ietf-lisp-introduction-05.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 (September 22, 2014) is 3503 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ermagan-lisp-nat-traversal' is defined on line 1000, 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 (-19) exists of draft-ermagan-lisp-nat-traversal-03 == Outdated reference: A later version (-09) exists of draft-ietf-lisp-ddt-01 == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-05 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-06 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-threats-10 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-08 -- No information found for draft-mathy-lisp-dht - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 9 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: March 26, 2015 INRIA 6 September 22, 2014 8 An Architectural Introduction to the LISP Location-Identity Separation 9 System 10 draft-ietf-lisp-introduction-05.txt 12 Abstract 14 This document describes the Locator/ID Separation Protocol (LISP) 15 architecture, its main operational mechanisms as well as its design 16 rationale. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 26, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Design Principles . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Overview of the Architecture . . . . . . . . . . . . . . 4 62 2.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.3.1. LISP encapsulation . . . . . . . . . . . . . . . . . 7 64 2.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 8 65 2.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 9 66 2.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 9 67 2.4.2. Mapping System Interface . . . . . . . . . . . . . . 9 68 2.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 10 69 2.5. Internetworking Mechanisms . . . . . . . . . . . . . . . 13 70 3. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 13 71 3.1. Cache Management . . . . . . . . . . . . . . . . . . . . 14 72 3.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 14 73 3.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 15 74 3.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 16 75 4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 18 80 7.2. LISP for IPv6 Transition . . . . . . . . . . . . . . . . 19 81 7.3. LISP for Network Virtualization . . . . . . . . . . . . . 19 82 7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 20 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 88 11.2. Informative References . . . . . . . . . . . . . . . . . 22 89 Appendix A. A Brief History of Location/Identity Separation . . 23 90 A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 24 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 93 1. Introduction 95 There is a rough consensus that the Internet routing and addressing 96 system is facing severe scalability issues [RFC4984]. Specifically, 97 the growth in the size of the routing tables of the Default-Free Zone 98 (DFZ) is accelerating and showing a supra-linear slope [DFZ]. The 99 main driving force behind this growth is the de-aggregation of BGP 100 prefixes, which results from the existing BGP multihoming and traffic 101 engineering mechanisms that are used -at the time of this writing- on 102 the Internet, as well as non-aggregatable address allocations. 104 This issue has two profound implications, on the one hand Internet 105 core routers are exposed to the network dynamics of the edge. For 106 instance this typically leads to an increased amount of BGP UPDATE 107 messages (churn), which results in additional processing requirements 108 of Internet core routers in order to timely compute the DFZ RIB. 109 Secondly, the supra-linear growth imposes strong requirements on the 110 size of the memory storing the DFZ FIB. Both aspects lead to an 111 increase on the development and production cost of high-end routers, 112 and it is unclear if the semiconductor and router manufacturer 113 industries will be able to cope, in the long-term, with such 114 stringent requirements in a cost-effective way[RFC4984]. 116 Although this important scalability issue is relatively new, the 117 architectural reasons behind it are well-known many years ago. 118 Indeed, and as pointed out by [Chiappa], IP addresses have overloaded 119 semantics. Currently, IP addresses both identify the topological 120 location of a network attachment point as well as the node's 121 identity. However, nodes and routing have fundamentally different 122 requirements, routing systems require that addresses are aggregatable 123 and have topological meaning, while nodes require to be identified 124 independently of their current location. 126 The Locator/ID Separation Protocol (LISP), specified in [RFC6830], is 127 built on top of this basic idea: decoupling the IP address overloaded 128 semantics. LISP creates two separate namespaces, EIDs (End-host 129 IDentifiers) and RLOCs (Routing LOCators), both are -typically, but 130 not limited to- syntactically identical to the current IPv4 and IPv6 131 addresses. EIDs are used to uniquely identify nodes irrespective of 132 their topological location and are typically routed intra-domain. 133 RLOCs are assigned topologically to network attachment points and are 134 typically routed inter-domain. With LISP, the edge of the Internet 135 -where the nodes are connected- and the core -where inter-domain 136 routing occurs- are architecturally separated and interconnected by 137 LISP-capable routers. LISP also introduces a publicly accessible 138 database, called the Mapping System, to store and retrieve mappings 139 between identity and location. LISP-capable routers exchange packets 140 over the Internet core by encapsulating them to the appropriate 141 location. By taking advantage of such separation between location 142 and identity, the Internet core is populated with RLOCs which can be 143 quasi-static and highly aggregatable, hence scalable [Quoitin]. 145 This document describes the LISP architecture, its main operational 146 mechanisms as its design rationale. It is important to note that 147 this document does not specify or complement the LISP protocol. The 148 interested reader should refer to the main LISP specifications 149 [RFC6830] and the complementary documents [RFC6831],[RFC6832], 150 [RFC6833],[RFC6834],[RFC6835], [RFC6836] for the protocol 151 specifications along with the LISP deployment guidelines [RFC7215]. 153 2. LISP Architecture 155 This section presents the LISP architecture, we first detail the 156 design principles of LISP and then we proceed to describe its main 157 aspects: data-plane, control-plane, and internetworking mechanisms. 159 2.1. Design Principles 161 The LISP architecture is built on top of four basic design 162 principles: 164 o Locator/Identifier split: By decoupling the overloaded semantics 165 of the current IP addresses the Internet core can be assigned with 166 topological meaningful address and hence, can use aggregation to 167 scale. Devices are assigned with identity meaningful address that 168 are independent of its topological location. 170 o Overlay architecture: Overlays route packets over the current 171 Internet, allowing to deploy new protocols without changing the 172 current infrastructure hence, resulting from a low deployment 173 cost. 175 o Decoupled data and control-plane: Separating the data-plane from 176 the control-plane allows them to scale independently and use 177 different architectural approaches. This is important given that 178 they typically have different requirements. 180 o Incremental deployability: This principle ensures that the 181 protocol is compatible with the legacy Internet while providing 182 some of the targeted benefits to early adopters. 184 2.2. Overview of the Architecture 186 LISP splits architecturally the core from the edge of the Internet by 187 creating two separate namespaces: Endpoint Identifiers (EIDs) and 188 Routing LOCators (RLOC). The edge are LISP sites (e.g., an 189 Autonomous System) that use EID addresses. EIDs are typically -but 190 not limited to- IPv4 or IPv6 addresses that uniquely identify 191 endhosts and are assigned and configured by the same mechanisms that 192 we have at the time of this writing. EIDs can be are typically 193 Provider Independent (PI [RFC4116]) addresses and can be thought as 194 they don't contain intra-domain topological information. Because of 195 this, EIDs are usually only routable in the edge. 197 With LISP, LISP sites (edge) and the core of the Internet are inter- 198 connected by means of LISP-capable routers (e.g., border routers). 199 When they provide egress (from the core perspective) to a LISP site 200 they are called Egress Tunnel Routers (ETR), Ingress Tunnel Routers 201 (ITR) when they provide ingress, and xTR when they provide both. 202 ITRs and ETRs exchange packets by encapsulating them, hence LISP 203 operates as an overlay to the current Internet core. 205 /-----------------\ --- 206 | Mapping | | 207 . System | | Control 208 -| |`, | Plane 209 ,' \-----------------/ . | 210 / \ --- 211 ,.., - _,..--..,, `, ,.., | 212 / ` ,' ,-` `', . / ` | 213 / \ +-----+ ,' `, +--'--+ / \ | 214 | EID |-| xTR |---/ RLOC ,---| xTR |-| EID | | Data 215 | Space |-| |---| Space |---| |-| Space | | Plane 216 \ / +-----+ . / +-----+ \ / | 217 `. .' `. ,' `. .' | 218 `'-` `., ,.' `'-` --- 219 ``''--''`` 220 LISP Site (Edge) Core LISP Site (Edge) 222 Figure 1.- A schema of the LISP Architecture 224 With LISP, the core uses RLOCs, an RLOC is typically -but not limited 225 to- an IPv4 or IPv6 address assigned to an Internet-facing network 226 interface of an ITR or ETR. Typically RLOCs are numbered from 227 topologically aggregatable blocks assigned to a site at each point to 228 which it attaches to the global Internet. The topology is defined by 229 the connectivity of networks, in this context RLOCs can be though as 230 Provider Aggregatable addresses [RFC4116]. 232 A publicly accessible and usually distributed database, called the 233 Mapping System, stores mappings between EIDs and RLOCs. Such 234 mappings relate the identity of the devices attached to LISP sites 235 (EIDs) to the set of RLOCs configured at the LISP-capable routers 236 servicing the site. Furthermore, the mappings also include traffic 237 engineering policies and can be configured to achieve multihoming and 238 load balancing. The LISP Mapping System can be thought as the 239 equivalent of a DNS that would be accessed by ETRs to register 240 mappings and by ITRs to retrieve them. 242 Finally, the LISP architecture has a strong emphasis in cost 243 effective incremental deployment. Given that LISP represents an 244 overlay to the current Internet architecture, endhosts as well as 245 intra and inter-domain routers remain unchanged, and the only 246 required changes to the existing infrastructure are to routers 247 connecting the EID with the RLOC space. Such LISP capable routers 248 typically require only a software upgrade. Additionally, LISP 249 requires the deployment of an independent Mapping System, this 250 distributed database is a new network entity. 252 In what follows we describe a simplified packet flow sequence between 253 two nodes that are attached to LISP sites. Client hostA wants to 254 send a packt to server hostB. 256 /----------------\ 257 | Mapping | 258 | System | 259 .| |- 260 ` \----------------/ `. 261 ,` \ 262 / `. 263 ,' _,..-..,, ', 264 / -` `-, \ 265 .' ,' \ `, 266 ` ' \ ' 267 +-----+ | | RLOC_B1+-----+ 268 HostA | | | RLOC |-------| | HostB 269 EID_A--|ITR_A|----| Space | |ETR_B|--EID_B 270 | | RLOC_A1 |-------| | 271 +-----+ | | RLOC_B2+-----+ 272 , / 273 \ / 274 `', ,-` 275 ``''-''`` 277 Figure 2.- Packet flow sequence in LISP 279 1. HostA retrieves the EID_B of HostB (typically querying the DNS) 280 and generates an IP packet as in the Internet, the packet has 281 source address EID_A and destination address EID_B. 283 2. The packet is routed towards ITR_A in the LISP site using 284 standard intra-domain mechanisms. 286 3. ITR_A upon receiving the packet queries the Mapping System to 287 retrieve the locator of ETR_B that is servicing hostB. In order 288 to do so it uses a LISP control message called Map-Request, the 289 message contains EID_A as the lookup key, in turn it receives 290 another LISP control message called Map-Reply, the message 291 contains two locators: RLOC_B1 and RLOC_B2 along with traffic 292 engineering policies: priority and weight per locator. ITR_A 293 also stores the mapping in a local cache to speed-up forwarding 294 of subsequent packets. 296 4. ITR_A encapsulates the packet towards RLOC_B1 (chosen according 297 to the priorities/weights specified in the mapping). The packet 298 contains two IP headers, the outer header has RLOC_A1 as source 299 and RLOC_B2 as destination, the inner header has EID_A as source 300 and EID_B as destination. Furthermore ITR_A adds a LISP header, 301 more details about LISP encapsulation can be found in 302 Section 2.3.1. 304 5. The encapsulated packet is forwarded by the Internet core as a 305 normal IP packet, making the EID invisible from the Internet 306 core. 308 6. Upon reception of the encapsulated packet by ETR_B, it 309 decapsulates the packet and forwards it to hostB. 311 2.3. Data-Plane 313 This section describes the LISP data-plane, which is specified in 314 [RFC6830]. The LISP data-plane is responsible of encapsulating and 315 decapsulating data packets and caching the appropriate forwarding 316 state. It includes two main entities, the ITR and the ETR, both are 317 LISP capable routers that connect the EID with the RLOC space (ITR) 318 and viceversa (ETR). We first describe how packets are LISP- 319 encapsulated and then we proceed to explain how ITRs cache forwarding 320 state. 322 2.3.1. LISP encapsulation 324 ITRs encapsulate data packets towards ETRs. LISP data packets are 325 encapsulated using UDP (port 4341). A particularity of LISP is that 326 UDP packets should include a zero checksum [RFC6935] [RFC6936] that 327 it is not verified in reception, LISP also supports non-zero 328 checksums that may be verified. This decision was made because the 329 typical transport protocols used by the applications already include 330 a checksum, by neglecting the additional UDP encapsulation checksum 331 xTRs can forward packets more efficiently. 333 LISP-encapsulated packets also include a LISP header (after the UDP 334 header). The LISP header is prepended by ITRs and striped by ETRs. 335 It carries reachability information (see more details in Section 3.2) 336 and the Instance ID field. The Instance ID field is used to 337 distinguish traffic that belongs to multiple tenants inside a LISP 338 site, and that may use overlapped but logically separated addressing 339 space. 341 Overall, LISP encapsulated data packets carry 4 headers [RFC6830] 342 ("outer" to "inner"): 344 1. Outer IP header containing RLOCs as source and destination 345 addresses. This header is originated by ITRs and stripped by 346 ETRs. 348 2. UDP header (port 4341) with zero checksum. This header is 349 originated by ITRs and stripped by ETRs. 351 3. LISP header that may contain reachability information and an 352 Instance ID field. This header is originated by ITRs and 353 stripped by ETRs. 355 4. Inner IP header containing EIDs as source and destination 356 addresses. This header is created by the source end-host and 357 remains unchanged. 359 Finally and in some scenarios Recursive and/or Re-encapsulating 360 tunnels can be used for Traffic Engineering and re-routing. Re- 361 encapsulating tunnels are consecutive LISP tunnels and occur when an 362 ETR removes a LISP header and then acts as an ITR to prepend another 363 one. On the other hand, Recursive tunnels are nested tunnels and are 364 implemented by using multiple LISP encapsulations on a packet. 366 2.3.2. LISP Forwarding State 368 ITRs retrieve from the LISP Mapping System mappings between EID 369 prefixes and RLOCs that are used to encapsulate packets. Such 370 mappings are stored in a local cache -called the Map-Cache- to 371 increase the forwarding speed of subsequent packets addressed to the 372 same EID prefix. Mappings include a (Time-to-Live) TTL (set by the 373 ETR) and are expired according to this value, more details about the 374 Map-Cache management can be found in Section 3.1. 376 2.4. Control-Plane 378 The LISP control-plane, specified in [RFC6833], provides a standard 379 interface to register, query, and retrieve mappings. The LISP 380 Mapping System, is a publicly accessible database that stores such 381 mappings. In what follows we first describe the mappings, then the 382 standard interface, and finally the Mapping System architecture. 384 2.4.1. LISP Mappings 386 Each mapping includes the bindings between EID prefix(es) and set of 387 RLOCs as well as traffic engineering policies, in the form of 388 priorities and weights for the RLOCs. Priorities allow the ETR to 389 configure active/backup policies while weights are used to load- 390 balance traffic among the RLOCs (on a per-flow basis). 392 Typical mappings in LISP bind EIDs in the form of IP prefixes with a 393 set of RLOCs, also in the form of IPs. Such addresses are encoded 394 using a general syntax called LISP Canonical Address Format (LCAF), 395 specified in [I-D.ietf-lisp-lcaf]. The syntax is general enough to 396 support encoding of IPv4 and IPv6 addresses and any other type of 397 value. 399 With such a general syntax for address encoding in place, LISP aims 400 to provide flexibility to current and future applications. For 401 instance LCAFs could support MAC addresses, geo-coordinates, ASCII 402 names and application specific data. 404 2.4.2. Mapping System Interface 406 LISP defines a standard interface between data and control planes. 407 The interface is specified in [RFC6833] and defines two entities: 409 Map-Server: A network infrastructure component that learns mappings 410 from ETRs and publishes them into the LISP Mapping System. 411 Typically Map-Servers are not authoritative to reply to queries 412 and hence, they forward them to the ETR. However they can also 413 operate in proxy-mode, where the ETRs delegate replying to queries 414 to Map-Servers. This setup is useful when the ETR has low 415 resources (i.e., CPU or power). 417 Map-Resolver: A network infrastructure component that interfaces 418 ITRs with the Mapping System by proxying queries and -in some 419 cases- responses. 421 The interface defines four LISP control messages which are sent as 422 UDP datagrams (port 4342): 424 Map-Register: This message is used by ETRs to register mappings in 425 the Mapping System and it is authenticated using a shared key 426 between the ETR and the Map-Server. 428 Map-Notify: When requested by the ETR, this message is sent by the 429 Map-Server in response to a Map-Register to acknowledge the 430 correct reception of the mapping. 432 Map-Request: This message is used by ITRs or Map-Resolvers to 433 resolve the mapping of a given EID. 435 Map-Reply: This message is sent by Map-Servers or ETRs in response 436 to a Map-Request and contains the resolved mapping. Please note 437 that a Map-Reply may contain a negative reply if the queried EID 438 is not part of the LISP EID space. In such cases the ITR 439 typically forwards the traffic natively (non encapsulated) to the 440 public Internet. 442 2.4.3. Mapping System 444 LISP architecturally decouples control and data-plane by means of a 445 standard interface. This interface glues the data-plane, routers 446 responsible of forwarding data-packets, with the LISP Mapping System, 447 a publicly accessible database responsible of storing mappings. 449 With this separation in place the data and control-plane can use 450 different architectures if needed and scale independently. Typically 451 the data-plane is optimized to route packets according to 452 hierarchical IP addresses. However the control-plane may have 453 different requirements, for instance and by taking advantage of the 454 LCAFs, the Mapping System may be used store non-hierarchical keys 455 (such as MAC addresses), requiring different architectural approaches 456 for scalability. Another important difference between the LISP 457 control and data-planes is that, and as a result of the local mapping 458 cache available at ITR, the Mapping System does not need to operate 459 at line-rate. 461 The LISP WG has discussed for the Mapping System architecture the 462 four main techniques available in distributed systems, namely: graph- 463 based databases in the form of LISP+ALT [RFC6836], hierarchical 464 databases in the form of LISP-DDT [I-D.ietf-lisp-ddt], monolithic 465 databases in the form of LISP-NERD [I-D.lear-lisp-nerd] and flat 466 databases in the form of LISP-DHT 467 [I-D.cheng-lisp-shdht],[I-D.mathy-lisp-dht]. Furthermore it is worth 468 noting that, in some scenarios such as private deployments, the 469 Mapping System can operate logically centralized. In such cases it 470 is typically composed of a single Map-Server/Map-Resolver. 472 In what follows we focus on the two mapping systems that have been 473 implemented and deployed (LISP-ALT and LISP+DDT). 475 2.4.3.1. LISP+ALT 477 The LISP Alternative Topology (LISP+ALT) [RFC6836] was the first 478 Mapping System proposed, developed and deployed on the LISP pilot 479 network. It is based on a distributed BGP overlay. All the 480 participating nodes connect to their peers through static tunnels. 481 Every ETR involved in the ALT topology advertises its EID prefixes 482 making the EID routable on the overlay. 484 When an ITR needs a mapping, it sends a Map-Request to a nearby ALT 485 router. The ALT routers then forward the Map-Request on the overlay 486 by inspecting their ALT routing tables. When the Map-Request reaches 487 the ETR responsible for the mapping, a Map-Reply is generated and 488 directly sent to the ITR's RLOC, without using the ALT overlay. 490 2.4.3.2. LISP-DDT 492 LISP-DDT [I-D.ietf-lisp-ddt] is conceptually similar to the DNS, a 493 hierarchical directory whose internal structure mirrors the 494 hierarchical nature of the EID address space. The DDT hierarchy is 495 composed of DDT nodes forming a tree structure, the leafs of the tree 496 are Map-Servers. On top of the structure there is the DDT root node 497 [DDT-ROOT], which is a particular instance of a DDT node and that 498 matches the entire address space. As in the case of DNS, DDT 499 supports multiple redundant DDT nodes and/or DDT roots. The 500 following figure presents a schematic representation of the DDT 501 hierarchy. 503 /---------\ 504 | | 505 | DDT Root| 506 | /0 | 507 ,.\---------/-, 508 ,-'` | `'., 509 -'` | `- 510 /-------\ /-------\ /-------\ 511 | DDT | | DDT | | DDT | 512 | Node | | Node | | Note | ... 513 | 0/8 | | 1/8 | | 2/8 | 514 \-------/ \-------/ \-------/ 515 _. _. . -..,,,_ 516 -` -` \ ````''-- 517 +------------+ +------------+ +------------+ +------------+ 518 | Map-Server | | Map-Server | | Map-Server | | Map-Server | 519 | EID-prefix1| | EID-prefix2| | EID-prefix3| | EID-prefix4| 520 +------------+ +------------+ +------------+ +------------+ 522 Figre 3.- An schematic representation of the DDT tree structure, 523 please note that the prefixes and the structure depitected 524 should be only considered as an example. 526 The DDT structure does not actually index EID-prefixes but eXtended 527 EID-prefixes (XEID). An XEID-prefix is just the concatenation of the 528 following fields (from most significant bit to less significant bit): 529 Database-ID, Instance ID, Address Family Identifier and the actual 530 EID-prefix. The Database-ID is provided for possible future 531 requirements of higher levels in the hierarchy and to enable the 532 creation of multiple and separate database trees. 534 In order to resolve a query LISP-DDT operates iteratively and in a 535 similar way to the DNS. DDT clients (usually Map-Resolvers) generate 536 Map-Requests to the DDT root node. In response they receive a newly 537 introduced LISP-control message: a Map-Referral. A Map-Referral 538 provides the list of RLOCs of the set of DDT nodes matching a 539 configured XEID delegation. That is, the information contained in 540 the Map-Referral points to the child of the queried DDT node that has 541 more specific information about the queried XEID-prefix. This 542 process is repeated until the DDT client walks the tree structure 543 (downwards) and discovers the Map-Server servicing the queried XEID. 544 At this point the client sends a Map-Request and receives a Map-Reply 545 containing the mappings. It is important to note that DDT clients 546 can also cache the information contained in Map-Referrals, that is, 547 they cache the DDT structure. This is used to reduce the mapping 548 retrieving latency[Jakab]. 550 The DDT Mapping System relies on manual configuration. That is Map- 551 Resolvers are manually configured with the set of available DDT root 552 nodes while DDT nodes are manually configured with the appropriate 553 XEID delegations. Configuration changes in the DDT nodes are only 554 required when the tree structure changes itself, but it doesn't 555 depend on EID dynamics (RLOC allocation or traffic engineering policy 556 changes). 558 2.5. Internetworking Mechanisms 560 EIDs are typically identical to either IPv4 or IPv6 addresses and 561 they are announced at the LISP Mapping System, however they are 562 usually not announced in the Internet global routing system. As a 563 result LISP requires an internetworking mechanism to allow LISP sites 564 to speak with non-LISP sites and viceversa. LISP internetworking 565 mechanisms are specified in [RFC6832]. 567 LISP defines two entities to provide internetworking: 569 Proxy Ingress Tunnel Router (PITR): PITRs provide connectivity from 570 the legacy Internet to LISP sites. PITRs announce in the global 571 routing system blocks of EID prefixes (aggregating when possible) 572 to attract traffic. For each incoming data-packet, the PITR LISP- 573 encapsulates it towards the RLOC(s) of the appropriate LISP site. 574 The impact of PITRs in the routing table size of the DFZ is, in 575 the worst-case, similar to the case in which LISP is not deployed. 576 EID-prefixes will be aggregated as much as possible both by the 577 PITR and by the global routing system. 579 Proxy Engress Tunnel Router (PETR): PETRs provide connectivity from 580 LISP sites to the legacy Internet. In some scenarios, LISP sites 581 may be unable to send encapsulated packets to the legacy Internet. 582 For instance when Unicast Reverse Path Forwarding (uRPF) is used 583 by Provider Edge routers, or when an intermediate network between 584 a LISP site and a non-LISP site does not support the desired 585 version of IP (IPv4 or IPv6). In both cases the PETR allows to 586 overcome such limitations by encapsulating packets over the 587 network. Finally, the RLOC of PETRs must be statically configured 588 in ITRs. 590 3. LISP Operational Mechanisms 592 In this section we detail the main operational mechanisms defined in 593 LISP. 595 3.1. Cache Management 597 LISP's decoupled control and data-plane, where mappings are stored in 598 the control-plane and used for forwarding in the data plane, requires 599 of a local cache in ITRs to reduce signaling overhead (Map-Request/ 600 Map-Reply) and increase forwarding speed. The local cache available 601 at the ITRs, called Map-Cache, is used by the router to LISP- 602 encapsulate packets. The Map-Cache is indexed by (Instance ID, EID- 603 prefix) and contains basically the set of RLOCs with the associated 604 traffic engineering policies (priorities and weights). 606 The Map-Cache, as any other cache, requires cache coherence 607 mechanisms to maintain up-to-date information. LISP defines three 608 main mechanisms for cache coherence: 610 Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon 611 expiration of the TTL the ITR could refresh the mapping by sending 612 a new Map-Request. Typical values for TTL defined by LISP are 613 24h. 615 Solicit-Map-Request (SMR): SMR is an explicit mechanism to update 616 mapping information. In particular a special type of Map-Request 617 can be sent on demand by ETRs to request refreshing a mapping. 618 Upon reception of a SMR message, the ITR must refresh the bindings 619 by sending a Map-Request to the Mapping System. 621 Map-Versioning: This optional mechanism piggybacks in the LISP 622 header of data-packets the version number of the mappings used by 623 an xTR. This way, when an xTR receives a LISP-encapsulated packet 624 from a remote xTR, it can check whether its own Map-Cache or the 625 one of the remote xTR is outdated. If its Map-Cache is outdated, 626 it sends a Map-Request for the remote EID so to obtain the newest 627 mappings. On the contrary, if it detects that the remote xTR Map- 628 Cache is outdated, it sends it a SMR to notify it that a new 629 mapping is available. 631 3.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 of explicit mechanisms to propagate 640 reachability information. LISP defines a set of mechanisms to inform 641 ITRs and 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 are up/down. This information can be 646 used by the ITRs as a hint about the reachability to perform 647 additional checks. Also note that LSB does not provide path 648 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 and waiting in 664 return a Map-Reply, also sent on the data-plane. The active nature 665 of RLOC-probing provides an effective mechanism to determine 666 reachability and, in case of failure, switching to a different 667 locator. Furthermore the mechanism also provides useful RTT 668 estimates of the delay of the path that can be used by other network 669 algorithms. 671 Additionally, LISP also recommends inferring reachability of locators 672 by using information provided by the underlay, in particular: 674 ICMP signaling: The LISP underlay -the current Internet- uses the 675 ICMP protocol to signal unreachability (among other things). LISP 676 can take advantage of this and the reception of a ICMP Network 677 Unreachable or ICMP Host Unreachable message can be seen as a hint 678 that a locator might be unreachable, this should lead to perform 679 additional checks. 681 Underlay routing: Both BGP and IBGP carry reachability information, 682 LISP-capable routers that have access to underlay routing information 683 can use it to determine if a given locator or path are reachable. 685 3.3. ETR Synchronization 687 All the ETRs that are authoritative to a particular EID-prefix must 688 announce the same mapping to the requesters, this means that ETRs 689 must be aware of the status of the RLOCs of the remaining ETRs. This 690 is known as ETR synchronization. 692 At the time of this writing LISP does not specify a mechanism to 693 achieve ETR synchronization. Although many well-known techniques 694 could be applied to solve this issue it is still under research, as a 695 result operators must rely on coherent manual configuration 697 3.4. MTU Handling 699 Since LISP encapsulates packets it requires dealing with packets that 700 exceed the MTU of the path between the ITR and the ETR. Specifically 701 LISP defienes two mechanisms: 703 Stateless: With this mechanism ITRs fragment packets that are too 704 big, typically reassembly is performed at the destination host. 706 Stateful: With this mechanism ITRs keep track of the MTU of the 707 paths towards the destination locators by parsing the ICMP Too Big 708 packets sent by intermediate routers. 710 In both cases if the packet cannot be framgneted (IPv4 with DF=1 or 711 IPv6) then the ITR drops it and replies with a ICMP Too Big message 712 to the source. 714 4. Mobility 716 LISP can also be used to enable mobility of devices not located in 717 LISP networks. The problem with mobility of such devices is that 718 their IP address changes whenever they change location, interrupting 719 so flows. 721 To enable mobility on such devices, the device can implement the xTR 722 functionality where the IP address presented to applications is an 723 EID that never changes while the IP address obtained from the network 724 is used by the xTR as RLOC. Packets are then transported on the 725 network using the IP address assigned to the device by the visited 726 network while at the application level IP addresses remain 727 independent of the location of the device. 729 Whenever the device changes of RLOC, the ITR updates the RLOC of its 730 local mapping and registers it to its Map-Server. To avoid the need 731 of a home gateway, the ITR also indicates the RLOC change to all 732 remote devices that have ongoing communications with the device that 733 moved. The combination of both methods ensures the scalability of 734 the system as signalling is strictly limited the Map-Server and to 735 hosts with which communications are ongoing. 737 5. Multicast 739 LISP also supports multicast environments, the operational changes 740 required to the multicast protocols are documented in [RFC6831]. 742 In such scenarios, LISP creates multicast state both at the core and 743 at the sites (both source and receiver). In order to create 744 multicast state at the sites, LISP routers unicast encapsulate PIM 745 Join/Prune messages from receiver to source sites. At the core, ETRs 746 build a new PIM Join/Prune message addressed to the RLOC of the ITR 747 servicing the source. An simplified sequence is shown below: 749 1. An end-host that belongs to a LISP site transmits a PIM Join/ 750 Prune message (S-EID,G) to join a multicast group. 752 2. The join message flows to the ETR, upon reception the ETR builds 753 two join messages, the first one unicast LISP-encapsulates the 754 original join message towards the RLOC of the ITR servicing the 755 source. This message creates multicast state at the source site. 756 The second join message contains as destination address the RLOC 757 of the ITR servicing the source (S-RLOC, G) and creates multicast 758 state at the core. 760 3. Multicast data packets originated by the source (S-EID, G) flow 761 from the source to the ITR. The ITR LISP-encapsulates the 762 multicast packets, the outter header includes its own RLOC as the 763 source (S-RLOC) and the original multicast group address (G) as 764 the destination. Please note that multicast group address are 765 logical and are not resolved by the mapping system. Then the 766 multicast packet is transmitted through the core towards the 767 receiving ETRs that decapsulates the packets and sends them using 768 the receiver's site multicast state. 770 6. Security 772 LISP uses a pull architecture to learn mappings. While in a push 773 system, the state necessary to forward packets is learned 774 independently of the traffic itself, with a pull architecture, the 775 system becomes reactive and data-plane events (e.g., the arrival of a 776 packet for an unknown destination) may trigger control-plane events. 777 This on-demand learning of mappings provides many advantages as 778 discussed above but may also affect the way security must be 779 envisioned. 781 Usually, the data-plane is implemented in the fast path of routers to 782 provide high performance forwarding capabilities while the control- 783 plane features are implemented in the slow path to offer high 784 flexibility and a performance gap of several order of magnitude can 785 be observed between the slow and the fast paths. As a consequence, 786 the way data-plane events are notified to the control-plane must be 787 though carefully so to not overload the slow path and rate limiting 788 should be used as specified in [RFC6830]. 790 Care must also been taken so to not overload the mapping system 791 (i.e., the control plane infrastructure) as the operations to be 792 performed by the mapping system may be more complex than those on the 793 data-plane, for that reason [RFC6830] recommends to rate limit the 794 sending of messages to the mapping system. 796 To improve resiliency and reduce the overall number of messages 797 exchanged, LISP offers the possibility to leak control informations, 798 such as reachabilty of locators, directly into data plane packets. 799 In environments that are not fully trusted, control informations 800 gleaned from data-plane packets should be verified before using them. 802 Mappings are the centrepiece of LISP and all precautions must be 803 taken to avoid them to be manipulated or misused by malicious 804 entities. Using trustable Map-Server that strictly respect [RFC6833] 805 and the lightweight authentication mechanism proposed by LISP-Sec 806 [I-D.ietf-lisp-sec] is a possibility to reduce the risk. In more 807 critical environments, stronger authentication may have to be used. 809 Packets are transported encapsulated with LISP meaning that devices 810 on the path between an ITR (or PITR) and an ETR (or PETR) cannot 811 correctly inspect the content of packets unless they implement 812 methods to strip the headers added by LISP. Similarly, mappings 813 enable triangular routing (i.e., packets of a flow cross different 814 border routers depending on their direction) which means that 815 intermediate boxes may have incomplete view on the traffic they 816 inspect or manipulate. 818 More details about security implications of LISP can be found in 819 [I-D.ietf-lisp-threats]. 821 7. Use Cases 823 7.1. Traffic Engineering 825 BGP is the standard protocol to implement inter-domain routing. With 826 BGP, routing informations are propagated along the network and each 827 autonomous system can implement its own routing policy that will 828 influence the way routing information are propagated. The direct 829 consequence is that an autonomous system cannot precisely control the 830 way the traffic will enter the network. 832 As opposed to BGP, a LISP site can strictly impose via which ETRs the 833 traffic must enter the network even though the path followed to reach 834 the ETR is not under the control of the LISP site. This fine control 835 is implemented with the mappings. When a remote site is willing to 836 send traffic to a LISP site, it retrieves the mapping associated to 837 the destination EID via the mapping system. The mapping is sent 838 directly by the owner of EID and is not altered by any intermediate 839 network. 841 A mapping associates a list of RLOCs to an EID prefix. Each RLOC 842 corresponds to an interface of an ETR that is able to correctly 843 forward packets to EIDs in the prefix. Each RLOC is tagged with a 844 priority and a weight in the mapping. The priority is used to 845 indicates which RLOCs should be preferred to send packets (the least 846 preferred ones being provided for backup purpose). The weight 847 permits to balance the load between the RLOCs with the same priority, 848 proportionally to the weight value. 850 As mappings are directly issued by the owner of the EID and not 851 altered while transmitted to the remote site, it offers highly 852 flexible incoming inter-domain traffic engineering with even the 853 possibility for a site to issue a different mapping for each remote 854 site, implementing so precise routing policies. 856 7.2. LISP for IPv6 Transition 858 LISP encapsulations permits to transport packets using EIDs from a 859 given address family (e.g., IPv6) with packets with addresses 860 belonging to another address family (e.g., IPv4). The absence of 861 correlation between the address family of RLOCs and EIDs makes LISP a 862 candidate to ease the transition to IPv4. 864 For example, two IPv6-only data centers could be interconnected via 865 the legacy IPv4 Internet. If their border routers are LISP capable, 866 sending packets between the data center is done without any form of 867 translation as the native IPv6 packets (in the EID space) will be 868 LISP encapsulated and transmitted over the IPv4 legacy Internet by 869 the mean of IPv4 RLOCs. 871 7.3. LISP for Network Virtualization 873 It is nowadays common to operate several virtual networks over the 874 same physical infrastructure. The current approach usually rely on 875 BGP/MPLS VPNs, where BGP is used to exchange routing information and 876 MPLS to segregate packets of the different logical networks. This 877 functionality could be achieved with LISP where the mappings and the 878 mapping system are used instead of BGP and the LISP encapsulation is 879 used to replace MPLS. 881 In virtual networks, it is essential to distinguish to which virtual 882 network a packet belongs and tags or labels are used for that 883 purpose. With LISP, the distinction can be made with the Instance ID 884 field. When an ITR encapsulates a packet from a particular virtual 885 network (e.g., known via the VRF or VLAN), it tags the encapsulated 886 packet with the Instance ID corresponding to the virtual network of 887 the packet. When an ETR receives a packet tagged with an Instance ID 888 it uses the Instance ID to determine how to threat the packet. 890 Appart from the simplicity of managing mappings, the advantage of 891 using LISP for virtual network is that it does not impose any 892 requirement on the underlying network, except running IP. 894 7.4. LISP for Virtual Machine Mobility in Data Centers 896 A way to enable seamless virtual machine mobility in data center is 897 to conceive the datacenter backbone as the RLOC space and the 898 subnetworks where servers are hosted as forming the EID space. A 899 LISP router is placed at the border between the backbone and each 900 sub-network. When a virtual machine is moved to another subnetwork, 901 it can (temporarily) keep the address of the sub-network it was 902 hosted before the move so to allow ongoing communications to subsist. 903 When a subnetwork detects the presence of a host with an address that 904 does not belong to the subnetwork (e.g., via a message sent by the 905 hypervisor), the LISP router of the new subnetwork registers the IP 906 address of the virtual machine as an EID to the Map-Server of the 907 subnetwork and associates its own address as RLOC. 909 To inform the other LISP routers that the machine moved and where, 910 and then to avoid detours via the initial subnetwork, every Map- 911 Server can listen on a predefined multicast address that is used as 912 source address for Map-Register. As a result, the Map-Notify sent 913 back by the Map-Server will be received by all the LISP routers that 914 hence automatically learn the new location of the virtual machine. 916 8. Security Considerations 918 This document does not specify any protocol or operational practices 919 and hence, does not have any security considerations. 921 9. IANA Considerations 923 This memo includes no request to IANA. 925 10. Acknowledgements 927 To Do. 929 11. References 931 11.1. Normative References 933 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 934 Requirement Levels", BCP 14, RFC 2119, March 1997. 936 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 937 Gill, "IPv4 Multihoming Practices and Limitations", RFC 938 4116, July 2005. 940 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 941 Workshop on Routing and Addressing", RFC 4984, September 942 2007. 944 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 945 Locator/ID Separation Protocol (LISP)", RFC 6830, January 946 2013. 948 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 949 Locator/ID Separation Protocol (LISP) for Multicast 950 Environments", RFC 6831, January 2013. 952 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 953 "Interworking between Locator/ID Separation Protocol 954 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 956 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 957 Protocol (LISP) Map-Server Interface", RFC 6833, January 958 2013. 960 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 961 Separation Protocol (LISP) Map-Versioning", RFC 6834, 962 January 2013. 964 [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation 965 Protocol Internet Groper (LIG)", RFC 6835, January 2013. 967 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 968 "Locator/ID Separation Protocol Alternative Logical 969 Topology (LISP+ALT)", RFC 6836, January 2013. 971 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 972 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 974 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 975 for the Use of IPv6 UDP Datagrams with Zero Checksums", 976 RFC 6936, April 2013. 978 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 979 Pascual, J., and D. Lewis, "Locator/Identifier Separation 980 Protocol (LISP) Network Element Deployment 981 Considerations", RFC 7215, April 2014. 983 11.2. Informative References 985 [Chiappa] Chiappa, J., "Endpoints and Endpoint names: A Propose 986 Enhancement to the Internet Architecture, 987 http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt", 1999. 989 [DDT-ROOT] 990 LISP DDT ROOT, , "http://ddt-root.org/", August 2013. 992 [DFZ] Huston, Geoff., "Growth of the BGP Table - 1994 to Present 993 http://bgp.potaroo.net/", August 2013. 995 [I-D.cheng-lisp-shdht] 996 Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping 997 Overlay", draft-cheng-lisp-shdht-04 (work in progress), 998 July 2013. 1000 [I-D.ermagan-lisp-nat-traversal] 1001 Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, 1002 F., and C. White, "NAT traversal for LISP", draft-ermagan- 1003 lisp-nat-traversal-03 (work in progress), March 2013. 1005 [I-D.ietf-lisp-ddt] 1006 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 1007 Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in 1008 progress), March 2013. 1010 [I-D.ietf-lisp-lcaf] 1011 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1012 Address Format (LCAF)", draft-ietf-lisp-lcaf-05 (work in 1013 progress), May 2014. 1015 [I-D.ietf-lisp-sec] 1016 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 1017 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-06 1018 (work in progress), April 2014. 1020 [I-D.ietf-lisp-threats] 1021 Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats 1022 Analysis", draft-ietf-lisp-threats-10 (work in progress), 1023 July 2014. 1025 [I-D.lear-lisp-nerd] 1026 Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 1027 draft-lear-lisp-nerd-08 (work in progress), March 2010. 1029 [I-D.mathy-lisp-dht] 1030 Mathy, L., Iannone, L., and O. Bonaventure, ""LISP-DHT: 1031 Towards a DHT to map identifiers onto locators" draft- 1032 mathy-lisp-dht-00 (work in progress)", April 2008. 1034 [Jakab] Jakab, L., Cabellos, A., Saucez, D., and O. Bonaventure, 1035 "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping 1036 System, IEEE Journal on Selected Areas in Communications, 1037 vol. 28, no. 8, pp. 1332-1343", October 2010. 1039 [Quoitin] Quoitin, B., Iannone, L., Launois, C., and O. Bonaventure, 1040 ""Evaluating the Benefits of the Locator/Identifier 1041 Separation" in Proceedings of 2Nd ACM/IEEE International 1042 Workshop on Mobility in the Evolving Internet 1043 Architecture", 2007. 1045 Appendix A. A Brief History of Location/Identity Separation 1047 The LISP system for separation of location and identity resulted from 1048 the discussions of this topic at the Amsterdam IAB Routing and 1049 Addressing Workshop, which took place in October 2006 [RFC4984]. 1051 A small group of like-minded personnel from various scattered 1052 locations within Cisco, spontaneously formed immediately after that 1053 workshop, to work on an idea that came out of informal discussions at 1054 the workshop. The first Internet-Draft on LISP appeared in January, 1055 2007, along with a LISP mailing list at the IETF. 1057 Trial implementations started at that time, with initial trial 1058 deployments underway since June 2007; the results of early experience 1059 have been fed back into the design in a continuous, ongoing process 1060 over several years. LISP at this point represents a moderately 1061 mature system, having undergone a long organic series of changes and 1062 updates. 1064 LISP transitioned from an IRTF activity to an IETF WG in March 2009, 1065 and after numerous revisions, the basic specifications moved to 1066 becoming RFCs at the start of 2013 (although work to expand and 1067 improve it, and find new uses for it, continues, and undoubtly will 1068 for a long time to come). 1070 A.1. Old LISP Models 1072 LISP, as initilly conceived, had a number of potential operating 1073 modes, named 'models'. Although they are now obsolete, one 1074 occasionally sees mention of them, so they are briefly described 1075 here. 1077 LISP 1: EIDs all appear in the normal routing and forwarding tables 1078 of the network (i.e. they are 'routable');this property is used to 1079 'bootstrap' operation, by using this to load EID->RLOC mappings. 1080 Packets were sent with the EID as the destination in the outer 1081 wrapper; when an ETR saw such a packet, it would send a Map-Reply 1082 to the source ITR, giving the full mapping. 1084 LISP 1.5: Similar to LISP 1, but the routability of EIDs happens on 1085 a separate network. 1087 LISP 2: EIDs are not routable; EID->RLOC mappings are available from 1088 the DNS. 1090 LISP 3: EIDs are not routable; and have to be looked up in in a new 1091 EID->RLOC mapping database (in the initial concept, a system using 1092 Distributed Hash Tables). Two variants were possible: a 'push' 1093 system, in which all mappings were distributed to all ITRs, and a 1094 'pull' system in which ITRs load the mappings they need, as 1095 needed. 1097 Authors' Addresses 1099 Albert Cabellos 1100 UPC-BarcelonaTech 1101 c/ Jordi Girona 1-3 1102 Barcelona, Catalonia 08034 1103 Spain 1105 Email: acabello@ac.upc.edu 1107 Damien Saucez (Ed.) 1108 INRIA 1109 2004 route des Lucioles BP 93 1110 Sophia Antipolis Cedex 06902 1111 France 1113 Email: damien.saucez@inria.fr