RFC 6835

The Locator/ID Separation Protocol Internet Groper (LIG)

📅 published January 2013, from ietf

RFC 6835: The Locator/ID Separation Protocol Internet Groper (LIG) 🦋

  • Number: RFC 6835
  • Authors: D. Farinacci and D. Meyer, both from Cisco Systems
  • Category: Informational
  • ISSN: 2070-1721
  • Date: January 2013
  • Obsoletes / Updates: nothing listed in the title block

This one is published by the IETF and is all about lig 🔍✨

Abstract 🌈

okay so a simple tool called the Locator/ID Separation Protocol (LISP) Internet Groper, or 'lig', can be used to query the LISP mapping database 💖 this doc explains how it works 🫶

Status of This Memo 📜

this document is not an Internet Standards Track specification 🙈 it's published for informational purposes, so it's more of a "here's how this works" moment than a rulebook 🎀

it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 👑 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved document is a candidate for any level of Internet Standard, though, so check Section 2 of RFC 5741 if you want the full picture 🧚

for the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc6835 🦋

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) as they stood on the publication date. read them carefully, because they spell out your rights and restrictions for this document 📜 also, any Code Components pulled out of this document have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💅

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 🌸

okay bestie, so the Locator/ID Separation Protocol [RFC6830] specifies an architecture and mechanism that swaps out the addresses IP uses today for two separate namespaces 🦋 there are Endpoint IDs (EIDs), used inside sites, and Routing Locators (RLOCs), used on the transit networks that make up the Internet's infrastructure 💅 to pull this off, LISP defines protocol mechanisms for mapping from EIDs to RLOCs. it also assumes a database exists to store and spread those mappings globally 🌍

there have been a few of these databases proposed, like 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]. LISP+ALT is the one currently being implemented and deployed on the pilot LISP network 🔥

alongside the various mapping systems, there's a network-based API called LISP Map-Server [RFC6833] ✨ Map-Resolvers and Map-Servers let LISP sites query and register into the database in a uniform way, no matter which mapping system is underneath 💖 sending Map-Requests to Map-Resolvers is a secure way to get a Map-Reply with the authoritative EID-to-RLOC mapping for a destination LISP site 🔐

the 'lig' is a manual management tool for querying the mapping database 🔍 every device that implements LISP can run it, including Ingress Tunnel Routers (ITRs), Egress Tunnel Routers (ETRs), Proxy-ITRs, Proxy-ETRs, Map-Resolvers, Map-Servers, and LISP-ALT Routers 🧚 a host system at a LISP-capable site or a non-LISP-capable site can run it too 🫶

last thing: the mapping database is typically a public one, used for wide-range connectivity across Internet sites 🌈 its info is purposely not kept private, so anyone can access it for public use 🎀

2. Definition of Terms 💅

okay, here's the glossary you'll want to keep handy 📖

  • 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) 🧚 it advertises these mappings in the distributed mapping database.
  • Map-Resolver: a network infrastructure component that accepts LISP Encapsulated Map-Requests, typically from an ITR, and quickly figures out whether the destination IP address is part of the EID namespace 👀 if it isn't, a Negative Map-Reply comes straight back. otherwise, the Map-Resolver finds the right 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's 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, so 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 gets a destination EID the same way it gets a destination address today, for example through a DNS lookup. the source EID comes from the 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, and a host can use an EID to refer to other hosts 🫶 EIDs must not be used as LISP RLOCs. EID blocks may be assigned hierarchically, independent of network topology, to help the mapping database scale 📈 and an EID block assigned to a site can have site-local structure (subnetting) for routing inside the site. that structure isn't visible to the global routing system 🙈
  • EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that stores, tracks, and takes care of timing out and otherwise validating EID-to-RLOC mappings ⏳ this cache is separate 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 holds a small piece of it: the EID-to-RLOC mappings for the EID prefixes "behind" the router. those map to one of the router's own globally visible IP addresses 🔥
  • Encapsulated Map-Request (EMR): an EMR is a Map-Request message that's encapsulated with another LISP header, using UDP destination port number 4342 🎀 it's used so an ITR, PITR, or a system running a 'lig' command can get the Map-Request to a Map-Resolver using locator addresses. when the Map-Resolver decapsulates the Map-Request, it's forwarded on the ALT network to the Map-Server that injected the EID-prefix for a registered site 🛰️ the Map-Server then encapsulates the Map-Request in a LISP packet and sends it to an ETR at the site, and the ETR returns an authoritative reply to the system that started 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 that "inner" IP destination address as an EID and does an EID-to-RLOC mapping lookup. then it 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 ✨ this destination RLOC might be an intermediate proxy device that has better knowledge of the EID-to-RLOC mapping closer to the destination EID 🧚 in general, an ITR gets IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other 🦋
  • Egress Tunnel Router (ETR): an ETR is a router that accepts an IP packet whose "outer" IP header destination address is one of its own RLOCs 💖 it strips the "outer" header and forwards the packet based on the next IP header it finds. in general, an ETR gets LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other 🌸 ETR functionality doesn't have to be limited to a router device, either. a server host can be the endpoint of a LISP tunnel too 🫶
  • Proxy-ITR (PITR): a PITR, also known as a PTR, is defined and described in [RFC6832] 🎀 it 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] 💜 it 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 the direction of data flow isn't part of the context description 🔁 xTR refers to the router that's the tunnel endpoint, and it's used synonymously with the term "tunnel router". for example, "an xTR can be located at the Customer Edge (CE) router" means both ITR and ETR functionality live at the CE router 🏠
  • Provider-Assigned (PA) Addresses: PA addresses are an address block assigned to a site by each service provider it connects to 🧾 usually each block is a sub-block of a service-provider Classless Inter-Domain Routing (CIDR) [RFC4632] block, and it gets aggregated into the larger block before being advertised into the global Internet 🌐 traditionally, IP multihoming meant each multihomed site acquired its own globally visible prefix. LISP only uses topologically assigned and aggregatable address blocks for RLOCs, which gets rid of this demonstrably non-scalable practice 💀🔥

to be continued… 🎀

3. Basic Overview 🎀

Okay so when you run lig, it sends a Map-Request for a destination EID. When a Map-Reply comes back, the contents get shown to you. Here's what you get to see ✨:

  • The EID-prefix for the site that the destination EID you queried matches.
  • The locator address of the Map Replier.
  • The Locator-Set for the mapping entry, which includes the locator address, up/down status, priority, and weight of each Locator.
  • 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>]

Parameter breakdown, bestie 💅:

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

So lig has two use cases 🦋. The first is querying the mapping database for a particular EID. The second is checking whether a site has registered successfully with a Map-Server.

We already covered the first one, so let's talk about the second. Checking your own registration is called "ligging yourself" 🫶, and here's how it goes down. In the lig initiator, a Map-Request is sent for one of the EIDs belonging to the initiator's site. That Map-Request then gets returned to one of the ETRs for the lig-initiating site. In response, a Map-Reply is sent back to the locator address of the lig initiator (and yes, the Map-Reply could be sent by the lig initiator itself 👀). The Map-Reply gets processed, and the mapping data for the lig-initiating site is displayed for the user. For the syntax, check out Section 4.1 for an implementation of "ligging yourself."

Lowkey though, for host-based implementations inside a LISP site, "lig self" isn't that useful, because the host may not have an RLOC to receive a Map-Reply with 😭. But lig can be used from a non-LISP site, and from infrastructure hosts too, to grab mapping information 🌸.

4. Implementation Details ⭐

4.1. LISP Router Implementation

The Cisco LISP prototype implementation supports lig for IPv4 and IPv6 💖. The command line looks like this:

lig <dest-eid> [source <source-eid>] [to <mr>] [count <1-5>]

This command starts the LISP Internet Groper. It's basically the DNS analogue dig, but it works on the LISP mapping database 🧚. When you invoke it, the local system sends a Map-Request to the configured Map-Resolver. When a Map-Reply comes back, its contents get displayed to the user. By default, up to three Map-Requests are sent if no Map-Reply comes back, but once a Map-Reply is returned, no other Map-Requests get 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 Virtual Routing and Forwarding (VRF) table. When <mr> is specified, the Map-Request goes to that address. Otherwise, the Map-Request goes to a configured Map-Resolver. If no Map-Resolver is configured, the Map-Request is sent on the ALT network, as long as the local router is attached to the ALT 🌈. When count <1-5> is specified, 1, 2, 3, 4, or 5 Map-Requests are sent.

Here's 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

Now, to "lig yourself," you use this syntax 🙈:

lig {self | self6} [source <source-eid>] [to <mr>] [count <1-5>]

This is the simple way to check whether your site is registered with the mapping database system ✅. The destination-EID for the Map-Request is 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 for the Map-Request is also 192.168.1.0 in this example, and the Map-Request goes to the configured Map-Resolver. If the Map-Resolver and Map-Server are the same LISP system, then "lig self" is testing whether the Map-Resolver can "turn back a Map-Request to the site." If a different Map-Resolver is used, it can test whether the site's EID-prefix has been injected into the ALT infrastructure. In that case, the lig Map-Request gets 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. Here, an xTR at the originating site sends a Map-Reply to the source of the Map-Request (which could be itself or another xTR for the site). All the other command parameters are described above. And "lig self6" tests registration of IPv6 EID-prefixes 💜.

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's a public domain implementation that can run on any x86-based system 🍓. The only requirement is that the system initiating lig must have an address assigned from the locator namespace.

lig [-d] <eid> -m <map-resolver> [-c <count>] [-t <timeout>]

Parameter breakdown:

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

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 version of lig lives at <http://github.com/LISPmob/lig> 🦋.

5. Testing the ALT 🔥

Sometimes a Map-Reply comes back from a lig request, but the user has no idea how much of the mapping infrastructure actually got tested 🤔. There are two cases to think about: avoiding the ALT, and traversing the ALT.

When an ITR sends a lig request to its Map-Resolver for a destination-EID, that Map-Resolver could also be configured as a Map-Server. And if the destination-EID belongs to a site that registers with this Map-Server, the Map-Request goes straight to the site without testing the ALT. That happens because the Map-Server is the source of the advertisement for the site's EID-prefix. So if the Map-Reply comes back to the lig-requesting site, you can't be sure other sites can reach the same destination-EID 😬.

If the Map-Resolver used is not a Map-Server for the EID-prefix being sought, then the ALT infrastructure can be tested. This test case checks the functionality of the Map-Resolver, the traversal of the ALT (testing BGP-over-GRE), and the Map-Server 🧠.

It is recommended that users issue two lig requests, so they send Map-Requests to different Map-Resolvers.

The network can have a LISP-ALT Router deployed as an "ALT looking-glass" node 👀. This type of router has BGP peering sessions with other ALT Routers, but it doesn't inject any EID-prefixes into the ALT. It just learns the 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 through the to <map-resolver> parameter on the lig command. The ALT looking-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 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's a web-based interface that does auto-polling with lig on the back-end, for most of the LISP sites on the LISP test network 💻. You can find the web page at <http://www.lisp4.net/status>.

There's also a LISP site monitoring web-based interface at <http://lispmon.net> 🌈.

And at <http://baldomar.ccaba.upc.edu/lispmon>, written by the folks at Universitat Politecnica de Catalunya (UPC), you can see a geographical map showing where each LISP site lives 🗺️. Iconic.

8. Security Considerations 🔐

The use of lig does not affect the security of the LISP infrastructure, because it's simply a tool that facilities diagnostic querying. For descriptions of the security properties of the LISP infrastructure, see [RFC6830], [RFC6836], and [RFC6833].

Here's the serious part, bestie 🫶. lig gives easy access to the information in the public mapping database. So it's really important to protect mapping information meant for private use. You can do that by disallowing access to specific mapping entries, or by placing those entries in a private mapping database system 🔒.

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 ✨

Okay bestie, these are the "extra reading" refs 📚 Not required to build the thing, but super useful for the full picture 🦋

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

Appendix A. Acknowledgments 💖

Huge shoutout 🫶 to John Zwiebel, Andrew Partan, Darrel Lewis, and Vince Fuller, who gave super important feedback on the 'lig' design and the prototype implementations. You literally made this better! 😭 Also a massive thank you to everyone on lisp-beta@external.cisco.com who tested 'lig' and is still testing it. You are all iconic 👑

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