Locator/ID Separation Protocol (LISP) Generic Protocol Extension
Extracted elements (23)
LISP-GPE uses the same UDP destination port (4341) as LISP to avoid requiring separate port allocations, with backward compatibility enforced by the P-bit convention.
Shim header values (0x80-0xFD) are separated from direct payload values (0x00-0x7F) to allow xTR implementations to process known shim headers in the fast path (ASIC) while punting unknown GPE features to the slow path, enabling incremental hardware deployment.
The P-bit reuses Flag bit 5 (the last reserved bit in the LISP header) rather than introducing a new header format, ensuring that when P=0 the header is bit-for-bit compatible with RFC 9300, preserving backward compatibility with existing LISP deployments.
When P=1, the Echo-Noncing and Map-Versioning features (bits N, E, V) become unavailable. The document justifies this by noting that equivalent capabilities can be implemented via LISP-GPE shim headers, allowing incremental deployment of new features without changing the base header.
LISP-GPE uses UDP destination port 4341 (the same port as LISP). Because non-LISP-GPE routers ignore the P-bit per RFC 9300, sending LISP-GPE frames (P=1) to such routers would cause misinterpretation of other header fields; capability detection and P-bit=0 enforcement are required before transmitting to legacy endpoints.
The discovery mechanism for xTR capability to support LISP-GPE is explicitly out of scope; in the controlled deployment environment, ITR/ETR configuration mechanisms are expected to handle this.
All shim protocols (Next Protocol 0x80-0xFD) MUST use the header structure in Figure 4 which includes a 'Next Protocol' field. When shim headers are used with protocols identified by Next Protocol values 0x00-0x7F, all shim headers MUST come first.
By default, a UDP checksum MUST be used when LISP-GPE is transported over IPv6. An operator MAY configure zero UDP checksum only under specific conditions (TMCE plus one of three listed criteria).
ECN tunneling behavior as described in RFC 6040 MUST be followed for IP packets encapsulated in LISP-GPE, to properly propagate congestion markers to inner packets.
LISP-GPE MUST be used with congestion-controlled traffic or within a traffic-managed controlled environment (TMCE) to avoid congestion, since LISP-GPE itself provides no congestion-control functionality.
LISP-GPE tunnel implementations using zero UDP checksum over IPv6 MUST use a non-zero UDP checksum as the default configuration, MUST meet RFC 6936 Section 4 requirements, and the ETR SHOULD validate source/destination IPv6 addresses before decapsulation.
Measures SHOULD be taken to prevent LISP-GPE traffic over IPv6 with zero UDP checksum from escaping into the general Internet, for example by employing packet filters at PETR or maintaining logical/physical network separation.
New encapsulated payloads registered with LISP-GPE MUST be accompanied by a set of congestion-control guidelines derived from Section 5 of RFC 9300.
The outer UDP checksum SHOULD be used with LISP-GPE when transported over IPv4, to protect the integrity of LISP-GPE headers, options, and payloads against corruption and misdelivery.
When encapsulating IP packets to a non-LISP-GPE-capable router, the P-bit MUST be set to 0; the LISP-GPE encapsulation format MUST NOT be sent to a router that has not indicated support, as it would misinterpret the header fields.
When the P-bit is set to 1, bits N, E, and V, and bits 8-23 of the 'Nonce/Map-Version/Next Protocol' field MUST be set to zero on transmission and MUST be ignored on receipt.
The 'Next Protocol' field occupies the lower 8 bits of the first 32-bit word when P=1. Defined values: 0x00 Reserved, 0x01 IPv4, 0x02 IPv6, 0x03 Ethernet, 0x04 NSH (RFC 8300), 0x05-0x7D Unassigned, 0x7E-0x7F Experimentation, 0x80-0xFD Unassigned shim headers, 0xFE-0xFF Experimentation shim headers.
The P-bit (Flag bit 5) signals the presence of the 8-bit 'Next Protocol' field. When P=0, the header is bit-for-bit identical to the RFC 9300 LISP header; when P=1, the LISP-GPE encoding applies.
IANA created the 'LISP-GPE Next Protocol' registry of 8-bit values. Initial entries include Reserved (0x00), IPv4 (0x01), IPv6 (0x02), Ethernet (0x03), NSH (0x04), experimentation ranges (0x7E-0x7F, 0xFE-0xFF), and unassigned shim header range (0x80-0xFD). New values require Specification Required policy.
LISP-GPE is subject to on-path adversaries that can arbitrarily modify the P-bit or payload type claims. Typical integrity protection mechanisms such as IPsec SHOULD be used in combination with LISP-GPE by protocol extensions that want to protect against on-path attackers.
LISP-GPE may be subject to data plane spoofing, flooding, and traffic redirection depending on the particular protocol payload encapsulated. Security considerations and mitigation techniques from RFC 7835 (LISP Threat Analysis) apply.
Shim header protocols (Next Protocol 0x80-0xFD) MUST use a common first 32-bit structure: 8-bit Type, 8-bit Length (in 4-octet units, excluding first 4 octets), 8-bit Reserved, and 8-bit Next Protocol, followed by protocol-specific fields.
The LISP-GPE header reuses the 8-bit flag field from RFC 9300 but repurposes Flag bit 5 as the P-bit (Next Protocol bit). When P=1, bits 8-23 of the first 32-bit word are zeroed and the lower 8 bits carry the Next Protocol value, forming a 2-word (64-bit) header.