RFC 7215
Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations
RFC 7215: the paperwork, bestie 📋✨
Okay, first the basics 🎀. This is RFC 7215, Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations, published in April 2014 by the IETF. The authors are L. Jakab from Cisco Systems, A. Cabellos-Aparicio, F. Coras, and J. Domingo-Pascual from the Technical University of Catalonia, and D. Lewis from Cisco Systems. It's filed as an Experimental document 🧪, with ISSN 2070-1721. The header doesn't list any RFCs that it obsoletes or updates, so it's standing on its own 💅.
Abstract 🌸
This doc is a snapshot of different LISP deployment scenarios 🦋. It talks about where the new network elements that LISP introduces should be placed, and it reflects what the LISP working group was thinking as of Summer 2013. Deployment scenarios may have evolved since then, so this is just one stable point in that evolution. Think of it as a time capsule 🕰️💜.
Status of This Memo ✨
Okay, important legal-ish stuff, but make it cute 🎀. This is not an Internet Standards Track spec. It's published so people can examine it, try out experimental implementations, and evaluate it 🧪.
It does define an Experimental Protocol for the Internet community 💖. It's a product of the IETF, it represents IETF community consensus, it got public review, and the IESG approved it for publication 🫶. Not everything the IESG approves is up for any level of Internet Standard, though. See Section 2 of RFC 5741 if you want the details 🤓.
For current status, errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7215 🔗.
Copyright Notice 💅
Copyright (c) 2014 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, which you can find at http://trustee.ietf.org/license-info as they stood on the publication date 📜. Please actually read them, because they spell out your rights and restrictions for this document 🙈. If you pull Code Components out of this document, they need to include the Simplified BSD License text the way Section 4.e of the Trust Legal Provisions describes, and they come with no warranty, as the Simplified BSD License says 🔥.
Table of Contents 🧚
1. Introduction ....................................................3
2. Tunnel Routers ..................................................5
2.1. Deployment Scenarios .......................................5
2.1.1. Customer Edge (CE) ..................................5
2.1.2. Provider Edge (PE) ..................................6
2.1.3. Tunnel Routers behind NAT ...........................8
2.1.3.1. ITR ........................................8
2.1.3.2. ETR ........................................9
2.1.3.3. Additional Notes ...........................9
2.2. Functional Models with Tunnel Routers ......................9
2.2.1. Split ITR/ETR .......................................9
2.2.2. Inter-Service-Provider Traffic Engineering .........11
2.3. Summary and Feature Matrix ................................13
3. Map-Servers and Map-Resolvers ..................................14
3.1. Map-Servers ...............................................14
3.2. Map-Resolvers .............................................16
4. Proxy Tunnel Routers ...........................................17
4.1. PITRs .....................................................17
4.2. PETRs .....................................................18
5. Migration to LISP ..............................................19
5.1. LISP+BGP ..................................................19
5.2. Mapping Service Provider (MSP) PITR Service ...............20
5.3. Proxy-ITR Route Distribution (PITR-RD) ....................20
5.4. Migration Summary .........................................23
6. Security Considerations ........................................24
7. Acknowledgements ...............................................24
8. References .....................................................24
8.1. Normative References ......................................24
8.2. Informative References ....................................24
Appendix A. Step-by-Step Example BGP-to-LISP Migration Procedure ..26
A.1. Customer Pre-Install and Pre-Turn-Up Checklist .............26
A.2. Customer Activating LISP Service ...........................28
A.3. Cut-Over Provider Preparation and Changes ..................291. Introduction 🦋
Okay, so LISP is designed to fix the scaling problems of the global Internet routing system that [RFC4984] called out 😭. The trick is that it splits the current addressing scheme into Endpoint IDentifiers (EIDs) and Routing LOCators (RLOCs) 🧠. The main spec, [RFC6830], explains how that separation works, which new network elements show up, and the packet formats for the data and control planes 📦.
LISP assumes the separation happens between the edge and the core, and it uses mapping and encapsulation to forward traffic 🌈. The boundary between the two isn't strictly defined, but one widely accepted definition puts it at the border routers of stub autonomous systems. Those routers might carry a partial or complete default-free zone (DFZ) routing table 👀. The original LISP design used that location as its baseline ✨. But LISP is good for more than shrinking the DFZ routing table. It also brings better multihoming and ingress traffic engineering (TE) support for edge networks, and even for individual hosts 💅. Throughout this document we'll say "LISP site" to mean those networks or hosts sitting behind a LISP Tunnel Router 🫶. Two terms get formal definitions:
- Network element: Facility or equipment used in the provision of a communications service over the Internet [TELCO96].
- LISP site: A single host or a set of network elements in an edge network under the administrative control of a single organization, delimited from other networks by LISP Tunnel Router(s).
Since LISP can be used for lots of different purposes, it's important to figure out the possible deployment scenarios and what extra requirements they might put on the protocol spec and on other protocols 🧩. This doc is also meant as a guide for the operations community running LISP in their networks 🛠️. It's expected to keep evolving as LISP deployment grows and as the scenarios get better understood or new ones show up 🌱.
Each subsection looks at one element type and talks about how deployment scenarios affect the protocol spec 🎀. For definitions of terms, check the relevant documents, which are cited in each section 📚.
⚠️ This is an experimental doc about deployment considerations 🧪. These considerations and the LISP specs still have areas that need more experience and measurement. LISP is not recommended for deployment beyond experimental situations 🙅♀️. Results from experimentation may lead to changes and enhancements to LISP mechanisms. Also, at the time of writing there's no standardized security to implement 😭. Beware that there are no countermeasures for any of the threats identified in [LISP-THREATS] 💀. For specific known issues that still need work during development, implementation, and experimentation, see Section 15 of [RFC6830]. For recommendations to ease the security threats mentioned above, see [LISP-THREATS] 🫶.
2. Tunnel Routers 🚇
The device that acts as the gateway between the edge and the core is called a Tunnel Router (xTR) 🌸. It does one or both of two separate jobs:
- Encapsulating packets that come from an end host, so they can be carried over intermediary (transit) networks toward the other endpoint of the communication 🎁.
- Decapsulating packets that come in from intermediary (transit) networks and originated at a remote end host 📬.
The first job is done by an Ingress Tunnel Router (ITR), and the second by an Egress Tunnel Router (ETR) 🧚.
Section 8 of the main LISP spec [RFC6830] has a short discussion of where Tunnel Routers can be deployed, along with some of the advantages and disadvantages that come with each place 🤓. This section adds more detail to those scenarios and also brings in some new ones 🌈. It also talks about functional models, which are network functions you can get by deploying Tunnel Routers in specific ways 💖.
2.1. Deployment Scenarios 🎀
2.1.1. Customer Edge (CE) ✨
okay so the first scenario is the customer edge 💅 This is when xTR functionality lives on the router(s) that connect the LISP site up to its upstream(s), but the site still controls those routers. Honestly this is the most common setup you'll see for xTRs, so this document uses it as the reference location and compares everything else to it 🦋
ISP1 ISP2
| |
| |
+----+ +----+
+--|xTR1|--|xTR2|--+
| +----+ +----+ |
| |
| LISP site |
+------------------+
Figure 1: xTRs at the Customer EdgeFrom the LISP site's point of view, the big perk of this deployment (compared to the one in the next section) is that you get direct control over your ingress traffic engineering 👑 That makes it easy to set up and maintain active/active, active/backup, or more complex TE policies, and you can add ISPs and extra xTRs whenever you want without involving third parties. no cap, it's giving independence 🌸
Since everything is under the same administrative control, the reachability info of all the ETRs is easier to keep in sync, because the necessary control traffic can be allowed between the ETRs' locators. That gets you a correct, synchronous global view of reachability, so the Locator-Status-Bits can be set correctly in the LISP data header of outgoing packets ✨
By putting the Tunnel Router at the edge of the site, you don't have to touch the existing internal network. Firewall rules, router configs, and address assignments inside the LISP site all stay the same 🎀 This helps with incremental deployment and gives you a quick upgrade path to LISP. For bigger sites spread across geographically diverse points of presence (PoPs), with lots of external connections and a complicated internal topology, it may, however, make more sense to encapsulate and decapsulate as soon as possible, so you can use the info from the IGP to choose the best path. See Section 2.2.1 for a discussion of this scenario 🧠
Another thing to think about when placing Tunnel Routers is MTU issues 😭 Encapsulation adds overhead to every packet, and that overhead decreases the effective end-to-end path MTU (unless fragmentation and reassembly are used). Some transit networks are known to offer larger MTU values than the typical value of 1500 bytes for popular access technologies used at end hosts (e.g., IEEE 802.3 and 802.11). However, putting the LISP router that connects to such a network at the customer edge could possibly bring up MTU issues, depending on the link type to the provider, as opposed to the following scenario. See [RFC4459] for MTU considerations of tunneling protocols and how to mitigate potential issues. Still, even with these mitigations, path MTU issues are still possible 💀
2.1.2. Provider Edge (PE) 🌈
The other spot at the core-edge boundary for deploying LISP routers is the Internet service provider edge. The main incentive here is that the customer does not have to upgrade the CE router(s) or change the configuration of any equipment. Encapsulation and decapsulation happen in the provider's network, which may be able to serve several customers with a single device. For large ISPs with lots of residential and business customers asking for LISP, this can mean serious savings, since there's no need to upgrade the software (or hardware, if that's the case) at each client's location. Instead, they upgrade the software (or hardware) on a few PE routers serving the customers 🫶 This scenario is depicted in Figure 2.
+----------+ +------------------+
| ISP1 | | ISP2 |
| | | |
| +----+ | | +----+ +----+ |
+--|xTR1|--+ +--|xTR2|--|xTR3|--+
+----+ +----+ +----+
| | |
| | |
+--<[LISP site]>---+-------+
Figure 2: xTRs at the Provider EdgeWhile this approach makes the transition easy for customers and may be cheaper for providers, the LISP site loses one of the main benefits of LISP: ingress traffic engineering 🥲 Since the provider controls the ETRs, extra complexity would be needed to let customers modify their mapping entries.
It gets worse when the LISP site is multihomed 💅 Take the scenario in Figure 2: whenever a change to TE policies is needed, the customer contacts both ISP1 and ISP2 to make the changes on the routers (if they offer that option). It's unlikely both ISPs will apply changes at the same time, which may lead to inconsistent state for the mappings of the LISP site. Also, since the different upstream ISPs are usually competing business entities, the ETRs may even be configured to compete, either to attract all the traffic or to get no traffic. The former will happen if the customer pays per volume, and the latter if the connectivity has a fixed price. One solution could be to configure the Map-Server(s) to do proxy-replying and have the Mapping Service Provider (MSP) apply policies 🧚
Additionally, since xTR1, xTR2, and xTR3 are in different administrative domains, locator reachability information is unlikely to be exchanged among them, which makes it hard to set the Locator-Status-Bits (LSBs) correctly on encapsulated packets. Because of this, and due to the security concerns about LSBs described in [LISP-THREATS], their use is discouraged (set the L-bit to 0). Map-Versioning is another alternative [RFC6834] 🔥
Compared to the customer edge scenario, deploying LISP at the provider edge might have the advantage of diminishing potential MTU issues, because the Tunnel Router is closer to the core, where links typically have higher MTUs than edge network links 🌸
2.1.3. Tunnel Routers behind NAT 🙈
"NAT" in this section refers to IPv4 network address and port translation.
2.1.3.1. ITR
_.--. _.--.
,-'' `--. +-------+ ,-'' `--.
' EID ` (Private) | NAT | (Public) ,' RLOC `.
( )---[ITR]---| |---------( )
. space ,' (Address) | Box |(Address) . space ,'
`--. _.-' +-------+ `--. _.-'
`--'' `--''
Figure 3: ITR behind NATPackets encapsulated by an ITR are just UDP packets from a NAT device's point of view, so they get handled like any other UDP packet. There are no additional requirements for LISP data packets 🦋
Map-Requests sent by an ITR create the state in the NAT table, but they have a different 5-tuple in the IP header than the Map-Reply generated by the authoritative ETR. Since the source address of that Map-Reply is different from the destination address of the request packet, no state will be matched in the NAT table and the packet will be dropped 😭 To avoid this, the NAT device has to do the following:
- Send all UDP packets with source port 4342, regardless of the destination port, to the RLOC of the ITR. The simplest way to achieve this is configuring 1:1 NAT mode from the external RLOC of the NAT device to the ITR's RLOC (called "DMZ" mode in consumer broadband routers).
- Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in the payload.
This setup supports only a single ITR behind the NAT device 🍓
2.1.3.2. ETR
An ETR placed behind NAT is reachable from the outside by the Internet-facing locator of the NAT device. It needs to know this locator (and configure a loopback interface with it), so it can use it in Map-Reply and Map-Register messages. Thus, support for dynamic locators for the mapping database is needed in LISP equipment 💜
Again, only one ETR behind the NAT device is supported 🫠
_.--. _.--.
,-'' `--. +-------+ ,-'' `--.
' EID ` (Private) | NAT | (Public) ,' RLOC `.
( )---[ETR]---| |---------( )
. space ,' (Address) | Box |(Address) . space ,'
`--. _.-' +-------+ `--. _.-'
`--'' `--''
Figure 4: ETR behind NAT2.1.3.3. Additional Notes
An implication of the issues above is that LISP sites with xTRs cannot be behind carrier-based NATs, since two different sites would collide on the same forwarded UDP port 🚫 An alternative to static hole-punching worth exploring is the use of the Port Control Protocol (PCP) [RFC6887].
We only include this scenario for completeness, to show that a LISP site can be deployed behind NAT should it become necessary. However, LISP deployments behind NAT should be avoided, if possible 🥹
2.2. Functional Models with Tunnel Routers 🧚♀️
This section describes how certain LISP deployments can provide network functions 💖
2.2.1. Split ITR/ETR ✨
okay so in a simple LISP deployment, xTRs sit at the border of the LISP site (see Section 2.1.1) 🏠. In that setup, packets get routed inside the domain based on the EID. BUT, more complex networks might want to route packets based on the destination RLOC instead 🧠. That's how they get to pick the best egress point 🦋
The LISP spec splits the ITR and ETR jobs apart, so each one can live on separate network gear 🎀. ITRs can be placed closer to the host (i.e., access routers), so packets get encapsulated as soon as possible, and egress point selection is driven by operational policy 💅. ETRs can go on the border routers of the network, so packets get decapsulated as soon as possible 🌸. Once they're decapsulated, packets are routed based on the destination EID according to internal routing policy. it's giving organized 👑
Check out Figure 5 🧚. The Source (S) sends packets using its EID, and in this case the packets get encapsulated at ITR_1. The encapsulated packets are routed inside the domain based on the destination RLOC, and they can leave the network through the best point (i.e., closer to the RLOC's Autonomous System (AS)) 💖. On the other side, inbound packets are received by ETR_1, which decapsulates them. Then the packets are routed towards S based on the EID, again following the best path ✨
+---------------------------------------+
| |
| +-------+ +-------+ +-------+
| | ITR_1 |---------+ | ETR_1 |-RLOC_A--| ISP_A |
| +-------+ | +-------+ +-------+
| +-+ | | |
| |S| | IGP | |
| +-+ | | |
| +-------+ | +-------+ +-------+
| | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B |
| +-------+ +-------+ +-------+
| |
+---------------------------------------+
Figure 5: Split ITR/ETR Scenariothis setup comes with a whole set of implications, bestie 🫶
- the site must carry more-specific routes so it can choose the best egress point, and BGP is typically used for this, which makes the network more complex 😭. BUT this is usually already the case for LISP sites that would benefit from this scenario 💅
- if the site is multihomed to different ISPs and any of the upstream ISPs do unicast reverse path forwarding (uRPF) filtering, this scenario may become impractical 💀. To set the correct source RLOC in the encapsulation header, ITRs need to figure out first which ETR the outgoing packet will use. That adds complexity and reliability concerns 🙈
- in LISP, ITRs set the reachability bits when they encapsulate data packets. So ITRs need a way to know the liveness of all ETRs serving their site 🔥
- the MTU within the site network must be big enough to fit encapsulated packets 📏
- in this scenario, each ITR serves fewer hosts than when it's deployed at the border of the network. It's been shown that the cache hit rate grows logarithmically with the number of users [CACHE] 📈. So when ITRs live closer to the host, the mapping cache may be less effective (i.e., the miss rate is higher). Another consequence is that the site may send a higher number of Map-Requests, which adds load to the distributed mapping database 🌈
- by placing the ITRs inside the site, they will still need global RLOCs 🌍. That can add complexity to intra-site routing configurations and more intra-site issues when there's a change of providers 😤
2.2.2. Inter-Service-Provider Traffic Engineering 🌸
At the time of writing, if two ISPs want to control their ingress TE policies for transit traffic between them, they have to rely on existing BGP mechanisms 😩. That usually means deaggregating prefixes so they can choose which upstream link packets should enter on. This either isn't feasible (if fine-grained per-customer control is required, the very-specific prefixes may not get propagated) or it bloats the DFZ table size 💀
LISP is usually seen as only applicable to stub networks, BUT LISP can also be applied in a recursive manner, which gives service providers ingress/egress TE capabilities without impacting the DFZ table size 🦋. Iconic plot twist 👑
To set this up with LISP, check out the scenario in Figure 6 🧚. The two ISPs that want ingress/egress TE are labeled ISP_A and ISP_B. They're servicing Stub1 and Stub2, respectively. Both are required to be LISP sites with their own xTRs. In this scenario, Stub1 and Stub2 are talking to each other, so ISP_A and ISP_B offer transit for that traffic 🎀. ISP_A has RLOC_A1 and RLOC_A2 as upstream IP addresses, while ISP_B has RLOC_B1 and RLOC_B2. The shared goal of ISP_A and ISP_B is to control the transit traffic flow between RLOC_A1/A2 and RLOC_B1/B2 💜
_.--.
Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub2
\ | R_A1|----,' `. ---|R_B1 | /
--| | ( Transit ) | |--
... .../ | R_A2|-----. ,' ---|R_B2 | \... ...
+-------+ `--. _.-' +-------+
... ... ISP_A `--'' ISP_B ... ...
Figure 6: Inter-Service-Provider TE ScenarioBoth ISPs deploy xTRs on RLOC_A1/A2 and RLOC_B1/B2, respectively, and they reach a bilateral agreement to deploy their own private mapping system 🤝. This mapping system holds bindings between the RLOCs of Stub1 and Stub2 (owned by ISP_A and ISP_B, respectively) and RLOC_A1/A2 and RLOC_B1/B2. Those bindings are literally the TE policies between both ISPs, and convergence is expected to be fast, since the ISPs only have to update or query a mapping to or from the database ⚡
Here's how the packet flows 🧁. First, a packet from Stub1 headed to Stub2 gets LISP encapsulated by Stub1's xTR. The xTR of ISP_A recursively encapsulates it, and based on the TE policies stored in the private mapping system, the ISP_A xTR picks RLOC_B1 or RLOC_B2 as the outer encapsulation destination. Note that the packet transits between ISP_A and ISP_B double-encapsulated 🫠. When the xTR of ISP_B receives it, the packet is decapsulated and sent towards Stub2, which performs the last decapsulation 💖
This deployment scenario, which uses recursive LISP, comes with three important caveats ⚠️. First, it's meant to be deployed between only two ISPs. If more than two ISPs use this approach, then either the xTRs at the participating ISPs have to query multiple mapping systems, or the ISPs have to agree on a common shared mapping system 😵💫. Keeping this scenario restricted to just two ISPs keeps the solution scalable, since only two entities need to agree on using recursive LISP and only one private mapping system is involved 👑
Second, the scenario is only recommended for ISPs providing connectivity to LISP sites, so the source RLOCs of packets being recursively encapsulated belong to that ISP. Otherwise, the participating ISPs must register prefixes they don't own in the private mapping system we talked about. That leads to either needing complex authentication mechanisms or enabling simple traffic redirection attacks 🚨. Not following these recommendations may lead to operational security issues when deploying this scenario 😬
And third, recursive encapsulation models are typically complex to troubleshoot and debug 🙃
Besides those recommendations, the main disadvantages of this deployment case are 📝:
- an extra LISP header is needed. That makes the packet bigger and means the MTU between both ISPs has to fit double-encapsulated packets 📦
- the ISP ITR has to encapsulate packets, so it must know the RLOC-to-RLOC bindings. Those bindings live in a mapping database and may be cached in the ITR's mapping cache. Cache misses add lookup latency, unless a push-based mapping system is used for the private mapping system 🐢
- maintaining the shared mapping database involves operational overhead 🛠️
2.3. Summary and Feature Matrix 🎀
okay so, when you're looking at all the deployment scenarios and functional models we just went through, there are a few things to weigh when picking one. It really depends on what kind of organization is doing the deployment 💅
For home users and small sites that want to multihome and keep control over their ISP options, the "CE" scenario is the main character 👑 It's simple to deploy. In some cases it only needs a software upgrade of the Customer Premises Equipment (CPE), getting mapping service, and configuring the router. The user keeps control of TE and gets to choose their upstreams. It doesn't give ISPs too many perks, though, because multihomed clients depend on them less. ISPs who want to offer LISP to their customers probably won't go with "CE" either. They'd have to send a technician to every customer and maybe ship a new CPE device 😭 Even with remote control over the router, where a software upgrade could add LISP support, it's still too risky.
For a network operator, the "PE" scenario is a solid pick 🫶 The exception is when the edge routers need a hardware upgrade to support LISP. In that case, upgrading CPEs might be the easier move. "PE" keeps control of TE, plus the choice of Proxy Egress Tunnel Router (PETR) and Map-Server/Map-Resolver. It also cuts down on potential MTU issues, as we talked about above. Network operators should also check out the "inter-service-provider TE" (recursive) functional model for their TE needs ✨
If you're a large organization trying to optimize traffic flow, the "split ITR/ETR" functional model is where you'll get the biggest glow-up 🔥
Here's a quick overview of which deployment scenarios support which features. A marked "x" means it's supported. The columns are "CE" for customer edge, "PE" for provider edge, "Split" for split ITR/ETR, and "Recursive" for inter-service-provider traffic engineering. The features are:
- Control of ingress TE: this scenario lets the LISP site easily control its LISP ingress traffic engineering policies 💖
- No modifications to existing int. network infrastructure: this scenario doesn't make the LISP site change its internal network configurations 🌸
- Locator-Status-Bits sync: this scenario makes it easy to keep the Locator Status Bits in sync 🦋
- MTU/PMTUD issues minimized: this scenario keeps potential MTU and Path MTU Discovery (PMTUD) issues to a minimum 🧚
Feature CE PE Split Recursive NAT
--------------------------------------------------------------------
Control of ingress TE x - x x x
No modifications to existing
int. network infrastructure x x - - x
Locator-Status-Bits sync x - x x -
MTU/PMTUD issues minimized - x - - -3. Map-Servers and Map-Resolvers 🌈
Map-Servers and Map-Resolvers together make up the LISP mapping system 🧁 They're how you find the authoritative EID-to-RLOC mapping info, following [RFC6833]. They're meant to live in RLOC space, and running them behind NAT isn't supported 🙅♀️
3.1. Map-Servers 💜
The Map-Server learns EID-to-RLOC mapping entries from an authoritative source and publishes them to the distributed mapping database ✨ It gets these entries from authenticated Map-Register messages sent by authoritative ETRs. When a Map-Request comes in, the Map-Server checks that the destination EID matches an EID-Prefix it's authoritative for. Then it re-encapsulates the request and forwards it to a matching ETR. All the details are in [RFC6833] 📖
The Map-Server is run by a Mapping Service Provider (MSP). The MSP joins the global distributed mapping database by connecting to other participants, depending on which mapping system is in use. Examples are Alternative Logical Topology (ALT) [RFC6836] and Delegated Database Tree (DDT) [LISP-DDT]. Being in the mapping database and storing EID-to-RLOC data are both subject to the policies of the "root" operators. Those operators should check ownership rights for the EID-Prefixes participants store in the database. Those policies are out of scope for this document 🫶
LISP DDT is how LISP MSPs reach each other's Map-Resolvers and Map-Servers 🌐 The DDT root is run by a bunch of organizations on an open basis right now. You can find more in [DDT-ROOT]. It's kind of like the DNS root: it has several server instances named after Greek letters (alpha, delta, and so on), and independent organizations run them 🇬🇷 When this document was published, there were 6 of these instances, and one was anycasted. [DDT-ROOT] lists the server instances on its web site, plus configuration files for several Map-Server implementations. The DDT root and LISP Mapping Providers both rely on, and follow, the existing allocation policies set by Regional Internet Registries (RIRs) to decide who owns a prefix used as an EID 💅
The DDT root organizations are expected to keep evolving as people experiment with LISP for Internet edge multihoming and VPN use cases 🦋
In every case, the MSP sets up its Map-Server(s) to publish its clients' prefixes in the distributed mapping database. It also has them start encapsulating and forwarding Map-Requests to the ETRs of the AS. Those ETRs register their prefixes with the Map-Server(s) through periodic authenticated Map-Register messages. With that in mind, some LISP sites need mechanisms to:
- Automatically distribute EID-Prefix(es) shared keys between the ETRs and the EID-registrar Map-Server.
- Dynamically obtain the address of the Map-Server in the ETR of the AS.
The Map-Server is a big deal for keeping the EID-Prefixes it serves reachable 🔥 It publishes those prefixes into the distributed mapping database, and it also encapsulates and forwards Map-Requests to the authoritative ETRs for those prefixes. If a failed Map-Server is responsible for some EIDs, ITRs that encapsulate toward those EIDs won't be able to look up any of their covering prefixes 😭 The only exception is ITRs that already have the mappings in their local caches. Those ITRs can keep reaching ETRs until the entry expires, which is typically 24 hours. That's why redundant Map-Server deployments are desirable 🛡️ A set of Map-Servers giving high-availability service to the same set of prefixes is called a redundancy group. ETRs are configured to send Map-Register messages to all Map-Servers in the redundancy group. How fail-over (or load-balancing, if you want it) works among group members depends on the technology behind the mapping system. Since ALT is based on BGP and DDT takes inspiration from the Domain Name System (DNS), deployments can use current industry best practices for redundancy in BGP and DNS. Those best practices are out of scope for this document 🌸
Also, if a Map-Server has no reachability to any ETR serving a given EID block, it should not originate that block into the mapping system 🙈
3.2. Map-Resolvers 🧚
A Map-Resolver is a network infrastructure component that accepts LISP-encapsulated Map-Requests, usually from an ITR. Then it finds the right EID-to-RLOC mapping by checking the distributed mapping database. Map-Resolver functionality is described in detail in [RFC6833] 📖
Anyone who has access to the distributed mapping database can set up a Map-Resolver and offer EID-to-RLOC mapping lookup service. How you set up database access depends on the mapping system ✨
For performance reasons, it's recommended that LISP sites use Map-Resolvers that are topologically close to their ITRs 🏎️ ISPs that support LISP will offer this service to their customers, and may limit access to their own user base. LISP sites that aren't in that position can use open access Map-Resolvers, if any are available. Still, no matter whether open access resolvers exist, the MSP running the Map-Server(s) for a LISP site should also provide Map-Resolver(s) for that site to use 💖
In medium- to large-size ASes, ITRs must be configured with the RLOC of a Map-Resolver, and you can do that manually 🛠️ In Small Office/Home Office (SOHO) scenarios, though, a mechanism for autoconfiguration should be provided 🏠
One way to skip manual configuration at LISP sites of any size is to use anycast [RFC4786] RLOCs for Map-Resolvers, a lot like the DNS root server setup 🌍 LISP uses UDP encapsulation, so using anycast wouldn't hurt reliability. LISP routers can then ship with a preconfigured list of well-known Map-Resolver RLOCs, and the network administrator can edit that list if needed 🫶
Anycast also helps mapping lookup performance 🚀 Large MSPs can grow the number and geographic spread of their Map-Resolver infrastructure, all behind a single anycasted RLOC. Once LISP deployment is far enough along, very large content providers might want this setup too, so people connecting from LISP sites get minimal connection setup latency 👑
Map-Servers and Map-Resolvers do different jobs in the LISP mapping system, but they can live on the same device 🎀 For example, MSPs that offer both services can deploy a single Map-Resolver/Map-Server in each PoP where they have a presence 💜
4. Proxy Tunnel Routers ✨
4.1. PITRs 🦋
Okay so PITRs (Proxy Ingress Tunnel Routers) are part of the non-LISP/LISP transition mechanism, and they're the reason non-LISP sites can reach LISP sites at all 💖. They announce certain EID-Prefixes via BGP (aggregated whenever possible) to attract traffic from non-LISP sites towards EIDs in the covered range. Then they do the mapping system lookup and encapsulate the received packets towards the right ETR. ✨ For the reverse path, LISP sites can reach non-LISP sites by simply not encapsulating traffic, which is very low effort, very iconic 💅. For a detailed description of PITR functionality, see [RFC6832].
The success of new protocols depends a LOT on whether they stay backwards compatible and can interoperate with the protocol(s) they're meant to enhance or replace, plus whether people actually have the incentives to deploy the new software or equipment 🫶. A LISP site needs an interworking mechanism to be reachable from non-LISP sites, and a PITR can totally fill that role. It lets early adopters see the benefits of LISP, kind of like tunnel brokers helped the move from IPv4 to IPv6 🌈. A site gets new LISP functionality (in proportion to how much LISP is already deployed globally) when it migrates, so it has a reason to deploy the necessary Tunnel Routers. To be reachable from non-LISP sites, it has two options: keep announcing its prefix(es) with BGP, or have a PITR announce prefix(es) covering them.
If the goal is to reduce the DFZ routing table size, the second option is the one to go for 🌸. On top of that, the second option allows LISP-based ingress traffic engineering from all sites. Be aware though: where you place PITRs has a big impact on performance and on deployment incentives 👀. Section 5 is dedicated to the migration to a LISP-enabled Internet and includes deployment scenarios for PITRs.
4.2. PETRs 🧚
Ngl, PETRs are not required for the correct functioning of all LISP sites 🙈. There are two cases where they can be of great help:
- LISP sites with unicast reverse path forwarding (uRPF) restrictions, and
- Communication between sites using different address family RLOCs.
In the first case, uRPF filtering is applied at the LISP site's upstream provider's PE router. When traffic is forwarded to non-LISP sites, an ITR doesn't encapsulate packets, so the original IP headers stay intact. That means the packets will have EIDs in their source address 😬. Since we're talking about the transition period, we can assume that a prefix covering the EIDs belonging to the LISP site is advertised to the global routing tables by a PITR, and the PE router has a route towards it. The catch is that the next hop won't be on the interface towards the CE router, so the non-encapsulated packets will fail uRPF checks. Yikes.
To dodge this filtering, the affected ITR encapsulates packets towards the locator of the PETR for non-LISP destinations. Now the source address of the packets, as seen by the PE router, is the ITR's locator, which won't fail the uRPF check 🎀. The PETR then decapsulates and forwards the packets. Problem solved, bestie ✨.
The second use case is IPv4-to-IPv6 transition. Service providers using older access network hardware that only supports IPv4 can still offer IPv6 to their clients by providing a CPE device running LISP, plus PETR(s) for reaching IPv6-only non-LISP sites and LISP sites with IPv6-only locators 🍓. Packets from the client LISP site headed to these destinations get encapsulated towards the PETR's IPv4 locator. The PETR sits in a native IPv6 network, where it decapsulates and forwards the packets. For non-LISP destinations, the packet travels natively from the PETR. For LISP destinations with IPv6-only locators, the packet goes through a PITR in order to reach its destination.
For more details on PETRs, see [RFC6832].
PETRs can be deployed by ISPs that want to offer value-added services to their customers 💜. As with PITRs, PETRs may also introduce path stretch (the ratio between the cost of the selected path and that of the optimal path). So the ISP has to weigh the tradeoff: lots of devices close to the customers to minimize stretch, or fewer devices farther away to minimize cost instead. It's giving budget vs. performance, periodt 💅.
Since the deployment incentives for PITRs and PETRs are different, they will likely be deployed in separate devices. The exception is the Content Delivery Network (CDN) case, which may deploy both in a single device ⭐.
In all cases, having a PETR adds another step to configuring a LISP router. CPE routers, which are typically configured by DHCP, stand to benefit the most from PETRs 🌈. Autoconfiguration of the PETR locator could be achieved by a DHCP option, or by adding a PETR field to either Map-Notify or Map-Reply messages.
5. Migration to LISP 🌸
This section discusses a deployment architecture to support the migration to a LISP-enabled Internet 🦋. The loosely defined terms "early transition phase", "late transition phase", and "LISP Internet phase" refer to time periods when LISP sites are a minority, a majority, or represent all edge networks, respectively.
5.1. LISP+BGP 👑
For sites that want to migrate to LISP with their Provider-Independent (PI) prefix, the least disruptive way is to upgrade their border routers to support LISP and register the prefix into the LISP mapping system, while continuing to announce it with BGP as well 💖. This way, LISP sites reach them over LISP, and legacy sites aren't affected by the change at all. The main disadvantage is that no decrease in the DFZ routing table size is achieved. Still, just increasing the number of LISP sites is a big win ✨, because an increasing LISP/non-LISP site ratio may reduce the need for BGP-based traffic engineering that leads to prefix deaggregation. That, in turn, may lead to a decrease in DFZ size and churn in the late transition phase 🔥.
This scenario isn't limited to sites that already have their prefixes announced with BGP. Newly allocated EID blocks could follow this strategy too during the early LISP deployment phase, depending on the cost/benefit analysis of each network 🧚. Since this increases the DFZ size, the following architecture should be preferred for new allocations 🫶.
5.2. Mapping Service Provider (MSP) PITR Service 💅
In addition to publishing their clients' registered prefixes in the mapping system, MSPs with enough transit capacity can offer PITR service to those clients as a separate service 🌈. This is especially useful for new PI allocations to sites without existing BGP infrastructure that want to avoid BGP altogether. The MSP announces the prefix into the DFZ, and the client gets ingress traffic engineering without prefix deaggregation. The downside of this scenario is added path stretch 😭.
Routing all non-LISP ingress traffic through a third party that isn't one of its ISPs is only feasible for sites with modest amounts of traffic (like those using the IPv6 tunnel broker services today) 🍓. That's especially true in the first stage of the transition to LISP, when there are lots of legacy sites. The reason is that handling this traffic is likely to add costs, which would get passed down to the client. When the LISP/non-LISP site ratio becomes high enough, this approach can get increasingly attractive 💜.
Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix deaggregation for traffic engineering purposes. That results in a slower routing table increase for new allocations, and a potential decrease for existing ones 🦋. MSPs serving different clients with adjacent aggregatable prefixes may lead to an additional decrease, but quantifying that is subject to future research study 🔮.
5.3. Proxy-ITR Route Distribution (PITR-RD) 🦋
okay so instead of every LISP site (or the MSP) announcing its EIDs with BGP out to the DFZ, this job can get handed off to a third party called a PITR Service Provider (PSP) 💅 this means less operational chaos at both the site and the MSP, which is honestly a glow-up 🌸
the PSP runs a bunch of distributed PITR(s) that advertise the matching EID-Prefixes through BGP to the DFZ. then those PITRs encapsulate the traffic they get for those EIDs and send it on toward the RLOCs of the LISP site. that's how non-LISP sites can still reach them 🫶
ngl, a PSP could manually configure each client's EID-Routes to be announced, but that's giving very little flexibility and it doesn't scale 💀 so this section lays out a scalable setup that automatically distributes EID-Routes to LISP sites and service providers ✨
the architecture doesn't need any changes to existing LISP network elements. what it adds is a new (conceptual) network element called the EID-Route Server 🧚 it's a router that either passes along routes it learned from other EID-Route Servers or originates EID-Routes itself. the EID-Routes it originates are the ones it's authoritative for. it sends those routes to Proxy-ITRs inside its own AS. fun fact: a BGP-capable router can also count as an EID-Route Server 🤓
also, an EID-Route is a prefix originated via the MSP's Route Server, and it should get aggregated if the MSP has multiple customers sitting inside one big continuous prefix 🍓 that prefix then gets propagated to other PITRs inside the MSP and to any other PITR operators the MSP peers with 💜
EID-Route Servers can be run by the LISP site, MSPs, or PSPs. they might be collocated with a Map-Server or PITR, but they're functionally separate entities, no mixing them up 🙈 they distribute EID-Routes to other domains using BGP, following policies set by the participants 👑
MSP (AS64500)
RS ---> PITR
| /
| _.--./
,-'' /`--.
LISP site ---,' | v `.
( | DFZ )----- Mapping system
non-LISP site ----. | ^ ,'
`--. / _.-'
| `--''
v /
PITR
PSP (AS64501)
Figure 7: PITR-RD Architecturethe architecture I just described splits EID origination apart from route propagation 🦋 and that gets you a few perks:
- Can accurately represent business relationships between PITR operators
- Is more mapping system agnostic
- Makes minor changes to PITR implementation; no changes to other components
in the Figure 7 example, we've got an MSP providing services to a LISP site. the LISP site doesn't run BGP, and it gets its EID allocation straight from a RIR, or from the MSP (which may be a Local Internet Registry (LIR)) 🌈 existing PI allocations can be migrated over too. the MSP makes sure the prefix shows up in the mapping system and runs an EID-Route Server to hand it off to PSPs. since the LISP site doesn't run BGP, the prefix gets originated with the MSP's AS number 🎀
in the simple case from Figure 7, the LISP site's EID-Route gets originated by the Route Server and announced to the DFZ by the PSP's PITRs, with AS path 64501 64500. after that, the usual BGP dynamics kick in 💖 so routes announced by the PITR still trace back to the authoritative Route Server, which is iconic. heads up though: the peering relationships between MSPs/PSPs and the ones in the underlying forwarding plane might not match up, which can make the AS path to a PITR look shorter than it really is 👀
the non-LISP site picks the best path toward the EID-Prefix based on its own local BGP policies. AS-path length is usually a big deal for path selection, so placing PITRs carefully could seriously cut down path stretch between LISP and non-LISP sites 🧠✨
the architecture allows for flexible policies between MSPs/PSPs. think of the EID-Route Server networks as control plane overlays that make it easier to implement policies reflecting the business relationships between participants 💅 the results then get injected into the shared underlying forwarding plane. for example, some MSPs/PSPs might agree to swap EID-Prefixes and only announce them to each other's forwarding plane customers 🫶 global reachability of an EID-Prefix depends on which MSP the LISP site buys service from, and it's also subject to agreements between those parties 🌸
as for the impact on the DFZ: this architecture means a slower routing table increase for new allocations, since traffic engineering happens at the LISP level 📈 for existing allocations migrating to LISP, the DFZ might actually decrease, because MSPs may be able to aggregate the prefixes they announce 🎉
compared to LISP+BGP, this approach avoids the DFZ bloat caused by prefix deaggregation for traffic engineering purposes. that means a slower routing table increase for new allocations and a potential decrease for existing ones 💜 plus, MSPs serving different clients with adjacent aggregatable prefixes may lead to an additional decrease, but how big that decrease is remains subject to future research study 🔬
the flexibility and scalability don't come free, though 😭 a PSP operator has to set up either transit or peering relationships to improve its connectivity. no shortcuts, bestie 💀
5.4. Migration Summary 🌷
registering a domain name usually comes with an annual fee that's supposed to cover the cost of publishing the domain in the global DNS 🌐 several other registration services work the same way. so a LISP MSP client publishing an EID-Prefix in the LISP mapping system has the option to sign up for PITR services as well, for an extra fee 💖 these services might be offered by the MSP itself, but it's expected that specialized PSPs will be the ones doing it 🧚 clients that don't sign up are responsible for getting non-LISP traffic to their EIDs (using the LISP+BGP scenario) 🙈
also, Tier 1 ISPs have incentives to offer PITR services to non-subscribers in strategic places, just to pull in more traffic from competitors and therefore more revenue 💰 main character ISP behavior, honestly 👑
here's the table of expected effects the transition scenarios have on the DFZ routing table size at each phase 📊
Phase | LISP+BGP | MSP PITR | PITR-RD
-----------------+--------------+-----------------+----------------
Early transition | no change | slower increase | slower increase
Late transition | may decrease | slower increase | slower increase
LISP Internet | considerable decreaseit's expected that PITR-RD will coexist with LISP+BGP during the migration, with LISP+BGP being more popular in the early transition phase 🦋 as the transition moves along and the MSP PITR and PITR-RD ecosystem gets more ubiquitous, LISP+BGP should become less attractive, which slows down the growth in the number of routes in the DFZ 📉✨
quick note: throughout Section 5 we focused on how LISP deployment affects the DFZ routing table size. other metrics may be impacted too, but to the best of our knowledge they haven't been measured yet 🔍
6. Security Considerations 🔒
all security implications of LISP deployments are going to be discussed in separate documents 📄 [LISP-THREATS] gives an overview of LISP threat models, including ETR operators attracting traffic by overclaiming an EID-Prefix (Section 4.4.3 of [LISP-THREATS]). securing mapping lookups is discussed in [LISP-SEC] 🛡️
⚠️ bestie, one ETR operator overclaiming an EID-Prefix to yoink traffic is a whole vibe, so go read Section 4.4.3 of [LISP-THREATS] 😭
7. Acknowledgements 🫶
many thanks to Margaret Wasserman for her contribution to the IETF 76 presentation that kickstarted this work 🎀 the authors would also like to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller, Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, Paul Vinciguerra, Fred Templin, Brian Haberman, and everyone else who provided input 💜 the real MVPs 👑
8. References 📚
8.1. Normative References
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
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.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833,
January 2013.8.2. Informative References
[CACHE] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS
performance and the effectiveness of caching", IEEE/ACM
Transactions on Networking (TON), Volume 10, Issue 5,
pages 589-603, October 2002.
[DDT-ROOT] "Introduction to LISP DDT: DDT Root", March 2014,
<http://ddt-root.org/>.
[LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", Work in Progress, March 2013.
[LISP-SEC] Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
and O. Bonaventure, "LISP-Security (LISP-SEC)", Work in
Progress, October 2013.
[LISP-THREATS]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", Work in Progress, April 2014.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with
In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, December 2006.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", RFC 4984,
September 2007.
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834,
January 2013.
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
Protocol Internet Groper (LIG)", RFC 6835, January 2013.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, January 2013.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887,
April 2013.
[TELCO96] Federal Communications Commission, "Telecommunications Act
of 1996", 1996, <http://transition.fcc.gov/telecom.html>.Appendix A. Step-by-Step Example BGP-to-LISP Migration Procedure 🪜
to help the operational community deploy LISP, this informative section offers a step-by-step guide for migrating a BGP-based Internet presence to a LISP site 🚀 it includes a pre-install/pre-turn-up checklist, plus customer and provider activation procedures ✅
A.1. Customer Pre-Install and Pre-Turn-Up Checklist 💅
Okay bestie, before anything goes live we run a little checklist. 🎀
- Determine how many current physical service provider connections the customer has, and their existing bandwidth and traffic engineering requirements.
This info decides how many routing locators there are, plus the priorities and weights that should be set on the xTRs. ✨
- Make sure the customer router has LISP capabilities.
- Check the OS version of the CE router. If LISP is an add-on, check to see if it is installed.
This tells us if the platform can handle LISP, so we know whether a software and/or hardware upgrade is needed. 💜
- Have the customer upgrade (if necessary, software and/or hardware) to be LISP capable.
- Obtain the current running configuration of the CE router. A suggested LISP router configuration example can be customized to the customer's existing environment. 🍓
- Verify MTU handling.
- Request an increase in MTU to 1556 or more on service provider connections. Before the MTU change, verify the transmission of a 1500-byte packet from the PxTR to the RLOC with the Don't Fragment (DF) bit set.
- Ensure that the customer is not filtering ICMP Unreachable or Time Exceeded messages on their firewall or router.
LISP, like any tunneling protocol, makes packets bigger when the LISP header gets tacked on. If bumping the MTU on the access links isn't possible, care must be taken that ICMP isn't being filtered, so Path MTU Discovery can actually do its thing. 🔥
- Validate member prefix allocation.
This step checks whether the prefix the customer uses is a direct (Provider-Independent) prefix or one assigned by a physical service provider (Provider Aggregatable). If the prefixes are assigned by other service providers, then a Letter of Agreement is required to announce prefixes through the Proxy Service Provider. 🦋
- Verify the member RLOCs and their reachability.
This step makes sure the RLOCs configured on the CE router are actually reachable and working. 🫶
- Prepare for cut-over.
- If possible, have a host outside of all security and filtering policies connected to the console port of the edge router or switch.
- Make sure the customer has access to the router in order to configure it.
A.2. Customer Activating LISP Service 🦋
- The customer configures LISP on CE router(s) according to the configuration recommended by the service provider.
The LISP configuration consists of the EID-Prefix, the locators, and the weights and priorities of the mapping between the two values. On top of that, the xTR has to be configured with Map-Resolver(s), Map-Server(s), and the shared key for registering to Map-Server(s). If required, Proxy-ETR(s) may be configured as well. 🌸
In addition to the LISP configuration:
- Ensure that the default routes(s) to next-hop external neighbors is included and RLOCs are present in the configuration.
- If two or more routers are used, ensure that all RLOCs are included in the LISP configuration on all routers.
- It will be necessary to redistribute the default route via IGP between the external routers.
- When transition is ready, perform a soft shutdown on existing eBGP peer session(s).
- From the CE router, use the LISP Internet Groper (LIG) [RFC6835] to ensure that registration is successful.
- To verify LISP connectivity, find and ping LISP connected sites. If possible, find ping destinations that are not covered by a prefix in the global BGP routing system, because PITRs may deliver the packets even if LISP connectivity is not working. Traceroutes may help determine if this is the case. 👑
- To verify connectivity to non-LISP sites, try accessing a landmark (e.g., a major Internet site) via a web browser.
A.3. Cut-Over Provider Preparation and Changes ⭐
- Verify site configuration, and then verify active registration on Map-Server(s).
- Authentication key.
- EID-Prefix.
- Add EID space to map-cache on proxies.
- Add networks to BGP advertisement on proxies.
- Modify route-maps/policies on PxTRs.
- Modify route policies on core routers (if non-connected member).
- Modify ingress policies on core routers.
- Ensure route announcement in looking glass servers, RouteViews.
- Perform traffic verification test.
- Ensure that MTU handling is as expected (PMTUD working).
- Ensure Proxy-ITR map-cache population.
- Ensure access from traceroute/ping servers around Internet.
- Use a looking glass to check for external visibility of registration via several Map-Resolvers.
And that's the whole cut-over, bestie!! 🌈💖
Authors' Addresses 💖
Lorand Jakab
Cisco Systems
170 Tasman Drive
San Jose, CA 95134
USA
EMail: lojakab@cisco.com
Albert Cabellos-Aparicio
Technical University of Catalonia
C/Jordi Girona, s/n
BARCELONA 08034
Spain
EMail: acabello@ac.upc.edu
Florin Coras
Technical University of Catalonia
C/Jordi Girona, s/n
BARCELONA 08034
Spain
EMail: fcoras@ac.upc.edu
Jordi Domingo-Pascual
Technical University of Catalonia
C/Jordi Girona, s/n
BARCELONA 08034
Spain
EMail: jordi.domingo@ac.upc.edu
Darrel Lewis
Cisco Systems
170 Tasman Drive
San Jose, CA 95134
USA
EMail: darlewis@cisco.com📦 where this page comes from
- ietf: rfc7215 2014-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms