RFC 6834

Locator/ID Separation Protocol (LISP) Map-Versioning

📅 published January 2013, from ietf

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

Okay bestie, let's get into it! Here's the title block, the stuff you check first:

  • Stream: Internet Engineering Task Force (IETF) 🌸
  • RFC number: 6834
  • Title: Locator/ID Separation Protocol (LISP) Map-Versioning
  • Authors: L. Iannone (Telecom ParisTech), D. Saucez (INRIA Sophia Antipolis), O. Bonaventure (Universite catholique de Louvain) 👑
  • Category: Experimental 🧪
  • ISSN: 2070-1721
  • Date: January 2013
  • Obsoletes / Updates: the header doesn't list any RFCs that this one obsoletes or updates ✨

Table of Contents 📑

   1. Introduction ....................................................3
   2. Requirements Notation ...........................................4
   3. Definitions of Terms ............................................4
   4. EID-to-RLOC Map-Version Number ..................................4
      4.1. The Null Map-Version .......................................5
   5. Dealing with Map-Version Numbers ................................6
      5.1. Handling Destination Map-Version Number ....................7
      5.2. Handling Source Map-Version Number .........................9
   6. LISP Header and Map-Version Numbers ............................10
   7. Map Record and Map-Version .....................................11
   8. Benefits and Case Studies for Map-Versioning ...................12
      8.1. Map-Versioning and Unidirectional Traffic .................12
      8.2. Map-Versioning and Interworking ...........................12
           8.2.1. Map-Versioning and Proxy-ITRs ......................13
           8.2.2. Map-Versioning and LISP-NAT ........................13
           8.2.3. Map-Versioning and Proxy-ETRs ......................14
      8.3. RLOC Shutdown/Withdraw ....................................14
      8.4. Map-Version for Lightweight LISP Implementation ...........15
   9. Incremental Deployment and Implementation Status ...............15
   10. Security Considerations .......................................16
      10.1. Map-Versioning against Traffic Disruption ................16
      10.2. Map-Versioning against Reachability Information DoS ......17
   11. Open Issues and Considerations ................................17
      11.1. Lack of Synchronization among ETRs .......................17
   12. Acknowledgments ...............................................19
   13. References ....................................................19
      13.1. Normative References .....................................19
      13.2. Informative References ...................................19
   Appendix A. Estimation of Time before Map-Version Wrap-Around .....21

Abstract 💅

Okay so this doc is all about LISP Map-Versioning, which is a way to put version info right inside the packet about the EID-to-RLOC mappings (Endpoint ID to Routing Locator) that get used to encapsulate LISP data packets. The big idea is giving every mapping a version number and carrying that number in the LISP-specific header of encapsulated packets. It's especially useful for letting the communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) know when the mappings used for encapsulation have changed. 🔥 Best part: it's totally transparent to implementations that don't support it, because the Map-Versioning bits in the LISP-specific header and in the Map Records can just be safely ignored by ITRs and ETRs that don't support the mechanism. 🫶

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation. 🧪

This document defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the full picture. 💖

Info about the current status of this document, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc6834. ✨

Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 📝

1. Introduction 🌸

This document describes the Map-Versioning mechanism that gives info on changes to the EID-to-RLOC (Endpoint ID to Routing Locator) mappings used in the LISP (Locator/ID Separation Protocol [RFC6830]) context to do packet encapsulation. The mechanism is totally transparent to xTRs (Ingress and Egress Tunnel Routers) that don't support it. It's not meant to replace any existing LISP mechanisms. It's more like an upgrade that adds new functionality on top. 💅 If for any unforeseen reason a normative conflict shows up between this document and the LISP main specifications, the latter ([RFC6830]) takes precedence over this document. 👑

The basic move is to attach a Map-Version number to each LISP EID-to-RLOC mapping and carry 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 (adding or removing one or more RLOCs), but it can also mean the priority or weight of one or more RLOCs changes. 🦋

When Map-Versioning is in use, LISP-encapsulated data packets carry the version numbers of the two mappings used to select the RLOCs in the outer header (that means both source and destination). These version numbers are encoded in the 24 low-order bits of the first longword of the LISP header, and a specific bit in the flags (the first 8 high-order bits of the first longword of the LISP header) indicates them. Not every packet has to carry version numbers, though. 🍓

When an ITR (Ingress Tunnel Router) encapsulates a data packet with a LISP header that contains Map-Version numbers, it puts two version numbers in the LISP-specific header:

  1. The version number assigned to the mapping (contained in the EID-to-RLOC Database) used to select the source RLOC.
  2. The version number assigned to the mapping (contained in the EID-to-RLOC Cache) used to select the destination RLOC.

This is a two-fold operation, and it's so useful. 🧚 On one hand, it lets the ETR (Egress Tunnel Router) that receives the packet figure out whether the ITR has the latest version number that any ETR at the destination EID site has given the ITR in a Map-Reply. If the ITR doesn't have it, the ETR can send the ITR a Map-Request with the updated mapping, or it can ask the ITR for a Map-Request. Both of these cases are already defined in [RFC6830]. That way the ITR can update its EID-to-RLOC Cache. ✨ On the other hand, an ETR that receives such a packet can check whether it already has the latest mapping for the source EID in its EID-to-RLOC Cache. This matters for bidirectional traffic. If it doesn't, a Map-Request can be sent. 💜

Issues and concerns about deploying LISP for Internet traffic are discussed in [RFC6830]. Section 11 covers extra issues and concerns raised by this document. In particular, Section 11.1 goes into detail on the ETRs' synchronization issue in the context of Map-Versioning. 🔥

2. Requirements Notation 📐

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🫶

3. Definitions of Terms 📖

This document uses terms that are already defined in the main LISP specification [RFC6830]. Here we define the terms that are specific to the Map-Versioning mechanism. Throughout the whole document, Big Endian bit ordering is used. 🎀

Map-Version number: An unsigned 12-bit integer that's assigned to an EID-to-RLOC mapping, not including the value 0 (0x000).

Null Map-Version: The 12-bit null value of 0 (0x000) is not used as a Map-Version number. It's used to signal that no Map-Version number is assigned to the EID-to-RLOC mapping. 🙈

Source Map-Version number: This Map-Version number of the EID-to-RLOC mapping is used to select the source address (RLOC) of the outer IP header of LISP-encapsulated packets. 💅

Destination Map-Version number: This Map-Version number of the EID-to-RLOC mapping is used to select the destination address (RLOC) of the outer IP header of LISP-encapsulated packets. 👑

4. EID-to-RLOC Map-Version Number 🦋

The EID-to-RLOC Map-Version number is an unsigned 12-bit integer. Versions are assigned per mapping, which means different mappings have different version numbers, and each one gets updated on its own schedule. An update (a newer version) is made by incrementing the older version number by one. 🍓 Appendix A has a rough estimate of how long it takes the Map-Version number to wrap around. ⏳

The space of version numbers has a circular order. Half of the version numbers are greater (so, newer) than the current Map-Version number, and the other half are smaller (so, older) than it. 🌀 Here's the more formal version: say we have two version numbers, V1 and V2, and the numbers are expressed in N bits. The following steps MUST be performed, in the same order as shown below, to strictly define their order:

  1. V1 = V2: The Map-Version numbers are the same.
  2. V2 > V1: if and only if the following holds:
V2 > V1 AND (V2 - V1) <= 2**(N-1)

OR

V1 > V2 AND (V1 - V2) > 2**(N-1)
  1. V1 > V2: otherwise.

Using 12 bits, as this document defines, and assuming a Map-Version value of 69, Map-Version numbers in the range [70; 69 + 2048] are greater than 69, while Map-Version numbers in the range [69 + 2049; (69 + 4096) mod 4096] are smaller than 69. 🧮✨

Map-Version numbers are assigned to mappings by configuration. The initial Map-Version number of a new EID-to-RLOC mapping SHOULD be assigned randomly, but it MUST NOT be set to the Null Map-Version value (0x000), because the Null Map-Version number has a special meaning (see Section 4.1). 🙈

On 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 described in this document. ETRs MUST NOT automatically generate and assign Map-Version numbers to mappings in the EID-to-RLOC Database. Bestie, don't let them do it on their own! 💀🫶

4.1. The Null Map-Version 🫶

okay so the value 0x000 (zero) is not a valid Map-Version number for the EID-to-RLOC mapping 🙈. It's set aside for special jobs, and it gets the name Null Map-Version number 💖.

The Null Map-Version MAY appear in the LISP-specific header as either a Source Map-Version number (cf. Section 5.2) or a Destination Map-Version number (cf. Section 5.1) 🎀. When the Source Map-Version number is the Null Map-Version value, it means no map version info is conveyed for the source site. So if there's a mapping for the source EID in the EID-to-RLOC Cache, the ETR MUST NOT compare the received Null Map-Version with the contents of that cache 🙅‍♀️. When the Destination Map-Version number is the Null Map-Version value, it means no map version info is conveyed for the destination site. In that case the ETR MUST NOT compare the value with the Map-Version number of the mapping for the destination EID in the EID-to-RLOC Database 💅.

The other place the Null Map-Version number shows up is in Map Records, which are part of the Map-Request, Map-Reply, and Map-Register messages (defined in [RFC6830]) 🧚. A Map Record with a Null Map-Version number says there's no Map-Version number tied to that mapping 🌸. That means LISP-encapsulated packets going to the EID-Prefix in that Map Record MUST either not contain any Map-Version numbers (V-bit set to 0), or, if they do contain them (V-bit set to 1), the destination Map-Version number MUST be set to the Null Map-Version number 🔥. Anything different from zero means Map-Versioning is supported and MAY be used ✨.

And the last bit, which is a big one 👑: since 0 has a special meaning, when you're updating a Map-Version number because the mapping changed and the next value would be 0, the Map-Version number MUST be incremented by 2 (i.e., set to 1, which is the next valid value) 💜.

5. Dealing with Map-Version Numbers 🦋

The main idea behind Map-Version numbers is that whenever the mapping changes (like adding or removing RLOCs, tweaking the weights for Traffic Engineering policies, or changing the priorities), or a LISP site realizes one or more of its own RLOCs aren't reachable anymore from its local point of view (for example through IGP or policy changes), the LISP site updates the mapping and gives it a new Map-Version number 💅.

Every mapping has a version number attached, and it changes each time the mapping changes ✨. Map-Versioning doesn't bring new headaches for coordinating the different ETRs of a domain 🫶. ETRs belonging to the same LISP site must return the same mapping for a specific EID-Prefix, including the same Map-Version number. In principle, that has nothing to do with whether Map-Versioning is turned on. The synchronization problem and its impact on traffic are out of scope for this document (see Section 11) 🙈.

To announce in a data-driven way that the mapping has been updated, the Map-Version numbers used to create the outer IP header of the LISP-encapsulated packet get embedded in the LISP-specific header 🦋. So the header needs to carry two Map-Version numbers:

  • The Source Map-Version number of the EID-to-RLOC mapping in the EID-to-RLOC Database used to select the source RLOC.
  • The Destination Map-Version number of the EID-to-RLOC mapping in the EID-to-RLOC Cache used to select the destination RLOC.

By embedding both the Source and Destination Map-Version numbers, an ETR that gets a LISP packet with Map-Version numbers can run these checks:

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

If one or both of those don't hold, the ETR can send a Map-Request either to make the ITR aware that a new mapping is available (see Section 5.1) or to update the mapping in its local EID-to-RLOC Cache (see Section 5.2) 💖.

5.1. Handling Destination Map-Version Number 🎀

When an ETR gets a packet, the Destination Map-Version number is about 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 Destination Map-Version number 👑. A check on this version number can go three ways:

  1. The packet arrives with the same Destination Map-Version number stored in the EID-to-RLOC Database. This is the regular case. The ITR sending the packet has an up-to-date mapping in its EID-to-RLOC Cache. No further actions are needed.
  2. The packet arrives with a Destination Map-Version number greater (i.e., newer) 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, this implies someone isn't behaving correctly with respect to the specifications 🙅. The packet carries a version number that isn't valid, because otherwise the ETR would have the same number, and the packet SHOULD be silently dropped 💀.
  3. The packets arrive with a Destination Map-Version number smaller (i.e., older) than the one stored in the EID-to-RLOC Database. This means the ITR sending the packet has an old mapping in its EID-to-RLOC Cache with stale information. The ETR MAY choose to normally process the encapsulated datagram according to [RFC6830]; however, the ITR has to be informed that a newer mapping is available. This is done with a Map-Request message sent back to the ITR. The Map-Request will either trigger a Map-Request back using the Solicit-Map-Request (SMR) bit, or it will piggyback the newer mapping. These aren't new mechanisms. How to use the SMR bit or how to piggyback mappings in Map-Request messages is already described in [RFC6830], while their security is discussed in [LISP-THREATS]. These Map-Request messages should be rate-limited (rate-limitation policies are also described in [RFC6830]). The feature Map-Version numbers introduce is the possibility of blocking traffic that isn't using the latest mapping. Indeed, after a certain number of retries, if the Destination Map-Version number in the packets still isn't updated, the ETR MAY drop packets with a stale Map-Version number while strongly reducing the rate of Map-Request messages. This is because either the ITR is refusing to use the mapping for which the ETR is authoritative, or (worse) it might be some form of attack. Another case might be that the control plane is experiencing transient failures, so the Map-Requests can't reach that ITR. By continually sending Map-Requests at a very low rate, it's possible to recover from this situation 🥺.

The rule in the third case MAY be more restrictive 🧐. If the mapping has been the same for a period of time as long as the Time to Live (TTL) (defined in [RFC6830]) of the previous version of the mapping, all packets arriving with an old Map-Version SHOULD 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 the same time as the TTL of the older mapping, all the entries in the EID-to-RLOC Caches of ITRs must have expired. So all ITRs sending traffic should have refreshed the mapping according to [RFC6830]. If packets with old Map-Version numbers are still received, then either someone hasn't respected the TTL or it's a form of spoof/attack. In both cases this is not valid behavior with respect to the specifications, and the packet SHOULD be silently dropped 🚫.

LISP-encapsulated packets with the V-bit set, when the original mapping in the EID-to-RLOC Database has the version number set to the Null Map-Version value, MAY be silently dropped. As explained in Section 4.1, if an EID-to-RLOC mapping has a Null Map-Version, it means that ITRs using the mapping for encapsulation MUST NOT use a Map-Version number in the LISP-specific header 🙅‍♀️.

For LISP-encapsulated packets with the V-bit set, when the original mapping in the EID-to-RLOC Database has the version number set to a value different from the Null Map-Version value, a Destination Map-Version number equal to the Null Map-Version value means that the Destination Map-Version number MUST be ignored 🌈.

5.2. Handling Source Map-Version Number 🌈

When an ETR gets a packet, the Source Map-Version number relates to the mapping for the source EID that the ITR which sent the packet is authoritative for. If the ETR has an entry in its EID-to-RLOC Cache for the source EID, then a check can 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 Cache. This is the correct regular case. The ITR has an up-to-date copy of the mapping in its EID-to-RLOC Cache. No further actions are needed ✨.
  2. The packet arrives with a Source Map-Version number greater (i.e., newer) than the one stored in the local EID-to-RLOC Cache. This means the ETR has a stale mapping in its EID-to-RLOC Cache that needs to be updated. A Map-Request SHOULD be sent to get the new mapping for the source EID. This is a normal Map-Request message sent through the mapping system, and it MUST respect the specifications in [RFC6830], including rate-limitation policies 🦋.
  3. The packet arrives with a Source Map-Version number smaller (i.e., older) than the one stored in the local EID-to-RLOC Cache. This isn't valid with respect to the specifications. If the mapping is already in the EID-to-RLOC Cache, that means an explicit Map-Request was sent and a Map-Reply was received from an authoritative source. Assuming the mapping system isn't corrupted, the Map-Version in the EID-to-RLOC Cache is the correct one, while the one carried by the packet is stale. In this situation, the packet MAY be silently dropped 🙈.

If the ETR doesn't have an entry in the EID-to-RLOC Cache for the source EID (e.g., in the case of unidirectional traffic), then the Source Map-Version number can be safely ignored 🧚.

For LISP-encapsulated packets with the V-bit set, if the Source Map-Version number is the Null Map-Version value, it means the Source Map-Version number MUST be ignored 💜.

6. LISP Header and Map-Version Numbers ✨

okay so for the versioning thing to actually work, the LISP-specific header has to carry BOTH the Source Map-Version number and the Destination Map-Version number 🫶 you do that by setting the V-bit in the LISP-specific header, as defined in [RFC6830] Section 5.3. when the V-bit is set, the low-order 24 bits of the first longword are used to carry both numbers. the first 12 bits hold the Source Map-Version number and the second 12 bits hold the Destination Map-Version number 🦋

here's a LISP header carrying version numbers in the case of IPv4-in-IPv4 encapsulation. the same setting works for any other case too (IPv4-in-IPv6, IPv6-in-IPv4, and IPv6-in-IPv6) 🌈

        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|flags|  Source Map-Version   |Destination Map-Version|
   LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                 Instance ID/Locator-Status-Bits               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Source Map-Version number (12 bits): this is the Map-Version of the mapping the ITR used to pick the RLOC sitting in the Source Routing Locator field. Section 5.2 tells you how to set it when sending and how to handle it when receiving 💅

Destination Map-Version number (12 bits): this is the Map-Version of the mapping the ITR used to pick the RLOC sitting in the Destination Routing Locator field. Section 5.1 tells you how to set it when sending and how to handle it when receiving 💖

this document ONLY specifies how to use the low-order 24 bits of the first longword of the LISP-specific header when the V-bit is set to 1. everything else, including the bit fields of the rest of the LISP-specific header and the whole LISP packet format, lives in [RFC6830] 📚 not every LISP-encapsulated packet needs to carry version numbers. but when Map-Version numbers ARE carried in these packets, the V-bit MUST be set to 1. all the permissible combinations of flags when the V-bit is set to 1 are described in [RFC6830] ✨

7. Map Record and Map-Version

so the Map Records that travel in Map-Request/Map-Reply/Map-Register messages also need to carry the Map-Version number, otherwise the whole mechanism falls apart 🙈 for this, the 12 bits right before the EID-Prefix-AFI field in the Record that describes a mapping get used. this is defined in Section 6.1.4 of [RFC6830], and it's repeated here as an example 🍓

        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                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Map-Version Number: this is the Map-Version of the mapping inside the Record. as Section 4.1 explains, this field can be zero (0), which means no Map-Version is attached to the mapping. so packets LISP-encapsulated with that mapping MUST NOT contain Map-Version numbers in the LISP-specific header, and the V-bit MUST be set to 0 🧚

this packet format works perfectly with xTRs that don't support Map-Versioning, since they can just ignore those bits 💜

8. Benefits and Case Studies for Map-Versioning

in the next sections we dig into more of the vibes and uses of Map-Versioning ✨ security observations are grouped in Section 10 🔥

8.1. Map-Versioning and Unidirectional Traffic

when you use Map-Versioning, the LISP-specific header carries TWO Map-Version numbers, one for the source mapping and one for the destination mapping. this raises the question of what happens with unidirectional flows, like the case in Figure 1, because the LISP specification does NOT mandate that the ETR have a mapping for the source EID 👀

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

Figure 1: Unidirectional Traffic between LISP Domains

for the ITR, it can put BOTH the source and destination version numbers in the LISP header. the Source Map-Version number lives in the ITR's database, and the Destination Map-Version number lives in the ITR's cache 🌸

for the ETR, it only checks the Destination Map-Version number, the same way Section 5 describes, and it ignores the Source Map-Version number 🙌

8.2. Map-Versioning and Interworking

Map-Versioning is compatible with the LISP interworking between LISP and non-LISP sites defined in [RFC6832]. LISP interworking defines three techniques for making LISP sites and non-LISP sites talk to each other: Proxy-ITR, LISP-NAT, and Proxy-ETR. the next bits describe how Map-Versioning relates to each of these three mechanisms 🦋

8.2.1. Map-Versioning and Proxy-ITRs

the whole point of the Proxy-ITR (PITR) is to encapsulate traffic coming from a non-LISP site so it can be delivered to one of the ETRs of the LISP site (see Figure 2). this is super similar to the unidirectional traffic case in Section 8.1, so similar rules apply 💅

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

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

the main difference is that a Proxy-ITR does NOT have any mapping, since it just encapsulates packets arriving from the non-LISP site. so it can't give a Source Map-Version. in this case the Proxy-ITR just puts the Null Map-Version value in as the Source Map-Version number, and the receiving ETR ignores that field 🫠

with this setup, LISP Domain A can check whether the PITR is using the latest mapping. if it isn't, the mapping for LISP Domain A on the PITR can be updated using one of the mechanisms defined in [RFC6830] and [RFC6832] 🔄

8.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 just doesn't apply here 🙅‍♀️

8.2.3. Map-Versioning and Proxy-ETRs

the Proxy-ETR (PETR) exists to decapsulate traffic coming from a LISP site so the packet can get delivered to the non-LISP site (see Figure 3). one of the big reasons people deploy PETRs is to get around uRPF (Unicast Reverse Path Forwarding) checks on the provider edge 🏰

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

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

a Proxy-ETR does NOT have any mapping, since it just decapsulates packets arriving from the LISP site. so in this case the ITR just puts the Null Map-Version value in as the Destination Map-Version number, and the receiving Proxy-ETR ignores that field 🌈

with this setup the Proxy-ETR can check whether the mapping has changed. if it has, the mapping for LISP Domain A on the PETR can be updated using one of the mechanisms defined in [RFC6830] and [RFC6832] 💖

8.3. RLOC Shutdown/Withdraw

Map-Versioning can also be used to do a graceful shutdown or withdraw of a specific RLOC 🌷 you do this by issuing a new mapping with an updated Map-Version number, where the RLOC being shut down is withdrawn or announced as unreachable (via the R-bit in the Map Record; see [RFC6830]), but WITHOUT actually turning it off yet ⭐

once no more traffic is being received by the RLOC, it can be shut down gracefully, because all the sites actively using the mapping have updated it 🫶

It should be pointed out that for frequent up/down changes such a mechanism should not be used, since this can generate excessive load on the mapping system. bestie, don't spam the mapping system 💀

8.4. Map-Version for Lightweight LISP Implementation ✨

Okay so Map-Versioning can be a total lifesaver if you're trying to build a lightweight LISP implementation 🪶. The catch? You don't get support for the Locator-Status-Bit, and that's useful in some contexts, so it's a real tradeoff, bestie.

In the current LISP specs, the set of RLOCs must always be maintained ordered and consistent with the content of the Locator-Status-Bits (see Section 6.5 of [RFC6830]). With Map-Versioning, you can skip all that babysitting 🙌 Adding a new RLOC to a mapping doesn't mean you have to "append" new Locators to the existing ones like Section 6.5 of [RFC6830] describes. Instead, a new mapping gets issued with a new Map-Version number. The old Locators are still valid, so the transition happens with no disruptions 💖 The same goes for withdrawing an RLOC. You don't need to keep holes in the list of Locators for sites that aren't using the withdrawn RLOC, which you would have to do with Locator-Status-Bits. Again, the transition is totally smooth ✨

Also, none of these operations need to keep the Locator-Status-Bits and the way the RLOCs are stored in the EID-to-RLOC Cache consistent with each other. Iconic 💅

Here's another slay: Map-Versioning can be used as a substitute for the "clock sweep" operation described in Section 6.6.1 of [RFC6830]. Every LISP site that talks to a specific LISP site which has updated its mapping gets told about the new mapping in a data-driven manner 🦋

Now the important bit 👀 What's proposed in this section is just an example, so it MUST NOT be considered as specifications for a lightweight LISP implementation. If the IETF decides to take on that work, it'll be documented somewhere else 🧚

9. Incremental Deployment and Implementation Status 🚀

Map-Versioning can be rolled out incrementally without any negative impact on existing LISP elements (e.g., xTRs, Map-Servers, Proxy-ITRs, etc.) 🌸 Any LISP element that doesn't support Map-Versioning can safely ignore the Map-Version numbers carried in the LISP header. Even better, there's no need for any specific mechanism to discover whether or not an xTR supports Map-Versioning, because that info is already included in the Map Record 🎀

Map-Versioning is currently implemented in OpenLISP [OPENLISP] 💜

Note that the reference document for LISP implementations and interoperability tests remains [RFC6830] 📚

10. Security Considerations 🔒

Okay, this is the serious part, so pay attention 🫶 Map-Versioning does not introduce any security issues for either the data plane or the control plane. Honestly, it's even better than that. As described below, if Map-Versioning is also used to update mappings when reachability information changes (instead of the Locator-Status-Bits), it's possible to reduce the effects of some DoS or spoofing attacks that can happen in an untrusted environment 🛡️

The robustness of the Map-Versioning mechanism depends on a trusted Mapping Distribution System. A thorough security analysis of LISP is documented in [LISP-THREATS] 😭

10.1. Map-Versioning against Traffic Disruption

An attacker can try to disrupt ongoing communications by creating LISP-encapsulated packets with wrong Locator-Status-Bits. If the xTR blindly trusts the Locator-Status-Bits, it will change the encapsulation accordingly, and that can result in traffic disruption 💀

This doesn't happen with Map-Versioning! 🙅‍♀️ As described in Section 5, when the version number changes, the xTR first issues a Map-Request. The assumption here is that the mapping distribution system is secure enough that Map-Request and Map-Reply messages and their content can be trusted. Security issues concerning specific mapping distribution systems are out of scope for this document. With Map-Versioning, the attacker would have to "guess" a valid version number that triggers a Map-Request as described in Section 5. If they don't, the packet is simply dropped 🗑️ Here's the thing though: guessing a version number that generates a Map-Request is easy, so it's important to follow the rate-limitation policies described in [RFC6830] to avoid DoS attacks ⚠️

Heads up: a similar level of security can be obtained with Locator-Status-Bits by simply making it mandatory to verify any change through a Map-Request. However, in that case the Locator-Status-Bits lose their meaning, because it no longer matters which specific bits changed. The xTR will query the mapping system and trust the content of the received Map-Reply. Also, there's no way to filter packets the way Map-Versioning does, so you can't drop packets that don't carry a valid Map-Version number. With Locator-Status-Bits, any random change can trigger a Map-Request (unless rate limitation is enabled, which raises another type of attack as discussed in Section 10.2) 😵‍💫

10.2. Map-Versioning against Reachability Information DoS

Attackers can try to trigger a huge number of Map-Requests by simply forging packets with random Map-Versions or random Locator-Status-Bits. In both cases, the Map-Requests are rate-limited as described in [RFC6830]. But here's the difference 💅 With the Locator-Status-Bit there's no filtering possible, whereas with Map-Versioning you can filter invalid version numbers before triggering a Map-Request, which helps reduce the effects of DoS attacks. In other words, Map-Versioning gives you fine control over when to update a mapping or when to notify someone that a mapping has been updated 🎯

To be clear, Map-Versioning does not protect against DoS and DDoS attacks in which an xTR loses processing power while checking the LISP header of packets sent by attackers. That's independent of Map-Versioning and is the same for Locator-Status-Bits 🥲

11. Open Issues and Considerations 🌈

There are a number of implications of using Map-Versioning that aren't fully explored yet 🔍 Among these are:

  • Performance of the convergence time when an EID-to-RLOC mapping changes, i.e., how much time is needed to update mappings in the EID-to-RLOC Cache of the ITRs currently sending traffic to ETRs for the EID whose mapping has been changed.
  • Support for ETR synchronization. The implications that a temporary lack of synchronization may have on the traffic are yet to be fully explored. Details on how to maintain synchronization are presented in Section 6.6 of [RFC6830]. Section 11.1 discusses the issue in further detail with respect to the Map-Versioning mechanism.

The authors expect that experimentation will help assess the performance and limitations of the Map-Versioning mechanism 🧪 Issues and concerns about deploying LISP for Internet traffic are discussed in [RFC6830] 🌍

11.1. Lack of Synchronization among ETRs

Even without Map-Versioning, LISP ([RFC6830]) requires ETRs to announce the same mapping for the same EID-Prefix to a requester. The implications that a temporary lack of synchronization may have on the traffic are yet to be fully explored 🤔

Map-Versioning doesn't require additional synchronization mechanisms compared to the normal functioning of LISP without Map-Versioning. Clearly, all the ETRs have to reply with the same Map-Version number, otherwise there can be an inconsistency that creates additional control traffic, instabilities, and traffic disruptions. It's the same without Map-Versioning, where ETRs have to reply with the same mapping, or else the same problems can arise 🙃

There are two ways Map-Versioning is helpful with respect to the synchronization problem ✨ On the one hand, assigning version numbers to mappings helps with debugging, since you can do quick checks on the consistency of the mappings on different ETRs just by looking at the Map-Version number 🔎 On the other hand, Map-Versioning can be used to control the traffic toward ETRs that announce the latest mapping 🎯

Let's look at an example, the topology of Figure 4. ITR A.1 of Domain A is sending unidirectional traffic to Domain B, while A.2 of 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 4: 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 instance, if the two ITRs of Domain A send different Locator-Status-Bits, then either the traffic gets disrupted (if ETR B trusts the Locator-Status-Bits), or ETR B doesn't trust them and starts sending Map-Requests to confirm each change in reachability 😬

So far, LISP doesn't provide any specific synchronization mechanism. Instead, it assumes that synchronization is handled by configuring the different xTRs consistently (see Section 6.6 in [RFC6830]). The same applies to Map-Versioning. If a synchronization mechanism is provided in the future, Map-Versioning will take advantage of it automatically, since it's included in the Record format, as described in Section 7 💖

12. Acknowledgments 💌

The authors would like to thank Alia Atlas, Jesper Skriver, Pierre Francois, Noel Chiappa, and Dino Farinacci for their comments and review 🫶

This work has been partially supported by the INFSO-ICT-216372 TRILOGY Project (http://www.trilogy-project.org) 🦋

13. References 📚

13.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013.
  • [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013.

13.2. Informative References

  • [LISP-THREATS] Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats Analysis", Work in Progress, October 2012.
  • [OPENLISP] Iannone, L., Saucez, D., and O. Bonaventure, "Implementing the Locator/ID Separation Protocol: Design and experience", Computer Networks Vol. 55, Number 4, Pages 948-958, March 2011.

Appendix A. Estimation of Time before Map-Version Wrap-Around ✨

Okay bestie, this appendix is basically a countdown clock 🕰️💖 It estimates how long it takes for the Map-Version number to wrap around. That's the 12-bit size we're talking about here.

Let's say the worst case is that a brand-new version gets issued every single second. Then it takes slightly more than 1 hour before the version wraps around 🫶 Quick aside: the granularity of seconds lines up with the rate-limiting policy for Map-Request messages, as proposed in the LISP main specifications ([RFC6830]). Very coherent, very intentional 💅

Alternatively, you can use a granularity of minutes, just like the TTL of the Map-Reply ([RFC6830]) 🧚 In that case the worst-case scenario is a new version every minute, which means a MUCH longer time before wrap-around. With 12 bits, the wrap-around time is almost 3 days. Main character timeline, honestly 🌸

Figure 5 below is a rough estimate of the time before wrap-around in the worst case. It covers different Map-Version sizes (in bits) and different time granularities, so you can see the whole vibe at a glance 🦋

Even in the case of a high mapping change rate (1 per second), the wrap-around time with 12 bits is way bigger than any reasonable Round-Trip Time (RTT) 😭 So there is no risk of race conditions. Literally no drama 👑

   +---------------+--------------------------------------------+
   |Version Number |           Time before Wrap-Around          |
   |  Size (bits)  +---------------------+----------------------+
   |               |Granularity: Minutes | Granularity: Seconds |
   |               | (mapping changes    | (mapping changes     |
   |               |  every 1 minute)    |  every 1 second)     |
   +-------------------------------------+----------------------+
   |          32   |   8171   years      |  136   years         |
   |          30   |   2042   years      |   34   years         |
   |          24   |     31   years      |  194   days          |
   |          16   |     45   days       |   18   hours         |
   |          15   |     22   days       |    9   hours         |
   |          14   |     11   days       |    4   hours         |
   |          13   |      5.6 days       |    2.2 hours         |
   |          12   |      2.8 days       |    1.1 hours         |
   +---------------+---------------------+----------------------+

Figure 5: Estimation of Time before Wrap-Around 🎀

Authors' Addresses 💌

Luigi Iannone Telecom ParisTech

EMail: luigi.iannone@telecom-paristech.fr

Damien Saucez INRIA Sophia Antipolis 2004 route des Lucioles - BP 93 Sophia Antipolis France

EMail: damien.saucez@inria.fr

Olivier Bonaventure Universite catholique de Louvain Place St. Barbe 2 Louvain-la-Neuve Belgium

EMail: olivier.bonaventure@uclouvain.be

That's the whole RFC, bestie! 🌈💜 Map-Versioning is officially iconic ✨

📦 where this page comes from