LISP
LISP (Locator/ID Separation Protocol)
Within this page
LISP RFCs (34)
RFC 10040: Locator/ID Separation Protocol (LISP) Geo-Coordinates
Experimental- D. Farinacci
- September 2026
- IETF publication
- Routing Area
Abstract
This document describes how Geo-Coordinates can be used in the Locator/ID Separation Protocol (LISP) and defines a new LISP Canonical Address Format (LCAF) encoding for such Geo-Coordinates.
This document updates RFC 8060.
Abstract
This document describes how Geo-Coordinates can be used in the Locator/ID Separation Protocol (LISP) and defines a new LISP Canonical Address Format (LCAF) encoding for such Geo-Coordinates.
This document updates RFC 8060.
RFC 9962: A Decentralized Locator/ID Separation Protocol Mapping System (LISP-Decent)
Informational- D. Farinacci
- C. Cantrell
- May 2026
- Independent Stream publication
Abstract
This document describes how the Locator/ID Separation Protocol (LISP)
Mapping System can be distributed for scale and decentralized for
management, while maintaining trust among data plane nodes. This is
an Informational RFC and should be used by LISP-Decent
implementations to interoperate with each other.
Abstract
This document describes how the Locator/ID Separation Protocol (LISP)
Mapping System can be distributed for scale and decentralized for
management, while maintaining trust among data plane nodes. This is
an Informational RFC and should be used by LISP-Decent
implementations to interoperate with each other.
RFC 9798: PIM Join/Prune Attributes for Locator/ID Separation Protocol (LISP) Environments Using Underlay Multicast
Experimental- V. Govindan
- S. Venaas
- June 2025
- IETF publication
- Routing Area
Abstract
This document specifies an update to the Receiver RLOC (Routing Locator) field of the PIM Join/Prune attribute that supports the construction of multicast distribution trees where the source and receivers are located in different Locator/ID Separation Protocol (LISP) sites and are connected using underlay IP multicast. This attribute allows the receiver site to signal the underlay multicast group to the control plane of the root Ingress Tunnel Router (ITR). This document updates RFC 8059.
Abstract
This document specifies an update to the Receiver RLOC (Routing Locator) field of the PIM Join/Prune attribute that supports the construction of multicast distribution trees where the source and receivers are located in different Locator/ID Separation Protocol (LISP) sites and are connected using underlay IP multicast. This attribute allows the receiver site to signal the underlay multicast group to the control plane of the root Ingress Tunnel Router (ITR). This document updates RFC 8059.
RFC 9735: Locator/ID Separation Protocol (LISP) Distinguished Name Encoding
Proposed Standard- D. Farinacci
- L. Iannone
- February 2025
- IETF publication
- Routing Area
Abstract
This document defines how to use the Address Family Identifier (AFI) 17 "Distinguished Name" in the Locator/ID Separation Protocol (LISP). LISP introduces two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). Distinguished Names (DNs) can be used in either EID-Records or RLOC-Records in LISP control messages to convey additional information.
Abstract
This document defines how to use the Address Family Identifier (AFI) 17 "Distinguished Name" in the Locator/ID Separation Protocol (LISP). LISP introduces two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). Distinguished Names (DNs) can be used in either EID-Records or RLOC-Records in LISP control messages to convey additional information.
RFC 9706: TreeDN: Tree-Based Content Delivery Network (CDN) for Live Streaming to Mass Audiences
Informational- L. Giuliano
- C. Lenart
- R. Adam
- January 2025
- IETF publication
- Operations and Management Area
Abstract
As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support formats and applications such as 4K, 8K, and Augmented Reality (AR), live streaming can place a unique type of stress upon network resources. TreeDN is a tree-based Content Delivery Network (CDN) architecture designed to address the distinctive scaling challenges of live streaming to mass audiences. TreeDN enables operators to offer Replication-as-a-Service (RaaS) at a fraction of the cost of traditional, unicast-based CDNs -- in some cases, at no additional cost to the infrastructure. In addition to efficiently utilizing network resources to deliver existing multi-destination traffic, this architecture also enables new types of content and use cases that previously were not possible or economically viable using traditional CDN approaches. Finally, TreeDN is a decentralized architecture and a democratizing technology that makes content distribution more accessible to more people by dramatically reducing the costs of replication.
Abstract
As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support formats and applications such as 4K, 8K, and Augmented Reality (AR), live streaming can place a unique type of stress upon network resources. TreeDN is a tree-based Content Delivery Network (CDN) architecture designed to address the distinctive scaling challenges of live streaming to mass audiences. TreeDN enables operators to offer Replication-as-a-Service (RaaS) at a fraction of the cost of traditional, unicast-based CDNs -- in some cases, at no additional cost to the infrastructure. In addition to efficiently utilizing network resources to deliver existing multi-destination traffic, this architecture also enables new types of content and use cases that previously were not possible or economically viable using traditional CDN approaches. Finally, TreeDN is a decentralized architecture and a democratizing technology that makes content distribution more accessible to more people by dramatically reducing the costs of replication.
RFC 9437: Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP)
Proposed Standard- A. Rodriguez-Natal
- V. Ermagan
- A. Cabellos
- S. Barkai
- M. Boucadair
- August 2023
- IETF publication
- Routing Area
Abstract
This document specifies an extension to the Locator/ID Separation Protocol (LISP) control plane to enable Publish/Subscribe (PubSub) operation.
Abstract
This document specifies an extension to the Locator/ID Separation Protocol (LISP) control plane to enable Publish/Subscribe (PubSub) operation.
RFC 9299: An Architectural Introduction to the Locator/ID Separation Protocol (LISP)
Informational- A. Cabellos
- D. Saucez
- October 2022
- IETF publication
- Routing Area
Abstract
This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes; more details can be found in the protocol specifications, RFCs 9300 and 9301.
Abstract
This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes; more details can be found in the protocol specifications, RFCs 9300 and 9301.
RFC 9300: The Locator/ID Separation Protocol (LISP)
Proposed Standard- D. Farinacci
- V. Fuller
- D. Meyer
- D. Lewis
- A. Cabellos
- October 2022
- IETF publication
- Routing Area
Abstract
This document describes the data plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces: Endpoint Identifiers (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify network attachment points. With this, LISP effectively separates control from data and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.
LISP requires no change to either host protocol stacks or underlay routers and offers Traffic Engineering (TE), multihoming, and mobility, among other features.
This document obsoletes RFC 6830.
Abstract
This document describes the data plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces: Endpoint Identifiers (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify network attachment points. With this, LISP effectively separates control from data and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.
LISP requires no change to either host protocol stacks or underlay routers and offers Traffic Engineering (TE), multihoming, and mobility, among other features.
This document obsoletes RFC 6830.
RFC 9301: Locator/ID Separation Protocol (LISP) Control Plane
Proposed Standard- D. Farinacci
- F. Maino
- V. Fuller
- A. Cabellos
- October 2022
- IETF publication
- Routing Area
Abstract
This document describes the control plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provide a simplified "front end" for one or more Endpoint IDs (EIDs) to Routing Locator mapping databases.
By using this control plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems; this behavior facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP control plane infrastructure, connecting EID addressable nodes of a LISP site, the implementation and operational complexity of the overall cost and effort of deploying LISP is reduced.
This document obsoletes RFCs 6830 and 6833.
Abstract
This document describes the control plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provide a simplified "front end" for one or more Endpoint IDs (EIDs) to Routing Locator mapping databases.
By using this control plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems; this behavior facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP control plane infrastructure, connecting EID addressable nodes of a LISP site, the implementation and operational complexity of the overall cost and effort of deploying LISP is reduced.
This document obsoletes RFCs 6830 and 6833.
RFC 9302: Locator/ID Separation Protocol (LISP) Map-Versioning
Proposed Standard- L. Iannone
- D. Saucez
- O. Bonaventure
- October 2022
- IETF publication
- Routing Area
Abstract
This document describes the Locator/ID Separation Protocol (LISP) Map-Versioning mechanism, which provides in-packet information about Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. This approach is based on associating a version number to EID-to-RLOC mappings and transporting such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is optional and transparent to implementations not supporting this feature, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support or do not want to use the mechanism.
This document obsoletes RFC 6834, which is the initial experimental specifications of the mechanisms updated by this document.
Abstract
This document describes the Locator/ID Separation Protocol (LISP) Map-Versioning mechanism, which provides in-packet information about Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. This approach is based on associating a version number to EID-to-RLOC mappings and transporting such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is optional and transparent to implementations not supporting this feature, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support or do not want to use the mechanism.
This document obsoletes RFC 6834, which is the initial experimental specifications of the mechanisms updated by this document.
RFC 9303: Locator/ID Separation Protocol Security (LISP-SEC)
Proposed Standard- F. Maino
- V. Ermagan
- A. Cabellos
- D. Saucez
- October 2022
- IETF publication
- Routing Area
Abstract
This memo specifies Locator/ID Separation Protocol Security (LISP-SEC), a set of security mechanisms that provides origin authentication, integrity, and anti-replay protection to the LISP's Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mapping data conveyed via the mapping lookup process. LISP-SEC also enables verification of authorization on EID-Prefix claims in Map-Reply messages.
Abstract
This memo specifies Locator/ID Separation Protocol Security (LISP-SEC), a set of security mechanisms that provides origin authentication, integrity, and anti-replay protection to the LISP's Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mapping data conveyed via the mapping lookup process. LISP-SEC also enables verification of authorization on EID-Prefix claims in Map-Reply messages.
RFC 9304: Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations
Proposed Standard- M. Boucadair
- C. Jacquenet
- October 2022
- IETF publication
- Routing Area
Abstract
This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP Packet Type codepoint for each extension.
This document obsoletes RFC 8113.
Abstract
This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP Packet Type codepoint for each extension.
This document obsoletes RFC 8113.
RFC 9305: Locator/ID Separation Protocol (LISP) Generic Protocol Extension
Proposed Standard- F. Maino
- J. Lemon
- P. Agarwal
- D. Lewis
- M. Smith
- October 2022
- IETF publication
- Routing Area
Abstract
This document describes extensions to the Locator/ID Separation Protocol (LISP) data plane, via changes to the LISP header, to support multiprotocol encapsulation and allow the introduction of new protocol capabilities.
Abstract
This document describes extensions to the Locator/ID Separation Protocol (LISP) data plane, via changes to the LISP header, to support multiprotocol encapsulation and allow the introduction of new protocol capabilities.
RFC 9306: Vendor-Specific LISP Canonical Address Format (LCAF)
Experimental- A. Rodriguez-Natal
- V. Ermagan
- A. Smirnov
- V. Ashtaputre
- D. Farinacci
- October 2022
- IETF publication
- Routing Area
Abstract
This document describes a new Locator/ID Separation Protocol (LISP) Canonical Address Format (LCAF), the Vendor-Specific LCAF. This LCAF enables organizations to have implementation-specific encodings for LCAF addresses. This document updates RFC 8060.
Abstract
This document describes a new Locator/ID Separation Protocol (LISP) Canonical Address Format (LCAF), the Vendor-Specific LCAF. This LCAF enables organizations to have implementation-specific encodings for LCAF addresses. This document updates RFC 8060.
RFC 8378: Signal-Free Locator/ID Separation Protocol (LISP) Multicast
Experimental- V. Moreno
- D. Farinacci
- May 2018
- IETF publication
- Routing Area
Abstract
When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism described in this document uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites.
Abstract
When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism described in this document uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites.
RFC 8111: Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)
Experimental- V. Fuller
- D. Lewis
- V. Ermagan
- A. Jain
- A. Smirnov
- May 2017
- IETF publication
- Routing Area
Abstract
This document describes the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (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.
Abstract
This document describes the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (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.
RFC 8112: Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG)
Informational- D. Farinacci
- A. Jain
- I. Kouvelas
- D. Lewis
- May 2017
- Independent Stream publication
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.
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.
RFC 8113: Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations
Experimental- M. Boucadair
- C. Jacquenet
- March 2017
- IETF publication
- Routing Area
Abstract
This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. It also defines a registry for LISP Packet Type allocations, thus updating RFC 6830.
- Obsoleted by RFC 9304
Abstract
This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. It also defines a registry for LISP Packet Type allocations, thus updating RFC 6830.
RFC 8060: LISP Canonical Address Format (LCAF)
Experimental- D. Farinacci
- D. Meyer
- J. Snijders
- February 2017
- IETF publication
- Routing Area
Abstract
This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System.
Abstract
This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System.
RFC 8061: Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality
Experimental- D. Farinacci
- B. Weis
- February 2017
- IETF publication
- Routing Area
Abstract
This document describes a mechanism for encrypting traffic encapsulated using the Locator/ID Separation Protocol (LISP). The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data plane from third-party surveillance attacks.
Abstract
This document describes a mechanism for encrypting traffic encapsulated using the Locator/ID Separation Protocol (LISP). The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data plane from third-party surveillance attacks.
RFC 8059: PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments
Experimental- J. Arango
- S. Venaas
- I. Kouvelas
- D. Farinacci
- January 2017
- IETF publication
- Routing Area
Abstract
This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol (LISP) sites. These attributes allow the receiver site to select between unicast and multicast underlying transport and to convey the RLOC (Routing Locator) address of the receiver ETR (Egress Tunnel Router) to the control plane of the root ITR (Ingress Tunnel Router).
Abstract
This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol (LISP) sites. These attributes allow the receiver site to select between unicast and multicast underlying transport and to convey the RLOC (Routing Locator) address of the receiver ETR (Egress Tunnel Router) to the control plane of the root ITR (Ingress Tunnel Router).
RFC 7954: Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block
Historic- L. Iannone
- D. Lewis
- D. Meyer
- V. Fuller
- September 2016
- IETF publication
- Routing Area
Abstract
This document directs IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as Endpoint Identifier (EID) addressing space.
Abstract
This document directs IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as Endpoint Identifier (EID) addressing space.
RFC 7955: Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block
Historic- L. Iannone
- R. Jorgensen
- D. Conrad
- G. Huston
- September 2016
- IETF publication
- Routing Area
Abstract
This document proposes a framework for the management of the Locator/ ID Separation Protocol (LISP) Endpoint Identifier (EID) address block. The framework described relies on hierarchical distribution of the address space, granting temporary usage of prefixes of such space to requesting organizations.
Abstract
This document proposes a framework for the management of the Locator/ ID Separation Protocol (LISP) Endpoint Identifier (EID) address block. The framework described relies on hierarchical distribution of the address space, granting temporary usage of prefixes of such space to requesting organizations.
RFC 7834: Locator/ID Separation Protocol (LISP) Impact
Informational- D. Saucez
- L. Iannone
- A. Cabellos
- F. Coras
- April 2016
- IETF publication
- Routing Area
Abstract
The Locator/ID Separation Protocol (LISP) aims to improve the Internet routing scalability properties by leveraging three principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment of LISP can have on both the routing infrastructure and the end user.
Abstract
The Locator/ID Separation Protocol (LISP) aims to improve the Internet routing scalability properties by leveraging three principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment of LISP can have on both the routing infrastructure and the end user.
RFC 7835: Locator/ID Separation Protocol (LISP) Threat Analysis
Informational- D. Saucez
- L. Iannone
- O. Bonaventure
- April 2016
- IETF publication
- Routing Area
Abstract
This document provides a threat analysis of the Locator/ID Separation Protocol (LISP).
Abstract
This document provides a threat analysis of the Locator/ID Separation Protocol (LISP).
RFC 7215: Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations
Experimental- L. Jakab
- A. Cabellos-Aparicio
- F. Coras
- J. Domingo-Pascual
- D. Lewis
- April 2014
- IETF publication
- Routing Area
Abstract
This document is a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer 2013. LISP deployment scenarios may have evolved since then. This memo represents one stable point in that evolution of understanding.
Abstract
This document is a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer 2013. LISP deployment scenarios may have evolved since then. This memo represents one stable point in that evolution of understanding.
RFC 7052: Locator/ID Separation Protocol (LISP) MIB
Experimental- G. Schudel
- A. Jain
- V. Moreno
- October 2013
- IETF publication
- Routing Area
Abstract
This document defines the MIB module that contains managed objects to support the monitoring devices of the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information, LISP functional status, and operational counters and other statistics.
Abstract
This document defines the MIB module that contains managed objects to support the monitoring devices of the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information, LISP functional status, and operational counters and other statistics.
RFC 6830: The Locator/ID Separation Protocol (LISP)
Experimental- D. Farinacci
- V. Fuller
- D. Meyer
- D. Lewis
- January 2013
- IETF publication
- Routing Area
Abstract
This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offers Traffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites.
Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. This document defines an Experimental Protocol for the Internet community.
- Obsoleted by RFC 9300, RFC 9301
Abstract
This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offers Traffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites.
Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. This document defines an Experimental Protocol for the Internet community.
RFC 6831: The Locator/ID Separation Protocol (LISP) for Multicast Environments
Experimental- D. Farinacci
- D. Meyer
- J. Zwiebel
- S. Venaas
- January 2013
- IETF publication
- Routing Area
Abstract
This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture. This document defines an Experimental Protocol for the Internet community.
Abstract
This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture. This document defines an Experimental Protocol for the Internet community.
RFC 6832: Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites
Experimental- D. Lewis
- D. Meyer
- D. Farinacci
- V. Fuller
- January 2013
- IETF publication
- Routing Area
Abstract
This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running LISP. A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts. Second, this document adds Network Address Translation (NAT) functionality to LISP ITRs and LISP Egress Tunnel Routers (ETRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. This document defines an Experimental Protocol for the Internet community.
Abstract
This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running LISP. A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts. Second, this document adds Network Address Translation (NAT) functionality to LISP ITRs and LISP Egress Tunnel Routers (ETRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. This document defines an Experimental Protocol for the Internet community.
RFC 6833: Locator/ID Separation Protocol (LISP) Map-Server Interface
Experimental- V. Fuller
- D. Farinacci
- January 2013
- IETF publication
- Routing Area
Abstract
This document describes the Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP- speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases.
By using this service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. This document defines an Experimental Protocol for the Internet community.
- Obsoleted by RFC 9301
Abstract
This document describes the Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP- speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases.
By using this service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. This document defines an Experimental Protocol for the Internet community.
RFC 6834: Locator/ID Separation Protocol (LISP) Map-Versioning
Experimental- L. Iannone
- D. Saucez
- O. Bonaventure
- January 2013
- IETF publication
- Routing Area
Abstract
This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. This document defines an Experimental Protocol for the Internet community.
- Obsoleted by RFC 9302
Abstract
This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. This document defines an Experimental Protocol for the Internet community.
RFC 6835: The Locator/ID Separation Protocol Internet Groper (LIG)
Informational- D. Farinacci
- D. Meyer
- January 2013
- IETF publication
- Routing Area
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. This document is not an Internet Standards Track specification; it is published for informational purposes.
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. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC 6836: Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)
Experimental- V. Fuller
- D. Farinacci
- D. Meyer
- D. Lewis
- January 2013
- IETF publication
- Routing Area
Abstract
This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map-Resolver (MR) to find the Egress Tunnel Router (ETR) that holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and Generic Routing Encapsulation (GRE). This document defines an Experimental Protocol for the Internet community.
Abstract
This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map-Resolver (MR) to find the Egress Tunnel Router (ETR) that holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and Generic Routing Encapsulation (GRE). This document defines an Experimental Protocol for the Internet community.
Subscribe to LISP
Get notified when:
- RFC changes to status, obsoleted by, updates, updated by, or subseries.
- New RFC added to this subject or below
- The subject was merged into another.