idnits 2.17.1 draft-ietf-lisp-introduction-04.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 2 instances of too long lines in the document, the longest one being 4 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 date (July 16, 2014) is 3571 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'NAT-Traversal' is mentioned on line 2756, but not defined == Unused Reference: 'I-D.meyer-lisp-mn' is defined on line 2243, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 2254, but no explicit reference was found in the text == Unused Reference: 'RFC4026' is defined on line 2409, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ermagan-lisp-nat-traversal-05 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-06 == 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 (-16) exists of draft-meyer-lisp-mn-10 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** 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) -- No information found for draft-chiappa-lisp-evolution - is the name correct? == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-00 -- No information found for draft-chiappa-lisp-improvements - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1631 (Obsoleted by RFC 3022) -- Obsolete informational reference (is this intentional?): RFC 3272 (Obsoleted by RFC 9522) Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Cabellos-Aparicio (Ed.) 3 Internet-Draft Technical University of Catalonia 4 Intended status: Informational D. Saucez (Ed.) 5 Expires: January 17, 2015 INRIA 6 July 16, 2014 8 An Architectural Introduction to the LISP Location-Identity 9 Separation System 10 draft-ietf-lisp-introduction-04.txt 12 Abstract 14 This document is an introductory overview of the Locator/ID 15 Separation Protocol, it describes the major concepts and functional 16 sub-systems of LISP and the interactions between them. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 17, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Prefatory Note . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Part I . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Initial Glossary . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Deployment Philosophy . . . . . . . . . . . . . . . . . . . . 7 57 5.1. Economics . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5.2. Maximize Re-use of Existing Mechanism . . . . . . . . . . 8 59 6. LISP Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 60 6.1. Basic Approach . . . . . . . . . . . . . . . . . . . . . 9 61 6.2. Basic Functionality . . . . . . . . . . . . . . . . . . . 9 62 6.3. Mapping from EIDs to RLOCs . . . . . . . . . . . . . . . 11 63 6.4. Interworking With Non-LISP-Capable Endpoints . . . . . . 11 64 6.5. Security in LISP . . . . . . . . . . . . . . . . . . . . 12 65 7. Initial Applications . . . . . . . . . . . . . . . . . . . . 13 66 7.1. Provider Independence . . . . . . . . . . . . . . . . . . 13 67 7.2. Multi-Homing . . . . . . . . . . . . . . . . . . . . . . 13 68 7.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 14 69 7.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 7.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 15 71 7.6. Traversal Across Alternate IP Versions . . . . . . . . . 15 72 7.7. Virtual Private Networks . . . . . . . . . . . . . . . . 16 73 7.8. Local Uses . . . . . . . . . . . . . . . . . . . . . . . 16 74 8. Major Functional Subsystems . . . . . . . . . . . . . . . . . 17 75 8.1. Data Plane - xTRs Overview . . . . . . . . . . . . . . . 17 76 8.1.1. Mapping Cache Performance . . . . . . . . . . . . . . 18 77 8.2. Control Plane - Mapping System Overview . . . . . . . . . 18 78 8.2.1. Mapping System Organization . . . . . . . . . . . . . 19 79 8.2.2. Interface to the Mapping System . . . . . . . . . . . 20 80 8.2.3. Indexing Sub-system . . . . . . . . . . . . . . . . . 20 81 9. Examples of operation . . . . . . . . . . . . . . . . . . . . 22 82 9.1. An Ordinary Packet's Processing . . . . . . . . . . . . . 22 83 9.2. A Mapping Cache Miss . . . . . . . . . . . . . . . . . . 23 84 10. Part II . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 11. Design Approach . . . . . . . . . . . . . . . . . . . . . . . 24 86 12. xTRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 87 12.1. When to Encapsulate . . . . . . . . . . . . . . . . . . 25 88 12.2. UDP Encapsulation Details . . . . . . . . . . . . . . . 26 89 12.3. Header Control Channel . . . . . . . . . . . . . . . . . 26 90 12.3.1. Mapping Versioning . . . . . . . . . . . . . . . . . 26 91 12.3.2. Echo Nonces . . . . . . . . . . . . . . . . . . . . 27 92 12.3.3. Instances . . . . . . . . . . . . . . . . . . . . . 27 93 12.4. Probing . . . . . . . . . . . . . . . . . . . . . . . . 28 94 12.5. Mapping Lifetimes and Timeouts . . . . . . . . . . . . . 28 95 12.6. Mapping Gleaning in ETRs . . . . . . . . . . . . . . . . 29 96 12.7. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . 29 97 12.8. Security of Mapping Lookups . . . . . . . . . . . . . . 29 98 12.9. ITR Mapping Cache Performance . . . . . . . . . . . . . 30 99 13. The Mapping System . . . . . . . . . . . . . . . . . . . . . 31 100 13.1. The Mapping System Interface . . . . . . . . . . . . . . 32 101 13.1.1. Map-Request Messages . . . . . . . . . . . . . . . . 32 102 13.1.2. Map-Reply Messages . . . . . . . . . . . . . . . . . 32 103 13.1.3. Map-Register and Map-Notify Messages . . . . . . . . 33 104 13.2. The DDT Indexing Sub-system . . . . . . . . . . . . . . 34 105 13.3. Reliability via Replication . . . . . . . . . . . . . . 35 106 13.4. Security of the DDT Indexing Sub-system . . . . . . . . 35 107 13.5. Extended Capabilities . . . . . . . . . . . . . . . . . 36 108 13.6. Performance of the Mapping System . . . . . . . . . . . 36 109 14. Multicast Support in LISP . . . . . . . . . . . . . . . . . . 37 110 14.1. Basic Concepts of Multicast Support in LISP . . . . . . 37 111 14.2. Initial Multicast Support in LISP . . . . . . . . . . . 38 112 15. Deployment Issues and Mechanisms . . . . . . . . . . . . . . 39 113 15.1. LISP Deployment Needs . . . . . . . . . . . . . . . . . 39 114 15.2. Interworking Mechanisms . . . . . . . . . . . . . . . . 40 115 15.2.1. Proxy LISP Routers . . . . . . . . . . . . . . . . . 40 116 15.2.2. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . 42 117 15.3. Use Through NAT Devices . . . . . . . . . . . . . . . . 42 118 15.4. LISP and Core Internet Routing . . . . . . . . . . . . . 43 119 16. Fault Discovery/Handling . . . . . . . . . . . . . . . . . . 43 120 16.1. Handling Missing Mappings . . . . . . . . . . . . . . . 44 121 16.2. Outdated Mappings . . . . . . . . . . . . . . . . . . . 44 122 16.2.1. Outdated Mappings - Updated Mapping . . . . . . . . 44 123 16.2.2. Outdated Mappings - Wrong ETR . . . . . . . . . . . 44 124 16.2.3. Outdated Mappings - No Longer an ETR . . . . . . . . 45 125 16.3. Erroneous Mappings . . . . . . . . . . . . . . . . . . . 45 126 16.4. Verifying ETR Liveness . . . . . . . . . . . . . . . . . 45 127 16.5. Verifying ETR Reachability . . . . . . . . . . . . . . . 46 128 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 129 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 130 19. Security Considerations . . . . . . . . . . . . . . . . . . . 47 131 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 132 20.1. Normative References . . . . . . . . . . . . . . . . . . 47 133 20.2. Informative References . . . . . . . . . . . . . . . . . 49 134 Appendix A. Glossary/Definition of Terms . . . . . . . . . . . . 52 135 Appendix B. Other Appendices . . . . . . . . . . . . . . . . . . 55 136 B.1. A Brief History of Location/Identity Separation . . . . 55 137 B.2. A Brief History of the LISP Project . . . . . . . . . . . 56 138 B.3. Old LISP 'Models' . . . . . . . . . . . . . . . . . . . . 56 139 B.4. The ALT Mapping Indexing Sub-system . . . . . . . . . . . 57 140 B.5. Early NAT Support . . . . . . . . . . . . . . . . . . . . 58 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 143 1. Prefatory Note 145 {{Suggestion by editors: Remove all the sections before "LISP 146 Overview" and write a straight-to-the-point introduction}} 148 {{Suggestion by editors: The draft should focus on describing the 149 LISP architecture and avoid comparing loc/id split architectures with 150 other approaches}} 152 This document is the first of a pair which, together, form what one 153 would think of as the 'architecture document' for LISP (the 154 'Location-Identity Separation Protocol'). Much of what would 155 normally be in an architecture document (e.g. the architectural 156 design principles used in LISP, and the design considerations behind 157 various components and aspects of the LISP system) is in the second 158 document, the 'Architectural Perspective on LISP' document. 159 [I-D.ietf-lisp-perspective] 161 This 'Architectural Introduction' document is primarily intended for 162 those who are unfamiliar with LISP, and want to start learning about 163 it. It is intended primarily for those working on LISP, but those 164 working with LISP, and more generally anyone who wants to know more 165 about LISP, may also find this document useful. 167 This document is intended to both be easy to follow and it is 168 structured as a series of phases, each covering the entire system, 169 but with ever-increasing detail. Reading only the first part of the 170 document will give a good high-level view of the system; reading the 171 complete document should provide a fairly detailed understanding of 172 the entire system. 174 People who just want to get an idea of how LISP works might only read 175 the first part; they can stop reading either just before, or just 176 after Section 9. People who are going to go on and read the protocol 177 specifications (perhaps to implement LISP) should read the entire 178 document. 180 This document is a descriptive document, not a protocol 181 specification. Should it differ in any detail from any of the LISP 182 protocol specification documents, they take precedence for the actual 183 operation of the protocol. 185 2. Part I 186 3. Initial Glossary 188 This initial glossary defines a few general terms which will be 189 useful to have in hand when commencing reading this document. A 190 complete glossary is available in Appendix A. 192 A note about style: initial usage of a term defined in the glossary 193 is denoted with double quotation marks ("). Other uses of quotations 194 (e.g. for quotations, euphemisms, etc) use single quotation marks 195 ('). 197 o Name: a name refers to an identifier for an object or entity. 198 Names have both semantics (meaning) and syntax (form) [RFC1498]. 200 o Namespace: A group of names with matching semantics and syntax; 201 they usually, but not always, refer to members of a class of 202 identical objects. 204 o Mapping: a binding between two names, one in each of two 205 namespaces. 207 o Delegation Hierarchy: an abstract rooted tree (in the graph theory 208 sense of the term) which is a virtual representation of the 209 delegation of a namespace into smaller and smaller blocks, in a 210 recursive process. 212 o Node: The general term used to describe any sort of communicating 213 entity; it might be a physical or a virtual host, or a mobile 214 device of some sort. It includes both entities which forward 215 packets, and entities which create or consume packets. 217 o Switch, Packet Switch: A packet switch, in the general meaning of 218 that term. A device which takes in packets from its interfaces 219 and forwards them on, either to a next-hop switch, or to the final 220 destination. They may operate at either the network layer (e.g. 221 ARPANET), or internetwork layer. [Baran][Heart][RFC1812] 223 o Endpoint, end-end communication entity: The fate-sharing region at 224 one end of an end-end communication; the collection of state 225 related to both the reliable end-end communication channel, and 226 the applications running there. [Chiappa] 228 o Address: In this document, in current IP (IPv4 or IPv6) and 229 similar networking suites, a "name" which has mixed semantics, in 230 that it includes both identity ('who') and location ('where') 231 semantics. [Atkinson] 233 o Address Block, Block: A contiguous section of a namespace (e.g., 234 IP addresses that belong to the same prefix). 236 o Identifier: a name which has identity semantics. 238 o Locator: name with only location semantics and not necessarily 239 carried in every packet [RFC1992]. 241 o Site: A collection of hosts, routers, and networks under a single 242 administrative control. 244 o LISP site: a site separated from the rest of the network by LISP 245 routers. 247 o LISP node: A network element implementing LISP functionality; this 248 means it can process some subset of LISP control and planes 249 traffic. 251 o LISP router: A network element implementing LISP data-plane 252 functionality, i.e., a LISP node which can forward user traffic. 254 o LISP host: A host which is behind (from the point of view of the 255 rest of the network) a LISP router. 257 4. Background 259 It has gradually been realized in the networking community that 260 networks, especially large networks, should deal quite separately 261 with the identity and location of an endpoint - basically, who an 262 endpoint is, and where it is ([RFC1498] [RFC4984]). 264 At the moment of this writing, in both IPv4 and IPv6, IP addresses 265 indicate both where the named node is, as well as identify it for 266 purposes of end-end communication; i.e. it has both location and 267 identity properties. However, the separation of those two properties 268 is a step which has been identified by the IRTF as a necessary 269 evolutionary architectural step for the Internet [RFC6115] and the 270 on-going LISP project is an attempt to provide a viable path towards 271 this separation. 273 As an add-on to a large existing system, it has had to make certain 274 compromises. (For a good example, see [I-D.ietf-lisp-perspective], 275 Section "Residual Location Functionality in EIDs". However, if it 276 reaches near-ubiquitous deployment, it will have two important 277 consequences. 279 First, in effectively providing separation of location and identity, 280 along with providing a distributed directory of the mappings between 281 them, 'Wheeler's Law' ('All problems in computer science can be 282 solved by another level of indirection') will come into play, and the 283 Internet technical community will have a new, immensely powerful, 284 tool at its disposal. The fact that the namespaces on both sides of 285 the mapping are global ones maximizes the power of that tool. (See 286 [I-D.ietf-lisp-perspective], Section "Need for a Mapping System", for 287 more on this.) 289 Second, because of a combination of the flexible capability built 290 into LISP, and the breaking of the unification of location and 291 identity names, further architectural evolution of the Internet 292 becomes easily available; for example, new namespaces for location or 293 identity could be designed and deployed. In other words, LISP is not 294 a point solution to meet a particular need, but hopefully an 'escape 295 hatch' which will allow further significant enhancement to the 296 Internet's overall architecture. (See [Future] for more on this.) 298 5. Deployment Philosophy 300 {{Suggestion by editors: Remove the entire section, it can be 301 summarized by the last paragraph. Furthermore the arguments used in 302 this sections are hard to follow since LISP has not been described 303 yet.}} 305 The deployment philosophy was a major driver for the design of LISP 306 (architecture and engineering). 308 Experience over the last several decades has shown that having a 309 viable deployment model for a new design is a key to the adoption of 310 the solution. In general, it is comparatively easy to conceive of 311 new network designs, but much harder to devise approaches which will 312 actually get deployed throughout the global network. A new design 313 may be fantastic but if it can not be successfully deployed (for 314 whatever factors), it is useless. 316 LISP aims to achieve the near-ubiquitous deployment necessary for 317 maximum exploitation of an architectural upgrade by i) minimizing the 318 amount of change needed (most existing hosts and routers can operate 319 unmodified); and ii) by providing significant benefits to early 320 adopters. 322 5.1. Economics 324 {{Suggestion by editors: Remove this section, this has not been 325 discussed by the WG}} 327 A key factor in successful adoption is economics: does the new design 328 have benefits which outweigh its costs? 329 More importantly, this balance needs to hold for early adopters - 330 because if they do not receive benefits to their adoption, the sphere 331 of earliest adopters will not expand, and it will never get to 332 widespread deployment. 334 This is particularly true of architectural enhancements, which are 335 far less likely to be an addition which one can bolt onto the side of 336 existing mechanisms, and often offer their greatest benefits only 337 when widely (or ubiquitously) deployed. 339 Maximizing the cost-benefit ratio obviously has two aspects. First, 340 on the cost side, by making the design as inexpensive as possible, 341 which means in part making the deployment as easy as possible. 342 Second, on the benefit side, by providing many new capabilities, 343 which is best done not by loading the design up with lots of features 344 or options (which adds complexity), but by making the addition 345 powerful through deeper flexibility. The LISP community believes 346 LISP has met both of these goals. 348 5.2. Maximize Re-use of Existing Mechanism 350 {{Suggestion by editors: Remove/Summarize the entire section, the 351 arguments used in this section are hard to follow since LISP has not 352 been described yet.}} 354 One key part of reducing the cost of a new design is to minimize the 355 amount of change required to existing, deployed, devices: the fewer 356 devices need to be changed, and the smaller the change to those that 357 do, the greater the likelihood of deployment. 359 Designs which absolutely require forklift upgrades to large amounts 360 of existing gear are far less likely to succeed - because they have 361 to have extremely large benefits to make their very substantial costs 362 worthwhile. 364 It is for this reason that LISP, in most cases, initially requires no 365 changes to almost all existing devices in the Internet (both hosts 366 and routers); LISP functionality needs to be added in only a few 367 places ( Section 15.1) 369 6. LISP Overview 371 LISP is an incrementally deployable architectural upgrade to the 372 existing Internet infrastructure, one which provides separation of 373 location and identity. It thus starts to separate the names used for 374 identity and location of nodes, which are currently unified in IP 375 addresses. 377 6.1. Basic Approach 379 {{Suggestion by editors: Merge this section with the previous one 380 (LISP Overview)}} 382 In LISP, the first key concept is that nodes have both an identifier 383 called an Endpoint IDentifier (EID) and an associated Routing Locator 384 (RLOC). A node may be associated with more than one RLOC, or the 385 RLOC may change over time (e.g., if the node is mobile), but it would 386 normally always have the same EID. 388 The second key concept is that if one wants to be as forward-looking 389 as possible, conceptually one should think of the two kinds of names 390 (EIDs and RLOCs) as naming different classes of entities. 392 On the one hand, EIDs are used to name nodes - or rather, their end- 393 end communication entities. RLOC(s), on the other hand, name 394 interfaces, i.e. places to which the system of routers sends packets. 396 This distinction, the formal recognition of different kinds of 397 entities ("endpoints" and interfaces), and their association with the 398 two different classes of names, is also important. Clearly 399 recognizing interfaces and endpoints as distinctly separate classes 400 of objects is another improvement to the existing Internet 401 architecture. 403 An important insight in LISP is that it initially uses existing IP 404 addresses for both of these kinds of names, as opposed to some 405 similar earlier deployment proposals for separation of location and 406 identity (e.g. [RFC1992]), which proposed using a new namespace for 407 locators. This choice minimizes LISP's deployment cost, as well as 408 providing the ability to easily interact with un-modified hosts and 409 routers. 411 The capability to use namespaces other than IP addresses for both 412 kinds of names is already built in LISP, which is expected to greatly 413 increase the long-term benefits, flexibility, and power of LISP 414 ([AFI], [I-D.ietf-lisp-lcaf]). 416 6.2. Basic Functionality 418 {{Suggestion by editors: Rewrite this section: It is using non- 419 standard terminology to refer to standard LISP concepts ('enhance' 420 instead of encapsulate) It is using subjective terms (e.g., 'near' 421 the source) It is missing key LISP aspects such as that RLOC packets 422 are forwarded in the RLOC space }} 423 The basic operation of LISP, as it currently stands, is quite simple. 424 LISP augmented packet switches, "LISP routers", near the source and 425 destination of packets intercept traffic, and 'enhance' the packets 426 for the trip between the LISP switches. 428 The LISP router near the original source (the Ingress Tunnel Router, 429 or ITR ) looks up additional information about the destination of the 430 packet, and then wraps the packet in an outer header, one which 431 contains additional information related to LISP operation. 433 The LISP router near the destination, the (the Egress Tunnel Router, 434 or ETR) removes that header, leaving the original, un-modified, 435 packet to be sent on to the original destination node. 437 The overall processing is shown below, in Figure 1: 439 /-----------------\ --- 440 | Mapping | | 441 . System | | Control 442 -| |`, | Plane 443 ,' \-----------------/ . | 444 / \ --- 445 ,.., - _,..--..,, `, ,.., | 446 / ` ,' ,-` `', . / ` | 447 / \ +-----+ ,' `, +--'--+ / \ | 448 | EID |-| xTR |---/ RLOC ,---| xTR |-| EID | | Data 449 | Space |-| |---| Space |---| |-| Space | | Plane 450 \ / +-----+ . / +-----+ \ / | 451 `. .' `. ,' `. .' | 452 `'-` `., ,.' `'-` --- 453 ``''--''`` 454 LISP Site (Edge) Core LISP Site (Edge) 456 Figure.- An schema of the LISP Architecture 458 Figure 1: Basic LISP Packet Flow 460 To retrieve that additional information, the ITR uses the information 461 in the original packet about the identity of its ultimate 462 destination, i.e. the destination EID address. It uses the 463 destination EID to look up the current location (the RLOC) of that 464 EID. 466 The lookup is performed through a mapping system, which is the heart 467 of LISP: it is a distributed directory of mappings from EIDs to 468 RLOCs. The destination RLOC(s) is (are) normally the address(es) of 469 the ETR(s) near the ultimate destination. 471 The ITR then generates a new outer header for the original packet, 472 with that header containing the ETR's RLOC as the wrapped packet's 473 destination, and the ITR's own address (i.e. the RLOC usually 474 associated with the original source) as the wrapped packet's source, 475 and sends it off. 477 When the packet arrives at the ETR, that outer header is stripped 478 off, and the original packet is forwarded to the original ultimate 479 destination for normal processing. 481 Return traffic is handled similarly, often (depending on the 482 network's configuration) with the original ITR and ETR switching 483 roles. The ETR and ITR functionality is usually co-located in a 484 single LISP router; these are normally denominated as xTRs. 486 6.3. Mapping from EIDs to RLOCs 488 The mappings from EIDs to RLOCs are provided by a distributed, and 489 potentially replicated, database, the "mapping database", which is 490 the heart of LISP. Here, and in other places in LISP, the 491 replication is not a deep architectural concept, simply an 492 engineering device to obtain reliability via potential redundancy. 494 Entities which need EID-to-RLOC mappings get them from the mapping 495 system, which is a collection of sub-systems through which clients 496 can find and obtain mappings as discussed in more details in 497 Section 8.2 and Section 13. 499 Mappings are normally distributed via a pull mechanism (i.e., not 500 pre-loaded, but requested on demand). Once obtained by an ITR, they 501 are cached for performance reasons. 503 6.4. Interworking With Non-LISP-Capable Endpoints 505 It is clearly crucial to provide the capability for easy 506 interoperation between "LISP hosts" - i.e. they are behind xTRs, and 507 their EIDs are in the mapping database - and existing non-LISP-using 508 hosts (often called 'legacy' hosts) or legacy "sites". 510 To allow interoperation between devices hosted in a LISP site and 511 devices not belonging to a LISP site (non-LISP site), an interworking 512 mechanism based on proxies has been designed. Proxy ITRs (PITR) 513 encapsulate packets sent from non-LISP sites to LISP sites while 514 Proxy ETRs (PETR) decapsulate packets sent from LISP sites to non- 515 LISP sites. More details are given in Section 15.2.1. 517 6.5. Security in LISP 519 {{Suggestion by editors: Rewrite this section: (first 3 paragraphs) 520 It contains a general discussion as well as strong statements that 521 are not supported by any WG document. (last 3 paragraphs) It 522 enumerates the security mechanisms specified in LISP but does not 523 describe them.}} 525 To provide a brief overview of security in LISP, it is definitely 526 understood that LISP needs to be highly _securable_, especially in 527 the long term; over time, the attacks mounted by 'bad guys' are 528 becoming more and more sophisticated. So LISP, like DNS, needs to be 529 _capable_ of providing 'the very best' security there is. 531 At the same time, there is a conflicting goal: it must be deployable 532 at a a viable cost. That means two things: First, as an experiment, 533 we cannot expect to create the complete security apparatus which we 534 might see in the finished product, including both design and 535 implementation. Second, security needs to be flexible, so that we 536 don't overload the users with more security than they need at any 537 point. 539 To accomplish these divergent goals, the approach taken is to first 540 analyze what LISP needs for security. [I-D.ietf-lisp-threats]. 541 Then, steps can be taken to ensure that the appropriate 'hooks' (such 542 as packet fields) are included at an early stage, when doing so is 543 still easy. Over time, additional mechanisms will be fully 544 specified, implemented, and deployed. 546 LISP does already include a number of security mechanisms; in 547 particular, requesting mappings can be secured (see Section 12.8, 548 "Security of Mapping Lookups"), as can registering of xTRs (see 549 Section 13.1.3, "Map-Register and Map-Notify Messages"); the key 550 database of the mapping system is also secured (see Section 13.4, 551 "Security of the DDT Indexing Sub-system"). 553 The existing security mechanisms, and their configuration (which is 554 mostly manual at this point) currently in LISP are felt to be 555 adequate for the needs of the on-going early stages of deployment; 556 experience will indicate when improvements are required (within the 557 constraints of the conflicting goal given above). 559 For more on LISP's security philosophy; see 560 [I-D.ietf-lisp-perspective], Section 7 "Security", where it is laid 561 out in some detail. 563 7. Initial Applications 565 {{Suggested by editors: Move this section after section 8, the 566 applications should not be described before LISP has been fully 567 described. 569 {{Suggested by Noel: Reorder the whole section in popularity order?}} 571 As previously mentioned, it is felt that LISP will provide even the 572 earliest adopters with some useful capabilities, and that these 573 capabilities will drive early LISP deployment. 575 It is very imporant to note that even when used only for 576 interoperation with existing un-modified hosts, use of LISP can still 577 provide benefits to the site which has deployed it - and, perhaps 578 even more importantly, can do so to both sides. This characteristic 579 acts to further enhance the utility for early adopters of LISP. 581 Note also that this section only lists some early applications and 582 benefits. See [I-D.ietf-lisp-perspective], in the Section "Goals of 583 LISP", for a more extensive discussion of some of what LISP might 584 ultimately provide. 586 7.1. Provider Independence 588 Provider independence (i.e. the ability to easily change one's 589 Internet Service Provider) is a good example of the utility of 590 separating location and identity. 592 To limit global routing table size addresses need to be aggregated. 593 To that aim networks can use provider aggregatable addresses 594 ([RFC4116]) which means that the IP prefixes of networks are sub- 595 prefixes of their provider. This solutions allows to reduce 596 scalability issues of the global routing table but it means that when 597 a network switches providers it has to re-number all its devices 598 which is known to be complex in current networks [RFC5887]. 600 Having separate namespaces for location and identity greatly reduces 601 the problems involved with re-numbering; an organization which moves 602 retains its EIDs (which are how most other parties refer to its 603 nodes), but is allocated new RLOCs, and the mapping system can 604 quickly provide the updated mapping from the EIDs to the new RLOCs. 606 7.2. Multi-Homing 608 {{Suggested by editors: This section should be extended, it is 609 unclear the benefits that LISP brings to multihoming (.e.g, traffic 610 engineering, decoupled multihoming from the data-plane). 612 Multi-homing is another place where the value of separation of 613 location and identity became apparent. There are several different 614 sub-flavours of the multi-homing problem - e.g. depending on whether 615 one wants open TCP connections to keep working, etc - and other axes 616 as well (e.g. site multi-homing versus host multi-homing). 618 In particular, for the 'keep open connections up' case, without 619 separation of location and identity, with most currently deployed 620 implementations, the only currently feasible approach is to use 621 provider-independent addressses - which moves the problem into the 622 global routing system, with attendant costs. This approach is also 623 not really feasible for host multi-homing. 625 7.3. Traffic Engineering 627 {{Suggestion by editors: Merge this section with the previous one, TE 628 is not practical without multihoming}} 630 {{Needs a fix - not sure what.}} 632 Traffic engineering (TE) [RFC3272], desirable though this capability 633 is in a global network, is currently somewhat problematic to provide 634 in the Internet. The problem, fundamentally, is that this capability 635 was not forseen when the Internet was designed, so the support for it 636 via hacks is neither clean, nor flexible. 638 TE is, fundamentally, a routing issue. However, the current Internet 639 routing architecture, which is basically the Baran design of fifty 640 years ago [Baran] (a single large, distributed computation), is ill- 641 suited to provide TE. The Internet seems a long way from adopting a 642 more-advanced routing architecture, although the basic concepts for 643 such have been known for some time. [RFC1992] 645 Although the identity-location mapping layer is thus a poor place, 646 architecturally, to provide TE capabilities, it is still an 647 improvement over the current routing tools available for this purpose 648 (e.g. injection of more-specific routes into the global routing 649 table). 651 In addition, instead of the entire network incurring the costs 652 (through the routing system overhead), when using a mapping layer to 653 provide TE, the overhead is limited to those who are actually 654 communicating with that particular destination. 656 LISP includes a number of features in the mapping system to support 657 TE. (described in Section 8.2, "Control Plane - Mapping System 658 Overview", below); more details about using LISP for TE can be found 659 in [I-D.farinacci-lisp-te]. 661 Also, a number of academic papers have explored how LISP can be used 662 to do TE, and how effective it can be. See the online LISP 663 Bibliography ([Bibliography]) for information about them. 665 7.4. Routing 667 {{Suggestion by editors: Remove this section, LISP is not a routing 668 protocol.}} 670 Multi-homing and Traffic Engineering are both, in some sense, uses of 671 LISP for routing, but there are many other routing-related uses for 672 LISP. 674 One of the major original motivations for the separation of location 675 and identity in general, and thus LISP, was to reduce the growth of 676 the routing tables in the "Internet core", the part where routes to 677 _all_ ultimate destinations must be available. LISP is expected to 678 help with this; for more detail, see Section 15.4, "LISP and Core 679 Internet Routing", below. 681 LISP may also have more local applications in which it can help with 682 routing; see, for instance, [CorasBGP]. 684 7.5. Mobility 686 {{Suggestion by editors: Remove this section, mobility is not in 687 charter.}} 689 Mobility is yet another place where separation of location and 690 identity is a key part of a clean, efficient and high-functionality 691 solution. Considerable experimentation has been completed on doing 692 mobility with LISP. 694 The mobility provided by LISP allows active sessions to survive moves 695 (provided of course that there is not a period of inaccessibility 696 which exceeds a timeout). LISP mobility also will typically have 697 better packet stretch (i.e. increase in path length) compared to 698 traditional mobility schemes, which use a home agent. 700 7.6. Traversal Across Alternate IP Versions 702 Note that LISP inherently supports intermixing of various IP versions 703 for packet carriage; IPv4 packets might well be carried in IPv6, or 704 vice versa, depending on the network's configuration. 706 This capability allows an island of operation of one type to be 707 automatically tunneled over a stretch of infrastucture which only 708 supports the other type. 710 7.7. Virtual Private Networks 712 {{Suggestion by editors: Remove this section, not covered by any WG 713 document}} 715 L2 and L3 {{Need to add text here - This used to be part of 'Local' 716 below, but we decided this was so important it deserved its own 717 section. Maybe move this up further, as it seems to be the most 718 important 'early adopter' application?}} 720 The mapping-and-encapsulation nature of LISP makes it a perfect 721 candidate for VPN solutions. In this case, private parts of the VPN 722 form LISP sites and the IP addresses of devices in the private parts 723 are composing EID spaces. The interconnection between the LISP sites 724 is the public network and IP addresses in the interconnection compose 725 the RLOC space. A major advantage of using LISP to construct VPN 726 resides in the simplicity of the configurations: each xTR (i.e., VPN 727 end) is configured to query the mapping system to retrieve mappings 728 making the glue between the public (RLOC space) and the private (EID 729 space) of the VPN. 731 This includes support of multi-tenancy where several private networks 732 can be carried over the same underlayer network. Thanks to the 733 instance-id field, multi-tenant network can even use the exact same 734 addresses as the xTR distinguishes the tenant based on the value of 735 the instance-id. The multiple address family support in LISP 736 mappings also allows to build private networks using a different 737 addressing family than the carrier (e.g., IPv6 over IPv4). 739 7.8. Local Uses 741 {{Suggestion by editors: Remove this section. The section contains a 742 general discussion about the applicability of LISP in intra-domain 743 scenarios, however it does not describe any specific application.}} 745 LISP has a number of use cases which are within purely 746 organizationally-local contexts, i.e. not in the larger Internet. 747 These fall into two categories: uses seen on the Internet (above), 748 but here on a private (and usually small scale) setting; and 749 applications which do not have a direct analog in the larger 750 Internet, and which apply only to local deployments. 752 Among the former are multi-homing and IP version traversal. {{This 753 was marked to be deleted - why? The next part doesn't make sense 754 without this first?}} 756 Among the latter class, non-Internet applications which have no 757 analog on the Internet, are the following example applications: 759 virtual machine mobility in data centers; non-IP EID types such as L2 760 MAC addresses, or application specific data. 762 Several of the applications listed in this section are the ones which 763 have been most popular for LISP in practise; these include virtual 764 networks, and virtual machine mobility. 766 These often show a synergistic tendency, in that a site which 767 installs LISP to do one, often finds that then becomes a small matter 768 to use it for the second. Given all the things which LISP can do, it 769 is hoped that this synergistic effect will continue to expand LISP's 770 uses. 772 {{Preceeding paragraphs should probably get moved up into VPN 773 section?}} 775 8. Major Functional Subsystems 777 {{Suggestion by editors: This section should appear before since it 778 describes key aspects of LISP (e.g., LISP decoupled control and data- 779 plane).}} 781 LISP has two major functional sub-systems: the xTRs which form the 782 data-plane of LISP; and the mapping system which forms the control 783 plane that maintains and distributes the mapping database. 785 The purpose and operation of each is described at a high level below, 786 and then, later on, in a fair amount of detail, in separate sections 787 on each (Section 12 and Section 13). 789 8.1. Data Plane - xTRs Overview 791 {{Suggestion by editors: Extend this section, it misses key LISP 792 data-plane aspects, such as the map-cache.}} 794 xTRs are routers that have been augmented with extra functionality in 795 both the data and control planes. The data plane functions in ITRs 796 include deciding which packets need to be given LISP processing 797 (since packets to non-LISP hosts may be sent as they are); i.e. 798 looking up the mapping; encapsulating (wrapping) the packet; and 799 sending it to the ETR. 801 This encapsulation is done using UDP [RFC0768], along with an 802 additional outer IP header (to hold the source and destination 803 RLOCs). To the extent that traffic engineering features are in use 804 for a particular EID, the ITRs implement them as well. 806 In the ETR, the data plane simply decapsulates (unwraps) the packets, 807 and forwards the it to the destination. 809 Control plane functions in ITRs include: asking for EID-to-RLOC 810 mappings via Map-Request packets; handling the returning reply 811 control messages (i.e., Map-Reply packets), which contain the EID-to- 812 RLOC mapping; managing the local mapping cache and checking for the 813 reachability of destination ETR's RLOCs. 815 In the ETR, control plane functions include participating in the 816 reachability tests (see Section 16.4); interacting with the mapping 817 sub-system to let it know what mapping this ETR can provide (see 818 Section 8.2.2); and answering Map-Request packets from ITRs for those 819 mappings. 821 8.1.1. Mapping Cache Performance 823 {{Suggestion by editors: Push this section further in the document, 824 the cache performance is not a "Major LISP subsystem"}} 826 As mentioned, studies have been performed to verify that caching 827 mappings in ITRs is viable, in practical engineering terms. These 828 studies not only verified that such caching is feasible, but also 829 provided some insight for designing ITR "mapping caches". 831 Briefly, they took lengthy traces of all packets leaving a large 832 site, over a period of a week or so, and used those to drive 833 simulations which showed how many mappings would be required. It 834 also allowed analysis of how much control traffic (for loading needed 835 mappings) would result, using various cache sizes and replacement 836 algorithms. These studies provide an insight into how well LISP can 837 be expected to perform, and scale, over time. 839 A more extended look at the results us given below, in Section 12.9, 840 "xTR Mapping Cache Performance". 842 8.2. Control Plane - Mapping System Overview 844 {{Suggestion by editors: Rewrite: Replace EID block terminology 845 (along with its description) with the very common term "prefix". 846 Describe Map-Request/Map-Reply LISP signaling messages.}} 848 The mapping system's entire purpose is to give ITRs on-demand access 849 to the mapping database, which is a distributed, and potentially 850 replicated, database which holds mappings between EIDs (identity) and 851 RLOCs (location), along with needed ancillary data (e.g. lifetimes). 853 To be exact, it contains mappings between EID blocks and RLOCs (the 854 block size is given explicitly, as part of the syntax). Support for 855 blocks is both for minimizing the administrative configuration 856 overhead, as well as for operational efficiency; e.g. when a group of 857 EIDs are behind a single xTR. In IP blocks are delimited by their IP 858 prefix. 860 However, the block may be, and sometimes is, as small as a single 861 EID. However, since mappings are only loaded upon demand, if smaller 862 blocks become predominant, then the increased size of the overall 863 database is far less problematic than if the Internet's routing 864 tables came to be dominated by such small entries. 866 A particular EID (or EID block) may be associated to than one RLOC, 867 and may change the association with time. 869 Also, in general, throughout LISP, the address family of EIDs and 870 RLOCs is explicitly mentioned in control packet. 872 Finally, the mapping from an EID (or EID block) contains not just the 873 RLOC(s), but also (for each RLOC for any given EID entry) priority 874 and weight fields (to allow allocation of load between several RLOCs 875 at a given priority); this allows a certain amount of traffic 876 engineering to be accomplished with LISP. 878 8.2.1. Mapping System Organization 880 {{Suggestion by editors: Rewrite: Describe key Mapping System 881 components: Map-Server/Map-Resolver}} 883 The mapping system is split into three functional sub-systems. 885 The first is the actual mappings themselves, collectively the mapping 886 database; they are held by the ETRs, and an ITR which needs a mapping 887 gets it (effectively) directly from the ETR. This co-location of the 888 authoritative version of the mappings, and the forwarding 889 functionality which it describes, is an instance of fate-sharing. 890 [Clark] 892 To find the appropriate ETR(s) to query for the mapping, the second 893 two sub-systems form an indexing system, itself also based on a 894 distributed, potentially replicated database. It provides 895 information on which ETR(s) are authoritative sources for the various 896 EID-to-RLOC mappings which are available. The two sub-systems which 897 form it are the client interface sub-system, and indexing sub-system 898 (which holds and provides the actual information). 900 8.2.2. Interface to the Mapping System 902 {{Suggestion by editors: has been rewritten: This section should 903 appear earlier since it describes key LISP components (Map-Request/ 904 Map-Reply/Map-Server/Map-Resolver}} 906 The client interface to the indexing system from an ITR's point of 907 view is not with the indexing sub-system directly; rather, it is 908 through the Map-Resolvers (MRs) and Map-Servers (MSs). 910 To obtain the mapping for an EID, the ITRs sends Map-Request packet 911 to an MR. The MR then uses the indexing sub-system to allow it to 912 forward the Map-Request to an appropriate Map-Server (MS), which in 913 turn sends the Map-Request on to the appropriate ETR. The latter is 914 authoritative for the actual mappings for the EID. 916 The ETR then sends the mappings for that EID in the form of aMap- 917 Reply packets, which is sent directly to the ITR, without passing 918 through the indexing sub-system and MR. The details of the indexing 919 sub-system are thus hidden from the ITRs. 921 Note that in proxy mode, the MS replies on behalf of the ETR. When 922 this the case, the map-replies is tagged to indicate that the answer 923 is not delivered from the authoritative ETR but from the MS instead. 925 The interface to the indexing system from an ETR's point of view is 926 made through MSes. ETRs send Map-Register packets to their 927 designated MSes. The effect of a Map-Register is to inform the MS 928 about the mappings maintained by ETRs such that the MS can transmit 929 the Map-Requests is receives to the appropriate ETRs. 931 The MS optionally replies Map-Register packets with a Map-Notify 932 packet to confirm the registration. The details of the indexing sub- 933 system are thus likewise hidden from ETRs. 935 The fact that the details of the indexing sub-system are entirely 936 hidden from xTRs gives considerably flexibility to this aspect of 937 LISP. As long as any potential indexing sub-system can track where 938 mappings are, it could potentially be used; this would allow the 939 actual indexing sub-system to be replaced without needing to modify 940 the xTRs. 942 8.2.3. Indexing Sub-system 944 {{suggestion by editor: rename the section to "DDT"}} 946 The current indexing sub-system is the Delegated Database Tree (DDT), 947 which is conceptually similar to DNS ([I-D.ietf-lisp-ddt], 949 [RFC1034]). DDT replaces the earlier LISP+ALT indexing sub-system 950 ([RFC6836]). The seamless migration to DDT while LISP+ALT was 951 previously used validated the concept of having a client-interface 952 sub-system between the indexing sub-system, and the clients. 954 8.2.3.1. DDT Overview 956 Conceptually, DDT is similar to the DNS, in DDT the delegation of the 957 EID namespace is instantiated as a delegation hierarchy, a tree of 958 DDT nodes, starting with the root DDT node. Each vertex is 959 responsible for a block of the EID namespace. 961 The root node is responsible for the entire EID space; any DDT node 962 can delegate part(s) of its EID block to child DDT node(s). The 963 child node(s) can in turn further delegate (necessarily smaller) 964 blocks of namespace to their children, through as many levels as are 965 needed (for operational, administrative, etc, needs). 967 Just as with DNS, any particular vertex in the DDT delegation tree 968 may be instantiated in one or more DDT servers. Multiple (redundant) 969 servers for a given node would be used for reasons of performance, 970 reliability, and robustness. Obviously, all the servers which 971 instantiate a particular nodes in the tree have to have identical 972 data about that node. 974 8.2.3.2. Use of DDT by MRs 976 An MR which wants to find a mapping for a particular EID first 977 interacts with the DDT servers which instantiate the nodes of the 978 LISP delegation hierarchy tree, discovering (by querying the servers 979 for information about DDT nodes) the chain of delegations which cover 980 that EID. Eventually it is directed to an MS, which is servicing an 981 ETR which is authoritative for that EID. 983 Also, again like DNS, MRs may cache information they receive about 984 the delegations in the delegation tree. This means that once an MR 985 has been in operation for a while, it will usually have much of the 986 delegation information cached locally (especially the top levels of 987 the delegation tree). This allows them, when passed a request for a 988 mapping by an ITR, to usually forward the mapping request to the 989 appropriate MS without having to interact with all the DDT servers on 990 the path down the delegation tree, in order to find any particular 991 mapping. 993 Thus, a typical resolution cycle would usually involve looking at 994 some locally cached delegation information, perhaps loading some 995 missing delegation entries into their delegation cache, and finally 996 sending the Map-Request to the appropriate MS. 998 It should also be noted that the delegation tree is fairly static, 999 since it reflects EID block allocations, which are themselves fairly 1000 static. This stability has several important consequences. First, 1001 it increases the performance of the mapping system, since the sub- 1002 system almost never needs to be re-queried for information about 1003 intermediate vertices. {{comment from editor: does not understand 1004 the next sentence...}}Second, it is not necessary to include a 1005 mechanism to find out-dated delegations. [LISP-TREE] 1007 This contrasts with the mappings, which may change at a high rate - 1008 changes which have no impact on the indexing sub-system. The 1009 potentially high dynamics of mappings explains why mappings are 1010 delivered directly from ETRs (or MSes in proxy mode) to ITRs and 1011 hence not cached at the MR level. LISP is designed to make sure that 1012 changes in the mappings are detected and acted upon fairly quickly; 1013 this allows LISP to provide a number of capabilities, such as 1014 mobility. 1016 9. Examples of operation 1018 To aid in comprehension, a few examples are given of user packets 1019 traversing the LISP system. The first shows the processing of a 1020 typical user packet which is LISP forwarded, i.e. what the vast 1021 majority of user packets will see. The second shows what happens 1022 when the first packet to a previously-unseen ultimate destination (at 1023 a particular ITR) is to be processed by LISP. 1025 9.1. An Ordinary Packet's Processing 1027 {{Suggestion by editors: This section should be earlier in the 1028 document structure, examples are important -particularly for 1029 engineers- to explain how systems work}} 1031 This case follows the processing of a typical , {{comment from 1032 editors: text missing}} when the packet has made its way through the 1033 local site to an ITR, which in this case is a border router for the 1034 site, the border router looks up the destination address - an EID - 1035 in its local mapping cache. For EIDs which are IP addresses, this 1036 lookup uses the IP longest prefix matching algorithm. 1038 It finds a mapping, which instructs it to wrap the packet in an outer 1039 header - an IP packet, containing a UDP packet which contains a LISP 1040 header - and then the user's original packet (see Section 12.2 for 1041 the reasons for this particular choice). The destination address in 1042 the outer header is set by the ITR to the RLOC of the destination 1043 ETR. 1045 The encapsulated packet is then sent off through the RLOC space 1046 (e.g., Internet), using normal Internet routing. 1048 On arrival at the destination ETR, the ETR will notice that it is 1049 listed as the destination in the outer header. It will examine the 1050 packet, detect that it is a LISP packet, and unwrap it. It will then 1051 examine the header of the user's original packet, and forward it 1052 internally, through the local site, to the ultimate destination. 1054 At the ultimate destination, the packet will be processed, and may 1055 produce a return packet, which follows the exact same process in 1056 reverse - with the exception that the roles of the ITR and ETR are 1057 swapped. 1059 9.2. A Mapping Cache Miss 1061 {{Suggestion by editors: (same as previous section)}} 1063 If a host sends a packet, and it gets to the ITR, and the ITR 1064 determines that it does not yet have a mapping cache entry which 1065 covers that destination EID, then additional processing ensues; it 1066 has to look up the mapping in the mapping system (as previously 1067 described in Section 6.2). 1069 The overall processing is shown below, in Figure 2: 1071 ----- ----- 1072 | | 3 | | 1073 Map Resolver | | -------> | | Map Server 1074 | | | | 1075 ----- ----- 1076 ^ | 1077 Key: | | 1078 | | 1079 -- = Control | | 1080 == = Data | | 1081 2 | 5 | 4 1082 | --- | 1083 Host A | / \ | Host B 1084 | |_ \ V 1085 ----- ----- \ ----- ----- 1086 | | 1 | | 6 | | 7 | | 1087 | | =====> | ITR | =======> | ETR | =====> | | 1088 | | | | | | | | 1089 ----- ----- ----- ----- 1091 Figure 2: Packet flow with missing mapping 1093 1. Source-EID sends packet (to Dest-EID) to ITR 1095 2. ITR sends Map-Request to Map-Resolver 1097 3. Map-Resolver delivers Map-Request to Map-Server 1099 4. Map-Server delivers Map-Request to ETR 1101 5. ETR returns Map-Reply to ITR; ITR caches EID-to-RLOC(s) mapping 1103 6. ITR uses mapping to encapsulate to ETR; sends user packet to ETR 1105 7. ETR decapsulates packet, delivers to Dest-EID 1107 The ITR first sends a Map-Request packet, giving the destination EID 1108 it needs a mapping for, to its MR. The MR will look in its cache of 1109 delegation information to find the vertex which is the most specific 1110 in the delegation tree for that destination EID . If it does not 1111 have the address of an appropriate MS, it will query the DDT system, 1112 recursively if need be, in order to eventually find the address of 1113 such an MS. 1115 When it has the MS's address, it will send the Map-Request on to the 1116 MS, which then usually sends it on to an appropriate ETR. The ETR 1117 sends a Map-Reply to the ITR which needs the mapping; from then on, 1118 processing of user packets through that ITR to that ultimate 1119 destination proceeds as above. 1121 To the best of our knowledge, in all LISP implementations, the 1122 original user packet will have been discarded, and not queued waiting 1123 for the mapping to be returned. When the host retransmits such a 1124 packet, the mapping will be there, and the packet will be forwarded. 1125 Alternatively, it might have been forwarded using a PITR to avoid 1126 being dropped (Section 6.4). 1128 10. Part II 1130 {{comment from editors: is that the role of an introductory document 1131 to enter in such level of details and discuss (mostly) all fields of 1132 the protocol? }} 1134 11. Design Approach 1136 {{Suggestion by editors: Remove this section, it does not describe/ 1137 discuss anything relevant, it is only providing a reference to 1138 another non-WG document.}} 1139 Before describing LISP's components in more detail below, it it worth 1140 pointing out that what may seem, in some cases, like odd (or poor) 1141 design approaches do in fact result from the application of a 1142 thought-through, and consistent, design philosophy used in creating 1143 them. {{Subjective: maybe JMH, Dino can help with better words?}} 1145 This design philosophy is covered in detail in 1146 [I-D.ietf-lisp-perspective], Section "Design"), and readers who are 1147 interested in the 'why' of various mechanisms should consult that; 1148 reading it may make clearer the reasons for some engineering choices 1149 in the mechanisms given here. 1151 12. xTRs 1153 As mentioned above (in Section 8.1), xTRs are the essential LISP data 1154 plane elements. This section explores some advanced topics related 1155 to xTRs. 1157 {{Suggestion by editors: remove next paragraph, brings nothing)}} 1159 Careful rules have been specified for both TTL and ECN [RFC3168] to 1160 ensure that passage through xTRs does not interfere with the 1161 operation of these mechanisms. In addition, care has been taken to 1162 ensure that traceroute works when xTRs are involved. 1164 12.1. When to Encapsulate 1166 An ITR knows that an ultimate destination is running LISP (remember 1167 that the actual destination machine itself probably knows nothing 1168 about LISP), and thus that it should perform LISP processing on a 1169 packet (including potential encapsulation) if it has an entry in its 1170 local mapping cache that covers the destination address (it is then 1171 called an EID). 1173 Conversely, if the cache contains a negative entry (indicating that 1174 the ITR has previously attempted to find a mapping that covers this 1175 EID, and it has been informed by the mapping system that no such 1176 mapping exists), it knows the ultimate destination is not running 1177 LISP, and the packet can be forwarded natively (i.e. not LISP- 1178 encapsulated). 1180 Note that the ITR cannot simply depend on the appearance, or non- 1181 appearance, of the destination in the routing tables in the Internet 1182 core, as a way to tell if a destination is a LISP node or not. That 1183 is because mechanisms to allow interoperation of LISP sites and 1184 legacy sites necessarily involve advertising LISP sites' EIDs into 1185 the Internet core; in other words, LISP sites which need to 1186 interoperate with legacy nodes will appear in the Internet core 1187 routing tables, along with non-LISP sites. 1189 12.2. UDP Encapsulation Details 1191 Use of UDP (instead of, say, a LISP-specific protocol number) was 1192 driven by the fact that many routers and middle boxes filter out 1193 unknown protocols, so adopting a non-UDP encapsulation would have 1194 compromised the initial deployment of LISP. 1196 The UDP source port used for encapsulating packet is computed with a 1197 5-way hash of the original source and destination in the inner 1198 header, along with the ports, and the protocol. This is because many 1199 ISPs use multiple parallel paths (so-called Equal Cost Multi-Path), 1200 and load-share across them. Using such a hash in the source-port in 1201 the outer header both allows LISP traffic to be load-shared, and also 1202 ensures that packets from individual connections are delivered in 1203 order (since most ISPs try to ensure that packets for a particular 1204 flow follow a single path, and hence do not become disordered). 1206 The UDP checksum is zero because the inner packet usually already has 1207 a end-end checksum, and the outer checksum adds no value ([Saltzer]). 1208 {{Suggestion by editors: not sure that next statement is correct}} In 1209 most exising hardware, computing such a checksum (and checking it at 1210 the other end) would also present a major load, for no benefit. 1212 12.3. Header Control Channel 1214 {{Suggestion by editors: Rewrite this section to improve readability, 1215 use standard terminology (e.g., Cache Coherence/Reachability instead 1216 of "Header Control Channel"). Split the mechanisms depending on its 1217 goal (cache coherence/reachability) and describe them under the same 1218 context.}} 1220 LISP provides a multiplexed channel in the encapsulation header. It 1221 is mostly (but not entirely) used for control purposes. The general 1222 concept is that the header starts with a flags field, and it also 1223 includes two data fields, the contents and meaning of which vary, 1224 depending on which flags are set. This allows these fields to be 1225 multiplexed among a number of different low-duty-cycle functions, 1226 while minimizing the space overhead of the LISP. 1228 12.3.1. Mapping Versioning 1230 One important use of the multiplexed control channel is mapping 1231 versioning; i.e. the discovery of when the mapping cached in an ITR 1232 is outdated. To allow an ITR to discover this, identifying sequence 1233 numbers are applied to different versions of a mappping [RFC6834]. 1235 This allows an ITR to easily discover when a cached mapping has been 1236 updated by a more recent variant. 1238 Version numbers are available in control messages (Map-Replies), but 1239 the initial concept is that to limit control message overhead, the 1240 versioning mechanism should primarily use the multiplexed user data 1241 header control channel. 1243 Versioning can operate in both directions: an ITR can advise an ETR 1244 what version of a mapping it is currently using (so the ETR can 1245 notify it if there is a more recent version), and ETRs can let ITRs 1246 know what the current mapping version is (so the ITRs can request an 1247 update, if their copy is outdated). 1249 12.3.2. Echo Nonces 1251 Another important use of the header control channel is for a 1252 mechanism known as the Nonce Echo, which is used as an efficient 1253 method for ITRs to check the reachability of neighbour ETRs. 1255 Basically, an ITR which has to determine that an ETR is up, and 1256 reachable, sends a nonce to that ETR, carried in the encapsulation 1257 header; when that ETR (also acting as an ITR) sends some other user 1258 data packet back to the ITR (acting in turn as an ETR), that nonce is 1259 carried in the header of that packet, allowing the original ITR to 1260 confirm that its packets are reaching that ETR. 1262 Note that a lack of a response is not necessarily proof that 1263 something has gone wrong - but it strongly suggests that something 1264 has, so other actions (e.g. a switch to an alternative ETR, if one is 1265 listed; a direct probe; etc) are advised. (See Section 16.5 for more 1266 about Echo Nonces.) 1268 12.3.3. Instances 1270 {{Suggestion by editors: Move and extend this section: - Instance ID 1271 is not a cache-coherence/reachability algorithm. Describe where and 1272 what is the Instance ID field Explain its applications}} 1274 The LISP data-plane header is also used to support VPN and multi- 1275 tenant networks. Since there is only one destination UDP port used 1276 for carriage of user data packets, and the source port is used for 1277 multiplexing, there is no other way to differentiate among different 1278 destination EID spaces (which are often overlapped in VPNs and multi- 1279 tenant networks). 1281 12.4. Probing 1283 RLOC-Probing is a mechanism method that an ITR can use to determine 1284 with that an ETR is up and reachable from the ITR. As a side- 1285 benefit, it gives RTT estimates. 1287 To probe the reachability of an RLOC, an ITR sends a specially marked 1288 Map-Request directly to the ETR it wishes information about; that ETR 1289 sends back a specially marked Map-Reply. A Map-Request message and a 1290 Map-Reply message are used, rather than a special probing control- 1291 message pair, because as a side-benefit the ITR can discover if the 1292 mapping has been updated since it cached it. 1294 {{Suggestion from editors: remove the following sentence as it is not 1295 motivated by strong arguments}} The probing mechanism is rather 1296 heavy-weight and expensive (compared to mechanisms like the Echo- 1297 Nonce), since it costs a control message from each side, so it should 1298 only be used sparingly. 1300 If the number of active neighbour ETRs of the ITR is large, use of 1301 RLOC-Probing to check on their reachability will result in 1302 considerable control traffic; such control traffic has to be spread 1303 out to prevent a load peak. 1305 Obviously, if RLOC-Probing is the only mechanism being used to detect 1306 unreachable neighbour ETRs, the rate at which RLOC-Probing is done 1307 will control the timeliness of the detection of loss of reachability. 1308 There is thus a tradeoff between overhead and responsiveness, 1309 particular when an ITR has a large fanout of neighbour ETRs. 1311 12.5. Mapping Lifetimes and Timeouts 1313 {{Suggestion by editors: Remove this section, TTL is a simple well- 1314 known concept, we suggest to include a sentence (and hence remove 1315 this section) in the control-plane section stating that mappings 1316 include a TTL. 1318 Mappings come with a Time-To-Live, which indicate how long the 1319 creator of the mapping expects them to be useful for. 1321 Mappings might also be discarded before the TTL expires, depending on 1322 what strategies the ITR is using to maintain its cache; if the 1323 maximum cache size is fixed, or the ITR needs to reclaim memory, 1324 mappings which have not been used recently may be discarded. (After 1325 all, there is no harm in so doing; a future reference will merely 1326 cause that mapping to be reloaded.) 1328 {{Contents may change before TTL expires?}} 1330 12.6. Mapping Gleaning in ETRs 1332 {{Suggestion by editors: Remove this section, gleaning is discouraged 1333 since it rises many security concerns.}} 1335 As an optimization to the mapping acquisition process, ETRs are 1336 allowed to glean mappings from incoming user data packets, and also 1337 from incoming Map-Request control messages. This is not secure, and 1338 so any such mapping must be verified by sending a Map-Request to get 1339 an authoritative mapping. 1341 The value of gleaning is that most communications are two-way, and so 1342 if host A is sending packets to host B (therefore needing B's 1343 EID->RLOC mapping), very likely B will soon be sending packets back 1344 to A (and thus needing A's EID->RLOC mapping). Without gleaning, 1345 this would sometimes result in a delay, and the dropping of the first 1346 return packet; this is felt to be very undesirable. 1348 12.7. MTU Issues 1350 Several mechanisms have been proposed for dealing with packets which 1351 are too large to transit the path from a particular ITR to a given 1352 ETR. 1354 In one, called the stateful approach, the ITR keeps a per-ETR record 1355 of the maximum size allowed, and sends an ICMP Too Big message to the 1356 original source host when a packet which is too large is seen. 1358 In the other, referred to as the stateless approach, for IPv4 packets 1359 without the DF bit set, too-large packets are fragmented, and then 1360 the fragments are forwarded; all other packets are discarded, and an 1361 ICMP Too Big message returned. 1363 12.8. Security of Mapping Lookups 1365 {{Suggestion from editors: would remove all what is related to 1366 security and instead put a small summary in the security section and 1367 reference the threats document}} 1369 LISP provides an optional mechanism to secure the obtaining of 1370 mappings by an ITR. [I-D.ietf-lisp-sec] It provides protection 1371 against attackers generating spurious Map-Reply messages (including 1372 replaying old Map-Replies), and also against over-claiming attacks 1373 (where a malicious ETR by claims EID-prefixes which are larger than 1374 what have been actually delegated to it). 1376 In summary, the ITR provides a One-Time Key with its Map-Request; 1377 this key is used by both the MS (to sign an affirmation that it has 1378 delegated that EID block to that ETR), and indirectly by the ETR (to 1379 sign the mapping that it is returning to the ITR). 1381 The specification for LISP-SEC suggests that the ITR-MR stage be 1382 cryptographically protected, and indicates that the existing 1383 mechanisms for securing the ETR-MS stage are used to protect Map- 1384 Rquests also. It does assume that the channel from the MR to the MS 1385 is secure. 1387 12.9. ITR Mapping Cache Performance 1389 As mentioned previously (Section 8.1.1, a substantial amount of 1390 simulation work has been performed to predict, and understand, the 1391 performance of the mapping cache in xTRs. 1393 Briefly, however, the first, [Iannone], was performed in the very 1394 early stages of the LISP effort, to verify that that caching approach 1395 was feasible. 1397 Packet traces of all traffic over the external connection of a large 1398 university over a week-long period were collected; simulations driven 1399 by these recording were then performed. A variety of control 1400 settings on the cache were used, to study the effects of varying the 1401 settings. 1403 First, the simulation gave the cache sizes that would result from 1404 such a cache design: it showed that the resulting cache sizes ranged 1405 from 7,500 entries, up to about 100,000 (depending on factors such as 1406 traffic and entry retention time). Using some estimations as to how 1407 much memory mapping entries would use, this indicated cache sizes of 1408 between roughly 100 Kbytes and a few Mbytes. 1410 Of more interest, in a way, were the results regarding two important 1411 measurements of the effectiveness of the cache: i) the hit ratio 1412 (i.e. the share of references which could be satisfied by the cache), 1413 and ii) the miss rate (since control traffic overhead is one of the 1414 chief concerns when using a cache). These results were also 1415 encouraging: miss (and hence lookup) rates ranged from 30 per minute, 1416 up to 3,000 per minute. 1418 Significantly, this was substantially lower than the amount of 1419 observed DNS traffic, which ranged from 1,800 packets per minute up 1420 to 15,000 per minute. The results overall showed that using a 1421 demand-loaded cache was an entirely plausible design approach: both 1422 cache size, and the control plane traffic load, were definitely 1423 feasible. 1425 The second, [Kim], was in general terms similar, except that it used 1426 data from a large ISP, one with about three times as many users as 1427 the previous study. It used the same cache design philosophy (the 1428 cache size was not fixed), but slightly different, lower, retention 1429 time values. 1431 The results were similar: cache sizes ranges from 20,000 entries to 1432 roughly 60,000; the miss rate ranged from very roughly 400 per minute 1433 to very roughly 7,000 per minute, similar to the previous results. 1435 Finally, a third study, [CorasCache], examined the effect of using a 1436 fixed size cache, and a purely Least Recently Used (LRU) cache 1437 eviction algorithm (i.e. no timeouts). It also tried to verify that 1438 models of the performance of such a cache (using previous theoretical 1439 work on caches) produced results that conformed with actual empirical 1440 measurements. 1442 It used yet another set of packet traces; using a cache size of 1443 around 50,000 entries produced a miss rate of around 1x10-4; again, 1444 definitely viable, and in line with the results of the other studies. 1446 13. The Mapping System 1448 {{Suggestion by editors: This section is somewhat redundant with 1449 respect to section 8.2, we suggest to move this section to Part I 1450 since it provides some missing details.}} 1452 As discussed already in Section 8.2, the LISP mapping system is an 1453 important part of LISP's control plane: it i) maintains the database 1454 of mappings between EIDs, and the RLOCs at which they are to be 1455 found, and ii) provides those mappings to ITRs which request them, so 1456 that the ITRs can send traffic for a given EID to the correct RLOC(s) 1457 for that EID. 1459 [RFC1034] has this to say about the DNS name to IP address database 1460 and mapping system: 1462 "The sheer size of the database and frequency of updates suggest 1463 that it must be maintained in a distributed manner, with local 1464 caching to improve performance. Approaches that attempt to 1465 collect a consistent copy of the entire database will become more 1466 and more expensive and difficult, and hence should be avoided." 1468 and this observation applies equally to the LISP mapping database and 1469 mapping system. 1471 To briefly recap, the mapping system is split into three parts: i) an 1472 indexing sub-system, which keeps track of where all the mappings are 1473 kept; ii) the interface to the indexing system (which remains the 1474 same, even if the actual indexing system is changed); and iii) the 1475 mappings themselves (collectively, the mapping database), the 1476 authoritative copies of which are always held by ETRs. 1478 13.1. The Mapping System Interface 1480 As mentioned in Section 8.2.2, both of the interfaces to the mapping 1481 system (from ITRs, and ETRs) are standardized, so that the more 1482 numerous xTRs do not have to be modified when the mapping indexing 1483 sub-system is changed. 1485 This section describes the interfaces in a little more detail; for 1486 details, see [RFC6833]. 1488 13.1.1. Map-Request Messages 1490 {{Suggestion from editors: should come much earlier as it is an 1491 essential message in LISP}} 1493 The Map-Request message contains a number of fields, the two most 1494 important of which are the requested EID block identifier (remember 1495 that individual mappings may cover a block of EIDs, not just a single 1496 EID), and the Address Family Identifier (AFI) for that EID block. 1498 Other important fields are the source EID (and its AFI), and one or 1499 more RLOCs for the source EID, along with their AFIs. The source EID 1500 and RLOCs allow ETRs to customize their answer. 1502 Finally, the message includes a long nonce, for simple, efficient 1503 protection against offpath attackers and a variety of other fields 1504 and control flag bits. 1506 13.1.2. Map-Reply Messages 1508 {{Suggestion from editors: should come much earlier as it is an 1509 essential message in LISP}} 1511 The Map-Reply message looks similar, except it includes the mapping 1512 entry for the requested EID(s), which contains one or more RLOCs and 1513 their associated data. Note that the reply may cover a larger block 1514 of the EID namespace than the request; most requests will be for a 1515 single EID, the one which prompted the query. 1517 If there are no mappings available at all for the EID(s) requested, a 1518 Negative Map-Reply message will be returned. This is a Map-Reply 1519 message with flag bits set to indicate that fact. 1521 For each RLOC in the entry, there is the RLOC, its AFI, priority and 1522 weight fields (see Section 8.2), and multicast priority and weight 1523 fields (see Section 14). 1525 13.1.2.1. Solicit-Map-Request Messages 1527 Solicit-Map-Request (SMR) messages are actually not another message 1528 type, but a variant of Map-Request messages. They include a special 1529 flag which indicates to the recipient that it should send a new Map- 1530 Request message, to refresh its mapping, because the ETR has detected 1531 that the one it is using is out-dated. 1533 SMR's, like most other control traffic, should be rate-limited. 1535 13.1.3. Map-Register and Map-Notify Messages 1537 {{Suggestion by editors: As noted by the author add a paragraph 1538 describing how a xTR de-registers an EID-to-RLOC mapping.}} 1540 {{Suggestion by editors: add a small paragraph to explain what Map- 1541 Registers are used for}} 1543 The Map-Register message contains one or several mapping records, 1544 each with an individual Time-To-Live (TTL). Each of the records 1545 contains an EID (potentially, a block of EIDs) and its AFI, a version 1546 number for this mapping (see Section 12.3.1 and a list of RLOCs and 1547 their AFIs. 1549 {{Suggestion by editors: do not understand the following paragraph}} 1550 Each RLOC entry also includes the same data as in the Map-Replies 1551 (i.e. priority and weight); this is because in some circumstances it 1552 is advantageous to allow the MS to proxy reply on the ETR's behalf to 1553 Map-Request messages, and the MS needs this information when it does 1554 so. 1556 Map-Notify messages have the exact same contents as Map-Register 1557 messages; they are purely acknowledgements. 1559 The entire interaction is authenticated by use of a shared key, 1560 configured in the MS and ETR. Although the protocol does already 1561 allow for replacement of the encryption algorithm, it does not 1562 support automated key management (although it appears to fall under 1563 the exclusions in [RFC4107]). 1565 LISP does not specify messages for de-registering an association with 1566 a MS. The de-registration is hence ensured by the expiration of a 1567 timer: if a MS does not receive Map-Register messages within given 1568 timeout, it de-register the association. 1570 13.2. The DDT Indexing Sub-system 1572 {{Suggestion from the editors: this section does not add any 1573 fundamental value to the DDT overview section, propose to remove it 1574 to only keep the overview; too much details that should not appear in 1575 an intro document}} 1577 As previously mentioned in Section 8.2.3, DDT is the current indexing 1578 sub-system in LISP. 1580 The overall functioning is conceptually fairly simple; an MR which 1581 needs a mapping starts at a server for the root DDT node (there will 1582 normally be more than one such server available, for both performance 1583 and robustness reasons), and through a combination of cached 1584 delegation information, and repetitive querying of a sequence of DDT 1585 servers, works its way down the delegation tree until it arrives at 1586 an MS which is authoritative for the block of EID which holds the 1587 destination EID in question. 1589 The interaction between MRs and DDT servers is as follow. The MR 1590 sends to the DDT server a Map-Request control message. The DDT 1591 server uses its data (which is configured, and static) to see whether 1592 it is directly peered to an MS which can answer the request, or if it 1593 has a child (or children, if replicated) which is responsible for 1594 that portion of the EID blocks. 1596 If it has children configured which are responsible, it will reply to 1597 the MR with another kind of LISP control message, a Map-Referral 1598 message, which provides information about the delegation of the block 1599 containing the requested EID. This step is secured via 1600 authentication. 1602 The Map-Referral also gives the addresses of DDT servers for that 1603 block and the MR can then send Map-Requests to any one (or all) of 1604 them. In addition, the Map-Referral includes keying material for the 1605 children, which allows any information provided by them to be 1606 cryptographically verified. 1608 Control flags in the Map-Referral indicate to the querying MR whether 1609 the referral is to another DDT server, an MS, or an ETR. {{All three? 1610 Check}} If the former, the MR then sends the Map-Request to the child 1611 DDT server, repeating the process. 1613 If the second, the MR then interacts with that MS, and usually the 1614 block's ETR(s) as well, to cause a mapping to be sent to the ITR 1615 which queried the MR for it. Recall that some MS's provide Map- 1616 Replies on behalf of an associated ETR, in so-called 'proxy mode', so 1617 in such cases the Map-Reply will come from the MS, not the ETR. 1619 Delegations are cached in the MRs, so that once an MR has received 1620 information about a delegation, it usually will not need to look that 1621 up again. Once it has been in operation for a short while, there 1622 will usually only be a limited amount of delegation information which 1623 is has not yet asked about - probably only the last stage in a 1624 delegation to a leaf MS. 1626 13.3. Reliability via Replication 1628 {{Suggestion by editors: Remove this section, describes operational 1629 practices/policies of the DDT infrastructure, this is beyond the 1630 scope of this document.}} 1632 Everywhere throughout the mapping system, robustness to operational 1633 failures is obtained by replicating data in multiple instances of any 1634 particular node (of whatever type). Map-Resolvers, Map-Servers, DDT 1635 nodes, ETRs - all of them can be replicated, and the protocol 1636 supports this replication. 1638 There are generally no mechanisms specified yet to ensure coherence 1639 between multiple copies of any particular data item (e.g. the copies 1640 of delegation data for a particular block of namespace, in DDT 1641 sibling servers) - this is currently a manual responsibility. 1643 If and when LISP protocol adoption proceeds, an automated layer to 1644 perform this functionality can easily be layered on top of the 1645 existing mechanisms. 1647 The deployed DDT system actually uses anycast [RFC4786], along with 1648 replicated servers, to improve both performance and robustness. 1650 13.4. Security of the DDT Indexing Sub-system 1652 {{Suggestion by editors: Remove this section, provides unnecessary 1653 details of DDT.}} 1655 In summary, securing the mapping indexing system is divided into two 1656 parts: the interface between the clients of the system (MR's) and the 1657 mapping indexing system itself, and the interaction between the DDT 1658 servers which make it up. 1660 The client interface provides only a single model, using the 1661 canonical public-private key system (starting from a trust anchor), 1662 in which the child's public key is provided by the parent, along with 1663 the delegation. When the child returns any data, it can sign the 1664 data, and the requestor can use that signature to verify the data. 1665 This requires very little configuration in the clients. 1667 The interface between the DDT servers allows for choices between a 1668 number of different options, allowing the operators to trade off 1669 among configuration complexity, security level, etc. This is based 1670 on experience with DNSSEC ([RFC4033]), where configuration complexity 1671 has been a major stumbling block to deployment. 1673 13.5. Extended Capabilities 1675 {{Suggestion by editors: Remove this section, not discussed in any WG 1676 document.}} 1678 In addition to the priority and weight data items in mappings, LISP 1679 offers other tools to enhance functionality, particularly in the 1680 traffic engineering area. 1682 One is requestor-specific mappings, i.e. the ETR may return different 1683 mappings to the enquiring ITR, depending on the identity of the ITR. 1684 This allows very fine-tuned traffic engineering, far more powerful 1685 than routing-based TE. 1687 13.6. Performance of the Mapping System 1689 Prior to the creation of DDT, a large study of the performance of the 1690 previous mapping system, ALT ([RFC6836]), along with a proposed new 1691 design called TREE (which used DNS to hold delegation information) 1692 provided considerable insight into the likely performance of the 1693 mapping systems at larger scale (See [LISP-TREE]). 1695 The basic structure and concepts of DDT are identical to those of 1696 TREE, so the performance simulation work done for that design applies 1697 equally to DDT. 1699 {{Suggestion from editors: next sentence is redundant with previous 1700 parts of the doucment}} In that study, as with earlier LISP 1701 performance analyses, extensive large-scale simulations were driven 1702 by lengthy recordings of actual traffic at several major sites; one 1703 was the site in the first study ([Iannone]), and the other was an 1704 even large university, with roughly 35,000 users. 1706 The results showed that a system like DDT, which caches information 1707 about delegations, and allows the MR to communicate directly with the 1708 servers for the lower vertices on the delegation hierarchy based on 1709 cached delegation information, would have good performance, with 1710 average resolution times on the order of the MR to MS RTT. This 1711 verified the effectiveness of this particular type of indexing 1712 system. 1714 A more recent study, [Saucez], has measured actual resolution times 1715 in the deployed LISP network; it took measurements from a variety of 1716 locations in the Internet, with respect to a number of different 1717 target EIDs. Average measured resolution delays ranged from roughly 1718 175 msec to 225 msec, depending on the location. 1720 14. Multicast Support in LISP 1722 {{Suggestion by editors: Rewrite this section, it provides too many 1723 details. Reduce it to a brief description of LISP Multicast}} 1725 LISP and its intrinsic separation of identity from location is well 1726 suited for Multicast ([RFC3170], [RFC5110]), and the definition of 1727 mappings in the current specifications already allows multicast 1728 capability ([RFC6830]). 1730 {{Say something about sources.}} 1732 {{Suggestion by editors: remove the paragraph below, motivation for 1733 multicast is out of the scope of this document}} 1735 Multicast is an important requirement, for a number of reasons: doing 1736 multiple unicast streams is inefficient, as it is easy to use up all 1737 the upstream bandwidth; without multicast a server can also be 1738 saturated fairly easily in doing the unicast replication; etc. 1740 Since it is important for LISP to work well with multicast; doing so 1741 has been a significant focus in LISP throughout its entire 1742 development. 1744 Further very significant improvements to multicast support in LISP 1745 are in progress; see [Improvements], Section "Multicast" for more on 1746 them. 1748 14.1. Basic Concepts of Multicast Support in LISP 1750 This section introduces some of the basic principles of multicast 1751 support in LISP. 1753 Since group addresses name distributed collective entities, in 1754 general they cannot have a single RLOC also. Since they usually 1755 refer to collections of entities the notion of endpoint identity must 1756 be 1758 A multicast source at a LISP site may not be able to become the root 1759 of a distribution tree in the core if it uses its EID as its identity 1760 for that distribution tree (i.e. a distribution tree (S-EID, G)); 1761 that is because there may not be a route to its EID in the core 1762 (assuming that its section of the core even supports multicast; not 1763 all parts of the core do). 1765 Therefore, outside the LISP site, multicast state for the 1766 distribution tree (S-RLOC, G) needs to be built instead, where S-RLOC 1767 is the RLOC of the ITR that the multicast source inside the LISP site 1768 will be sending its traffic through. 1770 Multicast LISP requires no packet format changes to existing 1771 multicast packets (both control, and user data). The initial 1772 multicast support in LISP uses existing multicast control mechanisms 1773 exclusively; improvements currently being worked on provide LISP- 1774 specific control mechanisms (see [Improvements]). 1776 14.2. Initial Multicast Support in LISP 1778 {{Suggestion by editors: remove this paragraph}} 1780 Readers who wish to fully understand multicast support need to 1781 consult the appropriate specifications: LISP multicast issues are 1782 discussed in [RFC6830], Section 11; and see [RFC6831] for the full 1783 details of current multicast support in LISP. 1785 With the multicast operation defined in [RFC6831]), destination group 1786 addresses are not mapped; only the source address (when the original 1787 source is inside a LISP site) needs to be mapped, both during 1788 distribution tree setup, as well as actual traffic delivery. 1790 In other words, while LISP's mapping capability is used, at this 1791 stage it is only applied to the source, not the destination (as with 1792 most LISP activity). Thus, in LISP-encapsulated multicast packets in 1793 this mode, the inner source is the EID, and the outer source is the 1794 ITR's RLOC; both inner and outer destinations are the group's 1795 multicast address. 1797 Note that this does mean that if the group is using separate source- 1798 specific trees for distribution, there isn't a separate distribution 1799 tree outside the LISP site for each different source of traffic to 1800 the group from inside the LISP site; they are all grouped together 1801 under a single source, the RLOC. 1803 The issue of encapsulation is complex, because if the rest of the 1804 group outside the LISP site includes some members which are at other 1805 LISP sites (i.e. packets to them have to be encapsulated), and some 1806 members at legacy sites (i.e. encapsulated packets would not be 1807 understood), there is no simple answer. (The situation becomes even 1808 more complex when one considers that as hosts leave and join the 1809 group, it may switch back and forth between mixed and homogenous.) 1810 This issue is too complex to fully cover here; see Section 9.2., 1811 "LISP Sites with Mixed Address Families", in [RFC6831], for complete 1812 coverage of this issue. 1814 Basically, there are multicast equivalents of some of the legacy 1815 interoperability mechanisms used for unicast; mPITRs and mPETRs 1816 (multicast-capable PITRs and PETRs). When mixed groups are a 1817 possibility, two choices are available: i) send two copies (one 1818 encapsulated, and one not) of all traffic, or ii) employ mPETRs to 1819 distribute non-encapsulated copies to legacy group members. 1821 15. Deployment Issues and Mechanisms 1823 {{Suggestion by editors: Remove this section, provides unnecessary 1824 details. Add a reference to the deployment RFC.}} 1826 This section discusses several deployment issues in more detail. 1827 With LISP's heavy emphasis on practicality, much work has gone into 1828 making sure it works well in the real-world environments most people 1829 have to deal with. 1831 15.1. LISP Deployment Needs 1833 As mentioned earlier (Section 5.2), LISP requires no change to almost 1834 all existing hosts and routers. Obviously, however, one must deploy 1835 something to run LISP. Exactly what that has to be will depend 1836 greatly on the details of the site's existing networking gear, and 1837 choices it makes for how to achieve LISP deployment. 1839 The primary requirement is for one or more xTRs. These may be 1840 existing routers, just with new software loads, or it may require the 1841 deployment of new devices. 1843 {{Suggestion by editors: next paragraph is barely understandable}} 1845 LISP also requires a certain amount of LISP-specific support 1846 infrastructure, such as MRs, MSs, the DDT hierarchy, etc. However, 1847 much of this will either i) {{for the case where you are adding a new 1848 site using existing LISP infrastructure}} already be deployed, and if 1849 the new site can make arrangements to use it, it need do nothing 1850 else; or ii) those functions the site must provide may be co-located 1851 in other LISP devices (again, either new devices, or new software on 1852 existing ones). 1854 15.2. Interworking Mechanisms 1856 One aspect which has received a lot of attention are the mechanisms 1857 previously referred to (in Section 6.4) to allow interoperation of 1858 LISP sites with so-called legacy sites which are not running LISP 1859 (yet). 1861 {{Suggestion by editors: remove next paragraph as it talks about 1862 features (NAT based transition) not covered by the WG}} 1864 There are two main approaches to such interworking: proxy routers 1865 (PITRs and PETRs), and an alternative mechanism using a router with 1866 combined NAT and LISP functionality; these are described in more 1867 detail here. 1869 15.2.1. Proxy LISP Routers 1871 {{Suggestion by editors: Move this section to Part I. PxTRs are an 1872 important aspect of LISP and as such, should be described before. 1873 Furthermore simplify it, it currently contains too many details plus 1874 an additional discussion on the impact of PITR that is out of the 1875 scope of the document.}} 1877 PITRs (proxy ITRs) serve as ITRs for traffic from legacy hosts to 1878 nodes in LISP sites. PETRs (proxy ETRs) serve as ETRs for LISP 1879 traffic to legacy host. 1881 Note that return traffic to a legacy host from a LISP-using node does 1882 not necessarily have to pass through an ITR/PETR pair - the original 1883 packets can usually just be sent directly to the ultimate 1884 destination. However, for some kinds of LISP operation (e.g. mobile 1885 nodes), this is not possible; in these situations, the PETR is 1886 needed. 1888 15.2.1.1. PITRs 1890 To serve as ITRs for traffic from legacy hosts to nodes in LISP 1891 sites, PITRs they have to advertise into the existing legacy backbone 1892 Internet routing the availability of whatever ranges of EIDs (i.e. of 1893 nodes using LISP) they are proxying for, so that legacy hosts will 1894 know where to send traffic to those LISP nodes. PITR implies that 1895 EID prefixes are advertised in BGP. 1897 This technique may have an impact on routing table in the Internet 1898 core, but it is not clear yet exactly what that impact will be; it is 1899 very dependent on the collected details of many individual deployment 1900 decisions. 1902 A PITR may cover a group of EID blocks with a single EID 1903 advertisement to the core, in order to reduce the number of routing 1904 table entries added. In fact, at the moment, aggressive aggregation 1905 of EID announcements is performed, precisely to to minimize the 1906 number of new announced routes added by this technique. 1908 At the same time, if a site does traffic engineering with LISP 1909 instead of fine-grained BGP announcement, that will help keep table 1910 sizes down (and this is true even in the early stages of LISP 1911 deployment). The same is true for multi-homing. {{Maybe mixing two 1912 concepts? LISP TE tools will still apply to traffic between PITR and 1913 LISP site.}} 1915 As mentioned previously (Section 12.1), an ITR at another LISP site 1916 can avoid using a PITR (i.e. it can detect that a given ultimate 1917 destination is not a legacy host, if a PITR is advertising it into 1918 the Internet core) by checking to see if a LISP mapping exists for 1919 that ultimate destination. 1921 15.2.1.2. PETRs 1923 PETRs (proxy ETRs) serve as ETRs for LISP traffic to legacy hosts, 1924 for cases where a LISP node cannot send packets to such hosts without 1925 encapsulation. That typically happens for one of two reasons. 1927 First, it will happen in places where some device is implementing 1928 Unicast Reverse Path Forwarding (uRPF), to prevent a variety of 1929 negative behaviour; originating packets with the original source's 1930 EID in the source address field will result in them being filtered 1931 out and discarded. 1933 {{Suggestion by editors: would adding and example be useful?}} 1935 Second, it will happen when a LISP site wishes to send packets to a 1936 non-LISP site, and the path in between does not support the 1937 particular IP protocol version used by the original source along its 1938 entire length. Use of a PETR on the other side of the gap will allow 1939 the LISP site's packet to 'hop over' the gap, by utilizing LISP's 1940 built-in support for mixed protocol encapsulation. 1942 PETRs are generally used by specific ITRs, which have the location of 1943 their PETRs configured into them. In other words, unlike normal 1944 ETRs, PETRs do not have to register themselves in the mapping 1945 database, on behalf of any legacy sites they serve. 1947 Also, allowing an ITR to always send traffic leaving a site to a PETR 1948 does avoid having to chose whether or not to encapsulate packets; it 1949 can just always encapsulate packets, sending them to the PETR if it 1950 has no specific mapping for the ultimate destination. 1952 15.2.2. LISP-NAT 1954 {{Suggestion by editors: Remove this section, LISP-NAT is not a WG 1955 document neither an inter-networking mechanisms.}} 1957 A LISP-NAT router, as previously mentioned, combines LISP and NAT 1958 functionality, in order to allow a LISP site which is internally 1959 using addresses which cannot be globally routed to communicate with 1960 non-LISP sites elsewhere in the Internet. (In other words, the 1961 technique used by the PITR approach simply cannot be used in this 1962 case.) 1964 To do this, a LISP-NAT performs the usual NAT functionality, and 1965 translates a host's source address(es) in packets passing through it 1966 from an inner value to an outer value, and storing that translation 1967 in a table, which it can use to similarly process subsequent packets 1968 (both outgoing and incoming). [RFC6832] 1970 {{Suggestion by editors: remove the following paragraph, does not 1971 bring anything}} 1973 There are two main cases where this might apply: 1975 o Sites using non-routable global addresses 1977 o Sites using private addresses [RFC1918] 1979 15.3. Use Through NAT Devices 1981 {{Suggestion by editors: Remove this section, LISP-NAT is not a WG 1982 document neither an inter-networking mechanisms.}} 1984 NATs are both ubiquitous, and here to stay for a long time to come. 1985 [RFC1631] Thus, in the actual Internet of today, having any new 1986 mechanisms function well in the presence of NATs (i.e. with LISP xTRs 1987 behind a NAT device) is absolutely necessary. 1989 LISP has produced a variety of mechanisms to do this. An 1990 experimental mechanism to support them had major limitations; it, and 1991 its limitations, are described in Appendix B.5. 1993 15.4. LISP and Core Internet Routing 1995 {{Suggestion by editors: Remove this section, this is already 1996 explained in lisp-deployment}} 1998 One of LISP's original motivations was to control the growth of the 1999 size of routing tables in the Internet core, the part where routes to 2000 all destinations must be available. As LISP becomes more widely 2001 deployed, it can help with this issue, in a variety of ways. 2003 In covering this topic, one must recognize that conditions in various 2004 stages of LISP deployment (in terms of ubiquity) will have a large 2005 influence. [RFC7215] introduced useful terminology for this 2006 progression, in addition to some coverage of the topic (see 2007 Section 5, "Migration to LISP"): 2009 The loosely defined terms of early transition phase, late transition 2010 phase, and LISP Internet phase refer to time periods when LISP sites 2011 are a minority, a majority, or represent all edge networks 2012 respectively. 2014 In the early phases of deployment, two primary effects will allow 2015 LISP to have a positive impact on the routing table growth: 2017 o Using LISP for traffic engineering instead of BGP 2019 o Aggregation of smaller PI sites into a single PITR advertisement 2021 The first is fairly obvious (doing TE with BGP requires injecting 2022 more-specific routes into the Internet core routing tables, something 2023 doing TE with LISP avoids); the second is not guaranteed to happen 2024 (since it requires coordination among a number of different parties), 2025 and only time will tell if it does happen. 2027 16. Fault Discovery/Handling 2029 {{Suggestion by editors: Remove this section, although this section 2030 helps understanding how many of the LISP mechanisms work 2031 (particularly the ones described in section 12) it provides an 2032 unnecessary level of (operational) detail. This level of 2033 understanding should be achieved reading the main LISP spec. }} 2035 The structure of LISP gives rise to a moderate number of of failure 2036 modes. 2038 16.1. Handling Missing Mappings 2040 To handling missing mappings, the ITR calls for the mapping, and in 2041 the meantime can either discard traffic to that ultimate destination 2042 (as many ARP implementations do) [RFC0826], or, if dropping the 2043 traffic is deemed undesirable, it can forward them via a PITR. 2045 16.2. Outdated Mappings 2047 If a mapping changes once an ITR has retrieved it, that may result in 2048 traffic to the EIDs covered by that mapping failing. There are three 2049 cases to consider: 2051 o When the ETR to which traffic is being sent is still a valid ETR 2052 for that EID, but the mapping has been updated (e.g. to change the 2053 priority of various ETRs) 2055 o When the ETR traffic is being sent to is still an ETR, but no 2056 longer a valid ETR for that EID 2058 o When the ETR traffic is being sent to is no longer an ETR 2060 16.2.1. Outdated Mappings - Updated Mapping 2062 A 'mapping versioning' system, whereby mappings have version numbers, 2063 and ITRs are notified when their mapping is out of date, has been 2064 added to detect this, and the ITR responds by refreshing the mapping. 2065 [RFC6834] 2067 16.2.2. Outdated Mappings - Wrong ETR 2069 If an ITR is holding an outdated cached mapping, it may send packets 2070 to an ETR which is no longer an ETR for that EID. 2072 It might be argued that if the ETR is properly managing the lifetimes 2073 on its mapping entries, this cannot happen, but it is a wise design 2074 methodology to assume that cannot happen events will in fact happen 2075 (as they do, due to software errors, or, on rare occasions, hardware 2076 faults), and ensure that the system will handle them properly. 2078 ETRs can easily detect cases where this happens, after they have un- 2079 wrapped a user data packet; in response, they send a Solicit-Map- 2080 Request to the source ITR to cause it to refresh its mapping. 2082 16.2.3. Outdated Mappings - No Longer an ETR 2084 In another case for what can happen if an ITR uses an outdated 2085 mapping, the destination of traffic from an ITR might no longer be a 2086 LISP node at all. In such cases, one might get an ICMP Destination 2087 Unreachable (Port Unreachble subtype) error message. However, one 2088 cannot depend on that - and in any event, that would provide an 2089 attack vector, so it should be used with care. (See [RFC6830], 2090 Section 6.3 for more about this.) 2092 The following mechanism will work, though. Since the destination is 2093 not an ETR, the echoing reachability detection mechanism (see 2094 Section 12.3.2, "Echo Nonces") will detect a problem. At that point, 2095 the backstop mechanism, Probing, will kick in. Since the destination 2096 is still not an ETR, that will fail, too. 2098 At that point, traffic will be switched to a different ETR, or, if 2099 none are available, a reload of the mapping may be initiated. 2101 16.3. Erroneous Mappings 2103 {{Suggestion by editors: this section brings nothing, remove it}} 2105 Again, this should not happen, but a good system should deal with it. 2106 However, in practise, should this happen, it will produce one of the 2107 prior two cases (the wrong ETR, or something that is not an ETR), and 2108 will be handled as described there. 2110 16.4. Verifying ETR Liveness 2112 The ITR, like all packet switches, needs to detect, and react, when 2113 its neighbour ceases operation. As LISP traffic is effectively 2114 always uni-directional (from ITR to ETR), this could be somewhat 2115 problematic. 2117 Solving a related problem, "neighbour ETR" "reachability" below) 2118 subsumes handling this fault mode, however. 2120 {{Suggestion by editors: remove next paragraph }} 2122 Note that the two terms - liveness and reachability - are not 2123 synonymous (although they are often confused). Liveness is a 2124 property of a node - it is either up and functioning, or it is not. 2125 Reachability is only a property of a particular pair of nodes. 2127 If packets sent from a first node to a second are successfully 2128 received at the second, it is reachable from the first. However, the 2129 second node may at the very same time not be reachable from some 2130 other node. Reachability is always a ordered pairwise property, and 2131 of a specified ordered pair. 2133 16.5. Verifying ETR Reachability 2135 A more significant issue than whether a particular ETR is up or not 2136 is, as mentioned above, that although the ETR may be up, attached to 2137 the network, etc, an issue in the network, between a source ITR, and 2138 the ETR, may prevent traffic from the ITR from getting to the ETR. 2139 (Perhaps a routing problem, or perhaps some sort of access control 2140 setting.) 2142 The one-way nature of LISP traffic makes this situation hard to 2143 detect with simple and non-intrusive techniques. In line with the 2144 LISP design philosophy this problem is then attacked not with a 2145 single mechanism (which would be complex) but with a collection of 2146 simple mechanisms. 2148 They are reliance on the underlying routing system (which can of 2149 course only reliably provide a negative reachabilty indication, not a 2150 positive one), the echo nonce (which depends on some return traffic 2151 from the destination xTR back to the source xTR), and finally RLOC 2152 probing, in the case where no positive echo is returned. 2154 {{Suggestion by editors: remove next paragraph }} 2156 (The last is not the first choice, as due to the large fan-out 2157 expected of LISP router, reliance on it as a sole mechanism would 2158 produce a fair amount of overhead.) 2160 17. Acknowledgments 2162 This document was initiated by Noel Chiappa, and much of the core 2163 philosophy came from him. We acknowledge the important contributions 2164 he has made to this work and thank him for his past efforts. 2166 The author would like to start by thanking all the members of the 2167 core LISP group for their willingness to allow him to add himself to 2168 their effort, and for their enthusiasm for whatever assistance he has 2169 been able to provide. 2171 He would also like to thank (in alphabetical order) Michiel Blokzijl, 2172 Peter Chiappa, Vina Ermagan, Dino Farinacci, Vince Fuller and 2173 Vasileios Lakafosis for their review of, and helpful suggestions for, 2174 this document. (If I have missed anyone in this list, I apologize 2175 most profusely.) 2176 A special thank you goes to Joel Halpern, who almost invariably, when 2177 asked, promptly returned comments on intermediate versions of this 2178 document. Grateful thanks go also to Darrel Lewis for his help with 2179 material on non-Internet uses of LISP, and to Dino Farinacci and 2180 Vince Fuller for answering detailed questions about some obscure LISP 2181 topics. 2183 A final thanks is due to John Wrocklawski for the author's 2184 organizational affiliation, and to Vince Fuller for help with XML. 2185 This memo was created using the xml2rfc tool. 2187 I would like to dedicate this document to the memory of my parents, 2188 who gave me so much, and whom I can no longer thank in person, as I 2189 would have so much liked to be able to. 2191 18. IANA Considerations 2193 This document makes no request of the IANA. 2195 19. Security Considerations 2197 This memo does not define any protocol and therefore creates no new 2198 security issues. 2200 20. References 2202 20.1. Normative References 2204 [AFI] IANA, , "Address Family Indicators (AFIs)", 2205 http://www.iana.org/assignments/address-family-numbers , 2206 January 2011. 2208 [I-D.ermagan-lisp-nat-traversal] 2209 Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, 2210 F., and C. White, "NAT traversal for LISP", draft-ermagan- 2211 lisp-nat-traversal-05 (work in progress), February 2014. 2213 [I-D.farinacci-lisp-te] 2214 Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic 2215 Engineering Use-Cases", draft-farinacci-lisp-te-06 (work 2216 in progress), March 2014. 2218 [I-D.ietf-lisp-ddt] 2219 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 2220 Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in 2221 progress), March 2013. 2223 [I-D.ietf-lisp-lcaf] 2224 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 2225 Address Format (LCAF)", draft-ietf-lisp-lcaf-05 (work in 2226 progress), May 2014. 2228 [I-D.ietf-lisp-perspective] 2229 Chiappa, J., "An Architectural Perspective on the LISP 2230 Location-Identity Separation System", draft-ietf-lisp- 2231 perspective-00 (work in progress), February 2013. 2233 [I-D.ietf-lisp-sec] 2234 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 2235 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-06 2236 (work in progress), April 2014. 2238 [I-D.ietf-lisp-threats] 2239 Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats 2240 Analysis", draft-ietf-lisp-threats-10 (work in progress), 2241 July 2014. 2243 [I-D.meyer-lisp-mn] 2244 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 2245 Mobile Node", draft-meyer-lisp-mn-10 (work in progress), 2246 January 2014. 2248 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2249 August 1980. 2251 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 2252 1981. 2254 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2255 (IPv6) Specification", RFC 2460, December 1998. 2257 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 2258 Locator/ID Separation Protocol (LISP)", RFC 6830, January 2259 2013. 2261 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 2262 Locator/ID Separation Protocol (LISP) for Multicast 2263 Environments", RFC 6831, January 2013. 2265 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 2266 "Interworking between Locator/ID Separation Protocol 2267 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 2269 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 2270 Protocol (LISP) Map-Server Interface", RFC 6833, January 2271 2013. 2273 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 2274 Separation Protocol (LISP) Map-Versioning", RFC 6834, 2275 January 2013. 2277 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 2278 Pascual, J., and D. Lewis, "Locator/Identifier Separation 2279 Protocol (LISP) Network Element Deployment 2280 Considerations", RFC 7215, April 2014. 2282 20.2. Informative References 2284 [Atkinson] 2285 R. Atkinson, , "Revised draft proposed definitions", RRG 2286 list message, Message-Id: 808E6500-97B4-4107- 8A2F- 2287 36BC913BE196@extremenetworks.com, 11 June 2007, 2288 http://www.ietf.org/mail-archive/web/ram/current/ 2289 msg01470.html , . 2291 [Baran] P. Baran, , "On Distributed Communications Networks", IEEE 2292 Transactions on Communications Systems Vol. CS-12 No. 1, 2293 pp. 1-9 , March 1964. 2295 [Bibliography] 2296 J.N. Chiappa, , "LISP (Location/Identity Separation 2297 Protocol) Bibliography", 2298 http://www.chiappa.net/~jnc/tech/lisp/LISPbiblio.html , 2299 July 2013. 2301 [Chiappa] J.N. Chiappa, , "Endpoints and Endpoint Names: A Proposed 2302 Enhancement to the Internet Architecture", Personal draft 2303 (work in progress), 1999, 2304 http://www.chiappa.net/~jnc/tech/endpoints.txt , 1999. 2306 [Clark] D. D. Clark, , "The Design Philosophy of the DARPA 2307 Internet Protocols", Proceedings of the Symposium on 2308 Communications Architectures and Protocols SIGCOMM '88', 2309 pp. 106-114 , 1988. 2311 [CorasBGP] 2312 F. Coras, D. Saucez, L. Jakab, A. Cabellos-Aparicio, and 2313 J. Domingo-Pascual, , "Implementing a BGP-free ISP Core 2314 with LISP", Proceedings of the Global Communications 2315 Conference (GlobeCom), IEEE, pp. 2772-2778 , December 2316 2012. 2318 [CorasCache] 2319 J. Kim, L. Iannone, and A. Feldmann, , "On the Cost of 2320 Caching Locator/ID Mappings", Proceedings of the 10th 2321 International IFIP TC 6 Conference on Networking - Volume 2322 Part I (NETWORKING '11)', IFIP, pp. 367-378 , May 2011. 2324 [Future] J.N. Chiappa, , "Potential Long-Term Developments With the 2325 LISP System", draft-chiappa-lisp-evolution-00 (work in 2326 progress) (NOT EXISTING) , October 2012. 2328 [Heart] F. E. Heart, R. E. Kahn, S. M. Ornstein, W. R. Crowther, 2329 and D. C. Walden, , "The Interface Message Processor for 2330 the ARPA Computer Network", Proceedings AFIPS SJCC, Vol. 2331 36, pp. 551-567 , 1970. 2333 [I-D.farinacci-lisp] 2334 Farinacci, D., "Locator/ID Separation Protocol (LISP)", 2335 draft-farinacci-lisp-00 (work in progress), January 2007. 2337 [IEN19] J. F. Shoch, , "Inter-Network Naming, Addressing, and 2338 Routing", IEN (Internet Experiment Note) 19 , January 2339 1978. 2341 [Iannone] L. Iannone and O. Bonaventure, , "On the Cost of Caching 2342 Locator/ID Mappings", Proceedings of the 3rd International 2343 Conference on emerging Networking EXperiments and 2344 Technologies (CoNEXT'07)', ACM, pp. 1-12 , December 2007. 2346 [Improvements] 2347 J.N. Chiappa, , "An Overview of On-Going Improvements to 2348 the LISP Location-Identity Separation System", draft- 2349 chiappa-lisp-improvements-00 (work in progress) (NOT 2350 EXISTING) , September 2013. 2352 [Kim] L. Iannone and O. Bonaventure, , "A Deep Dive Into the 2353 LISP Cache and What ISPs Should Know About It", 2354 Proceedings of the 3rd International Conference on 2355 emerging Networking EXperiments and Technologies 2356 (CoNEXT'07)', ACM, pp. 1-12 , December 2007. 2358 [LISP-TREE] 2359 L. Jakab, A. Cabellos-Aparicio, F. Coras, D. Saucez, and 2360 O. Bonaventure, , "LISP-TREE: A DNS Hierarchy to Support 2361 the LISP Mapping System", IEEE Journal on Selected Areas 2362 in Communications', Vol. 28, No. 8, pp. 1332-1343 , 2363 October 2010. 2365 [NIC8246] A. McKenzie and J. Postel, , "Host-to-Host Protocol for 2366 the ARPANET", NIC 8246, Network Information Center, SRI 2367 International, Menlo Park, CA , October 1977. 2369 [NSAP] International Organization for Standardization, , 2370 "Information Processing Systems - Open Systems 2371 Interconnection - Basic Reference Model", ISO Standard 2372 7489.1984 , 1984. 2374 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 2375 converting network protocol addresses to 48.bit Ethernet 2376 address for transmission on Ethernet hardware", STD 37, 2377 RFC 826, November 1982. 2379 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2380 STD 13, RFC 1034, November 1987. 2382 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 2383 Destinations", RFC 1498, August 1993. 2385 [RFC1631] Egevang, K. and P. Francis, "The IP Network Address 2386 Translator (NAT)", RFC 1631, May 1994. 2388 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 2389 1812, June 1995. 2391 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 2392 E. Lear, "Address Allocation for Private Internets", BCP 2393 5, RFC 1918, February 1996. 2395 [RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The 2396 Nimrod Routing Architecture", RFC 1992, August 1996. 2398 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2399 of Explicit Congestion Notification (ECN) to IP", RFC 2400 3168, September 2001. 2402 [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: 2403 Challenges and Solutions", RFC 3170, September 2001. 2405 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 2406 Xiao, "Overview and Principles of Internet Traffic 2407 Engineering", RFC 3272, May 2002. 2409 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 2410 Private Network (VPN) Terminology", RFC 4026, March 2005. 2412 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2413 Rose, "DNS Security Introduction and Requirements", RFC 2414 4033, March 2005. 2416 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 2417 Key Management", BCP 107, RFC 4107, June 2005. 2419 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 2420 Gill, "IPv4 Multihoming Practices and Limitations", RFC 2421 4116, July 2005. 2423 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 2424 Services", BCP 126, RFC 4786, December 2006. 2426 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 2427 Workshop on Routing and Addressing", RFC 4984, September 2428 2007. 2430 [RFC5110] Savola, P., "Overview of the Internet Multicast Routing 2431 Architecture", RFC 5110, January 2008. 2433 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 2434 Still Needs Work", RFC 5887, May 2010. 2436 [RFC6115] Li, T., "Recommendation for a Routing Architecture", RFC 2437 6115, February 2011. 2439 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 2440 "Locator/ID Separation Protocol Alternative Logical 2441 Topology (LISP+ALT)", RFC 6836, January 2013. 2443 [Saltzer] J. H. Saltzer, D. P. Reed, and D. D. Clark, , "End-To-End 2444 Arguments in System Design", ACM TOCS, Vol 2, No. 4, pp 2445 277-288 , November 1984. 2447 [Saucez] D. Saucez, L. Iannone, and B. Donnet, , "A First 2448 Measurement Look at the Deployment and Evolution of the 2449 Locator/ID Separation Protocol", ACM SIGCOMM Computer 2450 Communication Review', Vol. 43 No. 2, pp. 37-43 , April 2451 2013. 2453 Appendix A. Glossary/Definition of Terms 2455 {{Suggestion by editors: remove and use those from RFCs instead }} 2457 o EID, Enpoint Identifier: Originally defined as a name for an 2458 endpoint, one with purely identity semantics, and globally unique, 2459 and with syntax of relatively short fixed length. It is used in 2460 the LISP work to mean the identifier of a node; it is the input to 2461 an EID->RLOC lookup in the mapping system; it is usually an IP 2462 address. The source and destination addresses of the innermost 2463 header in a LISP packet are usually EIDs. 2465 o RLOC, Routing Locator: a LISP-specific term meaning the locator 2466 associated with an entity identified by an EID; as such, it is 2467 often the output of an EID->RLOC lookup in the mapping system; it 2468 is usually an IP address, and of an ETR. The source and 2469 destination addresses of the outermost header in a LISP packet are 2470 usually RLOCs. 2472 o ITR, Ingress Tunnel Router: a LISP router at the border of a LISP 2473 site which takes user packets sent to it from inside the LISP 2474 site, encapsulates in a LISP header, and then sends them across 2475 the Internet to an ETR; in other words, the start of a tunnel from 2476 the ITR to an ETR. 2478 o ETR: Egress Tunnel Router: a LISP router at the border of a LISP 2479 site which decapsulates user packets which arrive at it 2480 encapsulated in a LISP header, and sends them on towards their 2481 ultimate destination; in other words, the end of the tunnel from 2482 an ITR to the ETR. 2484 o Neighbour ETR: Although an ITR and ETR may be separated by many 2485 actual physical hops, at the LISP level, they are direct 2486 neighbours; so any ETR which an ITR sends traffic to is a 2487 neighbour ETR of that ITR. 2489 o xTR: An xTR refers to a LISP router which functions both as an ITR 2490 and an ETR (which is typical), when the discussion involves packet 2491 flows in both directions through the router, which results in it 2492 alternately functioning as an ITR and then as an ETR. 2494 o Reachable; Reachability; Neighbour ETR Reachability: The ability 2495 of an ITR to be able to send packets to a neighbour ETR, or the 2496 property of an ITR to be able to send such packets. 2498 o Liveness: Whether a LISP node of any kind is up and operating, or 2499 not; or the property of a LISP node to be in such a state. 2501 o MR, Map Resolver: A LISP node to which ITRs send requests for 2502 mappings. 2504 o MS, Map Server: A LISP node with which ETRs register mappings, to 2505 indicate their availability to handle incoming traffic to the EIDs 2506 covered in those mappings. 2508 o Mapping System: The entire ensemble of data and mechanisms which 2509 allow clients - usually ITRs - to find mappings (from EIDs to 2510 RLOCs). It includes both the mapping database, and also 2511 everything used to gain access to it - the MRs, the indexing sub- 2512 system, etc. 2514 o Mapping Database: The term mapping database refers to the entire 2515 collection of EID-to-RLOC mappings spread throughout the entire 2516 LISP system. It is a subset of the mapping system. 2518 o Mapping Cache: A collection of copies of EID-to-RLOC mappings 2519 retained in an ITR; not the entire mapping database, but just the 2520 subset of it that an ITR needs in order to be able to properly 2521 handle the user data traffic which is flowing through it. 2523 o Indexing Sub-system: the entire ensemble of data and mechanisms 2524 which allows MRs to find out which ETR(s) hold the mapping for a 2525 given EID or EID block. It includes both the data on namespace 2526 delegations, as well as the nodes which hold that data, and the 2527 protocols used to interact with those nodes. 2529 o DDT Vertex; Vertex: a node (in the graph theory sense of the term) 2530 in the (abstract) LISP namespace delegation hierarchy. 2532 o DDT Server: an actual machine, which one can send packets to, in 2533 the DDT server hierarchy - which is, hopefully, a one-to-one 2534 projection of the LISP address delegation hierarchy (although of 2535 course a single DDT vertex may turn into several sibling servers). 2536 Some documents refer to these as DDT nodes but this document does 2537 not use that term, to prevent confusion with DDT vertex. 2539 o PITR: Proxy ITR; an ITR which is used for interworking between a 2540 LISP-speaking node or site, and legacy nodes or sites; in general, 2541 it acts like a normal ITR, but does so on behalf of LISP nodes 2542 which are receiving packets from a legacy node. 2544 o PETR: Proxy ETR; an ETR which is used for interworking between a 2545 LISP-speaking node or site, and legacy nodes or sites; in general, 2546 it acts like a normal ETR, but does so on behalf of LISP nodes 2547 which are sending packets to a legacy node. 2549 o RTR: Re-encapsulating Tunnel Router; a data plane 'anchor point' 2550 used by a LISP-speaking node to perform functions that can only be 2551 be performed in the core of the network. One use is for LISP- 2552 speaking node behind a NAT device to send and receive traffic 2553 through the NAT device; see 2555 o Internet core: That part of the Internet in which there are no 2556 'default' entries in routing tables, but where the routing tables 2557 hold entries for every single reachable destination in the 2558 Internet. (Sometimes referred to colloquially as the DFZ, or 2559 'Default Free Zone'.) 2561 Appendix B. Other Appendices 2563 B.1. A Brief History of Location/Identity Separation 2565 It was only gradually realized in the networking community that 2566 networks (especially large networks) should deal quite separately 2567 with the identity and location of a node; the distinction between the 2568 two was more than a little hazy at first. 2570 The ARPANET had no real acknowledgment of the difference between the 2571 two. [Heart][NIC8246] The early Internet also co-mingled the two 2572 ([RFC0791]), although there was recognition in the early Internet 2573 work that there were two different things going on. [IEN19] 2575 This likely resulted not just from lack of insight, but also the fact 2576 that extra mechanism is needed to support this separation (and in the 2577 early days there were no resources to spare), as well as the lack of 2578 need for it in the smaller networks of the time. (It is a truism of 2579 system design that small systems can get away with doing two things 2580 with one mechanism, in a way that usually will not work when the 2581 system gets much larger.) 2583 The ISO protocol architecture took steps in this direction [NSAP], 2584 but to the Internet community the necessity of a clear separation was 2585 definitively shown by Saltzer. [RFC1498] Later work expanded on 2586 Saltzer's, and tied his separation concepts into the fate-sharing 2587 concepts of Clark. [Clark], [Chiappa] 2589 The separation of location and identity is a step which has recently 2590 been identified by the IRTF as a critically necessary evolutionary 2591 architectural step for the Internet. [RFC6115] However, it has taken 2592 quite some time for this requirement to be generally accepted by the 2593 Internet engineering community at large, although it seems that this 2594 may finally be happening. 2596 Unfortunately, although the development of IPv6 presented a golden 2597 opportunity to learn from this particular failing of IPv4, that 2598 design failed to recognize the need for separation of location and 2599 identity. 2601 B.2. A Brief History of the LISP Project 2603 {{Suggestion by editors: remove that makes no sense in this document 2604 }} 2606 The LISP system for separation of location and identity resulted from 2607 the discussions of this topic at the Amsterdam IAB Routing and 2608 Addressing Workshop, which took place in October 2006. [RFC4984] 2610 A small group of like-minded personnel from various scattered 2611 locations within Cisco, spontaneously formed immediately after that 2612 workshop, to work on an idea that came out of informal discussions at 2613 the workshop. The first Internet-Draft on LISP appeared in January, 2614 2007, along with a LISP mailing list at the IETF. 2615 [I-D.farinacci-lisp] 2617 Trial implementations started at that time, with initial trial 2618 deployments underway since June 2007; the results of early experience 2619 have been fed back into the design in a continuous, ongoing process 2620 over several years. LISP at this point represents a moderately 2621 mature system, having undergone a long organic series of changes and 2622 updates. 2624 LISP transitioned from an IRTF activity to an IETF WG in March 2009, 2625 and after numerous revisions, the basic specifications moved to 2626 becoming RFCs at the start of 2013 (although work to expand and 2627 improve it, and find new uses for it, continues, and undoubtly will 2628 for a long time to come). 2630 B.3. Old LISP 'Models' 2632 LISP, as initilly conceived, had a number of potential operating 2633 modes, named 'models'. Although they are now obsolete, one 2634 occasionally sees mention of them, so they are briefly described 2635 here. 2637 o LISP 1: EIDs all appear in the normal routing and forwarding 2638 tables of the network (i.e. they are 'routable');this property is 2639 used to 'bootstrap' operation, by using this to load EID->RLOC 2640 mappings. Packets were sent with the EID as the destination in 2641 the outer wrapper; when an ETR saw such a packet, it would send a 2642 Map-Reply to the source ITR, giving the full mapping. 2644 o LISP 1.5: Similar to LISP 1, but the routability of EIDs happens 2645 on a separate network. 2647 o LISP 2: EIDs are not routable; EID->RLOC mappings are available 2648 from the DNS. 2650 o LISP 3: EIDs are not routable; and have to be looked up in in a 2651 new EID->RLOC mapping database (in the initial concept, a system 2652 using Distributed Hash Tables). Two variants were possible: a 2653 'push' system, in which all mappings were distributed to all ITRs, 2654 and a 'pull' system in which ITRs load the mappings they need, as 2655 needed. 2657 B.4. The ALT Mapping Indexing Sub-system 2659 LISP initially used an indexing sub-system called ALT. [RFC6836]ALT 2660 re-purposed a number of existing mechanisms to provide an indexing 2661 system, which allowed an experimental LISP initial deployment to 2662 become operational without having to write a lot of code, ALT was 2663 relatively easily constructed from basically unmodified existing 2664 mechanisms; it used BGP running over virtual tunnels using GRE. 2666 ALT proved to have a number of issues which made it unsuitable for 2667 large-scale use, and it has now been superseded by DDT. A complete 2668 list of these is not possible here, but the issues mostly were of two 2669 kinds: technical issues which would have arisen at large scale, and 2670 practical operational issues which appeared even in the experimental 2671 deployment. 2673 The biggest operational issues was the effort involved in 2674 configuring, and maintain the configuration, of the virtual tunnels 2675 over which ALT ran (including assigning the addresses for the ends, 2676 etc); also, managing the multiple disjoint routing tables required 2677 was difficult and confusing (even for those who were very familiar 2678 with ALT). Debugging faults in ALT was also difficult; and finally, 2679 because of ALT's nature, administrative issues (who pays for what, 2680 who controls what, etc) were problematic. 2682 However, ALT would have had significant technical issues had it been 2683 used at a larger scale. 2685 The most severe (and fundamental) issue was that since all traffic on 2686 the ALT had to transit the 'root' of the ALT tree, those locations 2687 would have become traffic 'hot-spots' in a large scale deployment. 2689 In addition, optimal performance would have required that the ALT 2690 overall topology be restrained to follow the EID namespace 2691 allocation; however, it was not clear that this was feasible. In any 2692 event, even optimal performance was still less than that in 2693 alternatives. The ALT was also very vulnerable to misconfiguration. 2695 See [LISP-TREE] for more about these issues: the basic structure and 2696 operation of DDT is identical to that of TREE, so the conclusions 2697 drawn there about TREE's superiority to ALT apply equally to DDT. 2699 In particular, the big advantage of DDT over the ALT, in performance 2700 terms, is that it allows MRs to interact _directly_ with distant DDT 2701 servers (as opposed to the ALT, which _always_ required mediation 2702 through intermediate servers); caching of information about those 2703 distant servers allows DDT to make extremely effective use of this 2704 capability. 2706 The ALT did have some useful properties which its replacement, DDT, 2707 did not, e.g. the ability to forward data directly to the 2708 destination, over the ALT, when no mapping was available yet for the 2709 destination. However, these were minor, and heavily outweighed by 2710 its problems. 2712 A recent study, [Saucez], measured actual resolution times in the 2713 deployed LISP network during the changeover from ALT to DDT, allowing 2714 direct comparison of the performance of the two systems. The study 2715 took measurements from a variety of locations in the Internet, with 2716 respect to a number of different target EIDs. The results indicate 2717 that the performance was almost identical; there was more variance 2718 with DDT (perhaps due to the effects of caching), but the greatly 2719 improved scalability of DDT as compared to ALT made that effect 2720 acceptable. 2722 B.5. Early NAT Support 2724 The first mechanism used by LISP to support operation through a NAT 2725 device, described here, has now been superseded by the more general 2726 mechanism proposed in [I-D.ermagan-lisp-nat-traversal]. That 2727 mechanism is, however, based heavily on this mechanism. The initial 2728 mechanism had some serious limitations, which is why that particular 2729 form of it has been dropped. 2731 First, it only worked with some NATs, those which were configurable 2732 to allow inbound packet traffic to reach a configured host. The NAT 2733 had to be configured to know of the ETR. 2735 Second, since NATs share addresses by using ports, it was only 2736 possible to have a single LISP node behind any given NAT device. 2737 That is because LISP expects all incoming data traffic to be on a 2738 specific port, so it was not possible to have multiple ETRs behind a 2739 single NAT (which normally would have only one global IP address to 2740 share). Even looking at the sort host and port would not necessarily 2741 help, because some source ITR could be sending packets to both ETRs, 2742 so packets to either ETR could also have the identical source host/ 2743 port. In short, there was no way for a NAT with multiple ETRs behind 2744 it to know which ETR the packet was for. 2746 To support operation behind a NAT, there was a pair of new LISP 2747 control messages, LISP Echo-Request and Echo-Reply, which allowed the 2748 ETR to discover its temporary global address. The Echo-Request was 2749 sent to the configured Map-Server, and it replied with an Echo-Reply 2750 which included the source address from which the Echo Request was 2751 received (i.e. the public global address assigned to the ETR by the 2752 NAT). The ETR could then insert that address in any Map-Reply 2753 control messages which it sent to correspondent ITRs. 2755 Echo-Request and Echo-Reply have been replaced by Info-Request and 2756 Info-Reply in the replacement, [NAT-Traversal], where they perform 2757 very similar functions; the main change is the addition of the {{xxx 2758 - probably the port, etc to allow multiple XTRs behind a NAT}}. 2760 Authors' Addresses 2762 Albert Cabellos-Aparicio (Ed.) 2763 Technical University of Catalonia 2764 C/Jordi Girona, s/n 2765 BARCELONA 08034 2766 Spain 2768 Email: jacabello@ac.upc.edu 2770 Damien Saucez (Ed.) 2771 INRIA 2772 2004 route des Lucioles BP 93 2773 06902 Sophia Antipolis Cedex 2774 France 2776 Email: damien.saucez@inria.fr