RFC 4365

Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)

📅 published February 2006, from ietf

Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs) ✨

Okay bestie, here's the title block 🎀 This one's from the Network Working Group and it was written by E. Rosen at Cisco Systems, Inc. 💼 It's marked as Informational (so it's giving "here's some info," not "you must do this") 🧚 and it's dated February 2006 📅 It doesn't list anything it obsoletes or updates, so there's no drama with older RFCs 🫶

Network Working Group                                           E. Rosen
Request for Comments: 4365                           Cisco Systems, Inc.
Category: Informational                                    February 2006

Status of This Memo 📜

This memo gives info to the Internet community 💖 It is NOT a standard of any kind, and it can be shared freely with no limits 🌸

Copyright (C) The Internet Society (2006). 💜

Abstract 🦋

So this doc is basically an Applicability Statement for the VPN solution in RFC 4364 and some other docs listed in the References section 🌈

Table of Contents 🗂️

   1. Introduction ....................................................2
   2. SP Provisioning Model ...........................................4
   3. Supported Topologies and Traffic Types ..........................6
   4. Isolated Exchange of Data and Routing Information ...............7
   5. Access Control and Authentication ...............................9
   6. Security Considerations .........................................9
      6.1. Protection of User Data ....................................9
      6.2. SP Security Measures ......................................10
      6.3. Security Framework Template ...............................12
   7. Addressing .....................................................18
   8. Interoperability and Interworking ..............................19
   9. Network Access .................................................19
      9.1. Physical/Link Layer Topology ..............................19
      9.2. Temporary Access ..........................................19
      9.3. Access Connectivity .......................................20
   10. Service Access ................................................21
      10.1. Internet Access ..........................................21
      10.2. Other Services ...........................................21
   11. SP Routing ....................................................22
   12. Migration Impact ..............................................22
   13. Scalability ...................................................23
   14. QoS, SLA ......................................................26
   15. Management ....................................................27
      15.1. Management by the Provider ...............................27
      15.2. Management by the Customer ...............................28
   16. Acknowledgements ..............................................28
   17. Normative References ..........................................29
   18. Informative References ........................................29

1. Introduction 💅

Okay so this doc is an Applicability Statement for the VPN solution described in [BGP-MPLS-IP-VPN] and some other docs in the References section 📚 We call these "BGP/MPLS IP VPNs" 🎀 The reason is that Border Gateway Protocol (BGP) is used to spread the routes around, and Multiprotocol Label Switching (MPLS) is used to mark that certain packets need to follow certain routes 🚀 The features of BGP/MPLS IP VPNs get compared to the requirements in [L3VPN-REQS] ✨

A VPN service is provided by a Service Provider (SP) to a customer (sometimes called an enterprise) 💼 BGP/MPLS IP VPNs are meant for when:

  • The customer:
    • only uses the VPN for carrying IP packets 📦
    • doesn't want to run a routed backbone 🙅‍♀️ The customer might be using routing inside their sites, but they want to outsource the inter-site routing to the SP 🫶
    • wants the SP to make the backbone and its routing completely invisible to the customer's own routing 🙈

If the customer has a routed setup at their sites, they don't want their site routing algorithms to have to know about any part of the SP backbone, except for the Provider Edge (PE) routers the sites plug into 🔌 Like, the customer does NOT want their routers to need to know either the native structure of the SP backbone or an overlay of tunnels running through it 💀

  • The Service Provider:
    • has an IP backbone with MPLS-enabled edge routers, and possibly (though not necessarily) MPLS-enabled core routers 🌐
    • wants to offer a service that meets the customer requirements above 💖
    • doesn't want to maintain a separate overlay of tunnels for every customer 🧚

The basic idea is to treat each VPN like its own self-contained "internet" 🌈 Each site connects to an SP through one or more access connections, sends the SP its routing information, and then trusts the SP to pass routing information to and from the other sites in that same VPN 🫶 This is different from regular Internet service though, because the SP strictly controls how this routing info gets distributed 👑 Routes from inside a VPN don't go outside the VPN unless the customer explicitly allows it 🔒 Even inside the VPN, the SP may control how routes get distributed so it can meet some policy of the customer 💅

The routers at one customer site don't need to be routing peers with the routers at other customer sites, and they don't even need to know anything about the internal structure of those other sites ✨ Different sites can run different routing protocols too, with each site using whatever protocol fits that site best 🎀

If EBGP (the BGP procedures used between BGP speakers from different Autonomous Systems) is used on the access links that connect a Provider Edge router (PE router) to a Customer Edge router (CE router), then the SP and the customer do NOT peer in any Interior Gateway Protocol (IGP), i.e., intra-domain routing algorithm) 🙅‍♀️

BGP/MPLS IP VPNs are optimized for when a customer (an enterprise) expects a service provider to operate and maintain the customer's "backbone" (aka the customer's inter-site routing) 💼 That makes the service provider a "business partner" of the enterprise 🤝 The technical mechanisms also handle the case where a bunch of closely cooperating SPs can team up to offer the VPN service to one customer, since the BGP-based route distribution can work between different SPs 🫶 If a set of SPs has enough agreements about Quality of Service (QoS), Service Level Agreement (SLA), etc., then the customer's VPN could have sites attached to different SPs from that set 🌸

[BGP-MPLS-IP-VPN] specifies the inter-AS (Autonomous System) mechanisms that let a single VPN have sites attached to different SPs 🧩 BUT the design center is NOT an environment where one VPN gets spread across a massive number (e.g., hundreds) of SPs 🙃

When remote offices, individual telecommuters, etc. need to use the public Internet to reach the VPN, it's possible to "tunnel" that remote traffic to a PE router 🚇 The PE router then treats the traffic as if it arrived over an interface connected to the PE 🔁 Remote Point-to-Point Protocol (PPP) connections can be tunneled via Layer 2 Tunneling Protocol (L2TP) to a PE router 📞 IPsec tunnels can also be used to tunnel traffic to a PE router across the public Internet 🔐 Of course, when the public Internet is involved, things like QoS and SLAs must be carefully considered 👀

⚠️ Heads up: when the public Internet is in the mix, QoS and SLAs need careful thought. Don't skip this one, bestie 💀

Some customers want to connect their sites over the public Internet to make a VPN "virtual backbone" 🌍 They buy connectivity for each site from whatever Internet Service Provider (ISP) has the best price for that site 💸 A BGP/MPLS IP VPN is NOT the right solution for these customers 🙅‍♀️ Instead, they need to look at solutions (either customer-managed or provider-managed) that connect their sites through an overlay of secure tunnels across the Internet 🔒 (See, for example, [IPSEC-VPN].)

Some customers don't want to connect their sites with secure site-to-site tunnels over the Internet, but they still want full control over the routing in their VPN backbone 👑 These customers won't want a "managed routing service" like the one BGP/MPLS IP VPNs provide, since that hides all the details of the backbone routing and topology from the customer 🙈 They'd probably prefer a "virtual router" service, where the tunnels through the SP networks show up as links to the customer's routing algorithm 🧚 (See, for example, [VR-VPN].) 🦋

Part 1 of 7 done, more to come 💖

2. SP Provisioning Model ✨

okay bestie, so if a VPN plugs into a PE router, the SP has to set up a VPN Routing and Forwarding table (VRF) on that PE 🫶. it's a routing table that belongs to just that one VPN. (the [L3VPN-REQS] and [L3VPN-FRMWRK] docs call this a VPN Forwarding Instance, or VFI 🤓.) every interface or sub-interface on that PE that hooks up to a site in the VPN (aka each local access link of that VPN) has to be associated with that VRF 💅. each one can be unnumbered, or it can get an address that's unique within the VPN's address space. usually a routing algorithm runs on each of these links, though static routing is an option too 🧚. the algorithm can be EBGP, or an IGP like Routing Information Protocol (RIP) or Open Shortest Path First (OSPF). (IF OSPF is used, the procedures of [VPN-OSPF] MUST be implemented 📚.) and if an IGP runs on the access links, that IGP MUST be a separate IGP instance. it has to be different from the IGP running among the backbone routers, and different from the IGP running on the access links of any other VPN 🔥. static routing is allowed too, obviously.

the VRF fills itself up automatically. it learns routes from locally attached CE routers through whatever routing algorithm runs on the PE/CE links, and it also learns routes from other VRFs through BGP 🌸. standard routing decision processes pick the best routes automatically. static route config in the VRF is optional, so you don't have to do it.

each PE router has to run BGP. it also has to be pre-configured with the identities of a small set of BGP Route Reflectors, which it peers with via IBGP ✨. ("IBGP" just means the BGP procedures used between BGP speakers from the same Autonomous System.)

you could skip Route Reflectors and configure each PE with the identities of all the other PEs, creating a full mesh of IBGP connections 🕸️. that might be fine for small networks, but it won't scale well to big ones. Route Reflectors are necessary for scalability 😭. see section 4.3.3 of [BGP-MPLS-IP-VPN] for a much more complete explanation of Route Reflectors and related scalability stuff, like Outbound Route Filtering 💜.

each VRF has to be configured with three parameters 👑:

  • A Route Distinguisher. This is a globally unique 8-byte value. each VRF can get its own unique Route Distinguisher (RD), or there can be a single unique RD for an entire VPN. when BGP distributes VPN routing info across the SP backbone, this value gets prepended to the VPN's IPv4 address prefixes. that creates a brand new address family, the VPN-IPv4 address family 🦋. so even if two VPNs have overlapping IPv4 address spaces, their VPN-IPv4 address spaces are still unique. iconic 💅
  • One or more Export Route Targets. A Route Target (RT) is a globally unique 8-byte value. BGP carries it as the Extended Communities Route Target attribute, along with routes that get exported from the VRF 🎀.
  • One or more Import Route Targets. this RT is used to select which routes get imported from other VRFs into this VRF 🍓.

in the simplest and most common cases, the Export RT, Import RT, and RD can all be identical. then all the VRFs in the same VPN distribute routes to each other, which is basically a typical intranet 🫶. in more complex cases they can be set differently, which gives you a super fine degree of control over how routes get distributed among VRFs ✨. that's how you make extranets or enforce various customer policies. in complicated cases, particular Export RTs can be assigned to particular routes using router management mechanisms 🔧. one perk of the RD not having to match any RT is that an RD value can be determined automatically for each VRF 🤖. RT values, on the other hand, must always be configured 🙈.

adding a new site to a VPN is giving simple energy: attach the site's CE router to a PE router, configure the interface, and, if a VRF for that VPN already exists on the PE, associate that interface with the VRF 💖. if there isn't a VRF for that VPN on the PE yet, you configure one as described above. and any changes to a PE's config get automatically reflected via BGP to the other PEs 🌈.

the RTs and RDs are made unique by being structured as an SP identifier followed by a number that the identified SP assigns 🔢. SPs can be identified by their AS numbers, or by a registered IP address owned by that SP 🌟.

although RTs are encoded as BGP Extended Communities, the encoding itself tells them apart from any other kind of BGP Extended Community 🦋.

3. Supported Topologies and Traffic Types 🌈

the scheme is optimized for full inter-site connectivity. that's just what the simplest configurations give you, so it's the main-character setup 👑.

BUT the SP has full control over how routing info gets distributed among the set of VRFs, through the Route Target mechanism 🎯. so the SP can offer hub-and-spoke or partial mesh connectivity, not just full mesh 🕸️. flexible, periodt 💅.

ngl, strictly speaking, the scheme doesn't create a topology, because it doesn't create layer 2 connections among the sites 🙈. it does, however, let you control the IP connectivity among the sites ✨. you can even constrain how routing gets distributed in pretty arbitrary ways. for example, data from site A to site B could be forced to go through a third site C 🧚. (and if you want, you can get this level of control down to the granularity of a single route 🔥.)

it's also possible for some routes from one customer site A to go to one set of remote sites, while other routes from site A go to a different set 💜. that's done with the Route Target mechanism we just talked about 🎀.

unicast IP traffic is fully supported 💖. customer IP packets are passed transparently 🫶.

multicast IP traffic is optionally supported, but only if the SP provides the optional mechanisms of [BGP-MPLS-MCAST-VPN] 🦋. these mechanisms come with scaling implications, and we're deferring that discussion for now 😭.

non-IP traffic is not supported 🚫. if you really need non-IP traffic, either the SP has to additionally provide a layer 2 tunneling service, or the customer has to use IP tunneling 🍓.

in general, customer routers at different sites do not become routing peers 🙅‍♀️. BUT a customer can, if they so desire, let routers at different sites be routing peers over a link that is NOT part of the VPN service. these peering relationships are called "IGP backdoors" 🚪. to keep routing working properly when IGP backdoors are present, every VPN route the SP distributes comes along with a corresponding routing metric 📊. this lets the customer's IGP compare the "backdoor routes" properly with the routes that use the SP backbone. in the special case where a customer running OSPF within their sites wants IGP backdoors, they should run OSPF on the PE/CE link, and the PEs should run the procedures of [VPN-OSPF]. (the CEs do NOT require any special OSPF procedures 💅.)

4. Isolated Exchange of Data and Routing Information 🔐

the Route Target mechanism controls how routing info gets distributed, so routes from one VPN never get sent to another 🙅‍♀️. BGP treats VPN routes as a different address family than general Internet routes, which keeps everything separate 🧱. routes from a VRF don't get leaked to the Internet unless the VRF has been explicitly configured to allow it, and that is NOT the default 🛡️.

the way a particular VPN is divided into sites, and the topology of any particular VPN site, is hidden from the Internet and from other VPNs 🕵️‍♀️. (ngl, if a site can receive Internet traffic and it responds to traceroute probes from the Internet, then any Internet user can learn something about that site's topology 😬. being in a VPN doesn't make that any easier or harder.)

same energy the other way: Internet routes don't get leaked into the VPN, unless a VRF of that VPN is explicitly configured to import the Internet routes 🚫.

proper configuration is essential for keeping the isolation 🔑. each access link has to be associated with the proper VRF for that link, and each VRF has to be configured with the proper set of RTs 💜.

there are a few ways the PE and CE devices can exchange reachability info 🔄. static routing, EBGP, and RIP are supported by the procedures of [BGP-MPLS-IP-VPN] 💖. if the procedures of [VPN-OSPF] and [OSPF-2547-DNBIT] are implemented, OSPF can be used too 🦋. and if OSPF is used between two VPN sites that are in the same OSPF area, and you want routes over the VPN backbone to be preferred to the OSPF intra-site routes, then the "sham link" procedures of [VPN-OSPF] must be used 🎀.

the routing protocols used among the customer routers aren't restricted in any way by the VPN scheme 🙌. whatever IGP the customer uses within the VPN, the PE/CE access links may run EBGP, or may otherwise sit in a different routing domain than the site's internal links 🌸.

BGP is used for passing routing info among SPs 🤝. BGP may be authenticated with the TCP MD5 option, or by operating through an IPsec tunnel 🔒.

data traveling between two customer sites gets encapsulated while it's in transit through the backbone 📦. the encapsulation has enough info to make sure the packet gets sent to the proper PE router. then, along with the VRF and related info at that PE, it gets delivered to the proper CE routers 🎯.

if two VPNs attach to the same PE, there's strict separation of forwarding at that PE, and strict separation of the routing info too 🧱👑.

isolation of traffic is similar to what classical L2 VPNs based on Frame Relay or Asynchronous Transfer Mode (ATM) provide 🕰️. same as in those classical L2 VPNs, the customer has to rely on the SP to configure the backbone network properly, so the isolation holds and their communications gear stays secure 🫶🔐.

5. Access Control and Authentication ✨

okay so authentication for BGP/MPLS IP VPNs? the spec just doesn't pick one 🫶 no particular PE/CE auth method is specified. bestie, you can do mutual PE/CE auth with whatever the routing protocol between the CE and PE already supports, like TCP MD5 if the PE/CE protocol is BGP, or literally any other mechanism you want 💅 with that in place, a CE can't join a VPN until it authenticates itself to the Service Provider.

BUT, and this is lowkey the tea, there is no standardized method that makes a CE authenticate to the customer network (rather than the SP) before it's allowed into the VPN 😭 that one is listed as for further study. 🔮

packet filtering? also not specified. no particular means for controlling which user data packets get forwarded 🙈 the good news is BGP/MPLS IP VPNs play nicely with Access Control Lists (ACLs) and any other filtering features the PE routers support. and if you want extranet traffic to go straight through a firewall, you can set up routing that way 🔥

tunnel interfaces are also a thing 🦋 various sorts of "tunnel interfaces" can be associated with a VRF, and whatever authentication is natively used to set up the tunnel interface can be used too. like, an IPsec tunnel can be an "access link" to attach a remote user or site to a VRF. in that case the authentication is part of IPsec, not part of the VPN scheme, so it's giving "not my department" energy 💀

and for L2TP: each PPP session carried in an L2TP tunnel can be associated with a VRF. the SP's Authentication, Authorization, and Accounting (AAA) server can work out which VPN the PPP session belongs to, and then the customer's AAA server gets the chance to authenticate that session as well 🎀

6. Security Considerations 🔐

Security is serious business, so let's go 😤

6.1. Protection of User Data

no particular means of keeping user data secure is specified for BGP/MPLS IP VPNs 😬

the optional procedures of [MPLS/BGP-IPsec] can be used to add authentication and/or encryption to user data as it travels from the ingress PE to the egress PE. BUT the data is still exposed at those two PEs, and also on the PE/CE access links, so don't get too comfy 🙈

the customer can bring their own data security by using IPsec tunnels that terminate inside the customer sites. those tunnels are transparent to the VPN scheme ✨ schemes that discover the remote tunnel endpoints automatically and then set up tunnels automatically as needed are the best fit with this VPN tech 🧚 and note that there's no general requirement that IPsec tunnels between customer sites terminate at CE routers.

customers can also use end-to-end transport mode IPsec, and that's transparent to the VPN scheme too 💖 in fact, the VPN scheme works with any security the customer uses, as long as a cleartext IP header gets passed from CE to PE.

when data has to cross the Internet to reach the ingress PE router, IPsec tunnels between the end user and the PE router can be used. the PE router then has to associate each IPsec tunnel with the proper VRF. that association would have to be based on user-specific info given by the Internet Key Exchange (IKE) protocol, like a VPN-id 🌈

if data is going from one SP network to another and has to cross the public Internet to get between them, IPsec tunnels can secure the data. this would need a bilateral agreement between the two SPs 🤝 BGP connections can also go through an IPsec tunnel if a pair of SPs decides it's necessary to protect user data. QoS/SLA factors would have to be carefully considered in this case 👑

6.2. SP Security Measures

the SP is responsible for stopping illegitimate traffic from entering a VPN 🛡️ VPN traffic is always encapsulated while it travels across the backbone, so keeping out illegitimate traffic comes down to making sure the PE routers do the encapsulation/decapsulation correctly, and that encapsulations haven't been "spoofed". in other words, the encapsulated packets really were encapsulated by PE routers. 👀

that means the SP has to take a bunch of security measures 💅 the PE and P routers must themselves be secure against break-ins, whether from someone physically present or from the Internet 😭 and neither P nor PE routers should form routing adjacencies with other P or PE routers unless there's some kind of security in place. that could be authentication in the IGP, or physical security 🔒

the PE/CE access link should be secured in some way, though the provider may make it the customer's job to make sure the CE is secure from compromise 🫠 and if the PE/CE access link is a tunnel over the Internet, then of course some sort of authentication protocol should always be used. no skipping that one, babe ⭐

Label Distribution Protocol (LDP) sessions and BGP sessions between PE and/or P routers should be authenticated. this can be done with the TCP MD5 option or with IPsec 🎀

if the SP is providing the VPN service over an MPLS backbone, it should not accept MPLS packets from its external interfaces (that means interfaces to CE devices or to other providers' networks) unless the top label of the packet was legitimately distributed to the system the packet is being received from. 🚫 if the packet's incoming interface leads to a different SP (rather than a customer), an appropriate trust relationship must also be in place, including trust that the other SP also provides appropriate security measures 🤝

if the SP is providing the VPN service using an IP encapsulation (rather than MPLS), or if it accepts IP-encapsulated VPN packets from other SPs, it should apply filtering at its borders. that way it doesn't accept IP packets from other SPs or from customers if those packets are addressed to the PE routers, unless appropriate trust relationships are in place 🧱

cryptographic authentication of the encapsulated data packets is definitely advantageous when there are multiple SPs providing a single VPN 💜

now the DoS situation 😱 when a dynamic routing protocol runs on the link between a CE router and a PE router, routing instability in the private network can affect the PE router. for example, an unusually large number of routing updates could get sent from the CE router to the PE router, putting an unusually heavy processing load on the PE router. this can potentially be used as a Denial-of-Service (DoS) attack on the PE router 💀

this can be mitigated with resource partitioning in the PE, which limits how much of the resources (like CPU and memory) any one VPN is allowed to use in PE routers 🧠 rate limits can also be applied to the routing traffic sent from the CE to the PE. or, alternatively, when the problem is detected, the CE-to-PE interface can be shut down 🙅‍♀️

and network management traffic from the CE to the PE can be rate limited too (for example, so network management traffic from CE to PE can't be used in a DoS attack) 🍓

6.3. Security Framework Template

okay so [L2VPN-SEC-FRMWRK] has this Section 9 with "a brief template that may be used to evaluate and summarize how a given PPVPN [Provider-Provisioned Virtual Private Network] approach (solution) measures up against the PPVPN Security Framework". it also says "an evaluation using this template should appear in the applicability statement for each PPVPN approach" 📝 so this subsection gives the info in the format that template asks for. security requirements that only apply to L2VPNs don't apply here, so we're skipping those 🙅‍♀️

  • Does the approach provide complete IP address space separation for each L3VPN?

Yes. ✅

The IP address prefixes from a particular VPN only show up in their native form in routing tables that are specific to that VPN. they're only distributed in native form by routing instances that are specific to that VPN too 💖 when address prefixes from different VPNs get combined into a common table, or distributed by a common mechanism, the prefixes are first prepended with a Route Distinguisher (RD). the RD is a 64-bit quantity, structured so that globally unique RD values can easily be created by an SP ✨ as long as no two VPNs are assigned the same RD value, you get complete IP address space separation. it is possible for an SP to misconfigure the RD assignments though, so double-check those 🙈

  • Does the approach provide complete IP route separation for each L3VPN?

Yes. ✅

route distribution is controlled by assigning import and export Route Targets (RTs) 🎯 a route that's exported from a VRF carries an RT that the SP specifies as an export RT for that VRF. the route can only be imported into other VRFs if the RT it carries has been configured by the SP as an import RT for those other VRFs. so the SP has complete control over which VRFs a route gets distributed to 👑 it's of course possible for the SP to misconfigure the RT assignments, so keep an eye on them 👀

  • Does the approach provide a means to prevent improper cross-connection of sites in separate VPNs?

This requirement is handled in a way that's beyond the scope of the VPN mechanisms 🙃

in BGP/MPLS IP VPNs, an SP puts a particular site into a particular VPN by configuring the PE router's interface to that site so it's associated with a particular VRF in that PE. the VRF is configured with import and export RTs, and the way VRFs get configured with RTs across the various PEs is what ends up connecting a particular set of sites as a VPN 🧩

connecting the sites properly like this is considered a network management function, and the VPN scheme itself doesn't provide a means to prevent misconfiguration 😤

the VPN scheme also doesn't provide any particular method for making sure a given interface from a PE leads to the CE that's expected to be there. if a routing algorithm runs on a particular PE/CE interface, whatever security procedures the routing algorithm provides (like MD5 authentication of BGP sessions) can be used, but that's outside the scope of the VPN scheme 🫶 and a CE can also attach to a PE via an IPsec tunnel, if that's wanted, for a greater degree of security 🔐

  • Does the approach provide a means to detect improper cross-connection of sites in separate VPNs?

the base specifications for BGP/MPLS IP VPNs don't provide a means for detecting that a site has been connected to the wrong VPN 😬 BUT the optional procedure in [CE-VERIF] does provide such a means! 🎉 basically, each PE gets a secret from each CE it's directly attached to, via protocol. when the routes from a given CE get distributed, the secret from that CE is attached as an attribute of the route. this secret will eventually be distributed to any other CE that receives any route from the given CE 💌 a CE that isn't supposed to be part of a given VPN won't know the right secret, and if it's connected to that VPN, the other CEs in the VPN will realize that a CE that doesn't know the proper secret has been plugged in 🚨

  • Does the approach protect against the introduction of unauthorized packets into each VPN?

we have to look separately at the various points where someone might try to introduce unauthorized packets 👀

  • Packets arriving at a PE over a PE/CE interface 🎀

If a given PE is directly connected to a given CE, the PE will accept any packets that the CE sends it. The VPN scheme has no special procedures for determining that these packets actually came from the CE. ngl that's a little bit of a trust fall 🙈 But various means of securing the PE/CE connection can be used (for instance, the PE and CE can be connected by an IPsec tunnel) if desired. That is, this aspect of the requirement can be addressed by means that are outside the scope of the VPN specification. 🔐

Once a packet has been accepted from a CE by a PE, the packet is routed according to the VRF associated with that PE's interface to that CE. Such packets can only be sent along routes that are in that VRF. There is no way a packet from a CE can be routed to an arbitrary VPN. In particular, there is nothing a VPN user can do to cause any particular packet to be sent to the wrong VPN. So this aspect of the requirement is fully addressed 💅✨

  • Packets arriving at a PE over an interface from the backbone 🦋

The optional procedures of [MPLS/BGP-IPsec] can be used to ensure that a packet that is received by a PE from the backbone will not be recognized as a VPN packet unless it actually is one. Those procedures also ensure that a received VPN packet came from a particular PE and that it carries the MPLS label that that PE put on it. These procedures protect the packet from ingress PE to egress PE, but do not protect the PE/CE interfaces. 🛡️

If the optional procedures of [MPLS/BGP-IPsec] are not used, then the following considerations apply. 👀

Undetected corruption of the routing information carried in a packet's VPN encapsulation can result in misdelivery of the packet, possibly to the wrong VPN. 😭

If a packet enters an SP's network on an interface other than a PE/CE interface, the SP should ensure that the packet either does not look like a VPN packet or else is not routed to a PE router. This can be done in a variety of ways that are outside the scope of the VPN scheme. For example, IP packets addressed to the PE routers can be filtered, MPLS packets (or, e.g., MPLS-in-IP) from outside the SP network can be refused, etc. 🧱

In the case of a multi-provider L3VPN backbone, the SP will have to know which interfaces lead to SPs that are VPN partners, so that VPN packets can be allowed to flow on those interfaces. 🤝

If the public Internet is used as the L3VPN backbone, protection against unauthorized packets cannot be achieved by the above measures. IPsec tunnels should always be used to carry VPN traffic across the public Internet. 🚨
  • Does the approach provide confidentiality (secrecy) protection, sender authentication, integrity protection, or protection against replay attacks for PPVPN user data?

If these are desired, they must be provided by mechanisms that are outside the scope of the VPN mechanisms. For instance, the users can use secure protocols on an end-to-end basis, e.g., IPsec, Secure Shell (SSH), Secure Sockets Layer (SSL), etc. 🔒🫶

  • Does the approach provide protection against unauthorized traffic pattern analysis for PPVPN user data?

Preventing an observer from obtaining traffic pattern analysis from the SP network is beyond the scope of the VPN mechanisms. 🙈

  • Do the control protocol(s) used for each of the following functions provide for message integrity and peer authentication?
    • VPN membership discovery 🌸

This requirement is fully satisfied. Membership discovery is done by means of BGP. Control message integrity and peer authentication in BGP may be achieved by use of the TCP MD5 option. 💜

  • Tunnel establishment 🧚

The answer to this question depends of course on the tunnel protocol and tunnel establishment protocol; a variety of different tunneling schemes can be used in BGP/MPLS IP VPNs. Thus, this question is out of scope.

In the common case where the tunnels are MPLS Label Switching Routers (LSRs) established by LDP, then control message integrity and peer authentication may be achieved by use of the TCP MD5 option. 🍓

  • VPN topology and reachability advertisement 👑

With respect to PE-PE interactions, the relevant control protocol is BGP, so control message integrity and peer authentication can be achieved by use of the TCP MD5 option.

With respect to CE-PE interactions, the answer depends on the protocol used for exchanging information between PE and CE, as the security mechanisms (if any) of those protocols would need to be used. In the common case where the PE/CE protocol is BGP, the TCP MD5 option can be used. 🌈

  • VPN provisioning and management 🧾

The protocols procedures for provisioning VPNs and managing the PE routers are outside the scope of the VPN scheme. 🤷‍♀️

  • VPN monitoring and attack detection and reporting 🔍

The protocols and procedures for monitoring the VPNs are outside the scope of the VPN scheme. 👁️

  • What protection does the approach provide against PPVPN-specific DoS attacks (i.e., inter-trusted-zone DoS attacks)?
    • Protection of the service provider infrastructure against Data Plane or Control Plane DoS attacks originated in a private (PPVPN user) network and aimed at PPVPN mechanisms. 🚧

The PE/CE interfaces of a given VPN will generally be addressable from within that VPN. Apart from that, a user within an L3VPN has no more access to the service provider infrastructure than does any user of the Internet. Therefore, we will focus in this section on possible DoS attacks against a PE router that may occur when traffic from within a VPN is addressed to a PE router. 🎯

A user within the VPN may address traffic to a PE router and may attempt to send an excessive amount of traffic to it. Presumably, the PE routers will not accept unauthorized TCP connections or Simple Network Management Protocol (SNMP) commands, so such traffic will be thrown away; the danger is that the PE may need to use a significant proportion of its capacity to discard such traffic. However, this case is no different than the case of any SP access router that attaches to subscriber equipment. The presence of the VPN mechanisms does not make the PE any more or less vulnerable to DoS attacks from arbitrary end users. 😤

  • Protection of the service provider infrastructure against Data Plane or Control Plane DoS attacks originated in the Internet and aimed at PPVPN mechanisms. 🌐

DoS attacks of this sort can be prevented if the PE routers are not addressable from the Internet. Alternatively, an SP can apply address filtering at its boundaries so that packets from the Internet are filtered if they are addressed to a PE router. 🙅‍♀️

  • Protection of PPVPN users against Data Plane or Control Plane DoS attacks originated from the Internet or from other PPVPN users and aimed at PPVPN mechanisms. 🛸

Mechanisms already discussed prevent users in a VPN from receiving packets from the Internet, unless this is specifically allowed. In the case where it is specifically allowed, it is no different than any other situation in which a network is connected to the Internet, and there is no special vulnerability to DoS attacks due to the L3VPN mechanisms.

There is nothing to prevent a user in a VPN from mounting a DoS attack against other users in the VPN. However, the L3VPN mechanisms make this neither more nor less likely. 💀

  • Does the approach provide protection against unstable or malicious operation of a PPVPN user network?
    • Protection against high levels of, or malicious design of, routing traffic from PPVPN user networks to the service provider network. 🌪️

If a dynamic routing algorithm is running on the PE/CE interface, it can be used to mount an attack on the PE router, by having the CE present the PE with an excessive number of routing events. If an end user within a VPN successfully attacks the routing algorithm of the VPN, that might also result in an excessive number of routing events being seen by the PE router. This sort of attack can be ameliorated by having the PE limit the amount of its resources that can be expended processing routing events from a particular VPN. If the PE/CE routing algorithm is BGP, then such mechanisms as route flap damping may be appropriate as well. 🧃

  • Protection against high levels of, or malicious design of, network management traffic from PPVPN user networks to the service provider network. 📡

A user in a BGP/MPLS IP VPN has no more ability than any Internet user to send management traffic to the service provider network. 🙌

  • Protection against worms and probes originated in the PPVPN user networks, sent towards the service provider network. 🐛

A user in a BGP/MPLS IP VPN has no more ability than any Internet user to send worms or probes to the service provider network. 🫧

7. Addressing 🎀

Okay, bestie, overlapping customer addresses are totally supported 💅 There's no rule that they have to follow [RFC1918]. Customer VPN addresses don't have to be different from the addresses inside the SP network either 🦋

Basically any set of addresses works in the VPN, no matter how they got assigned, how well they aggregate, or whether they're public or private ✨ The one catch is that the set of addresses reachable from a given site must be unique 🔥

Network address translation for packets going out of or coming into a VPN is possible, and the VPN scheme doesn't even notice it's happening 🙈

Nothing in the architecture stops these mechanisms from being extended to IPv6 🌈 As long as the IPv6-capable routing algorithms are in place, you're good. PE/CE routing must support IPv6, and the PE-PE BGP must support the labeled IPv6 address family. That one hasn't been specified yet, but it's super obvious from how the labeled IPv4 address family was specified 💜 Also, the IGP in the SP backbone doesn't need to be IPv6 capable to support customer IPv6 networks. Iconic 👑

In theory the same logic works for other network layers too, but in practice, if a customer has non-IP traffic, they must expect to carry it either in site-to-site IP tunnels or through some extra service from the SP, like a layer 2 service 🧚

Layer 2 addresses and identifiers are never carried across the SP backbone. Never, ever 💀

No restrictions are placed on the customer's addressing schemes or policies 🌸 Just note that the SP may place restrictions on how many routes come from a given customer site, or may charge differently depending on how many routes there are. Those restrictions may have implications for the customer's addressing scheme. Specifically, addressing schemes that make route aggregation easy on a per-site basis use the SP's resources most efficiently, and that may be reflected in the SP's charging policies 💖

8. Interoperability and Interworking 🦋

Interoperability should be ensured by properly implementing the published standards. That's the vibe ✨

Direct PE-PE interworking over the SP backbone with other VPN solutions is not supported 🙅‍♀️

Now here's the fun part. All the different types of L3VPNs are IP networks, so they can interwork the same way any two IP networks can 🌈 For example, one site can have a CE router from one VPN scheme and a CE router from another VPN scheme. Those CE routers could be IGP peers, or they could even be the same CE router 🧠 This leads to routes being redistributed from one type of VPN to the other, and that's what makes the interworking happen 🫶

9. Network Access 🌸

The architecture and protocols don't restrict the link layer or the physical layer in any way 🔓

9.2. Temporary Access

Temporary access over PPP is possible, using industry standard PPP-based authentication mechanisms 📞 Here's how it goes:

  • A dial-up user (or any other PPP user) gets authenticated by the PE, using the SP's AAA server, based on a login string or the number they dialed.
  • The SP's AAA server returns a VPN-id to the PE.
  • The PE assigns the user to a VRF based on that VPN-id.
  • The user then gets authenticated by an AAA server inside the VPN, meaning one managed by the customer and not the SP 🔐 This AAA server is usually reached through the VRF, so it may live in the VPN's private address space.
  • If either authentication step fails, the user gets disconnected 💀

IPsec access to a VRF is also possible. In this case, the security association is between the end user and the SP 🔒

So yeah, a user can reach a BGP/MPLS IP VPN through the public Internet this way 🌍

Mobility isn't explicitly supported, apart from what's already mentioned above 🙈

9.3. Access Connectivity

Homing a CE to two or more PEs is fully supported, whether or not those PEs are on the same SP network 🏠✨

If a CE is connected to two or more PEs, all of its PE/CE links can carry traffic in both directions. Traffic from different ingress PEs to a particular CE may arrive at that CE over different PE/CE links. It depends on the backbone network routing between the CE and the various ingress PEs 🛣️

If a VRF on a particular ingress PE has several routes to one destination, traffic from that ingress PE can be split among those routes. If those routes end with different PE/CE links, the traffic from that ingress PE gets split across those links too 🔀

BGP has a ton of knobs that let an SP control which PE/CE link carries which traffic 🎛️ You can also use the Link Bandwidth extended community [BGP-EXT-COMM] to control how traffic is spread across multiple egress PE/CE links 💜

The VPN scheme is totally compatible with traffic engineering techniques in the backbone, whether those are RSVP-TE based or something else 🚦

10. Service Access 🎀

10.1. Internet Access

Internet access and VPN access can both come from the same site 💻 It's even possible over the same interface, as long as the VPN's internal addresses are different from the addresses of the systems that must be reached over the Internet. All that's needed is importing both Internet routes and VPN routes into the VRF tied to that interface 🌐 It can be as simple as putting a default route to the Internet into that VRF ✨

The "route to the Internet" in a particular VRF doesn't have to lead straight to the Internet 👀 It may lead to a firewall or another security device at a different site of the VPN. The VPN customer can make that happen just by exporting a default route from the site with the firewall 🔥 Usually, a site with a firewall will use a different virtual interface for Internet access than for VPN access, because the firewall needs to tell the "clean interface" apart from the "dirty interface" 🧼🗑️

In that setup, the customer exports their routes to the Internet through the firewall's dirty interface, but exports those same routes to the VPN through the clean interface. So all traffic from the Internet comes in through the dirty interface, goes through the firewall, and might then head to another VPN site through the clean interface 🛡️ This also means any necessary Network Address Translation (NAT) can happen in the firewall 🙌

10.2. Other Services

Any externally provided service can be accessed from the VPN, as long as it can be reached with an address that isn't already in use inside the VPN 🌟 Access can be firewalled or non-firewalled 🔓 If the client accessing the service doesn't have a globally unique IP address, and one server serves multiple VPNs, NAT has to be applied to the client's packets before they reach the server 🧚 That can happen at a customer site, or through a VRF-specific NAT function in a PE router ✨

11. SP Routing 🛣️

Routing through the backbone is independent of the VPN scheme, and it doesn't care whether VPNs exist or not 💅 The only impact is that the backbone routing must carry routes to the PE routers 🫶

VPN routes are carried in BGP as a separate address family, different from the one used for "ordinary" IP routes 📦 They get passed from PE router to Route Reflector to PE router, and the P routers never see them 🙈 The Route Reflectors carrying VPN routes can be totally separate from the Route Reflectors carrying "ordinary" IP routes 💜

Two PE routers supporting a common VPN doesn't require them to form an IGP routing adjacency with each other 🤝 The number of adjacencies in the backbone IGP has nothing to do with how many VPNs a set of PE routers supports 🧠

No VPN-specific protection and restoration mechanisms are needed. These are general routing considerations, and the VPN scheme works with any protection and restoration mechanisms that may be available 🛡️

The SP doesn't manage the customer's IGP in any way, and routes are never leaked between the SP's IGP and any customer's IGP 🚫

If the PE/CE protocol is EBGP, the SP and the customer never participate in a common IGP. Ever 🌸

12. Migration Impact 🦋

Generally, this means replacing an existing legacy backbone with a VPN backbone 🔄 The usual migration move is to hook up the sites one at a time to the VPN backbone, then start giving routes learned via the VPN backbone preference over routes learned via the legacy backbone 🎯 The details depend on the legacy backbone's IGP. In general, you'd have to manipulate the IGP metrics to get the right route preference 🎀

If the legacy backbone routing protocol is OSPF, migration is best done either with OSPF as the PE/CE protocol and the PE supporting the [VPN-OSPF] procedures, OR with BGP as the PE/CE protocol and the CE supporting the BGP/OSPF interaction specified in [VPN-OSPF] 💖

With other legacy backbone routing protocols, the proper metrics must be set at the point (PE or CE) where the BGP routes from the SP network are being redistributed into the legacy IGP 🔥

13. Scalability ✨

okay so the big scalability tea 🫖 is that there is no upper limit on the number of VPNs per SP network 💅. No single box in the SP network needs to know about all the VPNs. Knowledge of a particular VPN lives only in the PE routers that attach to sites in that VPN, plus the BGP Route Reflectors that take in routing data from those PEs 🦋. Everything else keeps zero state for that VPN 🧚. Just note that no one Route Reflector needs to know about every VPN either 🙈.

If the SP is running the VPN service over an MPLS backbone, then the backbone IGP has to carry a host route for every Label Switched Path (LSP) egress node within the routing domain 🌸. Every PE router in the routing domain is an LSP egress node. If there are VPNs on PE routers inside the routing domain and also on PE routers in some second routing domain, then the border routers leading toward that second routing domain are LSP egress nodes too 👑. So the number of PE routers plus the number of border routers in a routing domain is capped by how many routes that domain's IGP can carry 📏. Honestly, this does not seem to create any practical scalability issue ✨.

There is also no upper limit on the number of site interfaces per VPN 🎀. The state for a particular interface is kept only at the PE router that interface attaches to. The number of site interfaces per VPN at a given PE router is limited only by how many interfaces that PE router can support 🔥.

The number of routes per VPN is constrained only by three things: how many routes BGP can support, how many routes the PEs attached to that VPN can maintain, and how many routes the BGP Route Reflectors holding that VPN's routes can maintain 🧠.

The major constraint when you think about scalability is the number of routes a given PE can support 🚨. In general, a given PE can support as many VPNs as it has interfaces (including virtual interfaces or "sub-interfaces", not just physical interfaces), but it is limited in the total number of routes it can handle 💜. The number of routes a given PE has to handle depends on which VPNs it attaches to, how many routes are in each of those VPNs, and how many "non-VPN" Internet routes (if any) it also has to carry 🌈.

The SP may need to do some serious planning so these limits are not often reached 📋. If they are reached, it may be necessary either to replace the PE with one of larger capacity, or to reorganize the way access links lead from CEs to PEs so the access links from sites in the same VPN are better concentrated 🍓. Rehoming a site to a different PE may not involve actual rewiring. If the access technology is switched, it is just a matter of provisioning, but it can still be a big undertaking 🛠️. If the rehoming needs downtime, the customer is impacted too 😭. Rehoming can also be done "virtually" by creating a layer 2 tunnel from a CE's "old" PE to its "new" PE 🦋.

An important thing to remember is that one may have any number of INDEPENDENT BGP systems carrying VPN routes 🫶. This is unlike the Internet, where the Internet BGP system has to carry all the Internet routes. The difference comes from the fact that all Internet addresses must be reachable from each other, but a given VPN address is only supposed to be reachable from other addresses in the same VPN 💖.

Scalability is also affected by how fast reachability advertisements change from CE to PE, since changes a CE reports to its attached PE may be propagated to the other PEs ⚡. The SP should use BGP mechanisms to control the rate of those reported changes 🎯.

Another limit on how many VPNs a particular PE router can support comes from how many routing instances that PE router can run 🧩. If the PE/CE routing is static, or is done by BGP, the number of routing protocol instances in a PE device does not depend on how many CEs the PE device supports. With BGP, a single BGP protocol instance can support all the CEs that exchange routing information using BGP 🌟. If the PE/CE routing is done via RIP or OSPF, then the PE must maintain one RIP or OSPF instance per VRF 🙃. Note that the number of routing instances that can be supported may be different for different routing protocols 🔍.

Inter-AS scenarios built according to option (b) of section 10 of [BGP-MPLS-IP-VPN] require BGP "border routers" to hold the routes for a set of VPNs 🌉. If two SPs share a small number of VPNs, a single border router between them provides adequate capacity 👌. As the number of shared VPNs grows, additional border routers may be needed to handle the extra routes 🏗️. Again, no single border router would handle all the routes from all the VPNs, so an increase in the number of VPNs can always be supported by adding more border routers 💪.

Inter-AS scenarios built according to option (c) of section 10 of [BGP-MPLS-IP-VPN] get rid of the need for border routers to contain VPN routes, which improves scalability in that dimension 🎉. The cost is that each AS needs a route to the PEs in the others 💸.

(Inter-AS scenarios built according to option (a) of section 10 of [BGP-MPLS-IP-VPN] do not scale well 💀.)

The solution in [BGP-MPLS-IP-VPN] is meant to simplify CE and site operations 🎀. It hides the structure of the rest of the VPN from a site, and it hides the structure of the backbone too. So CEs need only a single sub-interface to the backbone, CEs at one site don't even need to be aware of CEs at another, and CEs at one site don't need to be routing peers of CEs at another 🦋. CEs are never routing peers of P routers 🚫. All of this helps scale the customer's network by limiting the number of adjacencies each CE has to see, and by limiting the total number of links the customer's IGP has to handle 🌷.

That same solution is also meant to simplify the SP's VPN provisioning, so that the SP potentially only has to say which sites belong to which VPNs 🪄. But as the system scales up, planning is needed to decide which PEs should home which VPNs, and which BGP RRs should take which VPNs' routing information 🗺️.

P routers maintain NO per-VPN state at all 🙌. Their only requirement is to maintain routes to the PE routers. When MPLS is used, a P router must also maintain one multipoint-to-point LSP for each such route 🛤️.

Certain VPN multicast schemes, however, require per-multicast-group state in the P routers, summed over all VPNs 😵‍💫. Others require no state in the P routers at all, but they result in sending more unnecessary traffic 📡. The complete set of tradeoffs for multicast is not that well understood yet 🤷‍♀️.

Note that because the scaling of a particular PE is mostly a matter of the total number of routes it has to maintain, scalability is helped when addresses are assigned in a way that lets them be aggregated (i.e., when the customers have a sensible addressing plan) 🧁.

When a dynamic routing protocol runs on the link between a CE router and a PE router, routing instability in the private network may affect the PE router 🌪️. For example, an unusually large number of routing updates could be sent from the CE router to the PE router, putting an unusually heavy processing load on the PE router 🥵.

This can be mitigated through resource partitioning in the PE, which limits the amount of resources (e.g., CPU and memory) any one VPN is permitted to use in PE routers 🛡️. Rate limits may also be applied to the routing traffic sent from the CE to the PE 🚦.

Alternatively, when this problem is detected, the CE-to-PE interface may be shut down 🔌.

14. QoS, SLA 🎀

The provision of appropriate QoS capabilities may require any combination of the following:

  • QoS in the access network. 📶
  • Admission control (policing) by the PE router on the ingress access links. 🚪
  • Traffic conditioning (shaping) by the PE router on the ingress access links. 🧘
  • Traffic engineering in the backbone. 🛣️
  • Intserv/diffserv classification by the PE, for traffic arriving from the CE. Once the PE classifies the user packets, this classification needs to be preserved in the encapsulation (MPLS or IP) used to send the packet across the backbone. 🏷️
  • Differentiated Services Codepoint (DSCP) mapping. 🗂️
  • DSCP transparency. 🫧
  • Random Early Discard in the backbone. 🎲

None of these features are VPN-specific 🙅‍♀️. Whether they can be supported depends on whether the features are available on the edge and core platforms, not on any particular VPN scheme 💅.

MPLS support for differentiated services is detailed in RFC 3270 [MPLS-DIFFSERV] 📖. DSCP mapping and transparency are covered in section 2.6 of that document ✨.

It is possible to use traffic engineering to provide, e.g., guaranteed bandwidth between two PEs for the traffic of a given VPN 🛤️. The VRF entries for that VPN in each PE need to be modified so that traffic to the other PE is directed onto the traffic-engineered path. How this is done is a local matter 🤫.

BGP/MPLS IP VPNs can support both the "hose model" and the "pipe model" of QoS 🌊. In the "pipe model", a particular quality of service (e.g., a guaranteed amount of bandwidth) would be applied to all or some of the packets traveling between a given pair of CEs 🪈. In the "hose model", a particular quality of service (e.g., a guaranteed amount of bandwidth) would be applied to all traffic to or from a particular CE, no matter which other CE the traffic is going to or coming from 🏠. Since BGP/MPLS IP VPNs don't usually use CE-CE tunnels, the hose model is the more natural fit 💖. Providing the pipe model would require using traffic engineering to explicitly create the necessary tunnels 🧱.

Many of the requirements in [L3VPN-REQS] say the Network Monitoring System (NMS) should support SLA monitoring and verification between the SP and the various customers, by measuring the indicators defined within the context of the SLA 📊. Those measurements (i.e., counters) can be achieved when BGP/MPLS IP VPNs are used by combining the Management Information Base (MIB) module designed for BGP/MPLS IP VPNs [L3VPN-MIB] with other standard MIB modules such as the IF-MIB [IF-MIB] 🧩. Devices that support these MIB modules can calculate SLAs based on real-time performance measurements, using indicators and threshold crossing alerts 🚨. Devices can make these thresholds configurable, either via a management interface such as SNMP 🎛️.

15. Management 🗂️

The L3VPN Requirements document [L3VPN-REQS] says the term "Provider Provisioned VPN" refers to VPNs where the service provider takes part in the management and provisioning of the VPN 🫶. RFC BGP/MPLS IP VPNs can be provisioned and managed to meet these requirements 🙌. The following subsections will outline how devices supporting BGP/MPLS IP VPNs can satisfy these requirements 🔜.

15.1. Management by the Provider

okay so the SP manages all the VPN-specific info in the PE device 🏢✨ and it can do that with the MIB made for BGP/MPLS IP VPNs [L3VPN-MIB], plus other standard MIB modules like IF-MIB [IF-MIB] and the MPLS ones [LSRMIB], [LDPMIB], [TEMIB], [FTNMIB] 🧚

devices that support BGP/MPLS IP VPNs and use the management interface stuff we just talked about also support the ITU-T Telecommunications Management Network Model "FCAPS" functionalities, as the L3VPN Requirements document asks for. that's Fault, Configuration, Accounting, Provisioning, and Security 💜 very organized, very iconic

now, the SP is not required to manage the CE devices in BGP/MPLS IP VPNs 🙅‍♀️ BUT if the SP wants to, it may manage CE devices from a central site, as long as a route to that central site gets exported into the CE's VPN, and the central site sits in a VPN where the routes to the managed CEs have been imported 🌸

this is a form of extranet. the central site lives in one VPN and reaches into another, so it's basically a little extranet moment 🫶

if the central site is managing CE devices from several VPNs, those CE devices must have mutually unique addresses 🎀 and quick note: this does NOT let CE devices from different VPNs reach each other. nope, still separate 💅

the CE devices don't have any VPN-specific info inside them, so the fact that they're tied into a VPN doesn't require them to have any VPN-specific management MIB modules or capabilities 🦋 they're just chillin, no extra baggage

15.2. Management by the Customer

CE devices can be managed from inside the VPN, and the SP doesn't even notice 👀 they have no VPN-specific info in them, so being in a VPN doesn't change how the customer manages them at all 🍓

customer access to a PE device is totally up to the SP 💁‍♀️ it's not required by the solution. the PE is a routing peer of the CE, so yes, it can be pinged, etc. 🏓

if a customer gets to access the PE router for management, the functions they can use need to be strictly controlled 🔐 and resource partitioning may be a good fit for that 🧩

network management traffic from the CE to the PE may be rate limited 🚦 (for example, so that management traffic from CE to PE can't be used in a DoS attack 💀 protect the vibes, protect the router)

16. Acknowledgements

omg huge thank-you to Jeremy De Clercq, Luyuan Fang, Dave McDysan, Ananth Nagarajan, Yakov Rekhter, and Muneyoshi Suzuki 🫶💖 for their comments, criticisms, and help preparing this doc. also thanks to Thomas Nadeau for helping with the management section 🧚, to Francois LeFaucheur for the QoS section 🌈, and to Ross Callon for reviewing the whole thing 👑

17. Normative References

[BGP-EXT-COMM]       Sangli, S., Tappan, D., and Y. Rekhter, "BGP
                     Extended Communities Attribute", RFC 4360,
                     February 2006.

[BGP-MPLS-IP-VPN]    Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual
                     Private Networks (VPNs)", RFC 4364, February
                     2006.

[L3VPN-FRMWRK]       Callon, R. and M. Suzuki, "A Framework for Layer
                     3 Provider-Provisioned Virtual Private Networks
                     (PPVPNs)", RFC 4110, July 2005.

[L3VPN-REQS]         Carugi, M. and D. McDysan, "Service Requirements
                     for Layer 3 Provider Provisioned Virtual Private
                     Networks (PPVPNs)", RFC 4031, April 2005.

[L2VPN-SEC-FRMWRK]   Fang, L., "Security Framework for Provider-
                     Provisioned Virtual Private Networks (PPVPNs)",
                     RFC 4111, July 2005.

18. Informative References

[VPN-OSPF]           Rosen, E., Psenak, P., and P. Pillay-Esnault,
                     "OSPF as the PE/CE Protocol in BGP/MPLS VPNs",
                     Work in Progress, February 2004.

[OSPF-2547-DNBIT]    Rosen, E., Psenak, P., and P. Pillay-Esnault,
                     "Using an LSA Options Bit to Prevent Looping in
                     BGP/MPLS IP VPNs", Work in Progress, March 2004.

[MPLS/BGP-IPsec]     Rosen, E., De Clercq, J., Paridaens, O.,
                     T'Joens, Y., and C. Sargor, "Architecture for
                     the Use of PE-PE IPsec Tunnels in BGP/MPLS IP
                     VPNs", Work in Progress, March 2004.

[BGP-MPLS-MCAST-VPN] Rosen, E., Cai, Y., and IJ. Wijsnands,
                     "Multicast in MPLS/BGP VPNs", Work in Progress,
                     May 2004.

[CE-VERIF]           Bonica, R., Rekhter, Y., Raszuk, R., Rosen, E.,
                     and D. Tappan, "CE-to-CE Member Verification for
                     Layer 3 VPNs", Work in Progress, September 2003.

[FTNMIB]             Nadeau, T., Srinivasan, C., and A. Viswanathan,
                     "Multiprotocol Label Switching (MPLS) Forwarding
                     Equivalence Class To Next Hop Label Forwarding
                     Entry (FEC-To-NHLFE) Management Information Base
                     (MIB)", RFC 3814, June 2004.

[IPSEC-VPN]          De Clercq, J., Paridaens, O., Krywaniuk, A., and
                     C. Wang, "An Architecture for Provider
                     Provisioned CE-based Virtual Private Networks
                     using IPsec", Work in Progress, February 2004.

[LDPMIB]             Cucchiara, J., Sjostrand, H., and J. Luciani,
                     "Definitions of Managed Objects for the
                     Multiprotocol Label Switching (MPLS), Label
                     Distribution Protocol (LDP)", RFC 3815, June
                     2004.

[LSRMIB]             Srinivasan, C., Viswanathan, A., and T. Nadeau,
                     "Multiprotocol Label Switching (MPLS) Label
                     Switching Router (LSR) Management Information
                     Base (MIB)", RFC 3813, June 2004.

[MPLS-DIFFSERV]      Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
                     Vaananen, P., Krishnan, R., Cheval, P., and J.
                     Heinanen, "Multi-Protocol Label Switching (MPLS)
                     Support of Differentiated Services", RFC 3270,
                     May 2002.

[L3VPN-MIB]          Nadeau, T. and H. Van Der Linde, "MPLS/BGP
                     Virtual Private Network Management Information
                     Base Using SMIv2", Work in Progress, August
                     2004.

[IF-MIB]             McCloghrie, K. and F. Kastenholz, "The
                     Interfaces Group MIB", RFC 2863, June 2000.

[RFC1918]            Rekhter, Y., Moskowitz, B., Karrenberg, D., de
                     Groot, G., and E. Lear, "Address Allocation for
                     Private Internets", BCP 5, RFC 1918, February
                     1996.

[TEMIB]              Srinivasan, C., Viswanathan, A., and T. Nadeau,
                     "Multiprotocol Label Switching (MPLS) Traffic
                     Engineering (TE) Management Information Base
                     (MIB)", RFC 3812, June 2004.

[VR-VPN]             Knight, P., Ould-Brahim, H., and B. Gleeson,
                     "Network Based IP VPN Architecture using Virtual
                     Routers", Work in Progress, April 2004.

Author's Address

Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719

EMail: erosen@cisco.com
Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights.  Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
`http://www.ietf.org/ipr`.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard.  Please address the information to the IETF at
`ietf-ipr@ietf.org`.

Acknowledgement

funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 💖🎀

📦 where this page comes from