RFC 8111
Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)
Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) 🦋
Okay bestie, this is RFC 8111 🎀. It's an Experimental document from the IETF, dated May 2017, and its ISSN is 2070-1721. The authors are V. Fuller (VAF.NET Internet Consulting), D. Lewis (no affiliation listed in the header), V. Ermagan (Cisco Systems), A. Jain (Juniper Networks), and A. Smirnov (Cisco Systems). There's no Obsoletes or Updates line in the header, so it isn't replacing or changing any other RFC 💅.
Abstract ✨
Okay so this doc describes LISP-DDT, which is short for Locator/ID Separation Protocol Delegated Database Tree 🌸. It's a hierarchical distributed database built on the delegation of authority, and its whole job is handing out mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs) 🧚. It's a statically defined split of the EID namespace across a group of LISP-speaking servers called "DDT nodes". Each DDT node is set up as "authoritative" for one or more EID-prefixes. It also holds the set of RLOCs for Map-Servers, or for "child" DDT nodes, that the more-specific EID-prefixes get delegated to 💖.
Status of This Memo 📜
This doc isn't an Internet Standards Track spec. It's published for examination, experimental implementation, and evaluation 🧪.
It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 if you want the details 🙈.
To find out the current status of this doc, any errata, or how to send feedback, go to http://www.rfc-editor.org/info/rfc8111 🔥.
Copyright Notice ⚖️
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they were in effect on the date this doc was published. Please read these carefully, because they spell out your rights and restrictions for this doc 🫶. Any Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License 🔒.
Table of Contents 🗂️
1. Introduction ....................................................4
2. Requirements Language ...........................................5
3. Definitions of Terms ............................................6
4. Database Organization ...........................................8
4.1. XEID-Prefixes ..............................................8
4.2. Structure of the DDT Database ..............................8
4.3. Configuring Prefix Delegation ..............................9
4.3.1. The Root DDT Node ..................................10
5. DDT Map-Request ................................................10
6. The Map-Referral Message .......................................11
6.1. Action Codes ..............................................11
6.2. Referral Set ..............................................12
6.3. "Incomplete" Flag .........................................12
6.4. Map-Referral Message Format ...............................13
6.4.1. Signature Section ..................................15
7. DDT Network Elements and Their Operation .......................17
7.1. DDT Node ..................................................17
7.1.1. Matching of a Delegated Prefix (or Sub-prefix) .....17
7.1.2. Missing Delegation from an Authoritative Prefix ....18
7.2. DDT Map-Server ............................................18
7.3. DDT Client ................................................18
7.3.1. Queuing and Sending DDT Map-Requests ...............19
7.3.2. Receiving and Following Referrals ..................20
7.3.3. Handling Referral Errors ...........................22
7.3.4. Referral Loop Detection ............................22
8. Pseudocode and Decision Tree Diagrams ..........................23
8.1. Map-Resolver Processing of ITR Map-Request ................23
8.1.1. Pseudocode Summary .................................23
8.1.2. Decision Tree Diagram ..............................24
8.2. Map-Resolver Processing of Map-Referral Message ...........25
8.2.1. Pseudocode Summary .................................25
8.2.2. Decision Tree Diagram ..............................27
8.3. DDT Node Processing of DDT Map-Request Message ............28
8.3.1. Pseudocode Summary .................................28
8.3.2. Decision Tree Diagram ..............................30
9. Example Topology and Request/Referral Following ................31
9.1. Lookup of 2001:db8:0103:1::1/128 ..........................33
9.2. Lookup of 2001:db8:0501:8:4::1/128 ........................34
9.3. Lookup of 2001:db8:0104:2::2/128 ..........................35
9.4. Lookup of 2001:db8:0500:2:4::1/128 ........................36
9.5. Lookup of 2001:db8:0500::1/128 (Nonexistent EID) ..........37
10. Securing the Database and Message Exchanges ...................37
10.1. XEID-Prefix Delegation ...................................38
10.2. DDT Node Operation .......................................38
10.2.1. DDT Public Key Revocation .........................38
10.3. Map-Server Operation .....................................39
10.4. Map-Resolver Operation ...................................39
11. Open Issues and Considerations ................................40
12. IANA Considerations ...........................................41
13. Security Considerations .......................................41
14. References ....................................................42
14.1. Normative References .....................................42
14.2. Informative References ...................................43
Acknowledgments ...................................................44
Authors' Addresses ................................................441. Introduction 🌈
Okay so the Locator/ID Separation Protocol (LISP) [RFC6830] has an architecture and a mechanism for swapping out the addresses IP uses today for two separate namespaces 💅:
- Endpoint Identifiers (EIDs), which get used end to end for terminating transport-layer associations, and
- Routing Locators (RLOCs), which are tied to topological locations and get used for routing and forwarding through the Internet infrastructure.
[RFC6833] is the interface between a database that stores EID-to-RLOC mappings and the LISP devices that need that info for packet forwarding 🦋. The internal organization of that database is outside the scope of [RFC6833]. Several database architectures have been proposed, and each one has its pros and cons (see, for example, [RFC6836] and [RFC6837]) 🍓.
This doc specifies an architecture for a database of LISP EID-to-RLOC mappings, and it's all about high scalability 🚀. The LISP Delegated Database Tree (LISP-DDT) is a hierarchical distributed database built on the delegation of authority to provide mappings. In other words, its internal structure mirrors the hierarchical delegation of address space 🌳. It also gives delegation info to Map-Resolvers, and they use that info to find EID-to-RLOC mappings. A Map-Resolver that's looking for a given mapping follows a path through the tree-structured database. It contacts the DDT nodes along that path one after another, until it reaches the leaf DDT node(s) that are authoritative for the mapping it wants ✨.
LISP offers a general-purpose mechanism for mapping between EIDs and RLOCs. To organize a database of EID-to-RLOC mappings, this spec extends the EID numbering space by logically prepending and appending a few fields, so they can be used to define the database index key 🔑:
- Database-ID (DBID) (16 bits),
- Instance Identifier (IID) (32 bits),
- Address Family Identifier (AFI) (16 bits), and
- EID-prefix (variable, according to the AFI value).
Put together, those fields are called an "Extended EID-prefix", or XEID-prefix 💖.
LISP-DDT defines a new device type, the DDT node. It's set up as authoritative for one or more XEID-prefixes, and it's also configured with the set of more-specific sub-prefixes that get delegated further to other DDT nodes 🎀. To delegate a sub-prefix, the "parent" DDT node is configured with the RLOCs of each child DDT node that's authoritative for that sub-prefix. Each of those RLOCs either points to a DDT Map-Server (MS) that an Egress Tunnel Router (ETR) has registered that sub-prefix with, or it points to another DDT node in the database tree that delegates the sub-prefix further 🌸. Check [RFC6833] for how the Map-Server and Map-Resolver work. Also, the target of a delegation must always be an RLOC, not an EID, so there's no circular dependency 🙈.
To traverse the database tree, LISP-DDT defines a new LISP message type, the Map-Referral 🧭. It gets returned to the sender of a Map-Request when the receiving DDT node can refer that sender to another DDT node with more detailed info. Section 6 has the full definition of the Map-Referral message 💜.
To find an EID-to-RLOC mapping, a LISP-DDT client, usually a DDT Map-Resolver, starts by sending an Encapsulated Map-Request to a preconfigured DDT node RLOC 🚪. The DDT node answers with a Map-Referral message that says one of two things. Either (1) it will find the requested mapping itself to finish processing the request, or (2) the DDT client should contact another DDT node that has more-specific info. In case 2, the DDT node sends a new Encapsulated Map-Request to the next DDT node, and the process repeats iteratively 🔁.
This is kind of like how a Domain Name System (DNS) client follows referrals (DNS responses that only contain NS records) from a series of DNS servers until it gets an answer. It's giving DNS vibes, honestly 💅✨.
2. Requirements Language 📏
Here's the deal with the key words. "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, just like shown here 🫶.
3. Definitions of Terms 🎀
okay bestie, this section is the glossary for the whole spec, so let's get the vocab down 📖💖
- Extended EID (XEID): a LISP EID that's been glammed up with data uniquely identifying the address space it belongs to (LISP IID, address family, etc.). See Section 4.1 for a detailed description of XEID data. ✨
- Extended EID-prefix (XEID-prefix): a LISP EID-prefix with XEID data prepended to it. An XEID-prefix is used as a key index into the DDT database. XEID-prefixes are used to describe database organization and are not seen as a single entity in protocol messages, though messages contain individual fields constituting XEID-prefixes. 🧚
- DDT node: a network infrastructure component responsible for specific XEID-prefix(es) and for the delegation of more-specific sub-prefixes to other DDT nodes. 🌸
- DDT client: a network infrastructure component that sends DDT Map-Request messages and implements the iterative following of Map-Referral results. Typically, a DDT client will be a Map-Resolver (as defined by [RFC6833]), but it is also possible for an Ingress Tunnel Router (ITR) to implement DDT client functionality. 💅
- DDT Map-Server: a DDT node that also implements Map-Server functionality (forwarding Map-Requests and/or returning Map-Replies if offering a proxy Map-Reply service) for a subset of its delegated prefixes. Map-Server functions, including proxying Map-Replies, are described in [RFC6833]. 🦋
- DDT Map-Server peers: a list of all DDT Map-Servers performing Map-Server functionality for the same prefix. If peers are configured on a DDT Map-Server, then the latter will provide complete information about the prefix in its Map-Replies; otherwise, the Map-Server will mark the returned reply as potentially incomplete. 👯♀️
- DDT Map-Resolver: a network infrastructure element that implements both DDT client functionality and Map-Resolver functionality as defined by [RFC6833]. A DDT Map-Resolver accepts Map-Requests from ITRs, sends DDT Map-Requests to DDT nodes, and implements the iterative following of Map-Referrals. Note that Map-Resolvers do not respond to clients that sent Map-Requests; they only ensure that the Map-Request has been forwarded to a LISP device (ETR or proxy Map-Server) that will provide an authoritative response to the original requester. A DDT Map-Resolver will typically maintain a cache (termed the "referral cache") of previously received Map-Referral message results containing RLOCs for DDT nodes responsible for XEID-prefixes of interest. 🗂️
- Encapsulated Map-Request: a LISP Map-Request that is carried within an Encapsulated Control Message and that has an additional LISP header prepended to it. Sent to UDP destination port 4342. The "outer" addresses are globally routable IP addresses, also known as RLOCs. Used by an ITR when sending a Map-Request to a Map-Resolver and by a Map-Server when forwarding a Map-Request to an ETR as documented in [RFC6833]. 📦
- DDT Map-Request: an Encapsulated Map-Request sent by a DDT client to a DDT node. The "DDT-originated" flag is set in the encapsulation header, indicating that the DDT node should return Map-Referral messages if the Map-Request EID matches a delegated XEID-prefix known to the DDT node. Section 7.3.1 describes how DDT Map-Requests are sent. Section 5 defines the position of the "DDT-originated" flag in the Encapsulated Control Message header. 🚩
- Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node and for which the DDT node may provide further delegations of more-specific sub-prefixes. 👑
- Map-Referral: a LISP message sent by a DDT node in response to a DDT Map-Request for an XEID that matches a configured XEID-prefix delegation. A non-Negative Map-Referral includes a "referral" -- a set of RLOCs for DDT nodes that have information about the more-specific XEID-prefix covering the requested XEID; a DDT client "follows the referral" by sending another DDT Map-Request to one of those RLOCs to obtain either an answer or another referral to DDT nodes responsible for an XEID-prefix that is even more specific. See Sections 7.1 and 7.3.2 for details on the sending and processing of Map-Referral messages. 🔁
- Negative Map-Referral: an answer from an authoritative DDT node that there is no mapping for the requested XEID. A Negative Map-Referral is a Map-Referral sent in response to a DDT Map-Request that matches an authoritative XEID-prefix but for which there is no delegation configured (or no ETR registration, if sent by a DDT Map-Server). 🙈
- Pending Request List: the set of outstanding requests for which a DDT Map-Resolver has received Encapsulated Map-Requests from its clients seeking EID-to-RLOC mapping for an XEID. Each entry in the list contains additional state needed by the referral-following process, including the XEID, requester(s) of the XEID (typically one or more ITRs), saved information about the last referral received and followed (matching XEID-prefix, action code, RLOC set, index of the last RLOC queried in the RLOC set), and any LISP-Security (LISP-SEC) information [LISP-SEC] that was included in the DDT client Map-Request. An entry in the list may be interchangeably termed a "pending request list entry" or simply a "pending request". 📝
For definitions of other terms -- notably Map-Request, Map-Reply, ITR, ETR, Map-Server, and Map-Resolver -- please consult the LISP specification [RFC6830] and the LISP Mapping Service specification [RFC6833]. 🫶
4. Database Organization 🌈
4.1. XEID-Prefixes 🔑
A DDT database is indexed by Extended EID-prefixes (XEID-prefixes). An XEID-prefix is a LISP EID-prefix, together with data extending it to uniquely identify the address space of the prefix. An XEID-prefix is composed of four binary-encoded fields, ordered by significance: DBID (16 bits), IID (32 bits), AFI (16 bits), and EID-prefix (variable, according to the AFI value). The fields are concatenated, with the most significant fields as listed above. 🧩
The DBID is the LISP-DDT Database-ID, a 16-bit field provided to allow the definition of multiple databases. Implementations that are compliant with this document must always set this field to 0. Other values of the DBID are reserved for future use. 🍓
The Instance ID (IID) is a 32-bit value describing the context of the EID-prefix, if the latter is intended for use in an environment where addresses may not be unique, such as in a Virtual Private Network where the [RFC1918] address space is used. See Section 5.5 of [RFC6830] for more discussion of IIDs. Encoding of the IID is specified by [RFC8060]. 🌐
The AFI is a 16-bit value defining the syntax of the EID-prefix. AFI values are assigned by IANA [AFI]. 🎟️
4.2. Structure of the DDT Database 🌳
The LISP-DDT database for each DDT node is organized as a tree structure that is indexed by XEID-prefixes. Leaves of the database tree describe the delegation of authority between DDT nodes (see Section 4.3 for details regarding delegation and information kept in the database entries). 🪴
DDT Map-Requests sent by the DDT client to DDT nodes always contain specific values for the DBID, IID, and AFI; unspecified values or ranges of values are never used for any of these fields. Thus, an XEID-prefix used as a key for searches in the database tree will have a length of at least 64 bits. 📏
A DDT node may, for example, be authoritative for a consecutive range of 3-tuples (DBID, IID, AFI) and all associated EID-prefixes, or only for a specific EID-prefix of a single 3-tuple. Thus, XEID-prefixes/keys of the database tree leaves may have lengths less than, equal to, or more than 64 bits. 🎭
It is important to note that LISP-DDT does not store actual EID-to-RLOC mappings. It is, rather, a distributed index that can be used to find the devices (ETRs that registered their EIDs with DDT Map-Servers) that can be queried with LISP to obtain those mappings. Changes to EID-to-RLOC mappings are made on the ETRs that define them, not to any DDT node configuration. DDT node configuration changes are only required when branches of the database hierarchy are added, removed, or modified. 🚨
4.3. Configuring Prefix Delegation 🛠️
Every DDT node is configured with one or more XEID-prefixes for which it is authoritative, along with a list of delegations of XEID-prefixes to other DDT nodes. A DDT node is required to maintain a list of delegations for all sub-prefixes of its authoritative XEID-prefixes; it also may list "hints", which are prefixes that it knows about that belong to its parents, to the root, or to any other point in the XEID-prefix hierarchy. A delegation (or hint) consists of an XEID-prefix, a set of RLOCs for DDT nodes that have more detailed knowledge of the XEID-prefix, and accompanying security information (for details regarding security information exchange and its use, see Section 10). Those RLOCs are returned in Map-Referral messages when the DDT node receives a DDT Map-Request with an XEID that matches a delegation. A DDT Map-Server will also have a set of sub-prefixes for which it accepts ETR mapping registrations and for which it will forward (or answer, if it provides a proxy Map-Reply service) Map-Requests. 🤝
One or more XEID-prefixes for which a DDT node is authoritative, and the delegation of authority for sub-prefixes, are provided as part of the configuration of the DDT node. Implementations will likely develop a language to express this prefix authority and delegation. Since DDT configuration is static (i.e., not exchanged between DDT nodes as part of the protocol itself), such language is implementation dependent and is outside the scope of this specification. 💭
4.3.1. The Root DDT Node 👑✨
The root DDT node is the logical "top" of the distributed database hierarchy. It is authoritative for all XEID-prefixes -- that is, for all valid 3-tuples (DBID, IID, AFI) and their EID-prefixes. A DDT Map-Request that matches no configured XEID-prefix will be referred to the root node (see Section 8 for a formal description of conditions where a DDT Map-Request is forwarded to the root node). The root node in a particular instantiation of LISP-DDT therefore MUST be configured, at a minimum, with delegations for all defined IIDs and AFIs. 🌟
5. DDT Map-Request ✨
okay so a DDT client (usually a Map-Resolver) 🫶 sends Map-Request messages to a DDT node by wrapping them in LISP Encapsulated Control Messages (ECMs). The ECM format is defined by [RFC6830], and this spec adds one new flag to the ECM header: "DDT-originated" 🦋. You can see where it lives in the diagram below.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LH |Type=8 |S|D| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+D: The DDT-originated flag. 💖 A DDT client sets this flag to tell the receiver that it SHOULD return Map-Referral messages as appropriate. We dig into how this flag works in Section 7.3.1. This bit comes from the LISP message header bits that [RFC6830] marks as "Reserved" 🧚
6. The Map-Referral Message 🌸
this spec introduces a brand new LISP message called the Map-Referral message 💅. A DDT node sends a Map-Referral to a DDT client as its reply to a DDT Map-Request. If you want the full field layout, check out Section 6.4.
the message is made up of an action code plus delegation info about the XEID-prefix that matches the XEID you asked for 🎀
6.1. Action Codes
the action codes go like this 👑
NODE-REFERRAL (0): 🌈 the replying DDT node has delegated an XEID-prefix matching the requested XEID to one or more other DDT nodes. The Map-Referral carries a "map-record" with extra info, most importantly the set of RLOCs the prefix was delegated to, and the DDT client uses that to "follow" the referral 🔥
MS-REFERRAL (1): 💜 the replying DDT node has delegated an XEID-prefix matching the requested XEID to one or more DDT Map-Servers. It has the same extra info as a NODE-REFERRAL, but the receiving DDT client handles it a little differently (see Section 7.3.2) 🦋
MS-ACK (2): ✨ the replying DDT Map-Server got a DDT Map-Request that matches an authoritative XEID-prefix with one or more registered ETRs. So the request got forwarded to one of those ETRs so it can answer the querying ITR 🫶
MS-NOT-REGISTERED (3): 🙈 the replying DDT Map-Server got a Map-Request for one of its configured XEID-prefixes, but no ETRs are registered for it.
DELEGATION-HOLE (4): 🕳️ the requested XEID matches a non-delegated sub-prefix of the XEID space. It's a non-LISP "hole" that hasn't been delegated to any DDT Map-Server or ETR. See Section 7.1.2 for the deets 💀. This one is also sent by a DDT Map-Server that has authoritative config covering the requested EID, but no specific site ETR is configured for it.
NOT-AUTHORITATIVE (5): 😭 the replying DDT node got a Map-Request for an XEID it isn't authoritative for, and it has no configured matching hint referrals. This can happen when a cached referral goes stale because the database hierarchy changed. Still, if that DDT node has a "hint" delegation covering the requested EID, it MAY choose to return NODE-REFERRAL or MS-REFERRAL as appropriate. When it returns NOT-AUTHORITATIVE, the DDT node MUST provide the EID-prefix from the request, and the TTL MUST be set to 0 🍓
⚠️ bestie, read that last bit twice. The EID-prefix has to be copied from the request, and the TTL has to be 0.
6.2. Referral Set
for the "positive" action codes (NODE-REFERRAL, MS-REFERRAL, MS-ACK), a DDT node MUST include in the Map-Referral a list of RLOCs for DDT nodes that are authoritative for the XEID-prefix being returned 🌸 The DDT client uses that list to reach one of those DDT nodes when it "follows" a referral ✨
6.3. "Incomplete" Flag
a DDT node sets the "Incomplete" flag in a Map-Referral when the Referral Set is incomplete 🙈. The point is to stop a DDT client from caching a referral that has incomplete info 🧚 A DDT node MUST set the "Incomplete" flag in these cases:
- If it's sending action code MS-ACK or MS-NOT-REGISTERED, but the matching XEID-prefix isn't flagged as "complete" in the configuration. The XEID-prefix configuration on the DDT Map-Server SHOULD be marked as "complete" when it lists every "peer" DDT node that's also authoritative for the same XEID-prefix, or when it's known that a local DDT node is the only authoritative node for that XEID-prefix 💅
- If it's sending action code NOT-AUTHORITATIVE.
6.4. Map-Referral Message Format ✨
okay bestie, this is the big one 🦋 here's the whole Map-Referral layout, and every single bit has a job 💅
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=6 | Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Referral Count| EID mask-len | ACT |A|I| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c |SigCnt | Map Version Number | EID-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix ... |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| e | Unused Flags |L|p|R| Loc-AFI |
| f +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator ... |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~ Sig section ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 🎀 Type value 6 was reserved for future use in [RFC6830]. This document allocates this value to identify Map-Referral messages, so 6 is officially the Map-Referral type now 👑
ACT 💖 The ACT (Action) field of the mapping Record in a Map-Referral message encodes one of six action types: NODE-REFERRAL, MS-REFERRAL, MS-ACK, MS-NOT-REGISTERED, DELEGATION-HOLE, or NOT-AUTHORITATIVE. Peep Section 6.1 for what each of these actually means 🌸
Incomplete 🙈 The "I" bit tells you that a DDT node's Referral Set of locators is incomplete, and the receiver of this message SHOULD NOT cache the referral. A DDT sets the "Incomplete" flag, the TTL, and the Action field like this:
-------------------------------------------------------------------
Type (Action field) Incomplete Referral Set TTL values
-------------------------------------------------------------------
0 NODE-REFERRAL No Yes 1440
1 MS-REFERRAL No Yes 1440
2 MS-ACK * * 1440
3 MS-NOT-REGISTERED * * 1
4 DELEGATION-HOLE No No 15
5 NOT-AUTHORITATIVE Yes No 0
-------------------------------------------------------------------*: okay so the "Incomplete" flag for the Map-Server-originated referral of MS-ACK and MS-NOT-REGISTERED types depends on whether the Map-Server has the full peer Map-Server configuration for the same prefix and has encoded that info in the mapping Record 🧚 If the bit isn't set, the Map-Server has encoded the info, which means the Referral Set includes all the RLOCs of all Map-Servers that serve the prefix. The bit MUST be set when the configuration of the Map-Server doesn't flag the matching prefix as configured with the complete information about "peer" Map-Servers, or when the Map-Server doesn't return all configured locators. no skipping that one, bestie 😭
Referral Count 🍓 This is the number of RLOCs in the current Referral Set. It's equal to the number of "Ref" sections in the message, which you can see in the diagram above ✨
SigCnt 🔥 This tells you how many signatures (Signature sections) are in the Record. If SigCnt is larger than 0, the signature info in a Signature section, as described in Section 6.4.1, gets tacked onto the very end of the Record. The number of Signature sections at the end of the Record MUST match the SigCnt. Also, the bits that SigCnt uses were marked "Reserved" in Records embedded into messages defined by [RFC6830], and they were required to be set to zero. so this is a glow-up of old reserved space 🌈
⚠️ Keep the MUST in mind here: the number of Signature sections has to match SigCnt exactly. No wiggle room, periodt.
Loc-AFI 🦋 This is the AFI of the Locator field. If the AFI value is different from the LISP Canonical Address Format (LCAF) AFI, security keys are not included in the Record. If it IS equal to the LCAF AFI, then the contents of the LCAF depend on the LCAF's Type field. LCAF Type 11 is used to store security material along with the AFI of the locator. DDT nodes and DDT Map-Servers can use this LCAF Type to include public keys tied to their child DDT nodes for an XEID-prefix Map-Referral Record. LCAF Types and formats are defined in [RFC8060] 💜
Locator 🌸 This is the RLOC of a DDT node that the DDT client is being referred to. It's variable-length, and its length is determined by the Loc-AFI setting 🫶
All other fields and their descriptions match the ones in the Map-Reply message, as defined in LISP [RFC6830]. The one twist is that the set of RLOCs here corresponds to the DDT node you're going to query as a result of the referral, not to the RLOCs for an actual EID-to-RLOC mapping. don't mix those up, bestie 💅
6.4.1. Signature Section
SigCnt counts the number of signature sections that show up at the end of the Record. Here's what the signature section looks like 🔐
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/| Original Record TTL |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Signature Expiration |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
s | Signature Inception |
i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
g | Key Tag | Sig Length |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Sig-Algorithm | Reserved | Reserved |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ~ Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Original Record TTL ⭐ This is the original Record TTL for this Record, the one that the signature covers. The Record TTL value is specified in minutes ⏰
Signature Expiration and Signature Inception 🗓️ These two specify the validity period for the signature. The signature MUST NOT be used for authentication prior to the inception date, and MUST NOT be used for authentication after the expiration date. Each field specifies a date and time as a 32-bit unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. time is a construct, fr fr 🕰️
Key Tag 🔑 An identifier that says which key was used for this signature, in case more than one valid key exists for the signing DDT node 🗝️
Sig Length 📏 The length of the Signature field, in bytes.
Sig-Algorithm 🧁 The identifier of the cryptographic algorithm used for the signature. The Sig-Algorithm values defined in this specification are listed in Table 1. Implementations conforming to this specification MUST implement at least RSA-SHA256 for DDT signing. Sig-Algorithm type 1 (RSA-SHA1) is deprecated and SHOULD NOT be used. RIP RSA-SHA1 🪦
+---------------+------------+-----------+------------+
| Sig-Algorithm | Name | Reference | Notes |
+---------------+------------+-----------+------------+
| 1 | RSA-SHA1 | [RFC8017] | DEPRECATED |
| | | | |
| 2 | RSA-SHA256 | [RFC8017] | MANDATORY |
+---------------+------------+-----------+------------+
Table 1: Sig-Algorithm ValuesReserved 🎀 These MUST be set to 0 on transmit and MUST be ignored on receipt. Yes, both rules, no exceptions 💅
Signature ✍️ This contains the cryptographic signature covering the entire Map-Referral Record that this signature belongs to. To compute the signature, the Record TTL (Section 6.4) gets set to the value of Original Record TTL, and the Signature field is filled with zeros. it's like a little rewind trick 🪄
7. DDT Network Elements and Their Operation ✨
As described above, LISP-DDT introduces a new network element -- the DDT node -- and extends the functionality of Map-Servers and Map-Resolvers so they can send and receive Map-Referral messages 🌈 The operation of each of these devices is described below, so let's get into it 💜
7.1. DDT Node
When a DDT node receives a DDT Map-Request, it compares the requested XEID against its list of XEID-prefix delegations and its list of authoritative XEID-prefixes, and then proceeds as follows 👑
7.1.1. Matching of a Delegated Prefix (or Sub-prefix)
If the requested XEID matches one of the DDT node's delegated prefixes, then a Map-Referral message gets returned with the matching more-specific XEID-prefix and the set of RLOCs for the referral target DDT nodes, including the associated security information (see Section 10 for the security details) 🔒 If at least one DDT node of the delegation is known to be a DDT Map-Server, then the Map-Referral message SHOULD be sent with action code MS-REFERRAL, to tell the receiver that LISP-SEC information (if it was saved in the pending request) SHOULD be included in the next DDT Map-Request. Otherwise, the action code NODE-REFERRAL SHOULD be used 🦋
Note that a matched delegation does not have to be for a sub-prefix of an authoritative prefix. On top of being configured to delegate sub-prefixes of an authoritative prefix, a DDT node may also be configured with other XEID-prefixes that it can use to provide referrals to DDT nodes anywhere in the database hierarchy. This capability to define "shortcut hints" is never required to be configured, but it may be a useful heuristic for reducing the number of iterations needed to find an EID, particularly for private network deployments 🧚
Referral hints, if used properly, may reduce the number of referrals a DDT client needs to follow to locate a DDT Map-Server authoritative for the XEID-prefix being resolved. On the other hand, the incorrect use of hints may create circular dependencies (or "referral loops") between DDT nodes. A DDT client MUST be prepared to handle such circular referrals. See Section 7.3.4 for a discussion of referral loops and the measures that the DDT client must implement in order to detect circular referrals and prevent infinite looping 🌀
Another danger related to the use of hints is when a DDT deployment spans multiple administrative domains (i.e., different authorities manage DDT nodes in the same DDT database). In this case, an operator managing a DDT node may not be aware of the fact that the node is being referred to by hints. Locator addresses in hints may become stale when referred DDT nodes are taken out of service or change their locator addresses. this is where things get messy, bestie 😭💀
7.1.2. Missing Delegation from an Authoritative Prefix ✨
okay so this is the "wait, this XEID isn't delegated but it's inside a prefix I'm in charge of" situation 💅. If the requested XEID didn't match a configured delegation but does match an authoritative XEID-prefix, the DDT node MUST return a Negative Map-Referral that uses the least-specific XEID-prefix that doesn't match any XEID-prefix the DDT node has delegated 🫶. The action code gets set to DELEGATION-HOLE, which signals that this XEID is not a LISP destination 🙈.
If the requested XEID matched none of the three things (a configured delegation, an authoritative XEID-prefix, or a hint), then a Negative Map-Referral with action code NOT-AUTHORITATIVE MUST be returned 💀.
7.2. DDT Map-Server
when a DDT Map-Server gets a DDT Map-Request, it works pretty much like a DDT node, with some extra steps on top 🧚
- If the requested XEID matches a registered XEID-prefix, the Map-Request gets forwarded to one of the destination ETR RLOCs (or the Map-Server sends a Map-Reply instead, if it's running a proxy Map-Reply service). Either way, a Map-Referral with action code
MS-ACKMUST be returned to the sender of the DDT Map-Request 🔥. - If the requested XEID matches a configured XEID-prefix but no ETR registration has come in for it, a Negative Map-Referral with action code
MS-NOT-REGISTEREDMUST be returned to the sender of the DDT Map-Request 😭.
7.3. DDT Client
a DDT client queries one or more DDT nodes and runs an iterative loop: it keeps following returned referrals until it gets one with action code MS-ACK (or an error indication) 🌸. MS-ACK basically means "the Map-Request has been sent to a Map-Server that will forward it to an ETR, and that ETR will send a Map-Reply to the locator address in the Map-Request" ✨.
DDT client functionality will typically be implemented by DDT Map-Resolvers. Just like any other Map-Resolver, a DDT Map-Resolver accepts Map-Requests from its clients (typically ITRs) and makes sure they get forwarded to the correct ETR, which generates Map-Replies 💖. The difference is that a Map-Resolver using the LISP Alternative Logical Topology (LISP+ALT) mapping system [RFC6836] doesn't need to do this hunt itself, but a DDT Map-Resolver implements DDT client functionality to find the correct ETR to answer a Map-Request. That means it needs extra state: a Map-Referral cache, plus a pending request list of XEIDs that are going through the iterative referral process 🦋.
DDT client functionality may be implemented on ITRs too. In that case, the DDT client won't receive a Map-Request from another network element. Instead, the same information gets handed to the DDT client through a programming interface 🎀.
7.3.1. Queuing and Sending DDT Map-Requests
when a DDT client gets a request to resolve an XEID (for a DDT Map-Resolver, that shows up as a received Encapsulated Map-Request), it first does a longest-match search for the XEID in its referral cache 🔍. If nothing matches, or a negative cache entry is found, then the destination isn't in the database. A Negative Map-Reply MUST be returned, and the DDT client does no further processing 🙅♀️.
If a match is found, the DDT client makes a pending request list entry for the XEID and saves the original request (for a DDT Map-Resolver, that's the original Map-Request minus the encapsulation header). It also saves whatever else it needs to track progress through the iterative referral process. The "referral XEID-prefix" gets initialized to show that no referral has been received yet 🌈. Then the DDT client builds a DDT Map-Request for the XEID: an Encapsulated Map-Request with the DDT-originated flag set in the message header. It leaves out any authentication data that might have been in the original request 🔐. The DDT Map-Request gets sent to one of the RLOCs in the chosen referral cache entry 🚀.
The referral cache starts out with one or more statically configured entries. More entries get added as referrals are followed, as described below 📚. Caching referrals isn't strictly mandatory for a DDT client, but doing it will cut latency and reduce lookup delays ⚡.
heads up bestie: on normal public Internet use, the statically configured initial referral cache for a DDT client should include a "default" entry with RLOCs for either the root DDT node or one or more DDT nodes that contain hints for the root DDT node 👑.
Without that config, a DDT client will return a Negative Map-Reply if it gets a query for an EID outside the slice of the mapping database it knows about. That might be fine on private network deployments or during the early transition to LISP, when few sites are using it. But it's not appropriate once LISP is in general use on the Internet 🙃. If DDT message exchanges are authenticated as described in Section 10, then the DDT client MUST also be configured with public keys of DDT nodes pointed to by the "default" cache entry. In this case, the "default" entry will typically be for the root DDT node 🔑.
7.3.2. Receiving and Following Referrals
after sending a DDT Map-Request, a DDT client expects a Map-Referral response 👀. If none shows up within the timeout period, the DDT client retransmits the request, sending it to the next RLOC in the referral cache entry if one is available. If all RLOCs have been tried and each has hit the maximum number of retransmissions, the pending request list entry gets dequeued and discarded. In that case, the DDT client returns no response to the sender of the original request 💔.
A DDT client handles a received Map-Referral message based on its action code 🧠:
NODE-REFERRAL: the DDT client checks for a possible referral loop, as described in Section 7.3.4. If no loop is found, it saves the prefix returned in the Map-Referral message in the referral cache. It updates the saved prefix and saved RLOCs in the pending request list entry, then follows the referral by sending a new DDT Map-Request to one of the DDT node RLOCs listed in the Referral Set. Security information saved with the original Map-Request SHOULD NOT be included 🙅.
MS-REFERRAL: the DDT client handles an MS-REFERRAL the same way as a NODE-REFERRAL, except that security information saved with the original Map-Request MUST be included in the new Map-Request sent to a Map-Server. (See Section 10 for details on security 🛡️.)
MS-ACK: an MS-ACK is returned by a DDT Map-Server to say it has one or more registered ETRs that can answer a Map-Request for the XEID, and the request has been forwarded to one of them. (Or, if the Map-Server is providing a proxy service for the prefix, a reply has already been sent to the querying ITR.) If the pending request didn't include saved LISP-SEC information, or if that information was already included in the previous DDT Map-Request (the one sent in response to either an MS-REFERRAL or an earlier MS-ACK referral), then the pending request for the XEID is complete. Processing stops and all request state can be discarded 🎉. Otherwise, LISP-SEC information is required but hasn't been sent to the authoritative DDT Map-Server yet. The DDT client MUST resend the DDT Map-Request with LISP-SEC information included, and the pending request queue entry stays put until another Map-Referral with action code MS-ACK arrives 🔁. If the "Incomplete" flag isn't set, the prefix gets saved in the referral cache 💾.
MS-NOT-REGISTERED: the DDT Map-Server queried couldn't process the request, because it didn't have any ETRs registered for a matching, authoritative XEID-prefix. If the DDT client hasn't tried all the RLOCs saved with the pending request yet, it sends a Map-Request to the next RLOC in that list. If all RLOCs have been tried, then the destination XEID isn't registered and is unreachable 🚫. The DDT client MUST return a Negative Map-Reply to the requester (or, for a DDT Map-Resolver, to the sender of the original Map-Request). That Map-Reply contains the least-specific XEID-prefix in the range this DDT Map-Server is authoritative for, where no registrations exist. The TTL value of the Negative Map-Reply SHOULD be set to 1 minute. A negative referral cache entry is created for the prefix (whose TTL also SHOULD be set to 1 minute), and processing of the request stops 🧊.
DELEGATION-HOLE: the DDT Map-Server queried didn't have an XEID-prefix defined that matched the requested XEID, so the XEID doesn't exist in the mapping database 🕳️. The DDT client MUST return a Negative Map-Reply to the requester (or, for a DDT Map-Resolver, to the sender of the original Map-Request). This Map-Reply SHOULD indicate the least-specific XEID-prefix matching the requested XEID for which no delegations exist, and SHOULD have a TTL value of 15 minutes. A negative referral cache entry is created for the prefix (which also SHOULD have a TTL of 15 minutes), and processing of the pending request stops 🛑.
NOT-AUTHORITATIVE: the DDT Map-Server queried isn't authoritative for the requested XEID. This can happen if a cached referral has gone stale because the database hierarchy changed 🌀. If the DDT client receiving this message can tell it's using old cached information, it MAY choose to delete that cached information and retry the original Map-Request, starting from its "root" cache entry. If this action code shows up in response to a query that did not use cached referral information, it points to a database synchronization problem or a configuration error 🛠️. The pending request is silently discarded; i.e., all state for the request that caused this answer is removed, and no answer is returned to the original requester 🤫.
7.3.3. Handling Referral Errors
other states are possible too, like a misconfigured DDT node (acting as a proxy Map-Server, for example) returning a Map-Reply to the DDT client 😬. Those should be treated as errors and logged as such. It's not totally clear what else the DDT client should do in these cases. One option is to remove the pending request list entry and send a Negative Map-Reply to the requester (or, for a DDT Map-Resolver, to the sender of the original Map-Request) 📝. Another option: if a DDT client detects unexpected behavior by a DDT node, it could mark that node as unusable in its referral cache, and update the pending request to try a different DDT node if more than one is listed in the referral cache 🔄. Either way, any prefix contained in a Map-Referral message that causes a referral error (including a referral loop) is not saved in the DDT client referral cache 🚫💅.
7.3.4. Referral Loop Detection ✨
okay so bestie, a Map-Referral with action code NODE-REFERRAL or MS-REFERRAL is basically the DDT node going "ask these guys instead" 🙃 and the DDT client has to go query a new set of DDT node RLOCs that should know more-specific XEID-prefix info for the requested XEID. but ngl there's a sneaky danger here: an iteration loop 🌀, where you bounce between DDT nodes forever and never get an answer. not on my watch 💅
so the DDT client saves the last received referral XEID-prefix for each pending request. then, when a newly received NODE-REFERRAL or MS-REFERRAL shows up, it checks whether that new referral XEID-prefix is more specific. if it's an exact match or less specific than the saved one, that's a referral loop 🚨 and the DDT Map-Resolver handles the request as described in Section 7.3.3. if it's not a loop, the DDT client saves the newest referral XEID-prefix with the pending request as it follows the referral. the vibe is "always moving closer, never going in circles" 🦋
extra safety? it's probably also wise to cap the total number of referrals for any request at some reasonable number 🧢. the exact number gets figured out during experimental deployment of LISP-DDT, but it's bounded by the maximum length of the XEID. (the boundary is giving very "you can't go past this" energy 😭)
one more fun thing 🎀: when a DDT client adds an entry to its lookup queue and sends an initial Map-Request for an XEID, that queue entry has no previous referral XEID-prefix yet. so the first DDT node contacted by a DDT Map-Resolver can refer you anywhere in the DDT hierarchy 🌍. which means a DDT client can use basically any DDT node RLOCs for its initial cache entries and rely on that first referral to point it somewhere useful. so there's no need to configure the same set of root DDT nodes on every DDT client 🙌 (main character energy for the whole system ✨)
8. Pseudocode and Decision Tree Diagrams 🧠
okay so this section is the cheat sheet 📝 to help you actually build this stuff. for each of the major DDT Map-Server and DDT Map-Resolver functions, we get some simple "pseudocode" first, and then the same logic as a decision tree 🌳. two ways to see it, both slay 💖
8.1. Map-Resolver Processing of ITR Map-Request 🎀
8.1.1. Pseudocode Summary
if ( request pending, i.e., (ITR,EID) of request same ) {
replace old request with new, & use new request nonce
for future requests
} else if ( no match in refcache ) {
return Negative Map-Reply to ITR
} else if ( match type DELEGATION-HOLE ) {
return Negative Map-Reply to ITR
} else if ( match type MS-ACK ) {
fwd DDT Map-Request to Map-Server
} else {
store & fwd DDT Map-Request w/o security material
to node delegation
}8.1.2. Decision Tree Diagram 🌳
+------------+
| Is request | Yes
| pending? |----> Replace old request with
| | new nonce for future requests
+------------+
|
|No
|
V
+------------+
| Match in | No
| referral |----> Send Negative Map-Reply
| cache? | (not a likely event, as root or
+------------+ hint configured on every Map-Resolver)
|
|Yes
|
V
+-------------+
| Match type | Yes
| DELEGATION- |----> Send Negative Map-Reply
| HOLE? |
+-------------+
|
|No
|
V
+------------+
| Match type | Yes
| MS-ACK? |----> Forward DDT Map-Request to Map-Server
| |
+------------+
|
|No
|
V
Store original request & send DDT Map-Request w/o security material
to DDT node delegation8.2. Map-Resolver Processing of Map-Referral Message 📨
8.2.1. Pseudocode Summary
if ( authentication signature validation failed ) {
silently drop
}
if ( no request pending matched by referral nonce ) {
silently drop
}
if ( pfx in referral less specific than last referral used ) {
if ( gone through root ) {
silently drop
} else {
send request to root
}
}
switch (map_referral_type) {
case NOT_AUTHORITATIVE:
if ( gone through root ) {
return Negative Map-Reply to ITR
} else {
send request to root
}
case DELEGATION_HOLE:
cache & send Negative Map-Reply to ITR
case MS_REFERRAL:
if ( referral equal to last used ) {
if ( gone through root ) {
return Negative Map-Reply to ITR
} else {
send request to root
}
} else {
cache
follow the referral; include security material
}
case NODE_REFERRAL:
if ( referral equal to last used ) {
if ( gone through root ) {
return Negative Map-Reply to ITR
} else {
send request to root
}
} else {
cache
follow the referral; strip security material
}
case MS_ACK:
if ( security material stripped ) {
resend request with security material
if { !incomplete } {
cache
}
}
case MS_NOT_REGISTERED:
if { all Map-Server delegations not tried } {
follow delegations not tried
if ( !incomplete ) {
cache
}
} else {
send Negative Map-Reply to ITR
if { !incomplete } {
cache
}
}
case DEFAULT:
drop
}
}8.2.2. Decision Tree Diagram 🌲
+----------------+
| Auth signature | No
| valid? |----> Silently drop
+----------------+
| Yes
V
+------------+
| Is request | No
| pending? |----> Silently drop
+------------+
| Yes
V
+------------------------------+ Yes
| Pfx less specific than last? |----> Silently drop
+------------------------------+
|No
V
+---------------------------------------------------+
| What is Map-Referral type? |--Unknown-+
+---------------------------------------------------+ |
| | | | | | V
| | | | | DEL_HOLE Drop
| | | | MS_ACK |
| | | | | V
| | MS_REF NODE_REF | Cache & return
| | | | V Negative Map-Reply
| | | | +---------+
| NOT_AUTH | | | Was sec | Yes
| | | | | material|
| | | | |stripped?|----> Done
| | V V +---------+
| | +------------+ | No
| | Yes | Pfx equal | V
MS_NOT_REGISTERED | +---| to last | +------------+
| | | | used? | |"Incomplete"| Yes
| | | +------------+ | bit set? |---> Resend DDT
| V V |No +------------+ request w/
| +------------+ | |No security
| | Gone | V | material
| | through | Cache & follow V
| | root? | the referral Cache & resend DDT
| +------------+ request with
| |No |Yes security material
| | |
| V V
| Send req Send Negative Map-Reply
| to root
V
+-----------+ Yes +------------+ Yes
| Other MS |---Follow other MS-------->|"Incomplete"|----> Don't cache
| not tried?| | bit set? |
| |--Send Negative Map-Reply->| |----> Cache
+-----------+ No +------------+ No8.3. DDT Node Processing of DDT Map-Request Message 🛎️
8.3.1. Pseudocode Summary
if ( I am not authoritative ) {
send Map-Referral NOT_AUTHORITATIVE with
"Incomplete" bit set and TTL 0
} else if ( delegation exists ) {
if ( delegated Map-Servers ) {
send Map-Referral MS_REFERRAL with
TTL 'Default_DdtNode_Ttl'
} else {
send Map-Referral NODE_REFERRAL with
TTL 'Default_DdtNode_Ttl'
}
} else {
if ( EID in site) {
if ( site registered ) {
forward Map-Request to ETR
if ( Map-Server peers configured ) {
send Map-Referral MS_ACK with
TTL 'Default_Registered_Ttl'
} else {
send Map-Referral MS_ACK with
TTL 'Default_Registered_Ttl' and "Incomplete" bit set
}
} else {
if ( Map-Server peers configured ) {
send Map-Referral MS_NOT_REGISTERED with
TTL 'Default_Configured_Not_Registered_Ttl'
} else {
send Map-Referral MS_NOT_REGISTERED with
TTL 'Default_Configured_Not_Registered_Ttl'
and "Incomplete" bit set
}
}
} else {
send Map-Referral DELEGATION_HOLE with
TTL 'Default_Negative_Referral_Ttl'
}
}
where architectural constants for TTL are set as follows:
Default_DdtNode_Ttl 1440 minutes
Default_Registered_Ttl 1440 minutes
Default_Negative_Referral_Ttl 15 minutes
Default_Configured_Not_Registered_Ttl 1 minute8.3.2. Decision Tree Diagram ✨
Okay bestie, here's the whole decision tree in one picture 🌳💖 Start at the top-left box and follow the arrows:
+------------+
| Am I | No
| authori- |----> Return NOT_AUTHORITATIVE
| tative? | Incomplete = 1
+------------+ TTL = Default_DdtNode_Ttl
|
|Yes
|
V
+------------+ +-------------+
| Delegation | Yes | Delegations | Yes
| exists? |---->| are |----> Return MS_REFERRAL
| | | Map-Servers?| TTL = Default_DdtNode_Ttl
+------------+ +-------------+
| \ No
|No +--> Return NODE_REFERRAL
| TTL = Default_DdtNode_Ttl
V
+------------+ +------------+ +------------+
| EID in | Yes | Site | Yes | Map-Server |
| site |---->| registered?|----> Forward---->| peers |
| config? | | | Map-Request | configured?|
+------------+ +------------+ to ETR +------------+
| | | |
| |No No| |Yes
| | | |
| | V V
| | Return MS_ACK Return MS_ACK
| V with INC=1
| +------------+ TTL = Default_Registered_Ttl
| | Map-Server | Yes
| | peers |----> Return MS_NOT_REGISTERED
| | configured?| TTL = Default_Negative_Referral_Ttl
| +------------+
| \ No
|No +--> Return MS_NOT_REGISTERED
| Incomplete = 1
V TTL = Default_Negative_Referral_Ttl
Return DELEGATION_HOLE
TTL = Default_Negative_Referral_Ttl9. Example Topology and Request/Referral Following 🦋
Let's do some examples now 🍓 This section shows an example DDT tree plus a few scenarios where Map-Requests land on a Map-Resolver and then get passed along through iterative DDT referrals. In this example, the RLOCs of the DDT nodes are IPv4 addresses, but the EIDs are in the IPv6 AF. The same principle of hierarchical delegation and pinpointing referrals works for any AF whose address hierarchy can be written as a bit string with an associated length. ✨ The DDT "tree" of IPv4 prefixes is another AF with immediate practical value 💅
This section could honestly use more examples, maybe one with IPv4 EIDs and another with IPv6 RLOCs 🙈 If this document is moved to the Standards Track, consideration should be given to adding such examples.
To see how referrals get followed to find the RLOCs for a bunch of EIDs, check out this example EID topology for DBID=0, IID=0, AFI=2, and EID=0/0:
+---------------------+ +---------------------+
| root1: 192.0.2.1 | | root2: 192.0.2.2 |
| authoritative: ::/0 | | authoritative: ::/0 |
+---------------------+ +---------------------+
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| | | |
V V V V
+-------------------------+ +--------------------------+
| DDT node1: 192.0.2.11 | | DDT node2: 192.0.2.12 |
| authoritative: | | authoritative: |
| 2001:db8::/32 | | 2001:db8::/32 |
+-------------------------+ +--------------------------+
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| | | |
V V V V
+--------------------------+ +---------------------------+
| Map-Server1: 192.0.2.101 | | DDT node3: 192.0.2.201 |
| authoritative: | | authoritative: |
| 2001:db8:0100::/40 | | 2001:db8:0500::/40 |
| site1: 2001:db8:0103::/48| +---------------------------+
| site2: 2001:db8:0104::/48| | |
+--------------------------+ | |
| |
| |
V V
+---------------------------+ +---------------------------+
| Map-Server2: 192.0.2.211 | | Map-Server3: 192.0.2.221 |
| authoritative: | | authoritative: |
| 2001:db8:0500::/48 | | 2001:db8:0501::/48 |
|site3: 2001:db8:0500:1::/64| |site5: 2001:db8:0501:8::/64|
|site4: 2001:db8:0500:2::/64| |site6: 2001:db8:0501:9::/64|
+---------------------------+ +---------------------------+The DDT nodes for this "root" are configured at IP addresses 192.0.2.1 and 192.0.2.2, and the DDT Map-Resolvers have default referral cache entries for those addresses 🌸
The root DDT nodes delegate 2001:db8::/32 to two DDT nodes, at 192.0.2.11 and 192.0.2.12 🎀
The DDT nodes for 2001:db8::/32 delegate 2001:db8:0100::/40 to a DDT Map-Server with RLOC 192.0.2.101. That Map-Server is configured to let ETRs register the sub-prefixes 2001:db8:0103::/48 and 2001:db8:0104::/48 🧚
The DDT nodes for 2001:db8::/32 also delegate 2001:db8:0500::/40 to a DDT node with RLOC 192.0.2.201. That node is further set up to delegate 2001:db8:0500::/48 to a DDT Map-Server with RLOC 192.0.2.211, and 2001:db8:0501::/48 to a DDT Map-Server with RLOC 192.0.2.221 👑
The DDT Map-Server for 2001:db8:0500::/48 is configured to let ETRs register 2001:db8:0500:1::/64 and 2001:db8:0500:2::/64. The DDT Map-Server for 2001:db8:0501::/48 is configured to let ETRs register 2001:db8:0501:8::/64 and 2001:db8:0501:9::/64 💜
9.1. Lookup of 2001:db8:0103:1::1/128 🌈
The first example shows a DDT Map-Resolver following a delegation from the root to a DDT node, and then another delegation to a DDT Map-Server ✨
ITR1 sends an Encapsulated Map-Request for 2001:db8:0103:1::1 to one of its configured (DDT) Map-Resolvers. The DDT Map-Resolver then does this 💅
- Sends a DDT Map-Request (for
2001:db8:0103:1::1) to one of the root DDT nodes (192.0.2.1or192.0.2.2). - Receives (and saves in the referral cache) the Map-Referral for EID-prefix
2001:db8::/32, action codeNODE-REFERRAL, RLOC set (192.0.2.11,192.0.2.12). - Sends a DDT Map-Request to
192.0.2.11or192.0.2.12. - Receives (and saves in the referral cache) the Map-Referral for EID-prefix
2001:db8:0100::/40, action codeMS-REFERRAL, RLOC set (192.0.2.101). - Sends a DDT Map-Request to
192.0.2.101; if the ITR-originated Encapsulated Map-Request had a LISP-SEC signature, it is included. - The DDT Map-Server at
192.0.2.101decapsulates the DDT Map-Request and forwards the Map-Request to a registered site1 ETR for2001:db8:0103::/48. - The DDT Map-Server at
192.0.2.101sends a Map-Referral message for EID-prefix2001:db8:0103::/48, action codeMS-ACK, to the DDT Map-Resolver. - The DDT Map-Resolver receives the Map-Referral message and dequeues the pending request for
2001:db8:0103:1::1. - The site1 ETR for
2001:db8:0103::/48receives the Map-Request forwarded by the DDT Map-Server and sends a Map-Reply to ITR1 🦋
9.2. Lookup of 2001:db8:0501:8:4::1/128 💖
This next example is a three-level delegation: root to first DDT node, first DDT node to second DDT node, and second DDT node to DDT Map-Server. It's giving main character energy 👑
ITR2 sends an Encapsulated Map-Request for 2001:db8:0501:8:4::1 to one of its configured (DDT) Map-Resolvers, which are different from the ones ITR1 uses. The DDT Map-Resolver does this 🫶
- Sends a DDT Map-Request (for
2001:db8:0501:8:4::1) to one of the root DDT nodes (192.0.2.1or192.0.2.2). - Receives (and saves in the referral cache) the Map-Referral for EID-prefix
2001:db8::/32, action codeNODE-REFERRAL, RLOC set (192.0.2.11,192.0.2.12). - Sends a DDT Map-Request to
192.0.2.11or192.0.2.12. - Receives (and saves in the referral cache) the Map-Referral for EID-prefix
2001:db8:0500::/40, action codeNODE-REFERRAL, RLOC set (192.0.2.201). - Sends a DDT Map-Request to
192.0.2.201. - Receives (and saves in the referral cache) the Map-Referral for EID-prefix
2001:db8:0501::/48, action codeMS-REFERRAL, RLOC set (192.0.2.221). - Sends a DDT Map-Request to
192.0.2.221; if the ITR-originated Encapsulated Map-Request had a LISP-SEC signature, it is included. - The DDT Map-Server at
192.0.2.221decapsulates the DDT Map-Request and forwards the Map-Request to a registered site5 ETR for2001:db8:0501:8::/64. - The DDT Map-Server at
192.0.2.221sends a Map-Referral message for EID-prefix2001:db8:0501:8::/64, action codeMS-ACK, to the DDT Map-Resolver. - The DDT Map-Resolver receives a Map-Referral (
MS-ACK) message and dequeues the pending request for2001:db8:0501:8:4::1. - The site5 ETR for
2001:db8:0501:8::/64receives a Map-Request forwarded by the DDT Map-Server and sends a Map-Reply to ITR2 ✨
9.3. Lookup of 2001:db8:0104:2::2/128 🎀
This example shows how a DDT Map-Resolver can use a saved referral cache entry to skip the referral process and head straight to a DDT Map-Server for a prefix that's similar to one requested before. Big time efficiency energy 🔥
Here, ITR1 uses the same Map-Resolver as in the example in Section 9.1. It sends an Encapsulated Map-Request for 2001:db8:0104:2::2 to that (DDT) Map-Resolver. The DDT Map-Resolver finds an MS-REFERRAL cache entry for 2001:db8:0100::/40 with RLOC set (192.0.2.101) and then does this 💜
- Sends a DDT Map-Request (for
2001:db8:0104:2::2) to192.0.2.101; if the ITR-originated Encapsulated Map-Request had a LISP-SEC signature, it is included. - The DDT Map-Server at
192.0.2.101decapsulates the DDT Map-Request and forwards the Map-Request to a registered site2 ETR for2001:db8:0104::/48. - The DDT Map-Server at
192.0.2.101sends a Map-Referral message for EID-prefix2001:db8:0104::/48, action codeMS-ACK, to the DDT Map-Resolver. - The DDT Map-Resolver receives the Map-Referral (
MS-ACK) and dequeues the pending request for2001:db8:0104:2::2. - The site2 ETR for
2001:db8:0104::/48receives a Map-Request and sends a Map-Reply to ITR1 🌸
9.4. Lookup of 2001:db8:0500:2:4::1/128 ✨
Okay so bestie, this example shows how a DDT Map-Resolver uses a saved referral cache entry to start the referral process at a non-root, intermediate DDT node 💅. It's for a prefix that's similar to one that was requested earlier. The vibe is "I already know the neighbourhood, so I don't need to ask the root for directions" 🗺️🦋.
In this case, ITR2 uses the same Map-Resolver as in the example in Section 9.2. It sends an Encapsulated Map-Request for 2001:db8:0500:2:4::1 to that (DDT) Map-Resolver, which finds a NODE-REFERRAL cache entry for 2001:db8:0500::/40 with RLOC set (192.0.2.201). Here's how it goes down 🌸:
- Send a DDT Map-Request (for 2001:db8:0500:2:4::1) to 192.0.2.201.
- Receive (and save in the referral cache) the Map-Referral for EID-prefix 2001:db8:0500::/48, action code MS-REFERRAL, RLOC set (192.0.2.211). Saved for later, obviously 🧠.
- Send a DDT Map-Request to 192.0.2.211; if the ITR-originated Encapsulated Map-Request had a LISP-SEC signature, it is included 🔐.
- The DDT Map-Server at 192.0.2.211 decapsulates the DDT Map-Request and forwards the Map-Request to a registered site4 ETR for 2001:db8:0500:2::/64 🎀.
- The DDT Map-Server at 192.0.2.211 sends a Map-Referral message for EID-prefix 2001:db8:0500:2::/64, action code MS-ACK, to the DDT Map-Resolver 💜.
- The DDT Map-Resolver receives the Map-Referral (MS-ACK) and dequeues the pending request for 2001:db8:0500:2:4::1 ✅.
- The site4 ETR for 2001:db8:0500:2::/64 receives a Map-Request and sends a Map-Reply to ITR2 🥳.
9.5. Lookup of 2001:db8:0500::1/128 (Nonexistent EID) 🙈
This example uses the cached MS-REFERRAL for 2001:db8:0500::/48 that we learned above to start the lookup at the DDT Map-Server at 192.0.2.211. It's giving "skip the middleman" energy 🧚. The DDT Map-Resolver proceeds like this:
- Send a DDT Map-Request (for 2001:db8:0500::1) to 192.0.2.211; if the ITR-originated Encapsulated Map-Request had a LISP-SEC signature, it is included 🔏.
- The DDT Map-Server at 192.0.2.211, which is authoritative for 2001:db8:0500::/48, does not have a matching delegation for 2001:db8:0500::1. So it responds with a Map-Referral message for 2001:db8:0500::/64, action code DELEGATION-HOLE, to the DDT Map-Resolver 🕳️. The prefix 2001:db8:0500::/64 is used because it is the least-specific prefix that does match the requested EID but does not match one of the configured delegations (2001:db8:0500:1::/64 and 2001:db8:0500:2::/64). Okay that's a lot, but it's the "not me, not this one" prefix 💀.
- The DDT Map-Resolver receives the delegation, adds a negative referral cache entry for 2001:db8:0500::/64, dequeues the pending request for 2001:db8:0500::1, and returns a Negative Map-Reply to ITR2 🫶.
10. Securing the Database and Message Exchanges 🔐👑
This section specifies the DDT security architecture that provides data origin authentication, data integrity protection, and XEID-prefix delegation 🛡️. Global XEID-prefix authorization is out of scope for this document, so that's a whole other slay for another day 💅.
Each DDT node is configured with one or more public/private key pairs that are used to digitally sign Map-Referral Records for XEID-prefix(es) for which the DDT node is authoritative. In other words, each public/private key pair is associated with the combination of a DDT node and an XEID-prefix for which it is authoritative 🎀. Every DDT node is also configured with the public keys of its child DDT nodes. By including the public keys of target child DDT nodes in the Map-Referral Records and signing each Record with the DDT node's private key, a DDT node can securely delegate sub-prefixes of its authoritative XEID-prefixes to its child DDT nodes 🌈. A DDT node configured to provide hints must also have the public keys of the DDT nodes to which its hints point. DDT node keys can be encoded using LCAF Type 11 to associate the key to the RLOC of the referred DDT node 🍓. If a node has more than one public key, it should sign its Records with at least one of these keys. When a node has N keys, it can sustain up to N-1 key compromises 🧁. The revocation mechanism is described in Section 10.2.1 💜.
Map-Resolvers are configured with one or more trusted public keys, referred to as "trust anchors" 🫡. Trust anchors are used to authenticate the DDT security infrastructure. Map-Resolvers can discover a DDT node's public key by either (1) having it configured as a trust anchor or (2) obtaining it from the node's parent as part of a signed Map-Referral. When a public key is obtained from a node's parent, it is considered trusted if it is signed by a trust anchor or if it is signed by a key that was previously trusted. Typically, in a Map-Resolver, the root DDT node's public keys should be configured as trust anchors 👑. Once a Map-Resolver authenticates a public key, it locally caches the key along with the associated DDT node RLOC and XEID-prefix for future use 🧠.
10.1. XEID-Prefix Delegation 🌸
In order to delegate XEID sub-prefixes to its child DDT nodes, a parent DDT node signs its Map-Referrals. Every signed Map-Referral MUST also include the public keys associated with each child DDT node. Such a signature indicates that the parent DDT node is delegating the specified XEID-prefix to a given child DDT node. The signature is also authenticating the public keys associated with the child DDT nodes, and authorizing them to be used by the child DDT nodes, to provide origin authentication and integrity protection for further delegations and mapping information of the XEID-prefix allocated to the DDT node 🦋.
As a result, for a given XEID-prefix, a Map-Resolver can form an authentication chain from a configured trust anchor (typically the root DDT node) to the leaf nodes (Map-Servers). Map-Resolvers leverage this authentication chain to verify the Map-Referral signatures while walking the DDT tree until they reach a Map-Server authoritative for the given XEID-prefix. It's a chain of trust, bestie, and it's honestly so iconic ⛓️✨.
10.2. DDT Node Operation 🛠️
Upon receiving a Map-Request, the DDT node responds with a Map-Referral as specified in Section 7. For every Record present in the Map-Referral, the DDT node also includes the public keys associated with the Record's XEID-prefix and the RLOCs of the child DDT nodes. Each Record contained in the Map-Referral is signed using the DDT node's private key 🔏.
10.2.1. DDT Public Key Revocation 💀
The node that owns a public key can also revoke that public key. For instance, if a parent DDT node advertises a public key for one of its child DDT nodes, the child DDT node can at a later time revoke that key. Since DDT nodes do not keep track of the Map-Resolvers that query them, revocation is done in a pull model, where the Map-Resolver is informed of the revocation of a key only when it queries the node that owns that key. If the parent DDT node is configured to advertise that key, the parent DDT node must also be signaled to remove the key from the Records it advertises for the child DDT node; this is necessary to avoid further distribution of the revoked key 🚫.
To securely revoke a key, the DDT node creates a new Record for the associated XEID-prefix and locator, including the revoked key with the R bit set. (See Section 4.7 of [RFC8060] for details regarding the R bit.) The DDT node must also include a signature in the Record that covers this Record; this is computed using the private key corresponding to the key being revoked. Such a Record is termed a "revocation record". By including this Record in its Map-Referrals, the DDT node informs querying Map-Resolvers about the revoked key. A digital signature computed with a revoked key can only be used to authenticate the revocation and SHOULD NOT be used to validate any data. To prevent a compromised key from revoking other valid keys, a given key can only be used to sign a revocation for that specific key; it cannot be used to revoke other keys. This prevents the use of a compromised key to revoke other valid keys as described in [RFC5011]. A revocation record MUST be advertised for a period of time equal to or greater than the TTL value of the Record that initially advertised the key, starting from the time that the advertisement of the key was stopped by removal from the parent DDT node ⏳.
10.3. Map-Server Operation 🏠
Similar to a DDT node, a Map-Server is configured with one or more public/private key pairs that it must use to sign Map-Referrals. 🔑
However, unlike DDT nodes, Map-Servers do not delegate prefixes and as a result do not need to include keys in the Map-Referrals they generate. No delegation drama here 🙅♀️.
10.4. Map-Resolver Operation 🔍
Upon receiving a Map-Referral, the Map-Resolver MUST first verify the signature(s) by using either a trust anchor or a previously authenticated public key associated with the DDT node sending the Map-Referral. If multiple authenticated keys are associated with the DDT node sending this Map-Referral, the Key Tag field (Section 6.4.1) of the signature can be used to select the correct public key for verifying the signature. If the key tag matches more than one key associated with that DDT node, the Map-Resolver MUST try to verify the signature with all matching keys. For every matching key that is found, the Map-Resolver MUST also verify that the key is authoritative for the XEID-prefix in the Map-Referral Record. If such a key is found, the Map-Resolver MUST use it to verify the associated signature in the Record. If (1) no matching key is found, (2) none of the matching keys is authoritative for the XEID-prefix in the Map-Referral Record, or (3) such a key is found but the signature is not valid, the Map-Referral Record is considered corrupted and MUST be discarded. This may be due to expired keys 🥀. The Map-Resolver MAY try other siblings of this node if there is an alternate node that is authoritative for the same prefix. If not, the Map-Resolver CAN query the DDT node's parent to retrieve a valid key. It is good practice to use a counter or timer to avoid repeating this process if the Map-Resolver cannot verify the signature after several attempts ⏱️.
Once the signature is verified, the Map-Resolver has verified the XEID-prefix delegation in the Map-Referral. This also means that public keys of the child DDT nodes were authenticated; the Map-Resolver must add these keys to the authenticated keys associated with each child DDT node and XEID-prefix. These keys are considered valid for the duration specified in the Record's TTL field 🌟.
11. Open Issues and Considerations 🤔
There are a number of issues with the organization of the mapping database that need further investigation. Among these are:
- Defining an interface to implement interconnection and/or interoperability with other mapping databases, such as LISP+ALT.
- Additional key structures for use with LISP-DDT, such as key structures to support additional EID formats as defined in [RFC8060].
- Management of the DDT Map-Resolver referral cache -- in particular, detecting and removing outdated entries.
- Best practices for either configuring hint referrals or avoiding their use.
Operational experience will help answer open questions surrounding these and other issues 📚🧁.
12. IANA Considerations 📋
IANA has made the following early assignment per this document:
- Message type 6, "LISP DDT Map-Referral", was added to the "LISP Packet Types" registry. See Section 6.4 ("Map-Referral Message Format").
As this document is an Experimental RFC, this is an early allocation as per [RFC7120] 🧪💖.
13. Security Considerations 🔐✨
okay bestie, security time 🫶 Section 10 is where the DDT security architecture lives, and it gives you data origin authentication, data integrity protection, and XEID-prefix delegation inside the DDT infrastructure. Lowkey the whole vibe of keeping the mapping system legit 💅
Global XEID-prefix authorization is out of scope for this document 🙈 but the Secure Inter-Domain Routing (SIDR) working group [RFC6480] is cooking up an infrastructure to improve the security of Internet routing. Still, it's an open question whether SIDR's Public Key Infrastructure (PKI), plus the distributed repository system it uses to store and share PKI data objects, could also be used by DDT devices to verifiably prove they're the legit holders of a set of XEID-prefixes. More work needed there, babe 🦋
This document spells out how DDT security and LISP-SEC [LISP-SEC] complement each other to secure the DDT infrastructure, Map-Referral messages, and the Map-Request/Map-Reply protocols. Other LISP security mechanisms might show up in the future to replace LISP-SEC, and if they do, they should describe how they can be used together with LISP-DDT to give similar levels of protection ✨
Here's the iykyk part 🔥 LISP-SEC can use the DDT public-key infrastructure to protect the transport of LISP-SEC key material (the One-Time Key) from a Map-Resolver to the matching Map-Server. So when LISP-SEC is deployed alongside a LISP-DDT mapping database and the path between the Map-Resolver and Map-Server needs protecting, DDT security as described in Section 10 should be enabled as well 💖
14. References 📚
14.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
- [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, <http://www.rfc-editor.org/info/rfc6830>.
- [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013, <http://www.rfc-editor.org/info/rfc6833>.
- [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <http://www.rfc-editor.org/info/rfc7120>.
- [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <http://www.rfc-editor.org/info/rfc8017>.
- [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, <http://www.rfc-editor.org/info/rfc8060>.
- [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
14.2. Informative References
- [AFI] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers/>.
- [LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, "LISP-Security (LISP-SEC)", Work in Progress, draft-ietf-lisp-sec-12, November 2016.
- [LISP-TREE] Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., and O. Bonaventure, "LISP-TREE: a DNS Hierarchy to Support the LISP Mapping System", IEEE Journal on Selected Areas in Communications, Volume 28, Issue 8, DOI 10.1109/JSAC.2010.101011, September 2010, <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5586446>.
- [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
- [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, <http://www.rfc-editor.org/info/rfc5011>.
- [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <http://www.rfc-editor.org/info/rfc6480>.
- [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, <http://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, <http://www.rfc-editor.org/info/rfc6837>.
Acknowledgments 🫶
The authors want to give a huge thank-you to Lorand Jakab, Albert Cabellos, Florin Coras, Damien Saucez, and Olivier Bonaventure for their work on LISP-TREE [LISP-TREE] and on LISP iterable mappings. That work inspired the hierarchical database structure and the lookup iteration approach described in this document 🌈
Thanks also to Dino Farinacci and Isidor Kouvelas for their implementation work 💜 to Selina Heimlich and Srin Subramanian for testing 🧚 to Fabio Maino for work on security processing 🔥 and to Job Snijders, Glen Wiley, Neel Goyal, and Mike Gibbs for work on operational considerations and the initial deployment of a prototype database infrastructure 🍓
Special shout-out to Jesper Skriver, Andrew Partan, and Noel Chiappa 👑 who all sat through (and somehow put up with) seemingly endless hours of discussion about mapping database ideas, concepts, and issues 😭
Authors' Addresses 📮
Vince Fuller
VAF.NET Internet Consulting
Email: vince.fuller@gmail.com
Darrel Lewis
Cisco Systems
Email: darlewis@cisco.com
Vina Ermagan
Cisco Systems
Email: vermagan@cisco.com
Amit Jain
Juniper Networks
Email: atjain@juniper.net
Anton Smirnov
Cisco Systems
Email: as@cisco.com📦 where this page comes from
- ietf: rfc8111 2017-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms