An Architectural Introduction to the Locator/ID Separation Protocol (LISP)Universitat Politecnica de Catalunyac/ Jordi Girona s/nBarcelona08034Spainacabello@ac.upc.eduInria2004 route des Lucioles - BP 93Sophia AntipolisFrancedamien.saucez@inria.fr
Routing Area
lispLISPArchitectureThis 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.Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 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
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Definitions of Terms
. LISP Architecture
. Design Principles
. Overview of the Architecture
. Data Plane
. LISP Encapsulation
. LISP Forwarding State
. Control Plane
. LISP Mappings
. Mapping System Interface
. Mapping System
. Internetworking Mechanisms
. LISP Operational Mechanisms
. Cache Management
. RLOC Reachability
. ETR Synchronization
. MTU Handling
. Mobility
. Multicast
. Use Cases
. Traffic Engineering
. LISP for IPv6 Co-existence
. LISP for Virtual Private Networks
. LISP for Virtual Machine Mobility in Data Centers
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
. A Brief History of Location/Identity Separation
. Old LISP Models
Acknowledgments
Authors' Addresses
IntroductionThis document introduces the Locator/ID Separation Protocol (LISP) architecture
, its
main operational mechanisms, and its design rationale. Fundamentally, LISP is
built following a well-known architectural idea: decoupling the overloaded semantics of IP addresses. As pointed out by , currently, IP addresses identify
both the topological location of a network attachment point as well
as the node's identity. However, nodes and
routing have fundamentally different requirements. On one hand,
routing systems require that addresses be aggregatable and have
topological meaning; on the other hand, nodes must be identified
independently of their current location .LISP creates two separate namespaces, Endpoint Identifiers (EIDs) and
Routing Locators (RLOCs). Both are
syntactically identical to the current IPv4 and IPv6 addresses. However, EIDs
are used to uniquely identify nodes irrespective of their topological
location and are typically routed intra-domain. RLOCs are assigned
topologically to network attachment points and are typically routed
inter-domain. With LISP, the edge of the Internet (where the nodes
are connected) and the core (where inter-domain routing occurs) can be
logically separated. LISP-capable routers interconnect the two logical spaces.
LISP also introduces a database, called the
Mapping System, to store and retrieve mappings between identity and
location. LISP-capable routers exchange packets over the Internet
core by encapsulating them to the appropriate location.In summary:
RLOCs have meaning only in the underlay network, that is, the
underlying core routing system.
EIDs have meaning only in the overlay network, which is the
encapsulation relationship between LISP-capable routers.
The LISP edge maps EIDs to RLOCs.
Within the underlay network, RLOCs have both Locator and
identifier semantics.
An EID within a LISP site carries both identifier and Locator
semantics to other nodes within that site.
An EID within a LISP site carries identifier and limited Locator
semantics to nodes at other LISP sites (i.e., enough Locator
information to tell that the EID is external to the site).
The relationship described above is not unique to LISP, and it is
common to other overlay technologies. The initial motivation in the LISP effort is to be found in the
routing scalability problem , where, if LISP were to be
completely deployed, the Internet core is populated with RLOCs while
Traffic Engineering (TE) mechanisms are pushed to the Mapping System.
In such a scenario, RLOCs are quasi-static (i.e., low
churn), hence making the routing system scalable , while EIDs can roam anywhere with no churn to the
underlying global routing system.
discusses the impact of LISP on the global routing system during the
transition period. However, the separation between location and identity
that LISP offers makes it suitable for use in additional scenarios, such
as TE, multihoming, and mobility among others.This document describes the LISP architecture and its main
operational mechanisms as well as its design rationale. It is important
to note that this document does not specify or complement LISP. The
interested reader should refer to the main LISP
specifications (see and ), as well as the
complementary documents (i.e., , , , , , and ) for the
protocol specifications along with the LISP deployment guidelines .Definitions of Terms
Endpoint Identifier (EID):
Addresses used to uniquely identify nodes irrespective
of their topological location. Typically routed
intra-domain.
Routing Locator (RLOC):
Addresses assigned topologically to network attachment
points. Typically routed inter-domain.
Ingress Tunnel Router (ITR):
A LISP-capable router that encapsulates packets from a LISP site
towards the core network.
Egress Tunnel Router (ETR):
A LISP-capable router that decapsulates packets from the core of
the network towards a LISP site.
xTR:
A router that implements both ITR and ETR functionalities.
Map-Request:
A LISP signaling message used to request an EID-to-RLOC mapping.
Map-Reply:
A LISP signaling message sent in response to a Map-Request that
contains a resolved EID-to-RLOC mapping.
Map-Register:
A LISP signaling message used to register an EID-to-RLOC
mapping.
Map-Notify:
A LISP signaling message sent in response of a Map-Register to
acknowledge the correct reception of an EID-to-RLOC mapping.
This document describes the LISP architecture and does not introduce
any new terms. The reader is referred to ,
, ,
, ,
, , , and for the complete definition of
terms.LISP ArchitectureThis section presents the LISP architecture. It first details the
design principles of LISP, and then it proceeds to describe its main aspects:
data plane, control plane, and internetworking mechanisms.Design PrinciplesThe LISP architecture is built on top of four basic design
principles:
Locator/Identifier split:
Decoupling the overloaded semantics of current IP addresses
allows devices to have identity-based addresses that are separate
from topologically meaningful addresses. By allowing only the
topologically meaningful addresses to be exposed to the Internet
core, those topologically meaningful addresses can be aggregated to
support substantial scaling. Individual devices are assigned
identity-based addresses that are not used for forwarding in the
Internet core.
Overlay architecture:
This architecture overlays route packets over the current Internet, allowing
deployment of new protocols without changing the current
infrastructure; hence, this results in a low deployment cost.
Decoupled data plane and control plane:
Separating the
data plane from the control plane allows them to scale independently
and use different architectural approaches. This is important given
that they typically have different requirements and allows for other
data planes to be added. Even though the data plane and the control plane are
decoupled, they are not completely isolated, because the LISP data plane may trigger
control plane activity.
Incremental deployability:
This principle ensures that the protocol interoperates with the
legacy Internet while providing some of the targeted benefits to
early adopters.
Overview of the ArchitectureLISP architecturally splits the core from the edge of the
Internet by creating two separate namespaces: Endpoint
Identifiers (EIDs) and Routing Locators (RLOCs). The edge
consists of LISP sites (e.g., an Autonomous System) that use
EID addresses. EIDs are IPv4 or IPv6 addresses that uniquely
identify communication end hosts and are assigned and
configured by the same mechanisms that exist at the time of
this writing. EIDs do not contain inter-domain topological
information, and because of this, EIDs are usually routable at
the edge (within LISP sites) but not in the core; see
for discussion of LISP site
internetworking with non-LISP sites and domains in the
Internet.LISP sites (at the edge) are connected to the interconnecting core
of the Internet by means of LISP-capable routers (e.g., border
routers). LISP sites are connected across the interconnecting core of the Internet
using tunnels between the LISP-capable routers. When packets
originated from a LISP site are flowing towards the core network, they
ingress into an encapsulated tunnel via an Ingress Tunnel Router
(ITR). When packets flow from the core network to a LISP site, they
egress from an encapsulated tunnel to an Egress Tunnel Router
(ETR). An xTR is a router that can perform both ITR and ETR
operations. In this context, ITRs encapsulate packets, while ETRs
decapsulate them; hence, LISP operates as an overlay on top of the
current Internet core.With LISP, the core uses RLOCs. An RLOC is an IPv4 or IPv6
address assigned to a core-facing network interface of an ITR or
ETR. A database that is typically distributed, called the Mapping System,
stores mappings between EIDs and RLOCs. Such mappings relate
the identity of the devices attached to LISP sites (EIDs) to the set
of RLOCs configured at the LISP-capable routers servicing the site.
Furthermore, the mappings also include TE policies
and can be configured to achieve multihoming and load balancing. The
LISP Mapping System is conceptually similar to the DNS, where it is
organized as a distributed multi-organization network database. With
LISP, ETRs register mappings, while ITRs retrieve them.Finally, the LISP architecture emphasizes incremental
deployment. Given that LISP represents an
overlay to the current Internet architecture, end hosts, as well as
intra-domain and inter-domain routers, remain unchanged. The only required
changes to the existing infrastructure are to routers connecting the
EID space with the RLOC space. Additionally, LISP requires the deployment of
an independent Mapping System; such a distributed database is a new
network entity.The following describes a simplified packet flow sequence between
two nodes that are attached to LISP sites. Please note that typical
LISP-capable routers are xTRs (both ITR and ETR). Client HostA wants
to send a packet to server HostB.
HostA retrieves the EID_B of HostB, typically querying the DNS
and obtaining an A or AAAA record.
Then, it generates an IP packet as in the Internet. The packet
has source address EID_A and destination address EID_B.
The packet is forwarded towards ITR_A in the LISP site using
standard intra-domain mechanisms.
ITR_A, upon receiving the packet, queries the Mapping System to
retrieve the Locator of ETR_B that is servicing HostB's EID_B. In order
to do so, it uses a LISP control message called Map-Request. The
message contains EID_B as the lookup key. In turn, it receives
another LISP control message called Map-Reply. The message
contains two Locators: RLOC_B1 and RLOC_B2. It also contains
TE policies: priority and weight per Locator. Note that a
Map-Reply can contain more Locators if needed. ITR_A can cache the mapping
in local storage to speed up forwarding of subsequent
packets.
ITR_A encapsulates the packet towards RLOC_B1 (chosen according
to the priorities/weights specified in the mapping). The packet contains two
IP headers. The outer header has RLOC_A1 as source and RLOC_B1 as
destination. The inner original header has EID_A as source and EID_B as
destination. Furthermore, ITR_A adds a LISP header. More details
about LISP encapsulation can be found in .
The encapsulated packet is forwarded over the interconnecting core as a
normal IP packet, making the EID invisible from the core.
Upon reception of the encapsulated packet by ETR_B, it
decapsulates the packet and forwards it to HostB.
Data PlaneThis section provides a high-level description of the LISP data plane,
which is specified in detail in . The LISP data plane is responsible for
encapsulating and decapsulating data packets and caching the
appropriate forwarding state. It includes two main entities, the ITR
and the ETR. Both are LISP-capable routers that connect the EID with
the RLOC space (ITR) and vice versa (ETR). LISP EncapsulationITRs encapsulate data packets towards ETRs. LISP data packets are
encapsulated using UDP (port 4341). The source port is usually
selected by the ITR using a 5-tuple hash of the inner header (so as to
be consistent in case of multipath solutions, such as ECMP ) and ignored on reception. LISP
data packets are often encapsulated in UDP packets that include a
zero checksum that may not be verified when it is
received, because LISP data packets typically include an inner
transport protocol header with a non-zero checksum. The use of UDP zero checksums
over IPv6 for all tunneling protocols like LISP is subject to the applicability
statement in . If LISP data packets are
encapsulated in
UDP packets with non-zero checksums, the outer UDP checksums are
verified when the UDP packets are received, as part of normal UDP
processing.LISP-encapsulated packets also include a LISP header (after the
UDP header and before the original IP header). The LISP header is
prepended by ITRs and stripped by ETRs. It carries reachability
information (see more details in ) and the 'Instance ID' field.
The 'Instance ID' field is used to distinguish traffic to/from
different tenant address spaces at the LISP site, and this use of the
Instance ID may use
overlapped but logically separated EID addressing.Overall, LISP works on 4 headers: the inner header the source
constructed and the 3 headers a LISP encapsulator prepends ("outer"
to "inner"):
Outer IP header containing RLOCs as source and destination
addresses. This header is originated by ITRs and stripped by
ETRs.
UDP header (port 4341), usually with zero checksum. This header is
originated by ITRs and stripped by ETRs.
LISP header that contains various forwarding-plane features
(such as reachability) and an
'Instance ID' field. This header is originated by ITRs and
stripped by ETRs.
Inner IP header containing EIDs as source and destination
addresses. This header is created by the source end host and
is left unchanged by the LISP data plane processing on the ITR and ETR.
Finally, in some scenarios, re-encapsulating and/or recursive
tunnels are useful to choose a specified path in the underlay
network, for instance, to avoid congestion or
failure. Re-encapsulating tunnels are consecutive LISP tunnels and
occur when a decapsulator (an ETR action) removes a LISP header and
then acts as an encapsulator (an ITR action) to prepend another one.
On the other hand, recursive tunnels are nested tunnels and are
implemented by using multiple LISP encapsulations on a packet. Such
functions are implemented by Re-encapsulating Tunnel Routers
(RTRs). An RTR can be thought of as a router that first acts as an
ETR by decapsulating packets and then as an ITR by encapsulating
them towards another Locator; more information can be found in and .LISP Forwarding State In the LISP architecture, ITRs keep just enough information to route
traffic flowing through them. In other words, ITRs only need to retrieve
from the LISP Mapping System mappings between EID-Prefixes (blocks of EIDs)
and RLOCs that are used to encapsulate packets.
Such mappings are stored in a local cache
called the LISP Map-Cache for subsequent packets addressed to the same EID-Prefix. Note that in the case of overlapping EID-Prefixes, after a request,
the ITR may receive a set of mappings covering the requested EID-Prefix and
all more-specific EID-Prefixes (cf., ). Mappings include a Time to Live
(TTL) (set by the ETR). More details about the Map-Cache
management can be found in .Control PlaneThe LISP control plane, specified in , provides a standard
interface to register and request mappings.
The LISP
Mapping System is a database that stores such
mappings. The following sub-sections first describe the mappings, then the
standard interface to the Mapping System, and finally its architecture.LISP MappingsEach mapping includes the bindings between EID-Prefix(es) and a
set of RLOCs as well as TE policies, in the form of
priorities and weights for the RLOCs. Priorities allow the ETR to
configure active/backup policies, while weights are used to
load-balance traffic among the RLOCs (on a per-flow basis).Typical mappings in LISP bind EIDs in the form of IP prefixes
with a set of RLOCs, also in the form of IP addresses. IPv4 and IPv6
addresses are encoded using the appropriate Address Family
Identifier (AFI) .
However,
LISP can also support more general address encoding by means of the
ongoing effort around the LISP Canonical Address Format (LCAF) .With such a general syntax for address encoding in place, LISP
aims to provide flexibility to current and future applications. For
instance, LCAFs could support Media Access Control (MAC) addresses,
geocoordinates, ASCII names, and application-specific data.Mapping System InterfaceLISP defines a standard interface between data and control
planes. The interface is specified in and
defines two entities:
Map-Server:
A network infrastructure component
that learns mappings from ETRs and publishes them into the LISP
Mapping System. Typically, Map-Servers are not authoritative to
reply to queries; hence, they forward them to the ETR.
However, they can also operate in proxy-mode, where the ETRs
delegate replying to queries to Map-Servers. This setup is
useful when the ETR has limited resources (e.g., CPU or power).
Map-Resolver:
A network infrastructure component
that interfaces ITRs with the Mapping System by proxying queries
and, in some cases, responses.
The interface defines four LISP control messages that are
sent as UDP datagrams (port 4342):
Map-Register:
This message is used by ETRs to
register mappings in the Mapping System, and it is authenticated
using a shared key between the ETR and the Map-Server.
Map-Notify:
When requested by the ETR, this message is sent by the
Map-Server in response to a Map-Register to acknowledge the
correct reception of the mapping and convey the latest Map-Server
state on the EID-to-RLOC mapping. In some cases, a Map-Notify can
be sent to the previous RLOCs when an EID is registered by a new
set of RLOCs.
Map-Request:
This message is used by ITRs or
Map-Resolvers to resolve the mapping of a given EID.
Map-Reply:
This message is sent by Map-Servers or ETRs in response to a
Map-Request and contains the resolved mapping. Please note that a
Map-Reply may contain a negative reply if, for example, the
queried EID is not part of the LISP EID space. In such cases, the
ITR typically forwards the traffic as is (non-encapsulated) to
the public Internet. This behavior is defined to support
incremental deployment of LISP.
Mapping SystemLISP architecturally decouples control and data planes by means of
a standard interface. This interface glues the data plane -- routers
responsible for forwarding data packets -- with the LISP Mapping
System -- a database responsible for storing mappings.With this separation in place, the data and control planes can use
different architectures if needed and scale independently.
Typically, the data plane is optimized to route packets according to
hierarchical IP addresses. However, the control plane may have
different requirements, for instance, and by taking advantage of the
LCAFs, the Mapping System may be used to store
nonhierarchical keys (such as MAC addresses),
requiring different architectural approaches for scalability.
Another important difference between the LISP control and
data planes is that, and as a result of the local mapping cache
available at the ITR, the Mapping System does not need to operate at
line-rate.Many of the existing mechanisms to create distributed systems
have been explored and considered for the Mapping System
architecture: graph-based databases in the form of LISP Alternative
Logical Topology (LISP-ALT) , hierarchical databases in the
form of the LISP Delegated Database Tree (LISP-DDT) , monolithic databases in the
form of the LISP Not-so-novel EID-to-RLOC Database (LISP-NERD) , flat databases in the form of
the LISP Distributed Hash Table (LISP-DHT) , and a multicast-based database . Furthermore, it
is worth noting that, in some scenarios, such as private deployments,
the Mapping System can operate as logically centralized. In such
cases, it is typically composed of a single
Map-Server/Map-Resolver.The following sub-sections focus on the two Mapping Systems that have
been implemented and deployed (LISP-ALT and LISP-DDT).LISP-ALTLISP-ALT was the first
Mapping System proposed, developed, and deployed on the LISP pilot
network. It is based on a distributed BGP overlay in which
Map-Servers and Map-Resolvers participate. The nodes connect to their peers
through static tunnels. Each Map-Server involved in the ALT topology
advertises the EID-Prefixes registered by the serviced ETRs, making
the EID routable on the ALT topology.
When an ITR needs a mapping, it sends a Map-Request to a Map-Resolver
that, using the ALT topology, forwards the Map-Request towards the
Map-Server responsible for the mapping. Upon reception, the Map-Server
forwards the request to the ETR, which in turn replies directly to the ITR.LISP-DDTLISP-DDT is
conceptually similar to the DNS, a hierarchical directory whose
internal structure mirrors the hierarchical nature of the EID
address space. The DDT hierarchy is composed of DDT nodes forming
a tree structure; the leafs of the tree are Map-Servers. On top
of the structure, there is the DDT root node, which is a particular
instance of a DDT node, that matches the entire address space. As
in the case of DNS, DDT supports multiple redundant DDT nodes
and/or DDT roots. Finally, Map-Resolvers are the clients of the
DDT hierarchy and can query the DDT root and/or other DDT
nodes.Please note that the prefixes and the structure depicted in the
figure above should only be considered as an example. The DDT structure does not actually index EID-Prefixes; rather, it
indexes Extended EID-Prefixes (XEID-Prefixes). An XEID-Prefix is just the
concatenation of the following fields (from most significant bit
to less significant bits): Database-ID, Instance ID, Address Family
Identifier, and the actual EID-Prefix. The Database-ID is provided
for possible future requirements of higher levels in the hierarchy
and to enable the creation of multiple and separate database
trees.In order to resolve a query, LISP-DDT operates in a similar way to the
DNS but only supports iterative lookups. DDT clients (usually Map-Resolvers)
generate Map-Requests to the DDT root node. In response, they
receive a newly introduced LISP control message: a Map-Referral. A
Map-Referral provides the list of RLOCs of the set of DDT nodes
matching a configured XEID delegation. That is, the information
contained in the Map-Referral points to the child of the queried
DDT node that has more specific information about the queried
XEID-Prefix. This process is repeated until the DDT client walks
the tree structure (downwards) and discovers the Map-Server
servicing the queried XEID. At this point, the client sends a
Map-Request and receives a Map-Reply containing the mappings. It
is important to note that DDT clients can also cache the
information contained in Map-Referrals; that is, they cache the
DDT structure. This is used to reduce the time required to retrieve
mappings .The DDT Mapping System relies on manual configuration. That is,
Map-Resolvers are configured with the set of available
DDT root nodes, while DDT nodes are configured with the
appropriate XEID delegations. Configuration changes in the DDT
nodes are only required when the tree structure changes itself,
but it doesn't depend on EID dynamics (RLOC allocation or
TE policy changes).Internetworking MechanismsEIDs are typically identical to either IPv4 or IPv6 addresses, and
they are stored in the LISP Mapping System. However, they are usually not
announced in the routing system beyond the local LISP domain. As a result, LISP
requires an internetworking mechanism to allow LISP sites to speak
with non-LISP sites and vice versa. LISP internetworking mechanisms are
specified in .LISP defines two entities to provide internetworking:
Proxy Ingress Tunnel Router (PITR):
PITRs provide
connectivity from the legacy Internet to LISP sites. PITRs
announce in the global routing system blocks of EID-Prefixes
(aggregating when possible) to attract traffic. For each incoming
packet from a source not in a LISP site (a non-EID),
the PITR LISP-encapsulates it towards the RLOC(s) of
the appropriate LISP site. The impact of PITRs on the routing
table size of the Default-Free Zone (DFZ) is, in the worst case, similar to the case
in which LISP is not deployed. EID-Prefixes will be aggregated
as much as possible, both by the PITR and by the global routing system.
Proxy Egress Tunnel Router (PETR):
PETRs provide connectivity from LISP sites to the legacy
Internet. In some scenarios, LISP sites may be unable to send
encapsulated packets with a local EID address as a source to the
legacy Internet, for instance, when Unicast Reverse Path
Forwarding (uRPF) is used by Provider Edge routers or when an
intermediate network between a LISP site and a non-LISP site does
not support the desired version of IP (IPv4 or IPv6). In both
cases, the PETR overcomes such limitations by
encapsulating packets over the network. There is no specified
provision for the distribution of PETR RLOC addresses to the
ITRs.
Additionally, LISP also defines mechanisms to operate with private
EIDs by means of LISP-NAT
. In this case, the xTR
replaces a private EID source address with a routable one. At the time
of this writing, work is ongoing to define NAT-traversal capabilities,
that is, xTRs behind a NAT using non-routable RLOCs.PITRs, PETRs, and LISP-NAT enable incremental deployment of LISP by
providing significant flexibility in the placement of the boundaries
between the LISP and non-LISP portions of the network and making it
easy to change those boundaries over time.LISP Operational MechanismsThis section details the main operational mechanisms defined in
LISP.Cache ManagementLISP's decoupled control and data planes, where mappings are
stored in the control plane and used for forwarding in the data
plane, require a local cache in ITRs to reduce signaling
overhead (Map-Request/Map-Reply) and increase forwarding speed. The
local cache available at the ITRs, called Map-Cache, is used by the
router to LISP-encapsulate packets. The Map-Cache is indexed by
(Instance ID, EID-Prefix) and contains basically the set
of RLOCs with the associated TE policies (priorities and
weights).The Map-Cache, as with any other cache, requires cache coherence
mechanisms to maintain up-to-date information. LISP defines three
main mechanisms for cache coherence:
Record Time To Live (TTL):
Each mapping record contains a TTL set by the ETR. Upon
expiration of the TTL, the ITR can't use the mapping until it is refreshed by
sending a new Map-Request.
Solicit-Map-Request (SMR):
SMR is an explicit
mechanism to update mapping information. In particular, a special
type of Map-Request can be sent on demand by ETRs to request refreshing
a mapping. Upon reception of an SMR
message, the ITR must refresh the bindings by sending a
Map-Request to the Mapping System. Further uses of SMRs are
documented in .
Map-Versioning:
This optional mechanism piggybacks, in the LISP header of data packets, the
version number of the mappings used by an xTR. This way, when an xTR receives
a LISP-encapsulated packet from a remote xTR, it can check whether its own
Map-Cache or the one of the remote xTR is outdated. If its Map-Cache is
outdated, it sends a Map-Request for the remote EID so as to obtain the newest
mappings. On the contrary, if it detects that the remote xTR Map-Cache is
outdated, it sends an SMR to notify it that a new mapping is available. Further
details are available in .
Finally, it is worth noting that, in some cases, an entry in the
Map-Cache can be proactively refreshed using the mechanisms described
in the section below.RLOC ReachabilityIn most cases, LISP operates with a pull-based Mapping System (e.g.,
DDT). This results in an edge-to-edge pull architecture. In such a
scenario, the network state is stored in the control plane while the
data plane pulls it on demand. This has consequences concerning the
propagation of xTRs' reachability/liveness information, since pull
architectures require explicit mechanisms to propagate this
information. As a result, LISP defines a set of mechanisms to inform
ITRs and PITRs about the reachability of the cached RLOCs:
Locator-Status-Bits (LSBs):
Using LSBs is a passive technique. The 'LSB'
field is carried by data packets in the LISP header and can be set by
ETRs to specify which RLOCs of the ETR site are up/down. This information
can be used by the ITRs as a hint about the reachability to perform
additional checks. Also note that LSBs do not provide path
reachability status; they only provide hints about the status of RLOCs. As such, they must not be
used over the public Internet and should be coupled with Map-Versioning to prevent
race conditions where LSBs are interpreted as referring to different RLOCs than
intended.
Echo-Nonce:
This is also a passive technique that can only operate
effectively when data flows bidirectionally between two communicating xTRs.
Basically, an ITR piggybacks a random number (called a nonce) in LISP
data packets. If the path and the probed Locator are up, the ETR will
piggyback the same random number on the next data packet; if this is
not the case, the ITR can set the Locator as unreachable. When traffic
flow is unidirectional or when the ETR receiving the traffic is not
the same as the ITR that transmits it back, additional mechanisms are
required. The Echo-Nonce mechanism must be used in trusted environments only, not
over the public Internet.
RLOC-Probing:
This is an active probing algorithm where ITRs send
probes to specific Locators. This effectively probes both the Locator
and the path. In particular, this is done by sending a
Map-Request (with certain flags activated) on the data plane (RLOC
space) and then waiting for a Map-Reply (also sent on the data
plane). The active
nature of RLOC-Probing provides an effective mechanism for determining
reachability and, in case of failure, switching to a different
Locator. Furthermore, the mechanism also provides useful RTT
estimates of the delay of the path that can be used by other network
algorithms.
It is worth noting that RLOC-Probing and the Echo-Nonce can work together.
Specifically, if a nonce is not echoed, an ITR cannot determine which path direction has failed. In this scenario, an ITR can use RLOC-Probing.Additionally, LISP also recommends inferring the reachability of
Locators by using information provided by the underlay,
particularly:
ICMP signaling:
The LISP underlay -- the current Internet -- uses
ICMP to signal unreachability (among other things). LISP can
take advantage of this, and the reception of an ICMP Network Unreachable
or ICMP Host Unreachable message can be seen as a hint that a Locator
might be unreachable. This should lead to performing additional
checks.
Underlay routing:
Both BGP and IGP carry reachability information.
LISP-capable routers that have access to underlay routing information
can use it to determine if a given Locator or path is reachable.
ETR SynchronizationAll the ETRs that are authoritative to a particular EID-Prefix must
announce the same mapping to the requesters. This means that ETRs must be
aware of the status of the RLOCs of the remaining ETRs. This is known as
ETR synchronization.At the time of this writing, LISP does not specify a mechanism to
achieve ETR synchronization. Although many well-known techniques could
be applied to solve this issue, it is still under research. As a
result, operators must rely on coherent manual configuration.MTU HandlingSince LISP encapsulates packets, it requires dealing with packets
that exceed the MTU of the path between the ITR and the
ETR. Specifically, LISP defines two mechanisms:
Stateless:
With this mechanism, the effective MTU is assumed from the ITR's
perspective. If a payload packet is too big for the effective MTU
and can be fragmented, the payload packet is fragmented on the ITR,
such that reassembly is performed at the destination host.
Stateful:
With this mechanism, ITRs keep track of the MTU of the paths
towards the destination Locators by parsing the ICMP Too Big packets
sent by intermediate routers. ITRs will send ICMP Too Big messages
to inform the sources about the effective MTU. Additionally, ITRs can
use mechanisms such as Path MTU Discovery (PMTUD) or Packetization Layer Path MTU Discovery (PLPMTUD) to keep track of the MTU towards the
Locators.
In both cases, if the packet cannot be fragmented (IPv4 with DF=1 or
IPv6), then the ITR drops it and replies with an ICMP Too Big message to
the source.MobilityThe separation between Locators and identifiers in LISP is suitable
for TE purposes where LISP sites can change their attachment
points to the Internet (i.e., RLOCs) without impacting endpoints or the
Internet core. In this context, the border routers operate the xTR
functionality, and endpoints are not aware of the existence of
LISP. This functionality is similar to Network Mobility
. However,
this mode of operation does not allow seamless mobility of endpoints between
different LISP sites, as the EID address might not be routable in a visited
site. Nevertheless, LISP can be used to enable seamless
IP mobility when LISP
is directly implemented in the endpoint or when the endpoint
roams to an attached xTR.
Each endpoint is then an xTR, and the EID address is the one
presented to the network stack used by applications
while the RLOC is the address gathered from the network when
it is visited. This functionality is similar to Mobile IP ( and ). Whenever a device changes its RLOC, the xTR updates the RLOC of its
local mapping and registers it to its Map-Server, typically with a
low TTL value (1 min). To avoid the need for a
home gateway, the ITR also indicates the RLOC change to all remote devices
that have ongoing communications with the device that moved. The
combination of both methods ensures the scalability of the system, as
signaling is strictly limited to the Map-Server and to hosts with which
communications are ongoing. In the mobility case, the EID-Prefix can
be as small as a full /32 or /128 (IPv4 or IPv6, respectively), depending
on the specific use case (e.g., subnet mobility vs. single VM/Mobile node mobility).The decoupled identity and location provided by LISP allow it to
operate with other Layer 2 and Layer 3 mobility solutions.MulticastLISP also supports transporting IP multicast packets sent from the EID
space. The required operational changes to the multicast protocols are
documented in .In such scenarios, LISP may create multicast state both at the core
and at the sites (both source and receiver). When signaling is used to
create multicast state at the sites, LISP
routers encapsulate PIM Join/Prune messages from receiver to source
sites as unicast packets. At the core,
ETRs build a new PIM Join/Prune message addressed to the RLOC of the
ITR servicing the source. A simplified sequence is shown below.
An end host willing to join a multicast channel sends an IGMP
report. Multicast PIM routers at the LISP site propagate PIM
Join/Prune messages (S-EID, G) towards the ETR.
The Join message flows to the ETR. Upon reception, the ETR builds
two Join messages. The first one unicast LISP-encapsulates the
original Join message towards the RLOC of the ITR servicing the
source. This message creates (S-EID, G) multicast state at the source
site.
The second Join message contains, as a destination address, the RLOC
of the ITR servicing the source (S-RLOC, G) and creates multicast
state at the core.
Multicast data packets originated by the source (S-EID, G) flow
from the source to the ITR. The ITR LISP-encapsulates the multicast
packets. The outer header includes its own RLOC as the source
(S-RLOC) and the original multicast group address (G) as the
destination. Please note that multicast group addresses are logical and
are not resolved by the Mapping System. Then, the
multicast packets are transmitted through the core towards the
receiving ETRs, which decapsulate the packets and forward them
using the receiver site's multicast state.
Please note that the inner and outer multicast addresses are
generally different, except in specific cases where the underlay provider
implements tight control on the overlay. LISP specifications already
support all PIM modes . Additionally, LISP can also support non-PIM
mechanisms in order to maintain multicast state.When multicast sources and receivers are active at LISP sites and the
core network between the sites does not provide multicast support, a
signal-free mechanism can be used to create an overlay that will allow
multicast traffic to flow between sites and connect the multicast trees at
the different sites . Registrations
from the different receiver sites will be merged in the Mapping System to
assemble a multicast replication list inclusive of all RLOCs that lead to receivers for a particular multicast group or multicast
channel. The replication list for each specific multicast entry is maintained
as a database mapping entry in the LISP Mapping System.Use CasesTraffic Engineering A LISP site can strictly impose via which ETRs the
traffic must enter the LISP site network even though the path followed to reach the
ETR is not under the control of the LISP site. This fine control is
implemented with the mappings. When a remote site is willing to send
traffic to a LISP site, it retrieves the mapping associated with the
destination EID via the Mapping System. The mapping is sent directly by an
authoritative ETR of the EID and is not altered by any intermediate network. A mapping associates a list of RLOCs with an EID-Prefix. Each RLOC
corresponds to an interface of an ETR (or set of ETRs) that is able to correctly forward
packets to EIDs in the prefix. Each RLOC is tagged with a priority and a
weight in the mapping. The priority is used to indicate which RLOCs
should be preferred for sending packets (the least preferred ones being
provided for backup purposes). The weight permits balancing the load
between the RLOCs with the same priority, in proportion to the weight
value. As mappings are directly issued by the authoritative ETR of the EID
and are not altered when transmitted to the remote site, it offers
highly flexible incoming inter-domain TE and even
makes it possible for a site to support a different mapping policy
for each remote site.LISP for IPv6 Co-existenceLISP encapsulations allow transporting packets using EIDs from a
given address family (e.g., IPv6) with packets from other address
families (e.g., IPv4). The absence of correlation between the address
families of RLOCs and EIDs makes LISP a candidate to allow, e.g., IPv6
to be deployed when all of the core network may not have IPv6 enabled.For example, two IPv6-only data centers could be interconnected via the
legacy IPv4 Internet. If their border routers are LISP capable, sending
packets between the data centers is done without any form of translation, as
the original IPv6 packets (in the EID space) will be LISP encapsulated and
transmitted over the IPv4 legacy Internet via IPv4 RLOCs.LISP for Virtual Private NetworksIt is common to operate several virtual networks over the same
physical infrastructure. In such virtual private networks, determining to
which virtual network a packet belongs is essential; tags or labels are used
for that purpose. When using LISP, the distinction can be made with the
'Instance ID' field. When an
ITR encapsulates a packet from a particular virtual network (e.g., known
via Virtual Routing and Forwarding (VRF) or the VLAN), it tags the encapsulated packet with the Instance ID
corresponding to the virtual network of the packet. When an ETR receives a
packet tagged with an Instance ID, it uses the Instance ID to determine how
to treat the packet. The main usage of LISP for virtual private networks does not introduce
additional requirements on the underlying network, as long as it runs IP.LISP for Virtual Machine Mobility in Data CentersA way to enable seamless virtual machine (VM) mobility in the data center is to
conceive the data center backbone as the RLOC space and the subnet
where servers are hosted as forming the EID space. A LISP router is placed
at the border between the backbone and each subnet. When a VM
is moved to another subnet, it can keep (temporarily) the address it had before the move so as to continue without a transport-layer connection reset. When an xTR detects a source address received on a subnet to be an address not assigned to the subnet, it registers the address to the Mapping System.To inform the other LISP routers that the machine moved and where, and then
to avoid detours via the initial subnetwork, mechanisms such as the
Solicit-Map-Request messages are used.Security ConsiderationsThis section describes the security considerations associated with
LISP.In a push Mapping System, the state necessary to forward packets is learned
independently of the traffic itself. However, with a pull architecture, the
system becomes reactive, and data plane events (e.g., the arrival of a
packet with an unknown destination address) may trigger control plane events.
This on-demand learning of mappings provides many advantages, as
discussed above, but may also affect the way security is enforced.Usually, the data plane is implemented in the fast path of routers to
provide high-performance forwarding capabilities, while the control plane
features are implemented in the slow path to offer high flexibility, and a
performance gap of several orders of magnitude can be observed between the
slow and fast paths.
As a consequence, the way to notify the control plane of data plane events must be considered carefully so as not to overload the
slow path, and rate limiting should be used as specified in and .Care must also be taken not to overload the Mapping System (i.e., the
control plane infrastructure), as the operations to be performed by the
Mapping
System may be more complex than those on the data plane. For that reason,
and recommend rate limiting the
sending of messages to the Mapping System. To improve resiliency and reduce the overall number of messages
exchanged, LISP makes it possible to leak certain information, such
as the reachability of Locators, directly into data plane packets. In
environments that are not
fully trusted, like the open Internet, control information gleaned from
data plane packets must not be used or must be
verified before using it.Mappings are the centerpiece of LISP, and all precautions must be taken to
prevent malicious entities from manipulating or misusing them. Using
trustable Map-Servers that strictly respect and the
authentication mechanism proposed by LISP-SEC reduces
the risk of attacks on mapping integrity. In more critical
environments, secure measures may be needed. The way security is
implemented for a given Mapping System strongly depends on the architecture
of the Mapping System itself and the threat model assumed for the
deployment. Thus, Mapping System security has to be discussed in the
relevant documents proposing the Mapping System architecture.As with any other tunneling mechanism, middleboxes on the path
between an ITR (or PITR) and an ETR (or PETR) must implement mechanisms
to strip the LISP encapsulation to correctly inspect the content of
LISP-encapsulated packets. Like other map-and-encap mechanisms, LISP enables triangular routing
(i.e., packets of a flow cross different border routers, depending on
their direction). This means that intermediate boxes may have an
incomplete view of the traffic they inspect or manipulate. Moreover,
LISP-encapsulated packets are routed based on the outer IP address
(i.e., the RLOC) and can be delivered to an ETR that is not responsible
for the destination EID of the packet or even delivered to a network element that
is not an ETR. Mitigation consists of applying appropriate filtering
techniques on the network elements that can potentially receive
unexpected LISP-encapsulated packets.More details about security implications of LISP are discussed in
.
IANA ConsiderationsThis document has no IANA actions.ReferencesNormative ReferencesPath MTU discoveryThis memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. [STANDARDS-TRACK]Address Allocation for Private InternetsThis document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Analysis of an Equal-Cost Multi-Path AlgorithmEqual-cost multi-path (ECMP) is a routing technique for routing packets along multiple paths of equal cost. The forwarding engine identifies paths by next-hop. When forwarding a packet the router must decide which next-hop (path) to use. This document gives an analysis of one method for making that decision. The analysis includes the performance of the algorithm and the disruption caused by changes to the set of next-hops. This memo provides information for the Internet community.Network Mobility (NEMO) Basic Support ProtocolThis document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network. [STANDARDS-TRACK]Packetization Layer Path MTU DiscoveryThis document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS-TRACK]Report from the IAB Workshop on Routing and AddressingThis document reports the outcome of the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions.Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not of the IAB. Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work. This memo provides information for the Internet community.IP Mobility Support for IPv4, RevisedThis document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS-TRACK]Mobility Support in IPv6This document specifies Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775. [STANDARDS-TRACK]The Locator/ID Separation Protocol (LISP) for Multicast EnvironmentsThis 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.Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP SitesThis 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.The Locator/ID Separation Protocol Internet Groper (LIG)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.Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)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.NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) DatabaseThe Locator/ID Separation Protocol (LISP) is a protocol to encapsulate IP packets in order to allow end sites to route to one another without injecting routes from one end of the Internet to another. This memo presents an experimental database and a discussion of methods to transport the mapping of Endpoint IDs (EIDs) to Routing Locators (RLOCs) to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of all EID-to- RLOC mappings scales well to at least 10^8 entries. This document defines an Experimental Protocol for the Internet community.IPv6 and UDP Checksums for Tunneled PacketsThis document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried. Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method.Applicability Statement for the Use of IPv6 UDP Datagrams with Zero ChecksumsThis document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6.Locator/ID Separation Protocol (LISP) MIBThis 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.Locator/Identifier Separation Protocol (LISP) Network Element Deployment ConsiderationsThis 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.Locator/ID Separation Protocol (LISP) Threat AnalysisThis document provides a threat analysis of the Locator/ID Separation Protocol (LISP).LISP Canonical Address Format (LCAF)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.Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)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.Signal-Free Locator/ID Separation Protocol (LISP) MulticastWhen 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.The Locator/ID Separation Protocol (LISP)Locator/ID Separation Protocol (LISP) Control PlaneLocator/ID Separation Protocol (LISP) Map-VersioningLocator/ID Separation Protocol Security (LISP-SEC)Informative ReferencesLISP-TREE: A DNS Hierarchy to Support the LISP Mapping SystemIEEE Journal on Selected Areas in Communications, vol. 28,
no. 8, pp. 1332-1343EID Mappings Multicast Across Cooperating Systems for LISPOne of the potential problems with the "map-and-encapsulate" approaches to routing architecture is that there is a significant chance of packets being dropped while a mapping is being retrieved. Some approaches pre-load ingress tunnel routers with at least part of the mapping database. Some approaches try to solve this by providing intermediate "default" routers which have a great deal more knowledge than a typical ingress tunnel router. This document proposes a scheme which does not drop packets yet does not require a great deal of knowledge in any router. However, there are still some issues that need to be worked out.Work in ProgressLISP Single-Hop DHT Mapping OverlayThis draft specifies the LISP Single-Hop Distributed Hash Table Mapping Database (LISP-SHDHT), a distributed mapping database which consists of a set of SHDHT Nodes to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). EID namespace is dynamically distributed among SHDHT Nodes based on DHT Hash algorithm. Each SHDHT Node is configured with one or more hash spaces which contain multiple EID-prefixes along with RLOCs of corresponding Map Servers.Work in ProgressLISP-DHT: Towards a DHT to map identifiers onto locatorsCoNEXT '08: Proceedings of the 2008 ACM CoNEXT Conference, ReArch '08 - Re-Architecting the InternetEvaluating the Benefits of the Locator/Identifier SeparationProceedings of 2nd ACM/IEEE International Workshop
on Mobility in the Evolving Internet ArchitectureA Brief History of Location/Identity SeparationThe LISP architecture for separation of location and identity resulted from
the discussions of this topic at the Amsterdam IAB Routing and
Addressing Workshop, which took place in October 2006 .A small group of like-minded personnel spontaneously formed immediately after that
workshop to work on an idea that came out of informal discussions at
the workshop and on various mailing lists. The first
Internet-Draft on LISP appeared in January 2007.Trial implementations started at that time, with initial trial
deployments underway since June 2007; the results of early experience
have been fed back into the design in a continuous, ongoing process
over several years. At this point, LISP represents a moderately
mature system, having undergone a long, organic series of changes and
updates.LISP transitioned from an IRTF activity to an IETF WG in March 2009.
After numerous revisions, the basic specifications moved to
becoming RFCs at the start of 2013; work to expand,
improve, and find new uses for it continues (and undoubtedly will
for a long time to come). The LISP WG was rechartered in 2018 to continue work on the LISP base protocol and produce Standards Track documents.Old LISP ModelsLISP, as initially conceived, had a number of potential operating
modes, named 'models'. Although they are not used anymore, one
occasionally sees mention of them, so they are briefly described
here.
LISP 1:
EIDs all appear in the normal routing and forwarding
tables of the network (i.e., they are 'routable'). This property is used
to load EID-to-RLOC mappings via bootstrapping operations. Packets are
sent with the EID as the destination in
the outer wrapper; when an ETR sees such a packet, it sends a
Map-Reply to the source ITR, giving the full mapping.
LISP 1.5:
LISP 1.5 is similar to LISP 1, but the routability of EIDs happens
on a separate network.
LISP 2:
EIDs are not routable; EID-to-RLOC mappings are available
from the DNS.
LISP 3:
EIDs are not routable and have to be looked up in a
new EID-to-RLOC mapping database (in the initial concept, a system
using Distributed Hash Tables). Two variants were possible: a
'push' system in which all mappings were distributed to all ITRs
and a 'pull' system in which ITRs load the mappings when they need them.
AcknowledgmentsThis document was initiated by ,
and much of the core philosophy came from him. The authors acknowledge
the important contributions he has made to this work and thank him for
his past efforts.The authors would also like to thank , , , ,
, , , , ,
, ,
, , , and .Authors' AddressesUniversitat Politecnica de Catalunyac/ Jordi Girona s/nBarcelona08034Spainacabello@ac.upc.eduInria2004 route des Lucioles - BP 93Sophia AntipolisFrancedamien.saucez@inria.fr