diff options
Diffstat (limited to 'doc/rfc/rfc6835.txt')
| -rw-r--r-- | doc/rfc/rfc6835.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc6835.txt b/doc/rfc/rfc6835.txt new file mode 100644 index 0000000..6311fb2 --- /dev/null +++ b/doc/rfc/rfc6835.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Farinacci +Request for Comments: 6835 D. Meyer +Category: Informational Cisco Systems +ISSN: 2070-1721 January 2013 + + + The Locator/ID Separation Protocol Internet Groper (LIG) + +Abstract + + A simple tool called the Locator/ID Separation Protocol (LISP) + Internet Groper or 'lig' can be used to query the LISP mapping + database. This document describes how it works. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + 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/rfc6835. + +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. + + + + + + + +Farinacci & Meyer Informational [Page 1] + +RFC 6835 LISP Internet Groper (LIG) January 2013 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 + 3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Implementation Details . . . . . . . . . . . . . . . . . . . . 6 + 4.1. LISP Router Implementation . . . . . . . . . . . . . . . . 6 + 4.2. Public Domain Host Implementation . . . . . . . . . . . . 8 + 5. Testing the ALT . . . . . . . . . . . . . . . . . . . . . . . 9 + 6. Future Enhancements . . . . . . . . . . . . . . . . . . . . . 10 + 7. Deployed Network Diagnostic Tools . . . . . . . . . . . . . . 10 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 + +1. Introduction + + The Locator/ID Separation Protocol [RFC6830] specifies an + architecture and mechanism for replacing the addresses currently used + by IP with two separate namespaces: 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: a Content distribution Overlay + Network Service for LISP [LISP-CONS], a Not-so-novel EID-to-RLOC + Database (LISP-NERD) [RFC6837], and LISP Alternative Topology (LISP+ + ALT) [RFC6836], with LISP+ALT being the system that is currently + being implemented and deployed on the pilot LISP network. + + In conjunction with the various mapping systems, there exists a + network-based API called LISP Map-Server [RFC6833]. Using Map- + Resolvers and Map-Servers allows LISP sites to query and register + into the database in a uniform way independent of the mapping system + used. Sending Map-Requests to Map-Resolvers provides a secure + mechanism to obtain a Map-Reply containing the authoritative EID-to- + RLOC mapping for a destination LISP site. + + The 'lig' is a manual management tool to query the mapping database. + It can be run by all devices that implement LISP, including Ingress + Tunnel Routers (ITRs), Egress Tunnel Routers (ETRs), Proxy-ITRs, + Proxy-ETRs, Map-Resolvers, Map-Servers, and LISP-ALT Routers, as well + as by a host system at either a LISP-capable or non-LISP-capable + site. + + + + +Farinacci & Meyer Informational [Page 2] + +RFC 6835 LISP Internet Groper (LIG) January 2013 + + + The mapping database system is typically a public database used for + wide-range connectivity across Internet sites. The information in + the public database is purposely not kept private so it can be + generally accessible for public use. + +2. Definition of Terms + + Map-Server: a network infrastructure component that learns EID-to- + RLOC mapping entries from an authoritative source (typically, an + ETR, though static configuration or another out-of-band mechanism + may be used). A Map-Server advertises these mappings in the + distributed mapping database. + + Map-Resolver: a network infrastructure component that accepts LISP + Encapsulated Map-Requests, typically from an ITR, quickly + determines whether or not the destination IP address is part of + the EID namespace; if it is not, a Negative Map-Reply is + immediately returned. Otherwise, the Map-Resolver finds the + appropriate EID-to-RLOC mapping by consulting the distributed + mapping database system. + + Routing Locator (RLOC): the IPv4 or IPv6 address of an Egress + Tunnel Router (ETR). It is the output of an 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. Thus, the topology is defined by the connectivity of + provider networks, and RLOCs can be thought of as Provider- + Assigned (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-bit (for IPv4) or 128-bit (for IPv6) 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 a destination address + today, for example, through a DNS lookup. The source EID is + obtained via existing mechanisms used to set a host's "local" IP + address. An EID is allocated to a host from an EID-prefix block + associated with the site where the host is located. An EID can be + used by a host to refer to other hosts. 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. + + + + + +Farinacci & Meyer Informational [Page 3] + +RFC 6835 LISP Internet Groper (LIG) January 2013 + + + EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that + stores, tracks, and is responsible for timing-out and otherwise + validating EID-to-RLOC mappings. This cache is distinct from the + full "database" of EID-to-RLOC mappings; the cache is dynamic, + local to the ITR(s), and relatively small, while the database is + distributed, relatively static, and much more global in scope. + + EID-to-RLOC Database: a global distributed database that contains + all known EID-prefix to RLOC mappings. Each potential ETR + typically contains a small piece of the database: the EID-to-RLOC + mappings for the EID prefixes "behind" the router. These map to + one of the router's own, globally-visible, IP addresses. + + Encapsulated Map-Request (EMR): an EMR is a Map-Request message + that is encapsulated with another LISP header using UDP + destination port number 4342. It is used so an ITR, PITR, or a + system initiating a 'lig' command can get the Map-Request to a + Map-Resolver by using locator addresses. When the Map-Request is + decapsulated by the Map-Resolver, it will be forwarded on the ALT + network to the Map-Server that has injected the EID-prefix for a + registered site. The Map-Server will then encapsulate the Map- + Request in a LISP packet and send it to an ETR at the site. The + ETR will then return an authoritative reply to the system that + initiated the request. See [RFC6830] for packet format details. + + Ingress Tunnel Router (ITR): An ITR is a router that 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 closer 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): An ETR is a router that accepts an IP + packet where the 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. + + + +Farinacci & Meyer Informational [Page 4] + +RFC 6835 LISP Internet Groper (LIG) January 2013 + + + Proxy-ITR (PITR): A PITR, also known as a PTR, is defined and + described in [RFC6832]. A PITR acts like an ITR but does so on + behalf of non-LISP sites that send packets to destinations at LISP + sites. + + Proxy-ETR (PETR): A PETR is defined and described in [RFC6832]. A + PETR acts like an ETR but does so on behalf of LISP sites that + send packets to destinations at non-LISP sites. + + xTR: An xTR is a reference to an ITR or ETR when direction of data + flow is not part of the context description. xTR refers to the + router that is the tunnel endpoint; it is used synonymously with + the term "tunnel router". For example, "an xTR can be located at + the Customer Edge (CE) router" means that both ITR and ETR + functionality is at the CE router. + + Provider-Assigned (PA) Addresses: PA addresses are an address block + assigned to a site by each service provider to which a site + connects. Typically, each block is a sub-block of a service- + provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and + is aggregated into the larger block before being advertised into + the global Internet. Traditionally, IP multihoming has been + implemented by each multihomed site acquiring its own globally + visible prefix. LISP uses only topologically assigned and + aggregatable address blocks for RLOCs, eliminating this + demonstrably non-scalable practice. + +3. Basic Overview + + When the 'lig' command is run, a Map-Request is sent for a + destination EID. When a Map-Reply is returned, the contents are + displayed to the user. The information displayed includes: + + o The EID-prefix for the site that the queried destination EID + matches. + + o The locator address of the Map Replier. + + o The Locator-Set for the mapping entry, which includes the locator + address, up/down status, priority, and weight of each Locator. + + o A round-trip-time estimate for the Map-Request/Map-Reply exchange. + + A possible syntax for a 'lig' command could be: + + lig <destination> [source <source>] [to <map-resolver>] + + + + + +Farinacci & Meyer Informational [Page 5] + +RFC 6835 LISP Internet Groper (LIG) January 2013 + + + Parameter description: + + <destination>: is either a Fully Qualified Domain Name (FQDN) or a + destination EID for a remote LISP site. + + source <source>: is an optional source EID to be inserted in the + 'Source EID' field of the Map-Request. + + to <map-resolver>: is an optional FQDN or RLOC address for a Map- + Resolver. + + The 'lig' utility has two use cases. The first is a way to query the + mapping database for a particular EID. The other is to verify if a + site has registered successfully with a Map-Server. + + The first usage has already been described. Verifying registration + is called "ligging yourself"; it happens as follows. In the 'lig' + initiator, a Map-Request is sent for one of the EIDs for the 'lig' + initiator's site. The Map-Request is then returned to one of the + ETRs for the 'lig'-initiating site. In response to the Map-Request, + a Map-Reply is sent back to the locator address of the 'lig' + initiator (note the Map-Reply could be sent by the 'lig' initiator). + That Map-Reply is processed, and the mapping data for the 'lig'- + initiating site is displayed for the user. Refer to the syntax in + Section 4.1 for an implementation of "ligging yourself". However, + for host-based implementations within a LISP site, "lig self" is less + useful since the host may not have an RLOC with which to receive a + Map-Reply. But, 'lig' can be used in a non-LISP site, as well as + from infrastructure hosts, to get mapping information. + +4. Implementation Details + +4.1. LISP Router Implementation + + The Cisco LISP prototype implementation has support for 'lig' for + IPv4 and IPv6. The command line description is: + + lig <dest-eid> [source <source-eid>] [to <mr>] [count <1-5>] + + This command initiates the LISP Internet Groper. It is similar to + the DNS analogue 'dig' but works on the LISP mapping database. When + this command is invoked, the local system will send a Map-Request to + the configured Map-Resolver. When a Map-Reply is returned, its + contents will be displayed to the user. By default, up to three Map- + Requests are sent if no Map-Reply is returned, but, once a Map-Reply + is returned, no other Map-Requests are sent. The destination can + take a DNS name, or an IPv4 or IPv6 EID address. The <source-eid> + can be one of the EID addresses assigned to the site in the default + + + +Farinacci & Meyer Informational [Page 6] + +RFC 6835 LISP Internet Groper (LIG) January 2013 + + + Virtual Routing and Forwarding (VRF) table. When <mr> is specified, + then the Map-Request is sent to the address. Otherwise, the Map- + Request is sent to a configured Map-Resolver. When a Map-Resolver is + not configured, then the Map-Request is sent on the ALT network if + the local router is attached to the ALT. When "count <1-5>" is + specified, 1, 2, 3, 4, or 5 Map-Requests are sent. + + Some sample output: + + router# lig abc.example.com + Send map-request to 10.0.0.1 for 192.168.1.1 ... + Received map-reply from 10.0.0.2 with rtt 0.081468 secs + + Map-Cache entry for abc.example.com EID 192.168.1.1: + 192.168.1.0/24, uptime: 13:59:59, expires: 23:59:58, + via map-reply, auth + Locator Uptime State Priority/Weight Packets In/Out + 10.0.0.2 13:59:59 up 1/100 0/14 + + Using 'lig' to "lig yourself" is accomplished with the following + syntax: + + lig {self | self6} [source <source-eid>] [to <mr>] [count <1-5>] + + Use this command for a simple way to see if the site is registered + with the mapping database system. The destination-EID address for + the Map-Request will be the first configured EID-prefix for the site + (with the host bits set to 0). For example, if the site's EID-prefix + is 192.168.1.0/24, the destination-EID for the Map-Request is + 192.168.1.0. The source-EID address for the Map-Request will also be + 192.168.1.0 (in this example), and the Map-Request is sent to the + configured Map-Resolver. If the Map-Resolver and Map-Server are the + same LISP system, then the "lig self" is testing if the Map-Resolver + can "turn back a Map-Request to the site". If another Map-Resolver + is used, it can test that the site's EID-prefix has been injected + into the ALT infrastructure, in which case the 'lig' Map-Request is + processed by the Map-Resolver and propagated through each ALT-Router + hop to the site's registered Map-Server. Then, the Map-Server + returns the Map-Request to the originating site. In that case, an + xTR at the originating site sends a Map-Reply to the source of the + Map-Request (could be itself or another xTR for the site). All other + command parameters are described above. Using "lig self6" tests for + registering of IPv6 EID-prefixes. + + + + + + + + +Farinacci & Meyer Informational [Page 7] + +RFC 6835 LISP Internet Groper (LIG) January 2013 + + + Some sample output for "ligging yourself": + + router# lig self + Send loopback map-request to 10.0.0.1 for 192.168.2.0 ... + Received map-reply from 10.0.0.3 with rtt 0.001592 secs + + Map-Cache entry for EID 192.168.2.0: + 192.168.2.0/24, uptime: 00:00:02, expires: 23:59:57 + via map-reply, self + Locator Uptime State Priority/Weight Packets In/Out + 10.0.0.3 00:00:02 up 1/100 0/0 + + + router# lig self6 + Send loopback map-request to 10.0.0.1 for 2001:db8:1:: ... + Received map-reply from 10::1 with rtt 0.044372 secs + + Map-Cache entry for EID 192:168:1::: + 2001:db8:1::/48, uptime: 00:00:01, expires: 23:59:58 + via map-reply, self + Locator Uptime State Priority/Weight Packets In/Out + 10.0.0.3 00:00:01 up 1/100 0/0 + 2001:db8:ffff::1 00:00:01 up 2/0 0/0 + +4.2. Public Domain Host Implementation + + There is a public domain implementation that can run on any x86-based + system. The only requirement is that the system that initiates 'lig' + must have an address assigned from the locator namespace. + + lig [-d] <eid> -m <map-resolver> [-c <count>] [-t <timeout>] + + Parameter description: + + -d: prints additional protocol debug output. + + <eid>: the destination EID or FQDN of a LISP host. + + -m <map-resolver>: the RLOC address or FQDN of a Map-Resolver. + + -c <count>: the number of Map-Requests to send before the first Map- + Reply is returned. The default value is 3. The range is from 1 + to 5. + + -t <timeout>: the amount of time, in seconds, before another Map- + Request is sent when no Map-Reply is returned. The default value + is 2 seconds. The range is from 1 to 5. + + + + +Farinacci & Meyer Informational [Page 8] + +RFC 6835 LISP Internet Groper (LIG) January 2013 + + + Some sample output: + + % lig xyz.example.com -m 10.0.0.1 + Send map-request to 10.0.0.1 for 192.168.1.1 ... + Received map-reply from 10.0.0.2 with rtt 0.04000 sec + + Mapping entry for EID 192.168.1.1: + 192.168.1.0/24, record ttl: 60 + Locator State Priority/Weight + 10.0.0.1 up 1/25 + 10.0.0.2 up 1/25 + 10.0.0.3 up 1/25 + 10.0.0.4 up 2/25 + + The public domain implementation of 'lig' is available at + <http://github.com/LISPmob/lig>. + +5. Testing the ALT + + There are cases where a Map-Reply is returned from a 'lig' request, + but the user doesn't really know how much of the mapping + infrastructure was tested. There are two cases to consider -- + avoiding the ALT and traversing the ALT. + + When an ITR sends a 'lig' request to its Map-Resolver for a + destination-EID, the Map-Resolver could also be configured as a Map- + Server. And if the destination-EID is for a site that registers with + this Map-Server, the Map-Request is sent to the site directly without + testing the ALT. This occurs because the Map-Server is the source of + the advertisement for the site's EID-prefix. So, if the map-reply is + returned to the 'lig'-requesting site, you cannot be sure that other + sites can reach the same destination-EID. + + If a Map-Resolver is used that is not a Map-Server for the EID-prefix + being sought, then the ALT infrastructure can be tested. This test + case is testing the functionality of the Map-Resolver, traversal of + the ALT (testing BGP-over-GRE), and the Map-Server. + + It is recommended that users issue two 'lig' requests; they send Map- + Requests to different Map-Resolvers. + + The network can have a LISP-ALT Router deployed as a "ALT looking- + glass" node. This type of router has BGP peering sessions with other + ALT Routers where it does not inject any EID-prefixes into the ALT + but just learns ones advertised by other ALT Routers and Map-Servers. + This router is configured as a Map-Resolver. 'lig' users can point to + the ALT looking-glass router for Map-Resolver services via the "to + <map-resolver>" parameter on the 'lig' command. The ALT looking- + + + +Farinacci & Meyer Informational [Page 9] + +RFC 6835 LISP Internet Groper (LIG) January 2013 + + + glass node can be used to 'lig' other sites as well as your own site. + When the ALT looking-glass is used as a Map-Resolver, you can be + assured the ALT network is being tested. + +6. Future Enhancements + + When Negative Map-Replies have been further developed and + implemented, 'lig' should be modified appropriately to process and + clearly indicate how and why a Negative Map-Reply was received. + Negative Map-Replies could be sent in the following cases: the 'lig' + request was initiated for a non-EID address or there was rate- + limiting on the replier. + +7. Deployed Network Diagnostic Tools + + There is a web-based interface to do auto-polling with 'lig' on the + back-end for most of the LISP sites on the LISP test network. The + web page can be accessed at <http://www.lisp4.net/status>. + + There is a LISP site monitoring web-based interface that can be found + at <http://lispmon.net>. + + At <http://baldomar.ccaba.upc.edu/lispmon>, written by the folks at + Universitat Politecnica de Catalunya (UPC), shows a geographical map + indicating where each LISP site resides. + +8. Security Considerations + + The use of 'lig' does not affect the security of the LISP + infrastructure as it is simply a tool that facilities diagnostic + querying. See [RFC6830], [RFC6836], and [RFC6833] for descriptions + of the security properties of the LISP infrastructure. + + 'lig' provides easy access to the information in the public mapping + database. Therefore, it is important to protect the mapping + information for private use. This can be provided by disallowing + access to specific mapping entries or to place such entries in a + private mapping database system. + + + + + + + + + + + + + +Farinacci & Meyer Informational [Page 10] + +RFC 6835 LISP Internet Groper (LIG) January 2013 + + +9. References + +9.1. Normative References + + [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing + (CIDR): The Internet Address Assignment and Aggregation + Plan", BCP 122, RFC 4632, August 2006. + + [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The + Locator/ID Separation Protocol (LISP)", RFC 6830, + January 2013. + + [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, + "Interworking between Locator/ID Separation Protocol + (LISP) and Non-LISP Sites", RFC 6832, January 2013. + + [RFC6833] Farinacci, D. and V. Fuller, "Locator/ID Separation + Protocol (LISP) Map Server Interface", RFC 6833, + January 2013. + +9.2. Informative References + + [LISP-CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A + Content distribution Overlay Network Service for LISP", + Work in Progress, April 2008. + + [RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, + "Locator/ID Separation Protocol Alternative Logical + Topology (LISP+ALT)", RFC 6836, January 2013. + + [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to + Routing Locator (RLOC) Database", RFC 6837, + January 2013. + + + + + + + + + + + + + + + + + + +Farinacci & Meyer Informational [Page 11] + +RFC 6835 LISP Internet Groper (LIG) January 2013 + + +Appendix A. Acknowledgments + + Thanks and kudos to John Zwiebel, Andrew Partan, Darrel Lewis, and + Vince Fuller for providing critical feedback on the 'lig' design and + prototype implementations. To these folks, as well as all the people + on lisp-beta@external.cisco.com who tested 'lig' functionality and + continue to do so, we extend our sincere thanks. + + This document is based on an individual contribution. + +Authors' Addresses + + Dino Farinacci + Cisco Systems + Tasman Drive + San Jose, CA 95134 + USA + + EMail: farinacci@gmail.com + + + Dave Meyer + Cisco Systems + 170 Tasman Drive + San Jose, CA + USA + + EMail: dmm@cisco.com + + + + + + + + + + + + + + + + + + + + + + + +Farinacci & Meyer Informational [Page 12] + |