RFC 6836

Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)

📅 published January 2013, from ietf

RFC 6836: Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT) 🦋

okay bestie, this one is a LISP+ALT spec, so it's about how routers find the right place to ask for mapping info 🧚. It's an Experimental doc (not a Standards Track thing), published in January 2013 with ISSN 2070-1721. The authors are V. Fuller, D. Farinacci, D. Meyer, and D. Lewis, all from Cisco Systems 💅. It doesn't obsolete or update anything, since there's no Obsoletes or Updates field in the title block. The number is RFC 6836, and that's the one we're vibing with 🎀.

Abstract ✨

okay so this doc describes a simple distributed index system. A Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map-Resolver (MR) uses it to find the Egress Tunnel Router (ETR) that holds the mapping info for a particular Endpoint Identifier (EID) 🗺️. The MR can then ask that ETR for the actual mapping info, which is a list of Routing Locators (RLOCs) for the EID 💖. This index is called the Alternative Logical Topology (ALT), and it's built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and Generic Routing Encapsulation (GRE) 🌈.

Status of This Memo ✨

this doc is not an Internet Standards Track spec. It's published so people can examine it, try implementing it, 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 doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 🫶.

info about the current status of this doc, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc6836 🔗.

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 🌸.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read them carefully, because they describe your rights and restrictions for this doc. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as described in the Simplified BSD License 📜.

Table of Contents 🌈

1. Introduction ....................................................3
2. Definition of Terms .............................................5
3. The LISP-ALT Model ..............................................8
   3.1. Routability of EIDs ........................................8
        3.1.1. Mechanisms for an ETR to Originate EID-Prefixes .....9
        3.1.2. Mechanisms for an ITR to Forward to EID-Prefixes ....9
        3.1.3. Map-Server Model Preferred ..........................9
   3.2. Connectivity to Non-LISP Sites ............................10
   3.3. Caveats on the Use of Data-Probes .........................10
4. LISP+ALT: Overview .............................................10
   4.1. ITR Traffic Handling ......................................11
   4.2. EID Assignment - Hierarchy and Topology ...................12
   4.3. Use of GRE and BGP between LISP-ALT Routers ...............14
5. EID-Prefix Propagation and Map-Request Forwarding ..............14
   5.1. Changes to ITR Behavior with LISP+ALT .....................15
   5.2. Changes to ETR Behavior with LISP+ALT .....................15
   5.3. ALT Datagram Forwarding Failure ...........................16
6. BGP Configuration and Protocol Considerations ..................16
   6.1. Autonomous System Numbers (ASNs) in LISP+ALT ..............16
   6.2. Subsequent Address Family Identifier (SAFI) for LISP+ALT ..17
7. EID-Prefix Aggregation .........................................17
   7.1. Stability of the ALT ......................................18
   7.2. Traffic Engineering Using LISP ............................18
   7.3. Edge Aggregation and Dampening ............................19
   7.4. EID Assignment Flexibility vs. ALT Scaling ................19
8. Connecting Sites to the ALT Network ............................20
   8.1. ETRs Originating Information into the ALT .................20
   8.2. ITRs Using the ALT ........................................21
9. Security Considerations ........................................22
   9.1. Apparent LISP+ALT Vulnerabilities .........................22
   9.2. Survey of LISP+ALT Security Mechanisms ....................23
   9.3. Use of Additional BGP Security Mechanisms .................24
10. Acknowledgments ...............................................24
11. References ....................................................24
   11.1. Normative References .....................................24
   11.2. Informative References ...................................25

1. Introduction ✨

okay so this doc describes LISP+ALT, which an ITR or MR (both defined in [RFC6830] and [RFC6833]) uses to find the Egress Tunnel Router (ETR) that holds the RLOC mapping info for a particular EID 🦋. The ALT network is built with BGP [RFC4271], the BGP multiprotocol extensions [RFC4760], and GRE [RFC2784]. Together they make an overlay of devices called ALT-Routers. These routers work on EID-Prefixes and use EIDs as forwarding destinations 💅.

ALT-Routers advertise hierarchically delegated chunks of the EID namespace (prefixes) toward the rest of the ALT 🌸. They also forward traffic for an EID covered by one of those prefixes toward the network element that's authoritative for that EID and is the origin of the BGP advertisement for that EID-Prefix 🧚. An ITR uses this overlay to send a LISP Map-Request (defined in [RFC6830]) to the ETR holding the EID-to-RLOC mapping for a matching EID-Prefix 💜. Usually, though, an ITR doesn't connect directly to the overlay. It sends its Map-Requests through a Map-Resolver (described in [RFC6833]) that does 🫶. Same deal on the other side: usually an ETR doesn't connect directly to the overlay either. Instead, it registers its EID-Prefixes with a Map-Server. The Map-Server advertises those EID-Prefixes onto the ALT and forwards Map-Requests for them to the ETR 🎀.

it's super important to know that the ALT does not distribute actual EID-to-RLOC mappings 🙈. What it does provide is a forwarding path from an ITR (or MR) that needs an EID-to-RLOC mapping to an ETR that holds that mapping 💖. The ITR/MR uses this path to send an ALT Datagram (see Section 3) to an ETR, and the ETR responds with a Map-Reply containing the info it needs 🌈.

one design goal for LISP+ALT is to use existing tech wherever possible ✨. So the ALT is meant to be built with off-the-shelf routers that already implement the required protocols (BGP and GRE). Little, if any, LISP-specific modifications should be needed for those devices to be deployed on the ALT (see Section 7 for aggregation requirements) 🧁. But ngl, there's a catch. Organizational and operational considerations suggest that ALT-Routers be both logically and physically separate from the "native" Internet packet transport system. Deploying this overlay on routers that are already in the global routing system and actively forwarding Internet traffic is not recommended 🚫.

this spec is experimental, and there are areas that still need more experience to figure out the best implementation strategy, operational model, and effects on Internet operations 🔬. Those areas are:

  • application effects of on-demand route map discovery
  • tradeoff in connection setup time vs. ALT design and performance when using a Map Request instead of carrying initial user data in a Data-Probe
  • best practical ways to build ALT hierarchies
  • effects of route leakage from ALT to the current Internet, particularly for LISP-to-non-LISP interworking
  • effects of exceptional situations, such as denial-of-service (DoS) attacks

experimentation, measurements, and deployment experience on these aspects are appreciated 🙌. These issues are conceptually well-understood (for example, an ALT lookup causes potential delay for the first packet destined to a given network), but the real-world operational effects are much less clear 🥹.

the rest of the doc is organized like this 🗺️. Section 2 defines the terms used in the doc. Section 3 outlines the LISP-ALT model, where EID-Prefixes are advertised using BGP on an overlay network (the "ALT") and Map-Requests are forwarded across it. Section 4 gives a basic overview of the LISP Alternative Logical Topology architecture, and Section 5 describes how the ALT uses BGP to propagate EID reachability over the overlay network. Section 6 covers other considerations for using BGP on the ALT. Section 7 describes building the ALT aggregation hierarchy, and Section 8 discusses how LISP-ALT elements are connected to form the overlay network. Section 9 covers the security considerations for LISP+ALT 🔐.

2. Definition of Terms ✨

okay bestie, this section is basically our glossary 🎀 It gives high-level definitions for the LISP concepts and parts that LISP+ALT touches, so we're all on the same page before the juicy stuff starts 💅

Alternative Logical Topology (ALT): This is the virtual overlay network made of tunnels between LISP-ALT Routers 🦋 BGP runs between ALT-Routers and carries reachability info for EID-Prefixes. The ALT gives us a way to forward Map-Requests (and Data-Probes, if they're supported) toward the ETR that "owns" an EID-Prefix. Since it's a tunneled overlay, its performance is expected to be pretty limited, so using it to forward high-bandwidth flows of Data-Probes is strongly discouraged (see Section 3.3 for more on that) 🙈

ALT-Router: This is the device that runs on the ALT. The ALT is a static network built from tunnels between ALT-Routers, and these routers are set up in a roughly hierarchical mesh 🧚 Routers at each level are responsible for aggregating EID-Prefixes learned from the ones logically "below" them, and advertising summary prefixes to the ones logically "above" them.

Prefix learning and propagation between ALT-Routers is done with BGP. An ALT-Router at the lowest level, the "edge" of the ALT, learns EID-Prefixes from its "client" ETRs. See Section 3.1 for how EID-Prefixes get learned at the "edge" of the ALT, and see Section 6 for details on how BGP is configured between the different network elements. When an ALT-Router gets an ALT Datagram, it looks up the destination EID in its forwarding table (made up of EID-Prefix routes it learned from neighboring ALT-Routers) and forwards it to the logical next hop on the overlay network 🌸

Endpoint ID (EID): A 32-bit (for IPv4) or 128-bit (for IPv6) value that identifies the ultimate source or destination for a LISP-encapsulated packet. See [RFC6830] for details ✨

EID-Prefix: A set of EIDs delegated in a power-of-two block 🍓 Info about EID-Prefixes is exchanged among ALT-Routers (not on the global Internet) using BGP, and EID-Prefixes are expected to be assigned hierarchically so they can be aggregated by ALT-Routers. A block like this is characterized by a prefix and a length. Note that while the ALT routing system treats an EID-Prefix as an opaque block of EIDs, an end site may put site-local, topologically relevant structure (subnetting) into an EID-Prefix for intra-site routing 🫶

Aggregated EID-Prefixes: A set of individual EID-Prefixes that have been aggregated in the [RFC4632] sense 💜

Map-Server (MS): An edge ALT-Router that provides a registration function for non-ALT-connected ETRs. It originates EID-Prefixes into the ALT on behalf of those ETRs, and forwards Map-Requests to them. See [RFC6833] for details 🎀

Map-Resolver (MR): An edge ALT-Router that accepts an Encapsulated Map-Request from a non-ALT-connected ITR, decapsulates it, and forwards it on to the ALT toward the ETR that owns the requested EID-Prefix. See [RFC6833] for details 🦋

Ingress Tunnel Router (ITR): A router that sends LISP Map-Requests or encapsulates IP datagrams with LISP headers, as defined in [RFC6830]. In this document, "ITR" refers to any device implementing ITR functionality, including a Proxy-ITR (see [RFC6832]). Under some circumstances, a LISP Map-Resolver may also originate Map-Requests (see [RFC6833]) 👑

Egress Tunnel Router (ETR): A router that sends LISP Map-Replies in response to LISP Map-Requests, and decapsulates LISP-encapsulated IP datagrams for delivery to end-systems, as defined in [RFC6830]. In this document, "ETR" refers to any device implementing ETR functionality, including a Proxy-ETR (see [RFC6832]). Under some circumstances, a LISP Map-Server may also respond to Map-Requests (see [RFC6833]) ⭐

Routing Locator (RLOC): A routable IP address for a LISP Tunnel Router (ITR or ETR). This document also calls it a "locator" interchangeably 🌈 An RLOC is also the output of an EID-to-RLOC mapping lookup, and an EID-Prefix maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are 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 Provider-Assigned (PA) addresses. Routing for RLOCs is not carried on the ALT 💅

EID-to-RLOC Mapping: A binding between an EID-Prefix and the set of RLOCs that can be used to reach it. It's sometimes just called a "mapping" ✨

EID-Prefix Reachability: An EID-Prefix is said to be "reachable" if at least one of its Locators is reachable. Put another way, an EID-Prefix is reachable if the ETR that is authoritative for a given EID-to-RLOC mapping is reachable 🧚

Default Mapping: A mapping entry for EID-Prefix 0.0.0.0/0 (::/0 for IPv6). It maps to a Locator-Set used for all EIDs in the Internet. If there's a more-specific EID-Prefix in the map-cache, it overrides the Default Mapping entry. The Default Mapping entry can be learned by configuration or from a Map-Reply message 🍓

ALT Default Route: An EID-Prefix value of 0.0.0.0/0 (or ::/0 for IPv6) that may be learned from the ALT or statically configured on an edge ALT-Router. The ALT Default Route defines a forwarding path for a packet to be sent into the ALT on a router that does not have a full ALT forwarding database 🌸

3. The LISP-ALT Model 🦋

okay so the LISP-ALT model uses the same basic query/response protocol that's documented in [RFC6830] 💖 LISP+ALT gives us two types of packets that an ITR can originate to get EID-to-RLOC mappings:

  1. Map-Request: A Map-Request message is sent into the ALT to request an EID-to-RLOC mapping. The ETR that owns the mapping responds to the ITR with a Map-Reply message. Since the ALT only forwards on EID destinations, the destination address of the Map-Request sent on the ALT must be an EID 🎀
  2. Data-Probe: Alternatively, an ITR may encapsulate and send the first data packet destined for an EID with no known RLOCs into the ALT as a Data-Probe 🫶 This might be done to minimize packet loss and to probe for the mapping. Same as above, the authoritative ETR for the EID-Prefix responds to the ITR with a Map-Reply message when it receives the data packet over the ALT. As a side-effect, the encapsulated data packet gets delivered to the end-system at the ETR site. Note that the Data-Probe's inner IP destination address, which is an EID, is copied to the outer IP destination address so the resulting packet can be routed over the ALT. See Section 3.3 for caveats on the usability of Data-Probes 👑

The term "ALT Datagram" is shorthand for a Map-Request or Data-Probe that's going to be sent into or forwarded on the ALT. Note that these packets use an RLOC as the outer-header source IP address and an EID as the outer-header destination IP address 💜

Detailed descriptions of the LISP packet types referenced by this document may be found in [RFC6830] ✨

3.1. Routability of EIDs 🌈

A LISP EID has the same syntax as an IP address, and it can be used, unaltered, as the source or destination of an IP datagram. In general though, EIDs are not routable on the public Internet 🙈 LISP+ALT provides a separate, virtual network called the LISP Alternative Logical Topology (ALT), where a datagram using an EID as an IP destination address may be transmitted. This network is built as an overlay on the public Internet using tunnels to interconnect ALT-Routers. BGP runs over these tunnels to propagate the path information needed to forward ALT Datagrams. Importantly, while the ETRs are the source(s) of the unaggregated EID-Prefixes, LISP+ALT uses existing BGP mechanisms to aggregate this information 🧚

3.1.1. Mechanisms for an ETR to Originate EID-Prefixes 🍓

There are three ways an ETR can originate its mappings into the ALT:

  1. By registration with a Map-Server, as documented in [RFC6833]. This is the common case and is expected to be used by the majority of ETRs 💅
  2. Using a "static route" on the ALT. Where no Map-Server is available, an edge ALT-Router may be configured with a "static EID-Prefix route" pointing to an ETR 🌸
  3. Edge connection to the ALT. If a site needs fine-grained control over how its EID-Prefixes are advertised into the ALT, it may configure its ETR(s) with tunnel and BGP connections to edge ALT-Routers 🦋

3.1.2. Mechanisms for an ITR to Forward to EID-Prefixes 💖

There are three ways an ITR can send ALT Datagrams:

  1. Through a Map-Resolver, as documented in [RFC6833]. This is the common case and is expected to be used by the majority of ITRs 🎀
  2. Using a "default route". Where a Map-Resolver is not available, an ITR may be configured with a static ALT Default Route pointing to an edge ALT-Router 🫶
  3. Edge connection to the ALT. If a site needs fine-grained knowledge of what prefixes exist on the ALT, it may configure its ITR(s) with tunnel and BGP connections to edge ALT-Routers 👑

3.1.3. Map-Server Model Preferred 👑

The ALT-connected ITR and ETR cases are expected to be rare. The Map-Server/Map-Resolver model is simpler for an ITR/ETR operator to use, and it also provides a more general service interface, not only to the ALT but also to other mapping databases that may be developed in the future ⭐

3.2. Connectivity to Non-LISP Sites 🌈

As stated above, EIDs used as IP addresses by LISP sites are not routable on the public Internet. This means that, without a mechanism for communication between LISP and non-LISP sites, connectivity between them isn't possible 😭 To solve this, an "interworking" technology has been defined. See [RFC6832] for details 💜

3.3. Caveats on the Use of Data-Probes 💀

It's worth noting that there's been a great deal of discussion and controversy about whether Data-Probes are a good idea 🙈 On one hand, they offer a way to avoid the "first packet drop" problem when an ITR doesn't have a mapping for a particular EID-Prefix. On the other hand, forwarding data packets on the ALT would require that it either be engineered to support relatively high traffic rates (not generally feasible for a tunneled network), or be carefully designed to aggressively rate-limit traffic to avoid congestion or DoS attacks 😭 There may also be issues caused by different latency or other performance characteristics between the ALT path taken by an initial Data-Probe and the "Internet" path taken by subsequent packets on the same flow once a mapping is in place on an ITR 🌸

For these reasons, the use of Data-Probes is not recommended at this time. They should only be originated from an ITR when explicitly configured to do so, and that configuration should only be enabled when performing experiments intended to test the viability of using Data-Probes 🔥

4. LISP+ALT: Overview ✨

Okay so LISP+ALT is a hybrid push/pull architecture 💖 Aggregated EID-Prefixes get advertised among the ALT-Routers, and also to those (rare 👀) ITRs that are directly connected to the ALT through a tunnel and BGP. When an ITR needs a specific EID-to-RLOC mapping, it asks using LISP, either through a Map-Resolver or straight to an edge ALT-Router, and the ETR sends the answer back the same way 🦋

The big idea is to let BGP, running on a tunneled overlay network (the ALT), handle reachability between ALT-Routers 🔥 The ALT BGP Routing Information Base (RIB) is made of EID-Prefixes and their associated next hops. ALT-Routers connect with each other over BGP and pass EID-Prefix updates around the group. The EID-Prefix info itself comes from ETRs at the "edge" of the ALT, and it can arrive through the Map-Server interface (the most common way by far), through static configuration, or from BGP-speaking ETRs 🌸

Map-Resolvers learn paths through the ALT to Map-Servers for EID-Prefixes. An ITR will normally use a Map-Resolver to send its ALT Datagrams on to the ALT, but in unusual cases (see Section 3.1.2) it MAY instead use a static ALT Default Route or connect to the ALT using BGP. Likewise, an ETR will normally register its prefixes in the mapping database using a Map-Server, or it can sometimes (see Section 3.1.1) connect directly to the ALT using BGP 💅 See [RFC6833] for details on Map-Servers and Map-Resolvers.

Quick heads up on tunnels 🧚 This document specifies Generic Routing Encapsulation (GRE) as the tunneling mechanism, but there is absolutely no reason parts of the ALT can't be built with other tunneling technologies, especially if GRE doesn't meet security, management, or other operational requirements. So any "GRE tunnel" mentions in later sections SHOULD therefore not be read as banning other tunnel types 🙈 Also, two ALT-Routers that are directly adjacent (no layer-3 router hops between them) don't need a tunnel at all. In that case BGP MAY be configured across the interfaces that connect to their common subnet, and that subnet then counts as part of the ALT topology. Using something like "eBGP multihop" to connect ALT-Routers that don't share a tunnel or common subnet is NOT RECOMMENDED, because the non-ALT routers in between may not have the info needed to forward ALT Datagrams destined for EID-Prefixes exchanged across that BGP session. Yikes 😭

In summary, LISP+ALT uses BGP to build paths through ALT-Routers, so an ALT Datagram sent into the ALT can get forwarded to the ETR that holds the EID-to-RLOC mapping for that EID-Prefix 🎀 That reachability travels as IPv4 or IPv6 Network Layer Reachability Information (NLRI) without any modification, since an EID-Prefix has the same syntax as an IPv4 or IPv6 address prefix. ALT-Routers set up BGP sessions with one another, and that's what forms the ALT. An ALT-Router sitting at the "edge" of the topology learns EID-Prefixes from the authoritative ETRs, either through the Map-Server interface, static configuration, or BGP with the ETRs. An ALT-Router MAY also be configured to aggregate EID-Prefixes it receives from ETRs or from other LISP-ALT Routers that are topologically "downstream" from it ✨

4.1. ITR Traffic Handling

Here's the flow 🌈 When an ITR gets a packet from an end-system inside its site (meaning a host whose exit path out of the site is that ITR) and the destination EID isn't in the ITR's map-cache, the ITR creates either a Map-Request for the destination EID or the original packet wrapped up as a Data-Probe (check Section 3.3 for the caveats on when Data-Probes are actually usable). The result, called an ALT Datagram, gets sent to an ALT-Router (see also [RFC6833] for ITRs that aren't ALT-connected, noting that Data-Probes cannot be sent to a Map-Resolver) 💖 This "first-hop" ALT-Router uses EID-Prefix routing info it learned from other ALT-Routers over BGP to steer the packet to the ETR that "owns" the prefix. Once the ETR gets it, normal LISP processing happens: the ETR answers the ITR with a LISP Map-Reply listing the RLOCs (and therefore the ETRs to use) for the EID-Prefix. For Data-Probes, the ETR also decapsulates the packet and sends it on toward its destination 🦋

When the ITR gets the Map-Reply, it installs the RLOC info for that prefix into a local mapping database 🔥 After that, packets for the EID-Prefix get routed straight to an RLOC without touching the ALT, until either the entry's Time to Live (TTL) runs out or the ITR can't find any reachable ETR. Heads up: a current mapping might exist that contains no reachable RLOCs at all. That's called a Negative Cache Entry, and it means packets destined for the EID-Prefix are to be dropped 🙈

Full details on Map-Request/Map-Reply processing can be found in [RFC6830] 📚

Traffic that goes onto the ALT is made up entirely of ALT Datagrams, which means Map-Requests and Data-Probes (if supported) 🍓 Since a tunneled topology is expected to perform relatively poorly, ALT-Routers (and Map-Resolvers) SHOULD aggressively rate-limit the ingress of ALT Datagrams from ITRs. If possible, they SHOULD also be configured to not accept packets that aren't ALT Datagrams. Protect that network, bestie 🛡️💅

4.2. EID Assignment - Hierarchy and Topology

The ALT database is organized hierarchically, with EID-Prefixes aggregated on power-of-2 block boundaries 🧩 If a LISP site has multiple EID-Prefixes that line up on a power-of-2 block boundary, they SHOULD be aggregated into a single EID-Prefix for advertisement. The ALT network is built as a roughly hierarchical, partial mesh, meant to allow aggregation wherever clearly defined hierarchical boundaries exist. Building that structure SHOULD minimize the number of EID-Prefixes carried by LISP+ALT nodes near the top of the hierarchy 👑

Routes on the ALT don't need to react to changes in policy, subscription, or underlying physical connectivity, so the topology can stay relatively static and aggregation can be sustained 🌸 Since routing on the ALT uses BGP, the same rules apply for generating aggregates. Specifically, an ALT-Router SHOULD only be configured to generate an aggregate if it's configured with BGP sessions to all of the originators of the components (more-specific prefixes) of that aggregate. Not every component has to be present for the aggregate to be originated, since some may be holes in the covering prefix and some may be down. But the aggregating router MUST be configured to learn the state of all of the components ✨

Whether the ALT-Router actually generates the aggregate is a matter of local policy. In some cases it'll be statically configured to do so at all times, using a "static discard" route. In other cases, it MAY be configured to only generate the aggregate prefix if at least one of the components is learned via BGP 💖

An ALT-Router MUST NOT generate an aggregate that includes a non-LISP-speaking hole unless it can be configured to return a Negative Map-Reply with action="Natively-Forward" (see [RFC6830]) when it receives an ALT Datagram matching that hole. If it receives an ALT Datagram that matches a LISP-speaking hole that's currently unreachable, it SHOULD return a Negative Map-Reply with action="drop". Negative Map-Replies SHOULD be returned with a short TTL, as specified in [RFC6833]. Also, an off-the-shelf, non-LISP-speaking router configured as an aggregating ALT-Router can't send Negative Map-Replies, so a router like that MUST never originate an aggregate that includes a non-LISP-speaking hole 🙅‍♀️

This means two ALT-Routers sharing an overlapping set of prefixes MUST exchange those prefixes if either one is going to generate and export a covering aggregate for them 🫶 It also means an ETR that connects to the ALT using BGP MUST maintain BGP sessions with every ALT-Router configured to originate an aggregate covering its prefix, and each of those ALT-Routers MUST be explicitly configured to know the set of EID-Prefixes making up any aggregate it originates. See also [RFC6833] for another example of how prefix origin consistency and aggregation can be maintained 📚

Let's make it concrete 🍓 Say ETRs are originating EID-Prefixes for 10.1.0.0/24, 10.1.64.0/24, 10.1.128.0/24, and 10.1.192.0/24. An ALT-Router SHOULD only be configured to generate an aggregate for 10.1.0.0/16 if it has BGP sessions configured with all of these ETRs. In other words, it should only do that if it has enough knowledge about the state of those prefixes to summarize them. If the router originating 10.1.0.0/16 gets an ALT Datagram destined for 10.1.77.88, which is a non-LISP destination covered by the aggregate, it returns a Negative Map-Reply with action "Natively-Forward". If it gets an ALT Datagram destined for 10.1.128.199 but the configured LISP prefix 10.1.128.0/24 is unreachable, it returns a Negative Map-Reply with action "drop" 💅

Note: Much is currently uncertain about the best way to build the ALT network. As testing and prototype deployment proceed, a guide to building the ALT network well will be developed 🧐

4.3. Use of GRE and BGP between LISP-ALT Routers

The ALT network is built using GRE tunnels between ALT-Routers 🌈 BGP sessions get configured over those tunnels, with each ALT-Router acting as a separate Autonomous System (AS) "hop" in a Path Vector for BGP. For LISP+ALT's purposes, the AS-path is used solely as a shortest-path determination and loop-avoidance mechanism. Because all next hops sit on tunnel interfaces, no IGP is needed to resolve those next hops to exit interfaces ✨

Using GRE and BGP makes LISP easier to deploy and run 💖 No new protocols need to be defined, implemented, or used on the overlay topology, and existing BGP/GRE tools and operational expertise get reused too. Tunnel address assignment is easy as well 🎀 The addresses on an ALT tunnel are only used by the pair of routers connected to that tunnel, so the only requirement for the IP addresses used to establish it is that the attached routers can reach each other. That means any addressing plan, including private addressing, can be used for ALT tunnels 🦋

5. EID-Prefix Propagation and Map-Request Forwarding ✨

okay so, like we talked about in Section 8.2, an ITR sends an ALT Datagram toward a given EID-to-RLOC mapping 🫶. The ALT is the infrastructure that makes sure those requests actually reach the authoritative ETR 🦋

ngl the cute part is where the replies go. Under normal circumstances, Map-Replies are not sent over the ALT. Instead, an ETR sends the Map-Reply to one of the ITR RLOCs it learned from the original Map-Request 💌 For more on how the ITR RLOC Address field gets used, check Sections 6.1.2 and 6.2 of [RFC6830]. Keep in mind that this field supports multiple RLOCs in multiple address families, so a Map-Reply sent back for a Map-Request is not necessarily sent to the Map-Request RLOC source 👀

There may be scenarios where Map-Replies could be sent over the ALT, maybe to encourage ALT-Routers to cache EID-to-RLOC mappings 🧚 Or a "first-hop" ALT-Router might change the originating RLOC on a Map-Request it got from an ITR, just to force the Map-Reply to come back to that "first-hop" ALT-Router 🔁 These cases are not supported by initial LISP+ALT implementations, but they may be explored in future experiments 🧪

ALT-Routers pass path information along using BGP ([RFC4271]), and ITRs use that info to send ALT Datagrams toward the right ETR for each EID-Prefix 🗺️ BGP runs on the inter-ALT-Router links, and it might also run between an edge ("last-hop") ALT-Router and an ETR, or between an edge ("first-hop") ALT-Router and an ITR. The ALT BGP RIB holds aggregated EID-Prefixes along with their next hops toward the authoritative ETR for that EID-Prefix 💜

5.1. Changes to ITR Behavior with LISP+ALT

Okay, reminder: an ITR will usually use the Map-Resolver interface and send its Map Requests to a Map-Resolver 📬 But when an ITR connects via tunnels and BGP to the ALT instead, it sends ALT Datagrams to one of its "upstream" ALT-Routers 🚀 These are only sent to get brand-new EID-to-RLOC mappings. RLOC probe and cache TTL refresh Map-Requests are not sent on the ALT, so don't even try 🙅‍♀️

Same as basic LISP, the ITR should use one of its RLOCs as the source address for these queries. It should not use a tunnel interface as the source address 🚫 Why? Because that would make replies get forwarded over the tunneled topology, and that can be a mess if the tunnel interface address isn't routed throughout the ALT 😭 If the ITR is running BGP with the LISP-ALT Router(s), it picks the right ALT-Router based on the BGP info it received. If it's not running BGP, it uses a statically configured ALT Default Route to pick an ALT-Router 🧭

5.2. Changes to ETR Behavior with LISP+ALT

Quick recap: an ETR will usually use the Map-Server interface (see [RFC6833]) and register its EID-Prefixes with its configured Map-Servers 📝 When an ETR connects using BGP to one or more ALT-Routers instead, it announces its EID-Prefix(es) to those ALT-Routers 📣

As documented in [RFC6830], when an ETR generates a Map-Reply to send back to a querying ITR, it sets the outer-header IP destination address to one of the requesting ITR's RLOCs 💅 That way the Map-Reply rides the underlying Internet topology, not the ALT. This avoids any latency penalty (aka "stretch") from sending the Map-Reply via the ALT, reduces load on the ALT, and makes sure the Map-Reply can still be routed even if the original ITR doesn't have an ALT-routed EID 🙌 For details on how an ETR picks which ITR RLOC to use, see Section 6.1.5 of [RFC6830].

5.3. ALT Datagram Forwarding Failure

Intermediate ALT-Routers forward ALT Datagrams using normal, hop-by-hop routing on the ALT overlay network 🛣️ Now, if an ALT-Router can't forward an ALT Datagram (whether because of an unreachable next hop, TTL exceeded, or some other problem 💀), it has a few choices:

  • If the ALT-Router understands LISP, like a Map-Resolver or Map-Server does, it may respond to the forwarding failure by returning a Negative Map-Reply, as described in Section 4.2 and [RFC6833] 🙋‍♀️
  • If the ALT-Router does not understand LISP, it may try to return an ICMP message to the source IP address of the packet that couldn't be forwarded. Since that source address is an RLOC, the ALT-Router would send this ICMP message using "native" Internet connectivity, not the ALT overlay 🌍
  • A non-LISP-capable ALT-Router may also choose to silently drop the non-forwardable ALT Datagram 🫥

[RFC6830] and [RFC6833] define how the source of an ALT Datagram should handle each of these cases 📖 The last one, where the ALT Datagram is silently discarded, will generally lead to several retransmissions by the source. After that, the destination gets treated as unreachable via LISP when no Map-Reply comes back. If a problem on the ALT is bad enough to stop ALT Datagrams from reaching a specific EID, this is probably the only sensible way to handle it 😤

Also, the use of GRE tunnels should prevent MTU problems from ever happening on the ALT. An ALT Datagram that exceeds an intermediate MTU gets fragmented at that point and reassembled by the target of the GRE tunnel 🧩

6. BGP Configuration and Protocol Considerations 🎀

6.1. Autonomous System Numbers (ASNs) in LISP+ALT

The main job of BGP today is defining the global Internet routing topology in terms of its participants, called Autonomous Systems 🌐 LISP+ALT uses BGP to build a global overlay network (the ALT) for finding EID-to-RLOC mappings. The ALT is related to the global routing database, but it has a totally different purpose and a very different hierarchy 🪞

Because LISP+ALT does use BGP, though, it puts ASNs in the paths that get propagated among ALT-Routers. To avoid confusion, LISP+ALT should use newly assigned AS numbers that are unrelated to the ASNs used by the global routing system 🔢 Exactly how this new space gets assigned and managed will be figured out during the deployment of LISP+ALT.

Also, the ALT-Routers that make up the "core" of the ALT won't be associated with any existing core-Internet ASN, because the ALT topology is completely separate from, and independent of, the global Internet routing system 💖

6.2. Subsequent Address Family Identifier (SAFI) for LISP+ALT

As defined by this document, LISP+ALT may be implemented using BGP without modification ✨ But here's the tea: propagating global Internet routing info (the current dominant use of BGP) is operationally very different from creating an overlay network for finding EID-to-RLOC mappings (the way this document proposes using BGP). So it may be desirable to assign a new SAFI [RFC4760] to prevent operational confusion and difficulties, including the inadvertent leaking of information from one domain to the other 🚧

The catch? A separate SAFI would make it easier to debug many operational problems, but it would come at a significant cost: unmodified, off-the-shelf routers that don't understand the new SAFI couldn't be used to build any part of the ALT network 😩 At present, this document does not request the assignment of a new SAFI. Additional experimentation may suggest the need for one in the future 🔮

7. EID-Prefix Aggregation 🧁

To make EID-Prefix aggregation easier, the ALT BGP topology is provisioned in a hierarchical manner. Since all inter-node links are tunnels, the topology can be constrained to follow the EID-Prefix assignment hierarchy 🏗️ Redundant links are provisioned to cover node and link failures. A basic assumption is that as long as the routers are up and running, the underlying Internet will provide alternative routes to keep tunnel and BGP connectivity among ALT-Routers 🦋

Remember from Section 4.2 that LISP+ALT's use of BGP requires that information only be aggregated where all active more-specific prefixes of a generated aggregate prefix are known 🧠 This is just like how BGP route aggregation works in the existing global routing system: a service provider only generates an aggregate route if it's configured to learn all the prefixes that make up that aggregate 📦

7.1. Stability of the ALT

It's worth noting that LISP+ALT does not directly propagate EID-to-RLOC mappings 🙅‍♀️ What it does is provide a mechanism for an ITR to communicate with the ETR that holds the mapping for a particular EID-Prefix. This distinction matters a lot when you compare the stability of BGP on the ALT network to the global routing system 📊 It also affects how site-specific EID-Prefix information might be used by LISP but not propagated by LISP+ALT (see Section 7.2 below).

RLOC prefixes are not propagated through the ALT, so their reachability isn't determined through LISP+ALT. Instead, reachability of RLOCs is learned through the LISP ITR-ETR exchange 🔍 That means link failures or other service disruptions that might change an RLOC's reachability are not known to the ALT. Changes to the presence of an EID-Prefix on the ALT happen much less often: only at subscription time, or if the ALT infrastructure itself fails 🥱 So "flapping" (frequent BGP updates and withdrawals due to prefix state changes) is not likely, and mapping information can't become "stale" from slow propagation through the ALT BGP mesh 🌸

7.2. Traffic Engineering Using LISP

Since an ITR learns an EID-to-RLOC mapping directly from the ETR that owns it, it's possible to do site-to-site Traffic Engineering 🎯 You can set the preference and/or weight fields, and include more-specific EID-to-RLOC information in Map-Reply messages to make it happen 💫

This is a seriously powerful mechanism that could conceivably replace the traditional practice of routing prefix deaggregation for Traffic Engineering purposes 👑 Instead of pushing more-specific info into the global routing system for local or regional optimization of traffic flows, that info can be exchanged through LISP (not LISP+ALT), on an as-needed basis, between only the ITRs/ETRs (and so, the site pairs) that actually need it. Swapping "more-specifics" between sites like this makes Traffic Engineering easier, because it allows richer and more fine-grained policies without advertising extra prefixes into either the ALT or the global routing system 🫶

Note that these new Traffic Engineering capabilities are an attribute of LISP and are not specific to LISP+ALT. They're discussed here because the BGP-based global routing system has traditionally used propagation of more-specific routes as a crude form of Traffic Engineering 🙈

7.3. Edge Aggregation and Dampening 🦋

okay so normal BGP best common practices apply to the ALT network 💅. first-hop ALT-Routers will aggregate EID-Prefixes and dampen changes to them when there are excessive updates 🌸. EID-Prefix assignments aren't expected to change as often as global routing BGP prefix reachability, so that dampening should be very rare, and it might even be worth logging as an exceptional event 📝.

again, worth noting that the ALT only carries EID-Prefixes, which are used to build a BGP path to each ETR (or Map-Server) that originates each prefix. the ALT does not carry reachability info about RLOCs 🙈. EID-Prefix info may also be aggregated as far as the topology and address assignment hierarchy allow 🧚. since the topology is all tunneled and can be modified as needed, reasonably good aggregation should be possible ✨. and since most ETRs are expected to connect to the ALT using the Map-Server interface, Map-Servers will be a natural "edge" for the ALT where dampening and aggregation can be applied 👑. so the set of prefix info on the ALT can be expected to be both better aggregated and considerably less volatile than the actual EID-to-RLOC mappings 💜.

7.4. EID Assignment Flexibility vs. ALT Scaling 🎀

there are major open questions about how the ALT will be deployed and which organization(s) will operate it 🤔. in a simple, non-distributed world, centralized administration of EID-Prefix assignment and ALT network design would make a well-aggregated ALT routing system super easy 🧁. but business and other realities will likely lead to a more complex, distributed system with multiple levels of prefix delegation, multiple operators running parts of the ALT infrastructure, and a mix of competition and cooperation among everyone involved 😭. on top of that, reusing existing IP address assignments, both Provider-Independent ("PI") and Provider-Assigned ("PA"), so sites don't have to renumber when they move to LISP will make building and operating the ALT even trickier 🌀.

a bunch of conflicting considerations need to stay on your radar when designing and building the ALT 🧠. the big ones are:

  1. Target ALT routing state size and level of aggregation. As described in Section 7.1, the ALT should not suffer from the same performance constraints or stability issues as the Internet global routing system, so some reasonable level of deaggregation, and an increased number of EID-Prefixes beyond what might be considered ideal, should be acceptable 🌷. that said, measures should be taken to reduce unnecessary explosion of ALT routing state 💅. these include tunnel rehoming to preserve aggregation when sites move from one mapping provider to another, and implementing aggregation at multiple levels in the hierarchy to collapse deaggregation at lower levels ✨.
  2. Number of operators of parts of the ALT and how they will be organized (hierarchical delegation vs. shared administration). This decides not only how EID-Prefixes are assigned, but also how tunnels are configured and how EID-Prefixes can be aggregated between different parts of the ALT 🍓.
  3. Number of connections between different parts of the ALT. Tradeoffs will need to be made among resilience, performance, and placement of aggregation boundaries ⚖️.
  4. EID-Prefix portability between competing operators of the ALT infrastructure. A big perk for an end site adopting LISP is having EID space that isn't tied to one connectivity provider 🦄. it's important to make sure an end site doesn't just trade lock-in to a connectivity provider for lock-in to a provider of its EID assignment, ALT connectivity, or Map-Server facilities 🔒.

this is, by no means, an exhaustive list 🙃.

while resolving these issues is beyond the scope of this document, the authors recommend carefully considering existing distributed resource structures, like the IANA/Regional Internet Registries and the ICANN/Domain Registrar, when designing and deploying the ALT infrastructure 🫶.

8. Connecting Sites to the ALT Network 🌈

8.1. ETRs Originating Information into the ALT 🍓

EID-Prefix info is originated into the ALT by three different mechanisms 📡:

  • Map-Server: In most cases, a site will configure its ETR(s) to register with one or more Map-Servers (see [RFC6833]) and does not participate directly in the ALT 🧚.
  • BGP: For sites that need complex control over their EID-Prefix origination into the ALT, an ETR may connect to the LISP+ALT overlay network by running BGP to one or more ALT-Routers over tunnel(s). The ETR advertises reachability for its EID-Prefixes over these BGP connection(s). The edge ALT-Router(s) that receive(s) these prefixes then propagate(s) them into the ALT 🦋.

Here, the ETR is simply a BGP peer of ALT-Router(s) at the edge of the ALT 💖. where possible, an ALT-Router that receives EID-Prefixes from an ETR via BGP should aggregate that info ✨.

  • Configuration: One or more ALT-Routers may be configured to originate an EID-Prefix on behalf of the non-BGP-speaking ETR that is authoritative for a prefix 🎀. as in the case above, the ETR is connected to ALT-Router(s) using GRE tunnel(s), but rather than BGP being used, the ALT-Router(s) are configured with what are in effect "static routes" for the EID-Prefixes "owned" by the ETR 🍭. the GRE tunnel is used to route Map-Requests to the ETR 🛰️.
Note: In all cases, an ETR may register to multiple Map-Servers or connect to multiple ALT-Routers for the following reasons: - redundancy, so that a particular ETR is still reachable even if one path or tunnel is unavailable 🛟 - to connect to different parts of the ALT hierarchy if the ETR "owns" multiple EID-to-RLOC mappings for EID-Prefixes that cannot be aggregated by the same ALT-Router (i.e., are not topologically "close" to each other in the ALT) 🗺️

8.2. ITRs Using the ALT 🔥

in the common configuration, an ITR doesn't need to know anything about the ALT, since it sends Map-Requests to one of its configured Map-Resolvers (see [RFC6833]) 😌. there are two exceptional cases:

  • Static default: If a Map-Resolver isn't available but an ITR is adjacent to an ALT-Router (either over a common subnet or through a tunnel), it can use an ALT Default Route to send all ALT Datagrams to that ALT-Router 🧭. this case is expected to be rare 🤏.
  • Connection to ALT: A site with complex Internet connectivity may need more fine-grained distinction between traffic to LISP-capable and non-LISP-capable sites 💅. such a site may configure each of its ITRs to connect directly to the ALT, using a tunnel and BGP connection. In this case, the ITR will receive EID-Prefix routes from its BGP connection to the ALT-Router and will LISP-encapsulate and send ALT Datagrams through the tunnel to the ALT-Router 🚇. traffic to other destinations may be forwarded (without LISP encapsulation) to non-LISP next-hop routers that the ITR knows 🌊.

in general, an ITR that connects to the ALT does so only to ALT-Routers at the "edge" of the ALT (typically two, for redundancy) 👯. there may, though, be situations where an ITR would connect to other ALT-Routers to receive additional, shorter-path info about a portion of the ALT that's of interest to it 🔍. this can be done by establishing GRE tunnels between the ITR and the set of ALT-Routers with the additional info 🧵. this is a purely local policy issue between the ITR and the ALT-Routers in question 🫧.

as described in [RFC6833], Map-Resolvers do not accept or forward Data-Probes 🙅‍♀️. in the rare scenario that an ITR does support and originate Data-Probes, it must do so using one of the exceptional configurations described above 🎯. note that the use of Data-Probes is discouraged at this time (see Section 3.3) 🚫.

9. Security Considerations 💀

LISP+ALT shares many of the security characteristics of BGP 🔐. its security mechanisms are made up of existing technologies that are in wide operational use today, so securing the ALT should be mostly a matter of applying the same technology used to secure the BGP-based global routing system (see Section 9.3 below) 🛡️.

9.1. Apparent LISP+ALT Vulnerabilities 🚨

this section briefly lists the known potential vulnerabilities of LISP+ALT 📋.

  • Mapping integrity: Potential for an attacker to insert bogus mappings to black-hole traffic (creating a DoS attack) or intercept LISP data-plane packets 🕳️.
  • ALT-Router availability: Can an attacker DoS the ALT-Routers connected to a given ETR? If a site's ETR cannot advertise its EID-to-RLOC mappings, the site is essentially unavailable 😱.
  • ITR mapping/resources: Can an attacker force an ITR or ALT-Router to drop legitimate mapping requests by flooding it with random destinations, which will generate large numbers of Map-Requests and fill its map-cache? Further study is required to see the impact of admission control on the overlay network 🌪️.
  • EID Map-Request exploits for reconnaissance: Can an attacker learn about a LISP site's TE policy by sending legitimate mapping requests and then observing the RLOC mapping replies? Is this info useful in attacking or subverting peer relationships? Note that any public LISP mapping database will have similar data-plane reconnaissance issues 🕵️‍♀️.
  • Scaling of ALT-Router resources: Paths through the ALT may have less bandwidth than more "direct" paths, which may make them more prone to high-volume DoS attacks. For this reason, all components of the ALT (ETRs and ALT-Routers) should be prepared to rate-limit traffic (ALT Datagrams) that could be received across the ALT 🚦.
  • UDP Map-Reply from ETR: Since Map-Replies are sent directly from the ETR to the ITR's RLOC, the ITR's RLOC may be vulnerable to various types of DoS attacks (this is a general property of LISP, not a LISP+ALT vulnerability) 📬.
  • More-specific prefix leakage: Because EID-Prefixes on the ALT are expected to be fairly well-aggregated, and EID-Prefixes propagated out to the global Internet (see [RFC6832]) are much more so, accidental leaking or malicious advertisement of an EID-Prefix into the global routing system could redirect traffic away from a LISP site 😤. this isn't really a new problem, though, and its solution can only be achieved with much stricter prefix filtering and authentication on the global routing system 🧱. Section 9.3 describes an existing approach to solving this problem 🙌.

9.2. Survey of LISP+ALT Security Mechanisms 🔐

okay bestie, let's look at the security toolkit LISP+ALT already has 💅

  • Explicit peering: the devices themselves can prioritize incoming packets, and potentially do key checks in hardware, to protect the control plane 🛡️
  • Use of TCP to connect elements: this makes it difficult for third parties to inject packets 🚫
  • Use of HMAC to protect BGP/TCP connections: Hashed Message Authentication Code (HMAC) [RFC5925] is used to verify the integrity and authenticity of the TCP connections that exchange BGP messages. This makes it nearly impossible for third-party devices to insert or modify messages 🔒✨
  • Message sequence numbers and nonce values in messages: this lets an ITR verify that a Map-Reply from an ETR is answering a Map-Request that ITR actually sent 🎯 (this is a general property of LISP, and LISP+ALT doesn't change this behavior 🦋)

9.3. Use of Additional BGP Security Mechanisms 🧩

LISP+ALT uses BGP, and that means it gets to borrow BGP security features that were designed for the regular Internet's BGP use 🌐. It's giving main character energy: LISP+ALT can and should use technology built for adding security to BGP (from the IETF SIDR working group or elsewhere) to provide authentication of EID-Prefix origination and EID-to-RLOC mappings 💜

10. Acknowledgments 🫶

The authors would like to specially thank J. Noel Chiappa, who was a key contributor to the design of the Content distribution Overlay Network Service for LISP (LISP-CONS) mapping database. Many ideas from LISP-CONS made their way into LISP+ALT 🌸, and he has kept giving invaluable insight as the LISP effort has evolved 👑. Others who made valuable contributions include John Zwiebel, Hannu Flinck, Amit Jain, John Scudder, Scott Brim, and Jari Arkko ✨

11. References 📚

11.1. Normative References

[RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
           Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
           March 2000.

[RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
           Protocol 4 (BGP-4)", RFC 4271, January 2006.

[RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
           (CIDR): The Internet Address Assignment and Aggregation
           Plan", BCP 122, RFC 4632, August 2006.

[RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
           "Multiprotocol Extensions for BGP-4", RFC 4760,
           January 2007.

[RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
           Locator/ID Separation Protocol (LISP)", RFC 6830,
           January 2013.

[RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
           Protocol (LISP) Map-Server Interface", RFC 6833,
           January 2013.

11.2. Informative References

[RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
           Authentication Option", RFC 5925, June 2010.

[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.

Authors' Addresses 💌

Vince Fuller

EMail: vaf@vaf.net


Dino Farinacci
Cisco Systems
Tasman Drive
San Jose, CA  95134
USA

EMail: farinacci@gmail.com


Dave Meyer
Cisco Systems
Tasman Drive
San Jose, CA  95134
USA

EMail: dmm@1-4-5.net


Darrel Lewis
Cisco Systems
Tasman Drive
San Jose, CA  95134
USA

EMail: darlewis@cisco.com

That's the whole spec, babe! 🌈💖

📦 where this page comes from