Network Working Group L. Mathy Internet-Draft Lancaster U Intended status: Informational L. Iannone Expires: August 28, 2008 O. Bonaventure UCLouvain February 25, 2008 LISP-DHT: Towards a DHT to map identifiers onto locators draft-mathy-lisp-dht-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Mathy, et al. Expires August 28, 2008 [Page 1] Internet-Draft LISP-DHT February 2008 Abstract LISP-DHT is a DHT based mapping distribution system for LISP. The purpose of LISP-DHT is to distribute identifier-to-routing-locators mappings through a distributed hash tables infrastructure. LISP-DHT is designed to preserve the locality of the mapping, i.e., the mapping is always stored on the LISP-DHT nodes chosen by the owner of the mapping. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Chord Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Mappings Authoritative Ownership . . . . . . . . . . . . . . . 6 4. Stealth Chord for LISP-DHT . . . . . . . . . . . . . . . . . . 8 5. LISP-DHT Queries/Replies . . . . . . . . . . . . . . . . . . . 10 6. LISP-DHT Robustness . . . . . . . . . . . . . . . . . . . . . 11 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 Appendix A. Terms Definition . . . . . . . . . . . . . . . . . . 17 11. Informative References . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Mathy, et al. Expires August 28, 2008 [Page 2] Internet-Draft LISP-DHT February 2008 1. Introduction The locator/ID separation paradigm is being discussed in the IRTF Routing Research Group (RRG) in order to solve scalability issues that todays Internet is facing ([I-D.iab-raws-report], [I-D.irtf-rrg-design-goals]). Several approaches are currently being discussed and most of them rely on the separation between the locators and the identifiers roles of addresses. Works like [QUOITIN07] clearly show that several benefits can be achieved with such an approach, not only in alleviating the routing burden of the Default Free Zone (DFZ). The Locator/ID Separation Protocol [I-D.farinacci-lisp] is one of the solutions being discussed within the RRG. We focus on LISP in this document and reuse some LISP terminology copied in Appendix A. A key problem faced by an architecture that separates the identifier/ locator roles is that a mapping system will be required to distribute mappings between identifiers and locators in a scalable way. Several mapping distribution protocols have been proposed recently for LISP ([I-D.lear-lisp-nerd], [I-D.curran-lisp-emacs], [I-D.fuller-lisp-alt], [I-D.meyer-lisp-cons]). However, none of them takes a DHT based approach. Even if, in the early versions of the LISP specification, for the LISP 3 variant was suggested the utilization of Distribute Hash Tables (DHT) to distribute the mappings [I-D.farinacci-lisp-03]. LISP-DHT fill this gap, by proposing to distribute mappings by using distributed hash tables. DHTs exhibit several very interesting properties, such as self- configuration, self-maintenance, scalability and robustness that are clearly desirable for a EID-to-RLOCs resolution service. LISP-DHT can be considered an hybrid push/pull approach for mapping distribution. Indeed, mappings are distributed inside the LISP-DHT infrastructure using the DHT push model. However, ITRs and ETRs retrieve mapping from the LISP-DHT system through explicit queries, thus using a pull model. LISP-DHT is designed to preserve the locality of the mapping, i.e., the mapping is always stored on the LISP-DHT nodes of the owner of the mapping. A DHT-based mapping service will play a crucial role in the Internet architecture that is being discussed within the IRTF RRG. Although no decision has been made on how identifiers are allocated, we assume that contiguous blocks of identifiers (EID-prefix) will be allocated to each domain. We use the notation EID-prefix(D) to indicate the list of contiguous EIDs that have been allocated to domain D. Given the importance of the mapping service for the reachability of the hosts inside a domain, we expect that domains will have the following requirements for their mapping service: Mathy, et al. Expires August 28, 2008 [Page 3] Internet-Draft LISP-DHT February 2008 1. a domain must be able to control the server that provides the authoritative mappings for the EIDs allocated to the hosts of its domain; 2. a domain will often require one (or more) redundant mapping server(s) and the domain must be able to control which redundant servers are used to map the identifiers that have been allocated to its hosts. These two requirements are similar to the requirements of today's network operators concerning their DNS servers. As classical DHTs tend to randomize which node is responsible for a key-value pair (in our case a key-value pair would be a mapping), they do not directly meet the requirements above. In the present memo we propose modifications to Chord, so to retain all its useful properties, while helping to meet the two above mapping requirements. This document is organized as follows. In Section 2 we first briefly summarize the Chord DHT. Then, in Section 3 we show how to modify Chord to meet the first requirement. In Section 4 and Section 5, we describe in more details the behavior of the LISP-DHT. Finally, in Section 6, we explain how redundant mapping servers can be supported in LISP-DHT. Mathy, et al. Expires August 28, 2008 [Page 4] Internet-Draft LISP-DHT February 2008 2. Chord Overview Chord [stoica-chord:2003] is a Distributed Hash Table (DHT). Each node has a unique k-bits identifier (called ChordID in this section). Chord organizes its ChordID space as a ring. A node owns all keys that precedes it on the circle, up to, but excluding, the previous node. For consistent routing and operation, every Chord node must maintain correct successor and predecessor node pointers. For performance reason, nodes also keep a finger table (a list of nodes that are further and further away - to be more precise, the ith finger in the table is the node that holds (i.e. succeeds) ChordID (n+2^(i-1)), where n is the node's ChordID). These "fingers" are not necessary to ensure correct operation of the protocol, however, they help in reducing lookup latency, which can be a main concern in the context of locator/id separation. Reliability and consistency is also increased if a node keeps pointers to several consecutive successors and predecessors on the ring. For load balancing, nodes are supposed to choose their ChordID (chosen in the same space as keys) randomly, and so should the key associated with a value (the key should be a hash of the value). It should also be noted that a single physical server can instantiate several separate Chord instances and thus appear at different positions on the ring. In current DHT implementations, and in Chord in particular, communications are usually implemented by using XML_RPC over HTTP, but other protocols are possible. To join the DHT ring, a new node only has to know another node on the ring, and uses this existing node to initialize its finger table (the first entry of the finger table is the successor to a node) and predecessor pointer, by simply asking that node to look up the corresponding keys (IDs) on the ring. The joining node also needs to then update its predecessor's successor pointer, its successor's predecessor pointer, as well as the finger pointers of other nodes that should now use the joining node in their fingers (these can be easily computed by the joining node). Then key transfers can take place. Additional information about Chord may be found in [stoica-chord:2003]. Mathy, et al. Expires August 28, 2008 [Page 5] Internet-Draft LISP-DHT February 2008 3. Mappings Authoritative Ownership As explained above, Chord nodes are supposed to choose their ChordID randomly. Also, keys associated with values should also be random (they should be hash values of the information). In the context of the EID-to-RLOC mapping resolution application considered in this document, such randomization is in contradiction with the kind of control expected by domains on their prefixes. To meet the first requirement expressed in section Section 1, we force each node to use one EID as ChordID on the Chord circle, and have domains create a Chord instance for each of their EID-prefix(D). The ChordID of each Chord instance would be the highest numerical EID inside EID-prefix(D) (instead of a random NodeID). Doing so ensures that domain D owns and manages the parts of the Chord circle that contains its identifiers (the domain can also actually own "unallocated" EIDs adjacent to EID-prefix(D)). Of course, the value associated with a key (EID) on the Chord ring would be the list of RLOCs associated with the corresponding EID. The knowledge of the predecessor node (and its ChordID), required for consistent routing and key management, also provides a guarantee that part of EID- prefix(D) has not been unlawfully claimed by another node in the Chord ring. It is mainly because of this straightforward use of EIDs as IDs and the associated ownership guarantee that we choose to use Chord for LISP-DHT. Also, all Chord routing information (used by Chord itself) should associate the (EID, RLOC) pair of a Chord node (i.e., mapping server) with its corresponding ChordID, so nodes on the Chord ring can communicate with each other. Credentials may be needed before insertion of a new node onto the ring. This could be needed, for instance, to prevent a rogue node from trying to hijack the mapping for some EID-prefix it does not own. This could be achieved by having the appropriate Internet Registries issue EID owners with a signed "certificate of ownership" of each prefix. The SIDR working group is already working on X.509 certificates for IP address prefixes [I-D.ietf-sidr-res-certs] that are very close to the certificates that would be required by LISP- DHT. Such certificate can be logically defined as below: M_own = (eidblock, owner, expiry) C_own = (M_own, Reg, Epriv(Reg, H(M_own))) where M represents a message containing the EID-prefix and a description of its owner, Reg is a description of the Internet Registry responsible for allocating the EID-prefix, expiry is the Mathy, et al. Expires August 28, 2008 [Page 6] Internet-Draft LISP-DHT February 2008 expiry date for the certificate, H(M) is a hash of message M, and Epriv(Entity, D) is the encryption, using Entity's private key of data D. As the "owner" of an EID-prefix will often be an organization, this organization must then issue the authoritative mapping server for its prefix mapping with a "certificate of authority": M_auth = (ChordID, server, C_own, expiry) C_auth = (M_auth, Epriv(owner, M_auth)) where ChordID is the Chord node ID (last address in the EID-prefix) and server is the (EID, RLOC) pair identifying the server. By including this certificate of authority in all Chord messages that trigger an update of routing information in other Chord nodes, a mapping server willing to join the ring can prove its right to be inserted in the corresponding place on the Chord ring. Note that for the system to be trusted, this Public Key Infrastructure (PKI) should be supported by the use of digital certificates and that any description of entities that may need to be authenticated should include a link to that entity's digital certificate. Finally, unless a re-allocation of EID-prefixes is taking place, no key transfer should happen, as a joining mapping server is simply claiming the part of the Chord space for which it knows the correct mappings. Mathy, et al. Expires August 28, 2008 [Page 7] Internet-Draft LISP-DHT February 2008 4. Stealth Chord for LISP-DHT The users of EID-RLOC mappings (e.g., Ingress Tunnel Routers -- ITR) will not necessarily also serve as mapping servers. Indeed, it is actually very likely that network providers will deploy a server infrastructure dedicated to mapping resolution, relieving the routers from the burden of answering mapping requests (this mirrors the DNS system where servers and resolvers play different roles). This situation, however, poses a dilemma: to send a request onto a DHT, a node must have joined the DHT, while every node on the DHT must relay and route DHT messages, manage part of the key space and answer requests for keys in this space. On the one hand, letting routers join the DHT is clearly not an option, as they would fragment and capture part of the mapping space for which they would have no authority, nor sufficient knowledge, to answer requests. On the other hand, using a router's local mapping server (i.e., the mapping server that manages the mappings for addresses local to the router's network) as a proxy onto the DHT poses a reliability issue: if the local mapping server becomes unavailable, the corresponding ITRs would become unable to find new EID-RLOC mappings (even when those mappings could reside on multiple mapping servers that are distant and alive). To solve this problem, we propose to use the concept of Stealth DHT [brampton-stealth:2006]. A stealth DHT separates the nodes on the DHT ring into two distinct types: 1. the service nodes, which behave like fully-fledge DHT nodes, 2. the stealth nodes, which can inject messages onto the DHT, but are never used for routing or key management. Stealth DHT works on the observation that the joining procedure of a DHT is composed of two distinct phases: 1. a state gathering phase at the end of which the joining node will have received enough information (e.g., routing, etc) to take part in the DHT; 2. an announcement phase through which the joining node advertises its presence to other nodes in the DHT and acquires part of the key space. Service nodes complete both of these phases, while stealth nodes only complete the state gathering phase. In Chord, this would mean that Mathy, et al. Expires August 28, 2008 [Page 8] Internet-Draft LISP-DHT February 2008 stealth nodes would acquire successor and predecessor pointers, as well a finger tables, but they would never appear as predecessor, successor or in finger tables of any other nodes (service and stealth nodes alike). In other words, the stealth nodes, which in our case are ITRs and ETRs, do have all the necessary information to inject messages into the DHT (e.g., Map-Request, see Section 5) efficiently (without single point of failure), but will never receive any DHT requests or be used for relaying messages. As a result, stealth nodes cannot store key (i.e. EID-RLOC mappings) nor reply to any request sent into the DHT. In an EID-RLOC mapping scenario, the role of the respective types of nodes can be enforced by the use of credentials. Without appropriate proof of credential (e.g. certificate of authority or of authority transfer) a node would only be allowed to complete the state gathering phase. Mathy, et al. Expires August 28, 2008 [Page 9] Internet-Draft LISP-DHT February 2008 5. LISP-DHT Queries/Replies Ultimately, the purpose of the LISP-DHT is to provide, upon explicit queries, the mapping between a given EID to its corresponding RLOCs (there may be several RLOCs associated with an EID in the case of multihoming). For this purpose the Map-Request and Map-Reply messages as defined by LISP in [I-D.farinacci-lisp] can be used. An ITR router will issue a Map-Request onto the DHT (as a stealth client) if an EID-to-RLOC lookup is needed and cannot be answered from its local cache. LISP- DHT will reply with the correct mapping in a Map-Reply message. However, in order to increase security and reduce the spoofing possibilities, we will extend these messages to ensure that the received answer is genuine. In this aim the lookup reply should be signed by the authoritative server for the mapping. All lookup replies should therefore be of the form: reply = (EID, RLOC list, expiry, C_auth) lookup_reply = (reply, Epriv(server, H(reply))) where server is the authoritative server. It is important to note that these signed mapping entries can be pre- calculated prior to publication on the DHT. In other words, the authoritative server only needs to perform the expensive signing operations once for each entry. Note that if the owner of an EID-prefix decides to change the authoritative server for this prefix, all mappings, as well as all certificate of authority transfer to members of the redundancy group must be re-issued. To re-issue a mapping, it may first have to be removed from the DHT (with the use of the appropriate remove DHT service by the previous authoritative server or owner). Mathy, et al. Expires August 28, 2008 [Page 10] Internet-Draft LISP-DHT February 2008 6. LISP-DHT Robustness For increased reliability, several copies of a mapping should be somehow present on the Chord ring, in case the authoritative server for that mapping fails. The classical approach to this problem on DHTs, is to replicate key-value pairs on nodes neighboring the node that owns them. However, such an approach would violate the second domain's requirements for EID-to-RLOC mapping: the domain, who can't choose its neighbors on the ring, would loose control of who is managing its mappings. As an alternative solution meeting the two main domain requirements (i.e., control and redundancy), we propose to build redundancy into the DHT structure itself. We propose to let several Chord entities share a same ChordID and say that such entities form a redundancy group. In other words, all routing information, such as predecessor, successor and finger table information, must now be ready to accommodate and manage several chord entities per ChordID. These entities will be differentiated by their (EID, RLOC) address pairs, used to send the IP packets. When sending a message to a ChordID, a node can choose any of the Chord entities in the redundancy group to be the message recipient. If better redundancy control is required, status information can even be associated with every member of the redundancy group to indicate when and how the member should be used. For instance, a surrogate status could indicate that the node will route and answer requests as ChordID at any time, while a back-up status could indicate that the node will only route and answer requests as ChordID when all the surrogate nodes have left the DHT. The first node of a redundancy group joins the Chord space as a "classic" Chord node (see Section 3). However, the join requests from subsequent redundancy group members trigger a demand for predecessor (resp. successor) update at the node that succeeds (resp. precedes) the joining ChordID on the ring. However, these nodes are aware that some redundant members are already present and should then send to the joining node, a list of (some) other known nodes in the redundancy group (and the corresponding certificates proving the "authority" of the nodes (if need be), see C_auth above and C_tran below), along with the required routing information. The successor and predecessor of the joining node will add information about this node in their Chord routing information, but will of course refrain from deleting their existing information (existing Chord routing information is only changed when the joining node is the first to join at the specified ChordID). In general, to facilitate management of structural information, Mathy, et al. Expires August 28, 2008 [Page 11] Internet-Draft LISP-DHT February 2008 members of a redundancy group should implement a distributed monitoring and structural information data exchange protocol, based on gossiping for instance, through which they not only cooperatively monitor each other's availability, but also propagate known changes to the redundancy group (such as the addition or removal of a member) and to the routing information (such as the addition of a new successor). The key-value pairs (in our case EID-to-RLOC mappings) are exchanged from the authoritative server for the EID block to members of its redundancy group by an out-of-band method (i.e. these are not published onto the DHT as PUT requests). In cases like EID-RLOC mappings, where tight control may be needed over which nodes can join as a member in a redundancy group, a mechanism for node credentials will be required. Building on the concept of "certificate of authority" (section Section 3), the authoritative server for an EID block can issue members of the corresponding redundancy group with "certificate of authority transfer": M_tran = (ChordID, member, C_auth, expiry) C_tran = (M_tran, Epriv(server, H(M_tran))) where member is a description of the redundancy group member (i.e. the (EID, RLOC) pair), and server the description of the authoritative server. Mathy, et al. Expires August 28, 2008 [Page 12] Internet-Draft LISP-DHT February 2008 7. Conclusion In this draft, we have proposed a new mechanism to map identifiers onto locators based on the utilization of Distributed Hash Tables (DHTs). We have first shown that such a mechanism should meet the control and redundancy requirements of network operators. We have then proposed several extensions to the Chord DHT to allow it to meet these requirements. Future versions of this memo will include a description of the LISP- DHT protocol, a description of the bootstrap phase, and an analysis of possible security threats. Mathy, et al. Expires August 28, 2008 [Page 13] Internet-Draft LISP-DHT February 2008 8. Acknowledgements The work described in the present memo has been partially supported by the European Commission within the IST AGAVE Project. Laurent Mathy's work was partially done while visiting UCLouvain. Mathy, et al. Expires August 28, 2008 [Page 14] Internet-Draft LISP-DHT February 2008 9. IANA Considerations This memo is a first draft of a mapping distribution system for LISP and at this stage does not include any specific request to IANA. . Mathy, et al. Expires August 28, 2008 [Page 15] Internet-Draft LISP-DHT February 2008 10. Security Considerations The security issues, specific to LISP are described [I-D.farinacci-lisp] and [I-D.bagnulo-lisp-threat]. Possible security concerns can arise from the LISP-DHT protocol itself, but these should be very limited due to the use of digital certificates to sign LISP-DHT messages. A thorough analysis of possible security threats will be provided in future versions of the present draft. Mathy, et al. Expires August 28, 2008 [Page 16] Internet-Draft LISP-DHT February 2008 Appendix A. Terms Definition The present draft uses the following terms originally defined in [I-D.farinacci-lisp]. The terms are reported hereafter only as a recall. Routing Locator (RLOC): the IPv4 or IPv6 address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Endpoint ID (EID): a 32- or 128-bit value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains an destination address today, for example through a DNS lookup or SIP exchange. The source EID is obtained via existing mechanisms used to set a hosts "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site the host is attached to. An EID can be used by a host to refer to other hosts. LISP uses PI blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. EID-prefix: A power-of-2 block of EIDs which are allocated to a site by an address allocation authority. EID-prefixes are associated with a set of RLOC addresses which make up a "database mapping". EID-prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the smaller EID- prefix. End-system: is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP header when communicating globally (i.e. outside of it's routing domain). An end-system can be a host computer, a switch or router device, or any network appliance. An iPhone. Mathy, et al. Expires August 28, 2008 [Page 17] Internet-Draft LISP-DHT February 2008 Ingress Tunnel Router (ITR): a router which accepts an IP packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its globally-routable RLOCs in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC may be an intermediate, proxy device that has better knowledge of the EID- to-RLOC mapping closest to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP- encapsulated IP packets toward the Internet on the other side. Egress Tunnel Router (ETR): a router that accepts an IP packet where destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well. Mathy, et al. Expires August 28, 2008 [Page 18] Internet-Draft LISP-DHT February 2008 11. Informative References [I-D.bagnulo-lisp-threat] Bagnulo, M., "Preliminary LISP Threat Analysis", draft-bagnulo-lisp-threat-01 (work in progress), July 2007. [I-D.curran-lisp-emacs] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID Mappings Multicast Across Cooperating Systems for LISP", draft-curran-lisp-emacs-00 (work in progress), November 2007. [I-D.farinacci-lisp] Farinacci, D., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-05 (work in progress), November 2007. [I-D.farinacci-lisp-03] Farinacci, D., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-03 (work in progress), August 2007. [I-D.fuller-lisp-alt] Farinacci, D., "LISP Alternative Topology (LISP-ALT)", draft-fuller-lisp-alt-01 (work in progress), November 2007. [I-D.iab-raws-report] Meyer, D., "Report from the IAB Workshop on Routing and Addressing", draft-iab-raws-report-02 (work in progress), April 2007. [I-D.ietf-sidr-res-certs] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs-09 (work in progress), November 2007. [I-D.irtf-rrg-design-goals] Li, T., "Design Goals for Scalable Internet Routing", draft-irtf-rrg-design-goals-01 (work in progress), July 2007. [I-D.lear-lisp-nerd] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-03 (work in progress), January 2008. [I-D.meyer-lisp-cons] Brim, S., "LISP-CONS: A Content distribution Overlay Mathy, et al. Expires August 28, 2008 [Page 19] Internet-Draft LISP-DHT February 2008 Network Service for LISP", draft-meyer-lisp-cons-03 (work in progress), November 2007. [QUOITIN07] Quoitin, B., Iannone, L., de Launois, C., and O. Bonaventure, "Evaluating the Benefits of the Locator/ Identifier Separation.", The 2nd ACM International Workshop on Mobility in the Evolving Internet Architecture (MobiArch'07), 2007. [brampton-stealth:2006] Brampton, A., MacQuire, A., Rai, I., Race, N., and L. Mathy, "Stealth Distributed Hash Table: A robust and flexible super-peered DHT", 2nd Conference on Future Networking Technologies (CoNEXT'06) Lisbon, Portugal, 2006. [stoica-chord:2003] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup Protocol for Internet Applications", IEEE/ACM Transactions on Networking Vol. 11, No. 1, pp. 17-32, 2003. Mathy, et al. Expires August 28, 2008 [Page 20] Internet-Draft LISP-DHT February 2008 Authors' Addresses Laurent Mathy Lancaster University Computing Department InfoLab 21 South Drive Lancaster University Lancaster, LA1 4WA United Kingdom Email: laurent@comp.lancs.ac.uk URI: http://www.comp.lancs.ac.uk/ Luigi Iannone UCLouvain IP Network Lab, UCL/INGI, Place St. Barbe 2 Louvain la Neuve, B-1348 Belgium Email: luigi.iannone@uclouvain.be URI: http://inl.info.ucl.ac.be Olivier Bonaventure UCLouvain IP Networking Lab, UCL/INGI, Place St. Barbe 2 Louvain la Neuve, B-1348 Belgium URI: http://inl.info.ucl.ac.be Mathy, et al. Expires August 28, 2008 [Page 21] Internet-Draft LISP-DHT February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Mathy, et al. Expires August 28, 2008 [Page 22]