RFC 9962

A Decentralized Locator/ID Separation Protocol Mapping System (LISP-Decent)

📅 published May 2026, from ietf

RFC 9962: A Decentralized Locator/ID Separation Protocol Mapping System (LISP-Decent) 🎀

(part 1 of 4)

Okay bestie, here's the vibe check on this one 💅. It's an Independent Submission, which means it came in from outside the usual IETF stream. It's marked as Category: Informational ✨, so it's not a standard, just a super useful write-up. It was written by D. Farinacci (lispers.net) and C. Cantrell (Nexus) 🧚, and it was published in May 2026. It has ISSN 2070-1721. It doesn't list any RFCs that it obsoletes or updates, so it's not replacing or changing anything else 🫶.

Abstract

okay so the big idea is that the Locator/ID Separation Protocol (LISP) Mapping System can be spread out across lots of machines to scale, and it can also be managed in a decentralized way 🦋. The whole point is that the data plane nodes still trust each other while doing it 💖. This document is Informational, and it's meant to help LISP-Decent implementations interoperate with each other 🌸. It's giving teamwork, no cap 🫶.

Status of This Memo

This document is not an Internet Standards Track specification. It's published just for info 📖.

This is a contribution to the RFC Series, and it's independent of any other RFC stream 💅. The RFC Editor picked to publish it at their discretion, and they make zero promises about how useful it is for implementing or deploying 🙈. Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard, so see Section 2 of RFC 7841 for the deets ✨.

For the current status of this document, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc9962 🔥.

Copyright (c) 2026 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're in effect on the date this document was published. Please read these carefully, because they describe your rights and restrictions for this document 📜🫶.

Table of Contents

   1.  Introduction
   2.  Definitions of Terms
     2.1.  Requirements Language
   3.  Overview
   4.  Decent-Push-Based Mapping System
     4.1.  Components of a Decent-Push-Based LISP-Decent xTR
     4.2.  Implementation Considerations
     4.3.  Configuration and Authentication
     4.4.  Core Seed-Group
   5.  Decent-Pull-Based Mapping System
     5.1.  Components of a Decent-Pulled Based LISP-Decent xTR
     5.2.  Configurable EID Prefix Lengths for Lookups
     5.3.  Deployment Example
     5.4.  Management Considerations
   6.  Security Considerations
   7.  IANA Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction ✨

okay so the LISP architecture [RFC9300] brings in two new numbering spaces meant to give you overlay network functionality 🦋. One is Endpoint Identifiers (EIDs), and the other is Routing Locators (RLOCs) 💅. To go from an EID to a set of RLOCs, you use a control plane Mapping System [RFC6836] [RFC8111]. These Mapping Systems are naturally spread out across many machines for scalability 🌸, but they're centrally managed by a third-party entity called a Mapping System Provider (MSP) 🙈. The entities that use the Mapping System, like the data plane LISP Tunnel Routers (xTRs), depend on the MSP and trust it. They don't participate in the Mapping System beyond registering and retrieving info [RFC9301] 💜.

This document brings in a Decentralized Mapping System (DMS) so the xTRs can participate in the Mapping System and use it 🔥. They can trust each other instead of relying on third-party infrastructure 🫶. The xTRs act as Map-Servers to keep distributed state for scale and to reduce the attack surface ✨. The trust relationships between the xTRs get set up through the authentication and authorization procedures in [RFC9301] and [ECDSA-AUTH] 🔐.

This design was first brought to the LISP Working Group (WG) in January of 2018 🎀. It was presented in London in March 2018 [IETF101-PRESO] and in Prague in March 2019 [IETF104-PRESO] 🧚. This Informational document is not a standard, and it didn't reach community consensus to become an IETF LISP WG document 🙈.

The intended audience for this specification is protocol development engineers who implement it in products, as well as network engineers who deploy the technology in operational environments 💖.

This design doesn't conflict with those designs, and it doesn't contradict any other LISP design principles the working group produced 🌈. It makes no fundamental LISP changes and sticks to the specifications in [RFC9301] 💅.

By the nature of this work, this document uses IP addresses as examples. They should not be copied or used outside of a lab environment. Deployments should use addresses appropriate for their environment 🚨.

2. Definitions of Terms 📖

Mapping System Provider (MSP): This is the infrastructure service that deploys LISP Map-Resolvers and Map-Servers [RFC9301], and possibly LISP-ALT nodes [RFC6836] or LISP-DDT nodes [RFC8111] 🌸. ALT-nodes and DDT-nodes use different algorithms for hooking Map-Resolvers and Map-Servers together 🧩. The MSP can be run by a separate organization from the one that manages the xTRs 💼. This model gives you a business separation between the org that manages (and is responsible for) the control plane and the org that manages the data plane overlay service 👑.

Decentralized Mapping System (DMS): This is a mapping system entity managed by the xTR nodes that use it, not by third-party nodes or operators 🦋. The xTRs themselves are part of the Mapping System 💖. The state of the Mapping System is fully distributed across the xTRs, and it's decentralized. The trust relies on the xTRs that use it and participate in their own mapping system 🫶.

Decent-Pull-Based Mapping System: This one is pull-based, which means xTRs look up and register mappings using an algorithmic transformation to figure out which Map-Resolvers and Map-Servers to use 🔍. It is required that the lookup and registration use a consistent algorithmic transformation function 💅. Map-Registers get sent to specific Map-Servers ✨. Map-Requests count as external lookups when they're sent to Map-Resolvers on xTRs that don't participate in the mapping system. They count as internal lookups when they're sent to Map-Resolvers on xTRs that do participate in it 🌈.

Modulus Value: This value is used in the Pull-based Mapping System 🎀. It defines the number of Map-Server sets used for the Mapping System 🧚. The modulus value gets used to produce a Name Index, which is used for a Domain Name System (DNS) lookup 🔥. The Modulus Value is chosen based on the horizontal scale-out width of the Map-Server cluster the network operator decides to deploy 📈.

Name Index: This index value <index> is used in the Pull-based Mapping System 🌸. For a Mapping System configured with a Map-Server set of DNS names in the form of <name>.example.com, the Name Index gets prepended to <name> to form the lookup name <index>.<name>.example.com 💜. If the Modulus Value is 8, then the Name Indexes are 0 through 7 🍓.

Hash Mask: The Hash Mask is used in the Pull-based Mapping System 🙈. It's a mask value with 1 bit left justified 🫶. The mask is used to select which high-order bits of an EID-prefix get used in the hash function 🔐.

Decent-Push-Based Mapping System: This one is push-based, which means xTRs push registrations via IP multicast to a group of Map-Servers, and they do local lookups while acting as their own Map-Resolvers 🦋.

Replication List Entry (RLE): This is an RLOC-record format that holds a list of RLOCs that an Ingress Tunnel Router (ITR) replicates multicast packets to on a multicast overlay 🌈. The RLE format is specified in [RFC8060] 💅. RLEs are used with the Decent-Push-based Mapping System ✨.

Group Address EID: This is an EID-record format that holds IPv4 (0.0.0.0/0, G) or IPv6 (0::/0, G) state 🎀. That state is encoded as a Multicast Info Type LISP Canonical Address Format (LCAF) specified in [RFC8060] 🧩. Members of a seed-group send Map-Registers for (0.0.0.0/0, G) or (0::/0, G) with an RLOC-record that RLE-encodes their RLOC address 💖. The details are specified in [RFC8378] 📖.

Seed-Group: This is a set of Map-Servers joined to a multicast group for the Decent-Push-based Mapping System, or mapped by DNS names in a Pull-based Mapping System 🌱. A core seed-group is used to bootstrap a set of LISP-Decent xTRs so they can learn about each other and use each other's Mapping System service 🧚. A seed-group can be pull-based to bootstrap the Decent-Push-based Mapping System. In other words, a set of DNS-mapped Map-Servers can be used to join the mapping system's IP multicast group 🔥.

2.1. Requirements Language 🔑

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💅✨.

3. Overview ✨

okay so bestie, the clients of the DMS are also the providers of mapping state 🫶 see [RFC9301] for the formal details. the clients are usually Egress Tunnel Routers (ETRs) that Map-Register EID-to-RLOC mapping state into the mapping database system 💅 ITRs are clients too, because they send Map-Requests to the mapping database system to grab EID-to-RLOC mappings that get cached for data plane use ✨ when xTRs join a DMS, they're also acting as Map-Resolvers and Map-Servers, using the protocol machinery from the LISP control plane specs [RFC9301], [RFC9303], and [ECDSA-AUTH] 🦋 the xTRs are not required to run the database mapping transport system protocols in [RFC6836] or [RFC8111] 🌸

this doc is going to describe two decentralized and distributed mapping system mechanisms 🔥 the Decent-Push-based Mapping System uses IP multicast, so xTRs find each other by locally joining an IP multicast group 💜 the Decent-Pull-based Mapping System uses DNS with an algorithmic transformation function, so xTRs can still find each other 🧚

the doc proposes two approaches that trade off state/bandwidth, ease of configurability, and robustness/complexity 👑 with the Decent-Push approach there's way less messaging involved 😭 an xTR can multicast a single Map-Register that goes to every Map-Server joined to the group 🎀 when Map-Servers get added or removed from the Map-Server cluster group, the Mapping System updates quickly with very little human intervention ✨ in the push model every Map-Server stores all the mapping state, so robustness comes from redundancy 🫶 BUT this needs a multicast underlay in the nodes between all xTRs and Map-Servers 💀 when there's no multicast underlay, the Decent-Pull approach can be used with the help of DNS 🍓 this one uses less state overall among the Map-Servers (each has different Mapping System state), and the ITRs know which Map-Server to ask by using the hashing techniques described later in this document 🌈

this document does not describe any compatibility with other mapping systems 🙈 the design is intentional so that all xTRs and Map-Servers support this specification 💖 moreover, all xTRs and Map-Servers MUST support either the pull-based or push-based algorithms, and they cannot be mixed 🔥 when both are used, they're completely discrete Mapping Systems, just like they'd be if they used one of the LISP WG Mapping System designs 🦋 an implementation can decide to implement only the pull-based approach or only the push-based approach and still be compliant with this specification 🌸

4. Decent-Push-Based Mapping System 🎀

okay so the xTRs get organized into a mapping-system group ✨ the group is identified by an IPv4 or IPv6 multicast group address, or by using a Decent-Pull-based approach described in Section 5 💅 when using multicast, the xTRs join the same multicast group and receive LISP control plane messages addressed to the group 🫶 messages sent to the multicast group get distributed when the underlay network supports IP multicast [RFC6831], or via the overlay multicast mechanism described in [RFC8378] 🦋 when overlay multicast is used and LISP Map-Register messages are sent to the group, they're LISP data encapsulated with an instance-ID set to 0xffffff in the LISP header 🌸 the inner header of the encapsulated packet has the destination address set to the multicast group address, and the outer header that gets prepended has the destination address set to the RLOC of the Mapping System group member 💜 the members of the Mapping System group are kept in the LISP data plane map-cache, so packets for the group can be replicated to each member RLOC 🧚

all xTRs in a Mapping System group store the same registered mappings and maintain the state the way Map-Servers normally do 👑 the members aren't just receivers of the multicast group, they also send packets to the group 😭

4.1. Components of a Decent-Push-Based LISP-Decent xTR 🌈

when an xTR is configured to be a LISP-Decent xTR (or PxTR [RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP network functions 💖

the diagram below shows 3 LISP-Decent xTRs joined to Mapping System group address 233.252.1.1 🔥 when the ETR function of xTR1 originates a Map-Register, it gets sent to all xTRs (including itself), synchronizing all 3 Map-Servers in xTR1, xTR2, and xTR3 ✨ the ITR function can populate its map-cache by sending a Map-Request locally to its Map-Resolver, so it can replicate packets to each RLOC for EID 233.252.1.1 🫶

in this document there's no special meaning for the multicast group address 233.252.1.1 🙈 it's just used for example purposes only 💅

                        xTR1
 Map-Request    +--------------------+
(always local)  |  +-----+  +-----+  |
   +---------------| ITR |  | ETR |-------------+
   |            |  +-----+  +-----+  |          |
   |            |                    |          |  Map-Register to
   |            |      +-------+     |          |  EID 233.252.1.1
   +------------------>| MR/MS |<---------------+  encapsulated to
                |      +-------+     |          | RLOCs xTR1, xTR2,
                +--------------------+          |     and xTR3
                                                |
                           +--------------------+------------+
                           |                                 |
                           |                                 |
                +----------v---------+            +----------v---------+
                |     +--------+     |            |     +--------+     |
                |     |  MR/MS |     |            |     |  MR/MS |     |
                |     +--------+     |            |     +--------+     |
                |  +-----+  +-----+  |            |  +-----+  +-----+  |
                |  | ITR |  | ETR |  |            |  | ITR |  | ETR |  |
                |  +-----+  +-----+  |            |  +-----+  +-----+  |
                +--------------------+            +--------------------+
                         xTR2                              xTR3

                               Figure 1

note that if any external xTR wants to use a Map-Resolver from the Mapping System group, it only needs to have one of the LISP-Decent Map-Resolvers configured 🦋 by looking at the Map-Resolver for EID 233.252.1.1, the external xTR can get the complete list of members for the Mapping System group 🌸

for future study, an external xTR could multicast the Map-Request to 233.252.1.1, and either one of the LISP-Decent Map-Resolvers would return a Map-Reply, or the external xTR is prepared to receive multiple Map-Replies 💜

4.2. Implementation Considerations 🧚

there are no LISP changes required to support the Decent-Push-based LISP-Decent set of procedures ✨ an implementation that sends Map-Register messages to a multicast group versus a specific Map-Server unicast address MUST change to call the data plane component, so the ITR functionality in the node can encapsulate the Map-Register as a unicast packet to each member of the Mapping System group 👑

an ITR SHOULD look up its Mapping System group address periodically to determine if the membership has changed 😭 the lookup interval is a configuration parameter only needed when the ITR does not use the PubSub capability documented in [RFC9437] to be notified when a new member joins or leaves the multicast group 🎀 when PubSub is not used, there needs to be coordination (via configuration management) among all xTRs so they rendezvous roughly at the same time and to the same group address 🫶

4.3. Configuration and Authentication 🔐

when xTRs are joined to a multicast group, they MUST have their site registration configuration consistent 💅 any policy or authentication key material MUST be configured consistently among all members 🌈 when [ECDSA-AUTH] is used to sign Map-Register messages, public keys can be registered to the Mapping System group using the site authentication key mentioned above, or using a different authentication key from the one used for registering EID records 🦋 an out-of-band registration controller, like an ETR dedicated for this function, can send Map-Register messages for public-key encoded EIDs 💖

4.4. Core Seed-Group ✨

okay so the core seed-group is how a brand-new xTR finds its crew 👯‍♀️ In a Decent-Push-based system you can discover it using a multicast group, and in a Decent-Pull-based system it's a set of Map-Server DNS names instead (see Section 5 for details) 💖

bestie, when you're using multicast for the Mapping System group, you can preconfigure a core seed-group multicast group address to bootstrap the decentralized Mapping System 🌸 The group address (or a DNS name that maps to a group address) can be explicitly configured in a few xTRs so they can start building up the registrations. Then, as other xTRs come online, they add themselves to the core seed-group by joining the seed-group multicast group 🫶

Alternatively or additionally, new xTRs can join a brand-new Mapping System multicast group to form another layer of a decentralized Mapping System 🦋 The group address and members of this new layer seed-group would be registered to the core seed-group address and stored in the core seed-group mapping system. Note that each Mapping System layer could have a specific function or a specific circle of trust 👑

This multi-layer Mapping System can be illustrated like so 🧚

           ____________                 -----------
          /   core     \  233.252.2.2  /  layer-1  \
         | seed-group   | ----------> |      I      |
         |  233.252.1.1 |             |     / \     |
          \____________/              |    J---K    |
               |                       \___________/
               | 233.252.3.3
               |
               v
           ---------
          / layer-2 \
         |     X     |
         |    / \    |
         |   Y---Z   |
          \_________/
                              Figure 2
Configured in xTRs A, B, and C (they make up the core seed-group):
  233.252.1.1 -> RLE: A, B, C

core seed-group DMS, mapping state in A, B, and C:
  233.252.2.2 -> RLE: I, J, K
  233.252.3.3 -> RLE: X, Y, Z

layer-1 seed-group DMS (inter-continental), mapping state in I, J, K:
   EID1 -> RLOCs: i(1), j(2)
   ...
   EIDn -> RLOCs: i(n), j(n)

layer-2 seed-group DMS (intra-continental), mapping sate in X, Y, Z::
   EIDa -> RLOCs: x(1), y(2)
   ...
   EIDz -> RLOCs: x(n), y(n)

The core seed-group multicast address 233.252.1.1 is configured in xTRs A, B, and C, so when each of them sends Map-Register messages, they can all keep their mapping state synchronized 🔁 Any EID can be registered to this DMS, but in this example, the seed-group multicast group EIDs are only being registered to find other Mapping System groups 🔍

For example, xTR I boots up and wants to find its other peers in its Mapping System group address 233.252.2.2. Group address 233.252.2.2 is configured, so xTR I knows which group to join for its Mapping System group 🎯 However, xTR I needs a Mapping System to register to, so the core seed-group is used and available to receive Map-Registers. The other xTRs J and K in the Mapping System group do the same, so when any of I, J, or K needs to register EIDs, they can now send their Map-Register messages to group address 233.252.2.2 📬 Examples of EIDs being registered are EID1 through EIDn shown above.

When Map-Registers are sent to group address 233.252.2.2, they are encapsulated by the LISP data plane by looking up EID 233.252.2.2 in the core seed-group Mapping System. For the map-cache entry to be populated for 233.252.2.2, the data plane MUST send a Map-Request so the RLOCs I, J, and K are cached for replication 🪄 To use the core seed-group Mapping System, the data plane MUST know of at least one of the RLOCs A, B, and/or C 🧠

5. Decent-Pull-Based Mapping System 🌈

5.1. Components of a Decent-Pulled Based LISP-Decent xTR

When an xTR is configured to be a LISP-Decent xTR (or PxTR [RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP network functions 💅

Unlike the Decent-Push-based Mapping System, the xTRs don't need to be organized by joining a multicast group 🙅‍♀️ In a Decent-Pull-based Mapping System, a hash function over an EID is used to figure out which xTR serves as the Map-Resolver and Map-Server. The DNS [RFC1034] [RFC1035] is used as a resource discovery mechanism 🔎

The RLOC addresses of the xTRs will be A and AAAA records for DNS names that map algorithmically from the hash of the EID. A SHA-256 hash function [RFC6234] is run over the following ASCII-formatted EID string:

[<iid>]<eid>/<ml>
[<iid>]<group>/<gml>-<source>/<sml>

In this section, wherever you see angle brackets, they get replaced with values in ASCII characters. For example, a unicast EID of 1.1.1.1 in instance-id 11 would be encoded as the string "[11]1.1.1.1/32" 🫧

<iid> is the instance-ID and <eid> is the EID of any EID-type defined in [RFC8060]. The Modulus Value <mv> is used to produce the Name Index <index> that builds the DNS lookup name 🧮

eid = "[<iid>]<eid>/<ml>"
index = hash.sha_256(eid) MOD mv

The Hash Mask is used to select which bits get used in the SHA-256 hash function. This is required to support longest match lookups in the Mapping System. The same Map-Server set needs to be selected when looking up a more-specific EID found in the Map-Request message as one that could match a less-specific EID-prefix registered and found in the Map-Register message 🌟 For example, if an EID-prefix [0]240.0.1.0/24 is registered to the Mapping System and EID [0]240.0.1.1/32 is looked up to match the registered prefix, a Hash Mask of 8 bytes can be used to AND both the /32 or /24 entries to produce the same hash string bits of "[0]240.0".

For (*,G) and (S,G) multicast entries in the Mapping System, the hash strings are:

sg-eid = "[<iid>]<group>/<gml>-<source>/<sml>"
index = hash.sha_256(sg-eid) MOD mv

starg-eid = "[<iid>]<group>/<gml>-0.0.0.0/0"
index = hash.sha_256(starg-eid) MOD mv

The Hash Mask MUST include the string "[<iid>]<group>" and not the string <source>. So when looking up [0](2.2.2.2, 233.252.1.1), which will match a (*, 233.252.1.1/32), the hash string produced with a Hash Mask of 12 bytes is "[0]233.252.1.1" 🎀

When the <index> is computed from a unicast or multicast EID, the DNS lookup name becomes:

<index>.map-server.example.com

When an xTR does a DNS lookup on the lookup name, it sends Map-Register messages to all A and AAAA records for EID registrations 📮 For Map-Request messages, xTRs MAY round robin EID lookup requests among the A and AAAA records 🎠

5.2. Configurable EID Prefix Lengths for Lookups

In implementations where EID allocations follow a predictable pattern, operators MAY configure ITRs to use specific prefix lengths for lookups when the EID falls within well-known allocation ranges 🗺️ This configuration lets ITRs compute the correct hash index even when data packets carry more-specific EIDs than the prefix lengths the ETRs used during registration.

For example, if an operator allocates EIDs in the range [0]240.11.0.0/16 and all ETRs register these EIDs with a /24 prefix length, ITRs receiving data packets for EIDs like [0]240.11.1.1/32 will still hash on the /24 prefix to locate the correct Map-Server 🎯 Without this configuration, the ITR would hash on the /32 and potentially query the wrong Map-Server 😬

ITRs SHOULD support configuration of EID prefix ranges and their associated lookup prefix lengths. When an ITR performs a Map-Request lookup, it SHOULD check whether the destination EID matches any configured range. If a match is found, the ITR MUST use the configured lookup prefix length instead of the EID's registered prefix length when computing the hash string. When multiple configured ranges match a given EID, the range with the longest (most-specific) configured prefix length MUST be selected 💜

The configuration consists of pairs of EID-prefix (the well-known EID allocation range in Classless Inter-Domain Routing (CIDR) notation, e.g., 240.11.0.0/16) and lookup-length (the prefix length to use for hash computation when EIDs fall within this range, 0-32 bytes for IPv4 and 0-128 bytes for IPv6) 📝

Implementation note: When computing the hash string for a lookup where the EID matches a configured range, the ITR MUST construct the hash string using the configured lookup-length, ensuring that the bits beyond the lookup-length are zero (i.e., the EID address is masked to the lookup-length before converting to the hash string format) 🫠

Here's an example configuration with multiple EID ranges:

EID Range Configuration:
  Range: [0]240.11.0.0/16  -> lookup-length: 24
  Range: [0]240.12.0.0/16  -> lookup-length: 30
  Range: [0]240.13.0.0/16  -> lookup-length: 25

Lookup Examples:
  EID [0]240.11.1.1/32     -> hash on [0]240.11.1.0/24
  EID [0]240.12.2.5/32     -> hash on [0]240.12.2.4/30
  EID [0]240.13.3.7/32     -> hash on [0]240.13.3.0/25
  EID [0]240.14.1.1/32     -> hash on [0]240.14.1.1/32
                               (no match, use full EID)

This approach is especially useful in deployments where the Mapping System uses a consistent ETR registration strategy (e.g., all ETRs in a region register with /24 prefixes), but the ITRs receive packets with more-specific destinations (/32 addresses). By configuring the expected registration prefix length for each allocation range, ITRs can reliably locate the correct Map-Servers without modifying LISP or introducing complex multi-level lookups 🦋✨

5.3. Deployment Example

Here's an example deployment of a Decent-Pull-based model 🍓 Let's say 4 Map-Server sets are provisioned for the Mapping System. That means 4 distinct DNS names are allocated and a Modulus Value 4 is used. Each DNS name is allocated Name Index 0 through 3:

0.map-server.lispers.net
1.map-server.lispers.net
2.map-server.lispers.net
3.map-server.lispers.net

The A records for each name can be assigned like this:

0.map-server.lispers.net:
    A <rloc1-att>
    A <rloc2-verizon>
1.map-server.lispers.net:
    A <rloc1-bt>
    A <rloc2-dt>
2.map-server.lispers.net:
    A <rloc1-cn>
    A <rloc2-kr>
3.map-server.lispers.net:
    A <rloc1-au>
    A <rloc2-nz>

When an xTR wants to register "[1000]fd::2222/128", it hashes the EID string to produce, for example, the hash value 0x67. Using the modulus value 4 (0x67 & 0x3) produces index 0x3, so the DNS name 3.map-server.lispers.net is used and a Map-Register is sent to <rloc1-au> and <rloc2-nz> 📨

Note that the Decent-Pull-based method can be used for a core seed-group to bootstrap a Decent-Push-based Mapping System where multicast groups are registered 🌸

5.4. Management Considerations

An implementation SHOULD do periodic DNS lookups to determine whether A records have changed for a DNS entry. This is a configuration parameter the network operator selects. This specification makes no recommendation for an interval value ⏰

When xTRs derive Map-Resolver and Map-Server names from the DNS, they need to use the same Modulus Value. Otherwise, some xTRs will look up EIDs in the wrong place from where they were registered 🙈

The Modulus Value can be configured or pushed to the LISP-Decent xTRs. A future version of this document will describe a push mechanism so all xTRs use a consistent modulus value 💖

6. Security Considerations ✨

Okay bestie, security time 🔐💀 For the full list of security mechanisms, plus pointers to the threat analysis docs, go check Section 9 of [RFC9301]. That's the place to look.

If you're running DNS for the Pull-based Mapping System, it's recommended to use DNSSEC [RFC9364] to add more security to the DNS lookup system 🛡️🫶

Replay attacks, spoofing, and trust relationships get the full deep dive in [RFC9301] and [RFC9303]. Read those and you'll be a security queen 👑😭

7. IANA Considerations 🦋

No IANA actions in this one. Nothing to register, nothing to update, we're chilling 🌸

8. References 📚

8.1. Normative References

8.2. Informative References

Acknowledgments 🫶

Big thank-yous to the LISP WG for reviewing and accepting this draft 💜

The authors also want to give a special shoutout to Roman Shaposhnik for the discussions that happened before the initial draft ✨

Eliot Lear and Victor Moreno get appreciated for proofreading the draft before it was published as an RFC 🎀

Authors' Addresses 🧚

Dino Farinacci lispers.net San Jose, CA United States of America Email: farinacci@gmail.com

Colin Cantrell Nexus Tempe, AZ United States of America Email: colin@nexus.io

📦 where this page comes from