RFC 9302

Locator/ID Separation Protocol (LISP) Map-Versioning

📅 published October 2022, from ietf

RFC 9302: Locator/ID Separation Protocol (LISP) Map-Versioning 🦋

okay bestie, the title block is the vibe check 💅

  • RFC number: 9302
  • Category: Standards Track
  • Date: October 2022
  • ISSN: 2070-1721
  • Obsoletes: RFC 6834
  • Authors: L. Iannone (Huawei Technologies France), D. Saucez (Inria), and O. Bonaventure (Universite catholique de Louvain)

Abstract 💖

so this doc describes LISP Map-Versioning, which is a way to put in-packet info about EID-to-RLOC mappings (the ones used to encapsulate LISP data packets) 🎀 the trick is that every mapping gets a version number, and that number rides along in the LISP-specific header of encapsulated packets. it's literally built so communicating ITRs and ETRs can tell when the mappings they're using have changed ✨ and it's optional and transparent. devices that don't support it (or don't want it) can just ignore the Map-Versioning bits in the LISP-specific header and in the Map Records 🙈

this doc also obsoletes RFC 6834, which was the first experimental spec for the mechanisms this one updates 🌸

Status of This Memo 🧚

This is an Internet Standards Track document.

It's a product of the IETF, and it represents the consensus of the IETF community. it got public review and was approved for publication by the IESG. if you want more on Internet Standards, check out Section 2 of RFC 7841 📚

For the current status, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc9302.

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 (https://trustee.ietf.org/license-info) as they stand on the publication date. read those carefully, because they spell out your rights and restrictions for this doc. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Revised BSD License 🔥

Table of Contents 🍓

   1.  Introduction
   2.  Requirements Notation
   3.  Definitions of Terms
   4.  LISP-Specific Header and Map-Version Numbers
   5.  Map Record and Map-Version
   6.  EID-to-RLOC Map-Version Number
     6.1.  The Null Map-Version
   7.  Dealing with Map-Version Numbers
     7.1.  Handling Dest Map-Version Number
     7.2.  Handling Source Map-Version Number
   8.  Security Considerations
   9.  Deployment Considerations
   10. IANA Considerations
   11. References
     11.1.  Normative References
     11.2.  Informative References
   Appendix A.  Benefits and Case Studies for Map-Versioning
     A.1.  Map-Versioning and Unidirectional Traffic
     A.2.  Map-Versioning and Interworking
       A.2.1.  Map-Versioning and Proxy-ITRs
       A.2.2.  Map-Versioning and LISP-NAT
       A.2.3.  Map-Versioning and Proxy-ETRs
     A.3.  RLOC Shutdown/Withdraw
   Authors' Addresses

1. Introduction ✨

okay so this doc describes the Map-Versioning mechanism, which gives info about changes to the EID-to-RLOC mappings used in LISP [RFC9300] [RFC9301] to do packet encapsulation. it's totally transparent to xTRs (Ingress and Egress Tunnel Routers) that don't support or use it 🦋 the LISP architecture lives in [RFC9299], and you're expected to already know that intro doc, so go read it if you haven't 💅

this doc also obsoletes [RFC6834], the initial experimental spec for the mechanisms this doc updates 🌸

the basic idea is giving each LISP EID-to-RLOC mapping a Map-Version number and carrying that number in the LISP-specific header. when a mapping changes, the updated mapping gets a new version number 💜 a change to an EID-to-RLOC mapping can mean the RLOC set changes, like adding or removing an RLOC, or changing the priority or weight of one or more RLOCs 🔥

when Map-Versioning is used, LISP-encapsulated data packets carry the version numbers of the two mappings used to pick the RLOCs in the outer header (so both source and destination RLOCs). this gives two perks:

  1. Map-Versioning lets the ETR that gets the packet know whether the ITR is using the latest mapping version for the destination EID. if it isn't, the ETR can directly send a Map-Request with the updated mapping to the ITR, so the ITR knows the latest version. the ETR can also ask the ITR to trigger a Map-Request to get the latest mapping by sending a Solicit Map-Request (SMR) message. both options are defined in [RFC9301] 🎀
  2. Map-Versioning lets an ETR that gets the packet know whether it has the latest mapping for the source EID in its EID-to-RLOC Map-Cache. if it doesn't, a Map-Request can be sent 🫶

deployment considerations for LISP Map-Versioning are in Section 9 🌈 and the benefits in some common LISP use cases are in Appendix A ✨

2. Requirements Notation 💜

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, like they do here 🔥

3. Definitions of Terms 🍓

this doc uses terms already defined in the main LISP specs ([RFC9300] and [RFC9301]) 💅 it only defines the terms that are specific to Map-Versioning. big-endian bit ordering is used throughout the whole doc 🌸

Map-Version number: an unsigned 12-bit integer assigned to an EID-to-RLOC mapping, which tells you its version number (Section 6) ✨

Null Map-Version: a Map-Version number with a value of 0x000 (zero). it signals that the Map-Version feature isn't being used and no Map-Version number is assigned to the EID-to-RLOC mapping (Section 6.1) 🙈

Dest Map-Version number: the Map-Version of the mapping in the EID-to-RLOC Map-Cache that the ITR uses to pick the RLOC in the Destination Routing Locator field of the outer IP header of LISP-encapsulated packets (Section 7.1) 🦋

Source Map-Version number: the Map-Version of the mapping in the EID-to-RLOC Database that the ITR uses to pick the RLOC in the Source Routing Locator field of the outer IP header of LISP-encapsulated packets (Section 7.2) 🧚

4. LISP-Specific Header and Map-Version Numbers 🎀

for the versioning approach to work, the LISP-specific header has to carry both the Source Map-Version number and the Dest Map-Version number 💖 you do that by setting the V-bit in the LISP-specific header, as specified in [RFC9300] and shown in the example in Figure 1 ✨ all the permissible combinations of the flags when the V-bit is set to 1 are described in [RFC9300] 🫶 not every LISP-encapsulated packet needs to carry version numbers. when the V-bit is set, the LISP-specific header looks like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|L|E|V|I|R|K|K|  Source Map-Version   |   Dest Map-Version    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Instance ID/Locator-Status-Bits               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: LISP-Specific Header Example When Map-Versioning Is in Use 🌟

Source Map-Version number (12 bits): see Section 3 🍓

Dest Map-Version number (12 bits): see Section 3 🍓

5. Map Record and Map-Version 💅

to make this work, the Map Records carried in Map-Request, Map-Reply, and Map-Register messages need to carry the Map-Version number too 🦋 for reference, the Map Record (specified in [RFC9301]) is shown here as Figure 2. this memo does NOT change how Map-Request, Map-Reply, and Map-Register messages work, and they keep operating exactly as [RFC9301] says 🌸

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record TTL                           |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |       EID-Prefix-AFI          |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-Prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Map-Record Format Example 🌈

Map-Version Number: the Map-Version of the mapping in the Record. as Section 6.1 explains, this field can be zero (0), which means no Map-Version is associated with the mapping ✨

the packet format is backward compatible with xTRs that don't support Map-Versioning, because they can just ignore those bits 💖

🚨 a Map-Server that gets a message with an unexpected Map-Version number (like an old one) MUST silently drop the message, and an appropriate log action SHOULD be taken. this one's important, bestie 😭

6. EID-to-RLOC Map-Version Number ✨

okay bestie so the EID-to-RLOC Map-Version number is an unsigned 12-bit integer 💖. Every mapping gets its own version number, so different mappings have different numbers and they update independently 🦋. An update (a newer version) MUST consist of an increment of the older version number. The only exception is the Null Map-Version, which we'll get to at the end of Section 6.1 💀.

The version numbers live in a circular order 🌈. Half of them count as newer than the current Map-Version and half count as older. It's basically a serial number, and the arithmetic from [RFC1982] applies. The ordering is what lets a router react differently: "older" numbers get thrown out, and "newer" numbers trigger Map-Requests (see Section 7 for the tea ☕). To define the order strictly, take two version numbers, V1 and V2, that are both different from the special Null Map-Version (see Section 6.1), expressed on 12 bits. The following steps MUST be performed, in the same order shown below:

  1. V1 = V2: the Map-Version numbers are the same.
  2. V2 > V1: if and only if the expression below is true.
  3. V1 > V2: otherwise.

For step 2, the expression is:

V2 > V1 AND (V2 - V1) <= 2^(12-1)

OR

V1 > V2 AND (V1 - V2) > 2^(12-1)

Let's do an example 🧁. With 12 bits and a Map-Version value of 69, the numbers in [70; 69 + 2048] are greater than 69, while the numbers in [69 + 2049; (69 + 4095) mod 4096] are smaller than 69. Iconic wraparound energy 🔥.

The initial Map-Version number of a new EID-to-RLOC mapping SHOULD be assigned randomly 🎲. It MUST NOT be set to the Null Map-Version value (0x000), because that value has a special meaning (see Section 6.1). Optionally, the initial Map-Version number may be configured.

Upon reboot, an ETR will use the mappings configured in its EID-to-RLOC Database 🔄. If those mappings have a Map-Version number, it gets used according to the mechanisms in this document. ETRs MUST NOT automatically generate and assign Map-Version numbers to mappings in the EID-to-RLOC Database. Not me making up version numbers on my own, no thanks 🙅‍♀️.

6.1. The Null Map-Version

The value 0x000 (zero) is a special Map-Version number 🥺. It means there is actually no version number associated with the EID-to-RLOC mapping. It's used for special purposes and it's called the Null Map-Version number.

Map Records with a Null Map-Version number are saying "there's no Map-Version number for this mapping" 🙈. So LISP-encapsulated packets destined to the EID-Prefix in that Map Record MUST NOT contain any Map-Version numbers (V-bit set to 0). If an ETR gets LISP-encapsulated packets with the V-bit set, while the original mapping in the EID-to-RLOC Database has the Null Map-Version, those packets MUST be silently dropped. Ghosted, no notification 👻.

The Null Map-Version can also show up in the LISP-specific header as a Source Map-Version number (Section 7.2). When the Source Map-Version number is the Null Map-Version, it means no map version information is being shared for the source site. So even if a mapping for the source EID exists in the EID-to-RLOC Map-Cache, the ETR MUST NOT compare the received Null Map-Version with the content of the EID-to-RLOC Map-Cache (Section 7.2). Don't compare apples to nothing 🍎.

Because 0 has a special meaning, there's a little plot twist when you update a Map-Version number after a mapping change 🌀. If the next value would be 0, the Map-Version number MUST be incremented by 2 (i.e., set to 1 (0x001), which is the next valid value). Skip the zero, it's giving main character 💅.

7. Dealing with Map-Version Numbers ✨

The main idea of Map-Version numbers is this: whenever the mapping changes (for example adding or removing RLOCs, changing weights for Traffic Engineering policies, or changing priorities), or a LISP site realizes that one or more of its own RLOCs are no longer reachable from its local point of view (for example through IGP or policy changes), the LISP site updates the mapping and also assigns a new Map-Version number 🦋. Only the latest Map-Version number has to be considered valid. Mapping updates and their Map-Version numbers must be managed so that a very old version number isn't mistaken for a new one (because of the circular numbering space) 🌀. To help with that, simple measures can be taken, like only updating a mapping once all active traffic is using the latest version, or waiting long enough for the mapping in LISP caches to expire. That means waiting at least as long as the mapping Time To Live (TTL), as defined in [RFC9301]. Patience is a virtue, bestie 🫶.

An ETR receiving a LISP packet with Map-Version numbers checks the following predicates 🔍:

  1. The ITR that sent the packet has an up-to-date mapping in its EID-to-RLOC Map-Cache for the destination EID and is performing encapsulation correctly. See Section 7.1 for details.
  2. In the case of bidirectional traffic, the mapping in the local ETR EID-to-RLOC Map-Cache for the source EID is up to date. See Section 7.2 for details.

7.1. Handling Dest Map-Version Number

When an ETR receives a packet, the Dest Map-Version number relates to the mapping for the destination EID that the ETR is an RLOC for 🎯. That mapping lives in the ETR EID-to-RLOC Database. Since the ETR is authoritative for the mapping, it has the correct and up-to-date Dest Map-Version number. A check on this version number MUST be done, and these cases can come up:

  1. The packet arrives with the same Dest Map-Version number stored in the EID-to-RLOC Database. This is the regular case ✅. The ITR that sent the packet has an up-to-date mapping in its EID-to-RLOC Map-Cache. No further actions are needed. Vibes are immaculate.
  2. The packet arrives with a Dest Map-Version number newer (as defined in Section 6) than the one stored in the EID-to-RLOC Database. Since the ETR is authoritative on the mapping, meaning its Map-Version number is the correct one, the packet carries a version number that isn't valid 🚫. Therefore, the packet MUST be silently dropped and an appropriate log action SHOULD be taken. Ugh, who sent this?
  3. The packet arrives with a Dest Map-Version number older (as defined in Section 6) than the one stored in the EID-to-RLOC Database. This means the ITR that sent the packet has an old mapping in its EID-to-RLOC Map-Cache with stale information 🥀. The ETR MAY choose to normally process the encapsulated datagram according to [RFC9300]. However, the ITR that sent the packet MUST be informed that a newer mapping is available, respecting the rate-limitation policies described in [RFC9301]. This is done with a Map-Request message sent back to the ITR, as specified in [RFC9301]. One feature introduced by Map-Version numbers is the ability to block traffic that isn't using the latest mapping. That can happen if an ITR isn't updating the mapping the ETR is authoritative for, or it might be some form of attack 🚨. According to the rate-limitation policy in [RFC9301] for Map-Request messages, after 10 retries, Map-Requests are sent every 30 seconds. If after the first 10 retries the Dest Map-Version number in the packets still isn't updated, the ETR SHOULD drop packets with a stale Map-Version number. Operators can configure exceptions to this recommendation, which are outside the scope of this document.

The rule in the third case MAY be more restrictive 😤. If the Record TTL of the previous mapping has already expired, all packets arriving with an old Map-Version MUST be silently dropped right away, without issuing any Map-Request. That's allowed because, if the new mapping with the updated version number has been unchanged for at least as long as the Record TTL of the older mapping, then all the entries in the EID-to-RLOC Map-Caches of ITRs must have expired. Indeed, all ITRs sending traffic should have refreshed the mapping according to [RFC9301]. Cache clearing, the glow-up 🧚.

It is a protocol violation for LISP-encapsulated packets to contain a Dest Map-Version number equal to the Null Map-Version number (see Section 6.1). Not allowed, period 💀.

7.2. Handling Source Map-Version Number

When an ETR receives a packet, the Source Map-Version number relates to the mapping for the source EID that the ITR that sent the packet is authoritative for 🪞. If the ETR has an entry in its EID-to-RLOC Map-Cache for the source EID, then a check MUST be performed, and these cases can come up:

  1. The packet arrives with the same Source Map-Version number as the one stored in the EID-to-RLOC Map-Cache. This is the regular case ✨. The ETR has an up-to-date copy of the mapping in its EID-to-RLOC Map-Cache. No further actions are needed.
  2. The packet arrives with a Source Map-Version number newer (as defined in Section 6) than the one stored in the local EID-to-RLOC Map-Cache. This means the ETR has a stale mapping in its EID-to-RLOC Map-Cache that needs to be updated 📬. A Map-Request MUST be sent to get the new mapping for the source EID, respecting the rate-limitation policies described in [RFC9301].
  3. The packet arrives with a Source Map-Version number older (as defined in Section 6) than the one stored in the local EID-to-RLOC Map-Cache. Note that if the mapping is already in the EID-to-RLOC Map-Cache, that means an explicit Map-Request was sent and a Map-Reply was received from an authoritative source 📩. In this situation, the packet SHOULD be silently dropped. Operators can configure exceptions to this recommendation, which are outside the scope of this document.

If the ETR does not have an entry in the EID-to-RLOC Map-Cache for the source EID, then the Source Map-Version number MUST be ignored. See Appendix A.1 for an example of when this situation can arise 🙃.

8. Security Considerations 🔒

okay bestie, this section is SERIOUS but also kind of iconic 💅 LISP's security stuff is built on top of [RFC9300] and [RFC9301], so those Security Considerations apply here too 🫶 The big rule: Map-Versioning MUST NOT be used over the public Internet 🚫 and it MUST only be used in trusted and closed deployments 🔐 no exceptions bestie. For a full security analysis of LISP, go read [RFC7835] 🧐

Attackers can totally try to trigger a flood of Map-Requests by just forging packets with random Map-Versions 😭 Map-Requests are rate limited the way [RFC9301] describes, which is a relief 💖 Map-Versioning actually helps here because you can filter packets with invalid version numbers before a Map-Request gets triggered, so it cuts down the DoS damage 🛡️ BUT ngl, it might not be enough to fully protect you from a DDoS attack 💀

This memo has some logging actions for certain events 📝 It is recommended that implementations include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks 🪵 that's a separate problem, so handle it separately 🙈

The specs in this memo are pretty conservative 🧊 in several cases the packets just get dropped 🗑️ That's because control plane actions triggered by the data plane could be abused for attacks, which is scary 👀 There are some corner cases where forwarding a packet with an invalid Map-Version might be considered safe 🤔 but system manageability got priority over building extra machinery to identify legit traffic 🛠️ so yeah, the vibe is "better safe than sorry" 🫶

9. Deployment Considerations 🏗️

LISP needs multiple ETRs in the same site to provide identical mappings for a given EID-Prefix 👯 Good news: Map-Versioning doesn't need any extra synchronization mechanisms 🎉 But every single ETR has to reply with the same mapping, including the same Map-Version number 💅 If they don't, you get inconsistency, which creates extra control traffic, instability, and traffic disruptions 😩

Map-Versioning is helpful for synchronization in two ways ✨ First, giving mappings version numbers helps with debugging 🔍 You can do quick consistency checks across different ETRs just by looking at the Map-Version number 👀 Second, Map-Versioning can steer traffic toward the ETRs that announce the latest mapping 🧭 main character energy 👑

Let's look at Figure 3 🦋 ITR A.1 in Domain A sends unidirectional traffic to Domain B, while A.2 in Domain A exchanges bidirectional traffic with Domain B 🔁 Specifically, ITR A.2 sends traffic to ETR B, and ETR A.2 receives traffic from ITR B 📦

    +-----------------+              +-----------------+
    | Domain A        |              | Domain B        |
    |       +---------+              |                 |
    |       | ITR A.1 |---           |                 |
    |       +---------+    \         +---------+       |
    |                 |      ------->| ETR B   |       |
    |                 |      ------->|         |       |
    |       +---------+    /         |         |       |
    |       | ITR A.2 |---      -----| ITR B   |       |
    |       |         |       /      +---------+       |
    |       | ETR A.2 |<-----        |                 |
    |       +---------+              |                 |
    |                 |              |                 |
    +-----------------+              +-----------------+

                         Figure 3: Example Topology

Obviously, with Map-Versioning, both ITR A.1 and ITR A.2 of Domain A must use the same value 🙃 otherwise the ETR of Domain B will start sending Map-Requests 😬

The same problem can happen without Map-Versioning too 🫠 for example, if the two ITRs of Domain A send different Locator-Status-Bits 💔 Then either the traffic gets disrupted (if ETR B doesn't verify reachability), or ETR B starts sending Map-Requests to confirm every change in reachability 🔄

So far, LISP doesn't have a specific synchronization mechanism 🤷‍♀️ it just assumes synchronization comes from configuring the different xTRs consistently ⚙️ Map-Versioning works the same way 🫶 If a synchronization mechanism shows up in the future, Map-Versioning will take advantage of it automatically 🚀 since the version number is already included in the Map Record format, as described in Section 5 📝

10. IANA Considerations 🌸

This document has no IANA actions 🙌 nothing to register, nothing to do, we're chilling 🧘‍♀️

11. References 📚

11.1. Normative References

Here are the normative refs, the ones you genuinely need to read 🤓

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9300]  Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
           Cabellos, Ed., "The Locator/ID Separation Protocol
           (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
           <https://www.rfc-editor.org/info/rfc9300>.

[RFC9301]  Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
           Ed., "Locator/ID Separation Protocol (LISP) Control
           Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
           <https://www.rfc-editor.org/info/rfc9301>.

11.2. Informative References

And these are the informative ones, the bonus reading for when you're feeling extra 🤓✨

[RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
           DOI 10.17487/RFC1982, August 1996,
           <https://www.rfc-editor.org/info/rfc1982>.

[RFC6832]  Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
           "Interworking between Locator/ID Separation Protocol
           (LISP) and Non-LISP Sites", RFC 6832,
           DOI 10.17487/RFC6832, January 2013,
           <https://www.rfc-editor.org/info/rfc6832>.

[RFC6834]  Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
           Separation Protocol (LISP) Map-Versioning", RFC 6834,
           DOI 10.17487/RFC6834, January 2013,
           <https://www.rfc-editor.org/info/rfc6834>.

[RFC7835]  Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
           Separation Protocol (LISP) Threat Analysis", RFC 7835,
           DOI 10.17487/RFC7835, April 2016,
           <https://www.rfc-editor.org/info/rfc7835>.

[RFC9299]  Cabellos, A. and D. Saucez, Ed., "An Architectural
           Introduction to the Locator/ID Separation Protocol
           (LISP)", RFC 9299, DOI 10.17487/RFC9299, October 2022,
           <https://www.rfc-editor.org/info/rfc9299>.

Appendix A. Benefits and Case Studies for Map-Versioning 🎀

Now the fun part 🧚 We're going deeper into different uses of Map-Versioning, and security observations are grouped in Section 8 🔒

A.1. Map-Versioning and Unidirectional Traffic 🦋

With Map-Versioning, the LISP-specific header carries two Map-Version numbers, one for the source mapping and one for the destination mapping 📦 So what happens with unidirectional flows? Like in Figure 4 👀 The LISP specs don't mandate that the ETR has a mapping from the source EID, so this is a fair question 🤔

    +-----------------+            +-----------------+
    | Domain A        |            | Domain B        |
    |       +---------+            +---------+       |
    |       | ITR A   |----------->| ETR B   |       |
    |       +---------+            +---------+       |
    |                 |            |                 |
    +-----------------+            +-----------------+

           Figure 4: Unidirectional Traffic between LISP Domains

An ITR can put both the source and destination version numbers in the LISP-specific header 🙌 because the Source Map-Version number lives in its database, and the Dest Map-Version number lives in its cache 🗄️

The ETR only checks the Dest Map-Version number and ignores the Source Map-Version number 🙈 as specified in the final sentence of Section 7.2 ✨

A.2. Map-Versioning and Interworking 🌈

Map-Versioning works with the LISP interworking between LISP and non-LISP sites, as defined in [RFC6832] 🫶 LISP interworking gives you three techniques for LISP sites and non-LISP sites to talk to each other: Proxy-ITR, LISP-NAT, and Proxy-ETR 🔁 Here's how Map-Versioning fits with each one 👇

A.2.1. Map-Versioning and Proxy-ITRs 🧚‍♀️

A Proxy-ITR (PITR) encapsulates traffic from a non-LISP site so it can get delivered to one of the ETRs of the LISP site (check out Figure 5) 📦 This is super similar to the unidirectional case in Appendix A.1, so similar rules apply 💖

    +----------+                             +-------------+
    | LISP     |                             | non-LISP    |
    | Domain A |                             | Domain B    |
    |  +-------+        +-----------+        |             |
    |  | ETR A |<-------| Proxy-ITR |<-------|             |
    |  +-------+        +-----------+        |             |
    |          |                             |             |
    +----------+                             +-------------+

    Figure 5: Unidirectional Traffic from Non-LISP Domain to LISP Domain

The main difference is that a Proxy-ITR doesn't have any mapping, since it just encapsulates packets arriving from the non-LISP site 🙃 so it can't provide a Source Map-Version 💀 Instead, the Proxy-ITR just puts the Null Map-Version value as the Source Map-Version number, and the receiving ETR ignores that field 🫶

This setup means LISP Domain A can check whether the PITR is using the latest mapping 🔍 The Proxy-ITR puts the version number of the mapping it used for encapsulation into the Dest Map-Version Number of the LISP-specific header 📝 and ETR A can use that value as defined in Section 7.1 ✨

A.2.2. Map-Versioning and LISP-NAT 🙅‍♀️

LISP-NAT is based on address translation from non-routable EIDs to routable EIDs 🔄 and it doesn't involve any form of encapsulation 🚫 So, Map-Versioning doesn't apply in this case 💅

A.2.3. Map-Versioning and Proxy-ETRs ✨

okay so the Proxy-ETR (PETR) is the one that unwraps traffic which started in a LISP site and delivers the packet to a non-LISP site 🎀 (cf. Figure 6). ngl one of the main reasons people deploy PETRs is to get past Unicast Reverse Path Forwarding checks on the domain 🫶

    +----------+                             +-------------+
    | LISP     |                             | non-LISP    |
    | Domain A |                             | Domain B    |
    |  +-------+        +-----------+        |             |
    |  | ITR A |------->| Proxy-ETR |------->|             |
    |  +-------+        +-----------+        |             |
    |          |                             |             |
    +----------+                             +-------------+

Figure 6: Unidirectional Traffic from LISP Domain to Non-LISP Domain

A Proxy-ETR doesn't have any mapping, because it just decapsulates packets arriving from the LISP site 💅. So the ITR can interchangeably put a Map-Version value or the Null Map-Version value as the Dest Map-Version number, since the receiving Proxy-ETR will ignore the field 🙈. literally doesn't matter what's in there.

With this setup, the Proxy-ETR looks at the Source Map-Version Number and can check whether the mapping of the source EID has changed 👑. That's super useful for source RLOC validation. In the example above, traffic coming from the LISP domain has to be LISP encapsulated with a source address that is an RLOC of the domain. The Proxy-ETR can retrieve the mapping associated with the LISP domain and check whether incoming LISP-encapsulated traffic is arriving from a valid RLOC. A change in the RLOC-Set that can be used as source addresses can be signaled via the version number, and the Proxy-ETR can request the latest mapping if necessary, as described in Section 7.2 🦋

A.3. RLOC Shutdown/Withdraw ✨

Map-Versioning can also be used to do a graceful shutdown or to withdraw a specific RLOC 🌸. The move is to issue a new mapping with an updated Map-Version number, where the specific RLOC to be shut down is withdrawn or announced as unreachable (via the R-bit in the Map Record; see [RFC9301]), but without actually turning it off.

Upon updating the mapping, the RLOC will receive less and less traffic, because remote LISP sites will request the updated mapping and see that it is disabled 📉. At least one TTL, plus a little time for traffic transit, after the mapping is updated, it should be safe to shut down the RLOC gracefully, because all sites actively using the mapping should have been updated 💜.

⚠️ bestie, note that a change in ETR for a flow can result in the reordering of the packet in the flow, just as any other routing change could cause reordering.

Authors' Addresses 🎀

Here's who to thank (and email!) for all of this 🫶

   Luigi Iannone
   Huawei Technologies France
   Email: luigi.iannone@huawei.com


   Damien Saucez
   Inria
   2004 route des Lucioles - BP 93
   Sophia Antipolis
   France
   Email: damien.saucez@inria.fr


   Olivier Bonaventure
   Universite catholique de Louvain
   Email: olivier.bonaventure@uclouvain.be
📦 where this page comes from