idnits 2.17.1 draft-ietf-lisp-perspective-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1241 lines 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 (February 18, 2013) is 4083 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-fuller-lisp-ddt-01 -- No information found for draft-chiappa-lisp-evolution - is the name correct? == Outdated reference: A later version (-01) exists of draft-chiappa-lisp-introduction-00 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-02 -- Obsolete informational reference (is this intentional?): RFC 1631 (Obsoleted by RFC 3022) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) == Outdated reference: A later version (-06) exists of draft-irtf-rrg-ilnp-arch-05 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 4 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 February 18, 2013 5 Expires: August 22, 2013 7 An Architectural Perspective on the LISP 8 Location-Identity Separation System 9 draft-ietf-lisp-perspective-00 11 Abstract 13 LISP upgrades the architecture of the IPvN internetworking system by 14 separating location and identity, current intermingled in IPvN 15 addresses. This is a change which has been identified by the IRTF as 16 a critically necessary evolutionary architectural step for the 17 Internet. In LISP, nodes have both a 'locator' (a name which says 18 _where_ in the network's connectivity structure the node is) and an 19 'identifier' (a name which serves only to provide a persistent handle 20 for the node). A node may have more than one locator, or its locator 21 may change over time (e.g. if the node is mobile), but it keeps the 22 same identifier. 24 This document gives additional architectural insight into LISP, and 25 considers a number of aspects of LISP from a high-level standpoint. 27 [NOTE: This is still a somewhat rough draft version; a few sections 28 at the end are just rough frameworks, but almost all the key 29 sections, and all the front part of the document, are here, and in 30 something like reasonably complete form.] 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. This document may not be modified, 36 and derivative works of it may not be created, except to format it 37 for publication as an RFC or to translate it into languages other 38 than English. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 This Internet-Draft will expire on August 22, 2013. 52 Copyright Notice 54 Copyright (c) 2013 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction 70 2. Goals of LISP 71 2.1. Reduce DFZ Routing Table Size 72 2.2. Deployment of New Namespaces 73 2.3. Future Development of LISP 74 3. Architectual Perspectives 75 3.1. Another Packet-Switching Layer 76 3.2. 'Double-Ended' Approach 77 4. Architectual Aspects 78 4.1. Critical State 79 4.2. Need for a Mapping System 80 4.3. Piggybacking of Control on User Data 81 5. Namespaces 82 5.1. LISP EIDs 83 5.1.1. Residual Location Functionality in EIDs 84 5.2. RLOCs 85 5.3. Overlapping Uses of Existing Namespaces 86 5.4. LCAFs 87 6. Scalability 88 6.1. Demand Loading of Mappings 89 6.2. Caching of Mappings 90 6.3. Amount of State 91 6.4. Scalability of The Indexing Subsystem 92 7. Security 93 7.1. Basic Philosophy 94 7.2. Design Guidance 95 7.2.1. Security Mechanism Complexity 96 7.3. Security Overview 97 7.3.1. Securing Lookups 98 7.3.2. Securing The Indexing Subsystem 99 7.3.3. Securing Mappings 100 7.4. Securing the xTRs 101 8. Robustness 102 9. Fault Discovery/Handling 103 10. Optimization 104 11. Open Issues 105 11.1. Local Open Issues 106 11.1.1. Missing Mapping Packet Queueing 107 11.1.2. Mapping Cache Management Algorithm 108 11.2. Systemic Open Issues 109 11.2.1. Mapping Database Provider Lock-in 110 11.2.2. Automated ETR Synchronization 111 11.2.3. EID Reachability 112 11.2.4. Detect and Avoid Broken ETRs 113 12. Acknowledgments 114 13. IANA Considerations 115 14. Security Considerations 116 15. References 117 15.1. Normative References 118 15.2. Informative References 119 Appendix A. Glossary/Definition of Terms 120 Appendix B. Other Appendices 122 1. Introduction 124 [[I0: Things inside '[[]]' are editorial comments. For now they show 125 up - when we go to produce the ID, I will make them invisible.]] 127 This document begins by introducing some high-level architectural 128 perspectives which have proven useful for thinking about the LISP 129 location-identity separation system. It then discusses some 130 architectural aspects of LISP (e.g. its namespaces). The balance 131 (and bulk) of the document contains architectural analysis of the 132 LISP system; that is, it reviews from a high-level standpoint various 133 aspects of that system; e.g. its scalability, security, robustness, 134 etc. 136 NOTE: This document assumes a fair degree of familiarity with LISP; 137 in particular, the reader should have a good 'high-level' 138 understanding of the overall LISP system architecture, such as is 139 provided by [Introduction], "An Introduction to the LISP System". 141 By "system architecture" above, the restricted meaning used there is: 142 'How the system is broken up into subsystems, and how those 143 subsystems interact; when does information flows from one to another, 144 and what that information is.' There is obviously somewhat more to 145 architecture (e.g. the namespaces of a system, in particular their 146 syntax and semantics), and that remaining architectural content is 147 covered here. 149 [[I1: import text from DPLSCS doc for 'name', 'object', 'namespace', 150 etc - or just refer to it?]] 152 2. Goals of LISP 154 As previously stated in the abstract, broadly, the goal of LISP is to 155 be a practically deployable architectural upgrade to IPvN which 156 performs separation of location and identity. But what is the value 157 of that? What will it allow us to do? 159 The answer to that obviously starts with the things mentioned in the 160 "Initial Applications" section of [Introduction], but there are 161 other, longer-range (and broader) goals as well. 163 2.1. Reduce DFZ Routing Table Size 165 One of the main design drivers for LISP, as well as other location- 166 identity separation proposals, is to decrease the overhead of running 167 global routing system. In fact, it was this aspect that led the IRTF 168 Routing RG to conclude that separation of location and identity was a 169 key architectural underpinning needed to control the growth of the 170 global routing system. [RFC6115] 172 As noted in [Introduction], many of the practical needs of Internet 173 users are today met with techniques that increase the load on the 174 global routing system (Provider Independent addresses for the 175 provision of provider independence, multihoming, etc; more-specific 176 routes for TE; etc.) Provision of these capabilities by a mechanism 177 which does not involve extra load on the global routing system is 178 therefore very desirable. 180 A number of factors, including the use of these techniques, has led 181 to a great increase in the fragmentation of the address space, at 182 least in terms of routing table entries. In particular, the growth 183 in demand for multi-homing has been forseen as driving a large 184 increase in the size of the global routing tables. 186 In addition, as the IPv4 address space becomes fuller and fuller, 187 there will be an inevitable tendency to find use in smaller and 188 smaller 'chunks' of that space. [RFC6127] This too would tend to 189 increase the size of the global routing table. 191 LISP, if successful and widely deployed, offers an opportunity to use 192 separation of location and identity to control the growth of the size 193 of the global routing table. (A full examination of this topic is 194 beyond the scope of this document - see {{find reference}}.) 196 2.2. Deployment of New Namespaces 198 Once the mapping system is widely deployed and available, it should 199 make deployment of new namespaces (in the sense of new syntax, if not 200 new semantics) easier. E.g. if someone wishes in the future to 201 devise a system which uses native MPLS [RFC3031] for a data carriage 202 system joining together a large number of xTRs, it would easy enough 203 to arrange to have the mappings for destinations attached to those 204 xTRs abe some sort of MPLS-specific name. 206 More broadly, the existence of a binding layer, with support for 207 multiple namespace built into the interface on both sides (see 208 Section 5) is a tremendously powerful evolutionary tool; one can 209 introduce a new namespace (on one side) more easily, if it is mapped 210 to something which is already deployed (on the other). Then, having 211 taken that step, one can invert the process, and deploy yet another 212 new namespace, but this time on the other. 214 [[G0: Say more about this?]] 216 2.3. Future Development of LISP 218 Speculation about long-term future developments which are enabled by 219 the deployment of LISP is not really proper for this document. 220 However, interested readers may wish to consult [Future] for one 221 person's thoughts on this topic. 223 [[G1: What else?]] 225 3. Architectual Perspectives 227 This section contains some high-level architectural perspectives 228 which have proven useful in a number of ways for thinking about LISP. 229 For one, when trying to think of LISP as a complete system, they 230 provide a conceptual structure which can aid analysis of LISP. For 231 another, they can allow the application of past analysis of, and 232 experience with, similar designs. 234 3.1. Another Packet-Switching Layer 236 When considering the overall structure of the LISP system at a high 237 level, it has proven most useful to think of it as another packet- 238 switching layer, run on top of the original internet layer - much as 239 the Internet first ran on top of the ARPANET. 241 All the functions that a normal packet switch has to undertake - such 242 as ensuring that it can reach its neighbours, and they they are still 243 up - the devices that make up the LISP overlay also have to do, along 244 the 'tunnels' which connect them to other LISP devices. 246 There is, however, one big difference: the fanout of a typical LISP 247 ITR will be much larger than most classic physical packet switches. 248 (ITRs only need to be considered, as the LISP tunnels are all 249 effectively unidirectional, from ITR to ETR - an ETR needs to keep no 250 per-tunnel state, etc.) [[A0: Is that true? Well, the echo nonce is 251 an exception, I guess - but that really only applies to xTRs, not 252 'pure' ETRs. And what about fragmented packets which are fragmented 253 on the ITR-ETR stretch?]] 255 LISP is, fundamentally, a 'tunnel' based system. Tunnel system 256 designs do have their issues (e.g. the high inter-'switch' fan-out), 257 but it's important to realize that they also can have advantages, 258 some of which are listed below. [[A1: Where the balance lies between 259 the two (with the advantages and disadvantages), only time will truly 260 tell. - Add, or leave out?]] 262 3.2. 'Double-Ended' Approach 264 LISP may be thought of as a 'double-ended' approach to enhancing the 265 architecture, in that it uses pairs of devices, one at each end of a 266 communication stream. In particular, to interact with the population 267 of 'legacy' hosts (which will be, inevitably, the vast majority, in 268 the early stages of deployment) it requires a LISP device at both 269 ends of the 'tunnel'. 271 This is in distinction to, say, NAT systems ([RFC1631]), which only 272 need a device deployed at one end: the host at the other end doesn't 273 need a matching device at its end to massage the packets, but can 274 simply consume them on its own, as any packets it receives are fully 275 normal packets. This allows any site which deploys such a 'single- 276 ended' device to get the full benefit, whilst acting entirely on its 277 own. [Wasserman] 279 The issue is not that LISP uses tunnels. Designs like HIP 280 ([RFC4423]) and ILNP ([ILNP]), which do not involve tunnels, inhabit 281 a similar space to tunnel-based designs like LISP, in that unless 282 both ends are upgraded - or there is a proxy at the un-upgraded end - 283 one doen't get any benefits. So it's really not the tunnel which is 284 the key aspect, it's the 'all at one end' part which is key. Whether 285 the system is tunnel, versus non-tunnel, is not that important. 286 [[A2: Maybe unnecessary diversion, ditch?]] 288 However, the double-ended approach of LISP does have advantages, as 289 well as costs. To put it simply, the 'feature' of the alternative 290 approach, that there's only a box at one end, has a 'bug': there's 291 only a box at one end. There are things which such a design cannot 292 accomplish, because of that. 294 To put it another way, does the fact that the packet thus necessarily 295 has only a single 'name' in it for the entities at each end (i.e. the 296 IPvN source and destination addresses), because it is a 'normal' 297 packet, present a limitation? Put that way, it would seem natural 298 that it should cause certain limits. 300 To compile a complete list of the things that can be done, when two 301 separate 'names' are in the packet, is beyond the scope of this 302 document. However, one example of the kind of thing that can be done 303 is mobility with open connections, without needing to 'triangle 304 route' the packets through some sort of 'base station' at the 305 original location. Another is that is possible to automatically 306 tunnel IPv6 traffic over IPv4 infrastructure, or vice versa, 307 invisibly to the hosts on both ends. 309 In the longer term, having having tunnel boxes will allow (and is 310 allowing) us to explore other kinds of wrappings. For example, we 311 can transport 'raw' local-network packets (such as Ethernet MAC 312 frames) across an IPvN infrastructure. 314 [[A3: Is this really true? It's slightly bizarre, it means that you 315 have to feed MAC addresses into the EID->RLOC mapping system, etc. 316 Joel wrote "many folks who are looking for this document will find 317 the idea of outer-headers being non-IP to be counter-productive. 318 Instead, can we turn the last paragraph ... around, and observe that 319 the use of tunnel technologies allows us to wrap up non-IP packets 320 using Identifiers (such as Ethernet MAC addresses) and deliver them 321 over an IP infrastructure?" To me, doing this is even more counter- 322 intuitive than my original example (next)!]] 324 One could also wrap packets in non-IPvN formats: perhaps to take 325 direct advantage of the capabilities of underlying switching fabrics 326 (e.g. MPLS [RFC3031]); perhaps to deploy new carriage protocols, 327 etc, where non-standard packet formats will allow extended semantics. 329 4. Architectual Aspects 331 LISP does take some novel architectural approaches in a number of 332 ways: e.g. its use of a separate mapping system, etc, etc. This 333 section contains some commentary on some of the high-level 334 architectural aspects of LISP. 336 4.1. Critical State 338 LISP does have 'critical state' in the network (i.e. state which, if 339 if lost, causes the communication to fail). However, because LISP is 340 designed as an overall system, 'designing it in' allows for a 341 'systems' approach to its state issues. In LISP, this state has been 342 designed to be maintained in an 'architected' way, so it does not 343 produce systemic brittleness in the way that the state in NATs does. 345 For instance, throughout the system, provisions have been made to 346 have redundant copies of state, in multiple devices, so that the loss 347 of any one device does not necessarily cause a failure of an ongoing 348 connection. 350 [[A4: Say more about this?]] 352 4.2. Need for a Mapping System 354 LISP does need to have a mapping system, which brings design, 355 implementation, configuration and operational costs. Surely all 356 these costs are a bad thing? However, having a mapping system have 357 advantages, especially when there is a mapping layer which has global 358 visibility (i.e. other entities know that it is there, and have an 359 interface designed to be able to interact with it). This is unlike, 360 say, the mappings in NAT, which are 'invisible' to the rest of the 361 network. 363 In fact, one could argue that the mapping layer is LISP's greatest 364 strength. Wheeler's Axiom* ('Any problem in computer science can be 365 solved with another level of indirection') indicates that the binding 366 layer available with the LISP mapping system will be of great value. 367 Again, it is not the job of this document to list them all - and in 368 any event, there is no way to forsee them all. 370 The author of this document has often opined that the hallmark of 371 great architecture is not how well it does the things it was designed 372 to do, but how well it does things it was never expected to have to 373 handle. Providing such a powerful and generic binding layer is one 374 sure way to achieve the sort of lasting flexibility and power that 375 leads to that outcome. 377 [Footnote *: This Axiom is often mis-attributed to Butler Lampson, 378 but Lampson himself indicated that it came from David Wheeler.] 380 4.3. Piggybacking of Control on User Data 382 LISP piggybacks control transactions on top of user data packets. 383 This is a technique that has a long history in data networking, going 384 back to the early ARPANET. [McQuillan] It is now apparently regarded 385 as a somewhat dubious technique, the feeling seemingly being that 386 control and user data should be strictly segregated. 388 [[A5: Can anyone explain to my _why_ it's so horrible? Yeah, I get 389 that it's probably _better_ to segregate them, all else being equal, 390 and I understand that high-speed switch designs may make it hard in 391 practise to do it, but I don't get how it's so inherently evil. If 392 you gotta send a packet anyway, why not two birds it?]] 394 It should be noted that _none_ of the piggybacking of control 395 functionality in LISP is _architecturally fundamental_ to LISP. All 396 of the functions in LISP which are performed with piggybacking could 397 be performed almost equally well with separate control packets. 399 The "almost" is solely because it would cause more overhead (i.e. 400 control packets); neither the response time, robustness, etc would 401 necessarily be affected - although for some functions, to match the 402 response time observed using piggybacking on user data would need as 403 much control traffic as user data traffic. 405 [[A6: It used to say this: Piggybacking is purely an optization. It 406 is easy to perform some 'back of the envelope' calculations to show 407 that abandoning it would not cause that great an increase in 408 overhead. but I think I just showed, above, that in some cases it 409 would take a great deal more traffic indeed to get the same kind of 410 response time.]] 412 [[A7: Should we actually throw some numbers in here?]] 414 This technique is particularly important, however, because of the 415 issue identified at the start of this section - the very large fanout 416 of the typical LISP switch. Unlike a typical router, which will have 417 control interactions with only a few neighbours, a LISP switch could 418 eventually have control interactions with hundreds, or perhaps even 419 thousands (for a large site) of neighbours. 421 Explicit control traffic, especially if good response times are 422 desired, could amount to a very great deal of overhead in such a 423 case. 425 5. Namespaces 427 One of the key elements in any architecture, or architectural 428 analysis, are the namespaces involved: what are their semantics and 429 syntax, what are the kinds of things they name, etc. 431 LISP has two key namespace, EIDs and RLOCs, but it must be emphasized 432 that on an architectural level, neither the syntax, or, to a lesser 433 degree, the semantics, of either are absolutely fixed. There are 434 certain core semantics which are generaly unchanging (such as the 435 notion that EIDs provide only identity, whereas RLOCs provide 436 location), but as we will see, there is a certain amount of 437 flexibility available for the long-term. 439 [[N0: Actually, technically speaking, it's not true that EIDs are 440 always only identity. In double-encapsulation cases, the output 441 (RLOC) of one stage of mapping turns into the input (EID) of another 442 stage. We should probably mention that at some point. For now, I 443 have thrown a few 'weasel words' in above.]] 445 In particular, all of LISP's key interfaces always include an Address 446 Family Identifier (AFI) [AFI] for all names, so that new forms can be 447 introduced at any time the need is felt. Of course, in practise such 448 an introduction would not be a trivial exercise - but neither is is 449 impossibly painful, as is the case with IPv4's 32-bit addresses, 450 which are effectively impossible to upgrade. 452 5.1. LISP EIDs 454 A 'classic' EID is defined as a subset of the possible namespaces for 455 endpoints. [Chiappa] Like most 'proper' endpoint names, as proposed 456 there, they contain contain no information about the location of the 457 endpoint. EIDs are the subset of possible endpoint names which are: 458 fixed length, 'reasonably' short', binary (i.e. not intended for 459 direct human use), globally unique (in theory), and allocated in a 460 top-down fashion (to achieve the former). [[N1: Check to make sure 461 that's the real definition of EID.]] 463 LISP EIDs are, in line with the general LISP deployment philosophy, a 464 reuse of something already existing - i.e. IPvN addresses. For 465 those used as in LISP as EIDs, LISP removes much (or, in some cases, 466 all) of the location-naming function of IPvN addresses. 468 In addition, the goal is to have EIDs name hosts (or, more properly, 469 their end-end communication stacks), whereas the other LISP namespace 470 group (RLOCs) names interfaces. The idea is not just to have two 471 namespaces (with different semantics), but also to use them to name 472 _different classes of things_ - classes which currently do not have 473 clearly differentiated names. This should produce even more 474 functionality. 476 5.1.1. Residual Location Functionality in EIDs 478 LISP retains, especially in the early stages of the deployment, in 479 many cases some residual location-naming functionality in EIDs, This 480 is to allow the packet to be correctly routed/forwarded to the 481 destination node, once it has been unwrapped by the ETR - and this is 482 a direct result of LISP's deployment philosophy (see [Introduction], 483 Section "Deployment"). 485 Clearly, if there are one or more unmodified routers between the ETR 486 and the desination node, those routers will have to perform a routing 487 step on the packet, for which it will need _some_ information as to 488 the location of the destination. 490 One can thus view such LISP EIDs, which retain 'stub' location 491 information, as 'addresses' (in the definition of the generic sense 492 of this term, as used here), but with the location information 493 restricted to a limited, local scope. 495 This retention of some location functionality in LISP EIDs, in some 496 cases, has led some people to argue that use of the name 'EID' is 497 improper. In response, it was suggested that LISP use the term 498 'LEID', to distinguish LISP's 'bastardized' EIDs from 'true' EIDs, 499 but this usage has never caught on. [[N2: Dike this? It has been 500 quite a hot bone, though, so I'm afraid that it we leave it out, 501 we'll just have round 17 of this debate..]] 503 It has also been suggested that one usage mode for LISP EIDs, in 504 existing software loads, is to assign them as the address on an 505 internal virtual interface; all the real interfaces would have RLOCs 506 only. [Templin] This would make such LISP EIDs functionally 507 equivalent to 'real' EIDs - they are names which are purely identity, 508 have no location information of any kind in them, and cannot be used 509 to make any routing decisions anywhere outside the host. 511 It is true that even in such cases, the EID is still not a 'pure' 512 EID, as it names an interface, not the end-end stack directly. 513 However, to do a perfect job here (or on separation of location and 514 identity) is impossible without modifying existing hosts (which are, 515 inevitably, almost always one end of an end-end communication) - and 516 that has been ruled out, for reasons of viable deployment. [[N3: 517 Now, this might be duplicative.]] 519 The need for interoperation with existing unmodified hosts limits the 520 semantic changes one can impose, much as one might like to provide a 521 cleaner separation. (Future evolution can bring us toward that 522 state, however: see [Future].) 524 [[N4: A LISP EID which is assigned to a virtual interface, one which 525 is created _solely_ as a place to hold the system's identity, is 526 effectively as pure an EID as one could wish. - Excessive, leave 527 out?]] 529 5.2. RLOCs 531 RLOCs are basically pure 'locators' [RFC1992], although their syntax 532 and semantics is restricted at the moment, because in practise the 533 only forms of RLOCs supported are IPv4 and IPv6. [[N5: Is this true? 534 Apparently people are working on other things?]] 536 [[N6: More? Can't think of anything else to say.]] 538 5.3. Overlapping Uses of Existing Namespaces 540 It is in theory possible to have a block of IPvN namespace used as 541 both EIDs and RLOCs. In other words, EIDs from that block might map 542 to some other RLOCs, and that block might also appear in the DFZ as 543 the locators of some other ETRs. 545 This is obviously potentially confusing - when a 'bare' IPvN address 546 from one of these blocks, is it the RLOC, or the EID? Sometimes it 547 it obvious from the context, but in general one could not simply have 548 a (hypothetical) table which assigns all of the address space to 549 either 'EID' or 'RLOC'. 551 In addition, such usage will not allow interoperation of the sites 552 named by those EIDs with legacy sites, using the PITR mechanism 553 ([Introduction], Section "Proxy Devices"), since that mechanisms 554 depends on advertizing the EIDs into the DFZ, although the LISP-NAT 555 mechanism should still work ([Introduction], Section "LISP-NAT"). 557 Nevertheless, as the IPv4 namespace becomes increasingly used up, 558 this may be an increasingly attractive way of getting the 'absolute 559 last drop' out of that space. [[N7: Do we really want to point this 560 out, or would it be better to be silent about the IPv4-extending 561 capability?]] 563 5.4. LCAFs 565 {{To be written.}}[[N8: ]] 567 --- Key-ID 568 --- Instance-IDs 570 6. Scalability 572 As with robustness, any global communication system must be scalable, 573 and scalable up to almost any size. As previously mentioned (xref 574 target="Perspectives-Packet"/), the large fanouts to be seen with 575 LISP, due to its 'overlay' nature, present a special challenge. 577 One likely saving grace is that as the Internet grows, most sites 578 will likely only interact with a limited subset of the Internet; if 579 nothing else, the separation of the world into language blocks means 580 that content in, say, Chinese, will not be of interest to most of the 581 rest of the world. This tendency will help with a lot of things 582 which could be problematic if constant, full, N^2 connectivity were 583 likely on all nodes; for example the caching of mappings. 585 6.1. Demand Loading of Mappings 587 One question that many will have about LISP's design is 'why demand- 588 load mappings - why not just load them all'? It is certainly true 589 that with the growth of memory sizes, the size of the complete 590 database is such that one could reasonably propose keeping the entire 591 thing in each LISP device. (In fact, one proposed mapping system for 592 LISP, named NERD, did just that. [NERD]) 594 A 'pull'-based system was chosen over 'push' for several reasons; the 595 main one being that the issue is not just the pure _size_ of the 596 mapping database, but its _dynamicity_. Depending on how often 597 mappings change, the update rate of a complete database could be 598 relatively large. 600 It is especially important to realize that, depending on what 601 (probably unforseeable) uses eventually evolve for the 602 identity->location mapping capability LISP provides, the update rate 603 could be very high indeed. E.g. if LISP is used for mobility, that 604 will greatly increase the update rate. Such a powerful and flexible 605 tool is likely be used in unforseen ways (Section 4.2), so it's 606 unwise to make a choice that would preclude any which raise the 607 update rate significantly. 609 Push as a mechanism is also fundamentally less desirable than pull, 610 since the control plane overhead consumed to load and maintain 611 information about unused destinations is entirely wasted. The only 612 potential downside to the pull option is the delay required for the 613 demand-loading of information. 615 (It's also probably worth noting that many issues that some people 616 have with the mapping approach of LISP, such as the total mapping 617 database size, etc are the same - if not worse - for push as they are 618 for pull.) 620 Finally, for IPv4, as the address space becomes more highly used, it 621 will become more fragmented - i.e. there will tend to be more, 622 smaller, entries. For a routing table, which every router has to 623 hold, this is problematic. For a demand-loaded mapping table, it is 624 not bad. Indeed, this was the original motivation for LISP 625 ([RFC4984]) - although many other useful and desirable uses for it 626 have since been enumerated (see [Introduction], Section 627 "Applications"). 629 For all of these reasons, as long as there is locality of reference 630 (i.e. most ITRs will use only a subset of the entire set), it makes 631 much more sense to use the a pull model, than the classic push one 632 heretofore seen widely at the internetwork layer (with a pull 633 approach thus being somewhat novel - and thus unsettling to many - to 634 people who work at that layer). 636 It may well be that some sites (e.g. large content providers) may 637 need non-standard mechanisms - perhaps something more of a 'push' 638 model. This remains to be determined, but it is certainly feasible. 640 6.2. Caching of Mappings 642 It should be noted that the caching spoken of here is likely not 643 classic caching, where there is a fixed/limited size cache, and 644 entries have to be discarded to make room for newly needed entries. 645 The economics of memory being what they are, there is no reason to 646 discard mappings once they have been loaded (although of course 647 implementations are free to chose to do so, if they wish to). 649 This leads to another point about the caching of mappings: the 650 algorithms for management of the cache are purely a local issue. The 651 algorithm in any particular ITR can be changed at will, with no need 652 for any coordination. A change might be for purposes of 653 experimentation, or for upgrade, or even because of environmental 654 variations - different environments might call for different cache 655 management strategies. 657 The local, unsynchronized replacability of the cache management 658 scheme is the architectural aspect of the design; the exact 659 algorithm, which is engineering, is not. 661 6.3. Amount of State 663 {{To be written.}} [Iannone] 665 -- Mapping cache size 666 --- Mention studies 667 -- Delegation cache size (in MRs) 668 --- Mention studies 669 -- Any others? 671 6.4. Scalability of The Indexing Subsystem 673 LISP initially used an indexing subsystem called ALT. [ALT] ALT was 674 relatively easy to construct from existing tools (GRE, BGP, etc), but 675 it had a number of issues that made it unsuitable for large-scale 676 use. ALT is now being superseded by DDT. [DDT] 678 The basic structure and operation of DDT is identical to that of 679 TREE, so the extensive simulation work done for TREE applies equally 680 to DDT, as do the conclusions drawn about TREE's superiority to ALT. 681 [Jakab] 683 From an architectural point of view, the main advantage of DDT is 684 that it enables client side caching of information about intermediate 685 nodes in the resolution hierarchy, and also enables direct 686 communication with them. As a result, DDT has much better scaling 687 properties than ALT. 689 The most important result of this change is that it avoids a 690 concentration of resolution request traffic at the root of the 691 indexing tree, a problem which by itself made ALT unsuitable for a 692 global-scale system. The problem of root concentration (and thus 693 overload) is almost unavoidable in ALT (even if masses of 'bypass' 694 links are created). 696 ALT's scalability also depends on enforcing an intelligent 697 organization that aincreases aggregation. Unfortunately, the current 698 backbone routing BGP system shows that there is a risk of an organic 699 growth of ALT, one which does not achieve aggregation. DDT does not 700 display this weakness, since its organization is inherently 701 hierarchical (and thus inherently aggregable). 703 The hierarchical organization of DDT also reduces the possibility for 704 a configuration error which interferes with the operation of the 705 network (unlike the situation with the current BGP DFZ). DDT 706 security mechanisms can also help produce a high degree of 707 robustness, both against misconfiguration, and deliberate attack. 708 The direct communication with intermediate nodes in DDT also helps to 709 quickly locate problems when they occur, resulting in better 710 operational characteristics. 712 Next, since in ALT mapping requests must be transmitted through an 713 overlay network, a significant share of requests can see 714 substantially increased latencies. Simulation results in the TREE 715 work clearly showed, and quantified, this effect. 717 The simulations also showed that the nodes composing the ALT and DDT 718 networks for a mapping database of full Internet size could have 719 thousands of neighbours. This is not an issue for DDT, but would 720 almost certainly have been problematic for ALT nodes, since handling 721 that number of simultaneous BGP sessions would likely to be 722 difficult. 724 7. Security 726 LISP does not yet have an overarching security architecture. Many 727 parts of the system have been hardened, but more on a case-by case 728 basis, rather than from an overall perspective. (This is in part due 729 to the 'just enough' approach to security initially taken in LISP; 730 see [Introduction], Section "Just Enough Security".) 732 This section represents an attempt to produce a more broadly-based 733 view of security in LISP; it mostly resulted from an attempt to add 734 security to the DDT indexing system ([DDT]), but the analysis is is 735 general enough to apply to LISP broadly. 737 The _good_ thing about the Internet is that it brings the world to 738 your doorstep - masses of information from all around the world are 739 instantly available on your computing device. The _bad_ thing about 740 the Internet is that it brings the world to your doorstep - including 741 legions of crackers, thieves, and general scum and villainy. Thus, 742 any node may be the target of fairly sophisticated attack - often 743 automated (thereby reducing the effort required of the attacker to 744 spread their attack as broadly as possible). 746 Security in LISP faces many of the same challenges as security for 747 other parts of the Internet: good security usually means work for the 748 users, but without good security, things are vulnerable. 750 The Internet has seen many very secure systems devised, only to see 751 them fail to reach wide adoption; the reasons for that are complex, 752 and vary, but being too much work to use is a common thread. It is 753 for this reason that LISP attempts to provide 'just enough' security 754 (see [Introduction], Section "Just Enough Security"). 756 7.1. Basic Philosophy 758 To square this circle, of needing to have very good security, but of 759 it being too difficult to use very good security, the general concept 760 is for LISP to have a series of 'graded' security measures available, 761 with the 'ultimate' security mechanisms being very high-grade indeed. 763 The concept is to devise a plan in which LISP can simultaneously 764 attempt to have not just 'ultimate' security, but also one or more 765 'easier' modes, ones which will be easier to configure and use. This 766 'easier' mode can be both an interim system (with the full powered 767 system available for when it it needed), as well as the system used 768 in sections of the network where security is less critical (following 769 the general rule that the level of any security should generally be 770 matched to what is being protected). 772 The challenge is to do this in a way that does not make the design 773 more complex, since it has to include both the 'full strength' 774 mechanism(s), and the 'easier to configure' mechanism(s). This is 775 one of the fundamental tradeoffs to struggle with: it is easy to 776 provide 'easier to configure' options, but that may make the overall 777 design more complex. 779 As far as making it hard to implement to begin with (also something 780 of a concern initially, although obviously not for the long term): we 781 can make it 'easy' to deploy initially by simply not implementing/ 782 configuring the heavy-duty security early on. (Provided, of course, 783 that the packet formats, etc, needed to support such security are all 784 included in the design to begin with.) 786 7.2. Design Guidance 788 In designing the security, there are a small number of key points 789 that will guide the design: 791 - Design lifetime 792 - Threat level 794 How long is the design intended to last? If LISP is successful, a 795 minimum of a 50-year lifetime is quite possible. (For comparison, 796 IPv4 is now 34 at the time of writing this, and will be around for at 797 least several decades yet, if not longer; DNS is 28, and will 798 probably last indefinitely.) 800 How serious are the threats it needs to meet? As mentioned above, 801 the Internet can bring the worst crackers from anywhere to any 802 location, in a flash. Their sophistication level is rising all the 803 time: as the easier holes are plugged, they go after others. This 804 will inevitably eventually require the most powerful security 805 mechanisms available to counteract their attacks. 807 [[S0: An illustration from another field may be useful here. The 808 kind of complex and powerful security available in multi-level secure 809 time-sharing systems like Multics appeared at one point to be a relic 810 of another age, not useful in the age of personal machines. Complex 811 and difficult, they appeared to be an expensive dead end. However, 812 when active content first started to appear, it became apparent that 813 allowing active content from the network was allowing almost anyone 814 to share the computer with you - exactly the situation the security 815 of multi-level secure time-sharing systems was designed to handle. - 816 Probably too long / not important enough, delete?]] 818 Which is not to say that LISP needs to be that secure _right away_. 819 The threat will develop and grow over a long time period. However, 820 the basic design has to be capable of being _securable_ to the 821 expanded degree that will eventually be necessary. However, 822 _eventually_ it will need to be as securable as, say, DNS - i.e. it 823 _can_ be secured to the same level, although people may chose not to 824 secure their LISP infrastructure as well as DNSSEC potentially does. 825 [RFC4033] 827 In particular, it should be noted that historically many systems have 828 been broken into, not through a weakness in the algorithms, etc, but 829 because of poor operational mechanics. (The well-known 'Ultra' 830 breakins of the Allies were mostly due to failures in operational 831 procedure. [Welchman]) So operational capabilities intended to 832 reduce the chance of human operational failure are just as important 833 as strong algorithms; making things operationally robust is a key 834 part of 'real' security. 836 7.2.1. Security Mechanism Complexity 838 Complexity is bad for several reasons, and should always be reduced 839 to a minimum. There are three kinds of complexity cost: protocol 840 complexity, implementation complexity, and configuration complexity. 841 We can further subdivide protocol complexity into packet format 842 complexity, and algorithm complexity. (There is some overlap of 843 algorithm complexity, and implementation complexity.) 845 We can, within some limits, trade off one kind of complexity for 846 others: e.g. we can provide configuration _options_ which are simpler 847 for the users to operate, at the cost of making the protocol and 848 implementation complexity greater. And we can make initial (less 849 capable) implementations simpler if we make the protocols slightly 850 more complex (so that early implementations don't have to implement 851 all the features of the full-blown protocol). 853 It's more of a question of some operational convenience/etc issues - 854 e.g. 'How easy will it be to recover from a cryptosystem 855 compromise'. If we have two ways to recover from a security 856 compromise, one which is mostly manual and a lot of work, and another 857 which is more automated but makes the protocol more complicated, if 858 compromises really are very rare, maybe the smart call _is_ to go 859 with the manual thing - as long as we have looked carefully at both 860 options, and understood in some detail the costs and benefits of 861 each. 863 7.3. Security Overview 865 First, there are two different classes of attack to be considered: 866 denial of service (DoS, i.e. the ability of an intruder to simply 867 cause traffic not to successfully flow) versus exploitation (i.e. the 868 ability to cause traffic to be 'highjacked', i.e. traffic to be sent 869 to the wrong location). 871 Second, one needs to look at all the places that may be attacked. 872 Again, LISP is a relatively simple system, so there are not that many 873 parts to examine. The following are the things we need to secure: 875 - Lookups 876 - Indexing 877 - Mappings 879 7.3.1. Securing Lookups 881 {{To be written.}} Nonces, [SecurityReq] 883 7.3.2. Securing The Indexing Subsystem 885 It is envisioned that DDT will be highly securable, with all the 886 delegations cryptographiclly secured via public-private signatures, 887 very similar to the way DNS is ([RFC4033]). 889 The detailed mechanisms will be based on DNS's; this has the obvious 890 benefit that all the lessons of DNS's years of practical experience 891 with deployment, operations, etc, as well as the improvements to the 892 basic design of DNS Security to provide a secure but usable system 893 can be taken into account. However, DDT's security will also apply 894 the thinking above, about making a 'versio' which is easier to use 895 available. 897 {{To be written.}} [[S3: WTF is up with DDTSEC anyway?]] 899 7.3.3. Securing Mappings 901 There are two approaches to securing the provision of mappings. The 902 first, which is of course not completely satisfactory, is to only 903 secure the channel between the ITR and the entities involved in 904 providing mappings for it. (See above, Section 7.3.1) 906 The second is to secure the mappings themselves, by signing them 'at 907 birth' (much the same way in which DNS Security operates). 908 [RFC4033]. There was an attempt early on to suggest such a system 909 for LISP ([SecurityAuth]), but it was not adopted (although the 910 particular proposal was rather complex). 912 In the long run, the latter approach would obviously be superior, 913 since it would be almost immune to any compromises of the mapping 914 distribution system. {{Tie-in to space allocation security}} 916 7.4. Securing the xTRs 918 --- Cache management 919 --- Unsoliticed Map-Replies are _very bad_ - must go through 920 mapping system to verify that the sender is authoritative for 921 that range of EIDs 923 8. Robustness 925 -- Depends on deployment as well as design 926 -- Architected, visible replication of state/data 927 -- Overlapping mechanisms (ref redundancy as key for robustness) 929 9. Fault Discovery/Handling 931 Any global communication system must be robust, and to be robust, it 932 must be able to discover and handle problems. LISP's general 933 philosophy of robustness is usually to have overlapping, simple 934 mechanisms to discover and repair problems. 936 [[F0: Check Intro document to see what text should probably be moved 937 back here with this.]] 939 10. Optimization 941 [[O0: May not need this section, most of these topics are covered 942 elsewhere?]] 944 -- Philosophy 945 -- Piggybacking 946 -- 'Wiretapping' return mappings 947 --- Security is an issue on that 949 [[O1: does wiretapping ever/still happen? - yes LISP pg. x]] 951 11. Open Issues 953 Although much work has been done on LISP, and it operates 954 satisfactorily in a reasonably large initial deployment, there are a 955 few potentially problematic issues which remain. It is not clear if 956 they will be issues which need to be dealt, since they have not 957 proven to be obstacles so far, but it is worth listing them. 959 We can divide them in _local_ issues, i.e. ones which can be solved 960 on a node-by-node basis, without requiring co-ordinated change, and 961 systemic issues, which are obviously more problematic, since they 962 could require co-ordinated changes to the protocols. 964 [[OI0: Should this section be in the Intro document?]] 966 11.1. Local Open Issues 968 11.1.1. Missing Mapping Packet Queueing 970 Currently, some (all?) ITRs discard packets when they need a 971 mapping, but have not loaded one yet, thereby causing the applicaton 972 to have to retransmit their opening packet. True, many ARP 973 implementations use the same strategy, but the average APR cache will 974 only ever contain a few mappings, so it will not be so noticeable as 975 with the mapping cache in an ITR, which will likely contain 976 thousands. 978 Obviously, they could queue the packets while waiting to load the 979 mapping, but this presents a number of subtle implementation issues: 980 the ITR must make sure that it does not queue too many packets, etc. 982 In particular, if such packets are queued, this presents a potential 983 DoS attack vector, unless the code is carefully written with that 984 possibility in mind. 986 11.1.2. Mapping Cache Management Algorithm 988 Relatively little work has been done on sophisticated mapping cache 989 management algorithms; in particular, the issue of which mapping(s) 990 to drop if the cache reaches some maximum allowed size. 992 This particular issue has also been identified as another potential 993 DoS attack vector. 995 11.2. Systemic Open Issues 997 11.2.1. Mapping Database Provider Lock-in 999 This refers to the fact that if one does not like the entity which is 1000 providing the indexing for the part of the address space which one's 1001 EIDs are allocated out of, there isn't probably isn't any way to 1002 switch to an alternative provider. 1004 It is not clear that this is a real probem, though - the fact that 1005 all DNS top-level zones only have a single registry has not been a 1006 problem, nor has the fact that if one doesn't like the service the 1007 registry offers, one can't take one's DNS name to another registry. 1009 Doing anything about it would also be difficult. Although it is 1010 _technically_ possible to duplicate any node in the delegation tree, 1011 and in theory such duplicates could be provided by different 1012 providers, it is not clear that such an arrangement would make 1013 _business_ sense. 1015 For instance, if the holder of 10.1.1/24 decides they do not like the 1016 entity providing indexing for 10.1/16 (call them E1), and ask another 1017 entity (E2) to provide alternative service for 10.1/16, two problems 1018 arise. First, E1 is _still_ going to have to maintain the correct 1019 data for 10.1.1/24, and response to queries asking about them. 1020 Second, E2 will similarly have to maintain data for, and reply to 1021 queries about, all the other space-holders in 10.1/16 - even though 1022 they will likely not have any business relationship with them. 1024 11.2.2. Automated ETR Synchronization 1026 LISP requires that all the ETRs which are authoritative for the 1027 mappings for a particular address block return the same mapping data. 1028 In particular, their idea of the 'liveness' of all the ETRs should be 1029 identical, and correct. 1031 At the moment, this is mostly a manual process, although liveness 1032 information can be currently be gathered from some IGPs. 1034 11.2.3. EID Reachability 1036 At the moment, LISP assumes that if an ETR is reachable from a given 1037 ITR, all destination EIDs behind that ETR are reachable from that 1038 ETR. There is no way to detect if any are not, nor to switch to an 1039 alternate ETR. 1041 It is not clear that this is a problem that needs attention. The 1042 same has been true for all border routers for many years now, and 1043 there does not seem to be any general mechanism to deal with it 1044 (Although some BGP implementations may advertize changes in 1045 reachability status if what they are seeing from their IGP changes.) 1047 11.2.4. Detect and Avoid Broken ETRs 1049 {{To be written}} 1051 12. Acknowledgments 1053 The author would like thank all the members of the core LISP group 1054 for their willingness to allow him to add himself to their effort, 1055 and for their enthusiasm for whatever assistance he has been able to 1056 provide. He would also like to thank (in alphabetical order) Vina 1057 Ermagan, Vince Fuller, and Joel Halpern for their careful review of, 1058 and helpful suggestions for, this document. Grateful thanks also to 1059 Vince Fuller for help with XML. 1061 A final thanks is due to John Wrocklawski for the author's 1062 organizational affiliation. This memo was created using the xml2rfc 1063 tool 1065 13. IANA Considerations 1067 This document makes no request of the IANA. 1069 [[xx: This section will be deleted by the RFC Editor.]] 1071 14. Security Considerations 1073 This memo does not define any protocol and therefore creates no new 1074 security issues. 1076 [[yy: Do we need to say anything at all here, beyond something like 1077 'LISP has some potential security issues, see XXX for details'?]] 1079 15. References 1081 15.1. Normative References 1083 [DDT] V. Fuller, D. Lewis, and D. Farinacci, "LISP 1084 Delegated Database Tree", draft-fuller-lisp-ddt-01 1085 (work in progress), March 2012. 1087 [Future] J. N. Chiappa, "Potential Long-Term Developments With 1088 the LISP System", draft-chiappa-lisp-evolution-00 1089 (work in progress), July 2012. 1091 [Introduction] J. N. Chiappa, "An Introduction to the LISP Location- 1092 Identity Separation System", 1093 draft-chiappa-lisp-introduction-00 (work in 1094 progress), July 2012. 1096 [SecurityAuth] R. Gagliano, "A Profile for Endpoint Identifier 1097 Origin Authorizations (IOA)", 1098 draft-rgaglian-lisp-iao-00 (work in progress), 1099 March 2009. 1101 [SecurityReq] F. Maino, V. Ermagan, A. Cabellos, D. Saucez, and 1102 O. Bonaventure, "LISP-Security (LISP-SEC)", 1103 draft-ietf-lisp-sec-02 (work in progress), 1104 March 2012. 1106 [AFI] IANA, "Address Family Indicators (AFIs)", Address 1107 Family Numbers, January 2011, . 1110 15.2. Informative References 1112 [RFC1631] K. Egevang and P. Francis, "The IP Network Address 1113 Translator (NAT)", RFC 1631, May 1994. 1115 [RFC1992] I. Castineyra, J. N. Chiappa, and M. Steenstrup, "The 1116 Nimrod Routing Architecture", RFC 1992, August 1996. 1118 [RFC3031] E. Rosen, A. Viswanathan, and R. Callon, 1119 "Multiprotocol Label Switching Architecture", 1120 RFC 3031, January 2001. 1122 [RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, and 1123 S. Rose, "DNS Security: Introduction and 1124 Requirements", RFC 4033, March 2005. 1126 [RFC4423] R. Moskowitz and P. Nikander, "Host Identity Protocol 1127 (HIP) Architecture", RFC 4423, May 2006. 1129 [RFC4984] D. Meyer, L. Zhang, and K. Fall, "Report from the IAB 1130 Workshop on Routing and Addressing", RFC 4984, 1131 September 2007. 1133 [RFC6115] T. Li, Ed., "Recommendation for a Routing 1134 Architecture", RFC 6115, February 2011. 1136 Perhaps the most ill-named RFC of all time; it 1137 contains nothing that could truly be called a 1138 'routing architecture'. 1140 [RFC6127] J. Arkko and M. Townsley, "IPv4 Run-Out and IPv4-IPv6 1141 Co-Existence Scenarios", RFC 6127, May 2011. 1143 [ALT] D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, 1144 "LISP Alternative Topology (LISP-ALT)", 1145 draft-ietf-lisp-alt-10 (work in progress), 1146 December 2011. 1148 [NERD] E. Lear, "NERD: A Not-so-novel EID to RLOC Database", 1149 draft-lear-lisp-nerd-09 (work in progress), 1150 April 2012. 1152 [ILNP] R.J. Atkinson and S.N. Bhatti, "ILNP Architectural 1153 Description", draft-irtf-rrg-ilnp-arch-05 (work in 1154 progress), May 2012. 1156 [Chiappa] J. N. Chiappa, "Endpoints and Endpoint Names: A 1157 Proposed Enhancement to the Internet Architecture", 1158 Personal draft (work in progress), 1999, 1159 . 1161 [Jakab] L. Jakab, A. Cabellos-Aparicio, F. Coras, D. Saucez, 1162 and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to 1163 Support the LISP Mapping System", in 'IEEE Journal on 1164 Selected Areas in Communications', Vol. 28, No. 8, 1165 pp. 1332-1343, October 2010. 1167 [Iannone] L. Iannone and O. Bonaventure, "On the Cost of 1168 Caching Locator/ID Mappings", in 'Proceedings of the 1169 3rd International Conference on emerging Networking 1170 EXperiments and Technologies (CoNEXT'07)', ACM, pp. 1171 1-12, December 2007. 1173 [McQuillan] J. M. McQuillan, W. R. Crowther, B. P. Cosell, 1174 D. C. Walden, and F. E. Heart, "Improvements in the 1175 Design and Performance of the ARPA Network", 1176 Proceedings AFIPS 1972 FJCC, Vol. 40, pp. 741-754. 1178 [Templin] F. Templin, "LISP WG", LISP WG list 1179 message, Message-ID: 39C363776A4E8C4A94691D2BD9D1C9A1 1180 05B0AC71@XCH-NW-7V2.nw.nos.boeing.com, 13 1181 March 2009,, . 1184 [Wasserman] M. Wasserman, "IPv6 networking: Bad news for small 1185 biz", IETF list message, Message-Id: 1186 D11C4A34-7362-423E-A60E-476FC5D61D37@lilacglade.org, 1187 5 April 2012, . 1191 [Welchman] G. Welchman, "The Hut Six Story", Allen Lane, 1192 London, pg. 3, 1982. 1194 A truly monumental book; the ground it covers ranges 1195 from his work helping break German codes in World War 1196 II to his experience with securing data packet 1197 networks! 1199 Appendix A. Glossary/Definition of Terms 1201 [[Gl1: I _hate_ it when people put this up front, it really cuts into 1202 the flow]] 1203 [[Gl2: Also, most of these can probably be lifted directly from the 1204 LISP RFC.]] 1206 - Address 1207 - Locator 1208 - EID 1209 - RLOC 1210 - ITR 1211 - ETR 1212 - xTR 1213 - PITR 1214 - PETR 1215 - MR 1216 - MS 1217 - DFZ 1219 Appendix B. Other Appendices 1221 -- Location/Identity Separation Brief History 1222 -- LISP History 1223 -- Old models (LISP 1, LISP 1.5, etc) 1224 -- Different mapping distribution models (e.g. LISP-NERD) 1225 -- Different mapping indexing models (LISP-ALT 1226 forwarding/overlay model), 1227 LISP-TREE DNS-based, LISP-CONS) 1229 Author's Address 1231 J. Noel Chiappa 1232 Yorktown Museum of Asian Art 1233 Yorktown, Virginia 1234 USA 1236 EMail: jnc@mit.edu