RFC 4577

OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)

📅 published June 2006, from ietf

Part 1 of 6 🎀

RFC 4577 💖 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)

Network Working Group 🌸 E. Rosen, P. Psenak, and P. Pillay-Esnault, all from Cisco Systems, Inc. 💅

Category: Standards Track ✨ Date: June 2006 📅 Updates: RFC 4364 🦋 This one doesn't obsolete anything, it just updates RFC 4364 🔥

Status of This Memo 📜

okay so this document is an Internet standards track protocol for the Internet community 🌈 It's basically asking everyone to talk about it and send in suggestions for making it better 💬 If you want to know where this protocol stands officially, check the current edition of "Internet Official Protocol Standards" (STD 1) 🧚 And the good news is that distribution of this memo is unlimited, so share away bestie 🫶

Copyright Notice ©️

Abstract ✨

so picture this: lots of Service Providers sell Virtual Private Network (VPN) services to their customers 🌍 The trick they use is that customer edge routers (CE routers) become routing peers of provider edge routers (PE routers) 🤝 The Border Gateway Protocol (BGP) carries the customer's routes across the provider's IP backbone, and Multiprotocol Label Switching (MPLS) tunnels the customer's packets across that same backbone 🚇 This combo is called a "BGP/MPLS IP VPN" 💅 The base spec for BGP/MPLS IP VPNs assumes the routing protocol between a PE router and a CE router is BGP, but this document extends that and lets the PE/CE routing protocol be Open Shortest Path First (OSPF) instead 🔥 It's giving flexibility, honestly 🦋

This document updates RFC 4364. 🎀

Table of Contents 📚

   1. Introduction ....................................................2
   2. Specification of Requirements ...................................3
   3. Requirements ....................................................4
   4. BGP/OSPF Interaction Procedures for PE Routers ..................6
      4.1. Overview ...................................................6
           4.1.1. VRFs and OSPF Instances .............................6
           4.1.2. VRFs and Routes .....................................6
           4.1.3. Inter-Area, Intra-Area, and External Routes .........7
           4.1.4. PEs and OSPF Area 0 .................................8
           4.1.5. Prevention of Loops .................................9
      4.2. Details ....................................................9
           4.2.1. Independent OSPF Instances in PEs ...................9
           4.2.2. Router ID ..........................................10
           4.2.3. OSPF Areas .........................................10
           4.2.4. OSPF Domain Identifiers ............................10
           4.2.5. Loop Prevention ....................................12
                  4.2.5.1. The DN Bit ................................12
                  4.2.5.2. Use of OSPF Route Tags ....................12
                  4.2.5.3. Other Possible Loops ......................13
           4.2.6. Handling LSAs from the CE ..........................14
           4.2.7. Sham Links .........................................16
                  4.2.7.1. Intra-Area Routes .........................16
                  4.2.7.2. Creating Sham Links .......................17
                  4.2.7.3. OSPF Protocol on Sham Links ...............18
                  4.2.7.4. Routing and Forwarding on Sham Links ......19
           4.2.8. VPN-IPv4 Routes Received via BGP ...................19
                  4.2.8.1. External Routes ...........................20
                  4.2.8.2. Summary Routes ............................22
                  4.2.8.3. NSSA Routes ...............................22
   5. IANA Considerations ............................................22
   6. Security Considerations ........................................23
   7. Acknowledgements ...............................................23
   8. Normative References ...........................................23
   9. Informative References .........................................24

1. Introduction 🧚

[VPN] explains how a Service Provider (SP) can use its IP backbone to give customers a VPN (Virtual Private Network) service 🌸 In that setup, a customer's edge devices (CE devices) hook up to the provider's edge routers (PE routers) 🔌 If the CE device is a router, the PE router can become one of its routing peers (using some routing protocol) and pick up the routes that lead to the CE's site 🗺️ Those routes then need to get sent to the other PE routers attached to the same VPN 📨

The PE routers attached to a common VPN use BGP (Border Gateway Protocol) to swap the VPN's routes with each other 🔁 A CE router then learns the routes to the other sites in the VPN by peering with its attached PE router in a routing protocol 💜 CE routers at different sites do not peer with each other, though, so no CE-to-CE drama 🙈

It's super likely that a lot of VPNs will use OSPF (Open Shortest Path First) as their IGP (Interior Gateway Protocol), which is just the routing protocol a network uses to distribute its internal routes ✨ That doesn't automatically mean the PE routers have to use OSPF to peer with the CE routers 🤷‍♀️ Each site in a VPN can run OSPF as its intra-site routing protocol while using, for example, BGP [BGP] or RIP (Routing Information Protocol) [RIP] to get routes to a PE router 🦋 That said, when OSPF is already running intra-site, it's honestly convenient to use it on the PE-CE link too, and [VPN] explicitly allows this 👑

Like anything else, using OSPF on the PE-CE link has pros and cons 🍓 The con is that it pulls the SP's PE router into a VPN site's IGP, even if only a little 🥺 But the pros are:

The administrators of the CE router don't need expertise in any routing protocol other than OSPF. 💅
The CE routers don't need support for any routing protocols other than OSPF. 🫶
If a customer is moving their network from a traditional OSPF backbone to the VPN service described in [VPN], using OSPF on the PE-CE link makes the transition way smoother. 🌈

Some SPs and their customers are going to pick the OSPF-on-PE-CE route, so we need to spell out the procedures a PE router must implement to make that possible 🔥 (No special procedures are needed on the CE router though. CE routers just run whatever OSPF implementations they already have 💖)

2. Specification of Requirements 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 💜 Read those capitalised words as the strict BCP 14 requirement levels they are, bestie 👑

3. Requirements ✨

Okay, so picture a bunch of VPN sites that are all in the same "OSPF domain" 🌸. Two sites count as being in the same OSPF domain if the plan is for routes from one to be treated as intra-network routes by the other. Sites in the same domain are almost definitely a group that together makes up an "intranet" 🦋, and each one runs OSPF as its intra-site routing protocol.

Per [VPN], the VPN routes get spread among the PE routers using BGP. Now, if the PE uses OSPF to hand routes to the CE router, the normal BGP/OSPF interaction rules [OSPFv2] would make routes from one site show up at another site inside type 5 LSAs (Link State Advertisements) as "AS-external" routes. 💀 That's not it, bestie. It would be way better to send those routes in type 3 LSAs (as inter-area routes), so they can be told apart from any "real" AS-external routes floating around the VPN. In other words, OSPF can tell them apart from routes that genuinely don't come from inside the VPN 🎀. So the PE routers have to implement a modified version of the BGP/OSPF interaction procedures.

Honestly, we want a super general set of procedures 👑. The goal is to let a customer swap a legacy private OSPF backbone for the VPN service without drama. These are the requirements the procedure has to meet:

The procedures should not make assumptions about the OSPF topology. In particular, it should not be assumed that customer sites are OSPF stub sites or NSSA (Not So Stubby Area) sites. Nor should it be assumed that a customer site contains only one OSPF area, or that it has no area 0 routers.
If VPN sites A and B are in the same OSPF domain, then routes from one should be presented to the other as OSPF intra-network routes. In general, this can be done by presenting such routes as inter-area routes in type 3 LSAs.

Note that this allows two VPN sites to be connected via an "OSPF backdoor link". That is, one can have an OSPF link between the two sites that is used only when the VPN backbone is unavailable. (This would not be possible with the ordinary BGP/OSPF interaction procedures. The ordinary procedures would present routes via the VPN backbone as AS-external routes, and these could never be preferred to intra-network routes.) This may be very useful during a period of transition from a legacy OSPF backbone to a VPN backbone.

It should be possible to make use of an "OSPF backdoor link" between two sites, even if the two sites are in the same OSPF area and neither of the routers attached to the inter-site backdoor link is an area 0 router. This can also be very useful during a transition period, and it eliminates any need to reconfigure the sites' routers to be ABRs (Area Border Routers).

Assuming that it is desired to have the route via the VPN backbone be preferred to the backdoor route, the VPN backbone itself must be presented to the CE routers at each site as a link between the two PE routers to which the CE routers are respectively attached.

CE routers, connected to PE routers of the VPN service, may themselves function as OSPF backbone (area 0) routers. An OSPF backbone may even consist of several "segments" that are interconnected themselves only via the VPN service. In such a scenario, full intercommunication between sites connected to different segments of the OSPF backbone should still be possible.
The transition from the legacy private OSPF backbone to the VPN service must be simple and straightforward. The transition is likely to be phased, such that customer sites are migrated one by one from the legacy private OSPF backbone to the VPN service. During the transition, any given site might be connected to the VPN service, to the legacy OSPF backbone, or to both. Complete connectivity among all such sites must be maintained.

Since the VPN service is to replace the legacy backbone, it must be possible, by suitable adjustment of the OSPF metrics, to make OSPF prefer routes that traverse the SP's VPN backbone to alternative routes that do not.

The OSPF metric assigned to a given route should be carried transparently over the VPN backbone.

Routes from sites that are not in the same OSPF domain will appear as AS-external routes.

We presuppose familiarity with the contents of [OSPFv2], including the OSPF LSA types, and will refer without further explanation to type 1, 2, 3, etc. LSAs. Familiarity with [VPN] is also presupposed. 🧚

4. BGP/OSPF Interaction Procedures for PE Routers 💅

4.1. Overview 🌈

4.1.1. VRFs and OSPF Instances

A PE router that attaches to more than one OSPF domain MUST run an independent instance of OSPF for each domain. If the PE is running OSPF as its IGP (Interior Gateway Protocol), the instance of OSPF running as the IGP must be separate and independent from any other instance of OSPF that the PE is running. (Whether these instances are realized as separate processes or merely as separate contexts of a common process is an implementation matter.) Each interface that attaches to a VPN site belongs to no more than one OSPF instance.

[VPN] defines the notion of a Per-Site Routing and Forwarding Table, or VRF. Each VRF is associated with a set of interfaces. If a VRF is associated with a particular interface, and that interface belongs to a particular OSPF instance, then that OSPF instance is said to be associated with the VRF. If two interfaces belong to the same OSPF instance, then both interfaces must be associated with the same VRF.

If an interface attaches a PE to a CE, and that interface is associated with a VRF, we will speak of the CE as being associated with the VRF.

4.1.2. VRFs and Routes 🦋

OSPF is used to distribute routes from a CE to a PE. The standard OSPF decision process is used to install the best OSPF-distributed routes in the VRF.

Per [VPN], BGP is used to distribute VPN-IPv4 routes among PE routers. An OSPF route installed in a VRF may be "exported" by being redistributed into BGP as a VPN-IPv4 route. It may then be distributed by BGP to other PEs. At the other PEs, a VPN-IPv4 route may be "imported" by a VRF and may then be redistributed into one or more of the OSPF instances associated with that VRF.

Import from and export to particular VRFs is controlled by the use of the Route Target Extended Communities attribute (or, more simply, Route Target or RT), as specified in [VPN].

A VPN-IPv4 route is "eligible for import" into a particular VRF if its Route Target is identical to one of the VRF's import Route Targets. The standard BGP decision process is used to select, from among the routes eligible for import, the set of VPN-IPv4 routes to be "installed" in the VRF.

If a VRF contains both an OSPF-distributed route and a VPN-IPv4 route for the same IPv4 prefix, then the OSPF-distributed route is preferred. In general, this means that forwarding is done according to the OSPF route. The one exception to this rule has to do with the "sham link". If the next hop interface for an installed (OSPF-distributed) route is the sham link, forwarding is done according to a corresponding BGP route. This is detailed in Section 4.2.7.4.

To meet the requirements of Section 3, a PE that installs a particular route into a particular VRF needs to know whether that route was originally an OSPF route and, if so, whether the OSPF instance from which it was redistributed into BGP is in the same domain as the OSPF instances into which the route may be redistributed. Therefore, a domain identifier is encoded as a BGP Extended Communities attribute [EXTCOMM] and distributed by BGP along with the VPN-IPv4 route. The route's OSPF metric and OSPF route type are also carried as BGP attributes of the route.

4.1.3. Inter-Area, Intra-Area, and External Routes ✨

Okay so picture this, bestie 💅: a PE grabs a VPN-IPv4 route through BGP and drops it into a VRF. If that's the preferred BGP route for the matching IPv4 prefix, the IPv4 route becomes "eligible for redistribution" into every OSPF instance tied to that VRF. 🦋 That means it could get advertised to each CE in an LSA.

Being eligible doesn't mean it actually gets redistributed, though 🙈. Depending on the configuration, the PE might be set up to push only the default route into a certain OSPF instance. In that case, the eligible routes just wouldn't get redistributed. Main character config, no cap.

Next up are the procedures for redistributing a BGP-distributed VPN-IPv4 route into OSPF. These are the steps to follow whenever a route is eligible to be redistributed and the configuration doesn't block it. 💖

If the route comes from a different OSPF domain than the OSPF instance it's going into, or it isn't from an OSPF domain at all, then it counts as an external route. ✨

If the route comes from the same OSPF domain as the instance it's going into, and it was originally advertised to a PE as an OSPF external route or an OSPF NSSA route, it gets treated as an external route too. Following the normal OSPF procedures, external routes may be advertised to the CE in type 5 LSAs, or in type 7 LSAs, or not at all, depending on the type of area the PE/CE link belongs to. 🌸

If the route is from the same OSPF domain as the instance it's going into, and it was originally advertised to a PE as an inter-area or intra-area route, it'll generally be advertised to the CE as an inter-area route (in a type 3 LSA). It's giving consistency 👑

Now for the special case 🎀. Say PE1 attaches to CE1, and PE2 attaches to CE2, where:

the OSPF instance containing the PE1-CE1 link and the OSPF instance containing the PE2-CE2 link are in the same OSPF domain, and
the PE1-CE1 and PE2-CE2 links are in the same OSPF area A (as determined by the configured OSPF area number),

then PE1 may flood to CE1 a type 1 LSA advertising a link to PE2, and PE2 may flood to CE2 a type 1 LSA advertising a link to PE1. The link advertised in these LSAs is known as a "sham link," and it's advertised as a link in area A. 🧚 This makes it look to routers in area A like the path from CE1 to PE1, across the service provider's network to PE2 and then to CE2, is an intra-area path. Bestie, that's iconic.

Sham links are an OPTIONAL feature of this specification, and they're only used when it's really necessary to have the service provider's network treated as an intra-area link. Check Section 4.2.7 for more deets on the sham link. 💜

The exact way a PE works out which LSA type to use for advertising a particular route to a CE is laid out in Section 4.2.8. Heads up: if the VRF is associated with multiple OSPF instances, the LSA type used for the route might be different in each instance. 🫶

Also, if a VRF is associated with several OSPF instances, a given route might get redistributed into some or all of them, depending on each instance's characteristics. If it gets redistributed into two or more instances, it may be advertised within each one using a different LSA type, again depending on the characteristics of that instance. ✨

4.1.4. PEs and OSPF Area 0 🌈

Within a single OSPF domain, a PE may attach to multiple CEs. Each PE/CE link gets assigned (by configuration) to an OSPF area. Any link can be assigned to any area, including area 0. 🍓

If a PE attaches to a CE over a link in a non-zero area, then the PE acts as an ABR for that area. 💅

So PEs can basically be treated as OSPF "area 0 routers," meaning they can be considered part of the "OSPF backbone." Because of that, they're allowed to distribute inter-area routes to the CE via Type 3 LSAs. 👑

If the OSPF domain has any area 0 routers other than the PE routers, then at least one of those MUST be a CE router and MUST have an area 0 link to at least one PE router. This adjacency MAY be via an OSPF virtual link. (Using an OSPF virtual link this way is an OPTIONAL feature.) This is needed so inter-area routes and AS-external routes can get leaked between the PE routers and the non-PE OSPF backbone. 🫶

Two sites that aren't in the same OSPF area will see the VPN backbone as an integral part of the OSPF backbone. But if there are area 0 routers that are NOT PE routers, then the VPN backbone actually works like a higher-level backbone, adding a third level of hierarchy above area 0. 🦋 That lets a legacy OSPF backbone get disconnected during a transition period, as long as all the segments attach to the VPN backbone. Lowkey genius.

4.1.5. Prevention of Loops 🔥

If a route sent from a PE router to a CE router could then be received by another PE router from one of its own CE routers, routing loops could happen. Yikes 😭. To prevent this, a PE sets the DN bit [OSPF-DN] in any LSA it sends to a CE, and a PE ignores any LSA received from a CE that already has the DN bit set. Older implementations may use an OSPF Route Tag instead of the DN bit in some cases. Check Sections 4.2.5.1 and 4.2.5.2 for those details. 🎀

4.2. Details ⭐

4.2.1. Independent OSPF Instances in PEs 🧚

The PE MUST support one OSPF instance for each OSPF domain it attaches to. These OSPF instances work independently and don't leak routes to each other. Each instance of OSPF MUST be associated with a single VRF. If n CEs associated with that VRF are running OSPF on their respective PE/CE links, then those n CEs are OSPF adjacencies of the PE in the corresponding OSPF instance. 💖

Generally, though not necessarily, if the PE attaches to several CEs in the same OSPF domain, it will associate the interfaces to those CEs with a single VRF. 🌸

4.2.2. Router ID 🦋

If a PE and a CE are talking via OSPF, the PE will have an OSPF Router ID that is valid (meaning unique) within the OSPF domain. More precisely, each OSPF instance has a Router ID, and different OSPF instances may have different Router IDs. ✨

4.2.3. OSPF Areas 💜

A PE-CE link may be in any area, including area 0. This is just a matter of the OSPF configuration. 🫶

If a PE has a link that belongs to a non-zero area, the PE functions as an Area Border Router (ABR) for that area. 👑

PEs don't pass the link state topology from one site to another (except when a sham link is used; see Section 4.2.7). 🙈

Per [OSPFv2, Section 3.1], "the OSPF backbone always contains all area border routers." So the PE routers are considered area 0 routers. Section 3.1 of [OSPFv2] also requires that area 0 be contiguous. It follows that if the OSPF domain has any area 0 routers other than the PE routers, at least one of those MUST be a CE router, and it MUST have an area 0 link (possibly a virtual link) to at least one PE router. 🍓

4.2.4. OSPF Domain Identifiers 🌈

Each OSPF instance MUST be associated with one or more Domain Identifiers. This MUST be configurable, and the default value (if none is configured) SHOULD be NULL. 💅

If an OSPF instance has multiple Domain Identifiers, one of them is considered its "primary" Domain Identifier, and this MUST be determinable by configuration. If an OSPF instance has exactly one Domain Identifier, that one is obviously its primary Domain Identifier. If an OSPF instance has more than one Domain Identifier, the NULL Domain Identifier MUST NOT be one of them. 🎀

If a route is installed in a VRF by a particular OSPF instance, the primary Domain Identifier of that OSPF instance is considered the route's Domain Identifier. ✨

Let's say there's a route, R, that gets installed in a VRF by OSPF instance I1, then redistributed into BGP as a VPN-IPv4 route, and then installed by BGP in another VRF. If R needs to be redistributed into OSPF instance I2, which is associated with that latter VRF, the way R gets advertised in I2 depends on whether R's Domain Identifier is one of I2's Domain Identifiers. If R's Domain Identifier is not one of I2's Domain Identifiers, then R will be advertised as an AS-external route if it's redistributed into I2, no matter what its OSPF route type is. But if R's Domain Identifier is one of I2's Domain Identifiers, how R gets advertised depends on R's OSPF route type. 🧚

If two OSPF instances are in the same OSPF domain, then either:

They both have the NULL Domain Identifier, OR
Each OSPF instance has the primary Domain Identifier of the other as one of its own Domain Identifiers.

If two OSPF instances are in different OSPF domains, then either:

They both have the NULL Domain Identifier, OR
Neither OSPF instance has the Primary Domain Identifier of the other as one of its own Domain Identifiers.

(Heads up, bestie: if two OSPF instances each have the NULL Domain Identifier, we can't tell from the Domain Identifier whether they're in the same OSPF Domain. If they're in different domains and routes from one get distributed into the other, those routes will show up as intra-network routes, which may not be what anyone intended. 😭)

A Domain Identifier is an eight-byte quantity that's a valid BGP Extended Communities attribute, as specified in Section 4.2.4. If a particular OSPF instance has a non-NULL Domain Identifier, then when routes from that OSPF instance get distributed by BGP as VPN-IPv4 routes, the routes MUST carry the Domain Identifier Extended Communities attribute that corresponds to the OSPF instance's Primary Domain Identifier. If the OSPF instance's Domain Identifier is NULL, the Domain Identifier Extended Communities attribute MAY be omitted when routes from that OSPF instance are distributed by BGP. Alternatively, a value of the Domain Identifier Extended Communities attribute that represents NULL (see Section 4.2.4) MAY be carried with the route. 💜

If the OSPF instances of an OSPF domain are given one or more non-NULL Domain Identifiers, this procedure lets us figure out whether a particular OSPF-originated VPN-IPv4 route belongs to the same domain as a given OSPF instance. From there we can tell whether the route should be redistributed to that OSPF instance as an inter-area route or as an OSPF AS-external route. The details are in Sections 4.2.4 and 4.2.8.1. 🌸

4.2.5. Loop Prevention 🙈

4.2.5.1. The DN Bit 🦋

Okay so when a type 3 LSA goes from a PE router to a CE router, the DN bit [OSPF-DN] in the LSA Options field MUST be set. 💅 The point is that if any CE router sends that type 3 LSA back to a PE router, the PE router won't redistribute it again. No loops, bestie. 🔁

Now, when a PE router needs to give a CE router a route that came from a site outside that CE's OSPF domain, the PE acts like an ASBR (Autonomous System Border Router) 🧚 and sends the route in a type 5 LSA. The DN bit [OSPF-DN] MUST be set in these LSAs so that any other PE routers that receive them will ignore them. ✨

Here's the tea. Some deployed implementations don't set the DN bit at all. Instead, they use OSPF route tagging so that a type 5 LSA generated by a PE gets ignored by any other PE that receives it 🙈. The special tag for this is called the VPN Route Tag (see Section 4.2.5.2). For backward compatibility, every implementation following this specification MUST support the VPN Route Tag procedures by default, which are the ones in Sections 4.2.5.2, 4.2.8.1, and 4.2.8.2. 🫶 Once you don't need the VPN Route Tag in a particular deployment anymore, you can turn off its use (both sending and receiving) through configuration. 🌸

4.2.5.2. Use of OSPF Route Tags 🏷️

If a VRF on a PE is linked to an OSPF instance, then by default it MUST be configured with a special OSPF route tag value, which we call the VPN Route Tag. 👑 By default, that route tag MUST be included in the Type 5 LSAs the PE creates (because it received a BGP-distributed VPN-IPv4 route, see Section 4.2.8) and sends to any of its attached CEs.

Including the VPN Route Tag is required for backward compatibility with deployed implementations that don't set the DN bit in type 5 LSAs. 💖 You can turn off the inclusion of the VPN Route Tag by configuration if it's been figured out that it isn't needed for backward compatibility anymore.

The value of the VPN Route Tag is arbitrary, but it must be different from any OSPF Route Tag being used in the OSPF domain. 🎀 So its value MUST be configurable. If the Autonomous System number of the VPN backbone is two bytes long, the default value SHOULD be an automatically computed tag based on that Autonomous System number. Here's what that looks like:

Tag = <Automatic = 1, Complete = 1, PathLength = 01>

    0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|1|0|1|     ArbitraryTag      |       AutonomousSystem        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 _AS number of the VPN Backbone_

If the Autonomous System number is four bytes long, then a Route Tag value MUST be configured, and it MUST be different from any Route Tag used within the VPN itself. 🌈

If a PE router needs to use OSPF to give a CE router a route from a site outside that CE's OSPF domain, the PE SHOULD present itself to the CE as an Autonomous System Border Router (ASBR) and SHOULD report those routes as AS-external routes. ⭐ So these PE routers create Type 5 LSAs that report the extra-domain routes as AS-external routes. Each Type 5 LSA like that MUST contain an OSPF route tag whose value is the VPN Route Tag. That tag tells everyone the route came from a PE router. 🔥 The VPN Route Tag MUST be used so that a Type 5 LSA created by a PE router doesn't get redistributed through the OSPF area to another PE router. Main character energy for that tag, honestly. 👑

4.2.5.3. Other Possible Loops 🌀

The procedures in this document make sure that if routing information from a BGP-distributed VPN-IPv4 route gets distributed into OSPF, it can't be redistributed back into BGP as a VPN-IPv4 route, as long as the DN bit and/or VPN route tag is kept within the OSPF domain. 🫶 BUT (and this is important) it doesn't rule out every possible source of loops. 😭 For example, say a BGP VPN-IPv4 route gets distributed into OSPF, then into RIP (where all the info needed to prevent looping is lost), and then back into OSPF. In that case it could get distributed back into BGP as a VPN-IPv4 route, and boom, loop. 💀

So you have to be extremely careful about any mutual redistribution of routes between the OSPF domain and any third routing domain (that is, one that isn't the VPN backbone). 🙈 If the third routing domain is a BGP domain (like the public Internet), the normal BGP loop prevention measures will stop the route from getting back into the OSPF domain. 🧚

4.2.6. Handling LSAs from the CE 📨

This section explains how a PE router handles the OSPF LSAs it gets from a CE router. 💅

When a PE router receives any LSA from a CE router with the DN bit [OSPF-DN] set, the information from that LSA MUST NOT be used by the route calculation. 🚫 If a Type 5 LSA is received from the CE, and it has an OSPF route tag value equal to the VPN Route Tag (see Section 4.2.5.2), then the information from that LSA MUST NOT be used by the route calculation either.

Otherwise, the PE must check the corresponding VRF. For every address prefix that one of its associated OSPF instances installed in the VRF, the PE must create a VPN-IPv4 route in BGP. Each of those routes will have some of the following Extended Communities attributes:

The OSPF Domain Identifier Extended Communities attribute. If the OSPF instance that installed the route has a non-NULL primary Domain Identifier, this MUST be present. If that OSPF instance has only a NULL Domain Identifier, it MAY be omitted. This attribute is encoded with a two-byte type field, and its type is 0005, 0105, or 0205. For backward compatibility, the type 8005 MAY be used as well and is treated as if it were 0005. If the OSPF instance has a NULL Domain Identifier, and the OSPF Domain Identifier Extended Communities attribute is present, then the attribute's value field must be all zeroes, and its type field may be any of 0005, 0105, 0205, or 8005.
OSPF Route Type Extended Communities Attribute. This attribute MUST be present. It is encoded with a two-byte type field, and its type is 0306. To ensure backward compatibility, the type 8000 SHOULD be accepted as well and treated as if it were type 0306. The remaining six bytes of the Attribute are encoded like this:

+-------+-------+-------+-------+-------+-------+
|        Area Number            | Route |Options|
|                               | Type  |       |
+-------+-------+-------+-------+-------+-------+

Area Number: 4 bytes, encoding a 32-bit area number. For AS-external routes, the value is 0. A non-zero value identifies the route as being internal to the OSPF domain, and as being within the identified area. Area numbers are relative to a particular OSPF domain. 🗺️
OSPF Route Type: 1 byte, encoded as follows:
- 1 or 2 for intra-area routes (depending on whether the route came from a type 1 or a type 2 LSA).
- 3 for inter-area routes.
- 5 for external routes (area number must be 0).
- 7 for NSSA routes.

Note that the procedures of Section 4.2.8 don't make any distinction between route types 1, 2, and 3. If BGP installs a route of one of these types in the VRF, and that route gets picked for redistribution into OSPF, OSPF will advertise it in either a type 3 or a type 5 LSA, depending on the domain identifier. 🤓

Options: 1 byte. Right now, this is only used if the route type is 5 or 7. Setting the least significant bit in the field means the route carries a type 2 metric. ✨

OSPF Router ID Extended Communities Attribute. This OPTIONAL attribute specifies the OSPF Router ID of the system identified in the BGP Next Hop attribute. More precisely, it specifies the OSPF Router Id of the PE in the OSPF instance that installed the route into the VRF the route was exported from. This attribute is encoded with a two-byte type field, and its type is 0107, with the Router ID itself carried in the first 4 bytes of the value field. The type 8001 SHOULD be accepted as well, for backward compatibility, and should be treated as if it were 0107. 🎀
MED (Multi_EXIT_DISC attribute). By default, this SHOULD be set to the value of the OSPF distance associated with the route, plus 1. 🍓

The idea behind all of this is the following. OSPF routes from one site get converted to BGP, sent across the VPN backbone, and maybe converted back to OSPF routes before going into another site. 🦋 With these attributes, BGP carries enough info about the route that it can be turned back into OSPF "transparently," just as if BGP had never been involved. Iconic. 👑

Routes that a PE receives in type 4 LSAs MUST NOT be redistributed to BGP. 🙅‍♀️

The attributes described above come on top of any other attributes that routes must carry under [VPN]. 💜

The Site of Origin attribute, which [VPN] usually requires, is OPTIONAL for routes that a PE learns from a CE via OSPF. 🌸

Here's why that's optional. If a site is multiply homed (meaning it's attached to several PE routers), using the Site of Origin attribute would stop an intra-site route from being reinjected into the site from the VPN backbone. 🙈 That reinjection wouldn't actually hurt routing, because the route via the VPN backbone would be advertised in a type 3 LSA, so it would look like an inter-area route, and the real intra-area route would still win. But it would add unnecessary overhead. 😤 On the flip side, if the Site of Origin attribute isn't used, a partitioned site fixes itself automatically, because traffic from one partition to the other just travels via the VPN backbone. 🫶 So using a Site of Origin attribute is optional, which lets you trade off the extra overhead against the value of that automatic partition repair. ⚖️

4.2.7. Sham Links 🧚

This section describes the protocol and procedures needed to support "Sham Links," as defined here. Supporting sham links is an OPTIONAL feature of this specification. ✨

4.2.7.1. Intra-Area Routes

Okay, picture this: two sites in the same OSPF area, each hanging off a different PE router, plus an intra-area OSPF link directly connecting the two sites. 🧚

You can treat these two sites as a single VPN site that just happens to be multihomed to the backbone. Honestly, that's the simplest approach and totally adequate, as long as the preferred route between the two sites is the intra-area OSPF link (a "backdoor link") and not the VPN backbone. 🦋 Routes between sites will still go through the PE routers, but they'll look like inter-area routes, so OSPF will rank them below the intra-area routes over the backdoor link. Lowkey a clean setup. 💅

Now, if you want OSPF to prefer the backbone routes over the backdoor link, the backbone routes have to look like intra-area routes. ✨ To pull that off, it's necessary to make it look like there's an intra-area link connecting the two PE routers. That's what we call a "sham link" 🎀 (and if both sites attach to the same PE router, you don't need one at all, obviously 🙈).

A sham link is basically a relationship between two VRFs. Each VRF that's getting connected needs a "Sham Link Endpoint Address", which is a 32-bit IPv4 address treated as the address of the PE router holding that VRF. 🌸 This address lives in the VPN's address space, NOT the SP's address space, so don't mix those up, bestie. The Sham Link Endpoint Address for a VRF MUST be configurable. If the VRF is tied to just one OSPF instance, and that instance's PE router ID is an IP address, then the Sham Link Endpoint Address MAY default to that Router ID. If a VRF is tied to several OSPF instances, each sham link belongs to exactly one of them. 👑

For a given OSPF instance, a VRF only needs one Sham Link Endpoint Address, no matter how many sham links it has. ⭐ That address MUST be distributed by BGP as a VPN-IPv4 address whose IPv4 prefix part is 32 bits long. It MUST NOT be advertised by OSPF. And if there's no BGP route to the Sham Link Endpoint Address, that address is supposed to look unreachable, so the sham link looks down. Iconic behaviour, honestly. 💀

4.2.7.2. Creating Sham Links

Sham links are manually configured. 🛠️

For a sham link to exist between two VRFs, each VRF has to be configured to create a sham link to the other, where the "other" is identified by its sham link endpoint address. 💜 No more than one sham link with the same pair of sham link endpoint addresses will ever be created. This spec doesn't cover procedures for single-ended manual configuration of the sham link, so don't go looking for those here. 🙅‍♀️

Sham links can be created for any area, including area 0. 🌈

A sham link connecting two VRFs counts as up if and only if a route to the 32-bit remote endpoint address of the sham link has been installed in the VRF. ✨

The sham link endpoint address MUST NOT be used as the endpoint address of an OSPF Virtual Link. Keep those two separate, periodt. 💅

4.2.7.3. OSPF Protocol on Sham Links

An OSPF protocol packet sent over a sham link from one PE to another has to use the sender's Sham Link Endpoint Address as its IP source address, and the receiver's Sham Link Endpoint Address as its IP destination address. 🦋 The packet travels from one PE router to the other across the VPN backbone, so it can be expected to go through multiple hops. That means its TTL (Time to Live) field must be set appropriately. Main character energy. 🎀

An OSPF protocol packet counts as received on a particular sham link if and only if all three of these conditions hold:

The packet arrives as an MPLS packet, and its MPLS label stack causes it to be "delivered" to the local sham link endpoint address.
The packet's IP destination address is the local sham link endpoint address.
The packet's IP source address is the remote sham link endpoint address.

Sham links SHOULD be treated by OSPF as OSPF Demand Circuits. 🌸 So LSAs get flooded over them, but the periodic refresh traffic gets skipped. Here's the tea: as long as the backdoor link is up, flooding LSAs over the sham link doesn't really do anything. ☕ BUT if the backdoor link goes down, OSPF doesn't have mechanisms that let routers in one site quickly flush the LSAs from the other site. So the databases at the two sites still need to stay in sync, which is exactly why the flooding over the sham link is there. Not me being extra. 🫶

The sham link is an unnumbered point-to-point intra-area link, and it's advertised as a type 1 link in a type 1 LSA. 🧚

The OSPF metric for a sham link MUST be configurable, and there MUST be a configurable default too. 🔥 Whether traffic between the sites takes the backdoor link or the VPN backbone (i.e., the sham link) depends on the OSPF link metrics you set. For example, you can set the metrics so the backdoor link only gets used if connectivity through the VPN backbone fails. Chef's kiss. 🍓

The default Hello Interval for sham links is 10 seconds, and the default Router Dead Interval for sham links is 40 seconds. ⏱️

4.2.7.4. Routing and Forwarding on Sham Links

If a PE determines that the next hop interface for a particular route is a sham link, then the PE SHOULD NOT redistribute that route into BGP as a VPN-IPv4 route. 🙃

Any other route advertised in an LSA that's transmitted over a sham link MUST also be redistributed into BGP (the PE does this by flooding the LSA over the sham link). So if the preferred OSPF route for some address prefix has the sham link as its next hop interface, there will also be a "corresponding BGP route" for that same prefix installed in the VRF. 👑 Per Section 4.1.2, the OSPF route is the preferred one. Still, when forwarding a packet, if the preferred route for that packet has the sham link as its next hop interface, the packet MUST be forwarded according to the corresponding BGP route. It gets forwarded as if the corresponding BGP route had been the preferred route. 💖 The "corresponding BGP route" is always a VPN-IPv4 route, and the procedure for forwarding a packet over a VPN-IPv4 route is described in [VPN]. ✨

The same rule applies to any packet whose IP destination address is the remote endpoint address of a sham link. Those packets MUST be forwarded according to the corresponding BGP route. 🫶

4.2.8. VPN-IPv4 Routes Received via BGP

This section explains how the PE router handles VPN-IPv4 routes received via BGP. 📬

If a received BGP VPN-IPv4 route isn't installed in the VRF, nothing gets reported to the CE. 🤷‍♀️ A received route won't be installed in the VRF if the BGP decision process considers some other route preferable. Once it is installed, the route looks like an IPv4 route to the CE. 🌈

A BGP route installed in the VRF isn't necessarily the one used for forwarding. If an OSPF route for the same IPv4 address prefix has been installed in the VRF, the OSPF route gets used for forwarding, EXCEPT when that OSPF route's next-hop interface is a sham link. 👀

If a BGP route installed in the VRF is used for forwarding, then it gets redistributed into OSPF and possibly reported to the CEs in an OSPF LSA. Which kind of LSA, if any, gets generated depends on various characteristics of the BGP route, and the later sections of this document go through those details. 🦋

The procedure for forwarding a packet over a VPN-IPv4 route is described in [VPN]. 💅

Below is what the PE reports to the CE in OSPF LSAs. This assumes the PE isn't configured to do any further summarization or filtering of routing information before reporting it to the CE. 🎀

When sending an LSA to the CE, it may be necessary to set the DN bit. See Section 4.2.5.1 for the rules regarding the DN bit. 🌸

When sending an LSA to the CE, it may be necessary to set the OSPF Route Tag. See Section 4.2.5.2 for the rules about setting the OSPF Route Tag. 🧚

When type 5 LSAs are sent, the Forwarding Address is set to 0. 💜

4.2.8.1. External Routes ✨

Okay so, for a particular OSPF instance tied to a VRF, a VPN-IPv4 route counts as an External Route 💅 if it gets installed in the VRF, gets selected as the preferred route, AND one of these is true:

The route type field of the OSPF Route Type Extended Community has an OSPF route type of "external".
The route is from a different domain from the domain of the OSPF instance.

So how do we check if a route is from a different domain? 🤔 The OSPF Domain Identifier Extended Communities attribute carried by the route gets compared with the OSPF Domain Identifier Extended Communities attribute(s) the OSPF instance was configured with (if any). Generally, when you compare two of these, you have to look at all eight bytes. Two of them are only considered equal if one of these three things is true:

They're identical in all eight bytes.
They're identical in their lower-order six bytes (value field), but one has two high-order bytes (type field) of 0005 and the other has two high-order bytes (type field) of 8005. (This one is for backward compatibility, so it's giving legacy support 🕰️🫶)
The lower-order six bytes (value field) of both attributes are entirely zeroes. Here, the two attributes count as identical no matter what their type fields say, and they both represent the NULL Domain Identifier 🌈

If a VPN-IPv4 route has an OSPF Domain Identifier Extended Communities attribute, we say that route is in the identified domain ✨ If the value field of that Extended Communities attribute is all zeroes, then the identified domain is the NULL domain, and the route belongs to the NULL domain. And if the route doesn't have an OSPF Domain Identifier Extended Communities attribute at all, it belongs to the NULL domain too. Main character energy for the NULL domain, honestly 💀

Every OSPF instance is associated with one or more Domain Identifiers, though it might only be associated with the NULL domain identifier. If an OSPF instance is associated with a particular Domain Identifier, we'll say it belongs to the identified domain.

Now, if a VPN-IPv4 route is going to be redistributed into a particular instance, we have to figure out whether that route and that OSPF instance belong to the same domain. They do if and only if one of these is true:

The route and the OSPF instance each belong to the NULL domain.
The domain the route belongs to is the domain the OSPF instance belongs to. (In other words, the route's Domain Identifier is equal to the OSPF instance's domain identifier, using the definitions we just went over.)

If the route and the VRF don't belong to the same domain, the route gets treated as an external route 🦋

If an external route gets redistributed into an OSPF instance, the route may or may not be advertised to a particular CE. That depends on the configuration and on the type of area the PE/CE link belongs to. If the route does get advertised and the PE/CE link belongs to an NSSA area, it's advertised in a type 7 LSA. Otherwise, if it gets advertised, it's advertised in a type 5 LSA. The LSA will be originated by the PE.

The DN bit (Section 4.2.5.1) MUST be set in the LSA. Also, the VPN Route Tag (see Section 4.2.5.2) MUST be placed in the LSA, unless the use of the VPN Route Tag has been turned off by configuration. No skipping these, bestie 🙅‍♀️

By default, a type 2 metric value is included in the LSA, unless the options field of the OSPF Route Type Extended Communities attribute of the VPN-IPv4 route says the metric should be type 1.

By default, the metric value comes from the MED attribute of the VPN-IPv4 route. If the MED isn't present, a default metric value gets used. (The default type 1 metric and the default type 2 metric MAY be different. 🎀)

Note that this way of handling external routes makes every PE look like an ASBR attached to all the external routes 🧚 In a multihomed site, this can end up producing a bunch of type 5 LSAs that all contain the same information. Kinda extra, but that's just how it goes 🙈

4.2.8.2. Summary Routes

Okay, so if a route and the VRF it's imported into belong to the same domain, the route should be treated as if it had been received in an OSPF type 3 LSA. This means the PE will report the route to the CE in a type 3 LSA. 💖

(Quick side note: this case is possible even if the VPN-IPv4 route carries an area number identical to the one the CE router is in. So if an area gets "partitioned" such that the two pieces are connected only via the VPN backbone, it looks like two areas with inter-area routes between them. Wild, right? 😭)

4.2.8.3. NSSA Routes

NSSA routes are treated the same as external routes, as described in Section 4.2.8.1. Easy peasy 🌸

5. IANA Considerations 📋

[EXTCOMM] Section 11 calls on IANA to create a registry for BGP Extended Communities Type Field and Extended Type Field values. Section 4.2.6 of this document assigns new values for the BGP Extended Communities Extended Type Field. These values all fall within the range of values that [EXTCOMM] says "are to be assigned by IANA, using the 'First Come, First Served' policy defined in RFC 2434".

The BGP Extended Communities Extended Type Field values assigned in Section 4.2.6 of this document are as follows:

OSPF Domain Identifier: Extended Types 0005, 0105, and 0205.
OSPF Route Type: Extended Type 0306
OSPF Router ID: Extended Type 0107

6. Security Considerations 🔥

Security considerations that are relevant in general to BGP/MPLS IP VPNS are discussed in [VPN] and [VPN-AS]. We only discuss here the security considerations that are specific to using OSPF as the PE/CE protocol.

A single PE may be running OSPF as the IGP of the SP backbone network, and also running OSPF as the IGP of one or more VPNs. This requires the use of multiple, independent OSPF instances, so routes aren't accidentally leaked between the backbone and any VPN. The OSPF instances for different VPNs also have to be independent OSPF instances, so routes don't get leaked between VPNs by mistake. 🚫

OSPF provides a number of procedures that allow the OSPF control messages between a PE and a CE to be authenticated. OSPF "cryptographic authentication" SHOULD be used between a PE and a CE. It MUST be implemented on each PE. 🔐

Without that authentication, the CE might not really belong to the VPN the PE assigns it to. An attacker might also be able to insert spoofed messages on the PE/CE link, in either direction. Spoofed messages sent to the CE could mess up the routing at the CE's site. Spoofed messages sent to the PE could result in improper VPN routing, or a denial-of-service attack on the VPN. Yikes 😱 So yeah, don't skip the auth!!

7. Acknowledgements 💜

Major contributions to this work were made by Derek Yeung and Yakov Rekhter. 🫶

Thanks to Ross Callon, Ajay Singhal, Russ Housley, and Alex Zinin for their review and comments. 🌷

8. Normative References 📚

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

[OSPFv2]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[OSPF-DN] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a Link
          State Advertisement (LSA) Options Bit to Prevent Looping in
          BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4576,
          June 2006.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

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

9. Informative References 🦋

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

[RIP]     Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
          1998.

[VPN-AS]  Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual
          Private Networks (VPNs)", RFC 4365, February 2006.

Authors' Addresses 🎀

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

EMail: erosen@cisco.com


Peter Psenak
Cisco Systems
BA Business Center, 9th Floor
Plynarenska 1
Bratislava 82109
Slovakia

EMail: ppsenak@cisco.com


Padma Pillay-Esnault
Cisco Systems
3750 Cisco Way
San Jose, CA 95134

EMail: ppe@cisco.com

Full Copyright Statement 📜

Copyright (C) The Internet Society (2006).

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

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🌈

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

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

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

Acknowledgement 🌸

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).

📦 where this page comes from

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