RFC 9301
Locator/ID Separation Protocol (LISP) Control Plane
RFC 9301: Locator/ID Separation Protocol (LISP) Control Plane 🎀
okay bestie, this is RFC 9301 and it's giving main character energy 👑. It's a Standards Track document from the IETF, published in October 2022 with ISSN 2070-1721 ✨. The authors are D. Farinacci (lispers.net), F. Maino (Cisco Systems), V. Fuller (vaf.net Internet Consulting), and A. Cabellos, Ed. (Universitat Politecnica de Catalunya) 🦋. It obsoletes RFC 6830 and RFC 6833, so those older versions are out 💅. There's no Updates line in the header.
Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 9301 lispers.net
Obsoletes: 6830, 6833 F. Maino
Category: Standards Track Cisco Systems
ISSN: 2070-1721 V. Fuller
vaf.net Internet Consulting
A. Cabellos, Ed.
Universitat Politecnica de Catalunya
October 2022Abstract ✨
okay so the abstract is the tea ☕. This doc describes the control plane and Mapping Service for LISP. It's built from two kinds of LISP-speaking devices, the Map-Resolver and the Map-Server, and together they act as a simplified "front end" for one or more Endpoint IDs (EIDs) to Routing Locator mapping databases 🌸.
Because ITRs and ETRs talk to Map-Resolvers and Map-Servers, they don't depend on the nitty-gritty details of mapping database systems. That's what makes it so modular, with lots of different database designs able to plug in 🧚. These devices form the "edge" of the LISP control plane infrastructure, connecting the EID-addressable nodes of a LISP site, so the implementation and operational complexity of deploying LISP (the overall cost and effort) goes down 💜.
This document obsoletes RFCs 6830 and 6833 🍓.
Status of This Memo
This is an Internet Standards Track document 💖.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841 🎀.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9301 ✨.
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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License 📜.
Table of Contents
1. Introduction
1.1. Scope of Applicability
2. Requirements Notation
3. Definitions of Terms
4. Basic Overview
5. LISP IPv4 and IPv6 Control Plane Packet Formats
5.1. LISP Control Packet Type Allocations
5.2. Map-Request Message Format
5.3. EID-to-RLOC UDP Map-Request Message
5.4. Map-Reply Message Format
5.5. EID-to-RLOC UDP Map-Reply Message
5.6. Map-Register Message Format
5.7. Map-Notify and Map-Notify-Ack Message Formats
5.8. Encapsulated Control Message Format
6. Changing the Contents of EID-to-RLOC Mappings
6.1. Solicit-Map-Request (SMR)
7. Routing Locator Reachability
7.1. RLOC-Probing Algorithm
8. Interactions with Other LISP Components
8.1. ITR EID-to-RLOC Mapping Resolution
8.2. EID-Prefix Configuration and ETR Registration
8.3. Map-Server Processing
8.4. Map-Resolver Processing
8.4.1. Anycast Operation
9. Security Considerations
10. Privacy Considerations
11. Changes Related to RFCs 6830 and 6833
12. IANA Considerations
12.1. LISP UDP Port Numbers
12.2. LISP Packet Type Codes
12.3. LISP Map-Reply EID-Record Action Codes
12.4. LISP Address Type Codes
12.5. LISP Algorithm ID Numbers
12.6. LISP Bit Flags
13. References
13.1. Normative References
13.2. Informative References
Acknowledgments
Authors' Addresses1. Introduction ✨
okay so LISP is the Locator/ID Separation Protocol, and it's described in [RFC9300] (see also [RFC9299]) 🦋. It does dynamic tunneling by splitting the addresses IP usually uses into two separate namespaces. There are Endpoint IDs (EIDs), which are used within sites, and Routing Locators (RLOCs), which are used on the transit networks that make up the Internet infrastructure 🌐. To pull that off, LISP defines mechanisms for mapping from EIDs to RLOCs 💅.
LISP also assumes there's a database that stores those mappings and propagates them across Mapping System nodes. Several have been proposed, like the Content distribution Overlay Network Service for LISP-NERD (a Not-so-novel EID-to-RLOC Database) [RFC6837], LISP Alternative Logical Topology (LISP-ALT) [RFC6836], and LISP Delegated Database Tree (LISP-DDT) [RFC8111] 🌸.
The LISP Mapping Service defines two types of LISP-speaking devices 🎀. First up is the Map-Resolver, which accepts Map-Requests from an Ingress Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a mapping database. Then there's the Map-Server, which learns authoritative EID-to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes them in a database 🧚.
This LISP control plane and Mapping Service can be used by lots of different encapsulation-based or translation-based data planes 🌈. That includes (but isn't limited to) the ones defined in LISP [RFC9300], the LISP Generic Protocol Extension (LISP-GPE) [RFC9305], Virtual eXtensible Local Area Networks (VXLANs) [RFC7348], VXLAN-GPE [NVO3-VXLAN-GPE], GRE [RFC2890], the GPRS Tunneling Protocol (GTP) [GTP-3GPP], Identifier-Locator Addressing (ILA) [INTAREA-ILA], and Segment Routing (SRv6) [RFC8402] 💖.
Conceptually, LISP Map-Servers share some of the same basic configuration and maintenance properties as Domain Name System (DNS) servers [RFC1035]. Map-Resolvers are conceptually similar to DNS caching resolvers too 🍓. So this specification borrows the familiar terms "resolver" and "server" from the DNS specifications 🫶.
Note that this document doesn't assume any particular database mapping infrastructure to illustrate certain aspects of Map-Server and Map-Resolver operations. The Mapping Service interface can (and likely will) be used by ITRs and ETRs to access other mapping database systems as the LISP infrastructure evolves 🔥.
LISP is not intended to address problems of connectivity and scaling on behalf of arbitrary communicating parties. Relevant situations are described in Section 1.1 of [RFC9300] 🙈.
This document obsoletes [RFC6830] and [RFC6833] 💀.
1.1. Scope of Applicability
LISP was originally developed to address the Internet-wide route scaling problem [RFC4984] 🌸. There are a number of approaches of interest for that problem. But as LISP has been developed and refined, a large number of other uses for it have been found and are being implemented. So the design and development of LISP have changed to focus on these use cases 👑. The common property of these uses is a large set of cooperating entities that want to communicate over the public Internet or other large underlay IP infrastructures, while keeping the addressing and topology of those entities separate from the underlay and Internet topology, routing, and addressing 🦋.
When communicating over the public Internet, deployers MUST consider the following guidelines 🎀:
- LISP Security (LISP-SEC) MUST be implemented [RFC9303]. This means that the S-bit MUST be set in the Map-Reply (Section 5.4), Map-Register (Section 5.6), and Encapsulated Control Messages (ECMs) (Section 5.8). 🔐
- Implementations SHOULD use
'HMAC-SHA256-128+HKDF-SHA256'as the Algorithm ID (Section 12.5) in the Map-Register message (Section 5.6), and MUST NOT use'None'or'HMAC-SHA-1-96-None'as the Algorithm ID (Section 12.5) in the Map-Register message (Section 5.6). 💅
2. Requirements Notation 📜
okay the key words are the important part, so pay attention 👀. 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 ✨.
Part 1 of 14 is done, bestie 🫶. Part 2 is coming up next, so stay tuned 💖🦋
3. Definitions of Terms ✨
okay so let's get into the vocab, bestie 🧚 these terms are the building blocks for everything else, so pay attention 💅
- Map-Server: a network infrastructure component that learns EID-Prefix mapping entries from an ETR (through the registration mechanism described below) or from some other authoritative source, if one exists. It then publishes those EID-Prefixes in a mapping database 💖
- Map-Request: a control plane message that queries the Mapping System to resolve an EID. A LISP Map-Request can also be sent to an RLOC to test for reachability and to exchange security keys between an encapsulator and a decapsulator. This type of Map-Request is also known as an RLOC-Probe Request 🦋
- Map-Reply: a control plane message returned in response to a Map-Request sent to the Mapping System when resolving an EID. A LISP Map-Reply can also be returned by a decapsulator in response to a Map-Request sent by an encapsulator to test for reachability. This type of Map-Reply is known as an RLOC-Probe Reply 🌸
- Encapsulated Map-Request: a LISP Map-Request carried within an ECM. This Map-Request has an additional LISP header prepended. It's sent to UDP destination port 4342. The "outer" addresses are routable IP addresses, also known as RLOCs. An ITR uses it when sending to a Map-Resolver, and a Map-Server uses it when forwarding a Map-Request to an ETR 🎀
- Map-Resolver: a network infrastructure component that accepts LISP Encapsulated (ECM) Map-Requests, typically from an ITR, and determines whether or not the destination IP address is part of the EID namespace. If it is not, a Negative Map-Reply is returned. Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC mapping by consulting a mapping database system 🔥
- Negative Map-Reply: a LISP Map-Reply that contains an empty Locator-Set. It's returned in response to a Map-Request if the destination EID is not registered in the Mapping System, is policy-denied, or fails authentication 🙈
- Map-Register message: a LISP message sent by an ETR to a Map-Server to register its associated EID-Prefixes. In addition to the set of EID-Prefixes to register, the message includes one or more RLOCs to reach the ETR(s). The Map-Server uses these RLOCs when forwarding Map-Requests (reformatted as Encapsulated Map-Requests). An ETR MAY request that the Map-Server answer Map-Requests on its behalf by setting the "proxy Map-Reply" flag (P-bit) in the message 👑
- Map-Notify message: a LISP message sent by a Map-Server to an ETR to confirm that a Map-Register has been received and processed. An ETR requests that a Map-Notify be returned by setting the "want-map-notify" flag (M-bit) in the Map-Register message. Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both source and destination. Map-Servers also send Map-Notify messages to ITRs when there are RLOC-Set changes 🌈
For definitions of other terms, notably Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), and Re-encapsulating Tunnel Router (RTR), refer to the LISP data plane specification [RFC9300].
4. Basic Overview 🧚
okay so a Map-Server is a device that publishes EID-Prefixes in a LISP mapping database on behalf of a set of ETRs. When it receives a Map-Request (typically from an ITR), it consults the mapping database to find an ETR that can answer with the set of RLOCs for an EID-Prefix. To publish its EID-Prefixes, an ETR periodically sends Map-Register messages to the Map-Server. A Map-Register message contains a list of EID-Prefixes plus a set of RLOCs that can be used to reach the ETRs 💖
When LISP-ALT [RFC6836] is used as the mapping database, a Map-Server connects to the ALT network and acts as a "last-hop" ALT-Router. Intermediate ALT-Routers forward Map-Requests to the Map-Server that advertises a particular EID-Prefix, and the Map-Server forwards them to the owning ETR, which responds with Map-Reply messages. It's giving teamwork 🫶
When LISP-DDT [RFC8111] is used as the mapping database, a Map-Server sends the final Map-Referral messages from the Delegated Database Tree 🦋
A Map-Resolver receives Encapsulated Map-Requests from its client ITRs and uses a mapping database system to find the appropriate ETR to answer those requests. On a LISP-ALT network, a Map-Resolver acts as a "first-hop" ALT-Router. It has Generic Routing Encapsulation (GRE) tunnels configured to other ALT-Routers and uses BGP to learn paths to ETRs for different prefixes in the LISP-ALT database. The Map-Resolver uses this path information to forward Map-Requests over the ALT to the correct ETRs. On a LISP-DDT network [RFC8111], a Map-Resolver maintains a referral cache and acts as a "first-hop" DDT node. The Map-Resolver uses the referral information to forward Map-Requests 🌸
Note that while it is conceivable that a Map-Resolver could cache responses to improve performance, issues surrounding cache management would need to be resolved so that doing so would be reliable and practical. In this specification, Map-Resolvers will operate only in a non-caching mode, decapsulating and forwarding Encapsulated Map-Requests received from ITRs. Any specification of caching functionality is out of scope for this document 🙈
Note that a single device can implement the functions of both a Map-Server and a Map-Resolver, and in many cases, the functions will be co-located in that way. Also, there can be ALT-only nodes and DDT-only nodes, when LISP-ALT and LISP-DDT are used, respectively, connecting Map-Resolvers and Map-Servers together to make up the Mapping System ✨
5. LISP IPv4 and IPv6 Control Plane Packet Formats 💅
the following UDP packet formats are used by the LISP control plane, so here they are, bestie 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol = 17 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port | Dest Port |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LISP Message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: IPv4 UDP LISP Control Message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header=17| Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Routing Locator +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Routing Locator +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port | Dest Port |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LISP Message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: IPv6 UDP LISP Control Message
When a UDP Map-Request, Map-Register, or Map-Notify (when used as a notification message) is sent, the UDP source port is chosen by the sender and the destination UDP port number is set to 4342. When a UDP Map-Reply, Map-Notify (when used as an acknowledgment to a Map-Register), or Map-Notify-Ack is sent, the source UDP port number is set to 4342 and the destination UDP port number is copied from the source port of either the Map-Request or the invoking data packet. Implementations MUST be prepared to accept packets when either the source port or destination UDP port is set to 4342 due to NATs changing port number values 🥺
The 'UDP Length' field will reflect the length of the UDP header and the LISP Message payload. LISP is expected to be deployed by cooperating entities communicating over underlays. Deployers are expected to set the MTU according to the specific deployment guidelines to prevent fragmentation of either the inner packet or the outer encapsulated packet. For deployments not aware of the underlay restrictions on the path MTU, the message size MUST be limited to 576 bytes for IPv4 or 1280 bytes for IPv6 -- considering the entire IP packet -- as outlined in [RFC8085] 🌈
The UDP checksum is computed and set to non-zero for all messages sent to or from port 4342. It MUST be checked on receipt, and if the checksum fails, the control message MUST be dropped [RFC1071] 🔥
The format of control messages includes the UDP header so the checksum and length fields can be used to protect and delimit message boundaries 💜
5.1. LISP Control Packet Type Allocations ✨
okay so this section is where the LISP control message formats get defined 🎀 and it also gives IANA a summary of the LISP Type codes assigned by this document. for completeness the table includes the LISP Shared Extension Message that [RFC9304] assigned too 💅 here's the lineup:
+===================================+======+==================+
| Message | Code | Codepoint |
+===================================+======+==================+
| Reserved | 0 | b'0000' |
+-----------------------------------+------+------------------+
| LISP Map-Request | 1 | b'0001' |
+-----------------------------------+------+------------------+
| LISP Map-Reply | 2 | b'0010' |
+-----------------------------------+------+------------------+
| LISP Map-Register | 3 | b'0011' |
+-----------------------------------+------+------------------+
| LISP Map-Notify | 4 | b'0100' |
+-----------------------------------+------+------------------+
| LISP Map-Notify-Ack | 5 | b'0101' |
+-----------------------------------+------+------------------+
| LISP DDT Map-Referral | 6 | b'0110' |
+-----------------------------------+------+------------------+
| Unassigned | 7 | b'0111' |
+-----------------------------------+------+------------------+
| LISP Encapsulated Control Message | 8 | b'1000' |
+-----------------------------------+------+------------------+
| Unassigned | 9-14 | b'1001'- b'1110' |
+-----------------------------------+------+------------------+
| LISP Shared Extension Message | 15 | b'1111' |
+-----------------------------------+------+------------------+
Table 1protocol designers who are experimenting with new message formats are recommended to use the LISP Shared Extension Message Type described in [RFC9304] 🦋 that's the move if you're building something new!
all LISP control plane messages use Address Family Identifiers (AFIs) [AFN] or LISP Canonical Address Format (LCAF) entries [RFC8060] to encode either fixed-length or variable-length addresses 🌈 this covers the explicit fields in each control message and also the parts of EID-Records or RLOC-Records in commonly formatted messages. so if a LISP control plane message includes an unrecognized AFI, it MUST be dropped 🙈 and the event MUST be logged 📝 no exceptions, bestie!
the LISP control plane also describes how other data planes can encode messages to support soliciting Map-Requests and RLOC-Probing procedures ✨
5.2. Map-Request Message Format 💜
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI n | ITR-RLOC Address n ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Reserved | EID mask-len | EID-Prefix-AFI |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | EID-Prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+here's the field tour, the good stuff 🍓
Type: Type is 1, which means Map-Request 🎀
A: this is the authoritative bit 👑 it gets set to 1 when an ITR wants the destination site to send back the Map-Reply, instead of the mapping database system doing it. otherwise it's 0.
M: this is the map-data-present bit 🌸 when it's set, it tells you a Map-Reply Record segment is included in the Map-Request.
P: this is the probe-bit, and it's giving important 🔥 a Map-Request with the probe-bit set MUST be treated as a Locator reachability probe. the receiver MUST respond with a Map-Reply that has the probe-bit set (so it knows it's a Locator reachability probe reply), and the nonce gets copied over from the Map-Request. check out "RLOC-Probing Algorithm" (Section 7.1) for the full tea ☕ also, this RLOC-Probe Map-Request MUST NOT be sent to the Mapping System 🙅♀️ and if a Map-Resolver or Map-Server gets a Map-Request with the probe-bit set, it MUST drop the message 💀
S: this is the Solicit-Map-Request (SMR) bit 🦋 the deets are in "Solicit-Map-Request (SMR)" (Section 6.1).
p: this is the Proxy Ingress Tunnel Router (PITR) bit ✨ it gets set to 1 when a PITR sends a Map-Request. how you use it depends on the deployment 🧚
s: this is the SMR-invoked bit 💜 it's set to 1 when an xTR sends a Map-Request in response to a received SMR-based Map-Request.
R: this is the reserved and unassigned bit 🌈 it MUST be set to 0 on transmit and MUST be ignored on receipt. hands off, bestie 🫶
Rsvd: this field MUST be set to 0 on transmit and MUST be ignored on receipt 🌸
L: this is the local-xtr bit 🎀 an xTR in a LISP site uses it to tell the other xTRs in the same site that it's part of the RLOC-Set for that site. the L-bit gets set to 1 when the RLOC is the sender's IP address.
D: this is the dont-map-reply bit 💅 it's used in the SMR procedure described in Section 6.1. when an xTR sends an SMR message, it doesn't need a Map-Reply back, so when this bit is set, the receiver of the Map-Request does NOT return a Map-Reply. (fine, it's not NOT, it's just a normal bit lol, moving on 🙈)
IRC: this is the 5-bit ITR-RLOC Count 🔢 it tells you how many extra (ITR-RLOC-AFI, ITR-RLOC Address) fields are in the message. at least one (ITR-RLOC-AFI, ITR-RLOC Address) pair MUST be encoded 🫶 you can have multiple ITR-RLOC Address fields so the Map-Replier can pick which destination address to use for the Map-Reply, which is so iconic 👑 the IRC value goes from 0 to 31. a value of 0 means there's 1 ITR-RLOC address encoded, a value of 1 means there are 2, and so on, all the way up to 31, which encodes 32 ITR-RLOC addresses total 🌈
Record Count: this is how many records are in this Map-Request message 📊 a record is the chunk of the packet labeled 'Rec' above, and it shows up as many times as the Record Count says. for this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record 🍓
Nonce: this is an 8-octet random value made by the sender of the Map-Request 🎲 the nonce gets returned in the Map-Reply, and it's used as an index so you can match the Map-Reply to the right Map-Request when it arrives 💖 the nonce MUST be generated by a properly seeded pseudo-random source, for example see [RFC4086] 🔐 do not skip the seeding, periodt!
Source-EID-AFI: this is the address family of the 'Source EID Address' field 🧚
Source EID Address: this is the EID of the source host that originated the packet that triggered the Map-Request ✨ when Map-Requests are used to refresh a Map-Cache entry or for RLOC-Probing, an AFI value of 0 is used, and this field has zero length 🦋
ITR-RLOC-AFI: this is the address family of the 'ITR-RLOC Address' field that comes right after it 🌸
ITR-RLOC Address: this gives the ETR the option to pick the destination address from any address family for the Map-Reply message 💜 this address MUST be a routable RLOC address of the sender of the Map-Request message 🌍
EID mask-len: this is the mask length for the EID-Prefix 🎀
EID-Prefix-AFI: this is the address family of the EID-Prefix, according to [AFN] and [RFC8060] 👑
EID-Prefix: this prefix address length is 4 octets for IPv4 (when the EID-Prefix-AFI is 1) and 16 octets for IPv6 (when it's 2) 🌈 for other AFIs [AFN], the address length varies, and for the LCAF AFI, the format is defined in [RFC8060] 📦 when an ITR sends a Map-Request because it got a data packet for a destination with no mapping entry, the EID-Prefix is set to that data packet's destination IP address, and the 'EID mask-len' field is set to 32 for IPv4 or 128 for IPv6 💅 and when an xTR wants to ask a site about the status of a mapping it already has cached, the EID-Prefix in the Map-Request has the same mask length as the EID-Prefix the site returned when it sent its Map-Reply 🫶
Map-Reply Record: when the M-bit is set, this field is the size of a single "Record" in the Map-Reply format 🍓 this Map-Reply record has the EID-to-RLOC mapping entry for the source EID, which lets the ETR that receives this Map-Request cache the data if it wants to 💖 but here's the important part, bestie: this mapping has NOT been validated by the Mapping System 🚨
5.3. EID-to-RLOC UDP Map-Request Message ✨
okay bestie, so a Map-Request is sent by an ITR 🦋 whenever it needs a mapping for an EID, wants to check if an RLOC is still reachable, or wants to refresh a mapping before its Time to Live (TTL) runs out 💅. For the first case, the destination IP address is the data packet's destination address (the destination EID) that just failed its mapping cache lookup 🙈. For the other two cases, the destination IP address is one of the RLOC addresses from the Locator-Set of the Map-Cache entry 💜. The source address is an IPv4 or IPv6 RLOC address, depending on whether the Map-Request uses an IPv4 or IPv6 header 🌈.
In every case, the UDP source port is a 16-bit value picked by the ITR/PITR 🎀, and the UDP destination port is the well-known port 4342 ✨. A successful Map-Reply is one whose nonce matches an outstanding Map-Request nonce, and it updates the cached set of RLOCs tied to that EID-Prefix range 🫶.
One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields MUST be filled in by the ITR 🍓. The number of fields, minus 1, MUST be placed in the 'IRC' field 🧚. The ITR MAY include every locally configured Locator in this list, or it can just give one Routing Locator Address from each address family it supports 🌸. If the ITR accidentally provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-Request 💀.
Map-Requests can also be LISP encapsulated using UDP destination port 4342, with the LISP Type value set to "Encapsulated Control Message", when they're sent from an ITR to a Map-Resolver 🦋. Map-Requests get encapsulated the same way when they go from a Map-Server to an ETR 💖. You can find the details on Encapsulated Map-Requests and Map-Resolvers in Section 5.8 ✨.
Map-Requests MUST be rate limited to 1 per second per EID-Prefix ⏱️. After 10 retransmits without getting the matching Map-Reply, the sender MUST wait 30 seconds 😭. Literally a timeout moment 🙈.
An ITR that's also configured with mapping database information (so it's also an ETR) MAY optionally include those mappings in a Map-Request 🎀. When an ETR that's set up to accept and verify this "piggybacked" mapping data gets such a Map-Request and doesn't have that mapping in its Map-Cache, it MUST originate a "verifying Map-Request" through the mapping database, so the piggybacked mapping data gets validated 👑 iykyk, that's the whole double-check energy 💅🌈
5.4. Map-Reply Message Format 💌
okay bestie, this is the Map-Reply 💅 the message that comes back with the answer after a Map-Request. here's the whole layout:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 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 |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field is doing ✨
Type: this is2, which means Map-Reply 🎀P: this is the probe-bit 🦋. It says the Map-Reply is answering a Locator reachability probe Map-Request. TheNoncefield has to contain a copy of the nonce from the original Map-Request. See "RLOC-Probing Algorithm" (Section 7.1) for more details. When the probe-bit is set to 1 in a Map-Reply message, the A-bit in each EID-Record in the message MUST be set to 1; otherwise, it MUST be silently discarded. 😭E: this bit says the ETR sending this Map-Reply is advertising that the site is enabled for the Echo-Nonce Locator reachability algorithm. See Section 10.1 ("Echo-Nonce Algorithm") of [RFC9300] for more details. 🌸S: this is the Security bit 🔐. When it's set to 1, the authentication information below gets tacked onto the end of the Map-Reply. Details can be found in [RFC9303].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved: this is an unassigned field. It MUST be set to 0 on transmit and MUST be ignored on receipt. 🙈Record Count: this is how many records are in the reply. A record is the chunk labeled 'Record' above, and you get as many as the Record Count says. The reply count can be bigger than the requested count, like when more-specific prefixes are present. 🍓Nonce: a 64-bit value copied from the Map-Request and echoed back in this 'Nonce' field 🧚Record TTL: this is how many minutes the recipient can store the mapping 🕰️. If the TTL is 0, the entry MUST be removed from the cache immediately. If the value is 0xffffffff, the recipient can decide locally how long to keep the mapping.Locator Count: how many Locator entries are in this Record (the stuff labeled 'Loc' above). It can be 0, which just means there are no Locators for the EID-Prefix. 💀EID mask-len: the mask length for the EID-Prefix 📏ACT: this 3-bit field describes Negative Map-Reply actions ✨. Any other message type sets these bits to 0 and ignores them on receipt. They only get used whenLocator Countis 0, and they're only encoded in Map-Reply messages. They tell an ITR or PITR why an empty Locator-Set came back from the Mapping System and how to store the Map-Cache entry. See Section 12.3 for additional information.(0)No-Action: the Map-Cache is kept alive, and no packet encapsulation happens.(1)Natively-Forward: the packet isn't encapsulated or dropped, it's natively forwarded.(2)Send-Map-Request: the Map-Cache entry gets created and flagged, so any packet matching it triggers sending a Map-Request.(3)Drop/No-Reason: a packet matching this Map-Cache entry gets dropped. An ICMP Destination Unreachable message SHOULD be sent. 🚫(4)Drop/Policy-Denied: a packet matching this Map-Cache entry gets dropped. The reason is that a Map-Request for the target EID was policy-denied by either an xTR or the Mapping System. 🙅(5)Drop/Auth-Failure: a packet matching this Map-Cache entry gets dropped. The reason is that a Map-Request for the target EID failed an authentication verification check by either an xTR or the Mapping System. 🔒
A: the Authoritative bit 👑. It MAY only be set to 1 by an ETR. A Map-Server generating Map-Replies as a proxy MUST NOT set the A-bit to 1. This bit tells the requesting ITRs whether the Map-Reply came from a LISP node managed at the site that owns the EID-Prefix.Map-Version Number: when this 12-bit value in an EID-Record of a Map-Reply is non-zero, see [RFC9302] for details. 🔢EID-Prefix-AFI: the address family of the EID-Prefix, according to [AFN] and [RFC8060] 🌈EID-Prefix: this is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family.Priority: every RLOC gets a unicast Priority, and lower values are preferable 🥇. When several RLOCs share the same Priority, they may be used in a load-split fashion. A value of 255 means the RLOC MUST NOT be used for unicast forwarding. ❌Weight: when priorities are the same, the Weight shows how to balance unicast traffic between them ⚖️. It's a relative weight of the total unicast packets that match the mapping entry. For example, say there are 4 Locators in a Locator-Set with Weights of 30, 20, 20, and 10. The first Locator gets 37.5% of the traffic, the second and third each get 25%, and the fourth gets 12.5%. If all Weights in a Locator-Set are equal, the receiver of the Map-Reply decides how to load-split. See Section 12 ("Routing Locator Hashing") of [RFC9300] for a suggested hash algorithm to spread the load across Locators with the same Priority and equal Weight values. 🍰M Priority: every RLOC also gets a multicast Priority. An ETR in a receiver multicast site uses it to pick an ITR in a source multicast site when building multicast distribution trees 🌳. A value of 255 means the RLOC MUST NOT be used for joining a multicast distribution tree. For more details, see [RFC6831].M Weight: when multicast priorities are the same, this shows how to balance building multicast distribution trees across multiple ITRs. It's a relative weight (similar to the unicast Weights) of the total number of trees built to the source site identified by the EID-Prefix. If all Weights in a Locator-Set are equal, the receiver of the Map-Reply decides how to spread multicast state across ITRs. For more details, see [RFC6831]. 🌿Unused Flags: these get set to 0 when sending and ignored on receipt 🫧L: when this bit is set, the Locator is flagged as a local Locator to the ETR sending the Map-Reply 🏠. When a Map-Server is doing proxy Map-Replying for a LISP site, the L-bit is set to 0 for all Locators in this Locator-Set.p: when this bit is set, an ETR tells the RLOC-Probing ITR that the Routing Locator Address with this bit is the one being RLOC-Probed. It may be different from the source address of the Map-Reply 🎯. An ITR that RLOC-Probes a particular Locator MUST use this Locator for retrieving the data structure used to store the fact that the Locator is reachable. Only one Locator in the same Locator-Set gets the p-bit. If an implementation sets more than one p-bit by mistake, the receiver of the Map-Reply MUST select the first set p-bit Locator. The p-bit MUST NOT be set for Locator-Set records sent in Map-Request and Map-Register messages. 🙌R: this gets set when the sender of a Map-Reply has a route to the Locator in the Locator data record. The receiver might find it useful to know the Locator is up, even if it isn't necessarily reachable from the receiver's point of view. 🛣️Locator: this is an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) assigned to an ETR and used by an ITR as a destination RLOC address in the outer header of a LISP encapsulated packet 📬. The destination RLOC address of a LISP encapsulated packet MAY be an anycast address, and a source RLOC can be an anycast address too. The source or destination RLOC MUST NOT be the broadcast address (255.255.255.255 or any subnet broadcast address known to the router) and MUST NOT be a link-local multicast address. The source RLOC MUST NOT be a multicast address. The destination RLOC SHOULD be a multicast address if it's being mapped from a multicast destination EID. 📡
Map-Replies MUST be rate limited. It is RECOMMENDED that a Map-Reply for the same destination RLOC be sent to no more than one packet every 3 seconds. ⏱️ don't spam, bestie 🫶
The Record format, as defined here, is used in both Map-Reply and Map-Register messages, and that includes all the field definitions. 💜
5.5. EID-to-RLOC UDP Map-Reply Message ✨
okay bestie, so a Map-Reply hands back an EID-Prefix whose mask length is less than or equal to the EID that got asked about 💅 The EID being asked about is either the destination field of the IP header in a Data-Probe, or the EID in a record of a Map-Request 🦋 The RLOCs in the Map-Reply are routable IP addresses of all the ETRs for the LISP site 🌸 Each RLOC tells you its status reachability, but it does NOT tell you path reachability from the requester's point of view 🙈 so separate testing of path reachability is required. Check out "RLOC-Probing Algorithm" (Section 7.1) for the deets 💖
Note that a Map-Reply MAY contain a different EID-Prefix granularity (prefix + mask length) than the Map-Request that set it off 🧚 This can happen if a Map-Request was for a prefix that an earlier Map-Reply already gave back 👑 In that case, the requester updates its cache with the new prefix info and granularity. Like, say a requester has two cached EID-Prefixes that are both covered by a Map-Reply with one less-specific prefix. It replaces those entries with the less-specific EID-Prefix, no drama 🌈 The reverse can happen too: one less-specific prefix gets replaced by multiple more-specific prefixes, and it's not because the less-specific one got removed. The more-specific ones just get added, and during a lookup they override the less-specific one ✨
When an EID moves out of a LISP site [EID-MOBILITY], the database Mapping System might end up with overlapping EID-Prefixes 😭 Same thing if a LISP site has multiple sets of ETRs that support different EID-Prefix mask lengths. So when overlapping EID-Prefixes exist, a Map-Request with an EID that best matches any EID-Prefix MUST be returned in a single Map-Reply message 🔥 Say an ETR has database mapping entries for these EID-Prefixes:
2001:db8::/32
2001:db8:1::/48
2001:db8:1:1::/64
2001:db8:1:2::/64A Map-Request for EID 2001:db8:1:1::1 gets a Map-Reply with a record count of 1, and the mapping record EID-Prefix is 2001:db8:1:1::/64 🎀
A Map-Request for EID 2001:db8:1:5::5 gets a Map-Reply with a record count of 3, with mapping records for the EID-Prefixes 2001:db8:1::/48, 2001:db8:1:1::/64, and 2001:db8:1:2::/64. It's filling out the /48 with the more-specific prefixes that exist in the Mapping System 🍓
Not every overlapping EID-Prefix has to come back, only the more-specific entries for the matching EID-Prefix of the requesting EID. Look at the second example: 2001:db8::/32 was NOT returned for requesting EID 2001:db8:1:5::5, and that's totally fine 🙈
When more than one EID-Prefix is returned, all of them SHOULD use the same TTL value so they can all time out at the same time 🫶 When a more-specific EID-Prefix shows up later, its TTL value in the Map-Reply record can be stored even if less-specific entries already exist 💜 When a less-specific EID-Prefix shows up later, its Map-Cache expiration time SHOULD be set to the minimum expiration time of any more-specific EID-Prefix in the Map-Cache. This keeps the integrity of the EID-Prefix set fully intact, so no more-specific entries get removed from the Map-Cache while the less-specific ones stay behind 💅
For scalability, aggregating EID addresses into EID-Prefixes is expected to let one Map-Reply satisfy a mapping for all the EID addresses in that prefix range 🌸 That means fewer Map-Request messages, which is iconic 👑
Map-Reply records can have an empty Locator-Set 💀 A Negative Map-Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies carry special actions from the Map-Reply sender to the ITR or PITR that asked for the Map-Reply ✨ There are two main uses. The first is a Map-Resolver telling an ITR or PITR whether a destination is in a LISP site or a non-LISP site. The second is source quenching Map-Requests that get sent for non-allocated EIDs 🧚
For each Map-Reply record, the list of Locators in a Locator-Set MUST be sorted in order of ascending IP address. An IPv4 Routing Locator Address counts as numerically "less than" an IPv6 Routing Locator Address 🔥
When sending a Map-Reply message, the destination address is copied from one of the ITR-RLOC fields in the Map-Request 🦋 The ETR can pick a Routing Locator Address from any of the address families it supports 🌈 For Data-Probes, the destination address of the Map-Reply is copied from the source address of the Data-Probe message that triggered the reply 🎀 The source address of the Map-Reply is one of those chosen local IP addresses. This lets Unicast Reverse Path Forwarding (uRPF) checks succeed in the upstream service provider, which is so smart 🧠✨ Last bit: the destination port of a Map-Reply message is copied from the source port of the Map-Request or Data-Probe, and the source port of the Map-Reply message is set to the well-known UDP port 4342 💖
5.6. Map-Register Message Format 🎀
okay bestie, this is the Map-Register section and it's giving main character energy 💅✨ This part is all about the encoding format for the Map-Register message. It gets sent over UDP with a destination UDP port of 4342 and a randomly selected UDP source port number 🦋
The fields below show up in more than one control message. They're defined for the Map-Register, Map-Notify, and Map-Notify-Ack message types, so you'll see them again 🫶
Here's the Map-Register layout, bestie 👀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P|S|I| Reserved |E|T|a|R|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Algorithm ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 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 |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Packet field descriptions: here's the tea on each field 🍓
Type: 3 (Map-Register) 💖P: this is the proxy Map-Reply bit 🌸 When it's set to 1, the ETR sending the Map-Register is asking the Map-Server to proxy a Map-Reply. The Map-Server will send non-authoritative Map-Replies on behalf of the ETR.S: this is the security-capable bit 🔐 When it's set, the procedures from [RFC9303] are supported.I: this is the ID-present bit ✨ It gets set to 1 to say that a 128-bitxTR-IDfield and a 64-bitSite-IDfield are sitting at the end of the Map-Register message. If an xTR is configured with an xTR-ID and Site-ID, it MUST set the I-bit to 1 and include its xTR-ID and Site-ID in the Map-Register messages it generates. The combo of Site-ID plus xTR-ID uniquely identifies an xTR in a LISP domain and helps track its last seen nonce 🦋Reserved: this unassigned field MUST be set to 0 on transmit and MUST be ignored on receipt 🫧E: this is the Map-Register EID-notify bit 👀 A First-Hop Router uses it when it discovers a dynamic EID. This EID-notify-based Map-Register is sent by the First-Hop Router to a same site xTR, which then propagates the Map-Register to the Mapping System. The site xTR keeps state so it can later Map-Notify the First-Hop Router after the EID has moved away. See [EID-MOBILITY] for a detailed use case 🧚T: this is the use TTL for timeout bit ⏰ When it's set to 1, the xTR wants the Map-Server to time out registrations based on the value in theRecord TTLfield of this message. Otherwise, the default timeout described in Section 8.2 is used.a: this is the merge-request bit 🤝 When it's set to 1, the xTR is asking to merge RLOC-Records from different xTRs that are registering the same EID-Record. See Signal-Free Multicast [RFC8378] for one use-case example.R: this reserved and unassigned bit MUST be set to 0 on transmit and MUST be ignored on receipt 🌈M: this is the want-map-notify bit 💌 When it's set to 1, an ETR is requesting a Map-Notify message be returned in response to sending a Map-Register message. The Map-Notify message sent by a Map-Server is used to acknowledge receipt of a Map-Register message.Record Count: the number of records in this Map-Register message 📚 A record is the portion of the packet labeled 'Record' above, and it shows up as many times as the Record Count says.Nonce: this 8-octetNoncefield gets incremented each time a Map-Register message is sent 🔢 When a Map-Register acknowledgment is requested, Map-Servers return the nonce in Map-Notify messages. Since the entire Map-Register message is authenticated, theNoncefield protects against Map-Register replay attacks 🛡️ An ETR that registers to the Mapping System SHOULD store the last nonce sent in persistent storage, so when it restarts, it can keep using an incrementing nonce. If the ETR cannot support saving the nonce, then when it restarts, it MUST use a new authentication key to register to the Mapping System. A Map-Server MUST track and save in persistent storage the last nonce received for each ETR xTR-ID and key pair. If a Map-Register arrives with a nonce value that is not greater than the saved nonce, it MUST drop the Map-Register message and SHOULD log the fact that a replay attack could have occurred 🚨Key ID: a key-id value that identifies a pre-shared secret between an ETR and a Map-Server 🔑 Per-message keys are derived from the pre-shared secret to authenticate the origin and protect the integrity of the Map-Register. The Key ID lets you rotate between multiple pre-shared secrets in a nondisruptive way. The pre-shared secret MUST be unique per each LISP Site-ID.Algorithm ID: this field identifies the Key Derivation Function (KDF) and Message Authentication Code (MAC) algorithms used to derive the key and to compute the Authentication Data of a Map-Register 🧮 This 8-bit field identifies the KDF and MAC algorithm pair. See Section 12.5 for codepoint assignments.Authentication Data Length: the length in octets of theAuthentication Datafield that follows this field 📏 The length of that field depends on the MAC algorithm used. The length field lets a device that doesn't know the MAC algorithm still parse the packet correctly.Authentication Data: this is the output of the MAC algorithm, placed in this field after the MAC computation 🔐 The MAC output is computed as follows:- The KDF algorithm is identified by the
Algorithm IDfield according to the table in Section 12.5. Implementations of this specification MUST implement HMAC-SHA-256-128 [RFC4868] and SHOULD implement HMAC-SHA-256-128+HKDF-SHA256 [RFC5869] 💅 - The MAC algorithm is identified by the
Algorithm IDfield according to the table in Section 12.5. 🫶 - The pre-shared secret used to derive the per-message key is represented by
PSK[Key ID], that is, the pre-shared secret identified by the Key ID. 🗝️ - The derived per-message key is computed as:
per-msg-key=KDF(nonce+PSK[Key ID],s). Here the nonce is the value in theNoncefield of the Map-Register, "+" means concatenation, and "s" (the salt) is a string that matches the message type being authenticated. For Map-Register messages it's"Map-Register Authentication". For Map-Notify and Map-Notify-Ack messages it's"Map-Notify Authentication"and"Map-Notify-Ack Authentication", respectively. For those Algorithm IDs defined in Section 12.5 that specify a'none'KDF, the per-message key is computed as:per-msg-key = PSK[Key ID]. This means the same key gets used across multiple protocol messages 🌀 - The MAC output is computed using the MAC algorithm and the per-msg-key over the entire Map-Register payload (from and including the LISP message type field through the end of the last RLOC-Record), with the authenticated data field preset to 0. 💯
- The KDF algorithm is identified by the
The rest of the Map-Register is defined in the EID-Record description in Section 5.4. When the I-bit is set, these fields get tacked onto the end of the Map-Register message 🎀
xTR-ID: 'xTR-ID' is a 128-bit field at the end of the Map-Register message, starting after the final Record in the message. It's used to uniquely identify an xTR. The same xTR-ID value MUST NOT be used in two different xTRs in the scope of the Site-ID. 🆔Site-ID: 'Site-ID' is a 64-bit field at the end of the Map-Register message, following the xTR-ID. It's used to uniquely identify which site the xTR that sent the message belongs to. This document does not specify a strict meaning for the 'Site-ID' field. Informally, it shows that a group of xTRs have some relationship, whether administrative, topological, or otherwise 🌸
5.7. Map-Notify and Map-Notify-Ack Message Formats ✨
okay bestie, this section is where the Map-Notify and Map-Notify-Ack messages get their encoding 🎀 they travel inside a UDP packet where both the source and destination UDP ports are 4342 🦋
The Map-Notify and Map-Notify-Ack message formats look 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=4/5| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Algorithm ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 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 |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Packet field descriptions:
Type: 4/5 (Map-Notify/Map-Notify-Ack) 💜
The Map-Notify message has the same contents as a Map-Register message 🫶 check out "Map-Register Message Format" (Section 5.6) for the field descriptions, and "Map-Reply Message Format" (Section 5.4) for the EID-Record and RLOC-Record descriptions.
The fields of the Map-Notify get copied over from the matching Map-Register, which is how it confirms the Map-Register was processed correctly 💅 In the Map-Notify, the 'Authentication Data' field gets recomputed using the matching per-message key, following the procedure from the previous section. The Map-Notify message can also be sent unsolicited, but that's out of scope for this doc 🙈 if you want the details, see [LISP-PUBSUB].
After sending a Map-Register, if a Map-Notify doesn't show up after 1 second, the transmitter MUST retransmit the original Map-Register with an exponential backoff (base of 2, so the next backoff timeout interval is doubled) ⏰ the maximum backoff is 1 minute. Map-Notify messages only get sent when a Map-Register with the M-bit set comes in, and Map-Notify messages are not retransmitted. The only exception is unsolicited Map-Notify messages, which we'll get to next 🦋
A Map-Server sends an unsolicited Map-Notify message (one that isn't being used as an acknowledgment to a Map-Register message) only in line with Section 3.1 ("Congestion Control Guidelines") of [RFC8085] and Section 3.3 ("Reliability Guidelines") of [RFC8085] 🌸 A Map-Notify keeps getting retransmitted until the Map-Server receives a Map-Notify-Ack carrying the same nonce that was used in the Map-Notify. An implementation SHOULD retransmit up to 3 times at 3-second retransmission intervals. After that, the retransmission interval gets exponentially backed off (base of 2, so the next backoff timeout interval is doubled) for another 3 retransmission attempts 🔥 Map-Notify-Ack messages only get sent in response to an unsolicited Map-Notify, and Map-Notify-Ack messages are not retransmitted.
The Map-Notify-Ack message has the same contents as a Map-Notify message ✨ it's used to acknowledge receipt of an unsolicited Map-Notify. Once the Authentication Data is validated, it lets the sender stop retransmitting any Map-Notify with the same nonce and (validated) Authentication Data 🫶 The fields of the Map-Notify-Ack are copied from the matching Map-Notify to show it was processed correctly, and the 'Authentication Data' field gets recomputed with the matching per-message key, following the procedure from the previous section.
Whenever a Map-Register, Map-Notify, or Map-Notify-Ack comes in, the receiver verifies the Authentication Data. If the Authentication Data fails to validate, the message gets dropped without any further processing 💀 no second chances, bestie.
5.8. Encapsulated Control Message Format
okay so an Encapsulated Control Message (ECM) is the thing used to wrap up control packets 🎁 they get sent between xTRs and the mapping database system, or inside the mapping database system itself 🧚
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header |
OH | (uses RLOC addresses) |
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4342 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LISP |Type=8 |S|D|R|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header |
IH | (uses RLOC or EID addresses) |
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = yyyy |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCM | LISP Control Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Packet header descriptions:
OH: This is the outer IPv4 or IPv6 header, which uses RLOC addresses in the source and destination header address fields.
UDP: This is the outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non-zero. 🔥
LISP: Type 8 is defined to be a "LISP Encapsulated Control Message", and what follows is either an IPv4 or IPv6 header, as encoded by the first 4 bits after the 'Reserved' field, or the 'Authentication Data' field [RFC9303] if the S-bit (see below) is set. 🦋
Type: 8 (Encapsulated Control Message (ECM))
S: This is the Security bit. When set to 1, the field following the 'Reserved' field will have the following Authentication Data format and follow the procedures from [RFC9303].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+D: This is the DDT-bit. When set to 1, the sender is requesting a Map-Referral message to be returned. Details regarding this procedure are described in [RFC8111]. 🧭
R: This reserved and unassigned bit MUST be set to 0 on transmit and MUST be ignored on receipt. 🌈
IH: This is the inner IPv4 or IPv6 header, which can use either RLOC or EID addresses in the header address fields. When a Map-Request is encapsulated in this packet format, the destination address in this header is an EID.
UDP: This is the inner UDP header, and its port assignments depend on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is selected by the ITR/PITR and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum field MUST be non-zero. 🚫
LCM: The format is one of the control message formats described in Section 5. Map-Request messages are allowed to be control plane (ECM) encapsulated. When Map-Requests are sent for RLOC-Probing purposes (i.e., the probe-bit is set), they MUST NOT be sent inside Encapsulated Control Messages. PIM Join/Prune messages [RFC6831] are also allowed to be control plane (ECM) encapsulated. 💜
6. Changing the Contents of EID-to-RLOC Mappings 🌈
In the LISP architecture, ITRs/PITRs use a local Map-Cache to store EID-to-RLOC mappings for forwarding. When an ETR updates a mapping, a mechanism is needed to inform the ITRs/PITRs that are using those mappings. 🫶
The LISP data plane defines several mechanisms to update mappings [RFC9300]. This document specifies the Solicit-Map-Request (SMR), a control plane push-based mechanism 🦋 An additional control plane mechanism based on the Publish/Subscribe paradigm is specified in [LISP-PUBSUB].
6.1. Solicit-Map-Request (SMR) 💌
okay so soliciting a Map-Request is the selective way for ETRs at the site where mappings change to control how fast they get hit with requests for Map-Reply messages 💅 SMRs also tell remote ITRs to refresh the mappings they already have cached, which is so iconic ✨
ETRs are not required to keep track of remote ITRs that have cached their mappings, so they don't know which ITRs need an update 😭 bestie, that's the tea. So an ETR will solicit Map-Requests to those sites it has been sending LISP encapsulated data packets to over the last minute. And when an ETR is also acting as an ITR, it will send an SMR to an ITR it has recently sent encapsulated data to 🦋
an SMR message is literally just a bit set in a Map-Request message 🎀 An ITR or PITR will send a Map-Request (SMR-invoked Map-Request) when it receives an SMR message. The SMR itself goes through the data plane, but the SMR-invoked Map-Request MUST be sent through the Mapping System (not directly) 🫶
both the SMR sender and the SMR responder MUST rate limit these messages, no exceptions, periodt 💀 It is RECOMMENDED that the SMR sender rate limit a Map-Request for the same destination RLOC to no more than one packet every 3 seconds. It is RECOMMENDED that the SMR responder rate limit a Map-Request for the same EID-Prefix to no more than once every 3 seconds 🌸
now the main-character moment 👑 when an ITR gets an SMR for an EID it does not have a cached mapping for, it SHOULD NOT send an SMR-invoked Map-Request. This can happen when an ETR sends SMR messages to every Locator in the Locator-Set it has stored in its Map-Cache, but the remote ITRs that get the SMR aren't sending packets to the site. So there's no point updating ITRs until they actually need to send. When they do, they'll send Map-Requests to get a Map-Cache entry anyway 🧚
7. Routing Locator Reachability 🦋
this section is where we figure out whether an RLOC is still alive 🔥 This document defines several control plane mechanisms for determining RLOC reachability. Also, please note that additional data plane reachability mechanisms are defined in [RFC9300] 💖
- An ITR may receive an ICMP Network Unreachable or Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. Note that trusting ICMP messages may not be desirable, but neither is ignoring them completely 🙈 Implementations are encouraged to follow current best practices in treating these conditions [OPSEC-ICMP-FILTER].
- When an ITR participates in the routing protocol that operates in the underlay routing system, it can determine that an RLOC is down when no Routing Information Base (RIB) entry exists that matches the RLOC IP address 🍓
- An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [RFC6832] and LISP-encapsulated data is sent to a non-LISP-capable site 😭
- An ITR may receive a Map-Reply from an ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up, since the ETR was able to send the Map-Reply to the ITR. Please note that in some scenarios the RLOC -- from the outer header -- can be a spoofable field 🫣
- An ITR/ETR pair can use the 'RLOC-Probing' mechanism described below ✨
When ITRs receive ICMP Network Unreachable or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators that are described in Locator lists of Map-Replies. However, using this approach is unreliable because many network operators turn off generation of ICMP Destination Unreachable messages 💀
If an ITR does receive an ICMP Network Unreachable or Host Unreachable message, it MAY originate its own ICMP Destination Unreachable message destined for the host that originated the data packet the ITR encapsulated 🌈
this assumption does create a dependency, bestie: Locator unreachability is detected by the receipt of ICMP Host Unreachable messages. When a Locator has been determined to be unreachable, it is not used for active traffic. This is the same as if it were listed in a Map-Reply with Priority 255 👑
The ITR can test the reachability of the unreachable Locator by sending periodic Map-Requests. Both Map-Requests and Map-Replies MUST be rate limited; see Sections 5.3 and 5.4 for information about rate limiting. Locator reachability testing is NEVER done with data packets, since that increases the risk of packet loss for end-to-end sessions 🚫🫶
7.1. RLOC-Probing Algorithm 🧚
RLOC-Probing is a method that an ITR or PITR can use to figure out the reachability status of one or more Locators it has cached in a Map-Cache entry. The probe-bit of the Map-Request and Map-Reply messages is used for RLOC-Probing 🦋
RLOC-Probing happens in the control plane on a timer basis. An ITR or PITR will originate a Map-Request destined to a Routing Locator Address from one of its own Routing Locator Addresses. A Map-Request used as an RLOC-Probe is NOT encapsulated and NOT sent to a Map-Server or to the mapping database system, which is what you'd do when requesting mapping data. The EID-Record encoded in the Map-Request is the EID-Prefix of the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a mapping data record for its own database mapping information that contains the local EID-Prefixes and RLOCs for its site. RLOC-Probes are sent periodically using a jittered timer interval 🌸
When an ETR receives a Map-Request message with the probe-bit set, it returns a Map-Reply with the probe-bit set. The source address of the Map-Reply is set to the IP address of the outgoing interface the Map-Reply destination address routes to. The Map-Reply SHOULD contain mapping data for the EID-Prefix contained in the Map-Request. This gives the ITR or PITR that sent the RLOC-Probe a chance to get mapping updates if the ETR's database mapping entries changed 🎀
RLOC-Probing has advantages and disadvantages, obviously 💅 The main benefit is that it can handle many failure scenarios. It lets the ITR tell when the path to a specific Locator is reachable or has become unreachable, which makes it a robust way to switch over to another Locator from the cached Locator set 👑 RLOC-Probing can also give rough Round-Trip Time (RTT) estimates between a pair of Locators. That's useful for network management and for picking low-delay paths ⭐ The major disadvantage is the number of control messages required and the amount of bandwidth used to get those benefits, especially if the failure detection time has to be very small 😭
8. Interactions with Other LISP Components 🌸
8.1. ITR EID-to-RLOC Mapping Resolution 🫶
An ITR is configured with one or more Map-Resolver addresses. These addresses are "Locators" (or RLOCs) and they MUST be routable on the underlying core network. They MUST NOT need to be resolved through LISP EID-to-RLOC mapping, because that would introduce a circular dependency 🙈 When using a Map-Resolver, an ITR does not need to connect to any other database Mapping System. Lowkey so clean 🧚
An ITR sends an Encapsulated Map-Request to a configured Map-Resolver when it needs an EID-to-RLOC mapping that is not found in its local Map-Cache. Using the Map-Resolver greatly reduces both the complexity of the ITR implementation and the costs associated with its operation 💖
In response to an Encapsulated Map-Request, the ITR can expect one of the following:
- An immediate Negative Map-Reply (with action code "Natively-Forward" and a 15-minute TTL) from the Map-Resolver if the Map-Resolver can determine that the requested EID does not exist. The ITR saves the EID-Prefix returned in the Map-Reply in its cache, marks it as non-LISP-capable, and knows not to attempt LISP encapsulation for destinations matching it 🍓
- A Negative Map-Reply (with action code "Natively-Forward") from a Map-Server that is authoritative (within the LISP deployment (Section 1.1)) for an EID-Prefix that matches the requested EID, but that does not have an actively registered, more-specific EID-Prefix. In this case, the requested EID is said to match a "hole" in the authoritative EID-Prefix. If the requested EID matches a more-specific EID-Prefix that has been delegated by the Map-Server but for which no ETRs are currently registered, a 1-minute TTL is returned. If the requested EID matches a non-delegated part of the authoritative EID-Prefix, then it is not a LISP EID and a 15-minute TTL is returned. See Section 8.2 for a discussion of aggregate EID-Prefixes and details regarding Map-Server EID-Prefix matching 🦋
- A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping, or possibly from a Map-Server answering on behalf of the ETR. See Section 8.4 for more details on Map-Resolver message processing ✨
Note that an ITR may be configured to both use a Map-Resolver and participate in a LISP-ALT logical network. In that situation, the ITR SHOULD send Map-Requests through the ALT network for any EID-Prefix learned via ALT BGP. This kind of configuration is expected to be very rare, since there's little benefit to using a Map-Resolver if an ITR is already using LISP-ALT 🌈 There would be, for example, no need for such an ITR to send a Map-Request to a possibly non-existent EID (and rely on Negative Map-Replies) if it can consult the ALT database to verify that an EID-Prefix is present before sending that Map-Request. Just check the ALT database first, bestie 💅💜
8.2. EID-Prefix Configuration and ETR Registration 💌
okay so an ETR publishes its EID-Prefixes on a Map-Server by sending LISP Map-Register messages 📬. A Map-Register message includes Authentication Data, so before any of that happens, the ETR and Map-Server MUST be set up with a pre-shared secret that they use to derive the Map-Register authentication keys 🔐. A Map-Server's configuration SHOULD also include a list of the EID-Prefixes each ETR is authoritative for 📝. When a Map-Register shows up from an ETR, the Map-Server only accepts EID-Prefixes that are configured for that ETR. Bestie, this check is non-negotiable 💀. If the Map-Server skips it, the Mapping System is wide open to trivial EID-Prefix hijacking attacks.
In addition to the EID-Prefixes defined for each ETR that may register, a Map-Server is usually also configured with one or more aggregate prefixes that cover the part of the EID numbering space assigned to it 🗺️. When LISP-ALT is the database in use, aggregate EID-Prefixes are implemented as discard routes and advertised into ALT BGP 🛣️. Because of that, a Map-Server's database can get Map-Requests for EID-Prefixes that match an aggregate but don't match any registered prefix. Section 8.3 explains how that gets handled 👀.
Map-Register messages are sent periodically from an ETR to a Map-Server, with a suggested interval of one minute between messages ⏰. A Map-Server SHOULD time out and remove an ETR's registration if it hasn't received a valid Map-Register message within the past three minutes 🫥. Now, when an ETR first contacts a Map-Server after a restart or after its EID-to-RLOC database mappings change, it MAY start off sending Map-Register messages more often, up to one every 20 seconds 🏃♀️. This "quick registration" period lasts no longer than five minutes ✨.
An ETR MAY ask a Map-Server to explicitly acknowledge that it received and processed a Map-Register message by setting the want-map-notify (M-bit) flag 🔔. A Map-Server that gets a Map-Register with this flag set will respond with a Map-Notify message 💬. The typical move here is for an ETR to set this flag on the Map-Register messages it sends during the initial "quick registration" with a Map-Server, and then only set it now and then during steady-state maintenance of that association 🧠. Also, heads up: the Map-Notify message goes to UDP destination port 4342, not to the source port from the original Map-Register message 📍.
Here's the thing 🤔: a one-minute minimum registration interval during ETR-Map-Server maintenance puts a lower bound on how quickly and how often a mapping database entry can be updated. That might affect what kinds of mobility the Mapping System can support directly, so shorter registration intervals or other mechanisms might be needed for faster mobility in some cases 🏎️. If you want to see one way faster mobility can be done for individual devices, check out [LISP-MN] 🦋.
An ETR MAY also ask, by setting the "proxy Map-Reply" flag (P-bit) in the Map-Register message, that a Map-Server answer Map-Requests itself instead of forwarding them to the ETR 🎀. See Section 7.1 for the details on how the Map-Server sets certain flags when it sends a Map-Reply on an ETR's behalf. Those flags include whether the message is authoritative and how returned Locators SHOULD be treated 🧩. When an ETR requests proxy reply service, it SHOULD include all RLOCs for all ETRs for the EID-Prefix being registered, along with the routable flag ("R-bit") setting for each RLOC 💅. The Map-Server then puts all of this info into the Map-Replies it sends on the ETR's behalf 📨. This is different from a non-proxy registration. A non-proxy registration only needs to give one or more RLOCs for the Map-Server to use when forwarding Map-Requests. The registration info isn't used in Map-Replies in that case, so it being incomplete isn't incorrect 🙌.
An ETR that uses a Map-Server to publish its EID-to-RLOC mappings doesn't have to take part any further in the mapping database protocol(s) 🫶. With LISP-ALT, for example, that means the ETR doesn't need to implement GRE or BGP, which makes its configuration way simpler and cheaper to run 🤑.
Note that using a Map-Server doesn't stop an ETR from also connecting to the mapping database (so it could connect to the LISP-ALT network too) 🌐. Honestly though, doing that doesn't seem super useful, since the whole point of using a Map-Server is to skip the complexity of the mapping database protocols 🙈.
8.3. Map-Server Processing
Once a Map-Server has EID-Prefixes registered by its client ETRs, it can accept and process Map-Requests for them 🥳.
When a Map-Request comes in, the Map-Server first checks whether the destination EID matches a configured EID-Prefix 🔍. If there's no match, the Map-Server returns a Negative Map-Reply with action code Natively-Forward and a 15-minute TTL ⏳. This can happen if a Map-Request is received for a configured aggregate EID-Prefix that has no more-specific EID-Prefix under it. It basically means there's a non-LISP "hole" in the aggregate EID-Prefix 🕳️.
Next, the Map-Server checks whether any ETRs have registered the matching EID-Prefix 🕵️♀️. If none are found, the Map-Server returns a Negative Map-Reply with action code Natively-Forward and a 1-minute TTL 🍓.
If the EID-Prefix is registered or not registered with the Mapping System, and the Map-Server has a policy saying the requester should drop packets for the matching EID-Prefix, then a Drop/Policy-Denied action is returned 🚫. If the EID-Prefix is registered or not registered and there's an authentication failure, then a Drop/Auth-Failure action is returned 🔒. If either of these actions comes from a temporary state in policy or authentication, then a Send-Map-Request action with a 1-minute TTL MAY be returned so the requester can retry the Map-Request 🔁.
If any of the registered ETRs for the EID-Prefix have asked for proxy reply service, then the Map-Server answers the request itself instead of forwarding it 🦸♀️. It returns a Map-Reply with the EID-Prefix, RLOCs, and other info it learned through the registration process 💖.
If none of the ETRs asked for proxy reply service, then the Map-Server re-encapsulates and forwards the resulting Encapsulated Map-Request to one of the registered ETRs 📦. It doesn't otherwise change the Map-Request, so any Map-Reply the ETR sends goes back to the RLOC in the Map-Request, not to the Map-Server 🎯. Unless it's also acting as a Map-Resolver, a Map-Server should never receive Map-Replies. Any such messages SHOULD be discarded without a response 🗑️, and maybe a diagnostic message gets logged if the rate of Map-Replies looks like malicious traffic 🚨.
8.4. Map-Resolver Processing
When a Map-Resolver gets an Encapsulated Map-Request, it decapsulates the enclosed message and then searches its local database of mapping entries for the requested EID 🧐. That database is either statically configured or learned from associated ETRs if the Map-Resolver is also a Map-Server offering proxy reply service 🧠. If it finds a matching entry, it returns a LISP Map-Reply with the known mapping 🎉.
If the Map-Resolver doesn't have the mapping entry, and it can tell that the EID isn't in the mapping database (for example, with LISP-ALT, the Map-Resolver has an ALT forwarding table that covers the full EID space), it immediately returns a Negative Map-Reply with action code Natively-Forward and a 15-minute TTL ⚡. To keep the number of negative cache entries an ITR needs small, the Map-Resolver SHOULD return the least-specific prefix that both matches the original query and doesn't match any EID-Prefix known to exist in the LISP-capable infrastructure 🧃.
If the Map-Resolver doesn't have enough info to know whether the EID exists, it needs to forward the Map-Request to another device that has more info about the requested EID 🙋♀️. To do that, it forwards the unencapsulated Map-Request, with the original ITR RLOC as the source, to the mapping database system 📤. With LISP-ALT, the Map-Resolver is connected to the ALT network and sends the Map-Request to the next ALT hop it learned from its ALT BGP neighbors 🛤️. The Map-Resolver doesn't send any response to the ITR. Since the source RLOC is the ITR's, the ETR or Map-Server that gets the Map-Request over the ALT and responds will reply directly to the ITR 🫢.
8.4.1. Anycast Operation
A Map-Resolver can be set up to use "anycast", where the same address is assigned to multiple Map-Resolvers and propagated through IGP routing 🌍. This helps each ITR use a topologically close Map-Resolver 📍.
ETRs MAY have anycast RLOC addresses that get registered as part of their RLOC-Set with the Mapping System 💫. However, registrations MUST use their unique RLOC addresses, distinct authentication keys, or different xTR-IDs to identify security associations with the Map-Servers 🔑. No shared identities, bestie, every association needs its own unique ID 💕.
9. Security Considerations 🔐✨
okay bestie, security time, so pay attention 💅 A LISP threat analysis lives in [RFC7835]. Here we're spotlighting the security stuff that matters when LISP is deployed in environments like the ones in Section 1.1, where these assumptions hold:
- The Mapping System is secure and trusted, and for the purpose of these security considerations, the Mapping System is considered as one trusted element. 🫶
- The ETRs have a preconfigured trust relationship with the Mapping System, including some form of shared secret. The Mapping System is aware of which EIDs an ETR can advertise. How those keys and mappings are established is out of scope for this document. 🗝️
- LISP-SEC [RFC9303] MUST be implemented. Network operators should carefully weigh how the LISP-SEC threat model applies to their particular use case or deployment. If they decide to ignore a particular recommendation, they should make sure the risk associated with the corresponding threats is well understood. 🧐
The Map-Request/Map-Reply message exchange can be exploited by an attacker to mount DoS and/or amplification attacks. Attackers can send Map-Requests at high rates to overload LISP nodes and increase the state maintained by such nodes or consume CPU cycles. 😭 Such threats can be mitigated by systematically applying filters and rate limiters. 🚧
The Map-Request/Map-Reply message exchange can also be exploited to inject forged mappings directly into the ITR EID-to-RLOC Map-Cache. This can lead to traffic being redirected to the attacker; see further details in [RFC7835]. 💀 In addition, valid ETRs in the system can perform overclaiming attacks. In this case, attackers can claim to own an EID-Prefix that is larger than the prefix owned by the ETR. Such attacks can be addressed by using LISP-SEC [RFC9303]. The LISP-SEC protocol defines a mechanism for providing origin authentication, integrity protection, and prevention of 'man-in-the-middle' and 'prefix overclaiming' attacks on the Map-Request/Map-Reply exchange. 🛡️ In addition, and while beyond the scope of securing an individual Map-Server or Map-Resolver, it should be noted that LISP-SEC can be complemented by additional security mechanisms defined by the Mapping System infrastructure. For instance, BGP-based LISP-ALT [RFC6836] can take advantage of standards work on adding security to BGP, while LISP-DDT [RFC8111] defines its own additional security mechanisms. 🌈
To publish an authoritative EID-to-RLOC mapping with a Map-Server using the Map-Register message, an ETR includes Authentication Data that is a MAC of the entire message using a key derived from the pre-shared secret. An implementation SHOULD support HMAC-SHA256-128+HKDF-SHA256 [RFC5869]. The Map-Register message includes protection against replay attacks by a man in the middle. However, there is a potential attack where a compromised ETR could overclaim the prefix it owns and successfully register it on its corresponding Map-Server. To mitigate this, as noted in Section 8.2, a Map-Server MUST verify that all EID-Prefixes registered by an ETR match the configuration stored on the Map-Server. 👑
Deployments concerned about manipulations of Map-Request and Map-Reply messages and malicious ETR EID-Prefix overclaiming MUST drop LISP control plane messages that do not contain LISP-SEC material (S-bit, EID-AD, OTK-AD, PKT-AD). See Section 3 of [RFC9303] for definitions of "EID-AD", "OTK-AD", and "PKT-AD". 🚫
Mechanisms to encrypt, support privacy, and prevent eavesdropping and packet tampering for messages exchanged between xTRs, between xTRs and the Mapping System, and between nodes that make up the Mapping System SHOULD be deployed. Examples of this are DTLS [RFC9147] or "lisp-crypto" [RFC8061]. 🔒🎀
10. Privacy Considerations 🦋
As noted by [RFC6973], privacy is a complex issue that greatly depends on the specific protocol use case and deployment. As noted in Section 1.1 of [RFC9300], LISP focuses on use cases where entities communicate over the public Internet while keeping separate addressing and topology. Here, we detail the privacy threats introduced by the LISP control plane; the analysis is based on the guidelines detailed in [RFC6973]. 🫧
LISP can use long-lived identifiers (EIDs) that survive mobility events. Such identifiers bind to the RLOCs of the nodes. The RLOCs represent the topological location with respect to the specific LISP deployments. In addition, EID-to-RLOC mappings are typically considered public information within the LISP deployment when control plane messages are not encrypted and can be eavesdropped while Map-Request messages are sent to the corresponding Map-Resolvers or Map-Register messages to Map-Servers. 👀
In this context, attackers can correlate the EID with the RLOC and track the corresponding user topological location and/or mobility. This can be achieved by off-path attackers, if they are authenticated, by querying the Mapping System. Deployments concerned about this threat can use access control lists or stronger authentication mechanisms [ECDSA-AUTH] in the Mapping System to make sure that only authorized users can access this information (data minimization). Use of ephemeral EIDs [EID-ANONYMITY] to achieve anonymity is another mechanism to lessen persistency and identity tracking. 🕵️♀️💜
11. Changes Related to RFCs 6830 and 6833 🌸
For implementation considerations, the following major changes have been made to this document since [RFC6830] and [RFC6833] were published:
- The 16-bit 'Key ID' field of the Map-Register and Map-Notify messages as defined in [RFC6830] has been split into an 8-bit 'Key ID' field and an 8-bit 'Algorithm ID' field. Note that this change also applies to the Map-Notify-Ack message defined by this document. See Sections 5.6 and 5.7.
- This document defines a Map-Notify-Ack message to provide reliability for Map-Notify messages. Any receiver of a Map-Notify message must respond with a Map-Notify-Ack message. Map-Servers who are senders of Map-Notify messages must queue the Map-Notify contents until they receive a Map-Notify-Ack with the nonce used in the Map-Notify message. Note that implementations for Map-Notify-Ack support already exist and predate this document. 🔁
- This document has incorporated the codepoint for the Map-Referral message from the LISP-DDT specification [RFC8111] to indicate that a Map-Server must send the final Map-Referral message when it participates in the LISP-DDT Mapping System procedures.
- Bits L and D have been added to the Map-Request message. See Section 5.3 for details.
- Bits S, I, E, T, a, R, and M have been added to the Map-Register message. See Section 5.6 for details.
- The nonce and the Authentication Data in the Map-Register message each behave differently; see Section 5.6 for details.
- This document adds two new action values that are in an EID-Record that appears in Map-Reply, Map-Register, Map-Notify, and Map-Notify-Ack messages. These new action values are Drop/Policy-Denied and Drop/Auth-Failure. See Section 5.4 for details. ✨
12. IANA Considerations 📚💅
This section provides guidance to IANA regarding registration of values related to this LISP control plane specification, in accordance with BCP 26 [RFC8126].
- LISP IANA registry allocations should not be made for purposes unrelated to LISP routing or transport protocols.
- The following policies are used here with the meanings defined in BCP 26 [RFC8126]: "Specification Required", "IETF Review", "Experimental Use", and "First Come First Served".
There are three namespaces (listed in the sub-sections below) in LISP that have been registered (see [RFC9299].
12.1. LISP UDP Port Numbers 🔌
IANA allocated UDP port number 4342 for the LISP control plane. IANA has updated the description for UDP port 4342 to reflect the following:
+==============+=============+===========+==============+===========+
| Service Name | Port | Transport | Description | Reference |
| | Number | Protocol | | |
+==============+=============+===========+==============+===========+
| lisp-control | 4342 | udp | LISP Control | RFC 9301 |
| | | | Packets | |
+--------------+-------------+-----------+--------------+-----------+
Table 212.2. LISP Packet Type Codes 🧩
IANA is now authoritative for LISP Packet Type definitions, so they have replaced the registry references to [RFC6830] with references to this document.
Based on deployment experience related to [RFC6830], the Map-Notify-Ack message (message type 5) is defined in this document. IANA has registered it in the "LISP Packet Types" registry.
+=====================+======+===========+
| Message | Code | Reference |
+=====================+======+===========+
| LISP Map-Notify-Ack | 5 | RFC 9301 |
+---------------------+------+-----------+
Table 312.3. LISP Map-Reply EID-Record Action Codes 🎯
New ACT values can be allocated through IETF Review or IESG Approval. Four values have already been allocated by [RFC6830]. IANA has replaced the reference pointing to [RFC6830] to point to this document. This specification changes the Action name of value 3 from "Drop" to "Drop/No-Reason". It also adds the following new ACT values.
+=======+===============+=============================+===========+
| Value | Action | Description | Reference |
+=======+===============+=============================+===========+
| 4 | Drop/Policy- | A packet matching this Map- | RFC 9301 |
| | Denied | Cache entry is dropped | |
| | | because the target EID is | |
| | | policy-denied by the xTR or | |
| | | the Mapping System. | |
+-------+---------------+-----------------------------+-----------+
| 5 | Drop/Auth- | A packet matching this Map- | RFC 9301 |
| | Failure | Cache entry is dropped | |
| | | because the Map-Request for | |
| | | the target EID fails an | |
| | | authentication check by the | |
| | | xTR or the Mapping System. | |
+-------+---------------+-----------------------------+-----------+
Table 4: LISP Map-Reply Action ValuesIn addition, LISP has a number of flag fields and reserved fields, such as the flags of the LISP header fields [RFC9300]. New bits for flags in these fields can be implemented after IETF Review or IESG Approval, but these need not be managed by IANA. 🌈
12.4. LISP Address Type Codes ✨
okay so the LISP Canonical Address Format (LCAF) [RFC8060] has an 8-bit Type field 💅 that defines LISP-specific encodings for AFI value 16387. LCAF encodings are used for specific use cases where different address types for EID-Records and RLOC-Records are required 🌸.
The "LISP Canonical Address Format (LCAF) Types" registry is the one for LCAF types 🦋. That registry uses the Specification Required policy [RFC8126]. The initial values and more info live in [RFC8060] 📖.
So basically, there's no longer any need for the "LISP Address Type Codes" registry that [RFC6830] asked for 🙈. Per this document, that registry has been closed 🔒.
12.5. LISP Algorithm ID Numbers 🔥
In [RFC6830], someone submitted a request for a "LISP Key ID Numbers" registry 📝. Per this document, IANA renamed it to "LISP Algorithm ID Numbers" and listed this document as the registry reference 🫶.
These are the Algorithm ID values defined by this spec, for use in any packet type that has an 'Algorithm ID' field 🌈:
+=============================+========+===========+===========+
| Name | Number | MAC | KDF |
+=============================+========+===========+===========+
| None | 0 | None | None |
+-----------------------------+--------+-----------+-----------+
| HMAC-SHA-1-96-None | 1 | [RFC2404] | None |
+-----------------------------+--------+-----------+-----------+
| HMAC-SHA-256-128-None | 2 | [RFC4868] | None |
+-----------------------------+--------+-----------+-----------+
| HMAC-SHA256-128+HKDF-SHA256 | 3 | [RFC4868] | [RFC4868] |
+-----------------------------+--------+-----------+-----------+
Table 5Number values run from 0 to 255 🔢. Values are handed out on a First Come First Served basis 🎀.
12.6. LISP Bit Flags 🦋
This document asks IANA to make a registry for allocating bits in several headers of the LISP control plane 🧚. We're talking Map-Request messages, Map-Reply messages, Map-Register messages, and Encapsulated Control Messages 💜. Bit allocations are also requested for EID-Records and RLOC-Records 🍓. The registry should be called "LISP Control Plane Header Bits" ✨. Each message and EID-Record needs its own subregistry 💖. The name of each subregistry is listed below, along with its format and the bits this document defines 🌸. Any extra bit allocations need a specification, following the policies in [RFC8126] 💅.
Subregistry: Map-Request Header Bits (Section 5.2):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+===========+===============+==============+========================+
| Spec Name | IANA Name | Bit Position | Description |
+===========+===============+==============+========================+
| A | Map-Request-A | 4 | Authoritative Bit |
+-----------+---------------+--------------+------------------------+
| M | Map-Request-M | 5 | Map Data Present Bit |
+-----------+---------------+--------------+------------------------+
| P | Map-Request-P | 6 | RLOC-Probe Request |
| | | | Bit |
+-----------+---------------+--------------+------------------------+
| S | Map-Request-S | 7 | Solicit Map-Request |
| | | | (SMR) Bit |
+-----------+---------------+--------------+------------------------+
| p | Map-Request-p | 8 | Proxy-ITR Bit |
+-----------+---------------+--------------+------------------------+
| s | Map-Request-s | 9 | Solicit Map-Request |
| | | | Invoked Bit |
+-----------+---------------+--------------+------------------------+
| L | Map-Request-L | 17 | Local xTR Bit |
+-----------+---------------+--------------+------------------------+
| D | Map-Request-D | 18 | Don't Map-Reply Bit |
+-----------+---------------+--------------+------------------------+
Table 6: LISP Map-Request Header BitsSubregistry: Map-Reply Header Bits (Section 5.4):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+===========+=============+==============+========================+
| Spec Name | IANA Name | Bit Position | Description |
+===========+=============+==============+========================+
| P | Map-Reply-P | 4 | RLOC-Probe Bit |
+-----------+-------------+--------------+------------------------+
| E | Map-Reply-E | 5 | Echo-Nonce Capable Bit |
+-----------+-------------+--------------+------------------------+
| S | Map-Reply-S | 6 | Security Bit |
+-----------+-------------+--------------+------------------------+
Table 7: LISP Map-Reply Header BitsSubregistry: Map-Register Header Bits (Section 5.6):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P|S|I| Reserved |E|T|a|R|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+===========+================+==============+======================+
| Spec Name | IANA Name | Bit Position | Description |
+===========+================+==============+======================+
| P | Map-Register-P | 4 | Proxy Map-Reply Bit |
+-----------+----------------+--------------+----------------------+
| S | Map-Register-S | 5 | LISP-SEC Capable Bit |
+-----------+----------------+--------------+----------------------+
| I | Map-Register-I | 6 | xTR-ID Present Bit |
+-----------+----------------+--------------+----------------------+
Table 8: LISP Map-Register Header BitsSubregistry: Encapsulated Control Message (ECM) Header Bits (Section 5.8):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=8 |S|D|E|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+===========+===========+==============+============================+
| Spec Name | IANA Name | Bit Position | Description |
+===========+===========+==============+============================+
| S | ECM-S | 4 | Security Bit |
+-----------+-----------+--------------+----------------------------+
| D | ECM-D | 5 | LISP-DDT Bit |
+-----------+-----------+--------------+----------------------------+
| E | ECM-E | 6 | Forward to ETR Bit |
+-----------+-----------+--------------+----------------------------+
| M | ECM-M | 7 | Destined to Map- |
| | | | Server Bit |
+-----------+-----------+--------------+----------------------------+
Table 9: LISP Encapsulated Control Message (ECM) Header BitsSubregistry: EID-Record Header Bits (Section 5.4):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Count | EID mask-len | ACT |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+===========+==============+==============+===================+
| Spec Name | IANA Name | Bit Position | Description |
+===========+==============+==============+===================+
| A | EID-Record-A | 19 | Authoritative Bit |
+-----------+--------------+--------------+-------------------+
Table 10: LISP EID-Record Header BitsSubregistry: RLOC-Record Header Bits (Section 5.4):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused Flags |L|p|R| Loc-AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+===========+===============+==============+======================+
| Spec Name | IANA Name | Bit Position | Description |
+===========+===============+==============+======================+
| L | RLOC-Record-L | 13 | Local RLOC Bit |
+-----------+---------------+--------------+----------------------+
| p | RLOC-Record-p | 14 | RLOC-Probe Reply Bit |
+-----------+---------------+--------------+----------------------+
| R | RLOC-Record-R | 15 | RLOC Reachable Bit |
+-----------+---------------+--------------+----------------------+
Table 11: LISP RLOC-Record Header Bits13. References ✨
13.1. Normative References 📚✨
okay bestie, these are the docs the spec leans on so hard that you can't implement it without them 💅 I'm keeping every single one, DOIs and links included 🫶
- [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>. - [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 1998,
<https://www.rfc-editor.org/info/rfc2404>. - [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. 🎲 - [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>. - [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. 🔑 - [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013,
<https://www.rfc-editor.org/info/rfc6833>. - [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017,
<https://www.rfc-editor.org/info/rfc8085>. - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. 🗂️ - [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>. 👑 - [RFC9302] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 9302, DOI 10.17487/RFC9302, October 2022,
<https://www.rfc-editor.org/info/rfc9302>. - [RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, "Locator/ID Separation Protocol Security (LISP-SEC)", RFC 9303, DOI 10.17487/RFC9303, October 2022,
<https://www.rfc-editor.org/info/rfc9303>. 🛡️ - [RFC9304] Boucadair, M. and C. Jacquenet, "Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations", RFC 9304, DOI 10.17487/RFC9304, October 2022,
<https://www.rfc-editor.org/info/rfc9304>.
13.2. Informative References 🌸
these ones are the extra reading 🤓 not required to build the thing, but SO worth bookmarking, no cap 🦋
- [AFN] IANA, "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers/>. - [ECDSA-AUTH] Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA Authentication and Authorization", Work in Progress, Internet-Draft, draft-ietf-lisp-ecdsa-auth-09, 11 September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-ecdsa-auth-09>. - [EID-ANONYMITY] Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP EID Anonymity", Work in Progress, Internet-Draft, draft-ietf-lisp-eid-anonymity-13, 11 September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-anonymity-13>. 🙈 - [EID-MOBILITY] Portoles, M., Ashtaputre, V., Maino, F., Moreno, V., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", Work in Progress, Internet-Draft, draft-ietf-lisp-eid-mobility-10, 10 July 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-mobility-10>. - [GTP-3GPP] 3GPP, "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)", TS.29.281, June 2022,
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1699>. 📡 - [INTAREA-ILA] Herbert, T. and P. Lapukhov, "Identifier-locator addressing for IPv6", Work in Progress, Internet-Draft, draft-herbert-intarea-ila-01, 5 March 2018,
<https://datatracker.ietf.org/doc/html/draft-herbert-intarea-ila-01>. 🧚 - [LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", Work in Progress, Internet-Draft, draft-ietf-lisp-mn-12, 24 July 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-12>. 📱 - [LISP-PUBSUB] Rodriguez-Natal, A., Ermagan, V., Cabellos-Aparicio, A., Barkai, S., and M. Boucadair, "Publish/Subscribe Functionality for LISP", Work in Progress, Internet-Draft, draft-ietf-lisp-pubsub-09, 28 June 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-09>. - [NVO3-VXLAN-GPE] Maino, F., Ed., Kreeger, L., Ed., and U. Elzur, Ed., "Generic Protocol Extension for VXLAN (VXLAN-GPE)", Work in Progress, Internet-Draft, draft-ietf-nvo3-vxlan-gpe-12, 22 September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-12>. - [OPSEC-ICMP-FILTER] Gont, F., Gont, G., and C. Pignataro, "Recommendations for filtering ICMP messages", Work in Progress, Internet-Draft, draft-ietf-opsec-icmp-filtering-04, 3 July 2013,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsec-icmp-filtering-04>. 🚧 - [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987,
<https://www.rfc-editor.org/info/rfc1035>. - [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the Internet checksum", RFC 1071, DOI 10.17487/RFC1071, September 1988,
<https://www.rfc-editor.org/info/rfc1071>. ➕ - [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000,
<https://www.rfc-editor.org/info/rfc2890>. - [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007,
<https://www.rfc-editor.org/info/rfc4984>. 🗺️ - [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>. 💖 - [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013,
<https://www.rfc-editor.org/info/rfc6831>. - [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>. - [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013,
<https://www.rfc-editor.org/info/rfc6836>. - [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database", RFC 6837, DOI 10.17487/RFC6837, January 2013,
<https://www.rfc-editor.org/info/rfc6837>. - [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. 🔒 - [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. - [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>. 😱 - [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017,
<https://www.rfc-editor.org/info/rfc8060>. - [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017,
<https://www.rfc-editor.org/info/rfc8061>. 🫣 - [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, May 2017,
<https://www.rfc-editor.org/info/rfc8111>. 🌳 - [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID Separation Protocol (LISP) Multicast", RFC 8378, DOI 10.17487/RFC8378, May 2018,
<https://www.rfc-editor.org/info/rfc8378>. - [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018,
<https://www.rfc-editor.org/info/rfc8402>. 🛤️ - [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>. - [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>. 🏛️ - [RFC9305] Maino, F., Ed., Lemon, J., Agarwal, P., Lewis, D., and M. Smith, "Locator/ID Separation Protocol (LISP) Generic Protocol Extension", RFC 9305, DOI 10.17487/RFC9305, October 2022,
<https://www.rfc-editor.org/info/rfc9305>. ✨
Acknowledgments ✨
okay bestie, big group hug first 🫶 the original authors (💖) wanna thank Greg Schudel, Darrel Lewis, John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, and everyone on the lisp@ietf.org mailing list for their feedback and helpful suggestions. honestly iconic behavior 💅
and a special shoutout to Noel Chiappa 👑 for all his extensive work and thought about caching in Map-Resolvers. he really went deep on that one, no cap 🔥
the current authors also wanna give a sincere thank-you 🌸 to everyone who helped get LISP onto the Standards Track in the IETF. the list is long and iconic: Joel Halpern, Luigi Iannone, Deborah Brungard, Fabio Maino, Scott Bradner, Kyle Rose, Takeshi Takahashi, Sarah Banks, Pete Resnick, Colin Perkins, Mirja Kühlewind, Francis Dupont, Benjamin Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagan, Mohamed Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. 🧚
their contributions seriously leveled up the security, scale, and robustness of the LISP architecture and protocols. the glow-up is real ✨💜
Authors' Addresses 🦋
Dino Farinacci lispers.net San Jose, CA United States of America Email: farinacci@gmail.com
Fabio Maino Cisco Systems San Jose, CA United States of America Email: fmaino@cisco.com
Vince Fuller vaf.net Internet Consulting Email: vince.fuller@gmail.com
Albert Cabellos (editor) 🎀 Universitat Politecnica de Catalunya c/ Jordi Girona s/n 08034 Barcelona Spain Email: acabello@ac.upc.edu
📦 where this page comes from
- ietf: rfc9301 2022-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms