diff options
Diffstat (limited to 'doc/rfc/rfc6833.txt')
| -rw-r--r-- | doc/rfc/rfc6833.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc6833.txt b/doc/rfc/rfc6833.txt new file mode 100644 index 0000000..2780f6a --- /dev/null +++ b/doc/rfc/rfc6833.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) V. Fuller +Request for Comments: 6833 +Category: Experimental D. Farinacci +ISSN: 2070-1721 Cisco Systems + January 2013 + + + Locator/ID Separation Protocol (LISP) Map-Server Interface + +Abstract + + This document describes the Mapping Service for the Locator/ID + Separation Protocol (LISP), implemented by two new types of LISP- + speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that + provides a simplified "front end" for one or more Endpoint ID to + Routing Locator mapping databases. + + By using this service interface and communicating with Map-Resolvers + and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel + Routers are not dependent on the details of mapping database systems, + which facilitates experimentation with different database designs. + Since these devices implement the "edge" of the LISP infrastructure, + connect directly to LISP-capable Internet end sites, and comprise the + bulk of LISP-speaking devices, reducing their implementation and + operational complexity should also reduce the overall cost and effort + of deploying LISP. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6833. + + + + + + + +Fuller & Farinacci Experimental [Page 1] + +RFC 6833 LISP Map-Server Interface January 2013 + + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Definition of Terms .............................................3 + 3. Basic Overview ..................................................4 + 4. Interactions with Other LISP Components .........................5 + 4.1. ITR EID-to-RLOC Mapping Resolution .........................5 + 4.2. EID-Prefix Configuration and ETR Registration ..............6 + 4.3. Map-Server Processing ......................................8 + 4.4. Map-Resolver Processing ....................................9 + 4.4.1. Anycast Map-Resolver Operation .....................10 + 5. Open Issues and Considerations .................................10 + 6. Security Considerations ........................................11 + 7. References .....................................................12 + 7.1. Normative References ......................................12 + 7.2. Informative References ....................................12 + Appendix A. Acknowledgments .......................................13 + +1. Introduction + + The Locator/ID Separation Protocol [RFC6830] specifies an + architecture and mechanism for replacing the addresses currently used + by IP with two separate name spaces: Endpoint IDs (EIDs), used within + sites; and Routing Locators (RLOCs), used on the transit networks + that make up the Internet infrastructure. To achieve this + separation, LISP defines protocol mechanisms for mapping from EIDs to + RLOCs. In addition, LISP assumes the existence of a database to + store and propagate those mappings globally. Several such databases + have been proposed; among them are the Content distribution Overlay + Network Service for LISP (LISP-CONS) [LISP-CONS], LISP-NERD + (a Not-so-novel EID-to-RLOC Database) [RFC6837], and LISP Alternative + Logical Topology (LISP+ALT) [RFC6836]. + + + + +Fuller & Farinacci Experimental [Page 2] + +RFC 6833 LISP Map-Server Interface January 2013 + + + The LISP Mapping Service defines two new types of LISP-speaking + devices: the Map-Resolver, which accepts Map-Requests from an Ingress + Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a + mapping database; and the Map-Server, which learns authoritative + EID-to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes + them in a database. + + Conceptually, LISP Map-Servers share some of the same basic + configuration and maintenance properties as Domain Name System (DNS) + [RFC1035] servers; likewise, Map-Resolvers are conceptually similar + to DNS caching resolvers. With this in mind, this specification + borrows familiar terminology (resolver and server) from the DNS + specifications. + + Note that while this document assumes a LISP+ALT database mapping + infrastructure to illustrate certain aspects of Map-Server and + Map-Resolver operation, the Mapping Service interface can (and likely + will) be used by ITRs and ETRs to access other mapping database + systems as the LISP infrastructure evolves. + + Section 5 of this document notes a number of issues with the + Map-Server and Map-Resolver design that are not yet completely + understood and are subjects of further experimentation. + + The LISP Mapping Service is an important component of the LISP + toolset. Issues and concerns about the deployment of LISP for + Internet traffic are discussed in [RFC6830]. + +2. Definition of Terms + + Map-Server: A network infrastructure component that learns of + EID-Prefix mapping entries from an ETR, via the registration + mechanism described below, or some other authoritative source if + one exists. A Map-Server publishes these EID-Prefixes in a + mapping database. + + Map-Resolver: A network infrastructure component that accepts LISP + Encapsulated Map-Requests, typically from an ITR, and determines + whether or not the destination IP address is part of the EID + namespace; if it is not, a Negative Map-Reply is returned. + Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC + mapping by consulting a mapping database system. + + + + + + + + + +Fuller & Farinacci Experimental [Page 3] + +RFC 6833 LISP Map-Server Interface January 2013 + + + Encapsulated Map-Request: A LISP Map-Request carried within an + Encapsulated Control Message, which has an additional LISP header + prepended. Sent to UDP destination port 4342. The "outer" + addresses are globally routable IP addresses, also known as RLOCs. + Used by an ITR when sending to a Map-Resolver and by a Map-Server + when forwarding a Map-Request to an ETR. + + Negative Map-Reply: A LISP Map-Reply that contains an empty + Locator-Set. Returned in response to a Map-Request if the + destination EID does not exist in the mapping database. + Typically, this means that the "EID" being requested is an IP + address connected to a non-LISP site. + + Map-Register message: A LISP message sent by an ETR to a Map-Server + to register its associated EID-Prefixes. In addition to the set + of EID-Prefixes to register, the message includes one or more + RLOCs to be used by the Map-Server when forwarding Map-Requests + (re-formatted as Encapsulated Map-Requests) received through the + database mapping system. An ETR may request that the Map-Server + answer Map-Requests on its behalf by setting the "proxy Map-Reply" + flag (P-bit) in the message. + + Map-Notify message: A LISP message sent by a Map-Server to an ETR + to confirm that a Map-Register has been received and processed. + An ETR requests that a Map-Notify be returned by setting the + "want-map-notify" flag (M-bit) in the Map-Register message. + Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both + source and destination. + + For definitions of other terms -- notably Map-Request, Map-Reply, + Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please + consult the LISP specification [RFC6830]. + +3. Basic Overview + + A Map-Server is a device that publishes EID-Prefixes in a LISP + mapping database on behalf of a set of ETRs. When it receives a Map + Request (typically from an ITR), it consults the mapping database to + find an ETR that can answer with the set of RLOCs for an EID-Prefix. + To publish its EID-Prefixes, an ETR periodically sends Map-Register + messages to the Map-Server. A Map-Register message contains a list + of EID-Prefixes plus a set of RLOCs that can be used to reach the ETR + when a Map-Server needs to forward a Map-Request to it. + + + + + + + + +Fuller & Farinacci Experimental [Page 4] + +RFC 6833 LISP Map-Server Interface January 2013 + + + When LISP+ALT is used as the mapping database, a Map-Server connects + to the ALT network and acts as a "last-hop" ALT-Router. Intermediate + ALT-Routers forward Map-Requests to the Map-Server that advertises a + particular EID-Prefix, and the Map-Server forwards them to the owning + ETR, which responds with Map-Reply messages. + + A Map-Resolver receives Encapsulated Map-Requests from its client + ITRs and uses a mapping database system to find the appropriate ETR + to answer those requests. On a LISP+ALT network, a Map-Resolver acts + as a "first-hop" ALT-Router. It has Generic Routing Encapsulation + (GRE) tunnels configured to other ALT-Routers and uses BGP to learn + paths to ETRs for different prefixes in the LISP+ALT database. The + Map-Resolver uses this path information to forward Map-Requests over + the ALT to the correct ETRs. + + Note that while it is conceivable that a Map-Resolver could cache + responses to improve performance, issues surrounding cache management + will need to be resolved so that doing so will be reliable and + practical. As initially deployed, Map-Resolvers will operate only in + a non-caching mode, decapsulating and forwarding Encapsulated Map + Requests received from ITRs. Any specification of caching + functionality is left for future work. + + Note that a single device can implement the functions of both a + Map-Server and a Map-Resolver, and in many cases the functions will + be co-located in that way. + + Detailed descriptions of the LISP packet types referenced by this + document may be found in [RFC6830]. + +4. Interactions with Other LISP Components + +4.1. ITR EID-to-RLOC Mapping Resolution + + An ITR is configured with one or more Map-Resolver addresses. These + addresses are "Locators" (or RLOCs) and must be routable on the + underlying core network; they must not need to be resolved through + LISP EID-to-RLOC mapping, as that would introduce a circular + dependency. When using a Map-Resolver, an ITR does not need to + connect to any other database mapping system. In particular, the ITR + need not connect to the LISP+ALT infrastructure or implement the BGP + and GRE protocols that it uses. + + An ITR sends an Encapsulated Map-Request to a configured Map-Resolver + when it needs an EID-to-RLOC mapping that is not found in its local + map-cache. Using the Map-Resolver greatly reduces both the + complexity of the ITR implementation and the costs associated with + its operation. + + + +Fuller & Farinacci Experimental [Page 5] + +RFC 6833 LISP Map-Server Interface January 2013 + + + In response to an Encapsulated Map-Request, the ITR can expect one of + the following: + + o An immediate Negative Map-Reply (with action code of + "Natively-Forward", 15-minute Time to Live (TTL)) from the + Map-Resolver if the Map-Resolver can determine that the requested + EID does not exist. The ITR saves the EID-Prefix returned in the + Map-Reply in its cache, marks it as non-LISP-capable, and knows + not to attempt LISP encapsulation for destinations matching it. + + o A Negative Map-Reply, with action code of "Natively-Forward", from + a Map-Server that is authoritative for an EID-Prefix that matches + the requested EID but that does not have an actively registered, + more-specific ID-prefix. In this case, the requested EID is said + to match a "hole" in the authoritative EID-Prefix. If the + requested EID matches a more-specific EID-Prefix that has been + delegated by the Map-Server but for which no ETRs are currently + registered, a 1-minute TTL is returned. If the requested EID + matches a non-delegated part of the authoritative EID-Prefix, then + it is not a LISP EID and a 15-minute TTL is returned. See + Section 4.2 for discussion of aggregate EID-Prefixes and details + of Map-Server EID-Prefix matching. + + o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or + possibly from a Map-Server answering on behalf of the ETR. See + Section 4.4 for more details on Map-Resolver message processing. + + Note that an ITR may be configured to both use a Map-Resolver and to + participate in a LISP+ALT logical network. In such a situation, the + ITR should send Map-Requests through the ALT network for any + EID-Prefix learned via ALT BGP. Such a configuration is expected to + be very rare, since there is little benefit to using a Map-Resolver + if an ITR is already using LISP+ALT. There would be, for example, no + need for such an ITR to send a Map-Request to a possibly non-existent + EID (and rely on Negative Map-Replies) if it can consult the ALT + database to verify that an EID-Prefix is present before sending that + Map-Request. + +4.2. EID-Prefix Configuration and ETR Registration + + An ETR publishes its EID-Prefixes on a Map-Server by sending LISP + Map-Register messages. A Map-Register message includes + authentication data, so prior to sending a Map-Register message, the + ETR and Map-Server must be configured with a shared secret or other + relevant authentication information. A Map-Server's configuration + must also include a list of the EID-Prefixes for which each ETR is + authoritative. Upon receipt of a Map-Register from an ETR, a + Map-Server accepts only EID-Prefixes that are configured for that + + + +Fuller & Farinacci Experimental [Page 6] + +RFC 6833 LISP Map-Server Interface January 2013 + + + ETR. Failure to implement such a check would leave the mapping + system vulnerable to trivial EID-Prefix hijacking attacks. As + developers and operators gain experience with the mapping system, + additional, stronger security measures may be added to the + registration process. + + In addition to the set of EID-Prefixes defined for each ETR that may + register, a Map-Server is typically also configured with one or more + aggregate prefixes that define the part of the EID numbering space + assigned to it. When LISP+ALT is the database in use, aggregate + EID-Prefixes are implemented as discard routes and advertised into + ALT BGP. The existence of aggregate EID-Prefixes in a Map-Server's + database means that it may receive Map Requests for EID-Prefixes that + match an aggregate but do not match a registered prefix; Section 4.3 + describes how this is handled. + + Map-Register messages are sent periodically from an ETR to a + Map-Server with a suggested interval between messages of one minute. + A Map-Server should time out and remove an ETR's registration if it + has not received a valid Map-Register message within the past + three minutes. When first contacting a Map-Server after restart or + changes to its EID-to-RLOC database mappings, an ETR may initially + send Map-Register messages at an increased frequency, up to one every + 20 seconds. This "quick registration" period is limited to + five minutes in duration. + + An ETR may request that a Map-Server explicitly acknowledge receipt + and processing of a Map-Register message by setting the + "want-map-notify" (M-bit) flag. A Map-Server that receives a + Map-Register with this flag set will respond with a Map-Notify + message. Typical use of this flag by an ETR would be to set it for + Map-Register messages sent during the initial "quick registration" + with a Map-Server but then set it only occasionally during + steady-state maintenance of its association with that Map-Server. + Note that the Map-Notify message is sent to UDP destination port + 4342, not to the source port specified in the original Map-Register + message. + + Note that a one-minute minimum registration interval during + maintenance of an ETR-Map-Server association places a lower bound on + how quickly and how frequently a mapping database entry can be + updated. This may have implications for what sorts of mobility can + be supported directly by the mapping system; shorter registration + intervals or other mechanisms might be needed to support faster + mobility in some cases. For a discussion on one way that faster + mobility may be implemented for individual devices, please see + [LISP-MN]. + + + + +Fuller & Farinacci Experimental [Page 7] + +RFC 6833 LISP Map-Server Interface January 2013 + + + An ETR may also request, by setting the "proxy Map-Reply" flag + (P-bit) in the Map-Register message, that a Map-Server answer + Map-Requests instead of forwarding them to the ETR. See [RFC6830] + for details on how the Map-Server sets certain flags (such as those + indicating whether the message is authoritative and how returned + Locators should be treated) when sending a Map-Reply on behalf of an + ETR. When an ETR requests proxy reply service, it should include all + RLOCs for all ETRs for the EID-Prefix being registered, along with + the routable flag ("R-bit") setting for each RLOC. The Map-Server + includes all of this information in Map-Reply messages that it sends + on behalf of the ETR. This differs from a non-proxy registration, + since the latter need only provide one or more RLOCs for a Map-Server + to use for forwarding Map-Requests; the registration information is + not used in Map-Replies, so it being incomplete is not incorrect. + + An ETR that uses a Map-Server to publish its EID-to-RLOC mappings + does not need to participate further in the mapping database + protocol(s). When using a LISP+ALT mapping database, for example, + this means that the ETR does not need to implement GRE or BGP, which + greatly simplifies its configuration and reduces its cost of + operation. + + Note that use of a Map-Server does not preclude an ETR from also + connecting to the mapping database (i.e., it could also connect to + the LISP+ALT network), but doing so doesn't seem particularly useful, + as the whole purpose of using a Map-Server is to avoid the complexity + of the mapping database protocols. + +4.3. Map-Server Processing + + Once a Map-Server has EID-Prefixes registered by its client ETRs, it + can accept and process Map-Requests for them. + + In response to a Map-Request (received over the ALT if LISP+ALT is in + use), the Map-Server first checks to see if the destination EID + matches a configured EID-Prefix. If there is no match, the + Map-Server returns a Negative Map-Reply with action code + "Natively-Forward" and a 15-minute TTL. This may occur if a Map + Request is received for a configured aggregate EID-Prefix for which + no more-specific EID-Prefix exists; it indicates the presence of a + non-LISP "hole" in the aggregate EID-Prefix. + + Next, the Map-Server checks to see if any ETRs have registered the + matching EID-Prefix. If none are found, then the Map-Server returns + a Negative Map-Reply with action code "Natively-Forward" and a + 1-minute TTL. + + + + + +Fuller & Farinacci Experimental [Page 8] + +RFC 6833 LISP Map-Server Interface January 2013 + + + If any of the registered ETRs for the EID-Prefix have requested proxy + reply service, then the Map-Server answers the request instead of + forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, + and other information learned through the registration process. + + If none of the ETRs have requested proxy reply service, then the + Map-Server re-encapsulates and forwards the resulting Encapsulated + Map-Request to one of the registered ETRs. It does not otherwise + alter the Map-Request, so any Map-Reply sent by the ETR is returned + to the RLOC in the Map-Request, not to the Map-Server. Unless also + acting as a Map-Resolver, a Map-Server should never receive + Map-Replies; any such messages should be discarded without response, + perhaps accompanied by the logging of a diagnostic message if the + rate of Map-Replies is suggestive of malicious traffic. + +4.4. Map-Resolver Processing + + Upon receipt of an Encapsulated Map-Request, a Map-Resolver + decapsulates the enclosed message and then searches for the requested + EID in its local database of mapping entries (statically configured + or learned from associated ETRs if the Map-Resolver is also a + Map-Server offering proxy reply service). If it finds a matching + entry, it returns a LISP Map-Reply with the known mapping. + + If the Map-Resolver does not have the mapping entry and if it can + determine that the EID is not in the mapping database (for example, + if LISP+ALT is used, the Map-Resolver will have an ALT forwarding + table that covers the full EID space), it immediately returns a + negative LISP Map-Reply, with action code "Natively-Forward" and a + 15-minute TTL. To minimize the number of negative cache entries + needed by an ITR, the Map-Resolver should return the least-specific + prefix that both matches the original query and does not match any + EID-Prefix known to exist in the LISP-capable infrastructure. + + If the Map-Resolver does not have sufficient information to know + whether the EID exists, it needs to forward the Map-Request to + another device that has more information about the EID being + requested. To do this, it forwards the unencapsulated Map-Request, + with the original ITR RLOC as the source, to the mapping database + system. Using LISP+ALT, the Map-Resolver is connected to the ALT + network and sends the Map-Request to the next ALT hop learned from + its ALT BGP neighbors. The Map-Resolver does not send any response + to the ITR; since the source RLOC is that of the ITR, the ETR or + Map-Server that receives the Map-Request over the ALT and responds + will do so directly to the ITR. + + + + + + +Fuller & Farinacci Experimental [Page 9] + +RFC 6833 LISP Map-Server Interface January 2013 + + +4.4.1. Anycast Map-Resolver Operation + + A Map-Resolver can be set up to use "anycast", where the same address + is assigned to multiple Map-Resolvers and is propagated through IGP + routing, to facilitate the use of a topologically close Map-Resolver + by each ITR. + + Note that Map-Server associations with ETRs should not use anycast + addresses, as registrations need to be established between an ETR and + a specific set of Map-Servers, each identified by a specific + registration association. + +5. Open Issues and Considerations + + There are a number of issues with the Map-Server and Map-Resolver + design that are not yet completely understood. Among these are: + + o Constants, such as those used for Map-Register frequency, + retransmission timeouts, retransmission limits, Negative Map-Reply + TTLs, et al. are subject to further refinement as more experience + with prototype deployment is gained. + + o Convergence time when an EID-to-RLOC mapping changes, and + mechanisms for detecting and refreshing or removing stale, cached + information. + + o Deployability and complexity tradeoffs of implementing stronger + security measures in both EID-Prefix registration and Map-Request/ + Map-Reply processing. + + o Requirements for additional state in the registration process + between Map-Servers and ETRs. + + A discussion of other issues surrounding LISP deployment may also be + found in Section 15 of [RFC6830]. + + The authors expect that experimentation on the LISP pilot network + will help answer open questions surrounding these and other issues. + + + + + + + + + + + + + +Fuller & Farinacci Experimental [Page 10] + +RFC 6833 LISP Map-Server Interface January 2013 + + +6. Security Considerations + + The 2-way LISP header nonce exchange documented in [RFC6830] can be + used to avoid ITR spoofing attacks. + + To publish an authoritative EID-to-RLOC mapping with a Map-Server, an + ETR includes authentication data that is a hash of the message using + a pair-wise shared key. An implementation must support use of + HMAC-SHA-1-96 [RFC2104] and should support use of HMAC-SHA-256-128 + [RFC6234] (SHA-256 truncated to 128 bits). + + During experimental and prototype deployment, all authentication key + configuration will be manual. Should LISP and its components be + considered for IETF standardization, further work will be required to + follow the BCP 107 [RFC4107] recommendations on automated key + management. + + As noted in Section 4.2, a Map-Server should verify that all + EID-Prefixes registered by an ETR match the configuration stored on + the Map-Server. + + The currently defined authentication mechanism for Map-Register + messages does not provide protection against "replay" attacks by a + "man-in-the-middle". Additional work is needed in this area. + + [LISP-SEC] defines a proposed mechanism for providing origin + authentication, integrity, anti-replay protection, and prevention of + man-in-the-middle and "overclaiming" attacks on the Map-Request/ + Map-Reply exchange. Work is ongoing on this and other proposals for + resolving these open security issues. + + While beyond the scope of securing an individual Map-Server or + Map-Resolver, it should be noted that a BGP-based LISP+ALT network + (if ALT is used as the mapping database infrastructure) can take + advantage of standards work on adding security to BGP. + + + + + + + + + + + + + + + + +Fuller & Farinacci Experimental [Page 11] + +RFC 6833 LISP Map-Server Interface January 2013 + + +7. References + +7.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms + (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. + + [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The + Locator/ID Separation Protocol (LISP)", RFC 6830, + January 2013. + + [RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, + "Locator/ID Separation Protocol Alternative Logical + Topology (LISP+ALT)", RFC 6836, January 2013. + +7.2. Informative References + + [LISP-CONS] Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, + D., and D. Meyer, "LISP-CONS: A Content distribution + Overlay Network Service for LISP", Work in Progress, + April 2008. + + [LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP + Mobile Node", Work in Progress, October 2012. + + [LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., Saucez, D., and O. + Bonaventure, "LISP-Security (LISP-SEC)", Work + in Progress, October 2012. + + [RFC4107] Bellovin, S. and R. Housley, "Guidelines for + Cryptographic Key Management", BCP 107, RFC 4107, + June 2005. + + [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to + Routing Locator (RLOC) Database", RFC 6837, + January 2013. + + + + + + + + +Fuller & Farinacci Experimental [Page 12] + +RFC 6833 LISP Map-Server Interface January 2013 + + +Appendix A. Acknowledgments + + The authors would like to thank Gregg Schudel, Darrel Lewis, John + Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, + Fabio Maino, and members of the lisp@ietf.org mailing list for their + feedback and helpful suggestions. + + Special thanks are due to Noel Chiappa for his extensive work on + caching with LISP-CONS, some of which may be used by Map-Resolvers. + +Authors' Addresses + + Vince Fuller + + EMail: vaf@vaf.net + + + Dino Farinacci + Cisco Systems + Tasman Drive + San Jose, CA 95134 + USA + + EMail: farinacci@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fuller & Farinacci Experimental [Page 13] + |