LISP Frequently Asked Questions

Traditional Internet routing and addressing architectures use a single namespace, the IP address, to simultaneously express two functions about a device: its identity, and its location within the network. As often-quoted, Yakov's Law states [“Addressing can follow topology or topology can follow addressing; choose one” – Y. Rekhter]. One very visible and detrimental result of this single namespace has been manifested in the rapid growth of the Internet's DFZ (default-free zone) as a consequence of multihoming, traffic engineering, non-aggregatable address allocations, and business events such as mergers and acquisitions. The Internet Architecture Board's October 2006 Routing and Addressing Workshop recogized that the negatvie effects of the growth of the Internet routing table, as documented in RFC 4984, and initiating invesitgations of ID/locator separation options. Prior to LISP, the concepts of separating the locator and the identifier has been discussed for many years as a way to greatly reduce the size of the Internet DFZ. The protocol known as LISP comprises the development of specifications for the IETF. For routing to scale, locators need to be assigned according to topology and change as topology changes. LISP accomplishes this by adding the level of indirection between host IPs and Locaotr IPs.

LISP currently comprises several RFCs, and continues to be robustly developed within the IETF LISP Working Group. Currently, LISP includes RFCs 6830 thru 6836, and RFC 7052. In addition to leading this standards effort, Cisco is also developing LISP software for our platforms, as well as gaining working experience with LISP through the deployment and operation of a public LISP network. Cisco contributions to LISP are being developed as open standards, with no Cisco intellectual property rights (IPR). Cisco believes it is in the best interest of the overall Internet community to resolve the issues facing the Internet today. A healthy and growing Internet benefits everyone, including Cisco. Cisco has constantly sought to stimulate outside interest and development efforts from the outset. Other LISP development is being pursued by the competitive vendors, open source communities, and many researchers and universities.

At a high-level, the deployment of LISP seeks to minimize end-customer changes and deployment complexities. From the LISP perspective, there are essentially two areas to be considered:
* LISP sites: LISP sites use IP addresses in the EID namespace to address hosts (and in Domain Name System (DNS)) in exactly the same way they are currently used. These addresses are not advertised within the non-LISP RLOC namespace (e.g., the Internet), but instead are advertised into and by the LISP mapping services. LISP site routers supports the LISP functionality of Ingress Tunnel Router (ITR) and Egress Tunnel Router (ETR).
* LISP infrastructure: To fully implement LISP with Internet scale and interoperability between LISP and non-LISP sites, additional LISP Infrastructure components are required to support the LISP EID-to-RLOC mapping services provides the "EID-to-RLOC" mapping (much in the same way that the URL-to-IP address mapping function is resolved by DNS), and LISP/non-LISP interworking. These LISP infrastructure functions include the Map-Server (MS), Map-Resolver (MR), Proxy Ingress Tunnel Router (PITR), and Proxy Egress Tunnel Router (PETR). These infrastructure services are most efficiently provided as a mapping service in a fashion similar to how DNS services are provided today. Also in a similar fashion to DNS, these LISP services can be jointly provided in both private and public implementations.

The specific functions used by LISP (and how they might be deployed on devices) are listed here.
* LISP site functions:
- ITR: An Ingress Tunnel Router (ITR) performs seveal operations. On the data plane side, an ITR receives packets from site-facing interfaces and either LISP-encapsulates packets to remote LISP sites, or natively forwards packets to non-LISP sites. On the control plane side, an ITR sends map requests and processes received map replies in order to resolve EID-to-RLOC mappings.
- ETR: An Egress Tunnel Router (ETR) performs seveal operations. On the data plane side, an ETR receives packets from core-facing interfaces, de-encapsulates them, and delivers them to local EIDs at the site. On the control plane side, an ETR registers its EID prefixes and RLOCs with the Map-Server, and responds to map requests received from the Map-Server.
In most cases, a LISP site edge device will implement both ITR and ETR functions; in this mode it is commonly referred to as an xTR.
* LISP infrastructure functions:
- MS: A Map-Server (MS) is a control plane only device. An MS receives Map-Registration messages from LISP sites. It also receives Map-Requests (via the Mapping System) seeking mapping resolutions for EID prefixes and forwards them to the registered ETR that is authoritative for the EID prefix being queried.
- MR: A Map-Resolver (MR) is a control plane only device. An MR receives map requests from ITRs and forwards them to the Mapping System (resulting in an MS receiving the Map-Request). An MR MR also sends negative map replies to ITRs in response to queries for non-LISP addresses.
- PITR: A Proxy ITR provides connectivity between non-LISP sites and LISP sites by advertising coarse-aggregate prefixes for the LISP EID namespace into the non-LISP core network (e.g., the Internet DFZ) and LISP-encapsulating this non-LISP sourced-traffic to LISP sites. (This functionality allows all LISP sites to take advantge of all LISP features without requiring all or some major percentage of the world to speak LISP before benefits are seen. In fact, even the very first (and only) LISP site sees benefit from LISP day-one).
- PETR: A Proxy ETR allows LISP sites to support cross-address family functionality. For example, a LISP site with IPv6 EIDs and and only IPv4 WAN (RLOC) connectivity can reach non-LISP destinations in IPv6 space by encapsulating packets to a (dual-stack) PETR. A PETR can also allows LISP sites with Unicast Reverse Path Forwarding (URPF) restrictions to reach non-LISP sites.
- RTR: A Re-Encapsulating Tunnel Router is a special version of a PITR/PETR that assist LISP-to-LISP communications when underlay issues prevent direction comminication. Situations that can prevent any networks from communicating directly (not just LISP) include: "disjointed RLOC space" and NAT. For example, say that a global enterprise builds a VPN and some sites are connected only to the IPv4 Internet (in the US for example, because this is the cheapest access), and other sites are connected only to the IPv6 Internet (in Asia for example, because this is the cheapest access). How does traffic traverse the VPN? A dual-stack RTR can receive LISP-encapsulated traffic in on one AF, decapsulate it, and then re-encapsulate it into the other AF and deliver it. NAT also offers similar obstacles. Say an enterprise site is connected to the Internet via LTE but the IP address it receives is behind NAT (quite typical). How do other sites communicate with this NAT'd site? How do you build a VPN between NAT'd sites? Use the RTR of course.

Cisco supports all of the LISP components at this time. Due to the variations in requirements imposed by each device's needs, certain LISP devices are supported by different Cisco platforms. Always refer to the Release Notes for current information on supported platforms and LISP functions, located at

LISP HW/SW

When an ITR receives a packet from a site-facing interface, it first does a destination lookup, with the possibility of one of two outcomes. If the lookup returns a non-default destination, the ITR forwards the packet to that destination natively since the destination is "known to routing" and routing takes precedence. If the lookup returns a match against and existing map-cache entry, then the ITR encapsulated using that map-cache policy and forwarded to the remote LISP destination. If a map-cache entry does not exist, and the packet matches the default route or "no route," the ITR sends a map request for the destination EID in question to its configured Map-Resolver. This map request is handled by the Mapping System and reaches the Map-Server to which the destination ETR is registered, and finally to the destination ETR. The ETR responds directly to the ITR with a map-reply, which the ITR adds to its map cache. The ITR can now forward LISP packets between its EID and the destination EID. When the LISP ETR receives the LISP packet, it de-encapsulates it, and then forwards it to the original (EID) destination IP address.

When an ITR receives a packet from a site-facing interface, it first does a destination lookup, with the possibility of one of two outcomes. If the lookup returns a non-default destination, the ITR forwards the packet to that destination natively (without LISP encapsulation) since the destination is "known to routing" and routing takes precedence. If the ITR is configured to use a PETR for egress traffic, instead of forwarding the packet natively, it LISP-encapsulates the packet to the configured PETR, which decapsulates the packet and forwards it natively. Because the destination IP address is known within the Internet DFZ, the packet is routed natively to the destination. Return traffic must be handled by a Proxy Ingress Tunnel Router (PITR). A PITR advertises coarse-aggregate prefixes for the LISP EID namespace into the Internet DFZ, thus attracting non-LISP traffic destined to LISP sites. This traffic is then encapsulated and forwarded to the LISP site in just the same way an ITR communicates with a LISP site.

LISP provides support for both IPv4 and IPv6 EIDs and IPv4 and IPv6 RLOCs. Because of this, it can function in any of four ways: IPv4-to-IPv4 over IPv4, IPv4-to-IPv4 over IPv6, IPv6-to-IPv6 over IPv6, and IPv6-to-IPv6 over IPv4. LISP does not translate between the IPv4 and IPv6 EID namespaces. Interworking between LISP and non-LISP sites requires the PITR/PETR (or RTR) infrastructure.

LISP encapsulation adds 36 bytes (IPv4) or 56 bytes (IPv6) to the original packet size. As with other protocols that encapsulate or tunnel traffic (e.g., IP Security [IPsec] and generic routing encapsulation [GRE]), it is possible that the resultant encapsulated packet length could exceed the permissible MTU somewhere along the transit path. LISP provides both stateful and stateless mechanisms for handling potential MTU issues, with the main goals being: (1) to prevent packets from being dropped, and (2) to prevent the need for ETRs to perform packet reassembly prior to LISP de-encapsulation.

Yes, LISP can be deployed within a NAT environment. NAT can be invovled on the EID side or the RLOC side, but the deployment requirements are different. When NAT is considered for EID space, that is, when private addresses are used on hosts behind NAT, these private addresses are first translated into global addresses within the LISP EID namespace. These packets then follow the normal LISP encapsulation process, with the outer (LISP) header using the RLOC address. Thus, the outside world only sees these global addresses in both namespaces: the EIDs in the inner header, and the RLOCs in the outer header. The original, private addresses are held only within the NAT state. When NAT is considered for RLOC space, that is, the local RLOC known to the xTR appears to the global world as a different (NAT'd) address, the Mapping System must be aware that the xTR is behind NAT, and an RTR must (Currently) be used to handle traffic flows to and from the xTR behidn NAT. A detailed description of this form is covered in the in the NAT traversal for LISP draft.

LISP was initially conceived to address Internet DFZ scalability issues. However, once the functionality of splitting IP identity and location is available, many potential benefits are possible. Some of the important use cases being developed include:
* Low OpEx, BGP-free multihoming with site-based policy control (ingress tunnel engineering)
* Multi-Address-Family Support (v4/v4, v4/v6, v6/v4, v6/v6)
* High-Scale virtualization/VPN support, with or without encryption
* Data Center Host Mobility "extending subnets" or "across subnets"
* LISP Mobile Node client

Multihomed sites traditionally require the use of external Border Gateway Protocol (eBGP) to advertise site prefixes to multiple upstream providers. (NAT is also a possibility, but with signficantly restricted flexibility). Note that just using BGP also requires (1) a preimum circuit from a proivder who will run BGP with you, an Autonomous System Number (ASN), and "proivder independent" (PI) address allocation from a regional Internet registry (RIR). The OpEx is often high due to configuration complexity and significant BGP parameter tuning requirements (with a considerable expertise level) to achieve basic traffic manipulation. By employing LISP in a multihomed environment, the need for eBGP peering with upstream providers is eliminated, and administrators can set the ingress traffic policy directly through the mapping parameters. Thus, LISP simplifies multihoming and allows for greater control of the ingress traffic policy.

The deployment of LISP on customer premises equipment (CPE) router can benefit even devices with a single connection to the Internet. The most obvious and direct benefit is that in this case LISP gives provider independence. If the site wishes to change providers, only the RLOC need change. All other site addresses (EIDs) and DNS entries remain unchanged, eliminating the need for renumbering. In addition, this change can be made seamlessly by adding the new RLOC to the site, adding it to the LISP policy, and then removing the old RLOC from the LISP policy. Thus, no traffic disruptions need occur during the transition. Since the EID prefix is never in the Internet DFZ, this also helps scale the core. In addition, all other "LISP benefits" become availble - such as: running IPv6 with an IPv4 WAN link (or vice versa), running multiple VRFs internally and sharing a single core network (e.g. the Internet), and enabling host mobility for disaster revoery for example.

The deployment of LISP in the data center enables an architectural paradigm shift by using local instances of the LISP mapping database and its infrastructure components for server reachability instead of traditional, topologically dependent, hop-by-hop routing protocols. This lowers the network OpEx by making the core much simpler by allowing it to just move packets. In addition, and more importantly, because the servers' identifiers (EIDs) are separated from their location (RLOC), "movement" can now occur by simply changing the locator while keeping the EID fixed. This same feature of LISP that enables you to change service providers also allows you to change the location of a device or cloud while keeping the identifiers fixed. This, for example, allows TCP connections to remain established during these changes. Virtual machine mobility is enabled by this same concept. All this can be done because the identifier is not in the underlying routing system.

Cisco has been supporting the open source community to build an interoperabile LISP Mobile Node client Additional information and the latest downloads are available at lispmob.org

LISP can help in a number of ways. First, LISP provides mechanisms for encapsulating IPv6 host packets using IPv4 locators (or IPv4 host packets and IPv6 locators). Thus, you can build IPv6 islands and connect them using your existing IPv4 Internet connectivity. This may allow you to gain experience with IPv6 before investing in additional infrastructure. In addition, when the LISP infrastructure also includes the use of a PETR that has both IPv4 and IPv6 connectivity into the Internet, your LISP IPv6 site can also connect with non-LISP IPv6 sites. LISP can also be used to stitch together remotes sites - some with IPv4 connectivtiy and some with IPv6 connectivity - to form one seemless VPN overlay.

Visit the Cisco LISP product information page