RFC 4364

BGP/MPLS IP Virtual Private Networks (VPNs)

📅 published February 2006, from ietf

BGP/MPLS IP Virtual Private Networks (VPNs) 🎀

okay bestie, this is RFC 4364, and it's giving main character energy 👑 It's a Standards Track spec from the Network Working Group, written by E. Rosen of Cisco Systems, Inc. and Y. Rekhter of Juniper Networks, Inc., dated February 2006. It obsoletes RFC 2547, which means it replaces that older doc, and its title block doesn't list anything it updates. 💖

Status of This Memo ✨

so this doc is an Internet standards track protocol for the Internet community, and it's basically asking everyone to discuss it and suggest improvements 🫶 if you want to know where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). and distribution of this memo is unlimited, so share away 🦋

Copyright Notice 🌸

Abstract 🔮

this doc explains how a Service Provider can use an IP backbone to give its customers IP Virtual Private Networks (VPNs) 🧚 the trick is the "peer model": the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers). there's no "overlay" the customer's routing algorithm can see, and CE routers at different sites never peer with each other 💅 the data packets get tunneled through the backbone, so the core routers don't have to know anything about the VPN routes. it's so clean 😭

this doc obsoletes RFC 2547.

Table of Contents 🗂️

1. Introduction ....................................................3
   1.1. Virtual Private Networks ...................................4
   1.2. Customer Edge and Provider Edge ............................5
   1.3. VPNs with Overlapping Address Spaces .......................6
   1.4. VPNs with Different Routes to the Same System ..............7
   1.5. SP Backbone Routers ........................................7
   1.6. Security ...................................................8
2. Sites and CEs ...................................................8
3. VRFs: Multiple Forwarding Tables in PEs .........................9
   3.1. VRFs and Attachment Circuits ...............................9
   3.2. Associating IP Packets with VRFs ..........................10
   3.3. Populating the VRFs .......................................11
4. VPN Route Distribution via BGP .................................12
   4.1. The VPN-IPv4 Address Family ...............................13
   4.2. Encoding of Route Distinguishers ..........................14
   4.3. Controlling Route Distribution ............................15
        4.3.1. The Route Target Attribute .........................15
        4.3.2. Route Distribution Among PEs by BGP ................17
        4.3.3. Use of Route Reflectors ............................20
        4.3.4. How VPN-IPv4 NLRI Is Carried in BGP ................22
        4.3.5. Building VPNs Using Route Targets ..................23
        4.3.6. Route Distribution Among VRFs in a Single PE .......23
5. Forwarding .....................................................23
6. Maintaining Proper Isolation of VPNs ...........................26
7. How PEs Learn Routes from CEs ..................................27
8. How CEs Learn Routes from PEs ..................................30
9. Carriers' Carriers .............................................30
10. Multi-AS Backbones ............................................32
11. Accessing the Internet from a VPN .............................34
12. Management VPNs ...............................................36
13. Security Considerations .......................................37
   13.1. Data Plane ...............................................37
   13.2. Control Plane ............................................39
   13.3. Security of P and PE Devices .............................39
14. Quality of Service ............................................39
15. Scalability ...................................................40
16. IANA Considerations ...........................................40
17. Acknowledgements ..............................................41
18. Contributors ..................................................41
19. Normative References ..........................................44
20. Informative References ........................................45

1. Introduction ✨

okay so this section is the setup 🎀 it's the same vibe as the abstract, but with more detail. the doc describes how a Service Provider can use an IP backbone to run IP VPNs for its customers 💖 same peer model again: the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers). then Border Gateway Protocol (BGP) [BGP, BGP-MP] is what the Service Provider uses to pass around a particular VPN's routes among the PE routers attached to that VPN 🦋 the big deal is that routes from different VPNs stay distinct and separate, even when two VPNs use overlapping address space. 🙈

the PE routers hand the routes from the other CE routers in a VPN over to each CE router in that same VPN 🫶 the CE routers never peer with each other, so the VPN's routing algorithm still doesn't see any "overlay." and the word "IP" in "IP VPN" just means the PE gets IP datagrams from the CE, looks at their IP headers, and routes them from there 💅

each route inside a VPN gets its own Multiprotocol Label Switching (MPLS) [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS] label 🧚 whenever BGP distributes a VPN route, it also distributes the MPLS label for that route, so they travel as a pair ✨ before a customer's data packet crosses the Service Provider's backbone, it gets encapsulated with the MPLS label that matches, inside the customer's VPN, the route that's the best match for the packet's destination address. then that MPLS packet gets wrapped again (for example, with another MPLS label, or with an IP or Generic Routing Encapsulation (GRE) tunnel header [MPLS-in-IP-GRE]) so it can be tunneled across the backbone to the right PE router 🚀 the result? the backbone core routers never have to learn the VPN routes. iconic 😭🔥

the main goal of all this is to support a client who gets IP backbone services from a Service Provider (or from several Service Providers) they have contracts with 💼 that client could be an enterprise, a group of enterprises that want an extranet, an Internet Service Provider, an application service provider, or another VPN Service Provider that uses this same method to offer VPNs to its clients, etc. 🌈 the method is super simple for the client to use, it's very scalable and flexible for the Service Provider, and it lets the Service Provider add value 💜

1.1. Virtual Private Networks 🌸

let's start with a set of "sites" hooked up to a shared network we call "the backbone" 🍓 now apply some policy to carve that set into a bunch of subsets, and enforce this rule: two sites can have IP interconnectivity over that backbone only if at least one of those subsets contains both of them 💅

those subsets are Virtual Private Networks (VPNs) ✨ so two sites have IP connectivity over the common backbone only if some VPN contains both of them. two sites with no VPN in common have no connectivity over that backbone at all, bestie 🙈

if every site in a VPN belongs to the same enterprise, the VPN can be thought of as a corporate "intranet" 🏢 if the sites belong to different enterprises, it can be thought of as an "extranet" 🤝 a site can live in more than one VPN, like being in one intranet and several extranets at once 🦋 in general, when this doc says "VPN," it's not distinguishing between intranets and extranets, so don't overthink it 💖

we call the owners of the sites "customers" 🫶 and we call the owners/operators of the backbone "Service Providers" (SPs) 💼 customers get "VPN service" from the SPs. a customer can be a single enterprise, a set of enterprises, an Internet Service Provider, an Application Service Provider, another SP that offers the same kind of VPN service to its own customers, etc. 🌈

whether a particular collection of sites counts as a VPN is decided by the customers' policies 🎀 some customers want the SP to handle implementing those policies all by itself. other customers want to share that responsibility with the SP 🤝 this doc specifies mechanisms that can be used to implement these policies, and they're general enough that the SP can do it alone or the VPN customer can do it together with the SP 💅 most of the discussion focuses on the SP-alone case, though 👑

the mechanisms here can build a wide range of policies ✨ for example, inside a given VPN, you can let every site have a direct route to every other site (a "full mesh") 🕸️ or you can force traffic between certain pairs of sites to go through a third site 🔥 that's useful if you want traffic between a pair of sites to pass through a firewall, and the firewall lives at the third site 🛡️

in this doc, we're only talking about the case where the customer is explicitly buying VPN service from an SP (or from a set of SPs that agreed to work together to provide the VPN service) 💼 so the customer isn't just buying internet access from an SP, and the VPN traffic doesn't wander through some random collection of interconnected SP networks 🙅‍♀️

we also limit the discussion to the case where the backbone gives the customer an IP service, not a layer 2 service like Frame Relay, Asynchronous Transfer Mode (ATM), ethernet, High Level Data Link Control (HDLC), or Point-to-Point Protocol (PPP) 🧃 the customer can attach to the backbone through one of those (or other) layer 2 services, but that layer 2 service gets terminated at the "edge" of the backbone, where the customer's IP datagrams are pulled out of any layer 2 encapsulation 🧚

in the rest of this introduction, we go over some properties that VPNs should have 🎀 the rest of the doc then specifies a set of mechanisms you can deploy to build a VPN model with all of those properties ✨ this section also introduces some of the technical terminology used through the rest of the doc, so you're set up for the good stuff 🦋💖

1.2. Customer Edge and Provider Edge 🎀

okay so routers can hook up to each other, or to end systems, in like a bunch of different ways 💅 think PPP connections, ATM Virtual Circuits (VCs), Frame Relay VCs, ethernet interfaces, Virtual Local Area Networks (VLANs) on ethernet interfaces, GRE tunnels, Layer 2 Tunneling Protocol (L2TP) tunnels, IPsec tunnels, etc. 🦋 we're gonna call all of those an "attachment circuit," which is just the umbrella term for any way of plugging into a router. an attachment circuit might be the kind of thing people normally call a "data link," or it might be some sort of tunnel, and honestly that doesn't matter. what matters is that two devices can be network layer peers over it ✨

every VPN site has to have one or more Customer Edge (CE) devices 🌸 each CE device connects through some kind of attachment circuit to one or more Provider Edge (PE) routers. bestie, the routers inside the SP's network that DON'T attach to CE devices are called "P routers" 🍓

CE devices can be hosts or routers 🧚 usually a site has a bunch of routers, and some of them hook up to PE routers. those site routers that connect to the PE routers are the CE devices, aka "CE routers." but nothing stops a non-routing host from plugging directly into a PE router. in that case, the host is the CE device 💖

sometimes the thing physically plugged into a PE router is a layer 2 switch 🫶 and here's the tea: we do NOT call that switch a CE device. the CE devices are the hosts and routers that talk to the PE router through the switch. the layer 2 infrastructure is basically invisible. and if that layer 2 infrastructure is a multipoint service, then multiple CE devices can share the same attachment circuit to the PE router 🌈

CE devices are logically part of a customer's VPN ✨ PE and P routers are logically part of the SP's network 👑

the attachment circuit a packet uses on its way from CE to PE is called that packet's "ingress attachment circuit," and the PE is its "ingress PE." the attachment circuit it uses going from PE to CE is the "egress attachment circuit," and that PE is its "egress PE" 🦋

a PE router counts as attached to a particular VPN if it's attached to a CE device that sits in a site of that VPN. same idea for sites: a PE router is attached to a particular site if it's attached to a CE device in that site 💜

when the CE device is a router, it's a routing peer of the PE(s) it connects to, BUT it is NOT a routing peer of CE routers at other sites 😭 routers at different sites don't swap routing info with each other, and they don't even need to know each other exists. so the customer doesn't have a backbone or "virtual backbone" to manage, and they don't have to deal with any inter-site routing stuff at all. basically, in the scheme this document describes, a VPN is NOT an "overlay" on top of the SP's network 💅✨

when it comes to managing the edge devices, there are clear administrative boundaries between the SP and its customers 🫶 customers aren't required to access the PE or P routers for management, and the SP isn't required to access the CE devices for management either. boundaries, bestie 🎀

1.3. VPNs with Overlapping Address Spaces 🌸

if two VPNs have no sites in common, they're allowed to have overlapping address spaces 🦋 like, the same address might be used in VPN V1 for system S1, while in VPN V2 that exact address belongs to a totally different system S2. this happens all the time when the VPNs each use an RFC 1918 private address space 🙈 but obviously, inside each VPN, every address has to be unambiguous ✨

even two VPNs that DO share sites can have overlapping address spaces, as long as there's no need for systems with those addresses to talk to systems in the common sites 💖

1.4. VPNs with Different Routes to the Same System 🧚

a site can be in multiple VPNs, but the route to a given system at that site doesn't have to be the same in every one of them 👑 let's say we have an intranet made of sites A, B, and C, and an extranet made of A, B, C, and the "foreign" site D. at site A there's a server, and we want clients from B, C, or D to be able to use it 🍓 also, site B has a firewall. we want ALL the traffic from site D to the server to go through that firewall, so extranet traffic can be access controlled 🔥 but we DON'T want traffic from C to hit the firewall on its way to the server, because that's intranet traffic, and it doesn't need the firewall 💅

so we set up two routes to the server 🫶 one route, used by sites B and C, goes straight to site A. the second route, used by site D, goes to the firewall at site B instead. if the firewall lets the traffic through, it then looks like it's coming from site B, and it follows the route to site A from there 🌈

1.5. SP Backbone Routers 💜

the SP's backbone is made up of the PE routers, plus the other routers ("P routers") that don't attach to CE devices ✨

okay, real talk: if every router in an SP's backbone had to keep routing info for every VPN the SP supports, we'd have severe scalability problems 😭 the number of sites you could support would be capped by how much routing info a single router can hold. so it's super important that routing info about a particular VPN only has to live in the PE routers that attach to that VPN. the P routers, in particular, don't need ANY per-VPN routing information whatsoever 🙌 (this might need to be loosened a bit when multicast routing comes into play. it's not covered further in this paper, but it's looked at in [VPN-MCAST].)

so just like VPN owners don't have a backbone or "virtual backbone" to administer, the SPs don't have a separate backbone or "virtual backbone" to administer for each VPN either 🦋 site-to-site routing in the backbone is optimal (within the policy constraints used to form the VPNs), and it isn't limited in any way by some artificial "virtual topology" of tunnels 💖

Section 10 covers some of the special issues that come up when the backbone spans several Service Providers 🎀

1.6. Security 🔐

VPNs like the ones we're talking about, even without cryptographic security measures, are meant to give you a level of security equivalent to what you'd get with a layer 2 backbone (e.g., Frame Relay) ✨ so, as long as there's no misconfiguration or deliberate interconnection of different VPNs, systems in one VPN can't get access to systems in another VPN 🙅‍♀️

BUT, bestie, the methods here don't encrypt your data for privacy, and they don't give you a way to tell whether data got tampered with en route 😭 if you want that, cryptographic measures have to be applied on top (See, e.g., [MPLS/BGP-IPsec].) security gets a deeper dive in Section 13 🔥

2. Sites and CEs 🌷

from the point of view of a particular backbone network, a set of IP systems can be considered a "site" if those systems have mutual IP interconnectivity that doesn't need the backbone 🧚 usually a site is a bunch of systems that are geographically close together. but that's not always true 🙈 for example, if two geographic locations are connected by a leased line running Open Shortest Path First (OSPF) protocol [OSPFv2], and that line is the preferred way for the two locations to talk, then they can count as a single site, even if each location has its own CE router. (this idea of "site" is topological, not geographical 💅 if the leased line goes down, or otherwise stops being the preferred route, but the two locations can still talk by using the VPN backbone, then one site has become two.)

a CE device is always considered to be in a single site (though, as we'll see in Section 3.2, a site might consist of multiple "virtual sites") 🦋 a site, however, can belong to multiple VPNs 💜

a PE router can attach to CE devices from any number of different sites, whether those CE devices are in the same VPN or in different VPNs ✨ a CE device can, for robustness, attach to multiple PE routers, from the same or from different service providers 🫶 if the CE device is a router, the PE router and the CE router will show up as router adjacencies to each other 👑

we mostly talk about "sites" as the basic unit of interconnection, but nothing here stops you from getting more fine-grained control over connectivity 🌈 for example, certain systems at a site might be members of an intranet AND one or more extranets, while other systems at that same site are only allowed to be in the intranet 💅 but this might mean the site needs two attachment circuits to the backbone, one for the intranet and one for the extranet ⭐ and it might further require that firewall functionality gets applied on the extranet attachment circuit 🔥

3. VRFs: Multiple Forwarding Tables in PEs 💖

each PE router keeps a number of separate forwarding tables 🎀 one of those is the "default forwarding table." the others are "VPN Routing and Forwarding tables," or "VRFs" ✨

3.1. VRFs and Attachment Circuits ✨

Okay bestie, every PE/CE attachment circuit gets linked to one or more VRFs through configuration 🎀. An attachment circuit linked to a VRF is called a "VRF attachment circuit" 💅.

In the simplest and most typical case, a PE/CE attachment circuit is linked to exactly one VRF 💖. When an IP packet arrives over a particular attachment circuit, its destination IP address gets looked up in that VRF 🔍. The result of that lookup decides how the packet gets routed 🦋. The VRF that a packet's ingress PE uses to route that packet is the packet's "ingress VRF" 🧚. (There's also an "egress VRF" at the packet's egress PE, and we get into that in Section 5 ✨.)

If an IP packet arrives over an attachment circuit that isn't tied to any VRF, its destination address gets looked up in the default forwarding table, and the packet gets routed from there 🌸. The default forwarding table handles packets from neighboring P or PE routers, plus packets from customer-facing attachment circuits that haven't been tied to VRFs 🫶.

Think of the default forwarding table as holding "public routes" 🌈, and the VRFs as holding "private routes" 🔒. Along the same lines, VRF attachment circuits are "private" and non-VRF attachment circuits are "public" 💜.

If a particular VRF attachment circuit connects site S to a PE router, then S's connectivity (through that attachment circuit) can be restricted by controlling which routes get entered into the matching VRF 🚧. The routes in that VRF should be limited to the routes leading to sites that share at least one VPN with S 💕. That way, a packet sent from S over a VRF attachment circuit can only be routed by the PE to another site S' if S' is in one of the same VPNs as S 🙌. In other words, communication through PE routers is blocked between any pair of VPN sites that don't have a VPN in common 🚫. Communication between VPN sites and non-VPN sites is blocked too, by keeping the routes to the VPN sites out of the default forwarding table 🛑.

If there are multiple attachment circuits leading from S to one or more PE routers, then several VRFs might be used to route traffic from S 🧩. To properly restrict S's connectivity, the same set of routes would have to exist in all of those VRFs 🔐. Or, you could impose different connectivity restrictions on different attachment circuits from S 🎭. In that case, some of the VRFs tied to S's attachment circuits would hold different sets of routes than others 🌀.

We allow a single attachment circuit to be linked to a set of VRFs, not just one 🍓. This comes in handy when you want to split a single VPN into several "sub-VPNs", each with its own connectivity restrictions, and some characteristic of the customer's packets picks which sub-VPN is used 🎯. For simplicity, though, we'll usually talk about an attachment circuit as being linked to a single VRF 🫧.

3.2. Associating IP Packets with VRFs 🎀

When a PE router receives a packet from a CE device, it must figure out which attachment circuit the packet arrived over, because that decides which VRF (or set of VRFs) can be used to forward it 🕵️‍♀️. Generally, a PE router works out the attachment circuit by noting the physical interface the packet came in on, and maybe also looking at something in the packet's layer 2 header 💡. For example, if a packet's ingress attachment circuit is a Frame Relay VC, the attachment circuit can be identified from the physical Frame Relay interface the packet arrived on, together with the Data Link Connection Identifier (DLCI) field in the packet's Frame Relay header 🧡.

Even though the PE's conclusion about which attachment circuit a packet arrived on can be partly based on the layer 2 header, it must be impossible for a customer to fool the SP by writing header fields, so the SP thinks a packet received over one attachment circuit actually arrived over a different one 🛡️. In the Frame Relay example above, the attachment circuit is partly determined by checking the DLCI field, but the customer can't set that field freely 🙅‍♀️.

Instead, it must be set to a value the SP specifies, or else the packet can't arrive at the PE router 🔒✨.

Sometimes a customer divides a particular site into several "virtual sites" 🌷. The SP can designate a specific set of VRFs for routing packets from that site, and it may let the customer set some characteristic of the packet, which is then used to pick a particular VRF from that set 🦄.

For example, each virtual site might be realized as a VLAN 🌈. The SP and the customer could agree that on packets arriving from a particular CE, certain VLAN values identify certain VRFs 🍭. Of course, the PE would discard packets from that CE if they carry VLAN tag values outside the agreed-upon set 🗑️. Another option is to use IP source addresses 🪪. Here, the PE looks at the IP source address in a packet from the CE, along with the interface the packet came in on, to assign the packet to a particular VRF 📍. Again, the customer can only pick from the particular set of VRFs that they're allowed to use 🙌.

If you want a particular host to be in multiple virtual sites, that host must decide, for each packet, which virtual site the packet belongs to 🧠. It can do this, for example, by sending packets from different virtual sites on different VLANs, or out different network interfaces 🛤️.

3.3. Populating the VRFs 🌸

So the big question: what set of routes are the VRFs populated with? 🤔

Let's look at an example where PE1, PE2, and PE3 are three PE routers, and CE1, CE2, and CE3 are three CE routers 🧚‍♀️. Say PE1 learns, from CE1, the routes reachable at CE1's site 🗺️. If PE2 and PE3 are attached to CE2 and CE3 respectively, and there's some VPN V containing CE1, CE2, and CE3, then PE1 uses BGP to distribute the routes it learned from CE1 to PE2 and PE3 📡. PE2 and PE3 use those routes to populate the VRFs they associate with the sites of CE2 and CE3, respectively 💜. Routes from sites that aren't in VPN V never show up in those VRFs, which means packets from CE2 or CE3 can't be sent to sites outside VPN V 🚷.

When we say a PE "learns" routes from a CE, we aren't assuming any particular learning technique 🎀. The PE might learn routes through a dynamic routing algorithm, but it can also "learn" routes that have been configured (that's static routing) 🛠️. (In that case, saying the PE "learned" the routes from the CE is maybe a bit of poetic license 🎭.) PEs also need to learn, from other PEs, the routes that belong to a given VPN 🔁. The procedures for populating the VRFs with the proper sets of routes are specified in Section 4 📖.

If there are multiple attachment circuits leading from a particular PE router to a particular site, they might all map to the same forwarding table 🗂️. But if policy says so, they can map to different forwarding tables 🎯. For instance, the policy might be that one attachment circuit from a site is used only for intranet traffic, while another attachment circuit from that same site is used only for extranet traffic 🏠🌐. (Maybe the CE on the extranet attachment circuit is a firewall, while the CE on the intranet attachment circuit isn't 🔥.) In this case, the two attachment circuits would be associated with different VRFs 💅.

Note that if two attachment circuits are associated with the same VRF, then packets the PE receives over either one can reach exactly the same set of destinations 👯‍♀️. So two attachment circuits can't be associated with the same VRF unless each CE is in the exact same set of VPNs as the other 🙅‍♀️💖.

If an attachment circuit leads to a site that's in multiple VPNs, the attachment circuit can still be associated with a single VRF 🦋. In that case, the VRF will contain routes from the full set of VPNs the site is a member of 🌈.

4. VPN Route Distribution via BGP 🎀

PE routers use BGP to distribute VPN routes to each other (more accurately, they cause VPN routes to be distributed to each other) 📡💌.

We let each VPN have its own address space 🏡. That means a given address can refer to different systems in different VPNs 🤯. If two routes to the same IP address prefix actually lead to different systems, it's important that BGP not treat them as comparable 🙅‍♀️. Otherwise, BGP might choose to install only one of them, leaving the other system unreachable 😭. We also have to make sure that POLICY decides which packets get sent on which routes ⚖️. Since BGP can install several such routes, only one of them should appear in any particular VRF 👑.

We meet these goals by using a new address family, as specified below 💅✨.

4.1. The VPN-IPv4 Address Family ✨

okay so BGP can already carry routes from multiple "address families" thanks to the BGP Multiprotocol Extensions [BGP-MP] 🫶 we're introducing the VPN-IPv4 address family 💜 a VPN-IPv4 address is a 12-byte quantity: it starts with an 8-byte Route Distinguisher (RD) and ends with a 4-byte IPv4 address 🦋 if several VPNs use the same IPv4 address prefix, the PEs translate those into unique VPN-IPv4 address prefixes, so the same address can show up in different VPNs and BGP can carry a completely different route to it for each VPN 🌈

VPN-IPv4 addresses and IPv4 addresses are different address families, so BGP never treats them as comparable addresses 🙈

an RD is just a number 🔢 it does NOT carry any inherent information, so it doesn't tell you where the route came from or which set of VPNs it should go to 💅 the RD's only job is to let you make distinct routes to a common IPv4 address prefix. Where the route gets redistributed is handled by other means (see Section 4.3) ✨

the RD can also create multiple different routes to the very same system 🎀 remember the server example where the route should look different for intranet traffic than for extranet traffic? you get that by making two VPN-IPv4 routes with the same IPv4 part but different RDs 🔥 BGP can then install multiple different routes to the same system, and policy (see Section 4.3.5) decides which packets use which route 👑

the RDs are structured so every Service Provider can run its own "numbering space" (aka make its own RD assignments) without clashing with any other SP's assignments 🌸 an RD has three fields: a 2-byte type field, an administrator field, and an assigned number field 💖 the type field decides how long the other two fields are and what the administrator field means 🧚 the administrator field identifies an assigned number authority, and the assigned number field holds a number that authority assigned for a particular purpose 🍓 for example, you could have an RD whose administrator field holds an Autonomous System number (ASN), and whose (4-byte) number field holds a number the SP that owns that ASN assigned itself (after the ASN was given to that SP by the proper authority) 🫶

why the structure? so an SP that provides VPN backbone service can always make a unique RD whenever it needs one 🥹 BUT the structure isn't meaningful to BGP. when BGP compares two such address prefixes, it ignores the structure completely 💀

a PE needs to be configured so that routes leading to a particular CE get associated with a particular RD 🎀 the config can make all routes to the same CE share one RD, or it can give different routes to that same CE different RDs 🦋

4.2. Encoding of Route Distinguishers 💜

as we said, a VPN-IPv4 address is an 8-byte Route Distinguisher followed by a 4-byte IPv4 address 🌈 the RDs are encoded like this:

Type Field: 2 bytes
Value Field: 6 bytes

the Value field's meaning depends on the type field 💅 right now, three type field values are defined: 0, 1, and 2 ✨

Type 0: the Value field has two subfields:
- Administrator subfield: 2 bytes
- Assigned Number subfield: 4 bytes

the Administrator subfield must contain an Autonomous System number 🍓 if that ASN is from the public ASN space, it must have been assigned by the appropriate authority (using private ASN values is strongly discouraged 🙈). The Assigned Number subfield contains a number from a numbering space administered by the enterprise the ASN was assigned to by an appropriate authority 🫶

Type 1: the Value field has two subfields:
- Administrator subfield: 4 bytes
- Assigned Number subfield: 2 bytes

the Administrator subfield must contain an IP address 🌸 if that IP address is from the public IP address space, it must have been assigned by an appropriate authority (using addresses from the private IP address space is strongly discouraged 😭). The Assigned Number subfield contains a number from a numbering space administered by the enterprise the IP address was assigned to 🧚

Type 2: the Value field has two subfields:
- Administrator subfield: 4 bytes
- Assigned Number subfield: 2 bytes

the Administrator subfield must contain a 4-byte Autonomous System number [BGP-AS4] 👑 if this ASN is from the public ASN space, it must have been assigned by the appropriate authority (using private ASN values is strongly discouraged). The Assigned Number subfield contains a number from a numbering space administered by the enterprise the ASN was assigned to by an appropriate authority 💖

4.3. Controlling Route Distribution 🎀

okay this is the part where we talk about how VPN-IPv4 route distribution gets controlled 🦋

if a PE router is attached to a particular VPN (by being attached to a particular CE in that VPN), it learns some of that VPN's IP routes from the attached CE router 🌈 routes learned from a CE routing peer over a particular attachment circuit may be installed in the VRF tied to that attachment circuit 💅 exactly which routes get installed this way depends on how the PE learns routes from the CE ✨ especially when the PE and CE are routing protocol peers, it's decided by the routing protocol's decision process (more on that in Section 7) 🔥

then those routes get converted to VPN-IP4 routes and "exported" to BGP 💜 if there's more than one route to a particular VPN-IP4 address prefix, BGP picks the "best" one using the BGP decision process 🫶 that route is then distributed by BGP to the set of other PEs that need to know about it 🍓 at those other PEs, BGP picks the best route for a particular VPN-IP4 address prefix all over again 🧚 then the chosen VPN-IP4 routes are converted back into IP routes and "imported" into one or more VRFs 🌸 whether they actually get installed in the VRFs depends on the decision process of the routing method used between the PE and the CEs associated with that VRF 👑 finally, any route installed in a VRF may be distributed to the associated CE routers 🎀

4.3.1. The Route Target Attribute 🦋

every VRF is associated with one or more Route Target (RT) attributes 💖

when a PE router creates a VPN-IPv4 route (from an IPv4 route it learned from a CE), that route is associated with one or more Route Target attributes 🌈 these get carried in BGP as attributes of the route ✨

any route associated with Route Target T must be distributed to every PE router that has a VRF associated with Route Target T 🔥 when a PE receives such a route, it's eligible to be installed in those of the PE's VRFs that are associated with Route Target T 💅 (whether it actually gets installed depends on the outcome of the BGP decision process, and on the outcome of the decision process of the IGP, i.e., the intra-domain routing protocol, running on the PE/CE interface 🙈)

a Route Target attribute can be thought of as identifying a set of sites 🫶 (though it's more precise to think of it as identifying a set of VRFs 🧚). Attaching a particular Route Target attribute to a route lets that route get placed in the VRFs used for routing traffic received from the matching sites 🌸

a PE router attaches a set of Route Targets to a route received from site S; these may be called the "Export Targets" 👑 and a PE router uses a set of Route Targets to decide whether a route received from another PE could be placed in the VRF associated with site S; these may be called the "Import Targets" 💜 the two sets are distinct and don't need to be the same 🍓 a particular VPN-IPv4 route is only eligible for installation in a particular VRF if there's some Route Target that is both one of the route's Route Targets AND one of the VRF's Import Targets 🎀

the Route Target attribute does a similar job to the BGP Communities attribute 🦋 but the format of Communities is inadequate for this purpose, since it only allows a 2-byte numbering space 😭 it's desirable to structure the format the way we described for RDs (see Section 4.2), so a type field defines the length of an administrator field and the rest of the attribute is a number from that administrator's numbering space 🌈 this can be done using BGP Extended Communities ✨ the Route Targets discussed here are encoded as BGP Extended Community Route Targets [BGP-EXTCOMM], and they're structured similarly to the RDs 💖

when a BGP speaker has received more than one route to the same VPN-IPv4 prefix, the BGP rules for route preference decide which VPN-IPv4 route BGP installs 🔥

note that a route can only have one RD, but it can have multiple Route Targets 🫶 in BGP, scalability is better when you have a single route with multiple attributes instead of multiple routes 🧚 you could get rid of the Route Target attribute by creating more routes (i.e., using more RDs), but the scaling properties would be less favorable 💀

so how does a PE figure out which Route Target attributes to attach to a given route? 🤔 there are a few possible ways 💅 the PE might be configured to attach all routes leading to a specified site to a specified Route Target 🌸 or it might be configured to attach certain routes leading to a specified site to one Route Target and certain others to another 👑

if the PE and the CE are themselves BGP peers (see Section 7), the SP may allow the customer, within limits, to specify how its routes get distributed 🎀 the SP and the customer would need to agree in advance on the set of RTs that are allowed to be attached to the customer's VPN routes 🦋 the CE could then attach one or more of those RTs to each IP route it distributes to the PE 🌈 this gives the customer the freedom to specify, in real time and within agreed-upon limits, its route distribution policies ✨ if the CE is allowed to attach RTs to its routes, the PE MUST filter out all routes that contain RTs the customer is not allowed to use 🔥 if the CE is not allowed to attach RTs to its routes but does so anyway, the PE MUST remove the RT before converting the customer's route to a VPN-IPv4 route 😭💅

4.3.2. Route Distribution Among PEs by BGP ✨

okay so bestie, if two sites of the same VPN plug into PEs that live in the same Autonomous System, those PEs can swap VPN-IPv4 routes with each other over an IBGP connection 💖 (IBGP is the whole set of protocols and procedures for a BGP connection between two BGP speakers in the same AS, while EBGP is the set used between speakers in different ASes 🌸). Or, if that's too much, each PE can hold an IBGP connection to a route reflector [BGP-RR] instead. Pick your fighter 💅

When a PE distributes a VPN-IPv4 route over BGP, it uses its own address as the "BGP next hop" 🦋 That address gets encoded as a VPN-IPv4 address with an RD of 0. (Quick reminder that [BGP-MP] says the next hop address has to be in the same address family as the NLRI 🫶) The PE also assigns and distributes an MPLS label. Honestly the vibe is that PEs aren't really distributing plain VPN-IPv4 routes, they're distributing Labeled VPN-IPv4 routes 🔥 (cf. [MPLS-BGP]). When the PE gets a packet with that label sitting at the top of the stack, it pops the stack and processes the packet appropriately ✨

The PE can distribute the exact set of routes that shows up in the VRF, or it can summarize and send out aggregates of those routes, or it can do a mix of both 🎀 Totally its call.

Now here's the tea 🍓 Say a PE has assigned label L to route R and distributed that mapping over BGP. If R is an aggregate of a bunch of routes in the VRF, the PE knows that packets coming in from the backbone with this label have to get their destination addresses looked up in a VRF. When the PE looks up the label in its Label Information Base, it finds out which VRF to use. But if R is NOT an aggregate, then when the PE looks up the label, it learns the egress attachment circuit and the encapsulation header for the packet. In that case, no VRF lookup happens at all 🧚

We'd expect the most common case to be where the route is NOT an aggregate 💅 The aggregate case can still be super useful though, especially if the VRF has a ton of host routes (like with dial-in) 🌈 or if the VRF has an associated Local Area Network (LAN) interface. That's because each system on the LAN can need a different outgoing layer 2 header, but a route doesn't get distributed for each one of those systems 😭

Whether or not each route gets its own label is an implementation matter 🙈 There are a few algorithms you could use to decide if two routes get the same label:

One option is a single label for an entire VRF, so every route from that VRF shares one label. Then when the egress PE gets a packet with that label, it has to look up the packet's IP destination address in that VRF (the packet's "egress VRF") to figure out the egress attachment circuit and the matching data link encapsulation 💜
Another option is a single label for each attachment circuit, so every route with the same "outgoing attachment circuit" shares that label. This lets you skip the egress VRF lookup, though some kind of lookup may still be needed to find the data link encapsulation, like an Address Resolution Protocol (ARP) lookup 🦋
The last option is a distinct label for each route. Then if a route could be reached over more than one attachment circuit, the PE/CE routing can switch the preferred path for that route from one attachment circuit to another, and there's no need to distribute a new label for that route 🔥

There may be other algorithms too 🌸 Whichever one gets picked is entirely at the discretion of the egress PE, and otherwise it's transparent to everyone else ✨

When we use BGP-distributed MPLS labels this way, we're assuming that an MPLS packet carrying such a label can be tunneled from the router that installs the corresponding BGP-distributed route to the router that's the BGP next hop of that route 🫶 That needs either a label switched path between those two routers, or some other tunneling technology (for example [MPLS-in-IP-GRE]) that can run between them 🚀

This tunnel can follow a "best effort" route, or it can follow a traffic-engineered route 🎀 Between a given pair of routers there could be one tunnel, or several, maybe with different Quality of Service (QoS) characteristics 💖 All the VPN architecture really cares about is that some such tunnel exists 🌈 Now, to make sure systems that do this VPN architecture with MPLS label switched paths as the tunneling tech can all talk to each other, all such systems MUST support Label Distribution Protocol (LDP) [MPLS-LDP] 🔥 Specifically, Downstream Unsolicited mode MUST be supported on interfaces that are neither Label Controlled ATM (LC-ATM) [MPLS-ATM] nor Label Controlled Frame Relay (LC-FR) [MPLS-FR] interfaces 👑 And Downstream on Demand mode MUST be supported on LC-ATM interfaces and LC-FR interfaces 😭

If the tunnel follows a best-effort route, the PE finds the route to the remote endpoint by looking up its IP address in the default forwarding table. Just that one lookup, bestie 💀

A PE router, UNLESS it's a route reflector (see Section 4.3.3) or an Autonomous System Border Router (ASBR) for an inter-provider VPN (see Section 10), should not install a VPN-IPv4 route unless it has at least one VRF with an Import Target identical to one of the route's Route Target attributes 🙈 Inbound filtering should be used to get those routes discarded 💅 Now if a new Import Target gets added to one of the PE's VRFs (a "VPN Join" operation ✨), it must then acquire the routes it may have discarded before 🦋 It can do that with the refresh mechanism described in [BGP-RFSH] 🫶 The outbound route filtering mechanism of [BGP-ORF] can also be used to make the filtering more dynamic, which is giving very flexible energy 🌈

Same vibes in reverse 🌸 If a particular Import Target isn't in any of a PE's VRFs anymore (because of one or more "VPN Prune" operations), the PE may discard all the routes that, as a result, no longer have any of the PE's VRF's Import Targets as one of their Route Target attributes 🍓

A router that isn't attached to any VPN and isn't a Route Reflector (aka a P router) never installs any VPN-IPv4 routes at all 🧚 Not even one, periodt 💅

Also, VPN Join and Prune operations are non-disruptive ✨ They don't require any BGP connections to be brought down, as long as the refresh mechanism of [BGP-RFSH] is being used 🎀 No drama, no reset 💖

And because of all these distribution rules, no single PE ever has to maintain all the routes for all the VPNs 👑 That's a really important scalability consideration, and honestly it's iconic 🔥🌈

4.3.3. Use of Route Reflectors 🪞✨

okay so instead of making every PE talk to every other PE in a full IBGP mesh (which is giving chaos 💀), it's way more scalable to use BGP Route Reflectors [BGP-RR] 🦋. All the usual route reflector tricks for scaling, like route reflector hierarchies, are available too 💅.

Route reflectors are literally the only systems that need routing info for VPNs they aren't directly attached to 👀. BUT no single route reflector needs to know every VPN-IPv4 route for every VPN on the backbone, so relax 🫶.

We're gonna outline two different ways to split up the VPN-IPv4 routes across a bunch of route reflectors 🍓.

Method one: each route reflector gets a preconfigured list of Route Targets. For redundancy, more than one route reflector can have the same list 🌸. The route reflector uses that list to build its inbound route filtering. It may use the techniques in [BGP-ORF] to install Outbound Route Filters (ORFs) on each of its peers (whether that peer is another route reflector or a PE) that contain its preconfigured Route Targets 🧚. Also, route reflectors should accept ORFs from other route reflectors, which means route reflectors should advertise the ORF capability to other route reflectors 📣.
- A service provider can modify the preconfigured list on a route reflector. When that happens, the route reflector modifies the ORFs it installs on all of its IBGP peers 🔄.
- To reduce how often route reflectors need config changes, each one can be preconfigured with a block of Route Targets. That way, when a new Route Target is needed for a new VPN, there's already one or more route reflectors that are (pre)configured with it 🎀.
- Unless a given PE is a client of all route reflectors, when a new VPN is added to the PE ("VPN Join"), it will need to become a client of the route reflector(s) that maintain routes for that VPN. Likewise, deleting an existing VPN from the PE ("VPN Prune") may mean the PE no longer needs to be a client of some route reflector(s). In either case, the Join or Prune operation is non-disruptive (as long as [BGP-RFSH] is used), and it never requires a BGP connection to be brought down, only to be brought right back up 🙌.
- By "adding a new VPN to a PE," we really mean adding a new import Route Target to one of its VRFs, or adding a new VRF with an import Route Target that none of the PE's other VRFs have 💅.
Method two: each PE is a client of some subset of the route reflectors. The route reflector isn't preconfigured with the list of Route Targets, and it doesn't do inbound route filtering on routes from its clients (PEs). Instead, it accepts all the routes from all of its clients 🤝. It keeps track of the set of Route Targets carried by all the routes it receives. When it gets a route from a client with a Route Target that isn't in that set, that Route Target is immediately added to the set ⚡. On the other hand, when the route reflector no longer has any routes with a Route Target that's in the set, it should delay (by a few hours) deleting that Route Target from the set ⏳.
- The route reflector uses this set to form the inbound route filters it applies to routes from other route reflectors. It may also use ORFs to install the right outbound route filtering on other route reflectors. Just like with the first method, route reflectors should accept ORFs from other route reflectors. To make that work, a route reflector advertises the ORF capability to other route reflectors 🎯.
- When the route reflector changes the set, it should immediately change its inbound route filtering. If it uses ORFs, then those have to be immediately changed to reflect the changes in the set 🔁. If it doesn't use ORFs and a new Route Target is added to the set, the route reflector, after changing its inbound route filtering, must issue BGP Refresh to other route reflectors 📨.
- The "a few hours" delay lets a route reflector hold onto routes with a given Route Target, even after it loses the last of its clients that were interested in those routes. This protects against having to reacquire all those routes if the clients' "disappearance" is only temporary 💾.
- With this procedure, VPN Join and Prune operations are also non-disruptive ✨.

🚨 Note that this technique will not work properly if some client PE has a VRF with an import Route Target that is not one of its export Route Targets.

In these procedures, a PE router that attaches to a particular VPN "auto-discovers" the other PEs that attach to the same VPN 🔍. When a new PE router is added, or when an existing PE router attaches to a new VPN, no reconfiguration of the other PE routers is needed 🪄.

Just as there's no one PE router that needs to know all the VPN-IPv4 routes supported over the backbone, these distribution rules make sure there's no one Route Reflector (RR) that needs to know all of them either. So the total number of such routes the backbone can support isn't bounded by the capacity of any single device, and it can increase virtually without bound 🚀💜.

4.3.4. How VPN-IPv4 NLRI Is Carried in BGP 📦

The BGP Multiprotocol Extensions [BGP-MP] are used to encode the NLRI 🧩. If the Address Family Identifier (AFI) field is set to 1 and the Subsequent Address Family Identifier (SAFI) field is set to 128, the NLRI is an MPLS-labeled VPN-IPv4 address. AFI 1 is used because the network layer protocol associated with the NLRI is still IP 🌐. Also, this VPN architecture doesn't require the capability to distribute unlabeled VPN-IPv4 addresses, so no stress 🙅.

In order for two BGP speakers to exchange labeled VPN-IPv4 NLRI, they must use BGP Capabilities Advertisement so they both know they can properly process it 🎟️. This is done as specified in [BGP-MP], using capability code 1 (multiprotocol BGP), with an AFI of 1 and a SAFI of 128.

The labeled VPN-IPv4 NLRI itself is encoded as specified in [MPLS-BGP], where the prefix consists of an 8-byte RD followed by an IPv4 prefix 🏷️.

4.3.5. Building VPNs Using Route Targets 🛠️

By setting up the Import Targets and Export Targets properly, you can construct different kinds of VPNs 💕.

Say you want a fully meshed closed user group 🔒: a set of sites where each one can send traffic directly to the others, but traffic can't be sent to or received from other sites. Then each site gets a VRF, one single Route Target attribute is chosen, that Route Target is assigned to each VRF as both the Import Target and the Export Target, and it isn't assigned to any other VRFs as either one.

Or, suppose you want, for whatever reason, a "hub and spoke" kind of VPN 🕸️. That can be done with two Route Target values, one meaning "Hub" and one meaning "Spoke":

At the VRFs attached to the hub sites, "Hub" is the Export Target and "Spoke" is the Import Target.
At the VRFs attached to the spoke site, "Hub" is the Import Target and "Spoke" is the Export Target.

Thus, the methods for controlling the distribution of routing information among various sets of sites are super flexible, which gives you great flexibility in constructing VPNs 👑.

4.3.6. Route Distribution Among VRFs in a Single PE 🔁

It's possible to distribute routes from one VRF to another, even if both VRFs are in the same PE. In that case, though, you can't really say the route was distributed by BGP 🤷. Still, the decision to distribute a particular route from one VRF to another within a single PE is the same decision that would be made if the VRFs were on different PEs. It depends on the Route Target attribute assigned to the route (or the one it would be assigned if it were distributed by BGP), and on the import target of the second VRF 💖.

5. Forwarding ✨

okay so bestie, the big question is: if the backbone routers don't know anything about the VPN routes, how does a packet get from one VPN site to another?? 🤔🫶

When a PE gets an IP packet from a CE device, it picks one particular VRF to look up the packet's destination address in. That pick is based on the packet's ingress attachment circuit. 🎀

Let's say a match is found. Now we know the packet's "next hop" 💅

If the next hop is reached directly over a VRF attachment circuit on this same PE (so the egress attachment circuit is on the same PE as the ingress one), the packet just goes out the egress attachment circuit, and no MPLS labels get pushed onto it. Easy peasy 🦋

Now, if the ingress and egress attachment circuits are on the same PE but belong to different VRFs, and the route that best matches the destination in the ingress circuit's VRF is an aggregate of several routes in the egress circuit's VRF, it might be necessary to look up the destination address in the egress VRF too. Plot twist 😭

If the next hop is NOT reached through a VRF attachment circuit, then the packet has to travel at least one hop through the backbone. So the packet gets a "BGP Next Hop", and that BGP Next Hop will have assigned an MPLS label to the route that best matches the packet's destination. We call that label the "VPN route label". The IP packet becomes an MPLS packet with the VPN route label as the only label on its label stack. 🌈

Then the packet has to be tunneled to the BGP Next Hop. 🧚

If the backbone supports MPLS, here's how it goes:

The PE routers (and any Autonomous System border routers) that redistribute VPN-IPv4 addresses need to insert /32 address prefixes for themselves into the IGP routing tables of the backbone. This lets MPLS, at every node in the backbone network, assign a label to the route to each PE router. To keep different implementations playing nicely together, support for LDP is required for setting up the label switched paths across the backbone. Other methods of setting up those label switched paths are also possible. (Some of those other methods may not need the /32 address prefixes in the IGP.) 🍓
If there are any traffic engineering tunnels to the BGP next hop, and if one or more of them is available for the packet in question, one of those tunnels gets chosen. That tunnel is associated with an MPLS label, the "tunnel label". The tunnel label gets pushed onto the MPLS label stack, and the packet is forwarded to the tunnel's next hop. 🚇
Otherwise,
- The packet will have an "IGP Next Hop", which is the next hop along the IGP route to the BGP Next Hop.
- If the BGP Next Hop and the IGP Next Hop are the same, and penultimate hop popping is used, the packet is sent to the IGP Next Hop carrying only the VPN route label.
- Otherwise, the IGP Next Hop will have assigned a label to the route that best matches the address of the BGP Next Hop. We call that the "tunnel label". The tunnel label gets pushed on as the packet's top label, and the packet is forwarded to the IGP Next Hop. 💜
MPLS then carries the packet across the backbone to the BGP Next Hop, where the VPN label gets examined. ✨

If the backbone doesn't support MPLS, the MPLS packet carrying only the VPN route label may be tunneled to the BGP Next Hop using the techniques of [MPLS-in-IP-GRE]. When the packet comes out of the tunnel, it's at the BGP Next Hop, where the VPN route label gets examined. 🦢

At the BGP Next Hop, what happens to the packet depends on the VPN route label (see Section 4.3.2). In lots of cases, the PE can tell from that label which attachment circuit to send the packet out on (toward a CE device), plus the right data link layer header for that interface. In other cases, the PE can only figure out that the packet's destination address needs to be looked up in a particular VRF before it goes to a CE device. There are also in-between cases where the VPN route label determines the egress attachment circuit, but a lookup (like ARP) still has to happen to find the packet's data link header on that circuit. 🙈

Info in the MPLS header itself, and/or info tied to the label, may also be used to provide QoS on the interface to the CE. 💅

Either way, if the packet was an unlabeled IP packet when it arrived at its ingress PE, it'll be an unlabeled packet again when it leaves its egress PE. Full circle 🌸

Here's the really iconic part: because packets with VPN route labels get tunneled through the backbone, all the VPN routes can stay out of the P routers. That is crucial for keeping this whole scheme scalable 👑 The backbone doesn't even need routes to the CEs. It only needs routes to the PEs.

About the tunnels, this specification:

does not require the tunnels to be point-to-point. Multipoint-to-point can be used. 🦋
does not require any explicit setup of the tunnels, whether through signaling or manual configuration. 🎀
does not require any tunnel-specific signaling. 🫧
does not require any tunnel-specific state in the P or PE routers, beyond what's needed to maintain the routing information and (if used) the MPLS label information. 💖

Of course, this specification is compatible with point-to-point tunnels that have to be explicitly configured and/or signaled, and in some situations there may be good reasons to use them. 🌈

Choosing a particular tunneling technology is outside the scope of this specification. That's a whole other conversation, bestie 💅

6. Maintaining Proper Isolation of VPNs 🔒

okay the golden rule here is keeping each VPN isolated from the others 😤 It's important that no router in the backbone accepts a tunneled packet from outside the backbone, unless it's sure both endpoints of that tunnel are outside the backbone. Main character boundaries, iykyk 👑

If MPLS is the tunneling technology, a router in the backbone MUST NOT accept a labeled packet from any adjacent non-backbone device unless both of these conditions hold:

the label at the top of the label stack was actually distributed by that backbone router to that non-backbone device, and
the backbone router can determine that using that label will cause the packet to leave the backbone before any labels lower in the stack get inspected, and before the IP header gets inspected.

The first condition makes sure any labeled packets from non-backbone routers have a legit, properly assigned label on top of the stack. The second condition makes sure the backbone routers never look below that top label. 🙅‍♀️ Of course, the simplest way to meet both conditions is for backbone devices to just refuse labeled packets from non-backbone devices. Honestly the easiest 10/10 option 💀

If MPLS is not the tunneling technology, then filtering has to be done so that an MPLS-in-IP or MPLS-in-GRE packet gets accepted into the backbone only if its IP destination address will cause it to be sent outside the backbone. 🧱

7. How PEs Learn Routes from CEs ✨

okay so the PE routers that plug into a particular VPN need to know, for every attachment circuit leading to that VPN, which of the VPN's addresses are reachable over that circuit 🫶

The PE turns those addresses into VPN-IPv4 addresses using a configured RD 💅 Then it treats these VPN-IPv4 routes as input to BGP. Routes from a VPN site are NOT leaked into the backbone's IGP, no exceptions 🔥

Which PE/CE route distribution techniques you can use depends on whether a CE is in a "transit VPN" 👀 A "transit VPN" is one that has a router receiving routes from a "third party" (basically a router that's not in the VPN but also isn't a PE router) and then redistributing those routes to a PE router. A VPN that's not a transit VPN is a "stub VPN" 🌸 Honestly, most VPNs, including just about all corporate enterprise networks, would be expected to be "stubs" in this sense 💼

So the possible PE/CE distribution techniques are:

Static routing (aka configuration) may be used. (This is likely to be useful only in stub VPNs 🧚)
PE and CE routers may be Routing Information Protocol (RIP) [RIP] peers, and the CE may use RIP to tell the PE router the set of address prefixes that are reachable at the CE router's site. When RIP is configured in the CE, care must be taken to ensure that address prefixes from other sites (i.e., address prefixes the CE router learned from the PE router) are never advertised to the PE. More precisely: if a PE router, say, PE1, receives a VPN-IPv4 route R1, and as a result distributes an IPv4 route R2 to a CE, then R2 must not be distributed back from that CE's site to a PE router, say, PE2 (where PE1 and PE2 may be the same router or different routers), unless PE2 maps R2 to a VPN-IPv4 route that is different than (i.e., contains a different RD than) R1. This is the kind of detail that makes me lowkey stressed 😭
The PE and CE routers may be OSPF peers. A PE router that is an OSPF peer of a CE router appears, to the CE router, to be an area 0 router 🦋 If a PE router is an OSPF peer of CE routers that are in distinct VPNs, the PE must of course be running multiple instances of OSPF.

IPv4 routes that the PE learns from the CE via OSPF are redistributed into BGP as VPN-IPv4 routes. Extended Community attributes are used to carry, along with the route, all the information needed to enable the route to be distributed to other CE routers in the VPN in the proper type of OSPF Link State Advertisement (LSA). OSPF route tagging is used to ensure that routes received from the MPLS/BGP backbone are not sent back into the backbone.

Specification of the complete set of procedures for the use of OSPF between PE and CE can be found in [VPN-OSPF] and [OSPF-2547-DNBIT].

The PE and CE routers may be BGP peers, and the CE router may use BGP (in particular, EBGP) to tell the PE router the set of address prefixes that are at the CE router's site. (This technique can be used in stub VPNs or transit VPNs.) 💜

This technique has a number of advantages over the others:

a) Unlike the IGP alternatives, this does not require the PE to run multiple routing algorithm instances in order to talk to multiple CEs.

b) BGP is explicitly designed for just this function: passing routing information between systems run by different administrations. Iconic behaviour 👑

c) If the site contains "BGP backdoors", i.e., routers with BGP connections to routers other than PE routers, this procedure will work correctly in all circumstances. The other procedures may or may not work, depending on the precise circumstances.

d) Use of BGP makes it easy for the CE to pass attributes of the routes to the PE. A complete specification of the set of attributes and their use is outside the scope of this document. However, some examples of the way this may be used are the following:

The CE may suggest a particular Route Target for each route, from among the Route Targets that the PE is authorized to attach to the route. The PE would then attach only the suggested Route Target, rather than the full set. This gives the CE administrator some dynamic control of the distribution of routes from the CE.
Additional types of Extended Community attributes may be defined, where the intention is to have those attributes passed transparently (i.e., without being changed by the PE routers) from CE to CE. This would allow CE administrators to implement additional route filtering, beyond that which is done by the PEs. This additional filtering would not require coordination with the SP. 🎀

On the other hand, using BGP may be something new for the CE administrators 🙈

If a site is not in a transit VPN, note that it need not have a unique Autonomous System Number (ASN). Every CE whose site is not in a transit VPN can use the same ASN. This can be chosen from the private ASN space, and it will be stripped out by the PE. Routing loops are prevented by use of the Site of Origin attribute (see below).

What if a set of sites constitutes a transit VPN? This will generally be the case only if the VPN is itself an Internet Service Provider's (ISP's) network, where the ISP is itself buying backbone services from another SP. The latter SP may be called a "carrier's carrier". In this case, the best way to provide the VPN is to have the CE routers support MPLS, and to use the technique described in Section 9. 🌈

When we don't need to distinguish between the different ways a PE can be informed of the address prefixes that exist at a given site, we'll simply say that the PE has "learned" the routes from that site. This includes the case where the PE has been manually configured with the routes.

Before a PE can redistribute a VPN-IPv4 route learned from a site, it must assign a Route Target attribute (see Section 4.3.1) to the route, and it may assign a Site of Origin attribute to the route.

The Site of Origin attribute, if used, is encoded as a Route Origin Extended Community [BGP-EXTCOMM]. The purpose of this attribute is to uniquely identify the set of routes learned from a particular site. This attribute is needed in some cases to ensure that a route learned from a particular site via a particular PE/CE connection is not distributed back to the site through a different PE/CE connection. It's especially useful if BGP is being used as the PE/CE protocol, but different sites haven't been assigned distinct ASNs 💅

8. How CEs Learn Routes from PEs 🦋

In this section, we assume that the CE device is a router.

If the PE places a particular route in the VRF it uses to route packets received from a particular CE, then in general, the PE may distribute that route to the CE. Of course, the PE may distribute that route to the CE only if this is permitted by the rules of the PE/CE protocol. (For example, if a particular PE/CE protocol has "split horizon", certain routes in the VRF cannot be redistributed back to the CE.) We add one more restriction on the distribution of routes from PE to CE: if a route's Site of Origin attribute identifies a particular site, that route must never be redistributed to any CE at that site. Main character energy, but make it secure 🫶

In most cases, however, it will be sufficient for the PE to simply distribute the default route to the CE. (In some cases, it may even be sufficient for the CE to be configured with a default route pointing to the PE.) This will generally work at any site that does not itself need to distribute the default route to other sites. (E.g., if one site in a corporate VPN has the corporation's access to the Internet, that site might need to have default distributed to the other site, but one could not distribute default to that site itself.) 🧚

Whatever procedure is used to distribute routes from CE to PE will also be used to distribute routes from PE to CE. ✨

9. Carriers' Carriers ✨

okay so sometimes a VPN is actually an ISP's own network, with its own peering and routing rules 🌐 and sometimes a VPN is an SP's network that sells VPN service to its own customers 💅. These VPNs can also get backbone service from another SP, the "carrier's carrier" 🫶. It basically uses the same methods we already covered in this doc, BUT in these cases the CE routers need to support MPLS 🎀. Here's the list:

The CE routers should distribute to the PE routers ONLY those routes that are internal to the VPN. This lets the VPN be handled as a stub VPN 🌸.
The CE routers should support MPLS, meaning they should be able to receive labels from the PE routers, and send labeled packets to the PE routers. They do not need to distribute labels of their own though 🧚.
The PE routers should distribute, to the CE routers, labels for the routes they distribute to the CE routers.

The PE must not distribute the same label to two different CEs unless one of the following conditions holds:

The two CEs are associated with exactly the same set of VRFs;
The PE maintains a different Incoming Label Map ([MPLS-ARCH]) for each CE.

Further, when the PE receives a labeled packet from a CE, it must verify that the top label is one that was distributed to that CE 👀.

Routers at the different sites should establish BGP connections among themselves for the purpose of exchanging external routes (i.e., routes that lead outside of the VPN) 🦋.
All the external routes must be known to the CE routers.

So when a CE router looks up a packet's destination address, the routing lookup will resolve to an internal address, usually the address of the packet's BGP next hop 🍓. The CE labels the packet and sends it to the PE. Then the PE, instead of looking up the destination IP address in a VRF, uses the packet's top MPLS label to pick the BGP next hop 🔥. If that BGP next hop is more than one hop away, the top label gets replaced by two labels, a tunnel label and a VPN route label. If the BGP next hop is one hop away, the top label may just get replaced by the VPN route label. If the ingress PE is also the egress PE, the top label just gets popped 💀. When the packet goes from its egress PE to a CE, it has one fewer MPLS label than when its ingress PE first got it. Iconic label math 😭✨.

In that procedure, the CE routers are the only routers in the VPN that need MPLS support. BUT if all the routers at a particular VPN site support MPLS, then the CE routers don't have to know all the external routes anymore 🌈. All that's needed is that the external routes are known to whatever routers are in charge of putting the label stack on a packet that has no label yet, AND that there's a label switched path leading from those routers to their BGP peers at other sites 🛤️. In this setup, for each internal route a CE router distributes to a PE router, it must also distribute a label.

10. Multi-AS Backbones

What if two sites of a VPN are connected to different Autonomous Systems (e.g., because the sites are connected to different SPs)? 🤔 The PE routers attached to that VPN won't be able to keep IBGP connections with each other, or with a common route reflector 😵. So there needs to be some way to use EBGP to distribute VPN-IPv4 addresses 💜.

There are a number of ways to handle this, which we'll go through in order of increasing scalability 📈.

a) VRF-to-VRF connections at the AS (Autonomous System) border routers.

In this procedure, a PE router in one AS attaches directly to a PE router in another AS 🔗. The two PE routers will be attached by multiple sub-interfaces, at least one for each of the VPNs whose routes need to be passed from AS to AS. Each PE will treat the other as if it were a CE router. That means the PEs associate each of those sub-interfaces with a VRF, and use EBGP to distribute unlabeled IPv4 addresses to each other 🌷.

This one "just works" 🙌, and it doesn't require MPLS at the border between ASes. BUT it doesn't scale as well as the other procedures below 😬.

b) EBGP redistribution of labeled VPN-IPv4 routes from AS to neighboring AS.

In this procedure, the PE routers use IBGP to redistribute labeled VPN-IPv4 routes either to an Autonomous System Border Router (ASBR), or to a route reflector that has an ASBR as a client 🛰️. The ASBR then uses EBGP to redistribute those labeled VPN-IPv4 routes to an ASBR in another AS. That ASBR passes them to the PE routers in its AS, or maybe to another ASBR that passes them along, and so on 🔁.

When using this procedure, VPN-IPv4 routes should only be accepted on EBGP connections at private peering points, as part of a trusted arrangement between SPs 🔐. VPN-IPv4 routes should neither be distributed to nor accepted from the public Internet, or from any BGP peers that are not trusted 🚫. An ASBR should never accept a labeled packet from an EBGP peer unless it has actually distributed the top label to that peer 🙅‍♀️.

If there are many VPNs with sites attached to different Autonomous Systems, there doesn't need to be a single ASBR between those two ASes that holds all the routes for all the VPNs. There can be multiple ASBRs, each holding only the routes for a particular subset of the VPNs 🧩.

This procedure requires a label switched path leading from a packet's ingress PE to its egress PE, so the appropriate trust relationships must exist between and among the set of ASes along the path 🤝. Also, the SPs need to agree on which border routers should receive routes with which Route Targets 🎯.

c) Multi-hop EBGP redistribution of labeled VPN-IPv4 routes between source and destination ASes, with EBGP redistribution of labeled IPv4 routes from AS to neighboring AS.

In this procedure, VPN-IPv4 routes are neither maintained nor distributed by the ASBRs 🙈. An ASBR must maintain labeled IPv4 /32 routes to the PE routers within its AS. It uses EBGP to distribute these routes to other ASes. ASBRs in any transit ASes also have to use EBGP to pass along the labeled /32 routes 🚚. This creates a label switched path from the ingress PE router to the egress PE router. Now PE routers in different ASes can set up multi-hop EBGP connections to each other, and exchange VPN-IPv4 routes over those connections 🥰.

If the /32 routes for the PE routers are made known to the P routers of each AS, everything works normally ✅. If the /32 routes for the PE routers are NOT made known to the P routers (other than the ASBRs), then this procedure requires a packet's ingress PE to put a three-label stack on it 🥞. The bottom label is assigned by the egress PE, corresponding to the packet's destination address in a particular VRF. The middle label is assigned by the ASBR, corresponding to the /32 route to the egress PE. The top label is assigned by the ingress PE's IGP Next Hop, corresponding to the /32 route to the ASBR 🏷️.

To improve scalability, one can have the multi-hop EBGP connections exist only between a route reflector in one AS and a route reflector in another 📡. (However, when the route reflectors distribute routes over this connection, they do not modify the BGP next hop attribute of the routes.) The actual PE routers would then only have IBGP connections to the route reflectors in their own AS 💫.

This procedure is very similar to the "carrier's carrier" procedures described in Section 9. Like the previous procedure, it requires a label switched path leading from a packet's ingress PE to its egress PE 💖.

11. Accessing the Internet from a VPN ✨

okay so, a lot of VPN sites need to reach the public Internet too, not just the other sites in the VPN 🌐🦋. Here are some of the ways to make that happen, bestie 💅

Option one: non-VRF Internet access 🌸

Some VPNs have one or more sites get Internet access through an "Internet gateway" (perhaps a firewall) attached to a non-VRF interface to an ISP. The ISP may or may not be the same organization as the SP that is providing the VPN service. Traffic to and from the Internet gateway then gets routed according to the PE router's default forwarding table.

In this case, the sites that have Internet access may be distributing a default route to their PEs, which in turn redistribute it to other PEs and hence into other sites of the VPN. This provides Internet access for all of the VPN's sites 💖.

In order to properly handle traffic from the Internet, the ISP must distribute, to the Internet, routes leading to addresses that are within the VPN. This is completely independent of any of the route distribution procedures described in this document. The internal structure of the VPN will in general not be visible from the Internet; such routes would simply lead to the non-VRF interface that attaches to the VPN's Internet gateway 🧚.

In this model, there is no exchange of routes between a PE router's default forwarding table and any of its VRFs. VPN route distribution procedures and Internet route distribution procedures are completely independent 🫶.

Note that although some sites of the VPN use a VRF interface to communicate with the Internet, ultimately all packets to and from the Internet traverse a non-VRF interface before leaving or entering the VPN, so we refer to this as "non-VRF Internet access" 💜.

Note that the PE router to which the non-VRF interface attaches does not necessarily need to maintain all the Internet routes in its default forwarding table. The default forwarding table could have as few as one route, default, which leads to another router (probably an adjacent one) that has the Internet routes. A variation of this scheme is to tunnel packets received over the non-VRF interface from the PE router to another router, where this other router maintains the full set of Internet routes 🍓.

Option two: VRF Internet access 🦋

Some VPNs may obtain Internet access via a VRF interface ("VRF Internet access"). If a packet is received by a PE over a VRF interface, and if the packet's destination address does not match any route in the VRF, then it may be matched against the PE's default forwarding table. If a match is made there, the packet can be forwarded natively through the backbone to the Internet, instead of being forwarded by MPLS 🚀.

In order for traffic to flow natively in the opposite direction (from Internet to VRF interface), some of the routes from the VRF must be exported to the Internet forwarding table. Needless to say, any such routes must correspond to globally unique addresses 🌈.

In this scheme, the default forwarding table might have the full set of Internet routes, or it might have as little as a single default route leading to another router that does have the full set of Internet routes in its default forwarding table ✨.

Option three: non-VPN routes in a VRF 🌷

Suppose the PE has the capability to store "non-VPN routes" in a VRF. If a packet's destination address matches a "non-VPN route", then the packet is transmitted natively, rather than being transmitted via MPLS. If the VRF contains a non-VPN default route, all packets for the public Internet will match it, and be forwarded natively to the default route's next hop. At that next hop, the packets' destination addresses will be looked up in the default forwarding table, and may match more specific routes 🌙.

This technique would only be available if none of the CE routers is distributing a default route 🙈.

Option four: Internet routes inside each VRF 👑

It is also possible to obtain Internet access via a VRF interface by having the VRF contain the Internet routes. Compared with option two, this eliminates the second lookup, but it has the disadvantage of requiring the Internet routes to be replicated in each such VRF 💅.

If this technique is used, the SP may want to make its interface to the Internet be a VRF interface, and to use the techniques of Section 4 to distribute Internet routes, as VPN-IPv4 routes, to other VRFs 🎀.

It should be clearly understood that by default, there is no exchange of routes between a VRF and the default forwarding table. This is done ONLY upon agreement between a customer and an SP, and only if it suits the customer's policies 🔥.

12. Management VPNs 🎀

This specification does not require that the sub-interface connecting a PE router and a CE router be a "numbered" interface. If it is a numbered interface, this specification allows the addresses assigned to the interface to come from either the address space of the VPN or the address space of the SP 🧁.

If a CE router is being managed by the Service Provider, then the Service Provider will likely have a network management system that needs to be able to communicate with the CE router. In this case, the addresses assigned to the sub-interface connecting the CE and PE routers should come from the SP's address space, and should be unique within that space. The network management system should itself connect to a PE router (more precisely, be at a site that connects to a PE router) via a VRF interface. The address of the network management system will be exported to all VRFs that are associated with interfaces to CE routers that are managed by the SP. The addresses of the CE routers will be exported to the VRF associated with the network management system, but not to any other VRFs 🛰️.

This allows communication between the CE and network management system, but does not allow any undesired communication to or among the CE routers 🔐.

One way to ensure that the proper route import/exports are done is to use two Route Targets; call them T1 and T2. If a particular VRF interface attaches to a CE router that is managed by the SP, then that VRF is configured to:

import routes that have T1 attached to them, and
attach T2 to addresses assigned to each end of its VRF interfaces.

If a particular VRF interface attaches to the SP's network management system, then that VRF is configured to attach T1 to the address of that system, and to import routes that have T2 attached to them 🧚‍♀️.

13. Security Considerations 🔐

13.1. Data Plane 🔐

okay so when we say "data plane security" we're talking about two big fears 😭. First, packets from inside a VPN somehow sneaking out to a site outside the VPN in a way that breaks the VPN's rules. Second, packets from outside a VPN barging into one of its sites in a way that breaks the rules too. Total nightmare, no thank you 🙅‍♀️

Packets from within a VPN travel to a site outside the VPN, other than in a manner consistent with the policies of the VPN.
Packets from outside a VPN enter one of the VPN's sites, other than in a manner consistent with the policies of the VPN.

Now here's the deal. The data plane security we get from this architecture is basically the same vibe you'd get from VPNs running over Frame Relay or ATM backbones 💅, but only if all three of these are true:

a backbone router does not accept labeled packets over a particular data link, unless it is known that that data link attaches only to trusted systems, or unless it is known that such packets will leave the backbone before the IP header or any labels lower in the stack will be inspected, and
labeled VPN-IPv4 routes are not accepted from untrusted or unreliable routing peers,
no successful attacks have been mounted on the control plane,

If the SP's devices are set up properly, data won't enter or leave a VPN unless it's actually allowed to 🫶. That's the dream!

Condition 1 has a more precise version too 🤓. You should throw out a labeled packet that comes in from a particular neighbor unless one of these two things is true:

the packet's top label has a label value that the receiving system has distributed to that neighbor, or
the packet's top label has a label value that the receiving system has distributed to a system beyond that neighbor (i.e., when it is known that the path from the system to which the label was distributed to the receiving system may be via that neighbor).

Condition 2 is the one people care about most for inter-provider VPNs (see Section 10) 👑. If your inter-provider VPN is built using scheme b) of Section 10, checking condition 2 is easy peasy. (Security for scheme (c) of Section 10 is still for further study 🧐, so no promises there yet.)

Also, MPLS makes data plane security SO much simpler than trying to use some kind of IP tunneling in place of the MPLS outer label 🦋. Your border routers can just refuse to accept any labeled packet unless the first condition above applies to it. Easy! Making a router refuse an IP packet that's tunneled and has a PE router's address as its destination is way trickier. It's not impossible, but it comes with management and performance costs 😩.

MPLS-in-IP and MPLS-in-GRE tunneling are specified in [MPLS-in-IP-GRE]. If you want to use those tunnels to carry VPN packets, you have to fully understand the security considerations in Section 8 of that document 🚨. Any implementation of BGP/MPLS IP VPNs that lets VPN packets get tunneled the way that document describes MUST include an implementation of IPsec that can be used the way that document describes. If the tunnel isn't secured by IPsec, then the only way to make sure a packet leaving the tunnel at a certain egress PE was really put in the tunnel by the correct tunnel head node (so it doesn't have a spoofed source address) is IP address filtering at the border routers, as described in Section 8.2 of that document. Border routers often filter only source addresses, so packet filtering might not do the job unless the egress PE can check the IP source address of every tunneled packet it gets and compare it to a list of valid tunnel head addresses 🔍. Any implementation that allows MPLS-in-IP and/or MPLS-in-GRE tunneling without IPsec MUST let the egress PE validate the IP source address of any tunneled packet it receives in this way.

Now, what about when a bunch of CE routers hook up to a PE router through a LAN interface? For security to be solid, one of these has to be true 🌸:

All the CE routers on the LAN belong to the same VPN, or
A trusted and secured LAN switch divides the LAN into multiple VLANs, with each VLAN containing only systems of a single VPN; in this case, the switch will attach the appropriate VLAN tag to any packet before forwarding it to the PE router.

Real talk: this architecture doesn't provide cryptographic privacy 🙈, and neither do Frame Relay or ATM VPNs. They all play nicely with cryptography between CE and CE, though, if you want that extra layer 🔐.

Cryptography between PE and PE is still for further study 🧠.

13.2. Control Plane 🎛️

The data plane security we just talked about depends on the security of the control plane, so it's a whole chain 🔗. To keep things safe, neither BGP nor LDP connections should be made with untrusted peers. Both of these protocols should use the TCP/IP MD5 authentication option [TCP-MD5]. The routing protocol inside the SP's network should also be secured in a similar way 💜.

13.3. Security of P and PE Devices 🛡️

If somebody compromises the physical security of these devices, the data plane security might also go down with them 😬.

The usual steps should be taken so that IP traffic from the public Internet can't be used to change the configuration of these devices, or to launch Denial of Service attacks against them. Protect your gear, bestie 🫡.

14. Quality of Service 🌈

This paper isn't really focused on it, but Quality of Service is a key part of any VPN service ✨. In MPLS/BGP VPNs, you can apply existing L3 QoS capabilities to labeled packets using the "experimental" bits in the shim header [MPLS-ENCAPS]. Or, if ATM is the backbone, you can use ATM QoS capabilities instead 💖. The traffic engineering work in [MPLS-RSVP] also applies directly to MPLS/BGP VPNs. Traffic engineering could even set up label switched paths with particular QoS characteristics between certain pairs of sites, if that's what you want 🧚. When an MPLS/BGP VPN spans multiple SPs, the architecture described in [PASTE] might be useful. And an SP can apply either intserv (Integrated Services) or diffserv (Differentiated Services) capabilities to a particular VPN, whichever fits best 💅.

15. Scalability 📈

We've been talking about scalability this whole time 🙌, but this section is a quick recap of the main things that make our model scale.

The Service Provider backbone network is made up of (a) PE routers, (b) BGP Route Reflectors, (c) P routers (that are neither PE routers nor Route Reflectors), and, in the case of multi-provider VPNs, (d) ASBRs.

P routers don't keep any VPN routes 🙅‍♀️. To forward VPN traffic correctly, they only need routes to the PE routers and the ASBRs. Having two levels of labeling is what keeps VPN routes out of the P routers, so that's the magic trick ✨.

A PE router keeps VPN routes, but only for the VPNs it's directly attached to 🎀.

Route reflectors can be split up among VPNs so that each partition only carries routes for a subset of the VPNs the Service Provider supports. That means no single route reflector has to hold routes for every VPN 🦋.

For inter-provider VPNs, if the ASBRs maintain and distribute VPN-IPv4 routes, the ASBRs can be split up among VPNs in a similar way, so no single ASBR has to keep routes for all the inter-provider VPNs. And if multi-hop EBGP is used, the ASBRs don't need to maintain and distribute VPN-IPv4 routes at all 🙌.

So no single component in the Service Provider network has to keep all the routes for all the VPNs. The total capacity of the network to support more and more VPNs isn't capped by the capacity of any one component. Iconic, honestly 👑.

16. IANA Considerations 📋

The Internet Assigned Numbers Authority (IANA) created a new registry for the "Route Distinguisher Type Field" (see Section 4.2) 🗂️. It's a two-byte field. Types 0, 1, and 2 are defined by this document. IANA may allocate additional Route Distinguisher Type Field values with a high-order bit of 0 on a "First Come, First Served" basis [IANA]. Values with a high-order bit of 1 may be allocated by IANA based on "IETF consensus" [IANA].

This document specifies (see Section 4.3.4) the use of the BGP Address Family Identifier (AFI) value 1, along with the BGP Subsequent Address Family Identifier (SAFI) value 128, to represent the address family "VPN-IPv4 Labeled Addresses", which is defined in this document 💜.

Using AFI value 1 for IP is already specified in the IANA registry "Address Family Identifier", so IANA doesn't need to do anything about it 🙂.

SAFI value 128 was originally specified as "Private Use" in the IANA "Subsequent Address Family Identifier" registry. IANA has changed SAFI value 128 from "private use" to "MPLS-labeled VPN address" 🎉. Glow up complete!

17. Acknowledgements 💌

The full list of contributors can be found in Section 18 💕.

Significant contributions to this work have also been made by Ravi Chandra, Dan Tappan, and Bob Thomas 🫶.

We also want to thank Shantam Biswas for his review and contributions 🌷.

18. Contributors 👯‍♀️

These are the people who helped make this happen, with their addresses and emails exactly as they appeared 📮:

Tony Bogovic
Telcordia Technologies
445 South Street, Room 1A264B
Morristown, NJ 07960

EMail: tjb@research.telcordia.com


Stephen John Brannon
Swisscom AG
Postfach 1570
CH-8301
Glattzentrum (Zuerich), Switzerland

EMail: stephen.brannon@swisscom.com
Marco Carugi
Nortel Networks S.A.
Parc d'activites de Magny-Les Jeunes Bois  CHATEAUFORT
78928 YVELINES Cedex 9 - FRANCE

EMail: marco.carugi@nortelnetworks.com


Christopher J. Chase
AT&T
200 Laurel Ave
Middletown, NJ 07748
USA

EMail: chase@att.com


Ting Wo Chung
Bell Nexxia
181 Bay Street
Suite 350
Toronto, Ontario
M5J2T3

EMail: ting_wo.chung@bellnexxia.com


Eric Dean


Jeremy De Clercq
Alcatel Network Strategy Group
Francis Wellesplein 1
2018 Antwerp, Belgium

EMail: jeremy.de_clercq@alcatel.be


Luyuan Fang
AT&T
IP Backbone Architecture
200 Laurel Ave.
Middletown, NJ 07748

EMail: luyuanfang@att.com
Paul Hitchen
BT
BT Adastral Park
Martlesham Heath,
Ipswich IP5 3RE
UK

EMail: paul.hitchen@bt.com


Manoj Leelanivas
Juniper Networks, Inc.
385 Ravendale Drive
Mountain View, CA 94043 USA

EMail: manoj@juniper.net


Dave Marshall
Worldcom
901 International Parkway
Richardson, Texas 75081

EMail: dave.marshall@wcom.com


Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112

EMail: lmartini@cisco.com


Monique Jeanne Morrow
Cisco Systems, Inc.
Glatt-com, 2nd floor
CH-8301
Glattzentrum, Switzerland

EMail: mmorrow@cisco.com
Ravichander Vaidyanathan
Telcordia Technologies
445 South Street, Room 1C258B
Morristown, NJ 07960

EMail: vravi@research.telcordia.com


Adrian Smith
BT
BT Adastral Park
Martlesham Heath,
Ipswich IP5 3RE
UK

EMail: adrian.ca.smith@bt.com


Vijay Srinivasan
1200 Bridge Parkway
Redwood City, CA 94065

EMail: vsriniva@cosinecom.com


Alain Vedrenne
Equant
Heraklion, 1041 route des Dolines, BP347
06906 Sophia Antipolis, Cedex, France

EMail: Alain.Vedrenne@equant.com

19. Normative References 📚✨

okay so these are the ones you need to actually implement this stuff, no cap 💅

[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[BGP-EXTCOMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS-BGP] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.

20. Informative References 🦋

these are the background reads: the bonus context that makes everything click, bestie 🧚

[BGP-AS4] Vohra, Q. and E. Chen, "BGP Support for Four-Octet AS Number Space", Work in Progress, March 2004.
[BGP-ORF] Chen, E. and Y. Rekhter, "Cooperative Route Filtering Capability for BGP-4", Work in Progress, March 2004.
[BGP-RFSH] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[BGP-RR] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[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.
[MPLS-FR] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
[MPLS-in-IP-GRE] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[MPLS-RSVP] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[PASTE] Li, T. and Y. Rekhter, "A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998.
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[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.
[TCP-MD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[VPN-MCAST] Rosen, E., Cai, Y., and J. Wijsnands, "Multicast in MPLS/BGP VPNs", Work in Progress, May 2004.
[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.

Authors' Addresses 💖

meet the people who wrote this whole thing, iconic 👑

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

EMail: erosen@cisco.com


Yakov Rekhter
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089

EMail: yakov@juniper.net

Full Copyright Statement 💅

so the legal bit, and yes it matters, bestie 🙈

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 on whether any IPR claims that might be made about the tech in this document are valid, how far they reach, or whether a license for them is even available. It also doesn't claim it went looking for any of them. If you want the procedures for rights in RFC documents, check out BCP 78 and BCP 79 💜

Copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses that may be available, or the results of an attempt to get a general license or permission to use the proprietary rights by implementers or users of this spec, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.

The IETF also invites any interested party to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 🌸

Acknowledgement 🫶

funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). and that's a wrap on the whole RFC, periodt ✨🎀

📦 where this page comes from

ietf: rfc4364 2006-02
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms