RFC 6565
OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol
OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol 🦋
RFC 6565 ✨ the title block tea:
- Document: RFC 6565, from the IETF (Internet Engineering Task Force) 💖
- Category: Standards Track 🏆
- ISSN: 2070-1721
- Date: June 2012 📅
- Authors: P. Pillay-Esnault (Cisco Systems), P. Moyer (Pollere, Inc.), J. Doyle (Jeff Doyle and Associates), and E. Ertekin and M. Lundberg (Booz Allen Hamilton) 🫶
- Obsoletes / Updates: this header doesn't list anything it obsoletes or updates 🙈
Abstract 💜
okay so lots of Service Providers (SPs) sell Virtual Private Network (VPN) services, and the way they do it is that Customer Edge (CE) routers become routing peers of Provider Edge (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 packets across that backbone 🚇. IPv4 and IPv6 VPNs both already have support, but the only PE-CE protocol that's specified is Open Shortest Path First version 2 (OSPFv2) 😭. This document extends those specs so OSPF version 3 (OSPFv3) can be a PE-CE routing protocol too 💅. Honestly the OSPFv3 PE-CE stuff is basically the same as OSPFv2, except for the differences this document spells out 🎀.
Status of This Memo 📜
This one is an Internet Standards Track document 🏆.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) ✨. If you want more on Internet Standards, check out Section 2 of RFC 5741 🧚.
Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc6565 🔗.
Copyright Notice 🌈
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 💖.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please actually read these, bestie, because they describe your rights and restrictions for this document 🙈. Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 📜.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭. So unless you get an adequate license from whoever controls the copyright in those materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍.
Table of Contents 🗂️
1. Introduction ....................................................4
2. Specification of Requirements ...................................4
3. Requirements ....................................................4
3.1. OSPFv3 Specificities .......................................5
4. BGP/OSPFv3 Interaction Procedures for PE Routers ................5
4.1. VRFs and OSPFv3 Instances ..................................5
4.1.1. Independent OSPFv3 Instances in PEs .................6
4.1.2. OSPFv3 Domain Identifier ............................6
4.2. OSPFv3 Areas ...............................................7
4.3. VRFs and Routes ............................................7
4.3.1. OSPFv3 Routes on PEs ................................8
4.3.2. VPN-IPv6 Routes Received from MP-BGP ................9
4.4. BGP Extended Communities Attribute ........................12
4.5. Loop Prevention Techniques ................................14
4.5.1. OSPFv3 Down Bit ....................................15
4.5.2. Other Possible Loops ...............................15
5. OSPFv3 Sham Links ..............................................15
5.1. Creating a Sham Link ......................................16
5.2. OSPF Protocol on Sham Link ................................16
5.3. OSPF Packet Forwarding on Sham Link .......................17
6. Multiple Address Family Support ................................17
7. Security Considerations ........................................18
8. IANA Considerations ............................................18
9. Acknowledgments ................................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................191. Introduction ✨
okay so [RFC4364] gives Service Providers (SPs) a way to offer Layer 3 Virtual Private Network (VPN) services to the customer networks hanging off them 💁. Using the procedures in [RFC4364], Provider Edge (PE) routers split customer VPN routing info into Virtual Routing and Forwarding (VRF) tables 🗂️. Then the Border Gateway Protocol (BGP) spreads those customer VPN routes between the PE VRFs that are configured in the same VPN 🚀.
The original BGP/MPLS IP VPN spec let PE routers learn routes inside customer sites either through static routing or through a dynamic routing protocol running on the PE-CE link 🧠. To be specific, [RFC4364] (and its predecessor, [RFC2547]) supported dynamic routing protocols like BGP, RIP, and OSPFv2 💖. Then the OSPFv2 as the Provider/Customer Edge Protocol spec [RFC4577] updated how OSPFv2 works as the PE-CE routing protocol 🔥. It added more extensions so that OSPFv2-based customer sites can have intra-domain routing connectivity between each other 🫶.
[RFC4364] was written for IPv4 networks, but [RFC4659] brings support to IPv6 VPNs 🌈. It's expected that OSPFv3 will be the IGP for some IPv6 VPNs, the same way OSPFv2 was used for IPv4 VPNs 👑. The perks of using OSPFv3 as a PE-CE protocol are the same as for the IPv4 VPN setup ✨.
This document defines the mechanisms needed to make OSPFv3 work as the PE-CE routing protocol 🎀. To do that, it reuses methods defined in [RFC4659] and [RFC4577], and extends them where necessary 💅. It also includes the specs for keeping intra-domain routing connectivity between OSPFv3-based customer sites across an SP backbone 🦋.
We presuppose familiarity with the contents of [RFC4364], [RFC4659], [RFC4577], [RFC4576], [RFC5340], and [RFC2328] 📚. So go read those first, babe 🙈.
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] 📜.
3. Requirements 🍓
The benefits and considerations of deploying OSPFv3 as the PE-CE routing protocol are pretty similar to what [RFC4577] describes 💖. The requirements in Section 3 of [RFC4577] stay semantically identical for deploying OSPFv3 ✨.
[RFC5340] describes the changes OSPF needs to support IPv6 🌸. In that spec, a lot of the core OSPFv2 mechanisms stay the same for OSPFv3 🫶. So honestly, OSPFv3 as the PE-CE protocol works super similarly to OSPFv2 as the PE-CE protocol 💅.
3.1. OSPFv3 Specificities 🧚
Section 2 of [RFC5340] covers the differences between OSPFv3 and OSPFv2 🔍. A few of those changes are going to require modifications to the architecture in [RFC4577] 🥺. Here's how those differences hit [RFC4577]:
New LSA types:
For an IPv6 VPN architecture where customers connect with providers through OSPFv3, the usual BGP/OSPF interactions say that VPN-IPv6 reachability info redistributed into OSPFv3 gets expressed as AS-External OSPFv3 LSAs 📦. But instead, it may be desirable to view those LSAs as inter-area-prefix LSAs 🤔. The OSPF Route Type Extended Communities attribute defined in [RFC4577] is extended to include OSPFv3 route types 🌈. These new encodings are defined in Section 4.4 ✨.
Multiple instances over a link:
OSPFv3 runs on a per-link basis, while OSPFv2 runs on a per-IP-subnet basis 🔗. Supporting multiple OSPFv3 protocol instances on a link changes the architecture in [RFC4577] 🫠. [RFC4577] says each interface belongs to no more than one OSPF instance 🙅. For OSPFv3, though, multiple instances can be set up over a single interface and associated with the same VRF 💖.
On top of multiple OSPFv3 instances over a single PE-CE link, multiple OSPFv3 instances can also be set up across a sham link 🦋. This lets multiple OSPFv3 instances associated with a VRF independently build intra-area connectivity to other OSPFv3 instances attached to a remote PE VRF 💜. Section 5 covers how multiple OSPFv3 instances work across the sham link 📖.
4. BGP/OSPFv3 Interaction Procedures for PE Routers 👑
4.1. VRFs and OSPFv3 Instances 🎀
Here's the deal with how VRFs, interfaces, and OSPFv3 instances relate to each other on a PE router 💅.
As [RFC4364] defines, a PE router can be configured with one or more VRFs 🗂️. Each VRF on the PE matches a customer VPN and holds the destinations reachable within that VPN 🌸. Each VRF can be associated with one or more interfaces, which lets multiple sites join the same VPN 🫶. If OSPFv3 is instantiated on an interface associated with a VRF, that VRF gets populated with OSPFv3 routing info ✨.
Since OSPFv3 supports multiple instances on a single interface, multiple customer sites can totally connect to the same PE interface (say, through a Layer 2 switch) using distinct OSPFv3 instances 🍓. A PE interface can be associated with only one VRF, and every OSPFv3 instance running on that same interface MUST be associated with that same VRF 🙅. Configurations where a PE interface is associated with multiple VRFs are out of scope for this document 🚫.
4.1.1. Independent OSPFv3 Instances in PEs
okay so like [RFC4577] says, the PE must associate at least one OSPFv3 instance for each OSPFv3 domain it attaches to, and each instance of OSPFv3 MUST be associated with a single VRF 🎀
supporting multiple PE-CE OSPFv3 instances on one PE interface does NOT change the paradigm that an OSPF instance can only be associated with a single VRF 🙅♀️ and for each instance on that interface, the PE sets up adjacencies with the matching CEs tied to that instance 🤝 ngl this is so organized. note that even if multiple instances populate a common VRF, they don't leak routes to each other unless you configure them to 🔒✨
4.1.2. OSPFv3 Domain Identifier
the OSPFv3 Domain ID tells you which administrative domain the OSPF instance that originated the route belongs to 🏰 it has AS-wide significance and it's one of the things used to decide whether a VPN-IPv6 route gets translated into an Inter-area-prefix LSA or an External LSA 🧚 each OSPFv3 instance MUST have a primary Domain ID, and that ID rides along with the VPN-IPv6 route in a BGP attribute over the VPN backbone 🚐 each instance may also have a set of secondary Domain IDs that apply to other OSPFv3 instances inside its administrative domain 💜
the primary Domain ID can either be configured or be set to NULL 🫧 secondary Domain IDs are only allowed if a non-NULL primary Domain ID is configured ⚠️ and the Domain ID MUST be configured on a per-OSPFv3 instance basis 💅
the Domain ID is how a receiving OSPFv3 instance checks whether an incoming VPN-IPv6 route is from the same domain as itself 👀 a route counts as the same domain if a non-NULL incoming Domain ID matches either the local primary or one of the local secondary Domain IDs 💖 and if the local Domain ID and the incoming Domain ID are both NULL, that's a match too 🌸
4.2. OSPFv3 Areas
sections 4.1.4 and 4.2.3 of [RFC4577] describe what a PE router looks like inside an OSPFv2 domain 🦋 and the mechanisms and expected behavior in [RFC4577] also apply to an OSPFv3 domain 🙌
4.3. VRFs and Routes
from the CE's point of view, the PE just looks like any other OSPFv3 neighbor 🫶 the CE doesn't need to support any IPv6 BGP/MPLS VPN mechanisms or be aware of VPNs at all, which means any OSPFv3 implementation can be used on a CE 🎀 literally so chill
because the export and import policies might install different routes in different VRFs of the same OSPFv3 domain, the VPN backbone can't be treated as one single router from the domain's CEs' perspective 🧩 instead, each CE should view its connected PE as a separate router 🌈
the PE uses OSPFv3 to distribute routes to CEs, and uses MP-BGP [RFC4760] to distribute VPN-IPv6 routes to other (remote) PE routers as defined in [RFC4659] 📡 an IPv6 prefix installed in the VRF by OSPFv3 becomes a VPN-IPv6 prefix once you add an 8-octet Route Distinguisher (RD), as discussed in Section 2 of [RFC4659] 🪄 that VPN-IPv6 route can then get redistributed into MP-BGP according to an export policy that adds a Route Target (RT) Extended Communities attribute to the Network Layer Reachability Information (NLRI) [RFC4360] 💌
Domain IDs are how OSPFv3 instances get told apart 🕵️♀️ when an OSPFv3 distributed route is redistributed into MP-BGP, the Domain ID, OSPFv3 Router ID, Area, OSPFv3 Route Type, and Options fields (External Route Type) get carried along in Extended Community Attributes of the MP-BGP route 🎁
when a PE gets a VPN-IPv6 NLRI from MP-BGP, it uses an import policy to decide, based on the RT, whether the route is even eligible to go into one of its local VRFs 🚪 the BGP decision process then picks which of the eligible routes actually get installed in the associated VRF, and the selected VPN-IPv6 routes are turned back into IPv6 routes by removing the RD before installation 🧼
an IPv6 route learned from MP-BGP and installed in a VRF might or might not be redistributed into OSPFv3, depending on local configuration 🎛️ for example, the PE might be set up to advertise only a default route to the CEs of one particular OSPFv3 instance 🏠 and if the route is going to be redistributed into multiple OSPFv3 instances, it might be advertised using different LSA types in different instances 🧃
if an IPv6 route learned from MP-BGP is going to be redistributed into a particular OSPFv3 instance, the OSPF Domain Identifier Extended Communities attribute of the VPN-IPv6 route is what tells you whether the OSPFv3 instance the route came from is the same as the one it's heading into 🔍✨
4.3.1. OSPFv3 Routes on PEs
VRFs can be populated by both OSPFv3 routes from a CE and VPN-IPv6 routes from other PEs via MP-BGP 🌊 OSPFv3 routes get installed in a VRF using the OSPFv3 decision process 🧠 they can be redistributed into BGP and disseminated to the other PEs participating in the VPN 📣 over at those remote PEs, the VPN-IPv6 routes may be imported into a VRF and redistributed into the OSPFv3 instance(s) associated with that VRF 🫧
as specified in [RFC4659], routes imported and exported into a VRF are controlled by the Route Target (RT) Extended Communities attribute 🎯 OSPFv3 routes that get redistributed into BGP are given an RT that corresponds to the VRF 🏷️ that RT gets examined at remote PEs 👀 to import a route, a VRF must have an import RT that is identical to the route's RT 💯 and for routes eligible to be imported into the VRF, the standard BGP decision process picks the "best" route(s) 👑
when a route is advertised from a CE to a PE via OSPFv3 and that route gets installed in the VRF associated with that CE, the route is advertised to other locally attached CEs under normal OSPFv3 procedures 🏘️
the route also gets redistributed into MP-BGP to be advertised to remote PEs 🚀 the info needed for accurate redistribution back into OSPFv3 by those remote PEs is carried in the OSPF Route Type, OSPF Domain ID, and OSPF Router ID Extended Communities attributes (Section 4.4) 🎀 the relevant local OSPFv3 info encoded into these attributes is as follows:
- The Area ID of the PE-CE link.
- The Route Type, as determined by the LSA type from which the route was learned.
- The Options fields (External metric-type).
- The Domain ID of the OSPFv3 process. If no Domain ID is configured, the
NULLidentifier is used. - The PE's Router ID associated with the OSPFv3 instance.
a Multi-Exit-Discriminator (MED) attribute SHOULD also be set to the value of the OSPFv3 metric associated with the route plus 1, when the OSPFv3 route is redistributed into the MP-BGP 📏💖
4.3.2. VPN-IPv6 Routes Received from MP-BGP
when a PE receives a valid VPN-IPv6 route from MP-BGP and has identified an association with a local VRF, it must determine three things 🧐
- whether a route to the corresponding IPv6 prefix is to be installed in the VRF;
- whether the installed IPv6 route is to be redistributed to one or more local OSPFv3 instances; and
- what OSPFv3 LSA type is to be used when advertising the route into each OSPFv3 instance.
an IPv6 route derived from a received VPN-IPv6 route is NOT installed in the associated local VRF if either of these is true 🙅♀️
- the BGP decision process identifies a better route to the destination NLRI; or
- a configured import policy prohibits the installation of the route.
the PE advertises the IPv6 route learned from MP-BGP to attached CEs via OSPFv3 if all of these are true 💅
- no configured filtering prohibits redistributing the route to OSPFv3;
- no configured policy blocks the route in favor of a less-specific summary route; and
- redistribution of a BGP learned IPv6 route into OSPF is based on local policy.
the next sections talk about advertising routes learned from MP-BGP and the rules for deciding which LSA types and which CEs get the routes 🗺️
when the PE sends an LSA to a CE, it sets the DN-bit in the LSA to prevent looping 🔁 (more on the DN-bit in Section 4.5.1 🧚)
4.3.2.1. OSPF Inter-Area Routes
a PE advertises an IPv6 route using an Inter-Area-Prefix (type 0x2003) LSA under the following circumstances 🌈
- the OSPFv3 domain the IPv6 route was learned from is the same (as determined by the Domain ID) as the domain of the OSPFv3 instance it's being redistributed into; and
- the IPv6 route was advertised to a remote PE in an Intra-Area-Prefix (type
0x2009) OR an Inter-Area-Prefix (type0x2003) LSA.
note that under these rules, the PE represents itself as an Area Border Router (ABR) 🏗️ no matter whether or not the route is advertised into the same area number the remote PE learned it from (that is, whether the VPN-IPv6 route carries the same or different area numbers) 🤷♀️
4.3.2.2. OSPF Intra-Area Route
a route is advertised as an intra-area route using an Intra-Area-Prefix (type 0x2009) LSA ONLY when sham links are used, as described in Section 5 🪞 otherwise, routes are advertised as either inter-area (Section 4.3.2.1) or external / Not-So-Stubby Area (NSSA) (Section 4.3.2.3) routes 🦋
4.3.2.3. OSPF External Routes and NSSA Routes ✨
okay so a PE counts an IPv6 route as external in any of these situations 💅
- The OSPFv3 domain the route was learned from is different (going by the Domain ID) from the domain of the OSPFv3 instance it's being redistributed into; or
- The OSPFv3 domain the route was learned from is the same as the domain of the OSPFv3 instance it's being redistributed into, AND it was advertised to the remote PE in an AS-External-LSA (type 0x4005) or an NSSA-LSA (type 0x2007); or
- The route was not learned from an OSPFv3 instance.
to figure out if the learned route came from a different domain, we compare the Domain ID attached to the VPN-IPv6 route (in the OSPF Domain ID Extended Communities attribute or attributes) with the local OSPFv3 Domain ID, if one is configured 🔍 two Domain IDs count as identical if:
- All 8 bytes are identical; or
- Both Domain IDs are NULL (all zeroes).
⚠️ if the VPN-IPv6 route has no Domain ID in its attributes, OR the local OSPFv3 instance has no configured Domain ID (either one, or both), the route is treated as having a NULL Domain ID.
an IPv6 route that gets marked as external might or might not be advertised to a connected CE 🤷♀️ it depends on what kind of area the PE-CE link is in and whether there's a configured policy blocking it.
if there are multiple external routes for the same prefix, the standard OSPFv3 decision process picks the "best" one 👑
when the external route is going to be advertised and the PE-CE link's area type is NSSA, the PE sends it in an NSSA-LSA (type 0x2007). otherwise it goes out in an AS-External-LSA (type 0x4005) 🦋
the DN-bit MUST be set in the LSA that advertises the external route, as described in Section 4.5.1. non-negotiable, bestie 🫶
if the VPN-IPv6 route carries a route Type-1 metric, the PE should advertise the external route with that metric-type. if it doesn't, the external IPv6 route's metric-type defaults to Type-2 🎀 and by default, a PE should advertise an external route with a Type-2 metric when the IPv6 route's Domain ID is different from the local OSPFv3 instance's, unless local policy says otherwise 💜
4.4. BGP Extended Communities Attributes 🌸
OSPFv3 routes from one site get translated and delivered to the far side as BGP VPN-IPv6 routes, totally transparently 🦋 the original OSPFv3 routes carry OSPFv3-specific info that has to make it across too, so the receiving side can rebuild a database just like it does in the OSPFv2 case. that's where BGP Extended Communities come in 💖
every OSPFv3 route that gets added to a VRF routing table on a PE is checked so a matching VPN-IPv6 route can be made in BGP. each of those OSPFv3 routes MUST have BGP Extended Communities Attributes that hold and preserve the OSPFv3 info from the original route. the BGP Extended Communities attributes defined in [RFC4577] get reused here, because why reinvent the wheel 🙌
OSPF Domain Identifier Extended Communities Attribute ✨
each OSPFv3 Instance within a VRF MUST have a Domain ID. the Domain ID gets configured per OSPFv3 Instance. it's a 6-byte number, and its default value is 0. this attribute has a 2-byte type field, encoded with a value of 0x0005, 0x0105, or 0x0205.
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Value | Domain Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Identifier Cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPF Domain Identifier Extended Communities AttributeOSPFv3 Domain IDs field : 6 bytes 🧚
each OSPFv3 Instance within a VRF MUST have a Domain ID, and if none is configured, its default value is 0. the Domain ID is configured per OSPFv3 Instance.
OSPF Router ID Extended Communities Attribute 🍓
the OSPFv3 Router ID is a 32-bit number, same as in OSPFv2. this attribute has a 2-byte type field, encoded with a value of 0x0107.
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Value | Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID Cont. | UNUSED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPF Router ID Extended Communities AttributeOSPFv3 Router ID field : 4 bytes 💅
the OSPFv3 Router ID is a 32-bit number, same as in OSPFv2. setting this field is OPTIONAL, and its default value is 0.
OSPF Route Type Extended Communities Attribute 🔥
the OSPF Route Type Extended Communities Attribute MUST be present 👑 it has a 2-byte type field, encoded with a value of 0x0306. the other 6 bytes split into 3 fields: an Area Number, a Route Type, and an Options field.
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Value | Area Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area Number Cont. | Route Type | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPF Route Type Extended Communities AttributeArea Number : 4 bytes 🌈
the area number is the 32-bit Area ID that the route belongs to.
Route Types : 1 byte 🦋
to fit the OSPFv3 LSA types (as registered by [RFC5340]), the Route Type field is encoded like this:
Route Type Route Type LSA Type Description
Code
-----------------------------------------------------------
3 Inter-area-prefix 0x2003 Inter-Area-Prefix-LSA
5 External 0x4005 AS-External-LSA
7 NSSA 0x2007 NSSA-LSA
1 or 2 Intra-area-prefix 0x2009 Intra-Area-Prefix-LSA
Route Type Field EncodingOptions : 1 byte ✨
the Options field tells you which options go with the OSPFv3 route.
8 7 6 5 4 3 2 1
+---+---+---+---+---+---+---+---+
| | | | | | | | E |
+---+---+---+---+---+---+---+---+
The OSPFv3 Route Options Fieldthe least significant bit (bit E) in this field is the external metric-type flag 🔢 if the bit is clear, the route carries a Type-1 external metric. if the bit is set, the route carries a Type-2 external metric.
4.5. Loop Prevention Techniques 🔁
sometimes routing loops can happen in certain topologies, because of how reachability info gets passed around. a classic example is a dual-homed CE router connected to two PEs. those PEs learn about reachability both through their CE and through their peer PE 😭 and since OSPFv3 routes get transported transparently over the VPN backbone, the PEs can't tell whether they're inside a loop.
the loop scenarios in OSPFv3 topologies are the same as the ones in the OSPFv2 topologies described in Sections 4.2.5.1 and 4.2.5.2 of [RFC4577]. out of the two loop prevention mechanisms covered in those sections, only the DN-bit option gets supported in the OSPFv3 implementation 💖
4.5.1. OSPFv3 Down Bit 🙈
[RFC4576] describes how the DN-bit is used for OSPFv2, and it applies to OSPFv3 for Inter-area-prefix LSAs, NSSA LSAs, and External LSAs. the DN-bit MUST be set in Inter-area-prefix LSAs, NSSA LSAs, and AS-External LSAs that get originated from a PE to a CE, so those prefixes don't get re-advertised into BGP. as in [RFC4577], any LSA with the DN-bit set must not be used for route calculations on PE routers 🚫
the DN-bit MUST be clear in all other LSA types. the OSPFv3 DN-bit format is described in Appendix A.4.1.1 of [RFC5340] 🧠
4.5.2. Other Possible Loops 💀
the mechanism in Section 4.5.1 of this document is enough to prevent looping, as long as the DN-bit info attached to a prefix is kept inside the OSPF domain. as described in Section 4.2.5.3 of [RFC4577], you have to be careful if mutual redistribution on a PE ends up losing loop prevention info 👀
5. OSPFv3 Sham Links ✨
okay so this section is where we tweak OSPFv2 sham links (from Section 4.2.7 of [RFC4577]) so they work with OSPFv3 💖. supporting OSPFv3 sham links is an OPTIONAL feature 🎀, so you don't have to do it, but here's how it works if you do.
a sham link lets a VPN backbone act like an intra-area link 🦋. it's needed when two sites are connected by an intra-area "backdoor" link and the inter-area VPN backbone route would be less preferable because of OSPF route preference rules 😭. the figure below shows a sham link between two VPN sites:
(VPN backbone)
(site-1) <-------- sham link --------> (site-2)
CE1 -------- PE1 -------- P ---------- PE2 -------- CE2
| |
|___________________________________________________|
<------------ backdoor link -------------->
(OSPF intra-area link)
Sham Linkmost of how sham links work is the same as before 🌸, but there are a few differences we need to define so OSPFv3 sham links actually work properly 💅.
one of the big differences from the [RFC4577] sham links is when multiple OSPFv3 instances fill up a VRF 👑. you might want separate intra-area links between these instances over the same sham link. to do that, multiple OSPFv3 instances can be set up across the PE-PE sham link, giving intra-area connectivity between the PE-CE OSPFv3 instances 🧚.
quick note: even though multiple OSPFv3 instances can be tied to a VRF, a sham link is still thought of as a relation between two VRFs 🍓.
another change from OSPFv2 sham links is that OSPFv3 sham links are identified by 128-bit endpoint addresses 🌈. since those endpoint addresses are now 128 bits, they can't default to the RouterID anymore, because the RouterID is a 32-bit number 😩. sham link endpoint addresses MUST be configured 🫶.
sham link endpoint addresses MUST be distributed by BGP as routeable VPN IPv6 addresses, each with an IPv6 address prefix that is 128 bits long 💜. as Section 4.2.7.1 of [RFC4577] says, these endpoint addresses MUST NOT be advertised by OSPFv3. if there's no BGP route to the sham link endpoint address, that address shows up as unreachable, so the sham link looks down 💀.
if there is a BGP route to the remote sham link endpoint address, the sham link looks up ✨. and if there's no BGP route to the sham link endpoint address, it looks down. no cap, it's that simple 🙈.
5.1. Creating a Sham Link
creating an OSPFv3 sham link works exactly like Section 4.2.7.2 of [RFC4577] describes 💖. just keep in mind that you need to configure both the local and remote 128-bit sham link endpoint addresses 🎀. the local sham link endpoint address tied to a VRF MAY be used by all OSPFv3 instances attached to that VRF 🦋. and the OSPFv3 PE-PE "link" Instance ID in the protocol packet header is what demultiplexes the multiple OSPFv3 instance protocol packets exchanged over the sham link 🧚.
5.2. OSPF Protocol on Sham Link
running OSPFv3 over a sham link is semantically the same as running OSPFv2 over one, as Section 4.2.7.3 of [RFC4577] explains 🌸. that covers how OSPFv3 packets are sent and received over sham links, plus the Hello/Router Dead Intervals 💅. the sham link metric assignment procedures also follow what OSPFv2 uses 👑. OSPFv3 sham links are treated as on-demand circuits 🍓.
even though OSPFv3 works the same as OSPFv2 here, you can set up multiple OSPFv3 instances across this one link 🌈. then you get distinct intra-area connections between the PE-PE OSPFv3 instances tied to the endpoint addresses 😭.
here's an example. say two OSPFv3 instances (O1, O2) attach to a VRF V1, and on a remote PE, two other OSPFv3 instances (O3, O4) attach to a VRF V2 🫶. you might want O1 and O3 on one intra-area link, and O2 and O4 on another. you can make that happen by setting up two OSPFv3 instances across the sham link that connects V1 and V2 ✨. then O1 and O3 map to one sham link OSPFv3 instance, and O2 and O4 map to the other 💖.
5.3. OSPF Packet Forwarding on Sham Link
the route redistribution rules from Section 4.2.7.4 of [RFC4577] stay the same in this spec 🎀. specifically:
If 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-IPv6 route. Any other route advertised in an LSA that is transmitted over a sham link MUST also be redistributed (by the PE flooding the LSA over the sham link) into BGP.
when those LSAs get redistributed into BGP, they're encoded with the BGP Extended Communities Attributes, as defined in Section 4.4 of this document 🦋.
and when forwarding a packet, if the preferred route for that packet has the sham link as its next-hop interface, then the packet MUST be forwarded according to the corresponding BGP route (as defined in [RFC4364] and [RFC4659]) 💅.
6. Multiple Address Family Support 🌈
OSPFv3 supports multiple address families (AFs), and that's described in [RFC5838] 🧚. [RFC5838] tells the AFs apart by using reserved ranges of Instance IDs for each AF 🍓.
the architecture in this document is fully compatible with [RFC5838] 💜. the OSPFv3 PE-CE protocol can support multiple address families across a VPN backbone 👑. all AFs redistributed from OSPFv3 into BGP on a PE MUST contain the BGP Extended Communities Attributes, as described in Section 4.4 🫶.
7. Security Considerations 💀
the extensions in this document are specific to using OSPFv3 as the PE-CE protocol 😭. they don't add any new security concerns beyond the ones already covered in Section 6 of [RFC4577] 🙈. so you're covered as long as you follow what's already there 🔥.
8. IANA Considerations 🌸
an early version of this document led to the allocation of the OSPFv3 Route Attributes (0x0004) entry in the BGP IPv6 Address Specific Extended Community 💖. that allocation is no longer needed 😅. IANA has marked the OSPFv3 Route Attributes (0x0004) entry in the BGP IPv6 Address Specific Extended Community registry as deprecated 🥀. the BGP Extended Communities Attributes in this document have already been registered by IANA ✨.
9. Acknowledgments 🫶
the authors want to thank Kelvin Upson, Seiko Okano, Matthew Everett, Dr. Vineet Mehta, Paul Wells, and Marek Karasek for their support of this work 💕. thanks also to Peter Psenak, Abhay Roy, Acee Lindem, Nick Weeds, Robert Hanzl, and Daniel Cohn for their Last Call comments 📣. special thanks to Stewart Bryant, Stephen Farrel, and Fred Baker for their thorough review 👑🎀.
10. References 📚
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4576] 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.
[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the
Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4577, June 2006.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, September 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
[RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
R. Aggarwal, "Support of Address Families in OSPFv3", RFC
5838, April 2010.10.2. Informative References
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March
1999.Authors' Addresses 🎀
Padma Pillay-Esnault
Cisco Systems
510 McCarty Blvd.
Milpitas, CA 95035
USA
EMail: ppe@cisco.com
Peter Moyer
Pollere, Inc.
325M Sharon Park Drive #214
Menlo Park, CA 94025
USA
EMail: pete@pollere.net
Jeff Doyle
Jeff Doyle and Associates
9878 Teller Ct.
Westminster, CO 80021
USA
EMail: jdoyle@doyleassociates.net
Emre Ertekin
Booz Allen Hamilton
5220 Pacific Concourse Drive
Los Angeles, CA 90045
USA
EMail: ertekin_emre@bah.com
Michael Lundberg
Booz Allen Hamilton
8283 Greensboro Drive
McLean, VA 22102
USA
EMail: lundberg_michael@bah.com📦 where this page comes from
- ietf: rfc6565 2012-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms