Locator/ID Separation Protocol (LISP) Map-Versioning
obsoletes
- rfc-6834 — Locator/ID Separation Protocol (LISP) Map-Versioning
Extracted elements (24)
Map-Versioning can be used for graceful RLOC shutdown: publish an updated mapping (new Map-Version) that marks the RLOC unreachable via the R-bit without actually turning it off, then wait at least one TTL for all remote caches to refresh before shutting down the RLOC.
Map-Versioning is transparent to non-supporting xTRs because both the V-bit in the LISP-specific header and the Map-Version field in Map Records occupy bits that older implementations safely ignore, providing full backward compatibility without a negotiation mechanism.
The circular 12-bit version number space uses serial number arithmetic (RFC 1982) so that exactly half the space (2048 values) is considered newer and the other half older than the current version. This enables unambiguous comparison and triggers the correct actions (discard vs. Map-Request) for stale and future versions.
The mechanism is designed to be conservative: packets with invalid or stale Map-Version numbers are dropped in several cases rather than forwarded, because control-plane actions triggered by data-plane events could be exploited for attacks. Manageability was prioritized over requiring complex machinery to distinguish legitimate traffic.
To prevent a very old version number from being mistaken for a new one due to wrap-around in the circular space, operators should update mappings only when all active traffic uses the latest version, or wait at least one mapping TTL before reusing numbers.
A Proxy-ITR (PITR) encapsulating traffic from non-LISP sites has no source mapping and therefore MUST use the Null Map-Version value as the Source Map-Version number; the receiving ETR will ignore the field per Section 7.2.
LISP-NAT does not involve encapsulation, so Map-Versioning does not apply. Proxy-ETRs ignore the Dest Map-Version field but MAY use the Source Map-Version to validate that incoming LISP-encapsulated traffic arrives from a currently authorized source RLOC.
Multiple ETRs within the same LISP site must advertise identical mappings including the same Map-Version number; inconsistent version numbers across ETRs cause additional control traffic, instabilities, and traffic disruptions. No new synchronization mechanism is defined; consistent configuration is assumed.
A Map-Server receiving a Map Record message with an unexpected Map-Version number (e.g., an old one) MUST silently drop the message; an appropriate log action SHOULD be taken.
After 10 Map-Request retries at the rate defined in RFC 9301, if the Dest Map-Version in arriving packets is still stale, the ETR SHOULD drop those packets. If the Record TTL of the previous mapping has already expired, stale-versioned packets MUST be dropped immediately without issuing any Map-Request.
An update to a Map-Version number MUST consist of an increment of the previous version number. The only exception is skipping the Null Map-Version: if the next increment would equal 0x000, the number MUST be incremented by 2 (set to 0x001).
ETRs MUST NOT automatically generate and assign Map-Version numbers to mappings in the EID-to-RLOC Database; upon reboot, ETRs use Map-Version numbers already configured in their database.
If an ETR receives LISP-encapsulated packets with the V-bit set but the authoritative mapping in its EID-to-RLOC Database has the Null Map-Version, those packets MUST be silently dropped.
It is a protocol violation to send LISP-encapsulated packets with a Dest Map-Version number equal to the Null Map-Version value (0x000).
The initial Map-Version number of a new EID-to-RLOC mapping SHOULD be assigned randomly but MUST NOT be set to the Null Map-Version value (0x000). Optionally, the initial value may be configured by operators.
When the Source Map-Version number in a received packet is the Null Map-Version, the ETR MUST NOT compare it with the content of the EID-to-RLOC Map-Cache for the source EID.
A Map-Version number is an unsigned 12-bit integer assigned on a per-mapping basis to an EID-to-RLOC mapping. Version numbers use circular (serial number) arithmetic as defined in RFC 1982, where half the number space is considered newer and half older than the current value.
The Null Map-Version is the special value 0x000 (zero), signaling that no version number is associated with the mapping. It is used by Proxy-ITRs that cannot provide a Source Map-Version and to indicate that the V-bit MUST NOT be set in encapsulated packets for the associated EID-Prefix.
Attackers can forge packets with random Map-Version numbers to trigger a large number of Map-Requests. Map-Versioning mitigates this by allowing packets carrying invalid version numbers to be filtered before a Map-Request is issued, reducing DoS amplification, though it may not be sufficient against a full DDoS attack.
Implementations MUST include mechanisms to avoid log resource exhaustion attacks, since the specification requires logging actions upon certain events (e.g., unexpected Map-Version numbers). The specific mechanisms are outside the scope of this document.
Map-Versioning MUST NOT be used over the public Internet and MUST only be used in trusted, closed deployments. The mechanism relies on LISP data-plane security as specified in RFC 9300 and RFC 9301, and the threat analysis of RFC 7835 applies.
On receipt of a packet, an ETR checks the Source Map-Version against its EID-to-RLOC Map-Cache (if an entry exists): (1) equal — no action; (2) newer than cache — ETR has stale mapping, MUST send a Map-Request; (3) older than cache — packet SHOULD be silently dropped. If no cache entry exists, the Source Map-Version MUST be ignored.
The Map Record format includes a 12-bit Map-Version Number field (after a 4-bit reserved field) in the third 32-bit word, alongside the EID-Prefix-AFI. A value of zero indicates no Map-Version is associated with the mapping.
When the V-bit is set in the LISP-specific header, the lower 24 bits carry two 12-bit Map-Version fields: Source Map-Version (bits 8–19) and Dest Map-Version (bits 20–31), replacing the Instance ID/Locator-Status-Bits word.