RFC 8112

Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG)

📅 published May 2017, from ietf

Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG) 🧚

  • RFC number: 8112
  • Stream: Independent Submission
  • Category: Informational
  • Date: May 2017
  • ISSN: 2070-1721
  • Authors: D. Farinacci (lispers.net), A. Jain (Juniper Networks), I. Kouvelas (Arista), D. Lewis (Cisco Systems)
  • Obsoletes / Updates: the title block doesn't list any RFCs it obsoletes or updates 💅

Abstract

okay so the rig tool is a simple one 🦋 It's the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG), and you can also just call it "rig" (lowercase, very chill). Its whole job is to query the LISP-DDT hierarchy. This doc explains how "rig" actually works ✨

Status of This Memo

ngl this part is the legal-ish bit, but it's important so read along 🫶

This document is not an Internet Standards Track specification. It's published for informational purposes only 🌸

It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents the RFC Editor approves for publication are not candidates for any level of Internet Standard. Check Section 2 of RFC 7841 for the details 💜

Want the current status, errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc8112 🎀

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. Please read those carefully, because they spell out your rights and restrictions for this document 📜

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 ✨

Okay so the "Locator/ID Separation Protocol (LISP)" [RFC6830] is the glow-up here 💖 It describes an architecture and mechanism that swaps out what an IP address means, splitting it into 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 make that split work, LISP defines protocol mechanisms for mapping from EIDs to RLOCs. LISP also assumes there's a database that stores and spreads 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 for querying the LISP-DDT mapping database hierarchy 🔍 Basically every device that implements LISP can run it: Ingress Tunnel Routers (ITRs), Egress Tunnel Routers (ETRs), Proxy ITRs (PITRs), Proxy ETRs (PETRs), Map-Resolvers, Map-Servers, and LISP-DDT nodes. A host system at a LISP-capable or non-LISP-capable site can run it too 💅

Now the lore: the LISP-DDT "rig" tool is kinda similar to the "LISP Internet Groper" ("lig") tool [RFC6835], because they're both diagnostic tools for querying a database 👯 But they have different jobs. "rig" finds the Map-Servers serving an EID-prefix, specifically inside a LISP-DDT mapping database framework. "lig" can sit on top of any mapping database system and retrieve the locators used for packet encapsulation 🦋

2. Requirements Language 💜

The BCP 14 key words are the rules-of-the-game words here 🎀 In this document, "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" get interpreted as described in BCP 14 [RFC2119] [RFC8174]. But only when they show up in ALL CAPITALS, exactly like that. Lowercase is just regular English, no drama 🙈

3. Definitions of Terms 📚

Here's the glossary, bestie 🧚 Let's go term by term.

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 gets a destination EID the same way it gets a destination address today, like through a Domain Name System (DNS) [RFC1034] lookup or a Session Initiation Protocol (SIP) [RFC3261] exchange. The source EID comes from the existing mechanisms that set a host's "local" IP address 🌸 An EID used on the public Internet has to have the same properties as any other IP address used that way. That means, among other things, it must be globally unique 🌍 An EID is allocated to a host from an EID-prefix block tied to the site where the host lives. A host can use an EID to refer to other hosts 🫶 EIDs MUST NOT be used as LISP RLOCs, so don't even try 🙅‍♀️ Also note that EID blocks MAY be assigned in a hierarchical manner, independent of the network topology, which helps the mapping database scale 📈 An EID block assigned to a site can also have site-local structure (subnetting) for routing inside the site. That structure is invisible to the global routing system 👀 In theory, the bit string that represents an EID for one device could represent an RLOC for a different device. As the architecture gets built out, if a given bit string is both an RLOC and an EID, it must refer to the same entity in both cases. When other Locator/ID separation proposals come up in "discussions," a LISP EID gets called an "LEID," and anywhere this document says "EID," it means an LEID 💖

Extended EID (XEID): a LISP EID, optionally extended with a non-zero Instance ID (IID) if the EID is meant for a context where it might not be a unique value, like a Virtual Private Network that uses private address space [RFC1918]. Check Section 5.5 of [RFC6830] for more on 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. RLOCs are usually numbered from topologically aggregatable blocks assigned to a site at each point where it attaches to the global Internet. When 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 delegating 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. Usually a DDT client is a Map-Resolver (as defined by [RFC6833]), but an ITR can also implement DDT client functionality 💅 A DDT client can be a device that's originating "rig" requests 🍓

DDT Map-Server: a DDT node that also implements Map-Server functionality (forwarding Map-Requests and/or returning Map-Replies if it offers a proxy Map-Reply service) for a subset of its delegated prefixes. The 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. It follows returned referrals until it gets one with the MS-ACK action code [RFC8111]. That signals the Map-Request has been sent to a Map-Server that will forward it to an ETR, which in turn will provide a Map-Reply to the original sender 🔥 A DDT Map-Resolver keeps two things: (1) a cache of Map-Referral message results (called the "referral cache") holding RLOCs for DDT nodes responsible for XEID-prefixes of interest, and (2) a lookup queue of XEIDs being resolved through iterative querying of DDT nodes 👑

Encapsulated Map-Request: a LISP Map-Request carried within an Encapsulated Control Message (ECM) that has an extra LISP header prepended. It's sent to UDP destination port 4342 🌸 The "outer" addresses are globally routable IP addresses, also known as RLOCs. An ITR uses it when sending a Map-Request to a Map-Resolver, and a Map-Server uses it when forwarding a Map-Request to an ETR, as documented in [RFC6833] ✨

Map-Referral: a LISP message sent by a DDT node when it gets a DDT Map-Request for an XEID that matches a configured XEID-prefix delegation. A non-Negative Map-Referral message includes a "referral," which is a set of RLOCs for DDT nodes that know more about the sub-prefix. A DDT client "follows the referral" by sending another DDT Map-Request to one of those RLOCs, to get 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, for which that DDT node may provide further delegations of more-specific sub-prefixes 👑

4. Basic Overview ✨

okay so LISP-DDT [RFC8111] is a hierarchical distributed database that basically embodies the delegation of authority 👑 to provide mappings from LISP EIDs to RLOCs. It's a statically defined split of the EID namespace across a bunch 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 that more-specific EID-prefixes get delegated to. it's giving org chart energy 🧚

Map-Resolvers send Map-Requests into the DDT hierarchy and keep referral caches by receiving Map-Referral messages from DDT nodes. They follow the hierarchy for a given EID lookup based on the EID-prefix and the delegation referrals inside those Map-Referral messages. The "rig" tool is meant to do the same job as a Map-Resolver, but it's also a management tool for the network admin 💅

When you run the "rig" command, an Encapsulated Control Message Map-Request gets sent for a destination EID. When a LISP-DDT Map-Referral comes back, the contents get displayed to you 🦋 Here's what shows up:

  • 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.
  • The type of DDT node that sent the Map-Referral.
  • The action code and TTL set by the sender of the Map-Referral.
  • The referral RLOC addresses from the Map-Referral message.
  • A round-trip-time estimate for the ECM-Map-Request / Map-Referral message exchange.

A possible syntax for a "rig" command MAY be:

rig [instance-id <iid>] <eid> to <ddt-node> [follow-all-referrals]

Parameter descriptions (bestie, read these, they're the good stuff 🍓):

  • [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 isn't configured with IIDs, this argument gets left off the command line.
  • <eid>: <eid> is either a Fully Qualified Domain Name or a destination EID that's being queried in the LISP-DDT mapping database.
  • <ddt-node>: <ddt-node> is the RLOC address of any DDT node in the DDT hierarchy. It 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 gets queried, so "rig" can descend the entire DDT hierarchy starting from <ddt-node>. when it's not used, one of the referral RLOCs gets selected to descend a single branch of the DDT hierarchy.

The "rig" utility doesn't just show branches of the delegation hierarchy, it can also report stuff like:

  • 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.
  • When a DDT Map-Server sends a Negative Map-Referral saying that a requested EID is configured but not registered to the mapping database system. This is known as an "MS-NOT-REGISTERED" action.
  • 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.
  • When a DDT node finds a hole in the address space that hasn't 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.
  • When a DDT node finds a hole in the address space that hasn't been allocated or configured in the delegation hierarchy at all. This is typically associated with a hole that's 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. so many options, I'm obsessed 😭

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's some sample IOS output. Read it like a little story 🌸

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
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.

And here's 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

6. Security Considerations 🔐

The use of "rig" doesn't affect the security of the LISP infrastructure, because it's just a tool that helps with diagnostic querying. See [RFC6830], [RFC6833], [RFC7835], and [RFC8111] for descriptions of the security properties of the LISP infrastructure.

⚠️ LISP "rig" gives easy access to the information in the public mapping database. So it's really important to protect mapping information meant for private use. This can be done by disallowing access to specific mapping entries, or by placing those entries in a private mapping database system.

7. IANA Considerations 🦋

This document does not require any IANA actions. zero registry drama, we love to see it ✨

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>.

[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>.

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. the squad is everything 💖

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
📦 where this page comes from