RFC 6830
The Locator/ID Separation Protocol (LISP)
RFC 6830: The Locator/ID Separation Protocol (LISP) 💖
okay bestie, let's get into it ✨ this is RFC 6830, and it's all about LISP, the Locator/ID Separation Protocol 🦋
- Authors: D. Farinacci, V. Fuller, D. Meyer, and D. Lewis. Farinacci, Fuller, Meyer, and Lewis all wrote it, and everyone is from Cisco Systems except Fuller, who is listed without an affiliation 🌸
- Category: Experimental 🧪
- Date: January 2013 📅
- Stream: published by the Internet Engineering Task Force (IETF) 🎀
- ISSN: 2070-1721
- Obsoletes and updates: the header doesn't list anything it obsoletes or updates 🫶
Abstract
okay so this doc describes a network-layer protocol that splits IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs) 🌈 you don't need to change host protocol stacks or the "core" of the Internet, which is so iconic 💅 LISP can be rolled out gradually, with no "flag day", and it gives early adopters Traffic Engineering, multihoming, and mobility perks, even when only a few sites are LISP-capable ✨
The whole design was mainly inspired by the problem statement from the October 2006 IAB Routing and Addressing Workshop 🧚
Status of This Memo
not gonna lie, this section is kinda serious, but here's the tea 🍓 this document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🔬
It defines an Experimental Protocol for the Internet community. It's a product of the IETF and represents the IETF community's consensus. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 for the details 💜
If you want the current status, any errata, or a way to send feedback, head to http://www.rfc-editor.org/info/rfc6830 🦋
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please review these carefully, since they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 📜
Table of Contents
1. Introduction ....................................................3
2. Requirements Notation ...........................................5
3. Definition of Terms .............................................5
4. Basic Overview .................................................10
4.1. Packet Flow Sequence ......................................13
5. LISP Encapsulation Details .....................................15
5.1. LISP IPv4-in-IPv4 Header Format ...........................16
5.2. LISP IPv6-in-IPv6 Header Format ...........................17
5.3. Tunnel Header Field Descriptions ..........................18
5.4. Dealing with Large Encapsulated Packets ...................22
5.4.1. A Stateless Solution to MTU Handling ...............22
5.4.2. A Stateful Solution to MTU Handling ................23
5.5. Using Virtualization and Segmentation with LISP ...........24
6. EID-to-RLOC Mapping ............................................25
6.1. LISP IPv4 and IPv6 Control-Plane Packet Formats ...........25
6.1.1. LISP Packet Type Allocations .......................27
6.1.2. Map-Request Message Format .........................27
6.1.3. EID-to-RLOC UDP Map-Request Message ................30
6.1.4. Map-Reply Message Format ...........................31
6.1.5. EID-to-RLOC UDP Map-Reply Message ..................35
6.1.6. Map-Register Message Format ........................37
6.1.7. Map-Notify Message Format ..........................39
6.1.8. Encapsulated Control Message Format ................41
6.2. Routing Locator Selection .................................42
6.3. Routing Locator Reachability ..............................44
6.3.1. Echo Nonce Algorithm ...............................46
6.3.2. RLOC-Probing Algorithm .............................48
6.4. EID Reachability within a LISP Site .......................49
6.5. Routing Locator Hashing ...................................49
6.6. Changing the Contents of EID-to-RLOC Mappings .............50
6.6.1. Clock Sweep ........................................51
6.6.2. Solicit-Map-Request (SMR) ..........................52
6.6.3. Database Map-Versioning ............................53
7. Router Performance Considerations ..............................54
8. Deployment Scenarios ...........................................55
8.1. First-Hop/Last-Hop Tunnel Routers .........................56
8.2. Border/Edge Tunnel Routers ................................56
8.3. ISP Provider Edge (PE) Tunnel Routers .....................57
8.4. LISP Functionality with Conventional NATs .................58
8.5. Packets Egressing a LISP Site .............................58
9. Traceroute Considerations ......................................58
9.1. IPv6 Traceroute ...........................................59
9.2. IPv4 Traceroute ...........................................60
9.3. Traceroute Using Mixed Locators ...........................60
10. Mobility Considerations .......................................61
10.1. Site Mobility ............................................61
10.2. Slow Endpoint Mobility ...................................61
10.3. Fast Endpoint Mobility ...................................61
10.4. Fast Network Mobility ....................................63
10.5. LISP Mobile Node Mobility ................................64
11. Multicast Considerations ......................................64
12. Security Considerations .......................................65
13. Network Management Considerations .............................67
14. IANA Considerations ...........................................67
14.1. LISP ACT and Flag Fields .................................67
14.2. LISP Address Type Codes ..................................68
14.3. LISP UDP Port Numbers ....................................68
14.4. LISP Key ID Numbers ......................................68
15. Known Open Issues and Areas of Future Work ....................68
16. References ....................................................70
16.1. Normative References .....................................70
16.2. Informative References ...................................71
Appendix A. Acknowledgments .......................................741. Introduction ✨
okay so LISP is the Locator/Identifier Separation Protocol 🎀 It gives routers a set of functions for swapping info that maps Endpoint Identifiers (EIDs), which aren't globally routable, to routable Routing Locators (RLOCs) 🦋 It also has a mechanism that lets these LISP routers wrap up IP packets addressed with EIDs, so they can travel across network infrastructure that routes on RLOCs 🌸
LISP was born from chats at the IAB-sponsored Routing and Addressing Workshop in Amsterdam in October 2006 (see [RFC4984]) 🧚 The big takeaway was that the Internet's routing and addressing system wasn't scaling well with all the explosive growth of new sites. One reason is the rising number of multihomed sites, plus other sites that can't be addressed as part of topology-based or provider-based aggregated prefixes 💅 More detail on the problem statement is in [RADIR] 📜
A basic observation from early networking research, like the work in [CHIAPPA] and [RFC4984], is that using a single address field to both identify a device and figure out where it sits topologically means you're optimizing along two clashing axes 🙈 For routing to be efficient, addresses have to be assigned topologically. But for devices to be managed easily, without renumbering every time the topology changes (like adding or removing attachment points, or mobility events), addresses have to be explicitly not tied to topology 💀
So LISP's answer to the routing scalability problem is to replace IP addresses with two new kinds of numbers 💖 Routing Locators (RLOCs) are assigned topologically to network attachment points, so they can be aggregated, and they're what gets used for routing and forwarding packets through the network 🌈 Endpoint Identifiers (EIDs) are assigned independently of the network topology, used for numbering devices, and aggregated along administrative boundaries ⭐ LISP then defines functions for mapping between the two spaces, and for encapsulating traffic from devices that use non-routable EIDs so it can cross an infrastructure that routes and forwards using RLOCs 🎀 Both are syntactically identical to IP addresses. What's different is how they're used 🫶
This document describes the protocol that does all of this 🦋 The database that stores EID-to-RLOC mappings is explicitly a separate "module", so people can experiment with lots of different approaches 🧪 One database design being developed for experimentation as part of the LISP working group's work is [RFC6836]. Others that have been described include [CONS], [EMACS], and [RFC6837] 🌸 Finally, [RFC6833] documents a general-purpose service interface for accessing a mapping database. It's meant to make the database modular, so different approaches can be tried without modifying installed LISP-capable devices in LISP sites 💜
This experimental spec has areas that need more experience and measurement 🔬 It is NOT RECOMMENDED for deployment beyond experimental situations. Results from experimentation may lead to changes and enhancements to the protocol mechanisms defined here. See Section 15 for the specific known issues that still need work during development, implementation, and experimentation 🍓
An examination of what LISP means for Internet traffic, applications, routers, and security is future study 🔮 That analysis will explain what role LISP can play in scalable routing, and it'll also look at the scalability and the levels of state needed for encapsulation, decapsulation, liveness, and so on 🧚
2. Requirements Notation 💜
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀 these are the BCP 14 words, and they carry the exact same force here as they do in [RFC2119] 🫶
3. Definition of Terms 🦋
next up: the definitions! 🧚💖
Provider-Independent (PI) Addresses: okay so PI addresses come from a pool where the blocks aren't tied to any particular spot in the network (like one specific service provider) 🌸. That means they're not topologically aggregatable in the routing system, which is a whole vibe 💅.
Provider-Assigned (PA) Addresses: PA addresses are an address block that each service provider gives to a site it connects to 🎀. Usually each block is a sub-block of a service provider Classless Inter-Domain Routing (CIDR) [RFC4632] block, and it gets aggregated into the bigger block before it's advertised into the global Internet ✨. Traditionally, IP multihoming meant every multihomed site grabbed its own globally visible prefix 😭. LISP only uses topologically assigned and aggregatable address blocks for RLOCs, which kills off this demonstrably non-scalable practice 💀🔥.
Routing Locator (RLOC): an RLOC is an IPv4 [RFC0791] or IPv6 [RFC2460] address of an Egress Tunnel Router (ETR) 🧚. It's the output of an EID-to-RLOC mapping lookup, and one EID can map to one or more RLOCs 🦋. Typically, RLOCs are numbered from topologically aggregatable blocks that get assigned to a site at each point where it attaches to the global Internet. Where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses 🌈. Multiple RLOCs can be assigned to the same ETR device, or to multiple ETR devices at a site 🍓.
Endpoint ID (EID): an EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value that lives in the source and destination address fields of the first (most inner) LISP header of a packet ✨. The host gets a destination EID the same way it gets a destination address today, like through a Domain Name System (DNS) [RFC1034] lookup or a Session Initiation Protocol (SIP) [RFC3261] exchange 📞. The source EID comes from the existing mechanisms that set a host's "local" IP address 🫶. An EID used on the public Internet has to have the same properties as any other IP address used that way. Among other things, that means it must be globally unique 👑. An EID is allocated to a host from an EID-Prefix block tied to the site where the host is located 🏡. An EID can also be used by a host to refer to other hosts 💜.
EIDs MUST NOT be used as LISP RLOCs. Not me using an EID as an RLOC, that's a no-go 🙈.
Note that EID blocks MAY be assigned in a hierarchical manner, independent of the network topology, which helps the mapping database scale 📈. Also, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site, and that structure is not visible to the global routing system 🤫. In theory, the bit string that represents an EID for one device can represent an RLOC for a different device 🌀. As the architecture gets realized, if a given bit string is both an RLOC and an EID, it must refer to the same entity in both cases 💅. When you're talking with other Locator/ID separation proposals, a LISP EID gets called an "LEID". Throughout this document, any reference to "EID" means an LEID 🦋.
EID-Prefix: an EID-Prefix is a power-of-two block of EIDs that an address allocation authority allocates to a site 🌸. EID-Prefixes are associated with a set of RLOC addresses that make up a "database mapping" 🧁. EID-Prefix allocations can be broken up into smaller blocks when an RLOC set is going to be associated with the larger EID-Prefix block 🍰. A globally routed address block (whether PI or PA) is not inherently an EID-Prefix, but a globally routed address block MAY be used by its assignee as an EID block 🎀. The converse is not supported. A site that receives an explicitly allocated EID-Prefix may not use that EID-Prefix as a globally routed prefix 🙅♀️. Doing that would require coordination and cooperation with the entities managing the mapping infrastructure. Once that's been done, the block could be removed from the globally routed IP system, if other suitable transition and access mechanisms are in place ✨. You can find talk about those transition and access mechanisms in [RFC6832] and [LISP-DEPLOY] 📚.
End-system: an end-system is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header 💻. When it's communicating globally (that is, outside of its routing domain), the end-system supplies an EID value for the destination address field of the IP header 🌍. An end-system can be a host computer, a switch or router device, or any network appliance 🖥️.
Ingress Tunnel Router (ITR): an ITR is a router that lives in a LISP site 🏠. Packets sent by sources inside the LISP site to destinations outside of it are candidates for encapsulation by the ITR 🎁. The ITR treats the IP destination address as an EID and performs an EID-to-RLOC mapping lookup 🔍. Then the router prepends an "outer" IP header, with one of its globally routable RLOCs in the source address field and the result of the mapping lookup in the destination address field 💌. Note that this destination RLOC MAY be an intermediate, proxy device that has better knowledge of the EID-to-RLOC mapping closer to the destination EID 🧭. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side 🌊.
Specifically, when a service provider prepends a LISP header for Traffic Engineering purposes, the router doing that is also regarded as an ITR 🛣️. The outer RLOC the ISP ITR uses can be based on the outer destination address (the originating ITR's supplied RLOC) or on the inner destination address (the originating host's supplied EID) 🎯.
TE-ITR: a TE-ITR is an ITR deployed in a service provider network that prepends an additional LISP header for Traffic Engineering purposes 🚦.
Egress Tunnel Router (ETR): an ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs 📥. The router strips the "outer" header and forwards the packet based on the next IP header it finds 🎈. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side 🫧. ETR functionality doesn't have to be limited to a router device, either. A server host can be the endpoint of a LISP tunnel as well 🖥️💖.
TE-ETR: a TE-ETR is an ETR deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes 🌟.
xTR: an xTR is a reference to an ITR or ETR when the direction of data flow isn't part of the context description 🤷♀️. "xTR" refers to the router that is the tunnel endpoint, and it's used synonymously with the term "Tunnel Router" 🦋. For example, "An xTR can be located at the Customer Edge (CE) router" means both ITR and ETR functionality at the CE router 🏢.
LISP Router: a LISP router is a router that performs the functions of any or all of the following: ITR, ETR, Proxy-ITR (PITR), or Proxy-ETR (PETR) 🧚♀️.
EID-to-RLOC Cache: the EID-to-RLOC Cache is a short-lived, on-demand table in an ITR. It stores, tracks, and is responsible for timing out and otherwise validating EID-to-RLOC mappings ⏳. It's distinct from the full "database" of EID-to-RLOC mappings. It's dynamic, local to the ITR(s), and relatively small, while the database is distributed, relatively static, and much more global in scope 🌐.
EID-to-RLOC Database: the EID-to-RLOC Database is a global distributed database that contains all known EID-Prefix-to-RLOC mappings 🗺️. Each potential ETR typically holds a small piece of the database: the EID-to-RLOC mappings for the EID-Prefixes "behind" the router 🧩. Those map to one of the router's own globally visible IP addresses 📍.
The same database mapping entries MUST be configured on all ETRs for a given site. In a steady state, the EID-Prefixes for the site and the Locator-Set for each EID-Prefix MUST be the same on all ETRs. Procedures to enforce and/or verify this are outside the scope of this document, so no spoilers here 🙊.
Note that there MAY be transient conditions when the EID-Prefix for the site and the Locator-Set for each EID-Prefix may not be the same on all ETRs 🌤️. This has no negative implications, since a partial set of Locators can be used 💖.
Recursive Tunneling: Recursive Tunneling occurs when a packet has more than one LISP IP header 🪆. Additional layers of tunneling MAY be employed to implement Traffic Engineering or other re-routing as needed. When this is done, an additional "outer" LISP header is added, and the original RLOCs are preserved in the "inner" header 🧅. Any references to tunnels in this specification refer to dynamic encapsulating tunnels. They are never statically configured 🎀.
Re-encapsulating Tunnels: Re-encapsulating Tunneling occurs when an ETR removes a LISP header, then acts as an ITR to prepend another LISP header 🔁. Doing this lets a packet be re-routed by the re-encapsulating router without adding the overhead of additional tunnel headers 🦋. Any references to tunnels in this specification refer to dynamic encapsulating tunnels, and they are never statically configured 💅. When using multiple mapping database systems, care must be taken not to create re-encapsulation loops through misconfiguration 🌀⚠️.
LISP Header: LISP header is a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-octet header that follows the UDP header and that an ITR prepends or an ETR strips 🎁✨.
Address Family Identifier (AFI): AFI is a term used to describe an address encoding in a packet 🏷️. An address family currently pertains to an IPv4 or IPv6 address. See [AFI] and [RFC3232] for details 📖. An AFI value of 0 used in this specification indicates an unspecified encoded address, where the length of the address is 0 octets following the 16-bit AFI value of 0 🫥.
Negative Mapping Entry: a negative mapping entry, also known as a negative cache entry, is an EID-to-RLOC entry where an EID-Prefix is advertised or stored with no RLOCs 🚫. That is, the Locator-Set for the EID-to-RLOC entry is empty or has an encoded Locator count of 0 🫙. This type of entry could be used to describe a prefix from a non-LISP site, which is explicitly not in the mapping database 🙃. There's a set of well-defined actions encoded in a Negative Map-Reply (Section 6.1.5) 🫶💜.
Data-Probe 🧚: a Data-Probe is a LISP-encapsulated data packet where the inner-header destination address matches the outer-header destination address that triggered a Map-Reply from a decapsulating ETR. The original packet also gets decapsulated and delivered to the destination host if the destination EID falls inside the EID-Prefix range configured on that ETR. If it doesn't, the packet gets discarded 🗑️. Some mapping database designs use Data-Probes to "probe" or request a Map-Reply from an ETR, and others use Map-Requests instead, so check each mapping database design for the details 📚. When you use Data-Probes, EID-Prefixes have to be advertised by sending Map-Requests on the underlying routing system, but this is discouraged if the core is supposed to scale by storing fewer EID-Prefixes in the core router routing tables 🙈.
Proxy-ITR (PITR) 💅: a PITR is defined and described in [RFC6832]. It acts like an ITR, but it does that on behalf of non-LISP sites that send packets to destinations at LISP sites 🌸.
Proxy-ETR (PETR) 🫶: a PETR is defined and described in [RFC6832]. It acts like an ETR, but it does that on behalf of LISP sites that send packets to destinations at non-LISP sites 🦋.
Route-returnability 🔥: this one is an assumption that the underlying routing system will deliver packets to the destination. When it's combined with a nonce that a sender provides and a receiver returns, it limits off-path data insertion, which is so important 😭. The route-returnability check is verified when a message gets sent with a nonce, another message comes back with that same nonce, and the destination of the original message shows up as the source of the returned message ✨.
LISP site 🏠: a LISP site is a set of routers in an edge network that are under a single technical administration. The LISP routers that live in the edge network are the demarcation points that separate the edge network from the core network 🌈.
Client-side 💜: this term in the document means a connection initiation attempt by an EID. The ITR(s) at the LISP site are the first to get involved in getting database Map-Cache entries by sending Map-Request messages 🎀.
Server-side 👑: this term means that a connection initiation attempt is being accepted for a destination EID. The ETR(s) at the destination LISP site are the first to send Map-Replies to the source site that's starting the connection 💖. The ETR(s) at that destination site can get mappings by gleaning information from Map-Requests, Data-Probes, or encapsulated packets 🧠.
Locator-Status-Bits (LSBs) 🚦: these bits are present in the LISP header. ITRs use them to tell ETRs about the up/down status of all the ETRs at the local site. They're only a hint for conveying up/down router status, not path reachability status, so be careful with them 🙈. The LSBs can be verified with one of the Locator reachability algorithms described in Section 6.3 ✅.
Anycast Address 🌍: in this document, this term means the same IPv4 or IPv6 address configured and used on multiple systems at the same time. An EID or RLOC can be an anycast address in its own address space 🦋.
4. Basic Overview ✨
Okay so the key concept of LISP is that end-systems (hosts) work the exact same way they do today 💖. The IP addresses hosts use for tracking sockets and connections, and for sending and receiving packets, don't change at all. In LISP terminology, these IP addresses are called Endpoint Identifiers (EIDs) 🎀.
Routers keep forwarding packets based on IP destination addresses 🚀. When a packet is LISP encapsulated, those addresses are called Routing Locators (RLOCs) 🧚. Most routers along a path between two hosts won't change at all. They keep doing routing and forwarding lookups on the destination addresses 💅. For routers between the source host and the ITR, and for routers from the ETR to the destination host, the destination address is an EID. For routers between the ITR and the ETR, the destination address is an RLOC 🌸.
Another key LISP concept is the "Tunnel Router" 🚇. A Tunnel Router prepends LISP headers on host-originated packets and strips them before final delivery to their destination. The IP addresses in this "outer header" are RLOCs 🦋. During end-to-end packet exchange between two Internet hosts, an ITR prepends a new LISP header to each packet, and an ETR strips that new header off. The ITR does EID-to-RLOC lookups to figure out the routing path to the ETR, which has the RLOC as one of its IP addresses 🗺️.
Some basic rules governing LISP are:
- End-systems (hosts) only send to addresses that are EIDs 💁. They don't know whether an address is an EID or an RLOC, but they assume packets get to their intended destinations 🤞. In a system where LISP is deployed, LISP routers intercept EID-addressed packets and help deliver them across the network core, where EIDs can't be routed 🛤️. The procedure a host uses to send IP packets doesn't change 😌.
- EIDs are always IP addresses assigned to hosts 🧑💻.
- LISP routers mostly deal with Routing Locator addresses. See Section 4.1 for what "mostly" really means 🙈.
- RLOCs are always IP addresses assigned to routers, preferably topologically oriented addresses from provider CIDR (Classless Inter-Domain Routing) blocks 🧱.
- Router-originated packets: when a router originates packets, it can use either an EID or an RLOC as the source address 🔀. When it's acting as a host (for example, when it's terminating a transport session such as Secure SHell (SSH), TELNET, or the Simple Network Management Protocol (SNMP)), it can use an EID that's explicitly assigned for that purpose 💻. An EID that identifies the router as a host MUST NOT be used as an RLOC 🚫. An EID is only routable within the scope of a site 🏡. A typical BGP configuration might show this "hybrid" EID/RLOC usage, where a router uses its "host-like" EID to terminate iBGP sessions to other routers in a site, while at the same time using RLOCs to terminate eBGP sessions to routers outside the site 🌈.
- Unwrapped EID packets: packets with EIDs in them aren't expected to be delivered end-to-end without an EID-to-RLOC mapping operation 🙅. They're expected to be used locally for intra-site communication, or to be encapsulated for inter-site communication 📦.
- EID-Prefixes are likely to be assigned hierarchically, in a way that's optimized for administrative convenience and for helping the EID-to-RLOC mapping database scale 📈. The hierarchy is based on an address allocation hierarchy that's independent of the network topology 🧩.
- Subnetting EIDs: EIDs may also be structured (subnetted) in a way that's suitable for local routing within an Autonomous System (AS) 🍓.
An additional LISP header MAY be prepended to packets by a TE-ITR when re-routing the path for a packet is desired 🛣️. A potential use case would be an ISP router that needs to do Traffic Engineering for packets flowing through its network 💼. In this situation, called "Recursive Tunneling", an ISP transit acts as an additional ITR. The RLOC it uses for the new prepended header would be either a TE-ETR inside the ISP (along an intra-ISP traffic engineered path) or a TE-ETR inside another ISP (an inter-ISP traffic engineered path, where an agreement to build that path exists) 🤝.
To avoid excessive packet overhead and possible encapsulation loops 🔁, this document mandates that a maximum of two LISP headers can be prepended to a packet. For initial LISP deployments, it's assumed two headers are enough: the first prepended header is used at a site for Location/Identity separation, and the second is used inside a service provider for Traffic Engineering purposes 💫.
Tunnel Routers can be placed pretty flexibly in a multi-AS topology 🗺️. For example, the ITR for a particular end-to-end packet exchange might be the first-hop or default router within a site for the source host. Similarly, the ETR might be the last-hop router directly connected to the destination host. Another example, maybe for a VPN service outsourced to an ISP by a site, is that the ITR could be the site's border router at the service provider attachment point 🏢. Mixing and matching site-operated, ISP-operated, and other Tunnel Routers is allowed for maximum flexibility 💖. See Section 8 for more details 🧚♀️.
4.1. Packet Flow Sequence ✨
okay bestie, let's walk through a whole unicast packet flow 🦋 Here's the setup we're working with:
- Source host
host1.abc.example.comis sending a packet tohost2.xyz.example.com, which is exactly what host1 would do if the site was not using LISP. - Each site is multihomed, so each Tunnel Router has an address (RLOC) assigned from the service provider address block for each provider that particular Tunnel Router is attached to. 🌸
- The ITR(s) and ETR(s) are directly connected to the source and destination, respectively, but the source and destination can be located anywhere in the LISP site.
- Map-Requests can be sent on the underlying routing system topology, to a mapping database system, or directly over an Alternative Logical Topology [RFC6836]. A Map-Request is sent for an external destination when the destination is not found in the forwarding table or matches a default route. 💅
- Map-Replies are sent on the underlying routing system topology.
Now, client host1.abc.example.com wants to chat with server host2.xyz.example.com. Here's how it goes down:
- host1 wants to open a TCP connection to host2, so it does a DNS lookup on
host2.xyz.example.com. An A/AAAA record comes back, and that address becomes the destination EID. host1's own locally assigned address is used as the source EID. Then an IPv4 or IPv6 packet gets built and forwarded through the LISP site like a totally normal IP packet until it reaches a LISP ITR. 🧚 - The LISP ITR must be able to map the destination EID to an RLOC of one of the ETRs at the destination site. ngl, the specific method for doing this isn't covered in this example, so check out [RFC6836] or [CONS] for possible solutions. 🤓
- The ITR sends a LISP Map-Request. Map-Requests SHOULD be rate-limited. 🚦
- If there's no alternate mapping system in use, the Map-Request gets routed through the underlying routing system. Otherwise, it gets routed on an alternate logical topology, like the [RFC6836] database mapping system. Either way, once the Map-Request reaches one of the ETRs at the destination site, that ETR processes it as a control message. 📬
- The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in its configured EID-to-RLOC mapping database. That's the list of EID-Prefixes the ETR supports for the site it lives in. If there's no match, the Map-Request is dropped. If there is a match, a LISP Map-Reply is returned to the ITR. 🙈
- The ITR receives the Map-Reply, parses it (to check for format validity), and stores the mapping information from the packet in its EID-to-RLOC mapping cache. Heads up: the map-cache is an on-demand cache. An ITR manages its map-cache in whatever way optimizes for its resource constraints. 🧠
- Subsequent packets from host1 to host2 get a LISP header prepended by the ITR, using the appropriate RLOC learned from the ETR as the LISP header destination address. Lowkey, the packet MAY be sent to a different ETR than the one that returned the Map-Reply, because of the source site's hashing policy or the destination site's Locator-Set policy. 🔀
- The ETR receives these packets directly (since the destination address is one of its assigned IP addresses), checks the validity of the addresses, strips the LISP header, and forwards the packets to the attached destination host. Slay 👑
In order to defer the need for a mapping lookup in the reverse direction, an ETR MAY create a cache entry that maps the source EID (inner-header source IP address) to the source RLOC (outer-header source IP address) in a received LISP packet. This is called a "gleaned" mapping, and it only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. And both the ITR and the ETR can influence the decision the other makes when selecting an RLOC. See Section 6 for more details. 🫶
5. LISP Encapsulation Details ✨
Okay, so here's the thing: since extra tunnel headers get prepended, the packet gets bigger and can exceed the MTU of any link traversed from the ITR to the ETR. 😭 It is RECOMMENDED in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet is dropped and an ICMP Too Big message is returned to the source.
This specification RECOMMENDS that implementations provide support for one of the proposed fragmentation and reassembly schemes. Two existing schemes are detailed in Section 5.4. 🧩
Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner header is in IPv4 packet format and the outer header is in IPv6 packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header is in IPv6 packet format and the outer header is in IPv4 packet format). The next sub-sections illustrate packet formats for the homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 combinations MUST be supported. 💖
5.1. LISP IPv4-in-IPv4 Header 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL |Type of Service| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OH | Time to Live | Protocol = 17 | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source Routing Locator |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|flags| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL |Type of Service| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH | Time to Live | Protocol | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source EID |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IHL = IP-Header-Length5.2. LISP IPv6-in-IPv6 Header 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| Traffic Class | Flow Label |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Payload Length | Next Header=17| Hop Limit |
v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
O + +
u | |
t + Source Routing Locator +
e | |
r + +
| |
H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d | |
r + +
| |
^ + Destination Routing Locator +
| | |
\ + +
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|flags| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| Traffic Class | Flow Label |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Payload Length | Next Header | Hop Limit |
v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
I + +
n | |
n + Source EID +
e | |
r + +
| |
H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d | |
r + +
| |
^ + Destination EID +
\ | |
\ + +
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5.3. Tunnel Header Field Descriptions 🎀
okay so this is where we get into the nitty gritty of every header field 🧚 the vibe is all about who's who in the packet, so let's go! 💅
Inner Header (IH): this is the header on the datagram that the originating host sent 🌸 its source and destination IP addresses are EIDs [RFC0791] [RFC2460].
Outer Header (OH): this is a brand new header that an ITR slaps on the front 🦋 its address fields hold RLOCs pulled from the ingress router's EID-to-RLOC Cache. the IP protocol number is UDP (17) from [RFC0768]. how the Don't Fragment (DF) bit in the 'Flags' field gets set follows the rules in Sections 5.4.1 and 5.4.2 💖
UDP Header: this one carries a source port that the ITR picked when it encapsulated the packet ✨ see Section 6.5 for how that source port gets chosen from a hash of the inner header's 5-tuple. the destination port MUST be set to the well-known IANA-assigned port value 4341. no exceptions bestie 🫶
UDP Checksum: okay this one is a whole thing 😭 an ITR SHOULD send the UDP Checksum field as zero, whether it's IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS] [UDP-ZERO]. when an ETR gets a packet with a zero UDP checksum, it MUST accept that packet for decapsulation. if an ITR sends a non-zero value, it MUST send a correctly computed value in this field. when an ETR gets a packet with a non-zero UDP checksum, it MAY decide to verify the value 🔥 if it does verify and the check fails, the packet MUST be silently dropped. if the ETR skips the verification, or the verification passes, the packet MUST be accepted for decapsulation. ngl the way the whole IETF is still debating how UDP checksums work for every tunneling protocol, LISP included, is so real 💀 once that conversation wraps up, any needed changes will be made so LISP lines up with the outcome 🌈
UDP Length: for an IPv4-encapsulated packet, the UDP Length field is the inner-header IPv4 Total Length plus the UDP and LISP header lengths 🍓 for an IPv6-encapsulated packet, it's the inner-header IPv6 Payload Length plus the size of the IPv6 header (40 octets) plus the size of the UDP and LISP headers 🧮
N: the N-bit is the nonce-present bit 💜 when it's set to 1, the low-order 24 bits of the first 32 bits of the LISP header hold a Nonce. see Section 6.3.1 for the details. both N- and V-bits MUST NOT be set in the same packet. if they somehow are, a decapsulating ETR MUST treat the Nonce/Map-Version field as having a Nonce value present 🙈
L: the L-bit is the Locator-Status-Bits field enabled bit ✨ when it's set to 1, the Locator-Status-Bits in the second 32 bits of the LISP header are in use 👑
x 1 x x 0 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E: the E-bit is the echo-nonce-request bit 🦋 this bit MUST be ignored and has no meaning when the N-bit is set to 0. when the N-bit is 1 and this bit is also 1, the ITR is asking for the nonce value in the Nonce field to be echoed back in LISP-encapsulated packets when the ITR is also an ETR. see Section 6.3.1 for details 🫶
V: the V-bit is the Map-Version present bit 🌸 when it's set to 1, the N-bit MUST be 0. check out Section 6.6.3 for more details. this bit also means the LISP header is encoded like this:
0 x 0 1 x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Source Map-Version | Dest Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+I: the I-bit is the Instance ID bit 💖 see Section 5.5 for more details. when this bit is 1, the Locator-Status-Bits field shrinks down to 8 bits, and the high-order 24 bits are used as an Instance ID 🧚 if the L-bit is 0, the low-order 8 bits are sent as zero and ignored on receipt. the LISP header then looks like this:
x x x x 1 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | LSBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+flags: the flags field is a 3-bit field saved for future flag use 🔮 it MUST be set to 0 on transmit and MUST be ignored on receipt. no touching!
LISP Nonce: the Nonce field is a 24-bit value that an ITR randomly generates when the N-bit is set to 1 🎲 how it gets generated is an implementation matter, but the algorithms are REQUIRED to generate different nonces when sending to different destinations. hmm wait, careful, that's not a BCP word here, so I'll say it plainly: the algorithms are required to make different nonces for different destinations 🫶 the same nonce CAN be reused for a while to the same destination. the nonce is also used when the E-bit asks for the nonce to be echoed back by the other side when packets come back 🦋 when the E-bit is clear but the N-bit is set, a remote ITR is either echoing a nonce that was requested earlier, or it's giving a random nonce. see Section 6.3.1 for more 💅
LISP Locator-Status-Bits (LSBs): when the L-bit is also set, an ITR fills in the Locator-Status-Bits field to tell an ETR the up/down status of the Locators at the source site 🌈 each RLOC in a Map-Reply gets an ordinal value from 0 to n-1 (when a mapping entry has n RLOCs). the Locator-Status-Bits are numbered 0 to n-1 starting from the least significant bit of the field. the field is 32 bits when the I-bit is 0 and 8 bits when the I-bit is 1. when a Locator-Status-Bit is set to 1, the ITR is telling the ETR that the RLOC matching that bit's ordinal is up ⭐ see Section 6.3 for how an ITR can figure out the status of the ETRs at the same site. when a site has several EID-Prefixes that lead to several mappings (each one possibly with a different Locator-Set), the Locator-Status-Bits in an encapsulated packet MUST reflect the mapping for the EID-Prefix that the inner-header source EID address matches. and if the LSB for an anycast Locator is 1, there's at least one RLOC with that address, and the ETR counts as 'up' 🎀
When doing ITR/PITR encapsulation:
- The outer-header 'Time to Live' field (or 'Hop Limit' field, for IPv6) SHOULD be copied from the inner-header 'Time to Live' field 🕰️
- The outer-header 'Type of Service' field (or the 'Traffic Class' field, for IPv6) SHOULD be copied from the inner-header 'Type of Service' field, with one exception (see below) 💖
When doing ETR/PETR decapsulation:
- The inner-header 'Time to Live' field (or 'Hop Limit' field, for IPv6) SHOULD be copied from the outer-header 'Time to Live' field, but only when the outer header's Time to Live value is less than the inner header's 💫 skipping this check can make the inner header's Time to Live keep going up across encapsulation and decapsulation cycles 😭 this check also happens during the first encapsulation, when a packet reaches an ITR or PITR headed for a LISP site.
- The inner-header 'Type of Service' field (or the 'Traffic Class' field, for IPv6) SHOULD be copied from the outer-header 'Type of Service' field, with one exception (see below) 🌸
Here's a little heads up 🙈 if an ETR/PETR is also an ITR/PITR and it decides to re-encapsulate after decapsulating, the new outer header ends up with the same Time to Live as the old outer header minus 1.
Copying the Time to Live (TTL) does two jobs 🧚 first, it keeps the distance the host meant the packet to travel. second, and this is the iconic one, it stops looping packets in case there's a loop of concatenated tunnels because of a misconfiguration 🔁 see Section 9.3 for the TTL exception handling for traceroute packets.
The Explicit Congestion Notification ('ECN') field takes up bits 6 and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic Class' field [RFC3168] 🦋 it needs special handling so that congestion signals don't get thrown away [RFC3168]. an ITR's encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header. if the 'ECN' field has a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header, the one used to forward the packet past the ETR 🔥 these requirements keep CE indications alive when an ECN packet crosses a LISP tunnel and gets marked CE because of congestion between the tunnel endpoints 👑
5.4. Dealing with Large Encapsulated Packets 🍓
this section proposes two mechanisms for packets that go over the path MTU between the ITR and ETR 📏
it's up to the implementor to pick the stateless or the stateful mechanism 🧠 you can use both, or neither, because how an ITR handles MTU issues is a local decision, and sites can interoperate even if they use different mechanisms 🫶
both the stateless and stateful mechanisms also apply to Re-encapsulating and Recursive Tunneling, so any actions below that mention an ITR also apply to a TE-ITR 💅
5.4.1. A Stateless Solution to MTU Handling ✨
Okay bestie, the stateless MTU fix is so clean 🫶. An ITR (the ingress tunnel router that does the encapsulating) can handle MTU issues without keeping any extra memory about paths. Here's how it goes:
- Define H to be the size, in octets, of the outer header an ITR prepends to a packet. This includes the UDP and LISP header lengths. 💅
- Define L to be the size, in octets, of the maximum-sized packet an ITR can send to an ETR without the need for the ITR or any intermediate routers to fragment the packet. 🦋
- Define an architectural constant S for the maximum size of a packet, in octets, an ITR must receive so the effective MTU can be met. That is,
S = L - H. ✨
So when an ITR gets a packet from a site-facing interface and the encapsulation pushes it to a size greater than L octets, the ITR first splits the original packet into 2 equal-sized fragments 🔪. Then it slaps a LISP header onto each fragment. Each encapsulated fragment ends up at S/2 + H octets, which is less than the ITR's estimate of the path MTU between itself and its correspondent ETR. Iconic, right? 😭
When an ETR receives encapsulated fragments, it treats them as two individually encapsulated packets. It strips the LISP headers and forwards each fragment to the destination host of the destination site. The two fragments get reassembled at the destination host into the single IP datagram that the source host originated 🧩.
Note that reassembly can happen at the ETR if the encapsulated packet was fragmented at or after the ITR. 👀
This behaviour happens when the source host originates a packet with the 'DF' field of the IP header set to 0. But when the 'DF' field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when its size is greater than L and send an ICMP Too Big message to the source with a value of S, where S is L - H. Not me gatekeeping the packet 💀.
When the outer-header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR. 🌸
This specification RECOMMENDS that L be defined as 1500. 🎀
5.4.2. A Stateful Solution to MTU Handling 💜
Now the stateful version, which was first introduced in [OPENLISP]. It's a little more involved, but it's giving "the ITR remembers everything" energy 🧚:
- The ITR will keep state of the effective MTU for each Locator per Map-Cache entry. The effective MTU is what the core network can deliver along the path between the ITR and ETR. 🗺️
- When an IPv6-encapsulated packet, or an IPv4-encapsulated packet with the DF bit set to 1, exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMP Too Big message to the ITR. The ITR will parse the ICMP message to determine which Locator is affected by the effective MTU change, and then record the new effective MTU value in the Map-Cache entry. 📝
- When a packet is received by the ITR from a source inside of the site, and the size of the packet is greater than the effective MTU stored with the Map-Cache entry associated with the destination EID the packet is for, the ITR will send an ICMP Too Big message back to the source. The packet size advertised by the ITR in that ICMP Too Big message is the effective MTU minus the LISP encapsulation length. 🫧
Even though this mechanism is stateful, it has real advantages over the stateless IP fragmentation mechanism, because it doesn't involve the destination host with reassembly of ITR fragmented packets. No extra drama for the host 💅✨.
5.5. Using Virtualization and Segmentation with LISP 🌈
When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-Prefixes, their address spaces MUST remain segregated because of possible address duplication. An Instance ID in the address encoding can help make the entire AFI-based address unique. See IANA Considerations (Section 14.2) for details on possible address encodings. 🔐
An Instance ID can be carried in a LISP-encapsulated packet. An ITR that prepends a LISP header will copy a 24-bit value, the one the LISP router uses to uniquely identify the address space. That value is copied to the 'Instance ID' field of the LISP header, and the I-bit is set to 1. 🪪
When an ETR decapsulates a packet, the Instance ID from the LISP header is used as a table identifier, which tells it which forwarding table to use for the inner destination EID lookup. Main character organizing 👑.
For example, an 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID. 🍓
6. EID-to-RLOC Mapping 🧚♀️
6.1. LISP IPv4 and IPv6 Control-Plane Packet Formats 🦋
The following UDP packet formats are used by the LISP control plane. Let's look at them together 👀:
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The LISP UDP-based messages are the Map-Request and Map-Reply messages. When a UDP Map-Request 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 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, because NATs can change port number values. 🙈
The 'UDP Length' field will reflect the length of the UDP header and the LISP Message payload. 📏
The UDP checksum is computed and set to non-zero for Map-Request, Map-Reply, Map-Register, and Encapsulated Control Message (ECM) control messages. It MUST be checked on receipt, and if the checksum fails, the packet MUST be dropped. 🚫
The format of control messages includes the UDP header, so the checksum and length fields can be used to protect and delimit message boundaries. Honestly the checksum and length doing double duty is so clever 🧠💖.
6.1.1. LISP Packet Type Allocations 🎀
This section will be the authoritative source for allocating LISP Type values and for defining LISP control message formats. Current allocations are:
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 Encapsulated Control Message: 8 b'1000'6.1.2. Map-Request Message Format ✨
okay bestie, the Map-Request packet is literally the main character of this whole section 💅 here's the 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=1 |A|M|P|S|p|s| Reserved | 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 what each field does 🎀
- Type:
1(Map-Request) 💖 - A: the authoritative bit 🔥. It's
0for UDP-based Map-Requests sent by an ITR. It's1when an ITR wants the destination site to send back the Map-Reply instead of the mapping database system, so it's basically asking the site directly. - M: the map-data-present bit 🌸. When it's set, a Map-Reply Record segment is included in the Map-Request.
- P: the probe-bit 👑. It says a Map-Request SHOULD be treated as a Locator reachability probe. The receiver SHOULD respond with a Map-Reply that has the probe-bit set, which tells you it's a Locator reachability probe reply, and the nonce gets copied over from the Map-Request. See Section 6.3.2 for more details.
- S: the Solicit-Map-Request (SMR) bit 🦋. See Section 6.6.2 for details.
- p: the PITR bit 🧚. It's set to 1 when a PITR sends a Map-Request.
- s: the SMR-invoked bit ✨. It's set to 1 when an xTR is sending a Map-Request in response to a received SMR-based Map-Request.
- Reserved: this field MUST be set to 0 on transmit and MUST be ignored on receipt 🙈.
- IRC: the 5-bit ITR-RLOC Count 💅. It encodes the additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields in this message. At least one (ITR-RLOC-AFI, ITR-RLOC-Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields are used so a Map-Replier can pick which destination address to use for a Map-Reply. The IRC value goes from 0 to 31:
- a value of 0 means there is 1 ITR-RLOC address encoded
- a value of 1 means there are 2 ITR-RLOC addresses encoded
- and so on, up to 31, which encodes a total of 32 ITR-RLOC addresses 🍓
- Record Count: the number of records in this Map-Request message 💜. A record is the part 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. Requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol 🔮.
- Nonce: an 8-octet random value created by the sender of the Map-Request 🎲. The nonce gets returned in the Map-Reply. The security of the LISP mapping protocol critically depends on how strong the nonce in the Map-Request is 😭. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security-sensitive random data.
- Source-EID-AFI: the address family of the 'Source EID Address' field 🌈.
- Source EID Address: the EID of the source host that originated the packet that caused the Map-Request 🧸. When Map-Requests are used for refreshing a Map-Cache entry or for RLOC-Probing, an AFI value 0 is used and this field is of zero length.
- ITR-RLOC-AFI: the address family of the 'ITR-RLOC Address' field that follows this field 🌊.
- ITR-RLOC Address: this gives the ETR the option of picking 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: the mask length for the EID-Prefix 🎀.
- EID-Prefix-AFI: the address family of the EID-Prefix according to [AFI] 💫.
- EID-Prefix: this prefix is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family 🦢. When an ITR sends a Map-Request because a data packet arrives for a destination with no mapping entry, the EID-Prefix is set to the destination IP address of the data packet, and the 'EID mask-len' is set to 32 for IPv4 or 128 for IPv6. When an xTR wants to ask a site about 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 a Map-Reply message.
- 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 holds the EID-to-RLOC mapping entry associated with the Source EID. That lets the ETR that will receive this Map-Request cache the data if it wants to 💖.
6.1.3. EID-to-RLOC UDP Map-Request Message 🧚
okay so a Map-Request gets sent from an ITR whenever it needs a mapping for an EID, wants to test an RLOC for reachability, or wants to refresh a mapping before its TTL runs out ⏰. For the first case, the destination IP address on the Map-Request is the data packet's destination address (the destination EID) that failed the 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 number is a 16-bit value picked by the ITR/PITR, and the UDP destination port number is the well-known port 4342 🦋. A successful Map-Reply, which is one whose nonce matches an outstanding Map-Request nonce, updates the cached set of RLOCs for 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) that got encoded MUST be placed in the 'IRC' field. The ITR MAY include all of its locally configured Locators in this list, or just one 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 a LISP Type value set to "Encapsulated Control Message" 🎁. That happens when they're sent from an ITR to a Map-Resolver. Map-Requests get LISP encapsulated the same way when they go from a Map-Server to an ETR. All the details on Encapsulated Map-Requests and Map-Resolvers are in [RFC6833] 📚.
Map-Requests MUST be rate-limited 🚦. It is RECOMMENDED that a Map-Request for the same EID-Prefix goes out no more than once per second ⭐.
An ITR that's 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 the mapping in its map-cache, it MAY originate a "verifying Map-Request" addressed to the map-requesting ITR, and the ETR MAY add a Map-Cache entry 🫶. If the ETR has a Map-Cache entry that matches the "piggybacked" EID and the RLOC is in the Locator-Set for that entry, then it may send the "verifying Map-Request" directly to the originating Map-Request source. If the RLOC is not in the Locator-Set, the ETR MUST send the "verifying Map-Request" to the "piggybacked" EID 🔍. Doing that forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, which guards against RLOC-spoofing in the "piggybacked" mapping data 🛡️✨.
6.1.4. Map-Reply Message Format 💌✨
okay bestie, this is the Map-Reply, the answer that comes back 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 giving 💅
- Type:
2(Map-Reply) 🌸 - P: This is the probe-bit 🔍. It says the Map-Reply is answering a Locator reachability probe Map-Request. The
Noncefield MUST contain a copy of the nonce value from the original Map-Request. Check Section 6.3.2 for the tea ☕ - E: This bit means the ETR sending this Map-Reply is advertising that the site is enabled for the Echo-Nonce Locator reachability algorithm. See Section 6.3.1 for more details 🧚
- S: This is the Security bit 🔐. When it's set to 1, the authentication info below gets tacked onto the end of the Map-Reply. The detailed format of the Authentication Data Content is for further study.
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 field MUST be set to 0 on transmit and MUST be ignored on receipt 🙅♀️
- Record Count: The number of records in this reply message 📋. A record is the chunk labeled
Recordabove, and it shows up as many times as the Record Count says. - Nonce: This is a 24-bit value set in a Data-Probe packet, or a 64-bit value from the Map-Request that gets echoed back in this
Noncefield of the Map-Reply 🎀. When a 24-bit value is supplied, it lives in the low-order 64 bits of theNoncefield. - Record TTL: This is how many minutes the recipient of the Map-Reply will store the mapping ⏰. If the TTL is
0, the entry SHOULD be removed from the cache immediately. If the value is0xffffffff, the recipient can decide locally how long to keep the mapping 🫶 - Locator Count: The number of Locator entries 📍. A Locator entry is the chunk labeled
Locabove. The Locator Count can be0, which 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 🚫. In any other message type these bits are set to 0 and ignored on receipt. They only get used when the
Locator Countfield is0. The action bits are only encoded in Map-Reply messages. These actions are used by an ITR or PITR when a destination EID matches a negative Map-Cache entry. Unassigned values should cause a Map-Cache entry to be created, and when packets match this negative cache entry, they will be dropped. The current assigned values are:(0) No-Action: The map-cache is kept alive, and no packet encapsulation occurs.(1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded.(2) Send-Map-Request: The packet invokes sending a Map-Request.(3) Drop: A packet that matches this map-cache entry is dropped. An ICMP Destination Unreachable message SHOULD be sent 💀
- A: The Authoritative bit 👑. When it's sent, an ETR always sets it to 1. When a Map-Server is proxy Map-Replying [RFC6833] for a LISP site, the Authoritative bit is set to 0. That tells the requesting ITRs that the Map-Reply wasn't originated by a LISP node managed at the site that owns the EID-Prefix 🕵️♀️
- Map-Version Number: When this 12-bit value is non-zero, the Map-Reply sender is letting the ITR know what the version number is for the EID record in the Map-Reply 🔢. The ETR can allocate this number internally, but it MUST coordinate this value with other ETRs for the site 🤝. When this value is
0, no versioning info is conveyed. The Map-Version Number can also show up in Map-Request and Map-Register messages. See Section 6.6.3 for more details. - EID-Prefix-AFI: The address family of the EID-Prefix, according to [AFI] 🌍
- EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family 📏
- Priority: Each RLOC gets a unicast Priority ⭐. Lower values are more preferable. When multiple RLOCs have the same Priority, they MAY be used in a load-split fashion 🍰. A value of
255means the RLOC MUST NOT be used for unicast forwarding 🚷 - Weight: When priorities are the same for multiple RLOCs, the Weight shows how to balance unicast traffic between them ⚖️. Weight is encoded as a relative weight of total unicast packets that match the mapping entry. For example, if 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 2nd and 3rd Locators get 25% each, and the 4th Locator gets 12.5%. If all Weights for a Locator-Set are equal, the receiver of the Map-Reply decides how to load-split the traffic. See Section 6.5 for a suggested hash algorithm to spread the load across Locators with the same Priority and equal Weight values 🧮
- M Priority: Each RLOC 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
255means the RLOC MUST NOT be used for joining a multicast distribution tree. For more details, see [RFC6831]. - M Weight: When priorities are the same for multiple RLOCs, the Weight shows how to balance building multicast distribution trees across multiple ITRs 🌳. It's encoded as 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 for a Locator-Set are equal, the receiver of the Map-Reply decides how to distribute multicast state across ITRs. For more details, see [RFC6831].
- Unused Flags: These are 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 that's sending the Map-Reply 🏠. When a Map-Server is doing proxy Map-Replying [RFC6833] 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 locator address with this bit set 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. The p-bit is set for a single Locator in the same Locator-Set. If an implementation sets more than one p-bit by mistake, the receiver of the Map-Reply MUST select the first Locator 🙃. The p-bit MUST NOT be set for Locator-Set records sent in Map-Request and Map-Register messages.
- R: This is set when the sender of a Map-Reply has a route to the Locator in the Locator data record 🛣️. The receiver may find it useful to know if the Locator is up but not necessarily reachable from the receiver's point of view. See also Section 6.4 for another way the R-bit may be used.
- Locator: This is an IPv4 or IPv6 address (as encoded by the
Loc-AFIfield) assigned to an ETR 📬. The destination RLOC address MAY be an anycast address, and a source RLOC can be an anycast address as well 🌐. The source or destination RLOC MUST NOT be the broadcast address (255.255.255.255or 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 📻
6.1.5. EID-to-RLOC UDP Map-Reply Message
okay bestie, so a Map-Reply hands back an EID-Prefix whose prefix length is less than or equal to the EID that was asked about 💅✨ That EID can come from the destination field of a Data-Probe's IP header, or from the EID record of a Map-Request. The RLOCs in the Map-Reply are globally routable IP addresses for all the ETRs of the LISP site 🌸 Each RLOC tells you about status reachability, but NOT path reachability from the requester's point of view 👀 So you have to test the path separately. Section 6.3 has the details 🦋
Quick heads up: a Map-Reply can have a different EID-Prefix granularity (prefix + length) than the Map-Request that set it off 💖 That can happen if you asked about a prefix that an earlier Map-Reply already gave you. In that case the requester updates its cache with the new prefix info and granularity 🎀 Like, if you had two cached EID-Prefixes covered by one less-specific prefix in a Map-Reply, you swap them for the less-specific one 🫶 The reverse can happen too: one less-specific prefix gets replaced by several more-specific ones. That doesn't mean removing the big one, it just means adding the smaller ones, which win during a lookup 🔥
Now, when an ETR has overlapping EID-Prefixes configured, a Map-Request with an EID that best matches any EID-Prefix MUST be returned in a single Map-Reply message 😭 Check out this example. Say an ETR has these database mapping entries for EID-Prefixes:
10.0.0.0/8
10.1.0.0/16
10.1.1.0/24
10.1.2.0/24A Map-Request for EID 10.1.1.1 gets a Map-Reply with a record count of 1, and the mapping record EID-Prefix is 10.1.1.0/24 💜
A Map-Request for EID 10.1.5.5 gets a Map-Reply with a record count of 3, with mapping records for EID-Prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24 🌈
Not every overlapping EID-Prefix has to come back, only the more-specific ones for the prefix matching the requesting EID 🧚 (Look at the second example: 10.0.0.0/8 was NOT returned when the requested EID was 10.1.5.5, which is giving "not me being extra" energy 💀) When more than one EID-Prefix comes back, they all SHOULD use the same Time to Live value so they can all time out together 🍓 If a more-specific EID-Prefix shows up later, its Time to Live value from the Map-Reply record can be stored even when less-specific entries already exist. And 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 whole EID-Prefix set intact, so no more-specific entries get deleted while the less-specific ones stick around. Iconic for integrity ✨
Map-Replies SHOULD be sent for an EID-Prefix no more often than once per second to the same requesting router ⭐ For scalability, aggregating EID addresses into EID-Prefixes means one Map-Reply can cover every EID address in that prefix range, so you end up sending fewer Map-Request messages. Big brain move 🧠💖
Map-Reply records can have an empty Locator-Set, and a Negative Map-Reply is just a Map-Reply with an empty Locator-Set 🙈 Negative Map-Replies carry special instructions from the 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 are sent for non-allocated EIDs 🌸
For each Map-Reply record, the Locators in a Locator-Set MUST appear in the same order for every ETR that originates a Map-Reply message 🎀 The Locator-Set MUST also be sorted in ascending IP address order, where an IPv4 locator address counts as numerically "less than" an IPv6 locator address. Strict ordering, no cap 👑
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 locator address from any of the address families it supports. For Data-Probes, the Map-Reply destination address 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 the local IP addresses chosen so that Unicast Reverse Path Forwarding (uRPF) checks succeed in the upstream service provider 💅 And the destination port of a Map-Reply message is copied from the source port of the Map-Request or Data-Probe, while the Map-Reply's source port is set to the well-known UDP port 4342 🌈
6.1.5.1. Traffic Redirection with Coarse EID-Prefixes
Okay, the scary part 😱 When an ETR is misconfigured or compromised, it could return coarse EID-Prefixes in the Map-Reply messages it sends. That EID-Prefix could cover prefixes allocated to other sites, which would redirect their traffic to the Locators of the compromised site 💀 Not it!!
There are two basic fixes. The first is to have Map-Servers proxy Map-Reply on behalf of ETRs, so the EID-Prefixes they register are the ones that show up in Map-Replies 🛡️ Since the interaction between an ETR and a Map-Server is secured with shared keys, it's easier for an ETR to catch misbehavior ✨ The second fix is to have ITRs and PITRs cache EID-Prefixes whose mask lengths are greater than or equal to a configured prefix length 🫶 That limits the damage to a specific width of any advertised EID-Prefix, but it has to be coordinated with how site prefixes get allocated 🎀 You can use these solutions separately or together, your call 💜
At the time of this writing, other approaches are being considered and researched 🔭
6.1.6. Map-Register Message Format
Quick note: the usage details of the Map-Register message are in [RFC6833] 📖 This section only defines the message format, so that's what we're doing here 💅
The message is sent in UDP with a destination UDP port of 4342 and a randomly selected UDP source port number 🦋
Here's the Map-Register message format. Don't panic, it looks like a lot but we're going field by field 🧚
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| Reserved |M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key 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, bestie 💖
Type: 3 (Map-Register) 🌸
P: This is the proxy Map-Reply bit. When it's set to 1, an ETR is sending a Map-Register message asking the Map-Server to proxy a Map-Reply. The Map-Server will send non-authoritative Map-Replies on behalf of the ETR 🎀 You can find the details on this usage in [RFC6833].
Reserved: This field 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 back in response to its Map-Register message. The Map-Notify message sent by a Map-Server is used to acknowledge that it received the Map-Register message 🦋
Record Count: This is the number of records in this Map-Register message. A record is the part of the packet labeled 'Record' above, and it shows up as many times as the Record Count says 🍓
Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register messages. Because the Map-Register message is authenticated, the 'Nonce' field isn't used for any security function right now, but it may be in the future as part of an anti-replay solution 🔥
Key ID: This is a configured ID used to find the configured Message Authentication Code (MAC) algorithm and key value for the authentication function. See Section 14.4 for codepoint assignments 🗝️
Authentication Data Length: This is the length in octets of the 'Authentication Data' field that follows this field. The length of the 'Authentication Data' field depends on the MAC algorithm used. This length field lets a device that doesn't know the MAC algorithm still parse the packet correctly 💅
Authentication Data: This is the message digest taken from the output of the MAC algorithm. The entire Map-Register payload is authenticated with this field preset to 0. After the MAC is computed, it goes in this field 🛡️ Implementations of this specification MUST include support for HMAC-SHA-1-96 [RFC2404], and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED 🌈
The definition of the rest of the Map-Register can be found in Section 6.1.4 ✨
6.1.7. Map-Notify Message Format 🔔✨
okay so the whole usage story for Map-Notify lives over in [RFC6833] 💅 this section is just the format, bestie.
the message gets sent inside a UDP packet where the source and destination ports are both 4342 🦋
the Map-Notify message format looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=4 | Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key 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 (Map-Notify)
the Map-Notify message has the same contents as a Map-Register message 🫶 so check the Map-Register section for the field descriptions. no need to reinvent the wheel, iykyk 💜
6.1.8. Encapsulated Control Message Format 🎀
okay this one is the wrapper queen 👑 an Encapsulated Control Message (ECM) is used to wrap control packets that get sent between xTRs and the mapping database system described in [RFC6833] 🧚
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| 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: the outer IPv4 or IPv6 header, which uses RLOC addresses in the source and destination header address fields.
- UDP: the outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non-zero.
- LH: 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.
- S: this is the Security bit. When it's set to 1, the field following the 'Reserved' field has the format shown below. The detailed format of the Authentication Data Content is for further study.
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 . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- IH: 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: the inner UDP header, where the 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 this section. At this time, only Map-Request messages are allowed to be encapsulated. In the future, PIM Join/Prune messages [RFC6831] might be allowed. Encapsulating other types of LISP control messages is for further study. 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.
6.2. Routing Locator Selection 🧭
okay the client-side and the server-side both might want a say in which RLOCs get picked for their conversations 👀 that control comes from messing with the 'Priority' and 'Weight' fields in EID-to-RLOC Map-Reply messages. or RLOC info MAY be gleaned from received tunneled packets or EID-to-RLOC Map-Request messages ✨
here are the different scenarios and how much control each side gets 💅
- The server-side returns one RLOC. The client-side can only use that one RLOC. The server-side has complete control of the selection.
- The server-side returns a list of RLOCs where a subset of the list has the same best Priority. The client can only use the subset list according to the weighting assigned by the server-side. In this case, the server-side controls both the subset list and load-splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution, while the client-side has the option of using alternatives to this list if RLOCs in the list are unreachable.
- The server-side sets a Weight of 0 for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. Control is shared: the server-side determines the list and the client determines load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs is unreachable.
- Either side (more likely the server-side ETR) decides not to send a Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the client-side ITR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the client-side ITR RLOC is done by caching the inner-header source EID and the outer-header source RLOC of received packets. The client-side ITR controls how traffic is returned and can alternate using an outer-header source RLOC, which can then be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server-side ETR MUST assume that each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-Prefix encoding cannot be conveyed in data packets, the EID-to-RLOC Cache on Tunnel Routers can grow to be very large 😭
- A "gleaned" Map-Cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner-header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the Map-Cache entry for the "gleaned" EID, and is stored and used for the time indicated from the 'TTL' field of a received Map-Reply. When a verified Map-Cache entry is stored, data gleaning no longer occurs for subsequent packets that have a source EID that matches the EID-Prefix of the verified entry.
RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the Locator record is set to 1. When the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the RLOC. Neither the information contained in a Map-Reply nor that stored in the mapping database system provides reachability information for RLOCs. Note that reachability is not part of the mapping system and is determined using one or more of the Routing Locator reachability algorithms described in the next section 🫶
6.3. Routing Locator Reachability 🦋
okay so, bestie, we need to figure out which RLOCs are actually alive 💅 Several mechanisms are currently defined for this:
- An ETR can look at the
Locator-Status-Bitsin the LISP header of an encapsulated data packet it gets from an ITR. If that ETR is also acting as an ITR and has traffic to send back to the original ITR site, it can use that status info to help pick an RLOC ✨ - An ITR might receive an ICMP Network Unreachable or Host Unreachable message for an RLOC it's using. That means the RLOC is likely down 🙈 Trusting ICMP messages may not be desirable, but ignoring them completely isn't great either, so it's giving "it's complicated." Implementations are encouraged to follow current best practices for handling these conditions 🫶
- An ITR that takes part in the global routing system can decide an RLOC is down if there is no BGP Routing Information Base (RIB) route that matches the RLOC IP address 💀
- An ITR might receive an ICMP Port Unreachable message from a destination host. This happens when an ITR tries to use interworking [RFC6832] and LISP-encapsulated data gets sent to a site that isn't LISP-capable 😭
- An ITR might receive a Map-Reply from an ETR in response to a Map-Request it sent earlier. The RLOC that the Map-Reply came from is likely up, since the ETR was able to send the Map-Reply back to the ITR 🌈
- When an ETR gets an encapsulated packet from an ITR, the source RLOC from the outer header of that packet is likely up 🍓
- An ITR/ETR pair can use the Locator reachability algorithms described in this section, namely Echo-Noncing or RLOC-Probing 🧚
When you check Locator up/down reachability by looking at the Locator-Status-Bits in the LISP-encapsulated data packet, the ETR gets up-to-date status from the encapsulating ITR about reachability for all the ETRs at the site. Ooh, and CE-based ITRs at the source site can figure out reachability relative to each other using the site IGP, like this:
- Normally, each ITR advertises a default route into the site IGP 🎀
- If an ITR fails, or if the upstream link to its PE fails, its default route will either time out or get withdrawn 😬
So each ITR can look at whether it sees a default route from the others (present or missing) and use that to set the Locator-Status-Bits for them 👑
Here's the numbering tea: RLOCs listed in a Map-Reply get ordinals 0 to n-1. The Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0 to n-1, starting with the least significant bit 🔥 For example, if the RLOC in the 3rd position of the Map-Reply goes down (ordinal value 2), then all the ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Locator-Status-Bits field for the packets they encapsulate. Iconic math 🧮💖
When an ETR decapsulates a packet, it checks for any change in the Locator-Status-Bits field. When a bit goes from 1 to 0, the ETR (if it's also acting as an ITR) will refrain from encapsulating packets to the RLOC that's marked as down. It only starts using that RLOC again if the matching Locator-Status-Bit returns to 1 ✨ Locator-Status-Bits are associated with a Locator-Set per EID-Prefix, so when a Locator becomes unreachable, the bit that matches that Locator's position in the list from the last Map-Reply gets set to zero for that particular EID-Prefix. Main character energy for the bit, fr fr 🦋
When ITRs at the site aren't deployed in CE routers, the IGP can still be used to figure out Locator reachability, as long as the Locators get injected into the IGP. This is typically done when a /32 address is configured on a loopback interface 🌸
When ITRs get ICMP Network Unreachable or Host Unreachable messages as a way to figure out unreachability, they refrain from using the Locators listed in the Locator lists of Map-Replies. BUT, using this approach is unreliable, because lots of 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. Be careful with this one, bestie 🫶
BGP-enabled ITRs can also, on their own, check the RIB to see whether a locator address from a Locator-Set in a mapping entry matches a prefix. If it doesn't find one and BGP is running in the Default-Free Zone (DFZ), it can decide to not use the Locator, even though the Locator-Status-Bits say the Locator is up. In that case, the path from the ITR to the ETR that was assigned the Locator isn't available. More details are in [LOC-ID-ARCH] 💜
Optionally, an ITR can send a Map-Request to a Locator, and if a Map-Reply comes back, reachability of the Locator has been determined ✨ Obviously, sending these probes increases the number of control messages originated by Tunnel Routers for active flows, so Locators are assumed to be reachable when they're advertised 🌈
This assumption does create a dependency: Locator unreachability is detected by receiving ICMP Host Unreachable messages. When a Locator has been determined to be unreachable, it isn't used for active traffic. This is the same as if it were listed in a Map-Reply with Priority 255 💅
The ITR can test whether the unreachable Locator is back by sending periodic Requests. Both Requests and Replies MUST be rate-limited 🚦 Locator reachability testing is never done with data packets, since that would increase the risk of packet loss for end-to-end sessions 🙅♀️
When an ETR decapsulates a packet, it knows it can reach the encapsulating ITR, because that's how the packet arrived. In most cases the ETR can also reach the ITR, but it can't assume that's true, because of the possibility of path asymmetry 🦋 In the presence of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT use the lack of return traffic as an indication that the ETR is unreachable. Instead, it MUST use an alternate mechanism to determine reachability 🍓
6.3.1. Echo Nonce Algorithm 🔁
When data flows both ways between Locators from different sites, a data-plane mechanism called "nonce echoing" can be used to figure out reachability between an ITR and ETR 💖 When an ITR wants to solicit a nonce echo, it sets the N- and E-bits and drops a 24-bit nonce [RFC4086] into the LISP header of the next encapsulated data packet 🧚
When the ETR gets this packet, the encapsulated packet is forwarded as normal ✨ When the ETR next sends a data packet to the ITR, it includes the nonce it received earlier, with the N-bit set and the E-bit cleared. The ITR sees this "echoed nonce" and knows the path to and from the ETR is up 🎀
While it's in the echo-nonce-request state, the ITR sets the E-bit and N-bit on every packet it sends. How long the ITR waits to process the echoed nonce before deciding the path is unreachable is variable, and that's a choice left up to the implementation ⏳
If the ITR is getting packets from the ETR but doesn't see the nonce echoed while it's in the echo-nonce-request state, then the path to the ETR is unreachable 💀 This decision may be overridden by other Locator reachability algorithms. Once the ITR decides the path to the ETR is down, it can switch to another Locator for that EID-Prefix 🌈
Note that "ITR" and "ETR" are relative terms here. Both devices MUST be implementing both ITR and ETR functionality for the echo nonce mechanism to work 👑
The ITR and ETR may both go into the echo-nonce-request state at the same time. How many packets get sent, or how long echo nonce requests keep going, is an implementation-specific setting 🍓 Still, when an ITR is in the echo-nonce-request state, it can echo the ETR's nonce in the next set of packets it encapsulates, and then keep on sending echo-nonce-request packets afterwards 💜
This mechanism doesn't completely solve the forward path reachability problem, because traffic may be unidirectional 🙈 That means the ETR receiving traffic at a site might not be the same device as the ITR that transmits traffic from that site, or the site-to-site traffic is unidirectional so there's no ITR return traffic at all.
The echo-nonce algorithm is bilateral. If one side sets the E-bit and the other side isn't enabled for echo-noncing, the nonce doesn't get echoed, and the requesting side may wrongly consider the Locator unreachable 😭 An ITR SHOULD only set the E-bit in an encapsulated data packet when it knows the ETR is enabled for echo-noncing. The E-bit in the Map-Reply message is how that gets conveyed 🫶
Note that other Locator reachability mechanisms are being researched, and they can be used to complement or even override the echo nonce algorithm. See the next section for an example of control-plane probing ✨
6.3.2. 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 originates a Map-Request destined to a locator address, sent from one of its own 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 soliciting mapping data. The EID record encoded in the Map-Request is the EID-Prefix of the Map-Cache entry the ITR or PITR has cached 🧚 The ITR may include a mapping data record for its own database mapping information, the one with 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 with the probe-bit set, it returns a Map-Reply with the probe-bit set too 💖 The source address of that Map-Reply is set according to the procedure described in Section 6.1.5. 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 have changed 🎀
RLOC-Probing has pros and cons, bestie. Its biggest benefit is that it can handle lots of failure scenarios, letting the ITR figure out when the path to a specific Locator is reachable or has become unreachable. That makes it a robust way to switch to another Locator from the cached Locator-Set 👑 RLOC-Probing can also give rough Round-Trip Time (RTT) estimates between a pair of Locators, which is useful for network management and for picking low-delay paths 🌈 The major disadvantage is the number of control messages required and the bandwidth used to get those benefits, especially if the requirement for failure detection times is very small 😬
Continued research and testing will try to characterize the tradeoffs between failure detection times and message overhead 🔬✨
6.4. EID Reachability within a LISP Site ✨
okay bestie, so a site can be multihomed using two or more ETRs 🏠💖 The hosts and infrastructure inside the site get addressed with one or more EID-Prefixes, and those get mapped to the RLOCs of the relevant ETRs in the mapping system 🗺️ One possible way this goes sideways is when an ETR loses reachability to one or more of the EID-Prefixes in its OWN site 😭 When that happens, the ETR can clear the R-bit tied to its own Locator when it sends Map-Replies 🙈 And if that ETR is also an ITR, it can clear its Locator-Status-Bit in the encapsulation data header 💅
It's giving "no simple solutions" energy, because it's genuinely hard to know which part of the EID-Prefix range got partitioned and which Locators can still reach any sub-ranges 🥺 This is under investigation, with the expectation that experiments will tell us more 🧪 And ngl, this isn't a new problem that LISP invented. It already happens today when a multihomed site uses BGP to advertise its reachability upstream 🌐 Same problem, different outfit 👑
6.5. Routing Locator Hashing 🧮
okay so when an ETR gives an EID-to-RLOC mapping in a Map-Reply to a requesting ITR, the Locator-Set for that EID-Prefix can have different Priority values for each locator address 💜 When more than one best Priority Locator exists, the ITR gets to decide how to load-share traffic across those Locators 🎀
The following hash algorithm may be used by an ITR to select a Locator for a packet destined to an EID for the EID-to-RLOC mapping:
- Either a source and destination address hash or the traditional 5-tuple hash can be used. The traditional 5-tuple hash includes the source and destination addresses; source and destination TCP, UDP, or Stream Control Transmission Protocol (SCTP) port numbers; and the IP protocol number field or IPv6 next-protocol fields of a packet that a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and destination addresses only from the header are used to compute the hash ✨
- Take the hash value and divide it by the number of Locators stored in the Locator-Set for the EID-to-RLOC mapping 🔢
- The remainder will yield a value of 0 to "number of Locators minus 1". Use the remainder to select the Locator in the Locator-Set 🎯
Note that when a packet is LISP encapsulated, the source port number in the outer UDP header needs to be set 🫶 Selecting a hashed value lets core routers attached to Link Aggregation Groups (LAGs) load-split the encapsulated packets across member links of those LAGs 🌈 Otherwise, core routers would see a single flow, since packets have a source address of the ITR, for packets originated by different EIDs at the source site 🙃 A suggested setting for the source port number computed by an ITR is a 5-tuple hash function on the inner header, as described above 🦋
Many core router implementations use a 5-tuple hash to decide how to balance packet load across members of a LAG 💅 The 5-tuple hash includes the source and destination addresses of the packet and the source and destination ports when the protocol number in the packet is TCP or UDP. For this reason, UDP encoding is used for LISP encapsulation 💜
6.6. Changing the Contents of EID-to-RLOC Mappings 🔄
Since the LISP architecture uses a caching scheme to retrieve and store EID-to-RLOC mappings, the only way an ITR can get a more up-to-date mapping is to re-request the mapping 🥲 However, the ITRs don't know when the mappings change, and the ETRs don't keep track of which ITRs requested their mappings. For scalability reasons, we want to keep this approach, but we still need a way for ETRs to change their mappings and inform the sites that are currently communicating with the ETR site using those mappings 📣
When adding a new Locator record in lexicographic order to the end of a Locator-Set, it's easy to update mappings 🍓 We assume new mappings keep the same Locator ordering as the old mapping, but with new Locators appended to the end of the list. So some ITRs can have a new mapping while other ITRs only have an old mapping, which they keep using until it times out ⏳ When an ITR has only an old mapping but detects bits set in the Locator-Status-Bits that correspond to Locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing Locator-Set 🙈
When a Locator record is inserted in the middle of a Locator-Set, to keep lexicographic order, the SMR procedure in Section 6.6.2 is used to inform ITRs and PITRs of the new Locator-Status-Bit mappings 📨
When a Locator record is removed from a Locator-Set, ITRs that have the mapping cached won't use the removed Locator, because the xTRs set the Locator-Status-Bit to 0 💀 So even if the Locator is still in the list, it won't be used. For new mapping requests, the xTRs can set the Locator AFI to 0 (indicating an unspecified address), as well as setting the corresponding Locator-Status-Bit to 0. This forces ITRs with old or new mappings to avoid using the removed Locator 🚫
If many changes happen to a mapping over a long period of time, you'll find empty record slots in the middle of the Locator-Set and new records appended to the end 🧩 At some point it would be useful to compact the Locator-Set, so the Locator-Status-Bit settings can be efficiently packed 📦
We propose three approaches for Locator-Set compaction: one operational mechanism and two protocol mechanisms 🎀 The operational approach uses a clock sweep method. The protocol approaches use the concept of Solicit-Map-Requests and Map-Versioning ✨
6.6.1. Clock Sweep ⏰
The clock sweep approach uses planning in advance and count-down TTLs to time out mappings that have already been cached. The default setting for an EID-to-RLOC mapping TTL is 24 hours, so there's a 24-hour window to time out old mappings ⌛ The following clock sweep procedure is used:
- 24 hours before a mapping change is set to take effect, a network administrator configures the ETRs at a site to start the clock sweep window 🗓️
- During the clock sweep window, ETRs keep sending Map-Reply messages with the current (unchanged) mapping records. The TTL for these mappings is set to 1 hour 🌸
- 24 hours later, all previous cache entries will have timed out, and any active cache entries will time out within 1 hour. During this 1-hour window, the ETRs keep sending Map-Reply messages with the current (unchanged) mapping records, with the TTL set to 1 minute 😭
- At the end of the 1-hour window, the ETRs send Map-Reply messages with the new (changed) mapping records. So any active caches can get the new mapping contents right away if they aren't cached, or in 1 minute if they had the mapping cached. The new mappings are cached with a TTL equal to the TTL in the Map-Reply 🎉
6.6.2. Solicit-Map-Request (SMR) 📨
Soliciting a Map-Request is a selective way for ETRs, at the site where mappings change, to control the rate at which they receive requests for Map-Reply messages 🦋 SMRs are also used to tell remote ITRs to update the mappings they have cached 💜
Since the ETRs don't keep track of remote ITRs that have cached their mappings, they don't know which ITRs need their mappings updated 🥺 As a result, an ETR will solicit Map-Requests (called an SMR message) from those sites it has been sending encapsulated data to during the last minute. In particular, an ETR will send an SMR to an ITR it has recently sent encapsulated data to 📬
An SMR message is simply a bit set in a Map-Request message. An ITR or PITR will send a Map-Request when it receives an SMR message. Both the SMR sender and the Map-Request responder MUST rate-limit these messages. Rate-limiting can be implemented as a global rate-limiter or as one rate-limiter per SMR destination 🚦
The following procedure shows how an SMR exchange occurs when a site is doing Locator-Set compaction for an EID-to-RLOC mapping:
- When the database mappings in an ETR change, the ETRs at the site begin to send Map-Requests with the SMR bit set for each Locator in each Map-Cache entry the ETR caches 🔔
- A remote ITR that receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message or to the mapping database system. A newly allocated random nonce is selected, and the EID-Prefix used is the one copied from the SMR message. If the source Locator is the only Locator in the cached Locator-Set, the remote ITR SHOULD send a Map-Request to the database mapping system, just in case the single Locator has changed and may no longer be reachable to accept the Map-Request 🕵️♀️
- The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply, while continuing to use the cached mapping. When Map-Versioning as described in Section 6.6.3 is used, an SMR sender can detect whether an ITR is using the most up-to-date database mapping 🔍
- The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message that has a nonce from the SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate-limited. This is important to avoid Map-Reply implosion 💥
- The ETRs at the site with the changed mapping record the fact that the site that sent the Map-Request has received the new mapping data in the Map-Cache entry for the remote site, so the Locator-Status-Bits reflect the new mapping for packets going to the remote site. The ETR then stops sending SMR messages ✅
Experimentation is in progress to determine the appropriate rate-limit parameters 🧪
For security reasons, an ITR MUST NOT process unsolicited Map-Replies 🔐 To avoid Map-Cache entry corruption by a third party, a sender of an SMR-based Map-Request MUST be verified. If an ITR receives an SMR-based Map-Request and the source is not in the Locator-Set for the stored Map-Cache entry, then the responding Map-Request MUST be sent with an EID destination to the mapping database system. Since the mapping database system is a more secure way to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data 🛡️
When an ITR receives an SMR-based Map-Request for which it doesn't have a cached mapping for the EID in the SMR message, it MAY not send an SMR-invoked Map-Request 🙈 This scenario can happen when an ETR sends SMR messages to all Locators in the Locator-Set it has stored in its map-cache, but the remote ITRs that receive the SMR may not be sending packets to the site. There's no point in updating the ITRs until they need to send, at which point they'll send Map-Requests to obtain a Map-Cache entry 💅
6.6.3. Database Map-Versioning ✨
okay so this one is about what happens when traffic only flows one way between an ITR and an ETR, and the EID-to-RLOC mappings change on the ETR side. 😭 The ETR needs to tell the ITR so encapsulation to a removed Locator can stop, and the ITR can start using a new Locator in the Locator-Set instead. bestie, that's a whole glow-up 💅
An ETR, when it sends Map-Reply messages, shares its own Map-Version Number. This is called the Destination Map-Version Number. ITRs put the Destination Map-Version Number in the packets they encapsulate to the site. When an ETR decapsulates a packet and sees that the Destination Map-Version Number is less than the current version for its mapping, the SMR procedure from Section 6.6.2 kicks off. 🔥
An ITR, when it encapsulates packets to ETRs, can share its own Map-Version Number too. This is the Source Map-Version Number. When an ETR decapsulates a packet and notices that the Source Map-Version Number is greater than the last Map-Version Number it sent in a Map-Reply to the ITR's site, the ETR will send a Map-Request to one of the ETRs for the source site. 👀
A Map-Version Number works like a sequence number per EID-Prefix, so bigger values are more recent. 🧚 A value of 0 for the Source Map-Version Number or the Destination Map-Version Number conveys no versioning information, and an ITR does no comparison with previously received Map-Version Numbers. So zero is basically "no info here" 🙈
A Map-Version Number can be included in Map-Register messages as well. This is a good way for the Map-Server to make sure all the ETRs registering to it for a site stay synchronized by Map-Version Number. 🫶
See [RFC6834] for a more detailed analysis and description of Database Map-Versioning. 📚
7. Router Performance Considerations 🚀
LISP is designed to be very "hardware-based forwarding friendly". 💖 A few implementation techniques can be used to incrementally implement LISP:
- When a tunnel-encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special Forwarding Information Base (FIB) entries for the EID-Prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control-plane processing should be performed. The forwarding logic of testing for particular IP protocol number values is not necessary. There are a few proven cases where no changes to existing deployed hardware were needed to support the LISP data-plane. 🌸
- On an ITR, prepending a new IP header consists of adding more octets to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already support this action. 🍓
- A packet's source address or the interface the packet was received on can be used to select VRF (Virtual Routing/Forwarding). The VRF's routing table can be used to find EID-to-RLOC mappings. 🦋
For performance issues related to map-cache management, see Section 12. ✨
8. Deployment Scenarios 🏡
This section will explore how and where ITRs and ETRs can be deployed, and it'll talk through the pros and cons of each deployment scenario. 💅 For a more detailed deployment recommendation, refer to [LISP-DEPLOY].
There are two basic deployment tradeoffs to consider: centralized versus distributed caches, and flat, Recursive, or Re-encapsulating Tunneling. When deciding between centralized and distributed caching, the following issues should be considered:
- Are the Tunnel Routers spread out so that the caches are spread across all the memories of each router? A centralized cache is when an ITR keeps a cache for all the EIDs it is encapsulating to. The packet takes a direct path to the destination Locator. A distributed cache is when an ITR needs help from other re-encapsulating routers because it does not store all the cache entries for the EIDs it is encapsulating to. So, the packet takes a path through re-encapsulating routers that have a different set of cache entries. 🧩
- Should management "touch points" be minimized by only choosing a few Tunnel Routers, just enough for redundancy? 🎀
- In general, using more ITRs doesn't increase management load, since caches are built and stored dynamically. On the other hand, using more ETRs does require more management, since EID-Prefix-to-RLOC mappings need to be explicitly configured. 📋
When deciding on flat, Recursive, or Re-encapsulating Tunneling, the following issues should be considered:
- Flat tunneling implements a single tunnel between the source site and destination site. This generally offers better paths between sources and destinations with a single tunnel path. 🛣️
- Recursive Tunneling is when tunneled traffic is again further encapsulated in another tunnel, either to implement VPNs or to perform Traffic Engineering. When doing VPN-based tunneling, the site has some control, since the site is prepending a new tunnel header. In the case of TE-based tunneling, the site may have control if it is prepending a new tunnel header, but if the site's ISP is doing the TE, then the site has no control. Recursive Tunneling generally will result in suboptimal paths, but with the benefit of steering traffic to parts of the network that have more resources available. 🌀
- The technique of re-encapsulation ensures that packets only require one tunnel header. So, if a packet needs to be re-routed, it is first decapsulated by the ETR and then re-encapsulated with a new tunnel header using a new RLOC. 🔁
The next sub-sections will examine where Tunnel Routers can reside in the network. 👑
8.1. First-Hop/Last-Hop Tunnel Routers 🏠
By locating Tunnel Routers close to hosts, the EID-Prefix set is at the granularity of an IP subnet. So, at the expense of more EID-Prefix-to-RLOC sets for the site, the caches in each Tunnel Router can remain relatively small. But caches always depend on the number of non-aggregated EID destination flows active through these Tunnel Routers. 💜
With more Tunnel Routers doing encapsulation, the increase in control traffic grows as well: since the EID granularity is greater, more Map-Requests and Map-Replies are traveling between more routers. 😭
The advantage of placing the caches and databases at these stub routers is that the products deployed in this part of the network have better price-memory ratios than their core router counterparts. Memory is typically less expensive in these devices, and fewer routes are stored (only IGP routes). These devices tend to have excess capacity, both for forwarding and routing states. 💰
LISP functionality can also be deployed in edge switches. These devices generally have layer-2 ports facing hosts and layer-3 ports facing the Internet. Spare capacity is also often available in these devices. 🔌
8.2. Border/Edge Tunnel Routers 🛡️
Using Customer Edge (CE) routers for tunnel endpoints allows the EID space associated with a site to be reachable via a small set of RLOCs assigned to the CE routers for that site. This is the default behavior envisioned in the rest of this specification. 👑
This offers the opposite benefit of the first-hop/last-hop Tunnel Router scenario: the number of mapping entries and network management touch points is reduced, allowing better scaling. 📈
One disadvantage is that fewer network resources are used to reach host endpoints, thereby centralizing the point-of-failure domain and creating network choke points at the CE router. 🚧
Note that more than one CE router at a site can be configured with the same IP address. In this case, an RLOC is an anycast address. This allows resilience between the CE routers. That is, if a CE router fails, traffic is automatically routed to the other routers using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. Another disadvantage of using anycast Locators is the limited advertisement scope of /32 (or /128 for IPv6) routes. 🌐
8.3. ISP Provider Edge (PE) Tunnel Routers 🏢
The use of ISP PE routers as tunnel endpoint routers is not the typical deployment scenario envisioned in this specification. This section attempts to capture some of the reasoning behind this preference for implementing LISP on CE routers. 🤔
The use of ISP PE routers as tunnel endpoint routers gives an ISP, rather than a site, control over the location of the egress tunnel endpoints. That is, the ISP can decide whether the tunnel endpoints are in the destination site (in either CE routers or last-hop routers within a site) or at other PE edges. The advantage of this case is that two tunnel headers can be avoided. By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and re-encapsulate for a tunnel to the destination end site. 🦋
An obvious disadvantage is that the end site has no control over where its packets flow or over the RLOCs used. Other disadvantages include difficulty in synchronizing path liveness updates between CE and PE routers. 😬
As mentioned in earlier sections, a combination of these scenarios is possible at the expense of extra packet header overhead; if both site and provider want control, then Recursive or Re-encapsulating Tunnels are used. 🍰
8.4. LISP Functionality with Conventional NATs 🎭
LISP routers can be deployed behind Network Address Translator (NAT) devices to provide the same set of packet services hosts have today when they are addressed out of private address space. 🧸
It is important to note that a locator address in any LISP control message MUST be a globally routable address and therefore SHOULD NOT contain [RFC1918] addresses. If a LISP router is configured with private addresses, they MUST be used only in the outer IP header so the NAT device can translate properly. Otherwise, EID addresses MUST be translated before encapsulation is performed. Both NAT translation and LISP encapsulation functions could be co-located in the same device. 🚨
⚠️ bestie, read that twice. Private addresses go in the outer header ONLY, and locator addresses in control messages have to be globally routable. Don't skip this one 💀
More details on LISP address translation can be found in [RFC6832]. 📖
8.5. Packets Egressing a LISP Site 🚪
When a LISP site is using two ITRs for redundancy, the failure of one ITR will likely shift outbound traffic to the second. This second ITR's cache may not be populated with the same EID-to-RLOC mapping entries as the first. If this second ITR does not have these mappings, traffic will be dropped while the mappings are retrieved from the mapping system. The retrieval of these messages may increase the load of requests being sent into the mapping system. Deployment and experimentation will determine whether this issue requires more attention. 🧪
9. Traceroute Considerations ✨
okay bestie, let's talk traceroute 🦋 When a source host in a LISP site starts a traceroute to a destination host in another LISP site, it is highly desirable for it to see the entire path 🫶 Since packets get encapsulated from the ITR to the ETR, that tunnel hop could look like just one hop. But LISP traceroute will show the whole path, so the user can see 3 distinct segments from a source LISP host to a destination LISP host 👀
Segment 1 (in source LISP site based on EIDs):
source host ---> first hop ... next hop ---> ITR
Segment 2 (in the core network based on RLOCs):
ITR ---> next hop ... next hop ---> ETR
Segment 3 (in the destination LISP site based on EIDs):
ETR ---> next hop ... last hop ---> destination hostFor segment 1, ICMP Time Exceeded messages come back the normal way, just like they do today 💅 The ITR does a TTL decrement and checks for 0 before it encapsulates. So the ITR's hop shows up to the traceroute source with an EID address (the address of the site-facing interface) 🌸
For segment 2, ICMP Time Exceeded messages go back to the ITR, because the TTL hits 0 on the outer header. That means the destinations of those ICMP messages are the ITR RLOC address and the source RLOC address of the encapsulated traceroute packet 🧚 The ITR peeks inside the ICMP payload to find the traceroute source, so it can send the ICMP message back to the traceroute client and keep the core router IP address in the message too. This is so the traceroute client can show the core router address (the RLOC address) in the output 💜 The ETR returns its RLOC address and responds to the TTL decrement to 0, just like the earlier core routers did ✨
For segment 3, the next-hop router downstream from the ETR is the one decrementing the TTL. The packet was encapsulated, sent into the core, decapsulated by the ETR, and forwarded because it isn't the final destination yet 🍓 If the TTL goes to 0, any router on the path to the traceroute destination, including the next-hop router or the destination, will send an ICMP Time Exceeded message to the source EID of the traceroute client. The local ITR encapsulates that ICMP message and sends it back to the ETR in the originating traceroute source site, where it gets delivered to the host 🎀
9.1. IPv6 Traceroute
IPv6 traceroute follows the procedure above, because the entire traceroute data packet is included in the ICMP Time Exceeded message payload 🌈 So only the ITR needs to pay special attention to forwarding ICMP messages back to the traceroute source 🫶
9.2. IPv4 Traceroute
Okay, IPv4 is where it gets messy 😭 We can't follow the procedure above here, because IPv4 ICMP Time Exceeded messages only include the invoking IP header and 8 octets that follow the IP header. So when a core router sends an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP payload is the encapsulated header it prepended, followed by a UDP header. The original invoking IP header, and therefore the identity of the traceroute source, is lost 💀
The fix we propose is to cache traceroute IPv4 headers in the ITR and match them up with the matching IPv4 Time Exceeded messages from core routers and the ETR. The ITR uses a circular buffer to cache the IPv4 and UDP headers of traceroute packets 🦋 It selects a 16-bit number as a key to find them later when the IPv4 Time Exceeded messages arrive. When an ITR encapsulates an IPv4 traceroute packet, it uses that 16-bit number as the UDP source port in the encapsulating header. When the ICMP Time Exceeded message comes back to the ITR, the UDP header of the encapsulating header is in the ICMP payload, so the ITR can find the cached headers for the traceroute source. The ITR puts the cached headers in the payload and sends the ICMP Time Exceeded message to the traceroute source, keeping the source address of the original ICMP Time Exceeded message (a core router or the ETR of the site of the traceroute destination) 🧚✨
The signature of a traceroute packet comes in two forms. The first is encoded as a UDP message, where the destination port gets inspected for a range of values. The second is encoded as an ICMP message, where the IP identification field gets inspected for a well-known value 🌸
9.3. Traceroute Using Mixed Locators
When either an IPv4 traceroute or an IPv6 traceroute is originated and the ITR encapsulates it in the other address family's header, you can't get all 3 segments 😩 Segment 2 can't be conveyed to the traceroute source, since that source expects addresses from intermediate hops in the same address format as the type of traceroute it originated. So in this case, segment 2 will make the tunnel look like one hop 💅 All the ITR has to do to make this work is not copy the inner TTL to the outer, encapsulating header's TTL when a traceroute packet is encapsulated using an RLOC from a different address family. That means no TTL decrement to 0 occurs in core routers between the ITR and ETR 🎀
10. Mobility Considerations 🦋
There are several kinds of mobility, and only some of them might concern LISP. Basically, they go like this 🌈
10.1. Site Mobility
A site wants to change its attachment points to the Internet, so its LISP Tunnel Routers will get new RLOCs when it changes upstream providers 🏠 Changes in EID-to-RLOC mappings for sites are expected to be handled by configuration, outside of LISP ⚙️
10.2. Slow Endpoint Mobility
An individual endpoint wants to move but isn't worried about keeping session continuity 📦 Renumbering is involved. LISP can help with the renumbering issues [RFC4192] [LISA96] by decoupling the address space a site uses from the address spaces its ISPs use [RFC4984] 💜
10.3. Fast Endpoint Mobility
Fast endpoint mobility happens when an endpoint moves relatively rapidly and changes its IP-layer network attachment point 🏃♀️💨 Keeping session continuity is a goal here. This is where the Mobile IPv4 [RFC5944] and Mobile IPv6 [RFC6275] [RFC4866] mechanisms get used, and it's mainly where interactions with LISP need to be explored 👑
The problem is that as an endpoint moves, its mapping between its EID and a set of RLOCs may need to change for its new network location. When that gets added to the overhead of Mobile IP binding updates, some packets might be delayed or dropped 😬
In IPv4 mobility, when an endpoint is away from home, packets to it are encapsulated and forwarded through a home agent that lives in the home area the endpoint's address belongs to. The home agent encapsulates and forwards packets either directly to the endpoint or to a foreign agent that lives where the endpoint has moved to. Packets from the endpoint may go directly to the correspondent node, may go through the foreign agent, or may be reverse-tunneled back to the home agent for delivery to the mobile node 🔁 As the mobile node's EID or available RLOC changes, LISP EID-to-RLOC mappings are required for communication between the mobile node and the home agent, whether or not it goes through the foreign agent. As a mobile endpoint changes networks, up to three LISP mapping changes may be required:
- The mobile node moves from an old location to a new visited network location and tells its home agent it has done so. The Mobile IPv4 control packets the mobile node sends pass through one of the new visited network's ITRs, which needs an EID-to-RLOC mapping for the home agent 📬
- The home agent might not have the EID-to-RLOC mappings for the mobile node's "care-of" address or its foreign agent in the new visited network, in which case it will need to acquire them 🔍
- When packets are sent directly to the correspondent node, it may be that no traffic has been sent from the new visited network to the correspondent node's network. The new visited network's ITR will then need to obtain an EID-to-RLOC mapping for the correspondent node's site 🗺️
In addition, if the IPv4 endpoint is sending packets from the new visited network using its original EID, then LISP will need to perform a route-returnability check on the new EID-to-RLOC mapping for that EID 🧐
In IPv6 mobility, packets can flow directly between the mobile node and the correspondent node in either direction. The mobile node uses its "care-of" address (EID). In this case the route-returnability check wouldn't be needed, but one more LISP mapping lookup may be required instead ✨
- As above, three mapping changes may be needed for the mobile node to communicate with its home agent and to send packets to the correspondent node.
- In addition, another mapping will be needed in the correspondent node's ITR, so the correspondent node can send packets to the mobile node's "care-of" address (EID) at the new network location 💫
When both endpoints are mobile, the number of potential mapping lookups goes up accordingly 📈
As a mobile node moves, there are not only mobility state changes in the mobile node, correspondent node, and home agent, but also state changes in the ITRs and ETRs for at least some EID-Prefixes 🌀
The goal is to support rapid adaptation, with little delay or packet loss for the entire system 🚀 Also, IP mobility can be modified to require fewer mapping changes. To boost overall system performance, there may be a need to reduce the optimization of one area in order to place fewer demands on another ⚖️
In LISP, one possibility is to "glean" information. When a packet arrives, the ETR could examine the EID-to-RLOC mapping and use that mapping for all outgoing traffic to that EID. It can do this after performing a route-returnability check, to make sure the new network location does have an internal route to that endpoint 🕵️♀️ However, this doesn't cover the case where an ITR (the node assigned the RLOC) at the mobile-node location has been compromised 🚨
Mobile IP packet exchange is designed for an environment where all routing information is disseminated before packets can be forwarded. To let the Internet grow to support expected future use, we're moving toward an environment where some information may have to be obtained after packets are already in flight 🛫 Modifications to IP mobility should be considered to optimize the behavior of the overall system. Anything that decreases the number of new EID-to-RLOC mappings needed when a node moves, or keeps the validity of an EID-to-RLOC mapping for longer, is useful 💖
10.4. Fast Network Mobility 🚀
okay so this one is about whole networks moving around, not just single endpoints 🌈 A "network" can be as tiny as one router or as big as an entire site. It's different from site mobility because it's fast and maybe short-lived, but it's also different from endpoint mobility because an entire prefix is switching RLOCs all at once 😭 The good news is the mechanisms are the same, so LISP doesn't add any new overhead. A Map-Request for any endpoint in that prefix gets back a binding for the whole mobile prefix ✨
if mobile networks start showing up way more often, it could be worth rethinking how the mapping service works and letting the database take dynamic updates 💅
the interactions between mobility and LISP still need more digging 🔍 how much better the whole system can get depends on the details of the mapping mechanisms, and those mechanisms should be judged on how well they keep sessions going for mobile nodes. session continuity is literally the whole vibe 🫶
10.5. LISP Mobile Node Mobility 📱
this is the iconic part: a phone or other mobile device can use the LISP infrastructure to get mobility on its own 💖 It just has to implement the LISP encapsulation and decapsulation functions and act like a simple ITR/ETR. A device doing this (a "LISP mobile node") can use topologically independent EID IP addresses. Those addresses don't get advertised into the global routing system and don't cost it anything 🦋 The EIDs live at the edges of the mapping system (in LISP Map-Servers and Map-Resolvers) and only get handed out on demand, and only to the mobile node's correspondents. main character energy, no cap 👑
for the full scoop, check out [LISP-MN] 🎀
11. Multicast Considerations 🌸
okay multicast, let's gooo 🧚 In the original Internet architecture, a multicast group address is an identifier for a bunch of topologically independent receiver locations. The address itself doesn't tell you where the receivers are. That's the job of the multicast routing protocol and the network state it builds 🍓
in LISP, a multicast group address is both an EID and a Routing Locator 🤯 So there's no special semantic or action needed for a destination address as it shows up in an IP header. A group address in the inner header built by a source host gets used as the destination EID, and the outer IP header (the destination RLOC) added by a LISP router uses that same group address as the destination RLOC 💅
the only stuff that really needs handling is the source EID and source RLOC. So an ITR just puts its own IP address in the source 'Routing Locator' field when it builds the outer header 🫶 That source RLOC address, like every other RLOC, MUST be globally routable ✨
so an ITR doesn't have to do an EID-to-RLOC mapping lookup when a received data packet is multicast, or when it's handling a source-specific Join (via IGMPv3 or PIM) 🙈 The source RLOC gets picked by the multicast routing protocol at the receiver site, so the EID-to-RLOC translation actually happens at control time instead 🔥
another option is for the ITR to not encapsulate a multicast packet and just let the host-built packet flow into the core, even if its source address comes from the EID namespace 😭 If PIM in the core uses the RPF-Vector TLV [RFC5496], then core routers can do RPF toward the ITR (the locator address, which is injected into core routing) instead of the host source address (the EID address, which is not injected into core routing). ate 💀
but to avoid any EID-based multicast state in the network core, the first approach is the one picked for LISP-Multicast 🦋 More on LISP-Multicast and interworking with non-LISP sites is in [RFC6831] and [RFC6832] 🌈
12. Security Considerations 🔐
this section is serious, bestie. read it all 🚨
it's believed that most of the security mechanisms will live in the mapping database service when control-plane procedures are used to get EID-to-RLOC mappings 💜 For data-plane-triggered mappings (the kind this spec describes), protection against ETR spoofing comes from route-returnability (see Section 3), shown by a 24-bit 'Nonce' field in the LISP encapsulation header and a 64-bit 'Nonce' field in the LISP control message 🎀
the nonce, plus the ITR only accepting solicited Map-Replies, gives a basic level of security that's kinda like what the current Internet routing system has 🌸 Off-path attackers have a hard time here because they don't know the nonce values. Sending a huge pile of packets to accidentally guess the right nonce is possible, but that alone would already be a denial-of-service (DoS) attack 😭 On-path attackers can do way worse stuff, but they can already do serious stuff in the current Internet too, like eavesdropping, blocking, or redirecting traffic. more discussion on this is in Section 6.1.5.1 📖
LISP doesn't rely on a PKI or any heavier authentication system 🙅♀️ Those would clash with one of LISP's main goals: scalability 💖
DoS prevention depends on implementations rate-limiting Map-Requests and Map-Replies going to the control plane, and rate-limiting how many data-triggered Map-Replies happen 🚦
an incorrectly implemented or malicious ITR might ignore the Priority and Weights that the ETR gives in its Map-Reply 💀 That traffic steering would only touch traffic sent from that ITR's site, and it's no worse than if the site launched a bandwidth DoS attack on (one of) the ETR's ingress links. the ITR's site wouldn't really gain anything by ignoring the Weights, and it would probably get better service by following them 🫶
to handle map-cache exhaustion attempts in an ITR/PITR, implementations should think about putting a maximum cap on stored entries, with a reserve list for special or frequently accessed sites 🧚 This should be a configuration policy set by the network administrator who manages the ITRs and PITRs 👑 When overlapping EID-Prefixes show up across multiple Map-Cache entries, the integrity of the set has to be fully kept. So if a more-specific entry can't be added because the cap is hit, then none of the less-specific entries should be stored in the map-cache either 🙈
since the ITR/PITR keeps a cache of EID-to-RLOC mappings, cache sizing and maintenance are things to keep in mind during implementation 🍓 It's a good idea to have instrumentation in place to detect cache thrashing. Implementation experimentation will decide which cache management strategies work best ✨ Generally, it's hard to defend against cache-thrashing attacks 😭 And an undersized cache in an ITR/PITR doesn't just hurt the site or region it serves. It can also push up Map-Request load on the mapping system 💅
"piggybacked" mapping data (see Section 6.1.3) explains how to handle those mappings. It also allows an ETR to temporarily accept such a mapping before verifying it when it's running in "trusted" environments 🦋 In that case, there's a potential threat that a fake mapping could get inserted into a map-cache, even if only for a short while 💀 As noted in Section 6.1.3, an ETR MUST be specifically configured to run in that mode, and it might usefully only consider some specific ITRs as running in that same trusted environment 🔥
there's a security risk built into the fact that ETRs generate the EID-Prefix they respond with. An ETR can claim a shorter prefix than the one it's actually responsible for 😬 Ways to ease or fix this will be looked at in the future [LISP-SEC] 🌈
spoofing inner-header addresses of LISP-encapsulated packets is possible, same as with any tunneling mechanism 🫠 ITRs MUST verify that a packet's source address is an EID belonging to the site's EID-Prefix range before encapsulating it. An ETR must only decapsulate and forward datagrams whose inner-header destination matches one of its EID-Prefix ranges. If, after receipt and decapsulation, a datagram's destination EID doesn't match one of the ETR's configured EID-Prefixes, the ETR MUST drop it 🚫 If a LISP-encapsulated packet arrives at an ETR, it SHOULD compare the inner-header source EID address and the outer-header source RLOC address with the mapping that's in the mapping database. That way, when spoofing attacks happen, the outer-header source RLOC address can be used to trace the attack back to the source site, using existing operational tools 🕵️♀️
this experimental spec doesn't cover automated key management (AKM). BCP 107 [RFC4107] has guidance on that 📚 Also, at the time of writing, there's a ton of work going on to improve the security of the routing system [RFC6518] [RFC6480] [BGP-SEC] [LISP-SEC] 💪 Future LISP work should deal with the issues in BCP 107 along with any other open security considerations, which might mean changes to this spec 🫶
13. Network Management Considerations 🛠️
there are considerations for network management tools so the LISP protocol suite can be run operationally 🌸 You'll find those mechanisms in [LISP-MIB] and [RFC6835] 💖
14. IANA Considerations 📋
this section tells the Internet Assigned Numbers Authority (IANA) how to register values for LISP, following BCP 26 [RFC5226] 🎀
there are four namespaces in LISP that have been registered (they're listed in the subsections below) 🦋
- 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: "Specification Required", "IETF Review", "Experimental Use", and "First Come First Served". 🧚
14.1. LISP ACT and Flag Fields 🚩
new ACT values (Section 6.1.4) can be allocated through IETF review or IESG approval. This spec has already allocated four values (Section 6.1.4) ✨
LISP also has a bunch of flag fields and reserved fields, like the LISP header flags field (Section 5.3). New bits for flags in these fields can be implemented after IETF review or IESG approval, but they don't need to be managed by IANA 🌈
14.2. LISP Address Type Codes 🏷️
LISP Address [LCAF] type codes go from 0 to 255 📊 New type codes MUST be allocated consecutively, starting at 0 💅 Type Codes 0-127 get assigned by IETF review or IESG approval 🫶
Type Codes 128-255 are open under the [RFC5226] First Come First Served policy 🦋
this registry starts out empty and is set up for future use in experimental work on LISP Canonical Address Format (LCAF) values 🧪 See [LCAF] for other possible unapproved address encodings. The unapproved LCAF encodings are an area for further study and experimentation 🔬
14.3. LISP UDP Port Numbers 🔌
IANA has allocated UDP ports 4341 and 4342 for lisp-data and lisp-control operation, respectively 💖 IANA has also updated the descriptions for UDP ports 4341 and 4342 like this:
lisp-data 4341 udp LISP Data Packets
lisp-control 4342 udp LISP Control Packets14.4. LISP Key ID Numbers 🔑
Here are the Key ID values this spec defines, for use in any packet type that has a 'Key ID' field 💅:
Name Number Defined in
-----------------------------------------------
None 0 n/a
HMAC-SHA-1-96 1 [RFC2404]
HMAC-SHA-256-128 2 [RFC4868]Number values run from 0 to 65535, and they're handed out first come, first served 🎟️
15. Known Open Issues and Areas of Future Work 🧪
Okay so, this is an experimental spec, which means it's by definition not finished yet 🙈 Here's where more experience and work are still needed:
- Right now, the only mapping database system defined for storing EID-to-RLOC mapping info is [RFC6836] 🗺️ Research into other mapping database systems is strongly encouraged!
- Failure and recovery of LISP site partitioning (see Section 6.4) in the presence of redundant configuration (see Section 8.5) still needs more research and experimentation 🔍
- The behaviour of map-cache management under exceptional conditions, like denial-of-service attacks, isn't fully understood yet 😬 More experience is needed to figure out whether current caching methods are practical or need further development. The performance, scaling, and security characteristics of the map-cache will be discovered as part of this experiment. The performance metrics being observed are packet reordering associated with the LISP Data-Probe, and loss of the first packet in a flow associated with map-caching. The impact of these on TCP will also be observed. See Section 12 for additional thoughts and considerations 💭
- Preliminary work has been done so sites using LISP can interconnect with the rest of the Internet 🌐 This work is documented in [RFC6832], but it still needs further experimentation and experience.
- Right now there's no mechanism defined for automated key management for message authentication 🔐 Addressing automated key management is necessary before this spec can be developed into a Standards Track RFC. See Section 12 for further details on security considerations.
- To maintain security and stability, Internet protocols typically isolate the control and data planes 🧱 So user activity cannot cause control-plane state to be created or destroyed. LISP doesn't keep this separation, though. How much the loss of separation affects security and stability is a topic for experimental observation.
- LISP allows for different mapping database systems to be used 🗂️ Only one, [RFC6836], is currently well defined, and each mapping database will likely have some impact on the security of the EID-to-RLOC mappings. How each mapping database system's security properties affect LISP overall is for further study.
- We need an examination of the implications of LISP on Internet traffic, applications, routers, and security 👀 This will help implementors understand the consequences for network stability, routing protocol function, routing scalability, migration and backward compatibility, and implementation scalability. That last one is influenced by additional protocol components, additional state, and additional processing for encapsulation, decapsulation, and liveness.
- Experiments need to verify that LISP produces no significant change in how protocols behave between end-systems over a LISP infrastructure, compared to running directly between those same end-systems 🧪✨
- Experiments need to verify that the issues raised in the Critique section of [RFC6115] are either insignificant or have been addressed by updates to LISP 📝
Other LISP documents may also include open issues and areas for future work 🌸
16. References 📚
Here are all the references, split into the must-reads and the nice-to-reads 🤓
16.1. Normative References
- [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
- [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
- [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
- [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
- [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
- [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
- [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
- [RFC6115] Li, T., "Recommendation for a Routing Architecture", RFC 6115, February 2011.
- [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
- [RFC6833] Farinacci, D. and V. Fuller, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013.
- [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, January 2013.
- [RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013.
16.2. Informative References
- [AFI] IANA, "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>. - [BGP-SEC] Lepinski, M. and S. Turner, "An Overview of BGPSEC", Work in Progress, May 2012.
- [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed Enhancement to the Internet Architecture", 1999,
<http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. - [CONS] Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", Work in Progress, April 2008.
- [EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID Mappings Multicast Across Cooperating Systems for LISP", Work in Progress, November 2007.
- [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", Work in Progress, January 2013.
- [LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin, "Renumbering: Threat or Menace?", Usenix Tenth System Administration Conference (LISA 96), October 1996.
- [LISP-DEPLOY] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-Pascual, J., and D. Lewis, "LISP Network Element Deployment Considerations", Work in Progress, October 2012.
- [LISP-MIB] Schudel, G., Jain, A., and V. Moreno, "LISP MIB", Work in Progress, January 2013.
- [LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", Work in Progress, October 2012.
- [LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., Saucez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", Work in Progress, October 2012.
- [LOC-ID-ARCH] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", Work in Progress, January 2009.
- [OPENLISP] Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP Implementation Report", Work in Progress, July 2008.
- [RADIR] Narten, T., "On the Scalability of Internet Routing", Work in Progress, February 2010.
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
- [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
- [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
- [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
- [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
- [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
- [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007.
- [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007.
- [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
- [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012.
- [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, January 2013.
- [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013.
- [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, January 2013.
- [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database", RFC 6837, January 2013.
- [UDP-TUNNELS] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", Work in Progress, January 2013.
- [UDP-ZERO] Fairhurst, G. and M. Westerlund, "Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums", Work in Progress, December 2012.
Appendix A. Acknowledgments 💖
Okay, bestie, first up is a big shoutout to Dave Oran 🌸, who planted the seeds for the initial LISP ideas. He's still helping the LISP authors out, and we're so grateful.
Next, a seriously appreciative thank you to Noel Chiappa 👑. For decades he's been pushing the architecture idea of separating location from identity. He also gave super detailed reviews of the LISP architecture and documents, and he's been hyped about making LISP a practical, incremental transition for the Internet. Iconic behavior, honestly 🫶.
The authors also want to thank everyone who brought discussions and ideas to this proposal. The whole group chat is: Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, and Alia Atlas. Everyone on that list is a legend 🦋✨.
This work started in the Routing Research Group (RRG) of the IRTF. An individual submission was later converted into the IETF LISP working group document that became this RFC. So it's a glow-up story, honestly 🌈.
Last but definitely not least, the LISP working group wants to give a special thanks to Jari Arkko 🔥. He was the Internet Area AD at the time the LISP documents were being prepared for IESG last call. He did meticulous reviews and detailed commentary on the 7 working group last call documents that were progressing toward experimental RFCs. That's dedication, bestie 💅.
Authors' Addresses 🎀
Here are the authors, with their contact info exactly as it appears in the RFC:
Dino Farinacci
Cisco Systems
Tasman Drive
San Jose, CA 95134
USA
EMail: farinacci@gmail.com
Vince Fuller
EMail: vaf@vaf.net
Dave Meyer
Cisco Systems
170 Tasman Drive
San Jose, CA
USA
EMail: dmm@1-4-5.net
Darrel Lewis
Cisco Systems
170 Tasman Drive
San Jose, CA
USA
EMail: darlewis@cisco.comThat's a wrap on the whole RFC, babes! 🧚💜
📦 where this page comes from
- ietf: rfc6830 2013-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms