RFC 6832
Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites
Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites 🦋
okay bestie, let's get into RFC 6832 🎀 It's an IETF document, so it's a bit of a stiff vibe on the surface, but the ideas are so iconic once you get them.
Here's the ID card 🪪. It's written by D. Lewis, D. Meyer, D. Farinacci (all from Cisco Systems), and V. Fuller. It's dated January 2013, and the category is Experimental, meaning it's for trying stuff out, not a full standard. The ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so no drama there 💅
Abstract ✨
Okay, so the big idea is this. LISP-speaking sites 💜 use Endpoint Identifiers (EIDs) instead of regular IP addresses in the source and destination fields of everything they send or receive. EIDs look exactly like IPv4 or IPv6 addresses, but routes to them usually aren't in the global routing system. So non-LISP sites (which might be on IPv4, IPv6, or both) need a way to actually talk to LISP sites. ngl this is the whole problem 😭
This document brings three fixes 🔥:
- The LISP Proxy Ingress Tunnel Router (Proxy-ITR): a new network element that acts as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP hosts.
- NAT on LISP ITRs and Egress Tunnel Routers (ETRs): it swaps non-routable EIDs for routable IP addresses. It's giving translation energy 🌸
- The Proxy Egress Tunnel Router (Proxy-ETR): for when a LISP ITR can't send packets to non-LISP sites without encapsulation.
Status of This Memo 🧾
Real talk, this one is not an Internet Standards Track spec. It's published so people can examine it, implement it experimentally, and evaluate it 🧪
It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🤓
For the current status, errata, and where to send feedback, go to http://www.rfc-editor.org/info/rfc6832.
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 publication date. Please read these carefully, because they describe 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. Definition of Terms .............................................5
3. LISP Interworking Models ........................................6
4. Routable EIDs ...................................................7
4.1. Impact on Routing Table ....................................7
4.2. Requirement for Sites to Use BGP ...........................7
4.3. Limiting the Impact of Routable EIDs .......................7
4.4. Use of Routable EIDs for Sites Transitioning to LISP .......7
5. Proxy Ingress Tunnel Routers ....................................8
5.1. Proxy-ITR EID Announcements ................................8
5.2. Packet Flow with Proxy-ITRs ................................9
5.3. Scaling Proxy-ITRs ........................................11
5.4. Impact of the Proxy-ITR's Placement in the Network ........11
5.5. Benefit to Networks Deploying Proxy-ITRs ..................11
6. Proxy Egress Tunnel Routers ....................................12
6.1. Packet Flow with Proxy-ETRs ...............................12
7. LISP-NAT .......................................................13
7.1. Using LISP-NAT with LISP-NR EIDs ..........................14
7.2. LISP Sites with Hosts Using RFC 1918 Addresses Sending
to Non-LISP Sites .........................................15
7.3. LISP Sites with Hosts Using RFC 1918 Addresses Sending
Packets to Other LISP Sites ...............................15
7.4. LISP-NAT and Multiple EIDs ................................16
8. Discussion of Proxy-ITRs, LISP-NAT, and Proxy-ETRs .............16
8.1. How Proxy-ITRs and Proxy-ETRs Interact ....................17
9. Security Considerations ........................................17
10. Acknowledgments ...............................................18
11. References ....................................................18
11.1. Normative References .....................................18
11.2. Informative References ...................................181. Introduction 🌈
This document describes how LISP [RFC6830] sites using EIDs that aren't globally routed can interoperate with non-LISP sites. The key behaviour of separating Locators from Endpoint IDs is that EID-Prefixes are normally not advertised into the Internet's Default-Free Zone (DFZ). (See Section 4 for the exception case.) Basically, only Routing Locators (RLOCs) travel through the DFZ 🛣️ But existing Internet sites (and their hosts) that don't run LISP still have to be able to reach sites numbered from LISP EID space. This document describes three mechanisms that give reachability between LISP-capable sites and those that aren't.
The first mechanism uses the new LISP Proxy Ingress Tunnel Router (Proxy-ITR) to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. The second mechanism adds a form of Network Address Translation (NAT) to Tunnel Routers (xTRs, where "xTR" refers to either an ITR or an ETR) to swap in routable IP addresses for non-routable EIDs. The last network element is the LISP Proxy Egress Tunnel Router (Proxy-ETR), which acts as an intermediate Egress Tunnel Router (ETR) for LISP sites that need to encapsulate LISP packets headed to non-LISP sites 🧚
Here's the roadmap so you know where to look:
- Section 2 defines the terms used throughout the document.
- Section 3 describes the different cases where interworking mechanisms are needed.
- Section 4 describes the relationship between the new EID-Prefix space and the IP address space the current Internet uses.
- Section 5 introduces Proxy-ITRs and how they operate.
- Section 6 introduces Proxy-ETRs and how they operate.
- Section 7 defines how ETRs use NAT to translate non-routable EIDs into routable IP addresses.
- Section 8 describes the relationship between the asymmetric and symmetric interworking mechanisms (Proxy-ITRs and Proxy-ETRs vs. LISP-NAT).
Note that any successful interworking model should be independent of any particular EID-to-RLOC mapping algorithm. This document doesn't comment on the value of any particular LISP mapping system 🙈
Several areas about LISP and non-LISP interworking are still open for further study. These include looking at how LISP-NAT affects Internet traffic and applications, understanding why anyone would deploy and operate Proxy Tunnel Routers, the impact of EID routes originated into the DFZ, and the effects of Proxy Tunnel Routers or LISP-NAT on Internet traffic and applications. Until these are fully understood, the interworking mechanisms described here might be hard to deploy or could have unintended consequences for applications. > Sis, it's not all sorted yet, so go in with eyes open 👀
2. Definition of Terms 📖
Here are the definitions, bestie 💕
- Default-Free Zone: The Default-Free Zone (DFZ) is the collection of all Internet autonomous systems that don't need a default route to send a packet to any destination.
- LISP Routable (LISP-R) Site: A LISP site whose addresses are used as both globally routable IP addresses and LISP EIDs. ✨
- LISP Non-Routable (LISP-NR) Site: A LISP site whose addresses are EIDs only. These EIDs aren't found in the legacy Internet routing table 🙅♀️
- LISP Proxy Ingress Tunnel Router (Proxy-ITR): Proxy-ITRs provide connectivity between sites that use LISP EIDs and sites that don't. They act as gateways between the parts of the Internet that aren't using LISP (the legacy Internet). A given Proxy-ITR advertises one or more highly aggregated EID-Prefixes into the public Internet, and it acts as the ITR for traffic it receives from the public Internet. LISP Proxy-ITRs are described in Section 5. 🦋
- LISP Network Address Translation (LISP-NAT): Network address translation between EID space assigned to a site and RLOC space also assigned to that same site. LISP-NAT is described in Section 7.
- LISP Proxy Egress Tunnel Router (Proxy-ETR): Proxy-ETRs give a LISP site's ITRs (routable or non-routable EID) the ability to send packets to non-LISP sites in cases where unencapsulated packets (the default mechanism) would fail to be delivered. A Proxy-ETR works by having an ITR encapsulate all non-LISP-destined traffic to a pre-configured Proxy-ETR. LISP Proxy-ETRs are described in Section 6. 🍓
- EID Sub-Namespace: A power-of-two block of aggregatable Locators set aside for LISP interworking. 🌸
For the definitions of other terms (notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR)), check out the LISP specification [RFC6830]. Go read that next, it's a whole vibe 💜
3. LISP Interworking Models 🦋
okay so bestie, there are 4 unicast connectivity cases that describe how sites can send packets to each other 💖
- non-LISP site to non-LISP site
- LISP site to LISP site
- LISP site to non-LISP site
- non-LISP site to LISP site
ngl Cases 3 and 4 look like twins, but they have sneaky differences because of how the packets get started 🙈
Case 1 is just the Internet as we know it today, so we're not going to talk about it any more here 💅 Case 2 is documented in [RFC6830], and there are no new interworking requirements there because there are no new protocol requirements placed on intermediate non-LISP routers ✨
In Case 3, LISP site to non-LISP site, a LISP site can (in most cases) send packets to a non-LISP site because the non-LISP site prefixes are routable 🌸 The non-LISP sites don't have to do anything new to receive packets, which is so iconic 👑 The only thing the LISP site has to do is know when NOT to LISP-encapsulate packets. An ITR knows explicitly that the destination is non-LISP if the destination IP address of an IP packet matches a (negative) Map-Cache entry that has the action 'Natively-Forward' 🧚
There could be some situations where (unencapsulated) packets originated by a LISP site may not be forwarded to a non-LISP site. Those cases are reviewed in Section 6 (Proxy Egress Tunnel Routers) 🫶
Case 4 is typically the most challenging 😭 It happens when a host at a non-LISP site wants to send traffic to a host at a LISP site. If the source host uses a (non-globally routable) EID as the destination IP address, the packet gets forwarded inside the source site until it reaches a router that cannot forward it (due to lack of a default route), and then the traffic is dropped 💀 For traffic not to be dropped, some mechanism to make this destination EID routable MUST be in place. Sections 5 (Proxy-ITRs) and 7 (LISP-NAT) describe two such mechanisms 🔥 Case 4 also applies to non-LISP packets (as in Case 3) that are returning to the LISP site 🍓
4. Routable EIDs 💜
An obvious way to achieve interworking between LISP and non-LISP hosts is for a LISP site to simply announce EID-Prefixes into the DFZ, much like the current routing system, effectively treating them as "Provider-Independent" (PI) prefixes. Having a site do this is undesirable, as it defeats one of the primary goals of LISP, which is to reduce global routing system state 😤
4.1. Impact on Routing Table 🌈
If EID-Prefixes are announced into the DFZ, the impact is similar to the case in which LISP has not been deployed, because these EID-Prefixes will be no more aggregatable than existing PI addresses. Such a mechanism is not viewed as a viable long-term solution, but it may be a viable short-term way for a site to transition a portion of its address space to EID space without changing its existing routing policy 🦋
4.2. Requirement for Sites to Use BGP 🎀
Routable EIDs might require non-LISP sites today to use BGP to, among other things, originate their site's routes into the DFZ, in order to enable ingress Traffic Engineering. Relaxing this requirement (and thus potentially reducing global DFZ routing state) while still letting sites control their ingress Traffic Engineering policy is a design goal of LISP ✨
4.3. Limiting the Impact of Routable EIDs 💅
Two schemes are proposed to limit the impact of having EIDs announced in the current global Internet routing table:
- Section 5 discusses the LISP Proxy Ingress Tunnel Router, an approach that provides ITR functionality to bridge LISP-capable and non-LISP-capable sites.
- Section 7 discusses another approach, LISP-NAT, in which NAT [RFC2993] is combined with ITR functionality to limit the impact of routable EIDs on the Internet routing infrastructure.
4.4. Use of Routable EIDs for Sites Transitioning to LISP 🧚
A primary design goal for LISP (and other Locator/ID separation proposals) is to facilitate topological aggregation of namespaces used for the path computation, and thus decrease global routing system overhead. Another goal is to achieve the benefits of improved aggregation as soon as possible. Individual sites advertising their own routes for LISP EID-Prefixes into the global routing system is therefore NOT RECOMMENDED 🙅
That being said, single-homed sites (or multihomed sites that are not leaking more-specific exceptions) that are already using provider-aggregated prefixes can use these prefixes as LISP EIDs without adding state to the routing system 🫶 In other words, such sites do not cause additional prefixes to be advertised. For such sites, connectivity to a non-LISP site does not require interworking machinery, because the "PA" (Provider-Assigned) EIDs are already routable (they are effectively LISP-R type sites). Their EIDs are found in the LISP mapping system, and their (aggregate) PA prefix(es) are found in the DFZ of the Internet 🌸
The continued announcements of an existing site's Provider-Independent (PI) prefix(es) are of course under the control of that site 👑 Some period of transition, where a site is found both in the LISP mapping system and as a discrete prefix in the Internet routing system, may be a viable transition strategy. Care SHOULD be taken not to advertise additional more-specific LISP EID-Prefixes into the DFZ 🍓
5. Proxy Ingress Tunnel Routers 🎀
Proxy Ingress Tunnel Routers (Proxy-ITRs) allow non-LISP sites to send packets to LISP-NR sites. A Proxy-ITR is a new network element that shares many characteristics with the LISP ITR 🦋 Proxy-ITRs allow non-LISP sites to send packets to LISP-NR sites without any changes to protocols or equipment at the non-LISP site 🔥 Proxy-ITRs have two primary functions:
Originating EID Advertisements: Proxy-ITRs advertise highly aggregated EID-Prefix space on behalf of LISP sites so that non-LISP sites can reach them ✨
Encapsulating Legacy Internet Traffic: Proxy-ITRs also encapsulate non-LISP Internet traffic into LISP packets and route them towards their destination RLOCs 💜
5.1. Proxy-ITR EID Announcements 🌈
A key part of Proxy-ITR functionality is to advertise routes for highly aggregated EID-Prefixes into parts of the global routing system. Aggressive aggregation is performed to minimize the number of new announced routes. In addition, careful placement of Proxy-ITRs can greatly reduce the advertised scope of these new routes. To this end, Proxy-ITRs SHOULD be deployed close to non-LISP-speaking sites rather than close to LISP sites 🧚 Such deployment not only limits the scope of EID-Prefix route advertisements but also allows the traffic forwarding load to be spread among many Proxy-ITRs 💅
5.2. Packet Flow with Proxy-ITRs 🦋
What follows is an example of the path a packet would take when using a Proxy-ITR 🌸 In this example, the LISP-NR site is given the EID-Prefix 192.0.2.0/24. For the purposes of this example, neither this prefix nor any covering aggregate is present in the global routing system. In other words, without the Proxy-ITR announcing 192.0.2.0/24, if a packet with this destination were to reach a router in the Default-Free Zone, it would be dropped 😭 The following diagram describes a high-level view of the topology 👑
Internet DFZ
.--------------------------------.
/ \
| Traffic Encap'd to Site's |
| +-----+ RLOC(s) | LISP Site:
| |P-ITR|=========> |
| +-----+ +--+ +-----+ |
| | |PE+------+CE 1 |-|
| | Originated Route +--+ +-----+ | +----+
| V 192.0.2.0/24 | |-|Host|
| +--| +-----+ | +----+
| |PE+------+CE 2 |-| 192.0.2.1
| +---+ +--+ +-----+ |
\ |PE | /
'---------------+-+-+------------' Site EID-Prefix:
| 192.0.2.0/24
| ^
| |
+--+--+ | Traffic
Non LISP Site: | CE | | to
+--+--+ | 192.168.2.1
| |
-----------
|
+----+
|Host|
+----+
Figure 1: Example of Proxy-ITR Packet FlowA full protocol exchange example follows 🧚
- The source host makes a DNS lookup EID for the destination and gets 192.0.2.1 in return 💖
- The source host has a default route to the Customer Edge (CE) router and forwards the packet to the CE 🌸
- The CE has a default route to its Provider Edge (PE) router and forwards the packet to the PE ✨
- The PE has a route to 192.0.2.0/24, and the next hop is the Proxy-ITR 🦋
- The Proxy-ITR has or acquires a mapping for 192.0.2.1 and LISP-encapsulates the packet. The outer IP header now has a destination address of one of the destination EID's RLOCs. The outer source address of this encapsulated packet is the Proxy-ITR's RLOC 🔥
- The Proxy-ITR looks up the RLOC and forwards the LISP packet to the next hop, after which it is forwarded by other routers to the ETR's RLOC 🌈
- The ETR decapsulates the packet and delivers the packet to the 192.0.2.1 host in the destination LISP site 👑
- Packets from host 192.0.2.1 will flow back through the LISP site's ITR. Such packets are not encapsulated because the ITR knows that the destination (the original source) is a non-LISP site. The ITR knows this because it can check the LISP mapping database for the destination EID and, on a failure, determines that the destination site is not LISP enabled 💅
- Packets are then routed natively and directly to the destination (original source) site 🍓
Note that in this example the return path is asymmetric, so return traffic will not go back through the Proxy-ITR. This is because the LISP-NR site's ITR will discover that the originating site is not a LISP site and will not encapsulate the returning packet (see [RFC6830] for details of ITR behavior) 🫶
The asymmetric nature of traffic flows allows the Proxy-ITR to be relatively simple 💜 It will only have to encapsulate LISP packets ✨
5.3. Scaling Proxy-ITRs 🦋
Okay so Proxy-ITRs pull in traffic by announcing the LISP EID namespace into parts of the non-LISP-speaking global routing system. Bestie, there are a few ways a network can keep one Proxy-ITR from getting more traffic than it can handle 💅
- The Proxy-ITR's aggregate routes might be selectively announced, which is a coarse way to control how much traffic that Proxy-ITR attracts. For example, some of the routes being announced might be tagged with a BGP community, and their scope of announcement gets limited by the provider's routing policy 🎀
- The same address might be announced by multiple Proxy-ITRs so they can share the traffic using IP Anycast. The asymmetric nature of traffic flows through the Proxy-ITR means that operationally, a set of Proxy-ITRs would be super similar to existing anycasted services like DNS caches 🌸 Multiple Proxy-ITRs could advertise the same BGP Next Hop IP address as their RLOC, and traffic would get attracted to the nearest Next Hop according to the network's IGP ✨
5.4. Impact of the Proxy-ITR's Placement in the Network 🧚
There are a bunch of approaches a network could take when placing Proxy-ITRs, and the placement really matters. Putting the Proxy-ITR near the source of traffic lets communication between the non-LISP site and the LISP site have the least "stretch" (aka the fewest forwarding hops compared to an optimal path between the sites) 💖
Some proposals, like the Core Router-Integrated Overlay [CRIO], have suggested grouping Proxy-ITRs near an arbitrary subset of ETRs and announcing a 'local' subset of EID space. Ngl this model cannot guarantee minimum stretch if the EID-Prefix route advertisement points change 😬 Such a change might happen if a site adds, removes, or replaces one or more of its ISP connections.
5.5. Benefit to Networks Deploying Proxy-ITRs 💜
When packets headed for LISP-NR sites arrive and get encapsulated at a Proxy-ITR, a new LISP packet header gets prepended. This sets the packet's destination to the destination ETR's RLOC. Since packets are routed toward RLOCs, they can potentially follow the Proxy-ITR network's Traffic Engineering policies better (like closest exit routing) 🍓
Here's the tea: providers that are not default-free and don't deploy Proxy-ITRs end up sending more traffic over expensive transit links (assuming their upstreams have deployed Proxy-ITRs) instead of to the ETR's RLOC addresses. They may actually have cheaper and closer connectivity to those, via settlement-free peering for example 🫶 A corollary to this is that large transit providers deploying Proxy-ITRs may attract more traffic, and therefore more revenue, from their customers. Main character money moves 👑
6. Proxy Egress Tunnel Routers 🌈
Proxy Egress Tunnel Routers (Proxy-ETRs) let LISP sites send packets to non-LISP sites when the access network doesn't allow the LISP site to send packets with its EID(s) as the source address. A Proxy-ETR is a brand new network element that, conceptually, acts as an ETR for traffic destined to non-LISP sites ✨ This also means an ITR doesn't have to decide whether to encapsulate or not. It can always encapsulate, which is so much simpler 🙈 An ITR still encapsulates packets destined for LISP sites (no change there), and those get routed directly to the correspondent site's ETR. All other packets, the ones destined to non-LISP sites, get sent to the originating site's Proxy-ETR.
There are two primary reasons why sites would want to use a Proxy-ETR:
- Avoiding strict Unicast Reverse Path Forwarding (uRPF) failures: Some providers' access networks require the source of the emitted packets to be within the addressing scope of the access network (see Section 9). Hard pass on that for LISP sites, so Proxy-ETRs save the day 🦋
- Traversing a different IP Protocol: A LISP site may want to transmit packets to a non-LISP site where some of the intermediate network doesn't support the particular IP protocol wanted (v4 or v6). Proxy-ETRs can let this LISP site's data 'hop over' that gap by using LISP's support for mixed-protocol encapsulation 🧚
6.1. Packet Flow with Proxy-ETRs 🎀
Packets from a LISP site can reach a non-LISP site with the help of a Proxy-ETR. An ITR is simply configured to send all non-LISP traffic (the stuff it normally would've forwarded natively, non-encapsulated) to a Proxy-ETR. If the ITR uses one or more Map-Resolvers, it will encapsulate packets that match the received Negative Map-Cache to the configured Proxy-ETR(s). If the ITR is connected to the mapping system directly, it will encapsulate all packets that are cache misses to the configured Proxy-ETR 🍓 Note that this outer encapsulation to the Proxy-ETR may be in an IP protocol other than the (inner) encapsulated data. Routers then use the LISP (outer) header's destination address to route the packets toward the configured Proxy-ETR 💅
A Proxy-ETR should verify the (inner) source EID of the packet at decapsulation time, to confirm it's from a configured LISP site. This is how we stop spoofed inner sources from getting encapsulated through the Proxy-ETR 🛡️ no sneaky stuff allowed!
Here's an example of the path a packet takes when using a Proxy-ETR 👀 The LISP-NR (or LISP-R) site has the EID-Prefix 192.0.2.0/24, and it's trying to reach a host at a non-LISP site with the IP prefix 198.51.100.0/24. For this example, the destination (198.51.100.0/24) is found in the Internet's routing system.
A full protocol exchange example goes like this:
- The source host makes a DNS lookup for the destination and gets 198.51.100.100 (an IP address of a host in the non-LISP site) back 💖
- The source host has a default route to the Customer Edge (CE) router and forwards the packet toward the CE 🌸
- The CE is a LISP ITR and is configured to encapsulate traffic destined for non-LISP sites to a Proxy-ETR 🧁
- The Proxy-ETR decapsulates the LISP packet and forwards the original packet to its next hop 🫧
- The packet is then routed natively and directly to the destination (non-LISP) site 198.51.100.0/24 🏁
Heads up bestie: in this example the return path is asymmetric, so return traffic will NOT go back through the Proxy-ETR. That means that in order to reach LISP-NR sites, non-LISP sites still have to use Proxy-ITRs. Plan accordingly 😭
7. LISP-NAT 💅
LISP Network Address Translation (LISP-NAT) is a limited form of NAT [RFC2993] ✨ It's designed to enable interworking between non-LISP sites and LISP-NR sites by making sure the LISP-NR's site addresses are always routable. LISP-NAT pulls this off by translating a host's source address from an 'inner' (LISP-NR EID) value to an 'outer' (LISP-R) value, and keeping that translation in a table it can reference for later packets 🦋
Also, existing RFC 1918 [RFC1918] sites can use LISP-NAT to talk to both LISP and non-LISP sites 🌈
The basic concept is that when transmitting a packet, the ITR swaps a non-routable EID source address for a routable one, which lets packets make it back to the site. Just a heads up that this section is a rough overview of what could be done. It is not an exhaustive guide to IPv4 NAT 🙈
There are two main cases that involve LISP-NAT:
- Hosts at LISP sites that use non-routable global EIDs speaking to non-LISP sites using global addresses 💜
- Hosts at LISP sites that use RFC 1918 private EIDs speaking to other sites, who may be either LISP or non-LISP sites 🫶
Note that LISP-NAT isn't needed for LISP-R (routable global EID) sources. This case happens when a site announces its prefix into both the LISP mapping system and the Internet DFZ. Because the LISP-R source's address is routable, return packets can natively reach the site, so no drama 👑
7.1. Using LISP-NAT with LISP-NR EIDs 🎀
LISP-NAT lets a host with a LISP-NR EID send packets to non-LISP hosts by translating the LISP-NR EID to a globally unique address (a LISP-R EID). That globally unique address may be either a PI or a PA address 🍓
Here's an example. A site has been assigned the LISP-NR EID 203.0.113.0/24. To use LISP-NAT, the site has also been given the PA EID 192.0.2.0/24, and it uses the first address (192.0.2.1) as the site's RLOC. The rest of this PA space (192.0.2.2 to 192.0.2.254) is used as a translation pool for this site's hosts that need to send packets to non-LISP hosts 💖
The translation table might look like this:
Site NR-EID Site R-EID Site's RLOC Translation Pool
==============================================================
203.0.113.0/24 192.0.2.0/24 192.0.2.1 192.0.2.2-254
Figure 2: Example Translation TableSo the host 203.0.113.2 sends a packet (destined for a non-LISP site, for this example) to its default route, which is the ITR 🧚 The ITR receives the packet and figures out that the destination is not a LISP site. How the ITR makes that determination is up to the ITR's implementation of the EID-to-RLOC mapping system being used (see, for example, [RFC6836]) 🔍
Next, the ITR rewrites the source address of the packet from 203.0.113.2 to 192.0.2.2, which is the first available address in the LISP-R EID space it has access to. The ITR keeps this translation in a table so it can reverse the process when it receives packets destined to 192.0.2.2 🌸
Finally, when the ITR forwards this packet without encapsulating it, it uses the entry in its LISP-NAT table to translate the destination IPs of returning packets to the proper host ✨
7.2. LISP Sites with Hosts Using RFC 1918 Addresses Sending to Non-LISP Sites 🌈
When hosts using RFC 1918 addresses want to send packets to non-LISP hosts, the LISP-NAT implementation acts a lot like an existing IPv4 NAT device doing address translation only (not port translation) 🦋 The ITR providing the NAT service must use LISP-R EIDs for its global address pool, and it must also provide all the standard NAT functions required today 💅
Note that the RFC 1918 addresses above are private addresses and not EIDs, and these RFC 1918 addresses are not found in the LISP mapping system 🙃
The source of the packet must be translated to a LISP-R EID in a manner similar to the one discussed in Section 7, and this packet must be forwarded to the ITR's next hop for the destination, without LISP encapsulation 🚀
7.3. LISP Sites with Hosts Using RFC 1918 Addresses Sending Packets to Other LISP Sites ✨
okay so LISP-NAT lets a host with an RFC 1918 address send packets to LISP hosts by translating that address into a LISP EID 🎀 After the translation, the communication between the source and destination ITR and ETRs keeps going the way it's described in [RFC6830] 💅
ngl, LISP EIDs talking to LISP EIDs is strictly speaking outside the scope of interworking 🙈 but it's included here so the whole LISP-NAT picture makes sense 🧚
Here's an example. A host has been given the RFC 1918 address 192.168.1.2 🍓 The site also got the LISP-R EID-Prefix 192.0.2.0/24 and uses the first address, 192.0.2.1, as its RLOC 🌸 The rest of this PA space (192.0.2.2 to 192.0.2.254) is a translation pool for this site's hosts that need to send packets to both non-LISP and LISP hosts 💖
The host at 192.168.1.2 sends a packet destined for a non-LISP site to its default route, which is the ITR ✨ The ITR gets the packet and figures out that the destination is a LISP site 🔥 How it makes that call is up to the ITR's implementation of the EID-to-RLOC mapping system 🦋
Next, the ITR rewrites the source address from 192.168.1.2 to 192.0.2.2, which is the first available address in the LISP EID space it has access to 💅 It keeps this translation in a table so it can reverse the process when packets destined to 192.0.2.2 come back 👑
Then the ITR LISP-encapsulates the packet (see [RFC6830] for details) 🫶 It uses the site's RLOC as the LISP outer header's source, and the translation address as the LISP inner header's source. When it decapsulates returning traffic, it looks up the entry in its LISP-NAT table, translates the returning packet's destination IP address, and forwards it to the proper host 😭✨
7.4. LISP-NAT and Multiple EIDs
okay this one is a whole vibe 🌈 With LISP-NAT, a given host can have two EIDs: the LISP-R EID and the LISP-NR EID 💜 When a site has two addresses a host might use for global reachability, the name-to-address directories may need to be modified 📖
This problem (global vs. local addressability) exists for NAT in general, but the specific issue described above is unique to location/identity separation schemes 🧠 Some of these have suggested running a separate DNS instance for new types of EIDs. That solves the problem, but it adds complexity for the site 😬 Alternatively, using Proxy-ITRs can mitigate this problem, because the LISP-NR EID can be reached in all cases 🎀
8. Discussion of Proxy-ITRs, LISP-NAT, and Proxy-ETRs 💅
the tea is that there are three suggested mechanisms for interworking LISP with non-LISP sites (for both IPv4 and IPv6) ☕ With the LISP-NAT option, the LISP site can manage and control the interworking on its own 👑 In the Proxy-ITR case, the site is not required to manage the advertisement of its EID-Prefix into the DFZ, but the cost is potentially adding stretch to the connections of non-LISP sites sending packets to the LISP site 🦋 The third option is Proxy-ETRs, which are optionally used by sites relying on Proxy-ITRs to mitigate two caveats for LISP sites sending packets to non-LISP sites 🌸 This means Proxy-ETRs are not usually expected to be deployed by themselves. They'll be used to assist LISP-NR sites that are already using Proxy-ITRs 🧚
8.1. How Proxy-ITRs and Proxy-ETRs Interact
there's a subtle difference between symmetrical (LISP-NAT) and asymmetrical (Proxy-ITR and Proxy-ETR) interworking techniques 🫶 Operationally, Proxy-ITRs and Proxy-ETRs can (and likely should) be decoupled. Proxy-ITRs are best deployed closest to non-LISP sites, and Proxy-ETRs are best located close to the LISP sites they're decapsulating for 💖 This asymmetric placement minimizes the stretch imposed on each direction of the packet flow, while still allowing for coarsely aggregated announcements of EIDs into the Internet's routing table ✨
9. Security Considerations 🚨
this section is serious business, so please read it all, bestie 💀
Like any router or LISP ITR, Proxy-ITRs will have the opportunity to inspect traffic at the time they encapsulate 👀 Where these devices sit in the network can have implications for discarding malicious traffic on behalf of ETRs that request this behavior (by setting the ACT (action) bit in Map-Reply packets [RFC6830] to "Drop" for an EID or EID-Prefix) 🔥 This is an area that would benefit from further experimentation and analysis 🧪
LISP interworking via Proxy-ITRs should have no impact on the existing network beyond what LISP ITRs and ETRs introduce when multihoming. That means if a site multihomes today (with LISP or BGP), there is a possibility of asymmetric flows 🌀
Proxy-ITRs and Proxy-ETRs will likely be operated by organizations other than the ones of the end site receiving or sending traffic. So care should be taken when selecting a Proxy-ITR/Proxy-ETR provider, to make sure the quality of service meets the site's expectations 📦
Proxy-ITRs and Proxy-ETRs share many of the same security issues as those discussed for ITRs and ETRs. For more info, check the security considerations section of [RFC6830] 🔐
As with traditional NAT, LISP-NAT will obscure the actual host LISP-NR EID behind the LISP-R addresses used as the NAT pool 🫣
When LISP sites send packets to non-LISP sites (and those non-LISP sites rely on Proxy-ITRs to enable interworking), the packets will have the site's EID as the source IP address 🙈 These EIDs may not be recognized by their ISP's Unicast Reverse Path Forwarding (uRPF) rules enabled on the Provider Edge router 😬 Several options are available to the service provider. For example, they could enable a less strict version of uRPF, where they only look for the existence of the EID-Prefix in the routing table 🧠 Another option, which is more secure, is to add a static route for the customer on the PE router but not redistribute this route into the provider's routing table 🔒 Finally, Proxy-ETRs can enable LISP sites to bypass this uRPF check by encapsulating all of their egress traffic destined to non-LISP sites to the Proxy-ETR (thus ensuring that the outer IP source address is the site's RLOC) 🦋
10. Acknowledgments 🫶
thank you so much to Christian Vogt, Lixia Zhang, Robin Whittle, Michael Menth, Xuewei Wang, and Noel Chiappa, who left super insightful comments about LISP interworking and transition mechanisms 💜
and a special thank you to Scott Brim for his initial brainstorming of these ideas and for his careful review 👑🌟
11. References 📚
11.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
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.11.2. Informative References
[CRIO] Zhang, X., Francis, P., Wang, J., and K. Yoshida, "CRIO:
Scaling IP Routing with the Core Router-Integrated
Overlay", November 2006.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.Authors' Addresses 💌
Darrel Lewis
Cisco Systems
EMail: darlewis@cisco.com
David Meyer
Cisco Systems
EMail: dmm@1-4-5.net
Dino Farinacci
Cisco Systems
EMail: farinacci@gmail.com
Vince Fuller
EMail: vaf@vaf.net📦 where this page comes from
- ietf: rfc6832 2013-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms