idnits 2.17.1 draft-ietf-lisp-introduction-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- == The document has an IETF Trust Provisions of 28 Dec 2009, Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 1, 2013) is 3857 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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-improvements - is the name correct? == Outdated reference: A later version (-09) exists of draft-ietf-lisp-ddt-01 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-04 == Outdated reference: A later version (-19) exists of draft-ermagan-lisp-nat-traversal-03 == Outdated reference: A later version (-16) exists of draft-meyer-lisp-mn-08 == Outdated reference: A later version (-12) exists of draft-ietf-lisp-deployment-09 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-03 -- Obsolete informational reference (is this intentional?): RFC 1631 (Obsoleted by RFC 3022) -- Obsolete informational reference (is this intentional?): RFC 3272 (Obsoleted by RFC 9522) == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-00 -- No information found for draft-chiappa-lisp-evolution - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP Working Group J. N. Chiappa 3 Internet-Draft Yorktown Museum of Asian Art 4 Intended status: Informational October 1, 2013 5 Expires: April 4, 2014 7 An Architectural Introduction to the LISP 8 Location-Identity Separation System 9 draft-ietf-lisp-introduction-02 11 Abstract 13 LISP is an upgrade to the architecture of the IP internetworking 14 system, one which separates location and identity (previously 15 intermingled in IP addresses). This is a change which has been 16 identified by the IRTF as a critically necessary evolutionary 17 architectural step for the Internet. In LISP, nodes have both a 18 'locator' (a name which says _where_ in the network's connectivity 19 structure the node is) and an 'identifier' (a name which provides a 20 persistent handle for the node). A node may have more than one 21 locator, or its locator may change over time (e.g. if the node is 22 mobile), but it keeps the same identifier. 24 One of the chief novelties of LISP, compared to other proposals for 25 the separation of location and identity, is its approach to deploying 26 this upgrade. LISP aims to achieve the near-ubiquitous deployment 27 necessary for maximum exploitation of an architectural upgrade by i) 28 minimizing the amount of change needed (existing hosts and routers 29 can operate unmodified); and ii) by providing significant benefits to 30 early adopters. 32 This document is an introductory overview of the entire LISP system, 33 for those who are unfamiliar with it. The first half of the document 34 is a unified stand-alone brief introduction to LISP, for those who 35 only want a basic understanding of LISP; the document taken as a 36 whole provides a more detailed overview of LISP and its operation. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. This document may not be modified, 42 and derivative works of it may not be created, except to format it 43 for publication as an RFC or to translate it into languages other 44 than English. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on April 4, 2014. 58 Copyright Notice 60 Copyright (c) 2013 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Prefatory Note . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3. Deployment Philosophy . . . . . . . . . . . . . . . . . . . . 7 78 3.1. Economics . . . . . . . . . . . . . . . . . . . . . . . . 7 79 3.2. Maximize Re-use of Existing Mechanism . . . . . . . . . . 8 80 3.3. 'Self-Deployment' . . . . . . . . . . . . . . . . . . . . 8 81 4. LISP Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 82 4.1. Basic Approach . . . . . . . . . . . . . . . . . . . . . . 9 83 4.2. Basic Functionality . . . . . . . . . . . . . . . . . . . 10 84 4.3. Mapping from EIDs to RLOCs . . . . . . . . . . . . . . . . 11 85 4.4. Interworking With Non-LISP-Capable Endpoints . . . . . . . 11 86 4.5. Security in LISP . . . . . . . . . . . . . . . . . . . . . 12 87 5. Initial Applications . . . . . . . . . . . . . . . . . . . . . 12 88 5.1. Provider Independence . . . . . . . . . . . . . . . . . . 13 89 5.2. Multi-Homing . . . . . . . . . . . . . . . . . . . . . . . 13 90 5.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 14 91 5.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 5.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 5.6. IP Version Reciprocal Traversal . . . . . . . . . . . . . 15 94 5.7. Local Uses . . . . . . . . . . . . . . . . . . . . . . . . 16 95 6. Major Functional Subsystems . . . . . . . . . . . . . . . . . 16 96 6.1. xTRs . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 6.1.1. Mapping Cache Performance . . . . . . . . . . . . . . 17 98 6.2. The Mapping System . . . . . . . . . . . . . . . . . . . . 19 99 6.2.1. Mapping System Organization . . . . . . . . . . . . . 19 100 6.2.2. Interface to the Mapping System . . . . . . . . . . . 20 101 6.2.3. Indexing Sub-system . . . . . . . . . . . . . . . . . 21 102 7. Examples of Operation . . . . . . . . . . . . . . . . . . . . 23 103 7.1. An Ordinary Packet's Processing . . . . . . . . . . . . . 23 104 7.2. A Mapping Cache Miss . . . . . . . . . . . . . . . . . . . 24 105 8. Design Approach . . . . . . . . . . . . . . . . . . . . . . . 25 106 9. Data Plane - xTRs . . . . . . . . . . . . . . . . . . . . . . 25 107 9.1. When to Encapsulate . . . . . . . . . . . . . . . . . . . 25 108 9.2. UDP Encapsulation Details . . . . . . . . . . . . . . . . 26 109 9.3. Header Control Channel . . . . . . . . . . . . . . . . . . 27 110 9.3.1. Mapping Versioning . . . . . . . . . . . . . . . . . . 27 111 9.3.2. Echo Nonces . . . . . . . . . . . . . . . . . . . . . 27 112 9.3.3. Instances . . . . . . . . . . . . . . . . . . . . . . 28 113 9.4. Probing . . . . . . . . . . . . . . . . . . . . . . . . . 28 114 9.5. Mapping Lifetimes and Timeouts . . . . . . . . . . . . . . 29 115 9.6. Security of Mapping Lookups . . . . . . . . . . . . . . . 29 116 9.7. Mapping Gleaning in ETRs . . . . . . . . . . . . . . . . . 30 117 9.8. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 30 118 10. Control Plane - The Mapping System . . . . . . . . . . . . . . 30 119 10.1. The Mapping System Interface . . . . . . . . . . . . . . . 31 120 10.1.1. Map-Request Messages . . . . . . . . . . . . . . . . . 31 121 10.1.2. Map-Reply Messages . . . . . . . . . . . . . . . . . . 32 122 10.1.3. Map-Register and Map-Notify Messages . . . . . . . . . 32 123 10.2. The DDT Indexing Sub-system . . . . . . . . . . . . . . . 33 124 10.2.1. Map-Referral Messages . . . . . . . . . . . . . . . . 34 125 10.3. Reliability via Replication . . . . . . . . . . . . . . . 34 126 10.4. Security of the DDT Indexing Sub-system . . . . . . . . . 34 127 10.5. Extended Tools . . . . . . . . . . . . . . . . . . . . . . 35 128 10.6. Performance of the Mapping System . . . . . . . . . . . . 35 129 11. Multicast Support in LISP . . . . . . . . . . . . . . . . . . 36 130 11.1. Basic Concepts of Multicast Support in LISP . . . . . . . 36 131 11.2. Initial Multicast Support in LISP . . . . . . . . . . . . 37 132 12. Deployment Issues and Mechanisms . . . . . . . . . . . . . . . 38 133 12.1. LISP Deployment Needs . . . . . . . . . . . . . . . . . . 38 134 12.2. Interworking Mechanism . . . . . . . . . . . . . . . . . . 38 135 12.2.1. Proxy Devices . . . . . . . . . . . . . . . . . . . . 39 136 12.2.2. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . 40 137 12.3. Use Through NAT Devices . . . . . . . . . . . . . . . . . 41 138 12.4. LISP and DFZ Routing . . . . . . . . . . . . . . . . . . . 41 139 12.4.1. Long-term Possibilities . . . . . . . . . . . . . . . 42 140 13. Fault Discovery/Handling . . . . . . . . . . . . . . . . . . . 42 141 13.1. Handling Missing Mappings . . . . . . . . . . . . . . . . 42 142 13.2. Outdated Mappings . . . . . . . . . . . . . . . . . . . . 43 143 13.2.1. Outdated Mappings - Updated Mapping . . . . . . . . . 43 144 13.2.2. Outdated Mappings - Wrong ETR . . . . . . . . . . . . 43 145 13.2.3. Outdated Mappings - No Longer an ETR . . . . . . . . . 43 146 13.3. Erroneous Mappings . . . . . . . . . . . . . . . . . . . . 44 147 13.4. Neighbour ETR Liveness . . . . . . . . . . . . . . . . . . 44 148 13.5. Neighbour ETR Reachability . . . . . . . . . . . . . . . . 44 149 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 150 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 151 16. Security Considerations . . . . . . . . . . . . . . . . . . . 46 152 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 153 17.1. Normative References . . . . . . . . . . . . . . . . . . . 46 154 17.2. Informative References . . . . . . . . . . . . . . . . . . 47 155 Appendix A. Glossary/Definition of Terms . . . . . . . . . . . . 51 156 Appendix B. Other Appendices . . . . . . . . . . . . . . . . . . 53 157 B.1. A Brief History of Location/Identity Separation . . . . . 53 158 B.2. A Brief History of the LISP Project . . . . . . . . . . . 54 159 B.3. Old LISP 'Models' . . . . . . . . . . . . . . . . . . . . 55 160 B.4. The ALT Mapping Indexing Sub-system . . . . . . . . . . . 55 161 B.5. Early NAT Support . . . . . . . . . . . . . . . . . . . . 56 163 1. Prefatory Note 165 This document is the first of a pair which, together, form what one 166 would think of as the 'architecture document' for LISP (the 167 'Location-Identity Separation Protocol'). Much of what would 168 normally be in an architecture document (e.g. the architectural 169 design principles used in LISP, and the design considerations behind 170 various components and aspects of the LISP system) is in the second 171 document, the 'Architectural Perspective on LISP' document. 173 This 'Architectural Introduction' document is primarily intended for 174 those who unfamiliar with LISP, and want to start learning about it. 175 It is intended to both be easy to follow, and also to give the reader 176 a choice as to how much they wish to know about LISP. Reading only 177 the first part(s) of the document will give a good high-level view of 178 the system; reading the complete document should provide a fairly 179 detailed understanding of the entire system. 181 This goal explains why the document has a somewhat unusual structure. 182 It is not a typical reference document, where all the content on a 183 particular topic is grouped in one place. (That role is filled by 184 the various protocol specifications.) Instead, it is structured as a 185 series of phases, each covering the entire system, but with 186 increasing detail. 188 It starts with a very high-level view of the entire system, to 189 provide readers with a mental framework to help understand the more 190 detailed material which follows. A second pass over the whole system 191 then goes into more detail. Finally, individual sub-systems are 192 covered in still deeper detail. 194 The intent is two-fold: first, the multiple passes over the entire 195 system, each one going into more detail, are intended to ease 196 understanding; second, people can simply stop reading when they have 197 a detailed-enough understanding for their purposes. 199 People who just want to get an idea of how LISP works might only read 200 the first two parts; they can stop reading either just before, or 201 just after, Section 7, "Examples of Operation". People who are going 202 to go on and read all the protocol specifications (perhaps to 203 implement LISP) would need/want to read the entire document. 205 Note: This document is a descriptive document, not a protocol 206 specification. Should it differ in any detail from any of the LISP 207 protocol specification documents, they take precedence for the actual 208 operation of the protocol. 210 2. Background 212 It has gradually been realized in the networking community that 213 networks, especially large networks, should deal quite separately 214 with the 'identity' and 'location' of an 'endpoint' ([Chiappa]) - 215 basically, 'who' an endpoint is, and 'where' it is. (A more detailed 216 history of this evolution is in Appendix B.1, "A Brief History of 217 Location/Identity Separation".) 219 At the moment, in both IPv4 and IPv6, IP addresses indicate both 220 where the named node is, as well as identify it for purposes of end- 221 end communication. (The term 'node' is admittedly a nebulous one, 222 but it was deliberately chosen for use in this document precisely 223 because its definition is not fixed, and therefore unlikely to cause 224 erroneous images in the minds of readers. You will not go far wrong 225 if you think of a node as being something like a host.) 227 However, the separation of location and identity is a step which has 228 recently been identified by the IRTF as a critically necessary 229 evolutionary architectural step for the Internet. [RFC6115] 231 The on-going LISP project is an attempt to provide a viable path 232 towards this separation. (A brief history of the LISP project can be 233 found in Appendix B.2, "A Brief History of the LISP Project".) As an 234 add-on to a large existing system, it has had to make certain 235 compromises. (For a good example, see [Perspective], Section 236 "Residual Location Functionality in EIDs".) However, if it reaches 237 near-ubiquitous deployment, it will have two important consequences. 239 First, in effectively providing separation of location and identity, 240 along with a distributed directory of the bindings between them, 241 'Wheeler's Law' ("All problems in computer science can be solved by 242 another level of indirection") will come into play, and the Internet 243 technical community will have a new, immensely powerful, tool at its 244 disposal. The fact that the namespaces on both sides of the mapping 245 are global ones maximizes the power of that tool. (See 246 [Perspective], Section "Need for a Mapping System", for more on 247 this.) 249 Second, because of combination of flexible capability built into 250 LISP, and the breaking of the unification of location and identity 251 names, further architectural evolvement of the Internet becomes 252 easily available; for example, new namespaces for location could be 253 designed and deployed. (See [Future] for more on this.) 255 3. Deployment Philosophy 257 It may seem odd to cover 'deployment philosophy' at this point in 258 such a document. However the deployment philosophy was a major 259 driver for much of the design (to some degree the architecture, and 260 to a very large measure, the engineering). So, as such an important 261 motivator, it is very desirable for readers to have this material in 262 hand as they examine the design, so that design choices that may seem 263 questionable at first glance can be better understood. 265 Experience over the last several decades has shown that having a 266 viable 'deployment model' for a new design is absolutely key to the 267 success of that design. In general, it is comparatively easy to 268 conceive of new network designs, but much harder to devise approaches 269 which will actually get deployed throughout the global network. A 270 new design may be fantastic - but if it can not or will not be 271 successfully deployed (for whatever factors), it is useless. 273 This absolute primacy of a viable deployment model is what has lead 274 to some painful compromises in the design; and the extreme focus on a 275 viable deployment model (including economics) is one of the novelties 276 of LISP. 278 3.1. Economics 280 The key factor in successful adoption, as shown by recent experience 281 in the Internet - and little appreciated to begin with, some decades 282 back - is economics: does the new design have benefits which outweigh 283 its costs. 285 More importantly, this balance needs to hold for early adopters - 286 because if they do not receive benefits to their adoption, the sphere 287 of earliest adopters will not expand, and it will never get to 288 widespread deployment. One might have the world's best 'clean-slate' 289 design, but if it does not have a deployment plan which is 290 economically feasible, it's not good for much. 292 This is particularly true of architectural enhancements, which are 293 far less likely to be an addition which one can 'bolt onto the side' 294 of existing mechanisms, and often offer their greatest benefits only 295 when widely (or ubiquitously) deployed. 297 Maximizing the cost-benefit ratio obviously has two aspects. First, 298 on the cost side, by making the design as inexpensive as possible, 299 which means in part making the deployment as easy as possible. 300 Second, on the benefit side, by providing many new capabilities, 301 which is best done not by loading the design up with lots of features 302 or options (which adds complexity), but by making the addition 303 powerful through deeper flexibility. We believe LISP has met both of 304 these goals. 306 3.2. Maximize Re-use of Existing Mechanism 308 One key part of reducing the cost of a new design is to absolutely 309 minimize the amount of change _required_ to existing, deployed, 310 devices: the fewer devices need to be changed, and the smaller the 311 change to those that do, the lower the pain (and thus the greater the 312 likelihood) of deployment. 314 Designs which absolutely require 'forklift upgrades' to large amounts 315 of existing gear are far less likely to succeed - because they have 316 to have extremely large benefits to make their very substantial costs 317 worthwhile. 319 It is for this reason that LISP, in most cases, initially requires no 320 changes to almost all existing devices in the Internet (both hosts 321 and routers); LISP functionality needs to be added in only a few 322 places (see Section 12.1, "LISP Deployment Needs", for more). 324 LISP also initially reuses, where-ever possible, existing protocols 325 (IPv4 [RFC791] and IPv6 [RFC2460]). The 'initially' must be stressed 326 - careful attention has also long been paid to the long-term future 327 (see [Future]), and larger changes become feasible as deployment 328 increases. 330 3.3. 'Self-Deployment' 332 LISP has deliberately employed a rather different deployment model, 333 which we might call 'self-deployment' (for want of a better term); it 334 does not require a huge push to get it deployed, rather, it is hoped 335 that once people see it and realize they can easily make good use of 336 it _on their own_ (i.e. without requiring adoption by others), it 337 will 'deploy itself' (hence the name of the approach). 339 One can liken the problem of deploying new systems in this way to 340 rolling a snowball down a hill: unless one starts with a big enough 341 snowball, and finds a hill of the right steepness (i.e. the right 342 path for it to travel), one's snowball is not going to go anywhere on 343 its own. However, if one has picked one's spot correctly, once 344 started, little additional work is needed. 346 4. LISP Overview 348 LISP is an incrementally deployable architectural upgrade to the 349 existing Internet infrastructure, one which provides separation of 350 location and identity. It starts to separate the names used for 351 identity and location of nodes, which are currently unified in IPvN 352 addresses. (This document uses the meaning for 'address' proposed in 353 [Atkinson], i.e. a name with mixed location and identity semantics.) 355 The separation into names with purely location and identity semantics 356 is usually - but not necessarily - not perfect, for reasons which are 357 driven by the deployment philosophy (above), and explored in more 358 detail elsewhere (in [Perspective], Section "Namespaces-EIDs- 359 Residual"). 361 4.1. Basic Approach 363 In LISP, nodes have both an 'identifier' (a name which serves only to 364 provide a persistent handle for the node), called an 'EID' (short for 365 'endpoint identifier'), and an associated 'locator' (a name which 366 says _where_ in the network's connectivity structure the node is), 367 called an 'RLOC' (short for 'routing locator'). 369 A node may be associated with more than one RLOC, or the RLOC may 370 change over time (e.g. if the node is mobile), but it would normally 371 always have the same EID. 373 Ideally, one should think of the EID as naming the node - or rather, 374 its end-end communication entity (see [Chiappa] for more), if one 375 wants to be as forward-looking as possible. RLOC(s) name 376 interface(s) - usually on the xTRs, at this stage. 378 This second distinction, of _what_ is named by the two classes of 379 name, is a further important enhancement to the architecture; failing 380 to clearly recognize interfaces, and end-end communication entities, 381 as distinctly separate classes of objects is another failing of the 382 existing Internet architecture (again, one inherited from the 383 previous generation of networking). 385 The distinction is also is necessary both to enable some of the 386 capabilities that LISP provides (e.g the ability to seamlessly 387 support multiple interfaces, to different networks). 389 An important insight in LISP is that it initially uses existing IPvN 390 addresses for both of these kinds of names, as opposed to some 391 similar earlier proposals (e.g. [RFC1992]), which proposed using a 392 new namespace for locators. This choice minimized LISP's deployment 393 cost, as well as providing the ability to easily interact with un- 394 modified hosts and routers. 396 The capability to use other namespaces for both kinds of names is 397 already built in, which is expected to greatly increase the long-term 398 benefits, flexibility, and power of the LISP mapping layer. 400 4.2. Basic Functionality 402 The basic operation of LISP, as it currently stands, is quite simple. 403 LISP augmented packet switches near the source and destination of 404 packets intercept traffic, and 'enhance' the packets for the trip 405 between the LISP switches. 407 The overall processing is shown below, in Figure 1: 409 (to be added) 411 Figure 1: Basic LISP Packet Flow 413 The LISP device near the original source (the Ingress Tunnel Router, 414 or 'ITR') looks up additional information about the destination, and 415 then wraps the packet in an outer header, one which contains some of 416 that additional information. The LISP device near the destination, 417 the (the Egress Tunnel Router, or 'ETR') removes that header, leaving 418 the original, un-modified, packet to be sent on to the destination 419 node. 421 To retrieve that additional information, the ITR uses the information 422 in the original packet about the identity of its ultimate 423 destination, i.e. the destination address; in LISP, this is the EID 424 of the ultimate destination. It uses the destination EID to look up 425 the current location (the RLOC) of that EID. 427 The lookup is performed through a 'mapping system', which is the 428 heart of LISP: it is a distributed directory of mappings from EIDs to 429 RLOCs. The destination RLOC(s) will normally be the address(es) of 430 the ETR(s) near the ultimate destination. 432 The ITR then generates a new outer header for the original packet, 433 with that header containing the ETR's RLOC as the wrapped packet's 434 destination, and the ITR's own address (i.e. the RLOC associated with 435 the original source) as the wrapped packet's source, and sends it 436 off. 438 When the packet gets to the ETR, that outer header is stripped off, 439 and the original packet is forwarded to the original ultimate 440 destination for normal processing. 442 Return traffic is handled similarly, often (depending on the 443 network's configuration) with the original ITR and ETR switching 444 roles. The ETR and ITR functionality is usually co-located in a 445 single device; these are normally denominated as 'xTRs'. 447 4.3. Mapping from EIDs to RLOCs 449 The mappings from EIDs to RLOCs are provided by a distributed, and 450 potentially replicated, database, the 'mapping database', which is 451 the heart of LISP. Entities which need mappings get them from the 452 'mapping system', which is a collection of subsystems through which 453 clients can find and obtain mappings. (The mapping system will be 454 discussed in more detail below, in Section 6.2, "The Mapping System" 455 and Section 10, "Control Plane - The Mapping System".) 457 Mappings are requested on demand, and generally not pre-loaded; in 458 other words, mappings are normally distributed via a 'pull' 459 mechanism. Once obtained by an ITR, they are cached by the ITR, for 460 performance reasons. 462 Extensive studies, including large-scale simulations driven by 463 lengthy recordings of actual traffic at several major sites, have 464 been performed to verify that this 'pull and cache' approach is 465 viable, in practical engineering terms. (This subject will be 466 discussed in more detail in Section 6.1.1, "Mapping Cache 467 Performance", below.) 469 4.4. Interworking With Non-LISP-Capable Endpoints 471 It is clearly crucial to provide the capability for 'easy' 472 interoperation between hosts 'using' LISP (i.e. they are behind xTRs, 473 and their EIDs are in the mapping database), and existing non-LISP- 474 using hosts (often called 'legacy' hosts) or sites (where 'site' is 475 usually taken to mean a collection of hosts, routers and networks 476 under a single administrative control). 478 To allow such interoperation, a number of mechanisms have been 479 designed. This multiplicity is in part because different mechanisms 480 have different advantages and disadvantages (so that no single 481 mechanism is optimal for all cases); this also allows a choice to be 482 made when more field experience has been obtained. 484 One approach uses proxy LISP devices, called PITRs (proxy ITRs) and 485 PETRs (proxy ETRs), to provide LISP functionality during interaction 486 with legacy hosts. Another approach uses a device with combined LISP 487 and NAT ([RFC1631]) functionality, named a LISP-NAT. (See 488 Section 12.2.1, "Proxy Devices", and Section 12.2.2, "LISP-NAT", 489 respectively, for details of each.) 491 4.5. Security in LISP 493 LISP has a subtle security philosophy; see [Perspective], Section 494 "Security", where it is laid out in some detail. 496 To provide a brief overview, it is definitely understood that LISP 497 needs to be highly _securable_, especially in the long term; over 498 time, the attacks mounted by 'bad guys' are becoming more and more 499 sophisticated. So LISP, like DNS, needs to be _capable_ of providing 500 'the very best' security there is. 502 At the same time, there is a conflicting goal: it must be deployable 503 (i.e. have a viable cost). That means two things: First, with the 504 limited manpower currently available, we cannot expect to create the 505 complete security apparatus that we might see in the long term (which 506 requires not just design, but also implementation, etc). Second, 507 security needs to be flexible, so that we don't overload the users 508 with more security than they need at any point. 510 To accomplish these divergent goals, the approach taken is to 511 thorougly analyze what LISP needs for security, and then design, in 512 detail, a scheme for providing that security. Then, steps can be 513 taken to ensure that the appropriate 'hooks' (such as packet fields) 514 are included at an early stage, when doing so is still easy. Later 515 on, the design can be fully specified, implemented, and deployed. 517 LISP does already include a number of security mechanisms; in 518 particular, requesting mappings can be secured (see Section 9.6, 519 "Security of Mapping Lookups"), as can registering of xTRs (see 520 Section 10.1.3, "Map-Register and Map-Notify Messages"); the key 521 indexing database of the mapping system is also secured (see 522 Section 10.4, "Security of the DDT Indexing Sub-system"). 524 The existing security mechanisms, and their configuration (which is 525 mostly manual at this point) currently in LISP are felt to be 526 adequate for the needs of the on-going early stages of deployment; 527 experience will indicate when improvements are required (within the 528 constraints of the conflicting goal given above). 530 5. Initial Applications 532 As previously mentioned, it is felt that LISP will provide even the 533 earliest adopters with some useful capabilities, and that these 534 capabilities will drive early LISP deployment. 536 It is very imporant to note that even when used only for 537 interoperation with existing unmodified hosts, use of LISP can still 538 provide benefits for communications with the site which has deployed 539 it - and, perhaps even more importantly, can do so _to both sides_. 540 This characteristic acts to further enhance the utility for early 541 adopters of deploying LISP, thereby increasing the cost/benefit ratio 542 needed to drive deployment, and increasing the 'self-deployment' 543 aspect of LISP. 545 Note also that this section only lists likely _early_ applications 546 and benefits - if and once deployment becomes more widespread, other 547 aspects will come into play (as described in [Perspective], in the 548 Section "Goals of LISP"). 550 5.1. Provider Independence 552 Provider independence (i.e. the ability to easily change one's 553 Internet Service Provider) was probably the first place where the 554 Internet engineering community finally really felt the utility of 555 separating location and identity. 557 The problem is simple: for the global routing to scale, addresses 558 need to be aggregated (i.e. things which are close in the overall 559 network's connectivity need to have closely related addresses), the 560 so-called "provider aggregatable" addresses. [RFC4116] However, if 561 this principle is followed, it means that when an entity switches 562 providers (i.e. it moves to a different 'place' in the network), it 563 has to renumber, a painful undertaking. [RFC5887] 565 In theory, it ought to be sufficient to update the DNS entries, and 566 have everyone switch to the new addresses, but in practise, addresses 567 are embedded in many places, such as firewall configurations at other 568 sites. 570 Having separate namespaces for location and identity greatly reduces 571 the problems involved with renumbering; an organization which moves 572 retains its EIDs (which are how most other parties refer to its 573 nodes), but is allocated new RLOCs, and the mapping system can 574 quickly provide the updated mapping from the EIDs to the new RLOCs. 576 5.2. Multi-Homing 578 Multi-homing is another place where the value of separation of 579 location and identity became apparent. There are several different 580 sub-flavours of the multi-homing problem - e.g. depending on whether 581 one wants open connections to keep working, etc - and other axes as 582 well (e.g. site multi-homing versus host multi-homing). 584 In particular, for the 'keep open connections up' case, without 585 separation of location and identity, the only currently feasible 586 approach is to use provider-independent addressses - which moves the 587 problem into the global routing system, with attendant costs. This 588 approach is also not really feasible for host multi-homing. 590 Multi-homing was once somewhat esoteric, but a number of trends are 591 driving an increased desirability, e.g. the wish to have multiple ISP 592 links to a site for robustness; the desire to have mobile handsets 593 connect up to multiple wireless systems; etc. 595 Again, separation of location and identity, and the existince of a 596 mapping layer which can be updated fairly quickly, as provided by 597 LISP, is a very useful tool for all variants of this issue. 599 5.3. Traffic Engineering 601 Traffic engineering (TE) [RFC3272], desirable though this capability 602 is in a global network, is currently somewhat problematic to provide 603 in the Internet. The problem, fundamentally, is that this capability 604 was not forseen when the Internet was designed, so the support for it 605 via 'hacks' is neither clean, nor flexible. 607 TE is, fundamentally, a routing issue. However, the current Internet 608 routing architecture, which is basically the Baran design of fifty 609 years ago [Baran] (a single large, distributed computation), is ill- 610 suited to provide TE. The Internet seems a long way from adopting a 611 more-advanced routing architecture, although the basic concepts for 612 such have been known for some time. [RFC1992] 614 Although the identity-location mapping layer is thus a poor place, 615 architecturally, to provide TE capabilities, it is still an 616 improvement over the current routing tools available for this purpose 617 (e.g. injection of more-specific routes into the global routing 618 table). 620 In addition, instead of the entire network incurring the costs 621 (through the routing system overhead), when using a mapping layer to 622 provide TE, the overhead is limited to those who are actually 623 communicating with that particular destination. 625 LISP includes a number of features in the mapping system to support 626 TE. (described in Section 6.2, "The Mapping System", below); more 627 details about using LISP for TE can be found in [LISP-TE]. 629 Also, a number of academic papers have explored how LISP can be used 630 to do TE, and how effective it can be. See the online LISP 631 Bibliography ([Bibliography]) for information about them. 633 5.4. Routing 635 Multi-homing and Traffic Engineering are both, in some sense, uses of 636 LISP for routing, but there are many other routing-related uses for 637 LISP. 639 One of the major original motivations for the separation of location 640 and identity in general, and thus LISP, was to reduce the growth of 641 the routing tables in the so-called 'Default-Free-Zone' (DFZ) - the 642 core of the Internet, the part where routes to _all_ ultimate 643 destinations must be available. LISP is expected to help with this; 644 for more detail, see Section 12.4, "LISP and DFZ Routing", below. 646 LISP may also have more local applications in which it can help with 647 routing; see, for instance, [CorasBGP]. 649 5.5. Mobility 651 Mobility is yet another place where separation of location and 652 identity is obviously a key part of a clean, efficient and high- 653 functionality solution. Considerable experimentation has been 654 completed on doing mobility with LISP. 656 The mobility provided by LISP allows active sessions to survive moves 657 (provided of course that there is not a period of inaccessability 658 which exceeds a timeout). LISP mobility also will typically have 659 better packet 'stretch' (i.e. increase in path length) compared to 660 traditional mobility schemes, which use a 'home agent'. 662 5.6. IP Version Reciprocal Traversal 664 Note that LISP inherently supports intermixing of various IP versions 665 for packet carriage; IPv4 packets might well be carried in IPv6, or 666 vice versa, depending on the network's configuration. 668 This capability allows an 'island' of operation of one type to be 669 'automatically' tunneled over a stretch of infrastucture which only 670 supports the other type. 672 While the machinery of LISP may seem too heavy-weight to be good for 673 such a mundane use, this is not intended as a 'sole use' case for 674 deployment of LISP. Rather, it is something which, if LISP is being 675 deployed anyway (for its other advantages), is an added benefit that 676 one gets 'for free'. 678 5.7. Local Uses 680 LISP has a number of use cases which are within purely local 681 contexts, i.e. not in the larger Internet. These fall into two 682 categories: uses seen on the Internet (above), but here on a private 683 (and usually small scale) setting; and applications which do not have 684 a direct analog in the larger Internet, and which apply only to local 685 deployments. 687 Among the former are multi-homing, IP version traversal, and support 688 of VPN's for segmentation and multi-tenancy (i.e. a spatially 689 separated private VPN whose components are joined together using the 690 public Internet as a backbone). 692 Among the latter class, non-Internet applications which have no 693 analog on the Internet, are the following example applications: 694 virtual machine mobility in data centers; other non-IP EID types such 695 as local network MAC addresses, or application specific data. 697 Several of the applications listed in this section are the ones which 698 have been most popular for LISP in practise; these include virtual 699 networks, and virtual machine mobility. 701 These often show a synergistic tendency, in that a site which 702 installs LISP to do one, often finds that then becomes a small matter 703 to use it for the second. Given all the things which LISP can do, it 704 is hoped that this synergistic effect will continue to expand LISP's 705 uses. 707 6. Major Functional Subsystems 709 LISP has only two major functional sub-systems - the collection of 710 LISP packet switches (the xTRs), which form the 'data plane' of LISP; 711 and the mapping system, the most important part of the 'control 712 plane', which manages the mapping database. 714 The purpose and operation of each is described at a high level below, 715 and then, later on, in a fair amount of detail, in separate sections 716 on each (Sections Section 9, "Data Plane - xTRs", and Section 10, 717 "Control Plane - The Mapping System", respectively). 719 6.1. xTRs 721 xTRs are IPvN packet switches which have been augmented with extra 722 functionality in both the data and control planes, to perform LISP 723 data and control functionality (respectively). 725 The data plane functions in ITRs include deciding which packets need 726 to be given LISP processing (since packets to non-LISP hosts may be 727 sent as they are); i.e. looking up the mapping; encapsulating 728 (wrapping) the packet; and sending it to the ETR. To the extent that 729 traffic engineering features are in use for a particular EID, the 730 ITRs implement them as well. 732 This encapsulation is done using UDP [RFC768] (for reasons to be 733 explained below, in Section 9.2, "UDP Encapsulation Details"), along 734 with an additional outer IPvN header (to hold the source and 735 destination RLOCs). 737 In the ETR, the data plane simply decapsulates (unwraps) the packets, 738 and forwards the now-normal packets to the ultimate destination. 740 Control plane functions in ITRs include: asking for {EID->RLOC} 741 mappings via request control messages (Map-Request packets); handling 742 the returning reply control messages (Map-Reply packets), which 743 contain the requested information; managing the local cache of 744 mappings; checking for the reachability and liveness of their 745 neighbour ETRs; and checking for outdated mappings and requesting 746 updates. 748 In the ETR, control plane functions include participating in the 749 neighbour reachability and liveness function (see Section 13.4, 750 "Neighbour ETR Liveness"); interacting with the mapping sub-system to 751 let it know what mapping this ETR can provide (see Section 6.2.2, 752 "Interface to the Mapping System"); and answering requests from ITRs 753 for those mappings (ditto). 755 6.1.1. Mapping Cache Performance 757 As mentioned, studies have been performed to verify that caching 758 mappings in ITRs is viable, in practical engineering terms. These 759 studies not only verified that such caching is feasible, but also 760 provided some insight for designing ITR mapping caches. 762 Obviously, these studies are all snapshots of a particular point in 763 time, and as the Internet continues its life-cycle they will 764 increasingly become out-dated. However, they are useful because they 765 provide an insight into how well LISP can be expected to perform, and 766 scale, over time. 768 Full details of the results are too lengthy to include here; see 769 [Perspective], Section "Mapping Cache Performance" for more. 771 Briefly, however, the first, [Iannone], was performed in the very 772 early stages of the LISP effort, to verify that that caching approach 773 was feasible. 775 Packet traces of all traffic over the external connection of a large 776 university over a week-long period were collected; simulations driven 777 by these recording were then performed. A variety of control 778 settings on the cache were used, to study the effects of varying the 779 settings. 781 First, the simulation gave the cache sizes that would result from 782 such a cache design: it showed that the resulting cache sizes ranged 783 from 7,500 entries, up to about 100,000 (depending on factors such as 784 traffic and entry retention time). Using some estimations as to how 785 much memory mapping entries would use, this indicated cache sizes of 786 between roughly 100 Kbytes and a few Mbytes. 788 Of more interest, in a way, were the results regarding two important 789 measurements of the effectiveness of the cache: i) the hit ratio 790 (i.e. the share of references which could be satisified by the 791 cache), and ii) the miss _rate_ (since control traffic overhead is 792 one of the chief concerns when using a cache). These results were 793 also encouraging: miss (and hence lookup) rates ranged from 30 per 794 minute, up to 3,000 per minute. 796 Significantly, this was substantially lower than the amount of 797 observed DNS traffic, which ranged from 1,800 packets per minute up 798 to 15,000 per minute. The results overall showed that using a 799 demand-loaded cache was an entirely plausible design approach: both 800 cache size, and the control plane traffic load, were definitely 801 feasible. 803 The second, [Kim], was in general terms similar, except that it used 804 data from a large ISP, one with about three times as many users as 805 the previous study. It used the same cache design philosophy (the 806 cache size was not fixed), but slightly different, lower, retention 807 time values. 809 The results were similar: cache sizes ranges from 20,000 entries to 810 roughly 60,000; the miss rate ranged from very roughly 400 per minute 811 to very roughly 7,000 per minute, similar to the previous results. 813 Finally, a third study, [CorasCache], examined the effect of using a 814 fixed size cache, and a purely Least Recently Used (LRU) cache 815 eviction algorithm (i.e. no timeouts). It also tried to verify that 816 models of the performance of such a cache (using previous theoretical 817 work on caches) produced results that conformed with actual empirical 818 measurements. 820 It used yet another set of packet traces; using a cache size of 821 around 50,000 entries produced a miss rate of around 1x10-4; again, 822 definitely viable, and in line with the results of the other studies. 824 6.2. The Mapping System 826 The mapping system's entire purpose is to give ITRs on-demand access 827 to the mapping database, which is a distributed, and potentially 828 replicated, database which holds mappings between EIDs (identity) and 829 RLOCs (location), along with needed ancillary data (e.g. lifetimes). 831 To be exact, it contains mappings between EID blocks and RLOCs (the 832 block size is given explicitly, as part of the syntax). Support for 833 blocks is both for minimizing the administrative configuration 834 overhead, as well as for operational efficiency; e.g. when a group of 835 EIDs are behind a single xTR. 837 However, the block may be, and often is, as small as a single EID. 838 However, since mappings are only loaded upon demand, if smaller 839 blocks become predominant, then the increased size of the overall 840 database is far less problematic than if the Internet's routing 841 tables came to be dominated by such small entries. 843 A particular EID (or EID block) may have more than one RLOC, or may 844 change its RLOC(s), while keeping its basic identity. 846 Also, in general, throughout LISP, anyplace a name (EID, RLOC, etc) 847 appears in a control packet, the packet format also includes an 848 Address Family Identifier (AFI) for that name. [AFI] The inclusion 849 of the AFI allows LISP (and in particular, the mapping system 850 interface, as embodied in those control packets) a great deal of 851 flexibility. (See [Perspective], Section "Namespaces" for more on 852 this.) 854 RLOC(s) may be compound names; see [Improvements], Section "LISP 855 Canonical Address Format (LCAF)" for more. 857 Finally, the mapping from an EID (or EID block) contains not just the 858 RLOC(s), but also (for each RLOC for any given EID entry) priority 859 and weight fields (to allow allocation of load between several RLOCs 860 at a given priority); this allows a certain amount of traffic 861 engineering to be accomplished with LISP. 863 6.2.1. Mapping System Organization 865 The mapping system is actually split into what are effectively three 866 major functional sub-systems (although the latter two are closely 867 integrated, and appear to most entities in the LISP system as a 868 single sub-system). 870 The first covers the actual mappings themselves; they are held by the 871 ETRs, and an ITR which needs a mapping gets it (effectively) directly 872 from the ETR. This co-location of the authoritative version of the 873 mappings, and the forwarding functionality which it describes, is an 874 instance of fate-sharing. [Clark] 876 To find the appropriate ETR(s) to query for the mapping, the second 877 two sub-systems form an 'indexing system', itself also a distributed, 878 potentially replicated database. It provides information on which 879 ETR(s) are authoritative sources for the various {EID -> RLOC} 880 mappings which are available. The two sub-systems which form it are 881 the client interface sub-system, and indexing sub-system (which holds 882 and provides the actual information). 884 6.2.2. Interface to the Mapping System 886 The client interface to the indexing system from an ITR's point of 887 view is not with the indexing sub-system directly; rather, it is 888 through the client-interface sub-system, which is provied by devices 889 called Map-Resolvers (MRs). 891 ITRs send request control messages (Map-Request packets) to an MR. 892 (This interface is probably the most important standardized interface 893 in LISP - it is the key to the entire system.) The MR then uses the 894 indexing sub-system to allow it to forward the Map-Request to an 895 appropriate MS, which in turn sends the Map-Request on to the 896 appropriate ETR. The latter is authoritative for the actual contents 897 of all mappings for those EID namespace blocks which have been 898 delegated to it. 900 The ETR then formulates reply control messages (Map-Reply packets), 901 which are sent to the ITR. The details of the indexing sub-system 902 are thus hidden from the ITRs. 904 (Note that in some cases, it is desirable for the MS to reply on 905 behalf of the ETR, in so-called 'proxy' mode. This behaviour can be 906 selected when the ETR registers with the MR, described immediately 907 below.) 909 Similarly, the client interface to the indexing system from an ETR's 910 point of view is through devices called Map-Servers (MSs - perhaps a 911 poorly chosen term, since their primary function is not to send 912 responses to queries from clients of the mapping system). 914 ETRs send registration control messages (Map-Register packets) to an 915 MS, which makes the information about the mappings which the ETR 916 indicates it is authoritative for available to the indexing sub- 917 system. 919 The MS formulates a reply control message (the Map-Notify packet), 920 which confirms the registration, and is returned to the ETR. The 921 details of the indexing sub-system are thus likewise hidden from the 922 'ordinary' ETRs. 924 The fact that the details of the indexing sub-system are entirely 925 hidden from xTRs gives considerably flexibility to this aspect of 926 LISP. As long as any potential indexing sub-system can track where 927 mappings are, it could potentially be used; this would allow the 928 actual indexing sub-system to be replaced without needing to modify 929 the clients - as has happened once already (see below). 931 6.2.3. Indexing Sub-system 933 The current indexing sub-system is the Delegated Database Tree (DDT), 934 which is very similar to DNS ([DDT], [RFC1034]), although unlike DNS, 935 DDT was designed from the start to be secured. Also unlike DNS, the 936 actual mappings are not handled by DDT; DDT, as the indexing sub- 937 system, merely identifies the ETRs which hold the actual mappings. 939 DDT replaced an earlier indexing sub-system, ALT (Appendix B.4, "The 940 ALT Mapping Indexing Sub-system"); this swap validated the concept of 941 having a client-interface sub-system between the indexing sub-system, 942 and the clients. 944 6.2.3.1. DDT Overview 946 Conceptually, DDT is fairly simple: like DNS, in DDT the delegation 947 of the EID namespace ([Perspective], Section "Namespaces-XEIDs") is 948 instantiated as a tree of DDT 'nodes', starting with the 'root' DDT 949 node. Each node is responsible (authoritative?) for one or more 950 blocks of the EID namespace. 952 The 'root' node is reponsible for the entire namespace; any DDT node 953 can 'delegate' part(s) of its block(s) of the namespace to child DDT 954 node(s). The child node(s) can in turn further delegate (necessarily 955 smaller) blocks of namespace to their children, through as many 956 levels as are needed (for operational, administrative, etc, needs). 958 Just as with DNS, for reasons of performance, reliability and 959 robustness, any particular node in the DDT delegation tree may be 960 instantiated in more than one redundant physical server machines. 961 Obviously, all the servers which instantiate a particular node in the 962 tree have to have identical data about that node; if they do not, 963 when a Map-Request is sent to one that does not have consistent 964 information with its other sibling(s), incorrect results will be 965 returned. 967 Also, although the delegation hierarchy is a strict tree , a single 968 DDT server could be responsible (authoritative?) for more than one 969 block of the EID namespace. 971 Eventually, leaf nodes in the DDT tree statically delegate EID 972 namespace blocks to MS's, which are DDT terminal nodes; i.e. a leaf 973 of the tree is reached when the delegation points to an MS instead of 974 to another DDT node. 976 The MS is in direct communication with the ETR(s) which both i) are 977 authoritative for the mappings for that block, and ii) handle traffic 978 to that block of EID namespace. 980 6.2.3.2. Use of DDT by MRs 982 An MR which wants to find a mapping for a particular EID first 983 interacts with the nodes of the DDT tree, discovering (by querying 984 DDT nodes) the chain of delegations which cover that EID. Eventually 985 it is directed to an MS, and then to an ETR which is responsible 986 {{authoritative?}} for that EID. 988 Also, again like DNS, MRs cache information about the delegations in 989 the DDT tree. This means that once an MR has been in operation for 990 while, it will usually have much of the delegation information cached 991 locally (especially the top levels of the delegation tree). This 992 allows them, when passed a request for a mapping by an ITR, to 993 usually forward the mapping request to the appropriate MS without 994 having to do a complete tree-walk of the DDT tree to find any 995 particular mappping. 997 Thus, a typical resolution cycle would usually involve looking at 998 some locally cached delegation information, perhaps loading some 999 missing delegation entries into their delegation cache, and finally 1000 sending the Map-Request to the appropriate MS. 1002 The big advantage of DDT over the ALT, in performance terms, is that 1003 it allows MRs to interact _directly_ with distant DDT nodes (as 1004 opposed to the ALT, which _always_ required mediation through 1005 intermediate nodes); caching of information about those distant nodes 1006 allows DDT to make extremely effective use of this capability. 1008 It should also be noted that the delegation tree is fairly static, 1009 since it reflects namespace allocations, which are themselves fairly 1010 static. This stability has several important consequences. First, 1011 it increases the performance of the mapping system, since 1012 intermediate nodes almost never need to be re-queried. Second, it is 1013 not necessary to include a mechanism to find outdated delegations. 1015 The _mappings_, however, may change at a high rate, and the system is 1016 designed to make sure that such changes are acted upon. This allows 1017 LISP to provide a number of capabilities, such as mobility. 1019 7. Examples of Operation 1021 To aid in comprehension, a few examples are given of user packets 1022 traversing the LISP system. The first shows the processing of a 1023 typical user packet, i.e. what the vast majority of user packets will 1024 see. The second shows what happens when the first packet to a 1025 previously-unseen ultimate destination (at a particular ITR) is to be 1026 processed by LISP. 1028 7.1. An Ordinary Packet's Processing 1030 This case follows the processing of a typical user packet (for 1031 instance, a normal TCP data or acknowledgment packet associated with 1032 an already-open TCP connection) - i.e. not the first packet sent from 1033 a given source to a given destination - as it makes its way from the 1034 original source host to the ultimate destination. 1036 When the packet has made its way through the local site to an ITR 1037 (which in this case is a border router for the site), the border 1038 router looks up the destination address (an EID) in its local mapping 1039 cache. For EIDs which are IPvN addresses, this lookup uses the usual 1040 IPvN 'longest prefix match' algorithm. 1042 It finds a mapping, which instructs it to wrap the packet in an outer 1043 header (an IP packet, containing a UDP packet which contains a LISP 1044 header, and then the user's original packet (see Section 9.2, "UDP 1045 Encapsulation Details", for the reasons for this particular choice). 1046 The destination address in the outer header is set by the ITR to the 1047 RLOC of the destination ETR. 1049 The packet is then sent off through the Internet, using normal 1050 Internet routing tables, etc. 1052 On arrival at the destination ETR, the ETR will notice that it is 1053 listed as the destination in the outer header. It will examine the 1054 packet, detect that it is a LISP packet, and unwrap it. It will then 1055 examine the header of the user's original packet, and forward it 1056 internally, through the local site, to the ultimate destination. 1058 At the ultimate destination, the packet will be processed, and may 1059 produce a return packet, which follows the exact same process in 1060 reverse - with the exception that the roles of the ITR and ETR are 1061 swapped. 1063 7.2. A Mapping Cache Miss 1065 If a host sends a packet, and it gets to the ITR, and the ITR both i) 1066 determines that it needs to perform LISP processing on the user data 1067 packet, but ii) does not yet have a mapping cache entry which covers 1068 that destination EID, then additional processing ensues; it has to 1069 look up the mapping in the mapping system (as previously described in 1070 Section 4.2, "Basic Functionality"). 1072 The overall processing is shown below, in Figure 2: 1074 Mapping System 1076 ----- ----- 1077 | | 4 | | 1078 Map Resolver | | -------> | | Map Server 1079 | | | | 1080 ----- ----- 1081 ^ | 1082 Key: | | 1083 | | 1084 -- = Control | | 1085 == = Data | | 1086 2 | 6 | 5 1087 | --- | 1088 Host A | / \ | Host B 1089 | |_ \ V 1090 ----- ----- \ ----- ----- 1091 | | 1 | | 7 | | 8 | | 1092 | | =====> | ITR | =======> | ETR | =====> | | 1093 | | | | | | | | 1094 ----- ----- ----- ----- 1096 Figure 2: Packet Flow With Missing Mapping 1098 1. Source-EID sends packet (to Dest-EID) to ITR 1099 2. ITR sends Map-Request to Map Resolver 1100 3. (Not shown) Map-Resolver locates corrrect Map-Server for Dest-EID 1101 4. Map-Resolver delivers Map-Request to Map-Server 1102 5. Map-Server delivers Map-Request to ETR 1103 6. ETR returns Map-Reply to ITR; ITR caches EID-to-RLOC(s) mapping 1104 7. ITR uses mapping to encapsulate to ETR; sends user packet to ETR 1105 8. 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 node which is closest in the 1110 delegation tree to that destination EID which it has information for. 1112 If it does not have the RLOC of an appropriate MS, it will query the 1113 DDT system, recursively if need be, in order to eventually find the 1114 RLOC of such an MS. 1116 When it has the MS's RLOC, it will send the Map-Request on to the MS, 1117 which then sends it on to an appropriate ETR. The ETR sends a Map- 1118 Reply to the ITR which needs the mapping; from then on, processing of 1119 user packets through that ITR to that ultimate destination proceeds 1120 as above. 1122 Often (as with many ARP implementations), the original user packet 1123 will have been discarded, and not queued waiting for the mapping to 1124 be returned. When the host retransmits such a packet, the mapping 1125 will be there, and the packet will be forwarded. Alternatively, it 1126 might have been queued, or perhaps it was forwarded using a PITR. 1127 (Section 4.4, "Interworking With Non-LISP-Capable Endpoints")> 1129 8. Design Approach 1131 Before describing LISP's components in more detail below, it it worth 1132 pointing out that what may seem, in some cases, like odd (or poor) 1133 design approaches do in fact result from the application of a 1134 thought-through, and consistent, design philosophy used in creating 1135 them. 1137 This design philosophy is covered in detail in in [Perspective], 1138 Section "Design"), and readers who are interested in the 'why' of 1139 various mechanisms should consult that; reading it may make clearer 1140 the reasons for some engineering choices in the mechanisms given 1141 here. 1143 9. Data Plane - xTRs 1145 As mentioned above (in Section 6.1, "xTRs"), xTRs are the basic data- 1146 handling devices in LISP, and, as such, form the LISP data plane. 1147 This section explores some advanced topics related to xTRs. 1149 Careful rules have been specified for both TTL and ECN [RFC3168] to 1150 ensure that passage through xTRs does not interfere with the 1151 operation of these mechanisms. In addition, care has been taken to 1152 ensure that 'traceroute' works when xTRs are involved. 1154 9.1. When to Encapsulate 1156 An ITR knows that an ultimate destination is 'running' LISP (remember 1157 that the destination machine itself probably knows nothing about 1158 LISP), and thus that it should perform LISP processing on a packet 1159 (including potential encapsulation) if it has an entry in its local 1160 mapping cache that covers the destination EID. 1162 Conversely, if the cache contains a 'negative' entry (indicating that 1163 the ITR has previously attempted to find a mapping that covers this 1164 EID, and it has been informed by the mapping system that no such 1165 mapping exists), it knows the ultimate destination is not running 1166 LISP, and the packet can be forwarded natively (i.e. not LISP- 1167 encapsulated). 1169 Note that the ITR cannot simply depend on the appearance, or non- 1170 appearance, of the destination in the routing tables in the DFZ, as a 1171 way to tell if an ultimate destination is a LISP node or not. That 1172 is because mechanisms to allow interoperation of LISP sites and 1173 'legacy' sites necessarily involve advertising LISP sites' EIDs into 1174 the DFZ; in other words, LISP sites which need to interoperate with 1175 'legacy' nodes will appear in the DFZ routing tables, along with non- 1176 LISP sites. 1178 9.2. UDP Encapsulation Details 1180 The UDP encapsulation used by LISP for carrying traffic from ITR to 1181 ETR, and many of the details of how it works, were all chosen for 1182 very practical reasons. 1184 Use of UDP (instead of, say, a LISP-specific protocol number) was 1185 driven by the fact that many devices filter out 'unknown' protocols, 1186 so adopting a non-UDP encapsulation would have made the initial 1187 deployment of LISP harder - and our goal (see Section 3.1, 1188 "Economics") was to make the deployment as easy as possible. 1190 The UDP source port in the encapsulated packet is a 5-way hash of the 1191 original source and ultimate destination in the inner header, along 1192 with the ports, and the protocol. 1194 This is because many ISPs use multiple parallel paths (so-called 1195 'Equal Cost Multi-Path'), and load-share across them. Using such a 1196 hash in the source-port in the outer header both allows LISP traffic 1197 to be load-shared, and also ensures that packets from individual 1198 connections are delivered in order (since most ISPs try to ensure 1199 that packets for a particular {source, source port, destination, 1200 destination port} tuple flow along a single path, and do not become 1201 disordered). 1203 The UDP checksum is zero because the inner packet usually already has 1204 a end-end checksum, and the outer checksum adds no value. [Saltzer] 1205 In most exising hardware, computing such a checksum (and checking it 1206 at the other end) would also present an intolerable load, for no 1207 benefit. 1209 9.3. Header Control Channel 1211 LISP provides a multiplexed channel in the encapsulation header. It 1212 is mostly (but not entirely) used for control purposes. (See 1213 [Perspective], Section "Architecture-Piggyback" for a longer 1214 discussion of the architectural implications of performing control 1215 functions with data traffic.) 1217 The general concept is that the header starts with an 8-bit 'flags' 1218 field, and it also includes two data fields (one 24 bits, one 32), 1219 the contents and meaning of which vary, depending on which flags are 1220 set. This allows these fields to be 'multiplexed' among a number of 1221 different low-duty-cycle functions, while minimizing the space 1222 overhead of the LISP encapsulation header. 1224 9.3.1. Mapping Versioning 1226 One important use of the multiplexed control channel is mapping 1227 versioning; i.e. the discovery of when the mapping cached in an ITR 1228 is outdated. To allow an ITR to discover this, identifying sequence 1229 numbers are applied to different versions of a mappping. [RFC6834] 1230 This allows an ITR to easily discover when a cached mapping has been 1231 updated by a more recent variant. 1233 Version numbers are available in control messages (Map-Replies), but 1234 the initial concept is that to limit control message overhead, the 1235 versioning mechanism should primarily use the multiplex user data 1236 header control channel. 1238 Versioning can operate in both directions: an ITR can advise an ETR 1239 what version of a mapping it is currently using (so the ETR can 1240 notify it if there is a more recent version), and ETRs can let ITRs 1241 know what the current mapping version is (so the ITRs can request an 1242 update, if their copy is outdated). 1244 At the moment version numbers are manually assigned, and ordered. 1245 Some felt that this was non-optimal, and that a better approach would 1246 have been to have 'fingerprints' which were computed from the current 1247 mapping data (i.e. a hash). It is not clear that the ordering buys 1248 much (if anything), and the potential for mishaps with manually 1249 configured version numbers is self-evident. 1251 9.3.2. Echo Nonces 1253 Another important use of the header control channel is for a 1254 mechanism known as the Nonce Echo, which is used as an efficient 1255 method for ITRs to check the reachability of correspondent ETRs. 1257 Basically, an ITR which wishes to ensure that an ETR is up, and 1258 reachable, sends a nonce to that ETR, carried in the encapsulation 1259 header; when that ETR (acting as an ITR) sends some other user data 1260 packet back to the ITR (acting in turn as an ETR), that nonce is 1261 carried in the header of that packet, allowing the original ITR to 1262 confirm that its packets are reaching that ETR. 1264 Note that lack of a response is not necessarily _proof_ that 1265 something has gone wrong - but it stronly suggests that something 1266 has, so other actions (e.g. a switch to an alternative ETR, if one is 1267 listed; a direct probe; etc) are advised. 1269 (See Section 13.5, "Neighbour ETR Reachability", for more about Echo 1270 Nonces.) 1272 9.3.3. Instances 1274 Another use of these header fields is for 'Instances' - basically, 1275 support for VPN's across backbones. [RFC4026] Since there is only 1276 one destination UDP port used for carriage of user data packets, and 1277 the source port is used for multiplexing (above), there is no other 1278 way to differentiate among different destination address namespaces 1279 (which are often overlapped in VPNs). 1281 9.4. Probing 1283 RLOC-Probing (see [RFC6830], Section 6.3.2. "RLOC-Probing Algorithm" 1284 for details) is a mechanism method that an ITR can use to determine 1285 with certainty that an ETR is up and reachable from the ITR. As a 1286 side-benfit, it gives a rough RTT estimates. 1288 It is quite a simple mechanism - an ITR simply sends a specially 1289 marked Map-Request directly to the ETR it wishes information about; 1290 that ETR sends back a specially marked Map-Reply. A Map-Request and 1291 Map-Reply are used, rather than a special probing control-message 1292 pair, because as a side-benefit the ITR can discover if the mapping 1293 has been updated since it cached it. 1295 The probing mechanism is rather heavy-weight and expensive (compared 1296 to mechanisms like the Echo-Nonce), since it costs a control message 1297 from each side, so it should only be used sparingly. However, it has 1298 the advantages of providing information quickly (a single RTT), and 1299 being a simple, direct robust way of doing so. 1301 If the number of neighbour ETRs of the ITR is large, use of RLOC- 1302 Probing to check on their reachability will result in considerable 1303 control traffic; such control traffic has to be spread out to prevent 1304 a load peak. 1306 Obviously, if RLOC-Probing is the only mechanism being used to detect 1307 unreachable neighbour ETRs, the rate at which RLOC-Probing is done 1308 will control the timeliness of the detection of loss of reachability. 1309 There is thus a tradeoff between overhead and responsiveness, 1310 particular when an ITR has a large fanout of neighbour ETRs. 1312 A further observation is that unless what are likely unreasonable 1313 amounts of RLOC Probing are being done, Echo Nonce will generally 1314 provide faster notification of loss of reachability (unless there is 1315 little or no bi-directional traffic between the ITR and ETR). 1317 9.5. Mapping Lifetimes and Timeouts 1319 Mappings come with a Time-To-Live, which indicate how long the 1320 creator of the mapping expects them to be useful for. The TTL may 1321 also indicate that the mapping should not be cached at all, or it can 1322 indicate that it has no particular lifetime, and the recipient can 1323 chose how long to store it. 1325 Mappings might also be discarded before the TTL expires, depending on 1326 what strategies the ITR is using to maintain its cache; if the 1327 maximum cache size is fixed, or the ITR needs to reclaim memory, 1328 mappings which have not been used 'recently' may be discarded. 1329 (After all, there is no harm in so doing; a future reference will 1330 merely cause that mapping to be reloaded.) 1332 9.6. Security of Mapping Lookups 1334 LISP provides an optional mechanism to secure the obtaining of 1335 mappings by an ITR. [LISP-SEC] It provides protection against 1336 attackers generating spurious Map-Reply messages (including replaying 1337 old Map-Replies), and also against 'over-claiming' attacks (where a 1338 malicious ETR by claims EID-prefixes which are larger what what have 1339 been actually delegated to it). 1341 Very briefly, the ITR provided a One-Time Key with its Map-Request; 1342 this key is used by both the MS (to sign an affirmation that it has 1343 delegated that EID block to that ETR), and indirectly by the ETR (to 1344 sign the mapping that it is returning to the ITR). 1346 The specification for LISP-SEC suggests that the ITR-MR stage be 1347 cryptographically protected, and indicates that the existing 1348 mechanisms for securing the ETR-MS stage are used to protect Map- 1349 Rquests also. It does assume that the channel from the MR to the MS 1350 is secure (otherwise an attacker could obtain the OTK from the Map- 1351 Request and use it to forge a reply). 1353 9.7. Mapping Gleaning in ETRs 1355 As an optimization to the mapping acquisition process, ETRs are 1356 allowed to 'glean' mappings from incoming user data packets, and also 1357 from incoming Map-Request control messages. This is not secure, and 1358 so any such mapping must be 'verified' by sending a Map-Request to 1359 get an authoritative mapping. (See further discussion of the 1360 security implications of this in [Perspective], Section "Security- 1361 xTRs".) 1363 The value of gleaning is that most communications are two-way, and so 1364 if host A is sending packets to host B (therefore needing B's 1365 EID->RLOC mapping), very likely B will soon be sending packets back 1366 to A (and thus needing A's EID->RLOC mapping). Without gleaning, 1367 this would sometimes result in a delay, and the dropping of the first 1368 return packet; this is felt to be very undesirable. 1370 9.8. Fragmentation 1372 Several mechanisms have been proposed for dealing with packets which 1373 are too large to transit the path from a particular ITR to a given 1374 ETR. 1376 In one, called the 'stateful' approach, the ITR keeps a per-ETR 1377 record of the maximum size allowed, and sends an ICMP Too Big message 1378 to the original source host when a packet which is too large is seen. 1380 In the other, referred to as the 'stateless' approach, for IPv4 1381 packets without the 'DF' bit set, too-large packets are fragmented, 1382 and then the fragments are forwarded; all other packets are 1383 discarded, and an ICMP Too Big message returned. 1385 It is not clear at this point which approach is preferable. 1387 10. Control Plane - The Mapping System 1389 As discussed already in Section 6.2, " The Mapping System", the LISP 1390 mapping system is the most important part of LISP's control plane: it 1391 i) maintains the database of mappings between EIDs, and the RLOCs at 1392 which they are to be found, and ii) provides those mappings to ITRs 1393 which request them, so that the ITRs can send traffic for a given EID 1394 to the correct RLOC(s) for that EID. 1396 RFC 1034 ("DNS Concepts and Facilities") has this to say about the 1397 DNS name to IP address database and mapping system: 1399 "The sheer size of the database and frequency of updates suggest 1400 that it must be maintained in a distributed manner, with local 1401 caching to improve performance. Approaches that attempt to 1402 collect a consistent copy of the entire database will become more 1403 and more expensive and difficult, and hence should be avoided." 1405 and this observation applies equally to the LISP mapping database and 1406 mapping system. 1408 To briefly recap, the mapping system is split into three parts: i) an 1409 indexing sub-system, which keeps track of where all the mappings are 1410 kept; ii) the interface to the indexing system (which remains the 1411 same, even if the actual indexing system is changed); and iii) the 1412 mappings themselves, the authoritative copies of which are always 1413 held by ETRs. 1415 10.1. The Mapping System Interface 1417 As mentioned in Section 6.2.2, "Interface to the Mapping System", 1418 both of the inferfaces to the mapping system (from ITRs, and ETRs) 1419 are standardized, so that the more numerous xTRs do not have to be 1420 modified when the mapping indexing sub-system is changed. 1422 (This precaution has already allowed the mapping system to be 1423 upgraded during LISP's evolution, when ALT was replaced by DDT.) 1425 This section describes the interfaces in a little more detail; for 1426 details, see [RFC6833]. 1428 10.1.1. Map-Request Messages 1430 The Map-Request message contains a number of fields, the two most 1431 important of which are the requested EID block identifier (remember 1432 that individual mappings may cover a block of EIDs, not just a single 1433 EID), and the Address Family Identifier (AFI) for that EID block. 1435 Other important fields are the source EID (and its AFI), and one or 1436 more RLOCs for the source EID, along with their AFIs. Multiple RLOCs 1437 are included to ensure that at least one is in a form which will 1438 allow the reply to be returned to the requesting ITR, and the source 1439 EID is used for a variety of functions, including 'gleaning' (see 1440 Section 9.7, " Mapping Gleaning in ETRs"). 1442 Finally, the message includes a long nonce, for simple, efficient 1443 protection against offpath attackers (see [Perspective], Section 1444 "Security-xTRs" for more), and a variety of other fields and control 1445 flag bits. 1447 10.1.2. Map-Reply Messages 1449 The Map-Reply message looks similar, except it includes the mapping 1450 entry for the requested EID(s), which contains one or more RLOCs and 1451 their associated data. (Note that the reply may cover a larger block 1452 of the EID namespace than the request; most requests will be for a 1453 single EID, the one which prompted the query.) 1455 If there are no mappings available at all for the EID(s) requested, a 1456 'Negative Map-Reply' message will be returned. This is a Map-Reply 1457 message with flag bits set to indicate that fact. 1459 For each RLOC in the entry, there is the RLOC, its AFI, priority and 1460 weight fields (see Section 6.2, " The Mapping System"), and multicast 1461 priority and weight fields (see Section 11, "Multicast Support in 1462 LISP"> for more about multicast support in LISP). 1464 10.1.2.1. Solicit-Map-Request Messages 1466 "Solicit-Map-Request" (SMR) messages are actually not another message 1467 type, but a sub-type of Map-Reply messages. They include a special 1468 flag which indicates to the recipient that it _should_ send a new 1469 Map-Request message, to refresh its mapping, because the ETR has 1470 detected that the one it is using is out-dated. 1472 SMR's, like most other control traffic, is rate-limited. 1474 10.1.3. Map-Register and Map-Notify Messages 1476 The Map-Register message contains authentication information, and a 1477 number of mapping records, each with an individual Time-To-Live 1478 (TTL). Each of the records contains an EID (potentially, a block of 1479 EIDs) and its AFI, a version number for this mapping (see 1480 Section 9.3.1, "Section 9.3.1 format="title"/>"), and a number of 1481 RLOCs and their AFIs. 1483 Each RLOC entry also includes the same data as in the Map-Replies 1484 (i.e. priority and weight); this is because in some circumstances it 1485 is advantageous to allow the MS to proxy reply on the ETR's behalf to 1486 Map-Request messages, and the MS needs this information when it does 1487 so (see [Mobility]). 1489 Map-Notify messages have the exact same contents as Map-Register 1490 messages; they are purely acknowledgements (although planned LISP 1491 functionality extensions may give them other functions as well). 1493 The entire interaction can be authenticated by use of a shared key, 1494 configured in the MS and ETR. Although the protocol does already 1495 allow for replacement of the encryption algorithm, it does not 1496 support automated key management (although it appears to fall under 1497 the exclusions in [RFC4107]). 1499 10.2. The DDT Indexing Sub-system 1501 As previously mentioned in Section 6.2.3, "Indexing Sub-system", the 1502 indexing sub-system in LISP is currently the DDT system. 1504 The overall operation is fairly simple; an MR which needs a mapping 1505 starts at a server for the root DDT node (there will normally be more 1506 than one such server available, for both performance and robustness 1507 reasons), and through a combination of cached delegation information, 1508 and repetitive querying of a sequence of DDT servers, works its way 1509 down the delegation tree until it arrives at an MS which is 1510 authoritative (responsible?) for the block of EID namespace which 1511 holds the destination EID in question. 1513 The interaction between MRs and DDT servers is not complex; the MR 1514 sends the DDT server a Map-Request control message. The DDT server 1515 uses its data (which is configured, and static) to see whether it is 1516 directly peered to an MS which can answer the request, or if it has a 1517 child (or children, if replicated) which is responsible for that 1518 portion of the EID namespace. 1520 If it has children configured which are responsible, it will reply to 1521 the MR with another kind of LISP control message, a Map-Referral 1522 message, which provides information about the delegation of the block 1523 containing the requested EID. This process is secured; see 1524 Section 10.4, "Security of the DDT Indexing Sub-system", for more. 1526 The Map-Referral also gives the RLOCs of all the machines which are 1527 DDT servers for that block. and the MR can then send Map-Requests to 1528 any one (or all) of them. In addition, the Map-Referral includes key 1529 data for the children, which allows any information provided by them 1530 to be cryptographically verified. 1532 Control flags in the Map-Referral indicate to the querying MR whether 1533 the referral is to another DDT node, an MS, or an ETR. If the 1534 former, the MR then sends the Map-Request to the child DDT node, 1535 repeating the process. 1537 If the latter, the MR then interacts with that MS, and usually the 1538 block's ETR(s) as well, to cause a mapping to be sent to the ITR 1539 which queried the MR for it. (Recall that some MS's provide Map- 1540 Replies on behalf of an associated ETR, in so-called 'proxy mode', so 1541 in such cases the Map-Reply will come from the MS, not the ETR. ) 1542 Delegations are cached in the MRs, so that once an MR has received 1543 information about a delegation, it will not need to look that up 1544 again. Once it has been in operation for a short while, it will only 1545 need to ask for delegation information which is has not yet asked 1546 about - probably only the last stage in a delegation to a 'leaf' MS. 1548 As describe below (Section 10.6, "Performance of the Mapping 1549 System"), significant amounts of modeling and performance measurement 1550 have been performed, to verify that DDT has (and will continue to 1551 have) acceptable performance. 1553 10.2.1. Map-Referral Messages 1555 Map-Referral messages look almost identical to Map-Reply messages, 1556 except that the RLOCs potentially name either i) other DDT nodes 1557 (children in the delegation tree), or ii) terminal MSs. 1559 10.3. Reliability via Replication 1561 Everywhere throughout the mapping system, robustness to operational 1562 failures is obtained by replicating data in multiple instances of any 1563 particular node (of whatever type). Map-Resolvers, Map-Servers, DDT 1564 nodes, ETRs - all of them can be replicated, and the protocol 1565 supports this replication. 1567 The deployed DDT system actually uses anycast [RFC4786], along with 1568 replicated servers, to improve both performance and robustness. 1570 There are generally no mechanisms specified yet to ensure coherence 1571 between multiple copies of any particular data item (e.g. the copies 1572 of delegation data for a particular block of namespace, in DDT 1573 sibling servers) - this is currently a manual responsibility. 1575 If and when LISP protocol adoption proceeds, an automated layer to 1576 perform this functionality can 'easily' be layered on top of the 1577 existing mechanisms. 1579 10.4. Security of the DDT Indexing Sub-system 1581 LISP provides an advanced model for securing the mapping indexing 1582 system, in line with the overall LISP security philosophy. 1584 Briefly, securing the mapping indexing system is broken into two 1585 parts: the interface between the clients of the system (MR's) and the 1586 mapping indexing system itself, and the interaction between the DDT 1587 nodes/servers which make it up. 1589 The client interface provides only a single model, using the 1590 'canonical' public-private key system (starting from a trust anchor), 1591 in which the child's public key is provided by the parent, along with 1592 the delegation. When the child returns any data, it can sign the 1593 data, and the requestor can use that signature to verify the data. 1594 This requires very little configuration in the clients, and is fairly 1595 secure. 1597 The interface between the DDT nodes/servers allows for choices 1598 between a number of different options, allowing the operators to 1599 trade off among configuration complexity, security level, etc. This 1600 is based on experience with DNS-SEC ([RFC4033]), where configuration 1601 complexity in the servers has been a major stumbling block to 1602 deployment. 1604 See [Perspective], Section "Security-Mappings" for more. 1606 10.5. Extended Tools 1608 In addition to the priority and weight data items in mappings, LISP 1609 offers other tools to enhance functionality, particularly in the 1610 traffic engineering area. 1612 One is 'source-specific mappings', i.e. the ETR may return different 1613 mappings to the enquiring ITR, depending on the identity of the ITR. 1614 This allows very fine-tuned traffic engineering, far more powerful 1615 than routing-based TE. 1617 10.6. Performance of the Mapping System 1619 Prior to the creation of DDT, a large study of the performance of the 1620 previous mapping system, ALT ([ALT]), along with a proposed new 1621 design called TREE (which used DNS to hold delegation information) 1622 provided considerable insight into the likely performance of the 1623 mapping systems at larger scale. [Jakab] The basic structure and 1624 concepts of DDT are identical to those of TREE, so the performance 1625 simulation work done for that design applies aequally to DDT. 1627 In that study, as with earlier LISP performance analyses, extensive 1628 large-scale simulations were driven by lengthy recordings of actual 1629 traffic at several major sites; one was the site in the first study 1630 ([Iannone]), and the other was an even large university, with roughly 1631 35,000 users. 1633 The results showed that a system like DDT, which caches information 1634 about delegations, and allows the MR to communicate directly with the 1635 lower nodes on the delegation hierarchy based on cached delegation 1636 information, would have good performance, with average resolution 1637 times on the order of the MR to MS RTT. This verified the 1638 effectiveness of this particular type of indexing system. 1640 A more recent study, [Saucez], has measured actual resolution times 1641 in the deployed LISP network; it took measurements from a variety of 1642 locations in the Internet, with respect to a number of different 1643 target EIDs. Average measured resolution delays ranged from roughly 1644 175 msec to 225 msec, depending on the location. 1646 11. Multicast Support in LISP 1648 Multicast ([RFC3170], [RFC5110]) may seem an odd thing to support 1649 with LISP, since LISP is all about separating identity from location, 1650 and although a multicast group in some sense has an identity, it 1651 certainly does not have _a_ location. 1653 However, multicast is very important to some users of the network, 1654 for a number of reasons: doing multiple unicast streams is 1655 inefficient, as it is easy to use up all the upstream bandwidth; 1656 without multicast a server can also be saturated fairly easily in 1657 doing the unicast replication; etc. 1659 So it is important for LISP to work well with multicast; doing so has 1660 been a significant focus in LISP throughout its entire development. 1662 Further very significant improvements to multicast support in LISP 1663 are in progress; see [Improvements], Section "Multicast" for more on 1664 them. 1666 11.1. Basic Concepts of Multicast Support in LISP 1668 This section introduces most of the basic principles of multicast 1669 support in LISP. 1671 Since group addresses name distributed collective entities, in 1672 general they cannot have a single RLOC (although they may, after 1673 future improvements in multicast support in LISP, have multiple 1674 RLOCs); also, since they usually refer to collections of entities, 1675 they aren't really EIDs either. 1677 A multicast source at a LISP site may not be able to become the root 1678 of a distribution tree in the core if it uses its EID as its identity 1679 for that distribution tree (i.e. a distribution tree (S-EID, G)); 1680 that is because there may not be a route to its EID in the core 1681 (assuming that its section of the core even supports multicast; not 1682 all parts of the core do). 1684 Therefore, outside the LISP site, multicast state for the 1685 distribution tree (S-RLOC, G) needs to be built instead, where S-RLOC 1686 is the RLOC of the ITR that the multicast source inside the LISP site 1687 will be sending its traffic through. 1689 Similarly, multicast receivers must join using the RLOC of the ETR 1690 through which traffic will be forward to them. 1692 Multicast LISP requires no packet format changes to existing 1693 multicast packets (both control, and user data). The initial 1694 multicast support in LISP uses existing multicast control mechanisms 1695 exclusively; improvements currently being worked on provide LISP- 1696 specific control mechanisms (see [Improvements], Section "Multicast", 1697 for more). 1699 11.2. Initial Multicast Support in LISP 1701 Readers who wish to fully understand multicast support need to 1702 consult the appropriate specifications: LISP multicast issues are 1703 discussed in [RFC6830], Section 11; and see [RFC6831] for the full 1704 details of current multicast support in LISP. 1706 In the current simple operating mode (covered in [RFC6831]), 1707 destination group addresses are not mapped; only the source address 1708 (when the original source is inside a LISP site) needs to be mapped, 1709 both during distribution tree setup, as well as actual traffic 1710 delivery. 1712 In other words, while LISP's mapping capability is used, at this 1713 stage it is only applied to the source, not the destination (as with 1714 most LISP activity). Thus, in LISP-encapsulated multicast packets in 1715 this mode, the inner source is the EID, and the outer source is the 1716 EID's RLOC; both inner and outer destinations are the group's 1717 multicast address. 1719 Note that this does mean that if the group is using separate source- 1720 specific trees for distribution, there isn't a separate distribution 1721 tree outside the LISP site for each different source of traffic to 1722 the group from inside the LISP site; they are all lumped together 1723 under a single source, the RLOC. 1725 The issue of encapsulation is complex, because if the rest of the 1726 group outside the LISP site includes some members which are at other 1727 LISP sites (i.e. packets to them have to be encapsulated), and some 1728 members at legacy sites (i.e. encapsulated packets would not be 1729 understood), there is no simple answer. (The situation becomes even 1730 more complex when one considers that as hosts leave and joint the 1731 group, it may switch back and forth between 'mixed' and 1732 'homogenous'.) 1733 This issue is too complex to fully cover here; see Section 9.2., 1734 "LISP Sites with Mixed Address Families", in [RFC6831], for complete 1735 coverage of this issue. 1737 Basically, there are multicast equivalents of some of the legacy 1738 interoperability mechanisms used for unicast; mPITRs and mPETRs 1739 (multicast-capable PITRs and PETRs) etc. When 'mixed' groups are a 1740 possibility, two choices are available: i) send two copies (one 1741 encapsulated, and one not) of all traffic, or ii) employ mPETRs to 1742 distribute non-encapsulated copies to 'legacy' group members. 1744 12. Deployment Issues and Mechanisms 1746 This section discusses several deployment issues in more detail. 1747 With LISP's heavy emphasis on practicality, much work has gone into 1748 making sure it works well in the real-world environments most people 1749 have to deal with. 1751 12.1. LISP Deployment Needs 1753 As mentioned earlier (Section 3.2, "Maximize Re-use of Existing 1754 Mechanism"), LISP requires no change to almost all existing hosts and 1755 routers. Obviously, however, one must deploy _something_ to run 1756 LISP! Exactly what that has to be will depend greatly on the details 1757 of the site's existing networking gear, and choices it makes for how 1758 to achieve LISP deployment. 1760 The primary requirement is for one or more xTRs. These may be 1761 existing routers, just with new software loads, or it may require the 1762 deployment of new devices. 1764 LISP also requires a certain amount of LISP-specific support 1765 infrastructure, such as MRs, MSs, the DDT hierarchy, etc but much of 1766 this will either i) already be deployed, and if the new site can make 1767 arrangements to use it, it need do nothing else, or ii) those 1768 functions the site must provide may be co-located in other LISP 1769 devices (again, either new devices, or new software on existing 1770 ones). 1772 12.2. Interworking Mechanism 1774 One aspect which has received a lot of attention are the mechanisms 1775 previously referred to (in Section 4.4, "Interworking With Non-LISP- 1776 Capable Endpoints") to allow interoperation of LISP sites with so- 1777 called 'legacy' sites which are not running LISP (yet). 1779 To briefly refresh what was said there, there are two main approaches 1780 to such interworking: proxy nodes (PITRs and PETRs), and an 1781 alternative mechanism using device with combined NAT and LISP 1782 functionality; these are described in more detail here. 1784 12.2.1. Proxy Devices 1786 PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to 1787 nodes using LISP. PETRs (proxy ETRs) serve as ETRs for LISP traffic 1788 _to_ legacy hosts (for cases where a LISP device cannot send packets 1789 directly to such hosts, without encapsulation). 1791 Note that return traffic _to_ a legacy host from a LISP-using node 1792 does not necessarily have to pass through an ITR/PETR pair - the 1793 original packets can usually just be sent directly to the ultimate 1794 destination. However, for some kinds of LISP operation (e.g. mobile 1795 nodes), this is not possible; in these situations, the PETR is 1796 needed. 1798 12.2.1.1. PITRs 1800 PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to 1801 nodes using LISP. To do that, they have to advertise into the 1802 existing legacy backbone Internet routing the availability of 1803 whatever ranges of EIDs (i.e. of nodes using LISP) they are proxying 1804 for, so that legacy hosts will know where to send traffic to those 1805 LISP nodes. 1807 As mentioned previously (Section 9.1, "When to Encapsulate"), an ITR 1808 at another LISP site can avoid using a PITR (i.e. it can detect that 1809 a given ultimate destination is not a legacy host, if a PITR is 1810 advertising it into the DFZ) by checking to see if a LISP mapping 1811 exists for that ultimate destination. 1813 This technique obviously has an impact on routing table in the DFZ, 1814 but it is not clear yet exactly what that impact will be; it is very 1815 dependent on the collected details of many individual deployment 1816 decisions. 1818 A PITR may cover a group of EID blocks with a single EID 1819 advertisement, in order to reduce the number of routing table entries 1820 added. (In fact, at the moment, aggressive aggregation of EID 1821 announcements is performed, precisely to to minimize the number of 1822 new announced routes added by this technique.) 1824 At the same time, if a site does traffic engineering with LISP 1825 instead of fine-grained BGP announcement, that will help keep table 1826 sizes down (and this is true even in the early stages of LISP 1827 deployment). The same is true for multi-homing. 1829 12.2.1.2. PETRs 1831 PETRs (proxy ETRs) serve as ETRs for LISP traffic _to_ legacy hosts, 1832 for cases where a LISP device cannot send packets to such hosts 1833 without encapsulation. That typically happens for one of two 1834 reasons. 1836 First, it will happen in places where some device is implementing 1837 Unicast Reverse Path Forwarding (uRPF), to prevent a variety of 1838 negative behaviour; originating packets with the original source's 1839 EID in the source address field will result in them being filtered 1840 out and discarded. 1842 Second, it will happen when a LISP site wishes to send packets to a 1843 non-LISP site, and the path in between does not support the 1844 particular IP protocol version used by the original source along its 1845 entire length. Use of a PETR on the other side of the 'gap' will 1846 allow the LISP site's packet to 'hop over' the gap, by utilizing 1847 LISP's built-in support for mixed protocol encapsulation. 1849 PETRs are generally paired with specific ITRs, which have the 1850 location of their PETRs configured into them. In other words, unlike 1851 normal ETRS, PETRs do not have to register themselves in the mapping 1852 database, on behalf of any legacy sites they serve. 1854 Also, allowing an ITR to always send traffic leaving a site to a PETR 1855 does avoid having to chose whether or not to encapsulate packets; it 1856 can just always encapsulate packets, sending them to the PETR if it 1857 has no specific mapping for the ultimate destination. However, this 1858 is not advised: as mentioned, it is easy to tell if something is a 1859 legacy destination. 1861 12.2.2. LISP-NAT 1863 A LISP-NAT device, as previously mentioned, combines LISP and NAT 1864 functionality, in order to allow a LISP site which is internally 1865 using addresses which cannot be globally routed to communicate with 1866 non-LISP sites elsewhere in the Internet. (In other words, the 1867 technique used by the PITR approach simply cannot be used in this 1868 case.) 1870 To do this, a LISP-NAT performs the usual NAT functionality, and 1871 translates a host's source address(es) in packets passing through it 1872 from an 'inner' value to an 'outer' value, and storing that 1873 translation in a table, which it can use to similarly process 1874 subsequent packets (both outgoing and incoming). [RFC6832] 1876 There are two main cases where this might apply: 1878 - Sites using non-routable global addresses 1879 - Sites using private addresses [RFC1918] 1881 12.3. Use Through NAT Devices 1883 Like them or not (and NAT devices have many egregious issues - some 1884 inherent in the nature of the process of mapping addresses; others, 1885 such as the brittleness due to non-replicated critical state, caused 1886 by the way NATs were introduced, as stand-alone 'invisible' boxes), 1887 NATs are both ubiquitous, and here to stay for a long time to come. 1888 [RFC1631] Thus, in the actual Internet of today, having any new 1889 mechanisms function well in the presence of NATs (i.e. with LISP xTRs 1890 behind a NAT device) is absolutely necessary. 1892 LISP has produced a variety of mechanisms to do this. The earliest 1893 mechanism to support them had major limitations; it, and its 1894 limitations, are described in Appendix B.5, "Early NAT Support". A 1895 more recent proposed mechanism, which avoids those limitations, is 1896 described in [Improvements], Section "Improved NAT Support". 1898 12.4. LISP and DFZ Routing 1900 One of LISP's original motivations was to try and control the growth 1901 of the size of the so-called 'Default-Free-Zone' (DFZ), the core of 1902 the Internet, the part where routes to _all_ destinations must be 1903 available. As LISP becomes more widely deployed, it can help with 1904 this issue, in a variety of ways. 1906 In covering this topic, one must recognize that conditions in various 1907 stages of LISP deployment (in terms of ubiquity) will have a large 1908 influence. [Deployment] introduced useful terminology for this 1909 progression, in addition to some coverage of the topic (see Section 1910 5, "Migration to LISP"): 1912 The loosely defined terms of "early transition phase", "late 1913 transition phase", and "LISP Internet phase" refer to time periods 1914 when LISP sites are a minority, a majority, or represent all edge 1915 networks respectively. 1917 In the early phases of deployment, two primary effects will allow 1918 LISP to have a positive impact on the routing table growth: 1919 - Using LISP for traffic engineering instead of BGP 1920 - Aggregation of smaller PI sites into a single PITR advertisement 1921 The first is fairly obvious (doing TE with BGP requires injecting 1922 more-specific routes into the DFZ routing tables, something doing TE 1923 with LISP avoids); the second is not guaranteed to happen (since it 1924 requires coordination among a number of different parties), and only 1925 time will tell if it does happen. 1927 12.4.1. Long-term Possibilities 1929 At a later stage of the deployment, a more aggressive approach 1930 becomes available: taking part of the DFZ, one for which all 'stub' 1931 sites connected to it have deployed LISP, and removing all 'EID 1932 routes' (used for backwards compatability with 'legacy' sites); only 1933 RLOC routes would remain in the routing table in that part of the 1934 Internet backbone. 1936 Obviously there would be a boundary between the two parts of the DFZ, 1937 and the routers on the border would have to (effectively) become 1938 PITRs, and inject routes to all of the LISP sites 'behind' them into 1939 the 'legacy' DFZ (to coin a name for the part of the DFZ which, for 1940 reasons of interoperability with legacy sites, still carries EID 1941 routes). 1943 Note that it is likely not feasible to have the 'RLOC only' part of 1944 the DFZ in the 'middle' of the DFZ; that would require (effectively) 1945 EID routes to be removed from BGP on crossing the boundary _into_ the 1946 RLOC DFZ, but re-created on crossing the boundary _out_ of the RLOC 1947 DFZ. This is likely to be impractical, leading to the suggestion of 1948 a simpler boundary between the RLOC-only part of the DFZ, and the 1949 'legacy' DFZ. 1951 The mechanism for detecting which routes are 'EID routes' and which 1952 are 'RLOC routes' (required for the boundary routers to be able to 1953 filter out the 'EID routes') would also need to be worked out; the 1954 most likely appears to be something involving BGP attributes. 1956 13. Fault Discovery/Handling 1958 LISP is, in terms of its functionality, a fairly simple system: the 1959 list of failure modes is thus not extensive. 1961 13.1. Handling Missing Mappings 1963 Handling of missing mappings is fairly simple: the ITR calls for the 1964 mapping, and in the meantime can either discard traffic to that 1965 ultimate destination (as many ARP implementations do) [RFC826], or, 1966 if dropping the traffic is deemed undesirable, it can forward them 1967 via a 'default PITR'. 1969 A number of PITRs advertise all EID blocks into the backbone routing, 1970 so that any ITRs which are temporarily missing a mapping can forward 1971 the traffic to these default PITRs via normal transmission methods, 1972 where they are encapsulated and passed on. 1974 13.2. Outdated Mappings 1976 If a mapping changes once an ITR has retrieved it, that may result in 1977 traffic to the EIDs covered by that mapping failing. There are three 1978 cases to consider: 1980 - When the ETR traffic is being sent to is still a valid ETR for 1981 that EID, but the mapping has been updated (e.g. to change the 1982 priority of various ETRs) 1983 - When the ETR traffic is being sent to is still an ETR, but no 1984 longer a valid ETR for that EID 1985 - When the ETR traffic is being sent to is no longer an ETR 1987 13.2.1. Outdated Mappings - Updated Mapping 1989 A 'mapping versioning' system, whereby mappings have version numbers, 1990 and ITRs are notified when their mapping is out of date, has been 1991 added to detect this, and the ITR responds by refreshing the mapping. 1992 [RFC6834] 1994 13.2.2. Outdated Mappings - Wrong ETR 1996 If an ITR is holding an outdated cached mapping, it may send packets 1997 to an ETR which is no longer an ETR for that EID. 1999 It might be argued that if the ETR is properly managing the lifetimes 2000 on its mapping entries, this 'cannot happen', but it is a wise design 2001 methodology to assume that 'cannot happen' events will in fact happen 2002 (as they do, due to software errors, or, on rare occasions, hardware 2003 faults), and ensure that the system will handle them properly (if, 2004 perhaps not in the most expeditious, or 'clean' way - they are, after 2005 all, very unlikely to happen). 2007 ETRs can easily detect cases where this happpens, after they have un- 2008 wrapped a user data packet; in response, they send a Solicit-Map- 2009 Request to the source ITR to cause it to refresh its mapping. 2011 13.2.3. Outdated Mappings - No Longer an ETR 2013 In another case for what can happen if an ITR uses an outdated 2014 mapping, the destination of traffic from an ITR might no longer be a 2015 LISP device at all. In such cases, one might get an ICMP Destination 2016 Unreachable error message. However, one cannot depend on that - and 2017 in any event, that would provide an attack vector, so it should be 2018 used with care. (See [RFC6830], Section 6.3, "Routing Locator 2019 Reachability" for more about this.) 2021 The following mechanism will work, though. Since the destination is 2022 not an ETR, the echoing reachability detection mechanism (see 2023 Section 9.3.2, "Echo Nonces") will detect a problem. At that point, 2024 the backstop mechanism, Probing, will kick in. Since the destination 2025 is still not an ETR, that will fail, too. 2027 At that point, traffic will be switched to a different ETR, or, if 2028 none are available, a reload of the mapping may be initiated. 2030 13.3. Erroneous Mappings 2032 Again, this 'should not happen', but a good system should deal with 2033 it. However, in practise, should this happen, it will produce one of 2034 the prior two cases (the wrong ETR, or something that is not an ETR), 2035 and will be handled as described there. 2037 13.4. Neighbour ETR Liveness 2039 The ITR, like all packet switches, needs to detect, and react, when 2040 its neighbour ceases operation. As LISP traffic is effectively 2041 always uni-directional (from ITR to ETR), this could be somewhat 2042 problematic. 2044 Solving a related problem, neighbour ETR reachability (below) 2045 subsumes handling this fault mode, however. 2047 Note that the two terms - liveness and reachability - are _not_ 2048 synonmous (although they are often confused). Liveness is a property 2049 of a node - it is either up and functioning, or it is not. 2050 Reachability is only a property of a particular _pair_ of nodes. 2052 If packets sent from a first node to a second are successfully 2053 received at the second, it is 'reachable' from the first. However, 2054 the second node may at the very same time _not_ be reachable from 2055 some other node. Reachability is _always_ a ordered pairwise 2056 property, and of a specified ordered pair. 2058 13.5. Neighbour ETR Reachability 2060 A more significant issue than whether a particular ETR E is up or not 2061 is, as mentioned above, that although ETR E may be up, attached to 2062 the network, etc, an issue in the network, between a source ITR I and 2063 E, may prevent traffic from I from getting to E. (Perhaps a routing 2064 problem, or perhaps some sort of access control setting.) 2066 The one-way nature of LISP traffic makes this situation hard to 2067 detect in a way which is economic, robust and fast. Two out of the 2068 three are usually not to hard, but all three at the same time - as is 2069 highly desirable for this particular issue - are harder. 2071 In line with the LISP design philosophy ([Perspective], Section 2072 "Design-Theoretical"), this problem is attacked not with a single 2073 mechanism (which would have a hard time meeting all those three goals 2074 simultaneously), but with a collection of simpler, cheaper 2075 mechanisms, which collectively will usually meet all three. 2077 They are reliance on the underlying routing system (which can of 2078 course only reliably provide a negative reachabilty indication, not a 2079 positive one), the echo nonce (which depends on some return traffic 2080 from the destination xTR back to the source xTR), and finally direct 2081 'pinging', in the case where no positive echo is returned. 2083 (The last is not the first choice, as due to the large fan-out 2084 expected of LISP devices, reliance on it as a sole mechanism would 2085 produce a fair amount of overhead.) 2087 14. Acknowledgments 2089 The author would like to start by thanking all the members of the 2090 core LISP group for their willingness to allow him to add himself to 2091 their effort, and for their enthusiasm for whatever assistance he has 2092 been able to provide. 2094 He would also like to thank (in alphabetical order) Michiel Blokzijl, 2095 Peter Chiappa, Vina Ermagan, Dino Farinacci, Vince Fuller and 2096 Vasileios Lakafosis for their review of, and helpful suggestions for, 2097 this document. (If I have missed anyone in this list, I apologize 2098 most profusely.) 2100 A very special thank you goes to Joel Halpern, who almost invariably, 2101 when asked, promptly returned comments on intermediate versions of 2102 this document. Grateful thanks go also to Darrel Lewis for his help 2103 with material on non-Internet uses of LISP, and to Dino Farinacci and 2104 Vince Fuller for answering detailed questions about some obscure LISP 2105 topics. 2107 A final thanks is due to John Wrocklawski for the author's 2108 organizational affiliation, and to Vince Fuller for help with XML. 2109 This memo was created using the xml2rfc tool. 2111 I would like to dedicate this document to the memory of my parents, 2112 who gave me so much, and whom I can no longer thank in person, as I 2113 would have so much liked to be able to. 2115 15. IANA Considerations 2117 This document makes no request of the IANA. 2119 16. Security Considerations 2121 This memo does not define any protocol and therefore creates no new 2122 security issues. 2124 17. References 2126 17.1. Normative References 2128 [AFI] IANA, "Address Family Indicators (AFIs)", Address 2129 Family Numbers, January 2011, . 2132 [RFC768] J. Postel, "User Datagram Protocol", RFC 768, 2133 August 1980. 2135 [RFC791] J. Postel, "Internet Protocol", RFC 791, 2136 September 1981. 2138 [RFC2460] S. Deering and R. Hinden, "Internet Protocol, 2139 Version 6 (IPv6) Specification", RFC 2460, 2140 December 1998. 2142 [RFC6830] D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, 2143 "The Locator/ID Separation Protocol (LISP)", 2144 RFC 6830, January 2013. 2146 [RFC6831] D. Farinacci, D. Meyer, J. Zwiebel, and S. Venaas, 2147 "The Locator/ID Separation Protocol (LISP) for 2148 Multicast Environments", RFC 6831, January 2013. 2150 [RFC6832] D. Lewis, D. Meyer, D. Farinacci, and V. Fuller, 2151 "Interworking between Locator/ID Separation Protocol 2152 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 2154 [RFC6833] V. Fuller and D. Farinacci, "Locator/ID Separation 2155 Protocol (LISP) Map-Server Interface", RFC 6833, 2156 January 2013. 2158 [RFC6834] L. Iannone, D. Saucez, and O. Bonaventure, 2159 "Locator/ID Separation Protocol (LISP) Map- 2160 Versioning", RFC 6834, January 2013. 2162 [Perspective] J. N. Chiappa, "An Architectural Perspective on the 2163 LISP Location-Identity Separation System", 2164 draft-ietf-lisp-perspective-00 (work in progress), 2165 February 2013. 2167 [Improvements] J. N. Chiappa, "An Overview of On-Going Improvements 2168 to the LISP Location-Identity Separation System", 2169 draft-chiappa-lisp-improvements-00 (work in 2170 progress), September 2013. 2172 [DDT] V. Fuller, D. Lewis, and D. Farinacci, "LISP 2173 Delegated Database Tree", draft-ietf-lisp-ddt-01 2174 (work in progress), March 2013. 2176 [LISP-SEC] F. Maino, V. Ermagan, A. Cabellos-Aparicio, 2177 D. Saucez, and O. Bonaventure, "LISP-Security (LISP- 2178 SEC)", draft-ietf-lisp-sec-04 (work in progress), 2179 October 2012. 2181 [NAT-Traversal] V. Ermagan, D. Farinacci, D. Lewis, J. Skriver, 2182 F. Maino, and C. White, "NAT traversal for LISP", 2183 draft-ermagan-lisp-nat-traversal-03 (work in 2184 progress), March 2013. 2186 [Mobility] D. Farinacci, V. Fuller, D. Lewis, and D. Meyer, 2187 "LISP Mobility Architecture", draft-meyer-lisp-mn-08 2188 (work in progress), April 2012. 2190 [Deployment] L. Jakab, A. Cabellos-Aparicio, F. Coras, 2191 J. Domingo-Pascual, and D. Lewis, "LISP Network 2192 Element Deployment Considerations", 2193 draft-ietf-lisp-deployment-09 (work in progress), 2194 July 2013. 2196 [LISP-TE] D. Farinacci, P. Lahiri, and M. Kowal, "LISP Traffic 2197 Engineering Use-Cases", draft-farinacci-lisp-te-03 2198 (work in progress), July 2013. 2200 17.2. Informative References 2202 [NIC8246] A. McKenzie and J. Postel, "Host-to-Host Protocol 2203 for the ARPANET", NIC 8246, Network Information 2204 Center, SRI International, Menlo Park, CA, 2205 October 1977. 2207 [NSAP] International Organization for Standardization, 2208 "Information Processing Systems - Open Systems 2209 Interconnection - Basic Reference Model", ISO 2210 Standard 7489.1984, 1984. 2212 [IEN19] J. F. Shoch, "Inter-Network Naming, Addressing, and 2213 Routing", IEN (Internet Experiment Note) 19, 2214 January 1978. 2216 [RFC826] D. Plummer, "Ethernet Address Resolution Protocol", 2217 RFC 826, November 1982. 2219 [RFC1034] P. V. Mockapetris, "Domain Names - Concepts and 2220 Facilities", RFC 1034, November 1987. 2222 [RFC1498] J. H. Saltzer, "On the Naming and Binding of Network 2223 Destinations", RFC 1498, (Originally published in: 2224 'Local Computer Networks', edited by P. Ravasio et 2225 al., North-Holland Publishing Company, Amsterdam, 2226 1982, pp. 311-317.), August 1993. 2228 [RFC1631] K. Egevang and P. Francis, "The IP Network Address 2229 Translator (NAT)", RFC 1631, May 1994. 2231 [RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, 2232 G. J. de Groot, and E. Lear, "Address Allocation for 2233 Private Internets", RFC 1918, February 1996. 2235 [RFC1992] I. Castineyra, J. N. Chiappa, and M. Steenstrup, 2236 "The Nimrod Routing Architecture", RFC 1992, 2237 August 1996. 2239 [RFC3168] K. Ramakrishnan, S. Floyd, and D. Black, "The 2240 Addition of Explicit Congestion Notification (ECN) 2241 to IP", RFC 3168, September 2001. 2243 [RFC3170] B. Quinn and K. Almeroth, "IP Multicast 2244 Applications: Challenges and Solutions", RFC 3170, 2245 September 2001. 2247 [RFC3272] D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, and 2248 X. Xiao, "Overview and Principles of Internet 2249 Traffic Engineering", RFC 3272, May 2002. 2251 [RFC4026] L. Andersson and T. Madsen, "Provider Provisioned 2252 Virtual Private Network (VPN) Terminology", 2253 RFC 4026, March 2005. 2255 [RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, and 2256 S. Rose, "DNS Security Introduction and 2257 Requirements", RFC 4033, March 2005. 2259 [RFC4107] S. Bellovin and R. Housley, "Guidelines for 2260 Cryptographic Key Management", RFC 4107, June 2005. 2262 [RFC4116] J. Abley, K. Lindqvist, E. Davies, B. Black, and 2263 V. Gill, "IPv4 Multihoming Practices and 2264 Limitations", RFC 4116, July 2005. 2266 [RFC4786] J. Abley and K. Lindqvist, "Operation of Anycast 2267 Services", RFC 4786, December 2006. 2269 [RFC4984] D. Meyer, L. Zhang, and K. Fall, "Report from the 2270 IAB Workshop on Routing and Addressing", RFC 4984, 2271 September 2007. 2273 [RFC5110] P. Savola, "Overview of the Internet Multicast 2274 Routing Architecture", RFC 5110, January 2008. 2276 [RFC5887] B. Carpenter, R. Atkinson, and H. Flinck, 2277 "Renumbering Still Needs Work", RFC 5887, May 2010. 2279 [RFC6115] T. Li, Ed., "Recommendation for a Routing 2280 Architecture", RFC 6115, February 2011. 2282 (Perhaps the most ill-named RFC of all time; it 2283 contains nothing that could truly be called a 2284 'routing architecture'.) 2286 [ALT] V. Fuller, D. Farinacci, D. Meyer, and D. Lewis, 2287 "Locator/ID Separation Protocol Alternative Logical 2288 Topology (LISP+ALT)", RFC 6836, January 2013. 2290 [LISP0] D. Farinacci, V. Fuller, and D. Oran, "Locator/ID 2291 Separation Protocol (LISP)", draft-farinacci-lisp-00 2292 (work in progress), January 2007. 2294 [Future] J. N. Chiappa, "Potential Long-Term Developments 2295 With the LISP System", 2296 draft-chiappa-lisp-evolution-00 (work in progress), 2297 October 2012. 2299 [Baran] P. Baran, "On Distributed Communications Networks", 2300 IEEE Transactions on Communications Systems Vol. 2301 CS-12 No. 1, pp. 1-9, March 1964. 2303 [Chiappa] J. N. Chiappa, "Endpoints and Endpoint Names: A 2304 Proposed Enhancement to the Internet Architecture", 2305 Personal draft (work in progress), 1999, 2306 . 2308 [Clark] D. D. Clark, "The Design Philosophy of the DARPA 2309 Internet Protocols", in 'Proceedings of the 2310 Symposium on Communications Architectures and 2311 Protocols SIGCOMM '88', pp. 106-114, 1988. 2313 [Saltzer] J. H. Saltzer, D. P. Reed, and D. D. Clark, "End-To- 2314 End Arguments in System Design", ACM TOCS, Vol 2, 2315 No. 4, pp 277-288, November 1984. 2317 [Heart] F. E. Heart, R. E. Kahn, S. M. Ornstein, 2318 W. R. Crowther, and D. C. Walden, "The Interface 2319 Message Processor for the ARPA Computer Network", 2320 Proceedings AFIPS 1970 SJCC, Vol. 36, pp. 551-567. 2322 [Iannone] L. Iannone and O. Bonaventure, "On the Cost of 2323 Caching Locator/ID Mappings", in 'Proceedings of the 2324 3rd International Conference on emerging Networking 2325 EXperiments and Technologies (CoNEXT'07)', ACM, pp. 2326 1-12, December 2007. 2328 [Kim] J. Kim, L. Iannone, and A. Feldmann, "A Deep Dive 2329 Into the LISP Cache and What ISPs Should Know About 2330 It", in 'Proceedings of the 10th International IFIP 2331 TC 6 Conference on Networking - Volume Part I 2332 (NETWORKING '11)', IFIP, pp. 367-378, May 2011. 2334 [CorasCache] F. Coras, A. Cabellos-Aparicio, and J. Domingo- 2335 Pascual, "An Analytical Model for the LISP Cache 2336 Size", in 'Proceedings of the 11th International 2337 IFIP TC 6 Networking Conference: Part I', IFIP, pp. 2338 409-420, May 2012. 2340 [Jakab] L. Jakab, A. Cabellos-Aparicio, F. Coras, D. Saucez, 2341 and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to 2342 Support the LISP Mapping System", in 'IEEE Journal 2343 on Selected Areas in Communications', Vol. 28, No. 2344 8, pp. 1332-1343, October 2010. 2346 [Saucez] D. Saucez, L. Iannone, and B. Donnet, "A First 2347 Measurement Look at the Deployment and Evolution of 2348 the Locator/ID Separation Protocol", in 'ACM SIGCOMM 2349 Computer Communication Review', Vol. 43 No. 2, pp. 2350 37-43, April 2013. 2352 [CorasBGP] F. Coras, D. Saucez, L. Jakab, A. Cabellos-Aparicio, 2353 and J. Domingo-Pascual, "Implementing a BGP-free ISP 2354 Core with LISP", in 'Proceedings of the Global 2355 Communications Conference (GlobeCom)', IEEE, pp. 2356 2772-2778, December 2012. 2358 [Atkinson] R. Atkinson, "Revised draft proposed definitions", 2359 RRG list message, Message-Id: 808E6500-97B4-4107- 2360 8A2F-36BC913BE196@extremenetworks.com, 11 June 2007, 2361 . 2364 [Bibliography] J. N. Chiappa (editor), "LISP (Location/Identity 2365 Separation Protocol) Bibliography", Personal 2366 site (work in progress), July 2013, . 2369 Appendix A. Glossary/Definition of Terms 2371 For those who are unfamiliar with the scholarly notation 'q.v.', it 2372 stands for 'quod vide', which is Latin for 'which see' (literally); 2373 in other words, that term also is defined here. 2375 - Name: In this document, and in much of computer science, a 'name' 2376 simply refers to an identifier for an object or entity. Names 2377 have both semantics (meaning) and syntax (form).[RFC1498] 2378 - Namespace: A group of names (q.v.) with matching semantics and 2379 syntax; they usually, but not always, refer to members of a class 2380 of identical objects. 2381 - Node: The general term used to describe any sort of communicating 2382 entity; it might be a physical or a virtual host, or a mobile 2383 device of some sort. It was deliberately chosen for use in this 2384 document precisely because its definition is not fixed, and 2385 therefore unlikely to cause erroneous images in the minds of 2386 readers. You will not go far wrong if you think of a node as 2387 being something like a host. 2388 - Switch: A packet switch, in the general meaning of that term. 2389 - Endpoint, end-end communication entity: the fate-sharing region at 2390 one end of an end-end communication; the collection of state 2391 related to both the reliable end-end communication channel, and 2392 the applications running there. 2393 - IPvN: IPv4 or IPv6; the two are so similar, in fundamental 2394 architecture, that in much discussion about their capabilities, 2395 limitations, etc statements about the apply equally to both, and 2396 to continually say "IPv4 and IPv6" quickly becomes tedious. 2397 - Address: In this document, and in current IPvN and similar 2398 networking suites, a 'name' (q.v.) which has mixed semantics, in 2399 that it includes both identity ('who') and location ('where') 2400 semantics. 2401 - Identifier: Here, and in current networking discussions, a 'name' 2402 (q.v.) which has purely identity semantics. 2403 - Locator: Originally defined as a 'name' with location semantics 2404 only, and one that was not necessarily carried in every packet (as 2405 was assumed of 'addresses') [RFC1992], it is now generally taken, 2406 including here, to mean a 'name' with purely location semantics. 2408 - EID, Enpoint Identifier: Originally defined as a name for an 2409 'endpoint' (see the reference), one with purely identity 2410 semantics, and globally unique, and with syntax of relatively 2411 short fixed length [Chiappa]. It is used in the LISP work to mean 2412 the 'identifier' (q.v.) of a node; it is the input to an EID->RLOC 2413 lookup in the 'mapping system' (q.v.); it is usually an IPvN 2414 address. The source and adestination addresses of the innermost 2415 header in a LISP packet are usually EIDs. 2416 - RLOC, Routing Locator: a LISP-specific term meaning the locator of 2417 an entity identified by an EID; as such, it is often the output of 2418 an EID->RLOC lookup in the 'mapping system' (q.v.); it is usually 2419 an IPvN address, and of an ETR. The source and adestination 2420 addresses of the outermost header in a LISP packet are usually 2421 RLOCs. 2422 - ITR, Ingress Tunnel Router: a LISP node at the border of a LISP 2423 site (q.v.) which takes user packets sent to it from inside the 2424 LISP site, encapsulates in a LISP header, and then sends them 2425 across the Internet to an ETR (q.v.); in other words, the start of 2426 a 'tunnel' from the ITR to an ETR. 2427 - ETR: Egress Tunnel Router: a LISP node at the border of a LISP 2428 site (q.v.) which decapsulates user packets which arrive at it 2429 encapsulated in a LISP header, and sends them on towards their 2430 ultimate destination; in other words, the end of the 'tunnel' from 2431 an ITR (q.v.) to the ETR. 2432 - Neighbour ETR: Although an ITR and ETR may be separated by many 2433 actual physical hops, _at the LISP level_, they are direct 2434 neighbours; so any ETR which an ITR sends traffic to is a 2435 'neighbour ETR' of that ITR. 2436 - xTR: An xTR refers to a device which functions both as an ITR and 2437 an ETR (which is typical), when the discussion involves packet 2438 flows in both directions through the device, which results in it 2439 alternately functioning as an ITR and then as an ETR. 2440 - Site: a collection of hosts, routers and networks under a single 2441 administrative control. 2442 - LISP site: A single node, or a set of network elements in an edge 2443 network under the administrative control of a single organization; 2444 they are delimited from the rest of the network by LISP devices 2445 (either separate ITRs and ETRs, or xTRs). 2446 - Reachability, Neighbour ETR Reachability: The ability of an ITR to 2447 be able to send packets to a neighbour ETR (q.v.), or the property 2448 of an ITR to be able to send such packets. 2449 - MR: Map Resolver; a LISP device to which ITRs send requests for 2450 mappings. See Section 6.2.2, "Interface to the Mapping System", 2451 for more. 2452 - MS: Map Server; a LISP device with which ETRs register mappings, 2453 to indicate their availability to handle incoming traffic to the 2454 EIDs covered in those mappings. See Section 6.2.2, "Interface to 2455 the Mapping System" for more. 2457 - Mapping system: the entire ensemble of data and mechanisms which 2458 allow clients - usually ITRs - to find mapppings (from EIDs to 2459 RLOCs). It includes both the mapping database (q.v), and also 2460 everything used to gain access to it - the MRs, the indexing sub- 2461 system (q.v.), etc. See Section 6.2.1, "Mapping System 2462 Organization" for more. 2463 - Mapping database: the term "mapping database" refers to the entire 2464 collection of {EID->RLOC} mappings spread throughout the LISP 2465 system. It is a subset of the 'mapping system' (q.v.). See 2466 Section 6.2, "The Mapping System", for more. 2467 - Indexing sub-system: the entire ensemble of data and mechanisms 2468 which allows MRs to find out which ETR(s) hold the mappping for a 2469 given EID or EID block. It includes both the data on namespace 2470 delegations, as well as the devices which hold that data, and the 2471 protocols used to interact with those devices. See Section 6.2.1, 2472 "Mapping System Organization" for more. 2473 - DDT node: a node in the (abstract) namespace delegation hierarchy. 2474 - DDT server: an actual machine, which one can send packets to, in 2475 the DDT hierarchy - which is, hopefully, a one-to-one projection 2476 of address delegation hierarchy (although of course a single DDT 2477 node may turn into several sibling servers). 2478 - PITR: Proxy ITR; an ITR which is used for interworking between a 2479 LISP-speaking node or site, and legacy nodes or sites; in general, 2480 it acts like a normal ITR, but does so on behalf of LISP devices 2481 which are receiving packets to a legacy device. See 2482 Section 12.2.1.1, "PITRs", for more. 2483 - PETR: Proxy ETR; an ETR which is used for interworking between a 2484 LISP-speaking node or site, and legacy nodes or sites; in general, 2485 it acts like a normal ETR, but does so on behalf of LISP devices 2486 which are sending packets to a legacy device. See 2487 Section 12.2.1.2, "PETRs" for more. 2488 - RTR: Re-encapsulating Tunnel Router; a data plane 'anchor point' 2489 used by a LISP-speaking device to perform functions that can only 2490 be be performed in the core of the network. One use is for LISP- 2491 speaking device behind a NAT device to send and receive traffic 2492 through the NAT device; see [Improvements], Section "Improved NAT 2493 Support" for more. 2494 - DFZ, Default Free Zone: That part of the Internet in which there 2495 are no 'default' entries in routing tables, but where the routing 2496 tables hold entries for every single reachable destination in the 2497 Internet. 2499 Appendix B. Other Appendices 2501 B.1. A Brief History of Location/Identity Separation 2503 It was only gradually realized in the networking community that 2504 networks (especially large networks) should deal quite separately 2505 with the identity and location of a node; the distinction between the 2506 two was more than a little hazy at first. 2508 The ARPANET had no real acknowledgment of the difference between the 2509 two. [Heart] [NIC8246] The early Internet also co-mingled the two 2510 ([RFC791]), although there was recognition in the early Internet work 2511 that there were two different things going on. [IEN19] 2513 This likely resulted not just from lack of insight, but also the fact 2514 that extra mechanism is needed to support this separation (and in the 2515 early days there were no resources to spare), as well as the lack of 2516 need for it in the smaller networks of the time. (It is a truism of 2517 system design that small systems can get away with doing two things 2518 with one mechanism, in a way that usually will not work when the 2519 system gets much larger.) 2521 The ISO protocol architecture took steps in this direction [NSAP], 2522 but to the Internet community the necessity of a clear separation was 2523 definitively shown by Saltzer. [RFC1498] Later work expanded on 2524 Saltzer's, and tied his separation concepts into the fate-sharing 2525 concepts of Clark. [Clark], [Chiappa] 2527 The separation of location and identity is a step which has recently 2528 been identified by the IRTF as a critically necessary evolutionary 2529 architectural step for the Internet. [RFC6115] However, it has taken 2530 quite some time for this requirement to be generally accepted by the 2531 Internet engineering community at large, although it seems that this 2532 may finally be happening. 2534 Unfortunately, although the development of IPv6 presented a golden 2535 opportunity to learn from this particular failing of IPv4, that 2536 design failed to recognize the need for separation of location and 2537 identity. 2539 B.2. A Brief History of the LISP Project 2541 The LISP system for separation of location and identity resulted from 2542 the discussions of this topic at the Amsterdam IAB Routing and 2543 Addressing Workshop, which took place in October 2006. [RFC4984] 2545 A small group of like-minded personnel from various scattered 2546 locations within Cisco, spontaneously formed immediately after that 2547 workshop, to work on an idea that came out of informal discussions at 2548 the workshop. The first Internet-Draft on LISP appeared in January, 2549 2007, along with a LISP mailing list at the IETF. [LISP0] 2551 Trial implementations started at that time, with initial trial 2552 deployments underway since June 2007; the results of early experience 2553 have been fed back into the design in a continuous, ongoing process 2554 over several years. LISP at this point represents a moderately 2555 mature system, having undergone a long organic series of changes and 2556 updates. 2558 LISP transitioned from an IRTF activity to an IETF WG in March 2009, 2559 and after numerous revisions, the basic specifications moved to 2560 becoming RFCs at the start of 2013 (although work to expand and 2561 improve it, and find new uses for it, continues, and undoubtly will 2562 for a long time to come). 2564 B.3. Old LISP 'Models' 2566 LISP, as initilly conceived, had a number of potential operating 2567 modes, named 'models'. Although they are now obsolete, one 2568 occasionally sees mention of them, so they are briefly described 2569 here. 2571 - LISP 1: EIDs all appear in the normal routing and forwarding 2572 tables of the network (i.e. they are 'routable');this property is 2573 used to 'bootstrap' operation, by using this to load EID->RLOC 2574 mappings. Packets were sent with the EID as the destination in 2575 the outer wrapper; when an ETR saw such a packet, it would send a 2576 Map-Reply to the source ITR, giving the full mapping. 2577 - LISP 1.5: Similar to LISP 1, but the routability of EIDs happens 2578 on a separate network. 2579 - LISP 2: EIDs are not routable; EID->RLOC mappings are available 2580 from the DNS. 2581 - LISP 3: EIDs are not routable; and have to be looked up in in a 2582 new EID->RLOC mapping database (in the initial concept, a system 2583 using Distributed Hash Tables). Two variants were possible: a 2584 'push' system, in which all mappings were distributed to all ITRs, 2585 and a 'pull' system in which ITRs load the mappings they need, as 2586 needed. 2588 B.4. The ALT Mapping Indexing Sub-system 2590 LISP initially used an indexing sub-system called ALT. [ALT] ALT re- 2591 purposed a number of existing mechanisms to provide an indexing 2592 system, which allowed an experimental LISP initial deployment to 2593 become operational without having to write a lot of code, ALT was 2594 relatively easily constructed from basically unmodified existing 2595 mechanisms; it used BGP running over virtual tunnels using GRE. 2597 ALT proved to have a number of issues which made it unsuitable for 2598 large-scale use, and it has now been superseded by DDT. A complete 2599 list of these is not possible here, but the issues mostly were of two 2600 kinds: technical issues which would have arisen at large scale, and 2601 practical operational issues which appeared even in the experimental 2602 deployment. 2604 The biggest operational issues was the effort involved in 2605 configuring, and maintain the configuration, of the virtual tunnels 2606 over which ALT ran (including assigning the addresses for the ends, 2607 etc); also, managing the multiple disjoint routing tables required 2608 was difficult and confusing (even for those who were very familiar 2609 with ALT). Debugging faults in ALT was also difficult; and finally, 2610 because of ALT's nature, administrative issues (who pays for what, 2611 who controls what, etc) were problematic. 2613 However, ALT would have had significant technical issues had it been 2614 used at a larger scale. 2616 The most severe (and fundamental) issue was that since all traffic on 2617 the ALT had to transit the 'root' of the ALT tree, those locations 2618 would have become traffic 'hot-spots' in a large scale deployment. 2619 In addition, optimal performance would have required that the ALT 2620 overall topology be restrained to follow the EID namespace 2621 allocation; however, it was not clear that this was feasible. In any 2622 event, even optimal performance was still less than that in 2623 alternatives. The ALT was also very vulnerable to misconfiguration. 2625 See [Jakab] for more about these issues: the basic structure and 2626 operation of DDT is identical to that of TREE, so the conclusions 2627 drawn there about TREE's superiority to ALT apply equally to DDT. 2629 The ALT did have some useful properties which its replacement, DDT, 2630 did not, e.g. the ability to forward data directly to the 2631 destination, over the ALT, when no mapping was available yet for the 2632 destination. However, these were minor, and heavily outweighed by 2633 its problems. 2635 A recent study, [Saucez], measured actual resolution times in the 2636 deployed LISP network during the changeover from ALT to DDT, allowing 2637 direct comparison of the performance of the two systems. The study 2638 took measurements from a variety of locations in the Internet, with 2639 respect to a number of different target EIDs. The results indicate 2640 that the performance was almost identical; there was more variance 2641 with DDT (perhaps due to the effects of caching), but the greatly 2642 improved scalability of DDT as compared to ALT made that effect 2643 acceptable. 2645 B.5. Early NAT Support 2647 The first mechanism used by LISP to support operation through a NAT 2648 device, described here, has now been superseded by the more general 2649 mechanism proposed in [NAT-Traversal]. That mechanism is, however, 2650 based heavily on this mechanism. The initial mechanism had some 2651 serious limitations, which is why that particular form of it has been 2652 dropped. 2654 First, it only worked with some NATs, those which were configurable 2655 to allow inbound packet traffic to reach a configured host. The NAT 2656 had to be configured to know of the ETR. 2658 Second, since NATs share addresses by using ports, it was only 2659 possible to have a single LISP device behind any given NAT device. 2660 That is because LISP expects all incoming data traffic to be on a 2661 specific port, so it was not possible to have multiple ETRs behind a 2662 single NAT (which normally would have only one global IP address to 2663 share). Even looking at the sort host and port would not necessarily 2664 help, because some source ITR could be sending packets to both ETRs, 2665 so packets to either ETR could also have the identical source host/ 2666 port. In short, there was no way for a NAT with multiple ETRs behind 2667 it to know which ETR the packet was for. 2669 To support operation behind a NAT, there was a pair of new LISP 2670 control messages, LISP Echo-Request and Echo-Reply, which allowed the 2671 ETR to discover its temporary global address. The Echo-Request was 2672 sent to the configured Map-Server, and it replied with an Echo-Reply 2673 which included the source address from which the Echo Request was 2674 received (i.e. the public global address assigned to the ETR by the 2675 NAT). The ETR could then insert that address in any Map-Reply 2676 control messages which it sent to correspondent ITRs. 2678 Echo-Request and Echo-Reply have been replaced by Info-Request and 2679 Info-Reply in the replacement, [NAT-Traversal], where they perform 2680 very similar functions; the main change is the addition of the {{xxx 2681 - probably the port, etc to allow multiple XTRs behind a NAT}}. 2683 Author's Address 2685 J. Noel Chiappa 2686 Yorktown Museum of Asian Art 2687 Yorktown, Virginia 2688 USA 2690 EMail: jnc@mit.edu