RFC 2917
A Core MPLS IP VPN Architecture
RFC 2917: A Core MPLS IP VPN Architecture 💖
okay bestie, here's the title block tea ☕✨
Network Working Group — this one's from the Network Working Group 🌸
Request for Comments: 2917 — it's RFC 2917 🦋
Category: Informational — it's Informational, so it's not a standard, just useful info 💅
Authors: K. Muthukrishnan (Lucent Technologies) and A. Malis (Vivace Networks, Inc.) 👑
Date: September 2000 🍓
The title block doesn't list anything it obsoletes or updates, so no drama there 🙈
Status of This Memo ✨
this memo is just here to give info to the internet community 🧚 it does not specify an internet standard of any kind, and it can be shared freely with no limits 💜
Copyright Notice 🎀
Copyright (C) The Internet Society (2000). All Rights Reserved. 🌈
Abstract 🦋
okay so this memo is all about how to build core Virtual Private Network (VPN) services inside a service provider's MPLS backbone 🔥 the big idea is that the backbone runs Multiprotocol Label Switching (MPLS) to give customers premium services on top of plain best effort ones 💅 the main vision is for the service provider to offer a virtual router service to its customers 👑
the keystones (aka the non-negotiables 😭) are: ease of configuration, user security, network security, dynamic neighbor discovery, scaling, and reusing the existing routing protocols exactly as they are today, without any modifications ✨ no cap, that last one is iconic.
1. Acronyms 🌸
ARP Address Resolution Protocol
CE Customer Edge router
LSP Label Switched Path
PNA Private Network Administrator
SLA Service Level Agreement
SP Service Provider
SPED Service Provider Edge Device
SPNA SP Network Administrator
VMA VPN Multicast Address
VPNID VPN Identifier
VR Virtual Router
VRC Virtual Router Console2. Introduction 🦋
so this memo explains how to build IP VPN services out of the SP's network backbone 🧚 there are basically two ways to do it: the overlay model and the virtual router approach 🫶 the overlay model works by overloading some semantic(s) of existing routing protocols so they can carry reachability information. Spoiler: this memo focuses on the virtual router service 💜
the approach here doesn't depend on changing any existing routing protocols at all ✨ neighbor discovery gets help from an emulated LAN and uses ARP to get the job done 🔥 the memo also makes a super intentional effort to draw the line between the SP and the PNA 💅 the SP owns and manages layer 1 and layer 2 services, while layer 3 services belong to the PNA and are manageable by the PNA 👑
because the design gives every customer fully logically independent routing domains, the PNA gets to use private and unregistered addresses 🌈 and data security? not an issue 🙈 the reason is that VPNs use private LSPs, plus VPNID encapsulation using label stacks over shared LSPs 🔐 slay.
now, the approach in this memo is different from [Rosen1] (aka RFC 2547) 🎀 RFC 2547 doesn't overload a routing protocol, it specifies a way to modify BGP to carry VPN unicast routes across the SP's backbone 🫶 the approach here doesn't overload any specific routing protocol to carry VPN routes 💅 and if you want to carry multicast routes, that'll need more architectural work in the future 😭
3. Virtual Routers 🌸
okay this is the core concept 💖 a virtual router is a collection of threads, static or dynamic, inside a routing device, and it provides routing and forwarding services just like physical routers do ✨ it doesn't have to be its own separate operating system process (although it could be 🧚). it just has to give the illusion that a dedicated router is there serving the network(s) it's connected to 🦋
like its physical counterpart, a virtual router is an element in a routing domain. the other routers in that domain can be physical or virtual routers themselves 💜 since a virtual router connects to one specific, logically discreet routing domain, and a physical router can support multiple virtual routers, a physical router supports multiple logically discreet routing domains 🔥
from the VPN customer's point of view, the virtual router needs to be as equivalent to a physical router as possible 👑 with very minor and very few exceptions, it should look like a dedicated physical router for everything: configuration, management, monitoring and troubleshooting 🫶 the big reason for this is to avoid upgrading or reconfiguring the huge installed base of routers and to avoid retraining network admins 😭
the aspects a virtual router needs to emulate are:
- Configuration of any combination of routing protocols
- Monitoring of the network
- Troubleshooting.
every VPN gets its own logically independent routing domain 🌈 this helps the SP offer a fully flexible virtual router service that serves each customer completely, without needing physical per-VPN routers 💅 so the SP's "hardware" investments (routers and the links between them) can be reused by multiple customers 🍓 money, honey 💸
4. Objectives 💜
here's the wishlist ✨
- Easy, scalable configuration of VPN endpoints in the SP network 🎀 at most, one piece of configuration should be needed when a CE is added 🌸
- No use of SP resources that are globally unique and hard to get, like IP addresses and subnets 🙈
- Dynamic discovery of VRs in the SP's cloud 🧚 this one is optional, but it's extremely valuable and very much a "keep it simple" goal 💖
- Virtual Routers should be fully configurable and monitorable by the VPN network administrator 👑 this gives the PNA the flexibility to either configure the VPN themselves or outsource those tasks to the SP 🫶
- Quality of data forwarding should be configurable on a VPN-by-VPN basis 🔥 this should translate to continuous (but maybe discrete) grades of service 🌈 examples include best effort, dedicated bandwidth, QOS, and policy based forwarding services 💅
- Differentiated services should be configurable on a VPN-by-VPN basis 🦋 that could be based on LSPs set up for exclusive use in forwarding that VPN's data traffic ✨
- Security of internet routers, extended to virtual routers 🔐 the virtual router's data forwarding and routing functions should be as secure as a dedicated, private physical router 😭 there should be no unintended leak of information (user data and reachability information) from one routing domain to another 🙈
- No specific routing protocols mandated between virtual routers 💜 this is critical so the VPN customer can set up the network and policies however they see fit 👑 for example, some protocols are strong in filtering, while others are strong in traffic engineering 🍓 the customer might want to use both for "best of breed" network quality 💅
- No special extensions to existing routing protocols like BGP, RIP, OSPF, ISIS etc. 🎀 this matters because it keeps the door open for other services like NHRP and multicast later 🧚 and as advances and addenda get made to existing protocols (like traffic engineering extensions to ISIS and OSPF), they can be easily brought into the VPN implementation 🌸
5. Architectural Requirements ✨
the SP network must run some form of multicast routing to all nodes that will have VPN connections, and to nodes that have to forward multicast datagrams for virtual router discovery 🔥 a specific multicast routing protocol is not mandated 🦋 an SP may run MOSPF, DVMRP, or any other protocol 💖
6. Architectural Outline ✨
okay so this is the blueprint section and it's giving main character energy 💅 here's how it all fits together:
- Every VPN gets a VPNID that's unique within the SP's network 🎀 It unambiguously identifies the VPN that a packet or connection is associated with. The VPNID of zero is reserved, and it's tied to the public internet 🌍 It is recommended, but not required that these VPN identifiers will be compliant with RFC 2685 [Fox].
- The VPN service comes as a Virtual Router service 🦋 These VRs live in the SPED and stay confined to the edge of the SP's cloud. They use the SP's network to forward data and control packets, but they're otherwise invisible outside the SPEDs 🫣
- The "size" of a VR contracted to a VPN in a given SPED is measured by how many IP resources it has, like routing interfaces, route filters, routing entries, etc. The SP controls all of this 👑 which gives the fine granularity the SP needs to offer virtually infinite grades of VR service on a per-SPED level. [Example: one SPED may be the aggregating point (say headquarters of the corporation) for a given VPN and a number of other SPEDs may be access points (branch offices). In this case, the SPED connected to the headquarters may be contracted to provide a large VR while the SPEDs connected to the branch offices may house small, perhaps stub VRs]. This setup also lets the SP design the network so the load gets spread out across the routers in the network 🧚
- One indicator of VPN size is the number of SPEDs in the SP's network that have connections to CPE routers in that VPN 📈 So a VPN with lots of sites to connect is a "large" VPN, and one with a few sites is a "small" VPN. A VPN can grow or shrink over time, and VPNs can even merge because of corporate mergers, acquisitions, and partnering agreements 🤝 This is easy to handle in this architecture, since globally unique IP resources don't have to be dedicated or assigned to VPNs. There's no artificial configuration limit on the number of SPEDs either 🙌
- The SP owns and manages Layer 1 and Layer 2 entities 🔧 To be specific, the SP controls physical switches or routers, physical links, logical layer 2 connections (like DLCI in Frame Relay and VPI/VCI in ATM), and LSPs (plus their assignment to specific VPNs). In the VPN context, it's the SP's job to contract and assign layer 2 entities to specific VPNs.
- Layer 3 entities belong to the PNA and the PNA can manage them 🧠 Examples include IP interfaces, the choice of dynamic routing protocols or static routes, and routing interfaces. Layer 3 configuration logically falls under the PNA's area of responsibility, but the PNA doesn't have to execute it 💁 It's totally viable for the PNA to outsource the IP administration of the virtual routers to the Service Provider. Either way, this approach gives the PNA a full routing domain view and lets them design the network for intranet, extranet, and traffic engineering goals 🗺️
- VPNs can be managed as if physical routers were deployed instead of VRs 💻 So management may be done with SNMP or other similar methods, or directly at the VR console (VRC).
- Industry-standard troubleshooting tools such as 'ping,' 'traceroute,' in a routing domain domain comprised exclusively of dedicated physical routers 🛠️ So monitoring and .bp troubleshooting may be done with SNMP or similar methods, but they can also use these standard tools. Again, the VRC can be used for these purposes just like any physical router.
- The VRC is visible to the user, so router-specific security checks need to be put in place 🔐 These make sure the VPN user can only access Layer 3 resources in that VPN and is blocked from accessing physical resources in the router. Most routers do this with database views.
- The VRC is available to the SP too 🫶 If configuration and monitoring have been outsourced to the SP, the SP may use the VRC to do these tasks as if it were the PNA.
- The VRs in the SPEDs form the VPN in the SP's network. Together they make up a virtual routing domain 🌸 They discover each other dynamically by using an emulated LAN that lives in the SP's network.
Each VPN in the SP's network gets one and only one multicast address 🦄 This address comes from the administratively scoped range (239.192/14) [Meyer], and the only requirement is that the multicast address can be uniquely mapped to a specific VPN. Routers can automate this easily with a simple function that unambiguously maps a VPNid to the multicast address. Subscribing to this multicast address lets a VR discover other VRs and be discovered by them. It's important to note that the multicast address doesn't have to be configured ✨
- Data forwarding can be done in one of several ways 🚀
- An LSP with best-effort characteristics that all VPNS can use.
- An LSP dedicated to a VPN and traffic engineered by the VPN customer.
- A private LSP with differentiated characteristics.
- Policy based forwarding on a dedicated L2 Virtual Circuit.
The choice of the preferred method is negotiable between the SP and the VPN customer, and it could be part of the SLA between them 📝 This lets the SP offer different grades of service to different VPN customers.
Of course, hop-by-hop forwarding is also available to forward routing packets, and to forward user data packets during periods of LSP establishment and failure 🔁
- This approach does not require separate operating system tasks for each routing protocol to run for each VR that the SPED houses 🙅♀️ Specific implementations can be tailored to the particular SPED in use. Keeping separate routing databases and forwarding tables, one per VR, is one way to get the highest performance for a given SPED 🏎️
7. Scalable Configuration 🎀
A typical VPN is expected to have 100s to 1000s of endpoints within the SP cloud 🌈 So configuration should scale (at most) linearly with the number of end points. To be specific, the administrator should have to add a couple of configuration items when a new customer site joins the set of VRs making up a specific VPN. Anything worse would make this task way too daunting for the service provider 😭 In this architecture, all the service provider needs to allocate and configure is the ingress/egress physical link (e.g. Frame Relay DLCI or ATM VPI/VCI) and the virtual connection between the VR and the emulated LAN 💖
8. Dynamic Neighbor Discovery 🧚♀️
The VRs in a given VPN live in a number of SPEDs across the network. These VRs need to learn about each other and get connected 🫧
One way to do this is to require manual configuration of neighbors. For example, when a new site is added to a VPN, every other VR would have to be configured as a neighbor. This is obviously not scalable from a configuration or network resource standpoint 🙈
So the need arises to let these VRs discover each other dynamically 🔍 Neighbor discovery is made possible by giving each VPN a limited emulated LAN. This emulated LAN is used in a couple of ways:
- Address resolution uses this LAN to resolve next-hop (private) IP addresses associated with the other VRs.
- Routing protocols such as RIP and OSPF use this limited emulated LAN for neighbor discovery and to send routing updates.
The per-VPN LAN is emulated using an IP multicast address 💜 To conserve public address space, and because this multicast address only needs to be visible in the SP network space, we would use an address from the Organizationally scoped multicast addresses (239.192/14) as described in [Meyer]. Each VPN is allocated an address from this range. To completely eliminate configuration in this regard, this address is computed from the VPNID 🎉
9. VPN IP Domain Configuration ✨
okay so first we look at the physical side 🦋 this is the physical routing domain in the SP's network:
151.0.0.1
################
# #
# ROUTER 'A' #
# #
################
# #
# #
# #
# #
############# ###############
# # # #
# ROUTER 'B'# # ROUTER 'C' #
# # # #
# # # #
############# ###############
152.0.0.2 153.0.0.3
Figure 1 'Physical Routing Domain'routers A, B and C are all connected together 🌸 each one has a 'public' IP address assigned to it, and those addresses uniquely identify each router in the SP's network. no mix-ups allowed bestie 💅
now the virtual routing domain, which is where it gets iconic 🎀
172.150.0/18 172.150.128/18
----------------------- ---------------------------|
| | |
| | 172.150.128.1
| ROUTER 'A' (151.0.0.1) | |---------|
| ############# | |Parts DB |
| ---#-----------# | /---------/
| OSPF | # # ISIS | /----------/
------------|# VR - A #|--------------
#-------|---#-|
#############10.0.1/24
|----|------------#-#---------------|-----|
|10.0.0.2/24# # |10.0.0.3/24
|------|-------| # # ---------|-------|
| ############### # |############### |
| # VR - B |# # # VR - C # |
|#-------------# ROUTER 'B'##|------------#----
(152.0.0.2)############### ############### (153.0.0.3)
------------------------- ROUTER 'C' | Extranet
172.150.64/18 V
Vendors
Figure 2 'Virtual Routing Domain'each Virtual Router (VR) can be configured by the PNA as though it's a private physical router 🧚 the SP does put limits on how many resources that VR can eat, and those limits are set SPED-by-SPED 💜 every VPN has a bunch of physical connections (to CPE routers) and a bunch of logical connections (to the emulated LAN). every connection is IP-capable, and you can mix and match any of the standard routing protocols and routing policies to hit specific corporate network goals. it's giving customizable 😭🔥
okay the example, because this is where it clicks ✨ in Figure 1, 3 VRs live on 3 SPEDs in VPN 1. router 'A' houses VR-A, router 'B' houses VR-B and router 'C' houses VR-C. VR-C and VR-B each have a physical connection to CPE equipment, but VR-A has 2 of them. every VR has a fully IP-capable logical connection to the emulated LAN.
VR-A has the physical connections to the company's headquarters and runs OSPF over them, so it can route packets to 172.150.0/18 and 172.150.128/18 👑 VR-B runs RIP in the branch office (over the physical connection) and uses RIP (over the logical connection) to export 172.150.64/18 to VR-A. VR-A advertises a default route to VR-B over the logical connection. vendors use VR-C as the extranet connection to reach the parts database at 172.150.128.1, so VR-C advertises a default route to VR-A over the logical connection. VR-A only exports 175.150.128.1 to VR-C 🙈 this keeps the rest of the corporate network safe from a security problem. no cap, that's the whole point.
the network administrator configures the following:
- OSPF connections to the
172.150.0/18and172.150.128/18network in VR-A. - RIP connections to VR-B and VR-C on VR-A.
- Route policies on VR-A to advertise only the default route to VR-B.
- Route policies on VR-A to advertise only
172.159.128.1to VR-C. - RIP on VR-B to VR-A.
- RIP on VR-C to advertise a default route to VR-A.
10. Neighbor Discovery Example 🦋
okay so in Figure #1, the SPED that houses VR-A (SPED-A) uses the public address 150.0.0.1/24, SPED-B uses 150.0.0.2/24 and SPED-C uses 150.0.0.3/24. the VRs talk to each other over an emulated LAN 🌈 for their interface addresses on that emulated LAN, VR-A uses 10.0.0.1/24, VR-B uses 10.0.0.2/24 and VR-C uses 10.0.0.3/24.
let's say VR-A wants to send a packet to VR-B 💅 first it needs VR-B's address (which is SPED-B's address), so VR-A sends an ARP request packet with VR-B's address (10.0.0.2) as the logical address. the source logical address is 10.0.0.1 and the hardware address is 151.0.0.1. this ARP request gets encapsulated in this VPN's multicast address and sent out. SPED-B and SPED-C both get a copy 👀 SPED-B recognizes 10.0.0.2 in the context of VPN 1 and replies with 152.0.0.2 as the "hardware" address. the reply goes out to the VPN multicast address too, which promotes promiscuous ARP and means way less network traffic 🫶 bestie that's efficiency.
manual configuration would be needed if neighbor discovery wasn't used. in this example, VR-A would get a static ARP entry for VR-B's logical address (10.0.0.1) with the "hardware" address set to 152.0.0.2. 😭
11. Forwarding 💖
as we said in the architectural outline, data forwarding can happen in a few different ways. in every technique except the Hop-by-Hop technique for forwarding routing/control packets, the actual method is configurable 🎀 at the high end you've got policy based forwarding for quick service, and at the other end you've got best effort forwarding using public LSP. the order of forwarding preference goes like this:
- Policy based forwarding.
- Optionally configured private LSP.
- Best-effort public LSP.
11.1. Private LSP 🌸
this LSP is optionally configured on a per-VPN basis. it's usually tied to a non-zero bandwidth reservation and/or a specific differentiated service or QOS class. if this LSP is available, it's used for user data AND for VPN private control data forwarding ✨
11.2. Best Effort Public LSP 🧚
VPN data packets get forwarded over this LSP if a private LSP with specified bandwidth and/or QOS characteristics is either not configured or not currently available. the LSP used is the one destined for the egress router in VPN 0. at the egress router, the VPNID in the shim header is what de-multiplexes data packets from the various VPNs 🍓
12. Differentiated Services 👑
configuring private LSPs for VPNs lets the SP offer differentiated services to paying customers 💅 these private LSPs could be associated with any available L2 QOS class or Diff-Serv codepoints. in a VPN, you could configure multiple private LSPs with different service classes and set up flow profiles to sort the packets among those LSPs. this feature, plus the ability to size the virtual routers, lets the SP offer truly differentiated services to the VPN customer. it's literally main character energy for the SP 🔥
13. Security Considerations 🔥
⚠️ bestie, this section is serious. read it carefully, every line matters.
13.1. Routing Security 🛡️
using standard routing protocols like OSPF and BGP in their unmodified form means all the encryption and security methods (such as MD5 authentication of neighbors) are fully available in VRs. making sure routes don't get accidentally leaked from one VPN to another is an implementation issue 😰 one way to handle it is to maintain separate routing and forwarding databases.
13.2. Data Security 🔒
this lets the SP assure the VPN customer that data packets in one VPN never have the opportunity to wander into another 🙈 from a routing standpoint, that can be achieved by maintaining separate routing databases for each virtual router. from a data forwarding standpoint, using label stacks with shared LSPs [Rosen2] [Callon], or using private LSPs, guarantees data privacy. packet filters can also be configured to help ease the problem.
13.3. Configuration Security 🗝️
virtual routers look like physical routers to the PNA. that means the PNA can configure them to achieve connectivity between a corporation's offices. obviously the SP has to guarantee that the PNA and the PNA's designees are the ONLY ones with access to the VRs on the SPEDs the private network connects to 😱 since the virtual router console is functionally equivalent to a physical router, all the authentication methods available on a physical console, like password, RADIUS, etc., are available to the PNA.
13.4 Physical Network Security 🧱
when a PNA logs in to a SPED to configure or monitor the VPN, the PNA is logged into the VR for that VPN. the PNA only has layer 3 configuration and monitoring privileges for the VR. specifically, the PNA has no configuration privileges for the physical network. this gives the SP the guarantee that a VPN administrator can't inadvertently or otherwise adversely affect the SP's network 💖 safety first, periodt.
14. Virtual Router Monitoring 🔍
all of the router monitoring features on a physical router are available on the virtual router ✨ that includes utilities like "ping" and "traceroute". on top of that, you can display private routing tables, link state databases, etc. it's giving full visibility 👀🌈
15. Performance Considerations ✨
okay bestie, so for talking about performance and scaling, today's routers get split into two planes: the routing (control) plane and the forwarding plane 🧚
In the routing plane, most modern routing protocols use some kind of optimized calculation to work out the shortest path(s) to end stations. OSPF and ISIS use the Djikstra algorithm, and BGP uses the "Decision Process" 💅 These algorithms parse the routing database and compute the best paths. How fast they run depends on the topology (for ISIS and OSPF) or on how many ASs are in the path to the destination (for BGP). But here's the thing 🫶 the setup overhead for starting these calculations is very little for basically any modern router. Even though we call the routing calculation inputs "databases," they're memory resident data structures, so it's giving speed 🔥
So, the following conclusions can be drawn:
- Starting a routing calculation for a routing domain is nothing more than setting up some registers to point to the right database objects. 💖
- Based on 1, the performance of a given algorithm is not significantly worsened by the overhead required to set it up. ✨
- Based on 2, when a physical router has to run routing calculations for a number of virtual routers, the complexity of the result is nothing more than the sum of the complexities of the individual virtual routers' calculations. 🌸
- Based on 3, whether an overlay model or a virtual routing model is used, a router's performance depends purely on its hardware capabilities and the choice of data structures and algorithms. 👑
Let's make it concrete 🦋 Say a physical router houses N VPNs, all running some routing protocol we'll call RP. Suppose the average performance of RP's routing calculation algorithm is f(X,Y), where x and y are the parameters that determine how fast the algorithm runs for that protocol. For example, for Djikstra algorithm users such as OSPF, X could be the number of nodes in the area and Y could be the number of links. The performance of an arbitrary VPN n is f (Xn, Yn). The performance of the (physical) router is the sum of f(Xi, Yi) for all values of i in 0 <= i <= N. This conclusion is independent of the chosen VPN approach (virtual router or overlay model) 🙈
Now the forwarding plane 💜 It has two inputs: the forwarding table and the packet header, and the main performance parameter is the lookup algorithm. The very best performance you can get for an IP routing table lookup is organizing the table as some form of tree and using binary search methods to do the actual lookup. The performance of this algorithm is O(log n). 🍓
So, as long as the virtual routers' routing tables are distinct from each other, the lookup cost is constant for finding the routing table and O(log n) to find the entry. This is no worse or different from any router, and no different from a router that uses overlay techniques to deliver VPN services. However, when the overlay router integrates multiple VPNs' routing tables, the performance is O(log m*n), where 'm' is the number of VPNs that the routing table holds routes for. ⭐
16. Acknowledgements 🎀
The authors wish to thank Dave Ryan, Lucent Technologies, for his invaluable in-depth review of this version of this memo. 🫶💖
17. References 📚
[Callon] Callon R., et al., "A Framework for Multiprotocol Label Switching", Work in Progress.
[Fox] Fox, B. and B. Gleeson,"Virtual Private Networks Identifier", RFC 2685, September 1999.
[Meyer] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998.
[Rosen1] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[Rosen2] Rosen E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", Work in Progress.
18. Authors' Addresses 🦋
Karthik Muthukrishnan Lucent Technologies 1 Robbins Road Westford, MA 01886
Phone: (978) 952-1368 EMail: mkarthik@lucent.com
Andrew Malis Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134
Phone: (408) 383-7223 EMail: Andy.Malis@vivacenetworks.com
19. Full Copyright Statement 🌈
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💅
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc2917 2000-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms