The Locator/ID Separation Protocol (LISP)
obsoletes
- rfc-6830 — The Locator/ID Separation Protocol (LISP)
Extracted elements (31)
A maximum of two LISP headers is recommended (not mandated) to limit per-packet overhead and prevent encapsulation loops from misconfiguration. The first header separates location from identity at the site boundary; the second supports Traffic Engineering inside a service provider.
LISP requires no changes to host protocol stacks or underlay routers. Hosts continue using EIDs as normal IP addresses; only Tunnel Routers (ITRs/ETRs) at the edges of LISP sites intercept and encapsulate/decapsulate packets. This incremental deployability was a core architectural goal.
LISP uses UDP encapsulation (rather than a new IP protocol or raw IP tunneling) specifically so that core routers performing 5-tuple hashing for Link Aggregation Group (LAG) load-balancing can distribute LISP-encapsulated flows across member links, rather than seeing all traffic as a single flow from the ITR address.
The LISP data plane protocol defined in RFC 9300 is not backwards compatible with RFC 6830 and has no explicit version field. Forward-compatibility for data plane capabilities is instead handled through the LISP control plane (RFC 9301) via new LISP Canonical Address Format (LCAF) types (RFC 8060), allowing an ITR to learn an ETR's capabilities before encapsulating.
A gleaned Map-Cache entry is stored for a recommended period of 3 seconds pending verification. Verification MUST be performed by sending a Map-Request to the source EID of the received encapsulated packet, and the gleaning mechanism MUST NOT be used over the public Internet.
All four combinations of inner/outer IP versions (IPv4-in-IPv4, IPv6-in-IPv6, IPv4-in-IPv6, IPv6-in-IPv4) MUST be supported by LISP implementations.
An RLOC assigned a Priority of 255 in an EID-to-RLOC mapping MUST NOT be used for forwarding. When multiple RLOCs share the same best Priority, the Weight field governs load-balancing.
During ETR/PETR decapsulation, the inner-header Time to Live (or Hop Limit) field MUST be replaced with the outer-header value when the outer TTL/Hop Limit is less than the inner value, to prevent TTL incrementing across encapsulation/decapsulation cycles.
Locator-Status-Bits MUST NOT be used over the public Internet and SHOULD only be used in trusted and closed deployments. They SHOULD be coupled with Map-Versioning to prevent race conditions where LSBs are interpreted as referring to different RLOCs than intended.
On the public Internet, xTRs MUST set the N-, L-, E-, and V-bits in the LISP header to zero, MUST NOT use Locator-Status-Bits or Echo-Nonce for RLOC reachability (relying solely on control plane methods), and MUST NOT use gleaning to update EID-to-RLOC mappings.
The Echo-Nonce mechanism MUST NOT be used over the public Internet and MUST only be used in trusted and closed deployments. An ITR SHOULD set the E-bit only when it knows the ETR is enabled for Echo-Noncing (conveyed via the E-bit in Map-Reply).
The ECN field in IPv4 and bits 6-7 of the IPv6 Traffic Class field require special treatment per RFC 6040 during both encapsulation and decapsulation to avoid discarding congestion indications. For re-encapsulating xTRs, each operation (decap then encap) MUST apply the RFC 6040 rules separately.
The Locator-Status-Bits setting in an encapsulated packet MUST reflect the mapping for the EID-Prefix that the inner-header source EID address matches via longest-prefix match. When a site has multiple EID-Prefixes with different Locator-Sets, each packet's LSBs are tied to the per-source-EID mapping.
The N-bit (nonce-present) and V-bit (Map-Version present) MUST NOT be set simultaneously in the same LISP header packet. If both are set, the decapsulating ETR MUST treat the field as containing a nonce.
The R-bit (reserved) in the LISP header MUST be set to 0 on transmit and MUST be ignored on receipt.
The source and destination EIDs in a LISP-encapsulated packet MUST belong to the same Instance ID. An EID used on the public Internet MUST be unique and have the same properties as any other IP address used in that manner.
The stateless MTU fragmentation behavior (splitting oversized packets into two equal fragments) MUST be implemented by the ITR only when the source host originates a packet with the DF bit set to 0. When DF=1 or the packet is IPv6, the ITR MUST drop and send an ICMP Fragmentation Needed or PTB message with value S=(L-H).
The UDP Checksum SHOULD be transmitted as zero by an ITR. When an ETR receives a packet with a non-zero UDP checksum and verification fails, the packet MUST be silently dropped; if verification succeeds or is skipped, the packet MUST be accepted for decapsulation.
The UDP destination port MUST be set to the well-known IANA-assigned port value 4341 for all LISP-encapsulated data packets.
When an ITR/PITR encapsulates a packet and the R-bit for a Locator record in a Map-Reply is set to 0, the ITR or PITR MUST NOT encapsulate packets to that RLOC.
Instance IDs are 24-bit values carried in the LISP header (I-bit=1) to support virtualization, overlapping address spaces, and multi-tenant segmentation. The ETR uses the Instance ID as a table identifier for the inner destination EID lookup. The Instance ID SHOULD NOT be used with overlapping IPv6 EID addresses.
RLOC selection from the Locator-Set uses Priority (lowest wins; 255 means never use) and Weight (relative load-share among equal-Priority RLOCs). A suggested hashing algorithm uses the inner-header 5-tuple (src/dst addr, src/dst port, protocol) to select among equal-Priority Locators and to compute the outer UDP source port.
The EID-to-RLOC Map-Cache is an on-demand, shortest-lived cache maintained by ITRs and PITRs that stores EID-Prefix-to-Locator-Set mappings. Entries are expired based on TTL, populated via the LISP control plane (RFC 9301), and support reachability information for RLOCs.
IANA has allocated UDP port 4341 for the LISP data plane, with service name 'lisp-data'. This document (RFC 9300) updates the description for this port assignment.
An attacker can forge the Map-Version field in LISP-encapsulated headers to trigger excessive control plane signaling (Map-Requests) between xTRs, potentially overloading them. Locator-Status-Bits, Echo-Nonce, and Map-Versioning MUST NOT be used over the public Internet.
An off-path attacker can exploit the Echo-Nonce mechanism by sending packets to an ITR with a guessed nonce from a spoofed ETR RLOC, causing the ITR to falsely believe the ETR is reachable for tens of seconds. Mitigation requires deploying uRPF (BCP 84, RFC 8704) to prevent RLOC spoofing.
IPv6 fragment reassembly at ETRs/RTRs/PETRs can be a DoS vector. Implementations should limit the number of fragments awaiting reassembly and the rate at which such fragments are admitted to mitigate this attack.
The optional gleaning mechanism allows an off-path attacker to spoof the source EID to divert traffic to a victim's spoofed EID, or spoof the source RLOC to mount a DoS attack by redirecting traffic to an overloaded victim RLOC. Gleaning MUST NOT be used over the public Internet.
The Echo-Nonce reachability algorithm: an ITR enters 'Echo-Nonce-request' state by setting N- and E-bits with a random 24-bit nonce; the co-located ETR/ITR at the remote site echoes the nonce (N=1, E=0) in return traffic. If the ITR does not observe the echoed nonce before a timeout, the path to the ETR RLOC is declared unreachable and the ITR switches to an alternate Locator.
The LISP header is 8 octets: the first 32 bits contain the N, L, E, V, I, R, KK flag bits (8 bits) and a 24-bit Nonce/Map-Version field; the second 32 bits carry either a 32-bit Locator-Status-Bits field (I=0) or a 24-bit Instance ID plus 8-bit LSBs (I=1).
The LISP IPv4-in-IPv4 encapsulation consists of an outer IPv4 header (OH) with Protocol=17, a UDP header with destination port 4341, an 8-octet LISP-specific header containing N/L/E/V/I/R/KK flag bits, a Nonce/Map-Version field, and an Instance ID/Locator-Status-Bits field, followed by the inner IP header with EID source and destination addresses.