summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8112.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8112.txt')
-rw-r--r--doc/rfc/rfc8112.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc8112.txt b/doc/rfc/rfc8112.txt
new file mode 100644
index 0000000..c3f8f35
--- /dev/null
+++ b/doc/rfc/rfc8112.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Independent Submission D. Farinacci
+Request for Comments: 8112 lispers.net
+Category: Informational A. Jain
+ISSN: 2070-1721 Juniper Networks
+ I. Kouvelas
+ Arista
+ D. Lewis
+ Cisco Systems
+ May 2017
+
+
+ Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)
+ Referral Internet Groper (RIG)
+
+Abstract
+
+ A simple tool called the Locator/ID Separation Protocol Delegated
+ Database Tree (LISP-DDT) Referral Internet Groper (RIG), also
+ referred to in this document as "rig", can be used to query the LISP-
+ DDT hierarchy. This document describes how the "rig" tool works.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This is a contribution to the RFC Series, independently of any other
+ RFC stream. The RFC Editor has chosen to publish this document at
+ its discretion and makes no statement about its value for
+ implementation or deployment. Documents approved for publication by
+ the RFC Editor are not a candidate for any level of Internet
+ Standard; see Section 2 of RFC 7841.
+
+ 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/rfc8112.
+
+Copyright Notice
+
+ Copyright (c) 2017 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.
+
+
+
+Farinacci, et al. Informational [Page 1]
+
+RFC 8112 LISP-DDT Referral Internet Groper (RIG) May 2017
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Requirements Language ...........................................3
+ 3. Definitions of Terms ............................................3
+ 4. Basic Overview ..................................................5
+ 5. Implementation Details ..........................................7
+ 6. Security Considerations .........................................9
+ 7. IANA Considerations .............................................9
+ 8. References ......................................................9
+ 8.1. Normative References .......................................9
+ 8.2. Informative References ....................................10
+ Acknowledgments ...................................................11
+ Authors' Addresses ................................................11
+
+1. Introduction
+
+ "The Locator/ID Separation Protocol (LISP)" [RFC6830] specifies an
+ architecture and mechanism for replacing the semantics of an address
+ currently used by IP with two separate namespaces: Endpoint
+ Identifiers (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. This document focuses on the LISP Delegated Database Tree
+ (LISP-DDT) [RFC8111] mapping database system.
+
+ The "rig" tool is a manual management tool to query the LISP-DDT
+ mapping database hierarchy. It can be run by all devices that
+ implement LISP, including Ingress Tunnel Routers (ITRs), Egress
+ Tunnel Routers (ETRs), Proxy ITRs (PITRs), Proxy ETRs (PETRs),
+ Map-Resolvers, Map-Servers, and LISP-DDT nodes, as well as by a host
+ system at either a LISP-capable or non-LISP-capable site.
+
+ The LISP-DDT "rig" tool is similar to the "LISP Internet Groper"
+ ("lig") tool [RFC6835] in that they are both diagnostic tools to
+ query a database. However, the "rig" tool is used to find
+ Map-Servers serving an EID-prefix, specifically within a LISP-DDT
+ mapping database framework. And "lig" can be used on top of any
+ mapping database system to retrieve locators used for packet
+ encapsulation.
+
+
+
+
+
+
+
+
+
+Farinacci, et al. Informational [Page 2]
+
+RFC 8112 LISP-DDT Referral Internet Groper (RIG) May 2017
+
+
+2. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+3. Definitions of Terms
+
+ Endpoint Identifier (EID): a 32-bit (for IPv4) or 128-bit (for IPv6)
+ value (or an address encoded per [RFC8060]) used in the source and
+ destination address fields of the first (innermost) LISP header of
+ a packet. The host obtains a destination EID the same way it
+ obtains a destination address today -- for example, through a
+ Domain Name System (DNS) [RFC1034] lookup or a Session Initiation
+ Protocol (SIP) [RFC3261] exchange. The source EID is obtained via
+ existing mechanisms used to set a host's "local" IP address. An
+ EID used on the public Internet must have the same properties as
+ any other IP address used in that manner; this means, among other
+ things, that it must be globally unique. 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. In theory, the bit
+ string that represents an EID for one device can represent an RLOC
+ for a different device. As the architecture is realized, if a
+ given bit string is both an RLOC and an EID, it must refer to the
+ same entity in both cases. When used in "discussions" with other
+ Locator/ID separation proposals, a LISP EID will be called an
+ "LEID". Throughout this document, any references to "EID" refer
+ to an LEID.
+
+ Extended EID (XEID): a LISP EID, optionally extended with a non-zero
+ Instance ID (IID) if the EID is intended for use in a context
+ where it may not be a unique value, such as in a Virtual Private
+ Network where private address space [RFC1918] is used. See
+ Section 5.5 of [RFC6830] for more discussion of IIDs.
+
+ Routing Locator (RLOC): an IPv4 [RFC791] or IPv6 [RFC2460] address
+ of an Egress Tunnel Router (ETR). An RLOC 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
+
+
+
+Farinacci, et al. Informational [Page 3]
+
+RFC 8112 LISP-DDT Referral Internet Groper (RIG) May 2017
+
+
+ attaches to the global Internet; where the topology is defined by
+ the connectivity of provider networks, 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.
+
+ DDT node: a network infrastructure component responsible for
+ specific XEID-prefix(es) and for the delegation of more-specific
+ sub-prefixes to other DDT nodes.
+
+ DDT client: a network infrastructure component that sends DDT
+ Map-Request messages and implements the iterative following of
+ Map-Referral results. Typically, a DDT client will be a
+ Map-Resolver (as defined by [RFC6833]), but it is also possible
+ for an ITR to implement DDT client functionality. A DDT client
+ can be a device that is originating "rig" requests.
+
+ DDT Map-Server: a DDT node that also implements Map-Server
+ functionality (forwarding Map-Requests and/or returning
+ Map-Replies if offering a proxy Map-Reply service) for a subset of
+ its delegated prefixes. Map-Server functions, including proxying
+ Map-Replies, are described in [RFC6833].
+
+ DDT Map-Resolver: a network infrastructure element that accepts a
+ Map-Request, adds the XEID to its lookup queue, then queries one
+ or more DDT nodes for the requested EID, following returned
+ referrals until it receives one with the MS-ACK action code
+ [RFC8111]. This indicates that the Map-Request has been sent to a
+ Map-Server that will forward it to an ETR that, in turn, will
+ provide a Map-Reply to the original sender. A DDT Map-Resolver
+ maintains both (1) a cache of Map-Referral message results (termed
+ the "referral cache") containing RLOCs for DDT nodes responsible
+ for XEID-prefixes of interest and (2) a lookup queue of XEIDs that
+ are being resolved through iterative querying of DDT nodes.
+
+ Encapsulated Map-Request: a LISP Map-Request that is carried within
+ an Encapsulated Control Message (ECM) and that 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 a Map-Request to a
+ Map-Resolver and by a Map-Server when forwarding a Map-Request to
+ an ETR as documented in [RFC6833].
+
+ Map-Referral: a LISP message sent by a DDT node when it receives a
+ DDT Map-Request for an XEID that matches a configured XEID-prefix
+ delegation. A non-Negative Map-Referral message includes a
+ "referral" -- a set of RLOCs for DDT nodes that have more
+ information about the sub-prefix; a DDT client "follows the
+
+
+
+
+Farinacci, et al. Informational [Page 4]
+
+RFC 8112 LISP-DDT Referral Internet Groper (RIG) May 2017
+
+
+ referral" by sending another DDT Map-Request to one of those RLOCs
+ to obtain either an answer or another referral to DDT nodes
+ responsible for a more-specific XEID-prefix.
+
+ Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node
+ and for which the DDT node may provide further delegations of
+ more-specific sub-prefixes.
+
+4. Basic Overview
+
+ LISP-DDT [RFC8111] is a hierarchical distributed database that
+ embodies the delegation of authority to provide mappings from LISP
+ EIDs to RLOCs. It is a statically defined distribution of the EID
+ namespace among a set of LISP-speaking servers called "DDT nodes".
+ Each DDT node is configured as "authoritative" for one or more
+ EID-prefixes, along with the set of RLOCs for Map-Servers or "child"
+ DDT nodes to which more-specific EID-prefixes are delegated.
+
+ Map-Resolvers send Map-Requests to the DDT hierarchy and maintain
+ referral caches by receiving Map-Referral messages from DDT nodes.
+ Map-Resolvers follow the DDT hierarchy for a given EID lookup based
+ on the EID-prefix and delegation referrals contained in the
+ Map-Referral messages. The "rig" tool is intended to perform the
+ same operation as that of a Map-Resolver but to also be used as a
+ management tool for the network administrator.
+
+ When the "rig" command is run, an Encapsulated Control Message
+ Map-Request is sent for a destination EID. When a LISP-DDT
+ Map-Referral is returned, the contents are displayed to the user.
+ The information displayed includes:
+
+ o A delegated EID-prefix configured in a DDT node or a configured
+ site EID-prefix in a DDT Map-Server that matches the
+ requested EID.
+
+ o The type of DDT node that sent the Map-Referral.
+
+ o The action code and TTL set by the sender of the Map-Referral.
+
+ o The referral RLOC addresses from the Map-Referral message.
+
+ o A round-trip-time estimate for the ECM-Map-Request / Map-Referral
+ message exchange.
+
+
+
+
+
+
+
+
+Farinacci, et al. Informational [Page 5]
+
+RFC 8112 LISP-DDT Referral Internet Groper (RIG) May 2017
+
+
+ A possible syntax for a "rig" command MAY be:
+
+ rig [instance-id <iid>] <eid> to <ddt-node> [follow-all-referrals]
+
+ Parameter descriptions:
+
+ [instance-id <iid>]: <iid> is the IID portion of the XEID used as a
+ VPN identifier or for other future purposes. When the DDT
+ hierarchy is not configured with IIDs, this argument is omitted
+ from the command line.
+
+ <eid>: <eid> is either a Fully Qualified Domain Name or a
+ destination EID that is being queried in the LISP-DDT mapping
+ database.
+
+ <ddt-node>: <ddt-node> is the RLOC address of any DDT node in the
+ DDT hierarchy. This can be the DDT root node, a DDT transit node,
+ or a DDT Map-Server.
+
+ [follow-all-referrals]: When this keyword is used, each referral
+ RLOC is queried so "rig" can descend the entire DDT hierarchy
+ starting from the node <ddt-node>. When this keyword is not used,
+ one of the referral RLOCs will be selected to descend a branch of
+ the DDT hierarchy.
+
+ The "rig" utility not only shows branches of the delegation hierarchy
+ but can also report:
+
+ o When a DDT Map-Server would forward a Map-Request to the ETRs at a
+ registered LISP site. This is known as an "MS-ACK" action.
+
+ o When a DDT Map-Server sends a Negative Map-Referral indicating
+ that a requested EID is configured but not registered to the
+ mapping database system. This is known as an "MS-NOT-REGISTERED"
+ action.
+
+ o When a DDT node is sending referrals for a transit or leaf node in
+ the hierarchy. These are known as "NODE-REFERRAL" and
+ "MS-REFERRAL" actions, respectively.
+
+ o When a DDT node finds a hole in the address space that has not
+ been allocated or configured in the delegation hierarchy. This is
+ typically associated with a hole in a DDT node's configured
+ authoritative prefix. This is known as a "DELEGATION-HOLE"
+ action.
+
+
+
+
+
+
+Farinacci, et al. Informational [Page 6]
+
+RFC 8112 LISP-DDT Referral Internet Groper (RIG) May 2017
+
+
+ o When a DDT node finds a hole in the address space that has not
+ been allocated or configured in the delegation hierarchy at all.
+ This is typically associated with a hole that is outside of a DDT
+ node's authoritative prefix. This is known as a
+ "NOT-AUTHORITATIVE" action.
+
+ Refer to [RFC8111] for more details about Map-Referral actions.
+
+5. Implementation Details
+
+ The Cisco LISP prototype implementations on IOS and NX-OS have "rig"
+ support for IPv4 and IPv6 EIDs in either the default instance or a
+ non-zero IID.
+
+ The IOS syntax is:
+
+ rig [instance-id <iid>] <eid> to <ddt-node> [follow-all-referrals]
+
+ The NX-OS syntax is:
+
+ rig [instance-id <iid>] { <hostname> | {<eid> | <eid6>} }
+ to { <ddt-hostname> | {<ddt> | <ddt6>} }
+
+ Here is some sample IOS output:
+
+ Router# rig 12.0.1.1 to 1.1.1.1
+
+ Send Map-Request to DDT-node 1.1.1.1 ... node referral, rtt: 0 ms
+ EID-prefix: [0] 12.0.0.0/16, ttl: 1440
+ referrals: 2.2.2.2
+
+ Send Map-Request to DDT-node 2.2.2.2 ... node referral, rtt: 0 ms
+ EID-prefix: [0] 12.0.1.0/24, ttl: 1440
+ referrals: 4.4.4.4, 5.5.5.5
+
+ Send Map-Request to DDT-node 4.4.4.4 ... map-server acknowledgement,
+ rtt: 0 ms
+ EID-prefix: [0] 12.0.1.0/28, ttl: 1440
+ referrals: 4.4.4.4, 5.5.5.5
+
+ Router# rig 12.0.1.1 to 1.1.1.1 follow-all-referrals
+
+ Send Map-Request to DDT-node 1.1.1.1 ... node referral, rtt: 4 ms
+ EID-prefix: [0] 12.0.0.0/16, ttl: 1440
+ referrals: 2.2.2.2
+
+
+
+
+
+
+Farinacci, et al. Informational [Page 7]
+
+RFC 8112 LISP-DDT Referral Internet Groper (RIG) May 2017
+
+
+ Send Map-Request to DDT-node 2.2.2.2 ... node referral, rtt: 0 ms
+ EID-prefix: [0] 12.0.1.0/24, ttl: 1440
+ referrals: 4.4.4.4, 5.5.5.5
+
+ Send Map-Request to DDT-node 4.4.4.4 ... map-server acknowledgement,
+ rtt: 0 ms
+ EID-prefix: [0] 12.0.1.0/28, ttl: 1440
+ referrals: 4.4.4.4, 5.5.5.5
+
+ Send Map-Request to DDT-node 5.5.5.5 ... map-server acknowledgement,
+ rtt: 0 ms
+ EID-prefix: [0] 12.0.1.0/28, ttl: 1440
+ referrals: 4.4.4.4, 5.5.5.5
+
+ No more referrals to pursue.
+
+ Here is some sample NX-OS output:
+
+ Router# rig 12.0.1.1 to 1.1.1.1
+
+ rig LISP-DDT hierarchy for EID [0] 12.0.1.1
+ Send Map-Request to DDT-node 1.1.1.1 ... replied, rtt: 0.003509 secs
+ EID-prefix [0] *, ttl: 1440, action: node-referral, referrals:
+ 2.2.2.2, priority/weight: 0/0
+
+ Send Map-Request to DDT-node 2.2.2.2 ... replied, rtt: 0.003173 secs
+ EID-prefix [0] 12.0.0.0/20, ttl: 1440, action: node-referral,
+ referrals:
+ 3.3.3.3, priority/weight: 0/0
+
+ Send Map-Request to DDT-node 3.3.3.3 ... replied, rtt: 0.004145 secs
+ EID-prefix [0] 12.0.1.0/24, ttl: 1440, action: node-referral,
+ referrals:
+ 5.5.5.5, priority/weight: 0/0
+ 6.6.6.6, priority/weight: 0/0
+
+ Send Map-Request to DDT-node 6.6.6.6 ... replied, rtt: 0.005800 secs
+ EID-prefix [0] 12.0.1.0/28, ttl: 1440, action: ms-ack, referrals:
+ 5.5.5.5, priority/weight: 0/0
+ 6.6.6.6, priority/weight: 0/0
+
+
+
+
+
+
+
+
+
+
+
+Farinacci, et al. Informational [Page 8]
+
+RFC 8112 LISP-DDT Referral Internet Groper (RIG) May 2017
+
+
+6. Security Considerations
+
+ The use of "rig" does not affect the security of the LISP
+ infrastructure, as it is simply a tool that facilitates diagnostic
+ querying. See [RFC6830], [RFC6833], [RFC7835], and [RFC8111] for
+ descriptions of the security properties of the LISP infrastructure.
+
+ LISP "rig" 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 placing such entries in a
+ private mapping database system.
+
+7. IANA Considerations
+
+ This document does not require any IANA actions.
+
+8. References
+
+8.1. Normative References
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ DOI 10.17487/RFC0791, September 1981,
+ <http://www.rfc-editor.org/info/rfc791>.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
+ <http://www.rfc-editor.org/info/rfc1034>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
+ Locator/ID Separation Protocol (LISP)", RFC 6830,
+ DOI 10.17487/RFC6830, January 2013,
+ <http://www.rfc-editor.org/info/rfc6830>.
+
+ [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
+ Protocol (LISP) Map-Server Interface", RFC 6833,
+ DOI 10.17487/RFC6833, January 2013,
+ <http://www.rfc-editor.org/info/rfc6833>.
+
+ [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
+ Protocol Internet Groper (LIG)", RFC 6835,
+ DOI 10.17487/RFC6835, January 2013,
+ <http://www.rfc-editor.org/info/rfc6835>.
+
+
+
+Farinacci, et al. Informational [Page 9]
+
+RFC 8112 LISP-DDT Referral Internet Groper (RIG) May 2017
+
+
+ [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
+ Smirnov, "Locator/ID Separation Protocol Delegated
+ Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
+ May 2017, <http://www.rfc-editor.org/info/rfc8111>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
+ RFC 2119 Key Words", BCP 14, RFC 8174,
+ DOI 10.17487/RFC8174, May 2017,
+ <http://www.rfc-editor.org/info/rfc8174>.
+
+8.2. Informative References
+
+ [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+ and E. Lear, "Address Allocation for Private Internets",
+ BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
+ <http://www.rfc-editor.org/info/rfc1918>.
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
+ December 1998, <http://www.rfc-editor.org/info/rfc2460>.
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ DOI 10.17487/RFC3261, June 2002,
+ <http://www.rfc-editor.org/info/rfc3261>.
+
+ [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
+ Separation Protocol (LISP) Threat Analysis", RFC 7835,
+ DOI 10.17487/RFC7835, April 2016,
+ <http://www.rfc-editor.org/info/rfc7835>.
+
+ [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
+ Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
+ February 2017, <http://www.rfc-editor.org/info/rfc8060>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farinacci, et al. Informational [Page 10]
+
+RFC 8112 LISP-DDT Referral Internet Groper (RIG) May 2017
+
+
+Acknowledgments
+
+ The authors would like to thank Damien Saucez and Fabio Maino for
+ their ideas and comments. Appreciation also goes to Joel Halpern,
+ Luigi Iannone, and Nevil Brownlee for their help with this document.
+
+Authors' Addresses
+
+ Dino Farinacci
+ lispers.net
+ San Jose, California
+ United States of America
+
+ Phone: 408-718-2001
+ Email: farinacci@gmail.com
+
+
+ Amit Jain
+ Juniper Networks
+ San Jose, California
+ United States of America
+
+ Email: atjain@juniper.net
+
+
+ Isidor Kouvelas
+ Arista
+ Santa Clara, California
+ United States of America
+
+ Email: kouvelas@arista.com
+
+
+ Darrel Lewis
+ Cisco Systems
+ Tasman Ave.
+ San Jose, California
+ United States of America
+
+ Email: darlewis@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+Farinacci, et al. Informational [Page 11]
+