From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6565.txt | 1123 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1123 insertions(+) create mode 100644 doc/rfc/rfc6565.txt (limited to 'doc/rfc/rfc6565.txt') diff --git a/doc/rfc/rfc6565.txt b/doc/rfc/rfc6565.txt new file mode 100644 index 0000000..a95da3d --- /dev/null +++ b/doc/rfc/rfc6565.txt @@ -0,0 +1,1123 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Pillay-Esnault +Request for Comments: 6565 Cisco Systems +Category: Standards Track P. Moyer +ISSN: 2070-1721 Pollere, Inc. + J. Doyle + Jeff Doyle and Associates + E. Ertekin + M. Lundberg + Booz Allen Hamilton + June 2012 + + + OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol + +Abstract + + Many Service Providers (SPs) offer Virtual Private Network (VPN) + services to their customers using a technique in which Customer Edge + (CE) routers are routing peers of Provider Edge (PE) routers. The + Border Gateway Protocol (BGP) is used to distribute the customer's + routes across the provider's IP backbone network, and Multiprotocol + Label Switching (MPLS) is used to tunnel customer packets across the + provider's backbone. Support currently exists for both IPv4 and IPv6 + VPNs; however, only Open Shortest Path First version 2 (OSPFv2) as + PE-CE protocol is specified. This document extends those + specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing + protocol. The OSPFv3 PE-CE functionality is identical to that of + OSPFv2 except for the differences described in this document. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6565. + + + + + + + + + +Pillay-Esnault, et al. Standards Track [Page 1] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + +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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided 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 person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such 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, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Pillay-Esnault, et al. Standards Track [Page 2] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + +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 ...................................19 + + + + + + + + + + + + + + + + + + + + + + +Pillay-Esnault, et al. Standards Track [Page 3] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + +1. Introduction + + [RFC4364] offers Service Providers (SPs) a method for providing Layer + 3 Virtual Private Network (VPN) services to subtending customer + networks. Using the procedures defined in [RFC4364], Provider Edge + (PE) routers separate customer VPN routing information into Virtual + Routing and Forwarding (VRF) tables. The Border Gateway Protocol + (BGP) is used to disseminate customer network VPN routes between PE + VRFs configured in the same VPN. + + The initial BGP/MPLS IP VPN specification enabled PE routers to learn + routes within customer sites through static routing, or through a + dynamic routing protocol instantiated on the PE-CE link. + Specifically, [RFC4364] (and its predecessor, [RFC2547]) included + support for dynamic routing protocols such as BGP, RIP, and OSPFv2. + The OSPFv2 as the Provider/Customer Edge Protocol specification + [RFC4577] further updates the operation of OSPFv2 as the PE-CE + routing protocol by detailing additional extensions to enable intra- + domain routing connectivity between OSPFv2-based customer sites. + + While [RFC4364] was defined for IPv4-based networks, [RFC4659] + extends support to IPv6 VPNs. It is expected that OSPFv3 will be + used as the IGP for some IPv6 VPNs just as the OSPFv2 was used for + IPv4 VPNs. The advantages of using OSPFv3 as a PE-CE protocol are + the same as for the IPv4 VPN deployment. + + This document defines the mechanisms required to enable the operation + of OSPFv3 as the PE-CE routing protocol. In doing so, it reuses, and + extends where necessary, methods defined in [RFC4659] and [RFC4577]. + This document also includes the specifications for maintaining 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]. + +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 associated with deploying OSPFv3 as + the PE-CE routing protocol are similar to those described in + [RFC4577]. The requirements described in Section 3 of [RFC4577] + remain semantically identical for the deployment of OSPFv3. + + + +Pillay-Esnault, et al. Standards Track [Page 4] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + + [RFC5340] describes the modifications required to OSPF to support + IPv6. In that specification, many of the fundamental mechanisms + associated with OSPFv2 remain unchanged for OSPFv3. Consequently, + the operation of OSPFv3 as the PE-CE routing protocol is very similar + to OSPFv2 as the PE-CE protocol. + +3.1. OSPFv3 Specificities + + Section 2 of [RFC5340] describes the differences between OSPFv3 and + OSPFv2. Several of these changes will require modifications to the + architecture described in [RFC4577]. These differences and their + corresponding impact to [RFC4577] are described below: + + New LSA types: + + For an IPv6 VPN architecture where customers interface with + providers through OSPFv3, traditional BGP/OSPF interactions + specify that VPN-IPv6 reachability information redistributed into + OSPFv3 will be expressed as AS-External OSPFv3 LSAs. Instead, it + may be desirable to view these 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 operates on a per-link basis as opposed to OSPFv2, which + operates on a per-IP-subnet basis. The support of multiple OSPFv3 + protocol instances on a link changes the architecture described in + [RFC4577]. [RFC4577] specifies that each interface belongs to no + more than one OSPF instance. For OSPFv3, multiple instances can + be established over a single interface and associated with the + same VRF. + + In addition to establishing multiple OSPFv3 instances over a + single PE-CE link, multiple OSPFv3 instances can also be + established across a sham link. This enables multiple OSPFv3 + instances associated with a VRF to independently establish intra- + area connectivity to other OSPFv3 instances attached to a remote + PE VRF. Support for multiple OSPFv3 instances across the sham + link is described in Section 5. + +4. BGP/OSPFv3 Interaction Procedures for PE Routers + +4.1. VRFs and OSPFv3 Instances + + The relationship between VRFs, interfaces, and OSPFv3 instances on a + PE router is described in the following section. + + + +Pillay-Esnault, et al. Standards Track [Page 5] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + + As defined in [RFC4364], a PE router can be configured with one or + more VRFs. Each VRF configured on the PE corresponds to a customer + VPN and retains the destinations that are reachable within that VPN. + Each VRF may be associated with one or more interfaces, which allows + multiple sites to participate in the same VPN. If OSPFv3 is + instantiated on an interface associated with a VRF, the VRF will be + populated with OSPFv3 routing information. + + As OSPFv3 supports multiple instances on a single interface, it is + therefore possible that multiple customer sites can connect to the + same interface of a PE router (e.g., through a Layer 2 switch) using + distinct OSPFv3 instances. A PE interface can be associated with + only one VRF, and all OSPFv3 instances running on the same interface + MUST be associated with the 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 + + Similar to [RFC4577], the PE must associate at least one OSPFv3 + instance for each OSPFv3 domain to which it attaches, and each + instance of OSPFv3 MUST be associated with a single VRF. + + The support of multiple PE-CE OSPFv3 instances per PE interface does + not change the paradigm that an OSPF instance can be associated with + only a single VRF. Furthermore, for each instance instantiated on + the interface, the PE establishes adjacencies with corresponding CEs + associated with the instance. Note that although multiple instances + may populate a common VRF, they do not leak routes to one another, + unless configured to do so. + +4.1.2. OSPFv3 Domain Identifier + + The OSPFv3 Domain ID describes the administrative domain of the OSPF + instance that originated the route. It has an AS-wide significance + and is one of the parameters used to determine whether a VPN-IPv6 + route should be translated as an Inter-area-prefix LSA or External + LSA. Each OSPFv3 instance MUST have a primary Domain ID that is + transported along with the VPN-IPv6 route in a BGP attribute over the + VPN backbone. Each OSPFv3 instance may have a set of secondary + Domain IDs that applies to other OSPFv3 instances within its + administrative domain. + + The primary Domain ID may either be configured or be set to a value + of NULL. The secondary Domain IDs are only allowed if a non-NULL + primary Domain ID is configured. The Domain ID MUST be configured on + a per-OSPFv3 instance basis. + + + + +Pillay-Esnault, et al. Standards Track [Page 6] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + + The Domain ID is used to determine whether an incoming VPN-IPv6 route + belongs to the same domain as the receiving OSPFv3 instance. An + incoming VPN-IPv6 route is said to belong to the same domain if a + non-NULL incoming Domain ID matches either the local primary or one + of the secondary Domain IDs. If the local Domain ID and incoming + Domain ID are NULL, it is considered a match. + +4.2. OSPFv3 Areas + + Sections 4.1.4 and 4.2.3 of [RFC4577] describe the characteristics of + a PE router within an OSPFv2 domain. The mechanisms and expected + behavior described in [RFC4577] are applicable to an OSPFv3 domain. + +4.3. VRFs and Routes + + From the perspective of the CE, the PE appears as any other OSPFv3 + neighbor. There is no requirement for the CE to support any + mechanisms of IPv6 BGP/MPLS VPNs or for the CE to have any awareness + of the VPNs, thereby enabling any OSPFv3 implementation to be used on + a CE. + + Because the export and import policies might cause different routes + to be installed in different VRFs of the same OSPFv3 domain, the VPN + backbone cannot be considered as a single router from the perspective + of the domain's CEs. Rather, each CE should view its connected PE as + a separate router. + + The PE uses OSPFv3 to distribute routes to CEs, and 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 is + changed to a VPN-IPv6 prefix by the addition of an 8-octet Route + Distinguisher (RD) as discussed in Section 2 of [RFC4659]. This VPN- + IPv6 route can then be 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 used to distinguish between OSPFv3 instances. 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) are also carried in Extended Community + Attributes of the MP-BGP route. + + A PE receiving a VPN-IPv6 NLRI from MP-BGP uses an import policy to + determine, based on the RT, whether the route is eligible to be + installed in one of its local VRFs. The BGP decision process selects + + + + + +Pillay-Esnault, et al. Standards Track [Page 7] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + + which of the eligible routes are to be installed in the associated + VRF, and the selected set of VPN-IPv6 routes are converted 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 the local + configuration. For example, the PE might be configured to advertise + only a default route to CEs of a particular OSPFv3 instance. + Further, if the route is to be redistributed into multiple OSPFv3 + instances, the route might be advertised using different LSA types in + different instances. + + If an IPv6 route learned from MP-BGP is to be redistributed into a + particular OSPFv3 instance, the OSPF Domain Identifier Extended + Communities attribute of the VPN-IPv6 route is used to determine + whether the OSPFv3 instance from which the route was learned is the + same as the OSPFv3 instance into which the route is to be + redistributed. + +4.3.1. OSPFv3 Routes on PEs + + VRFs may be populated by both OSPFv3 routes from a CE or VPN-IPv6 + routes from other PEs via MP-BGP. OSPFv3 routes are installed in a + VRF using the OSPFv3 decision process. They may be redistributed + into BGP and disseminated to other PEs participating in the VPN. At + these 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 are redistributed into BGP are given + an RT that corresponds to the VRF. This RT is examined at remote + PEs. In order to import a route, a VRF must have an import RT that + is identical to the route's RT. For routes that are eligible to be + imported into the VRF, the standard BGP decision process is used to + choose the "best" route(s). + + When a route is advertised from a CE to a PE via OSPFv3 and that + route is installed in the VRF associated with the CE, the route is + advertised to other locally attached CEs under normal OSPFv3 + procedures. + + The route is also redistributed into MP-BGP to be advertised to + remote PEs. The information necessary for accurate redistribution + back into OSPFv3 by the 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 information encoded into + these attributes are as follows: + + + +Pillay-Esnault, et al. Standards Track [Page 8] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + + 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 NULL identifier 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: + + 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: + + 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: + + No configured filtering prohibits redistributing the route to + OSPFv3; + + No configured policy blocks the route in favor of a less-specific + summary route; and + + + + +Pillay-Esnault, et al. Standards Track [Page 9] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + + Redistribution of a BGP learned IPv6 route into OSPF is based on + local policy. + + The subsequent sections discuss the advertisement of routes learned + from MP-BGP and the rules for determining to which LSA types and to + which CEs to advertise the routes. + + When the PE sends an LSA to a CE, it sets the DN-bit in the LSA to + prevent looping. The DN-bit is discussed 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 from which the IPv6 route was learned is the + same (as determined by the Domain ID) as the domain of the OSPFv3 + instance into which it is to be redistributed; and + + The IPv6 route was advertised to a remote PE in an Intra-Area- + Prefix (type 0x2009) OR an Inter-Area-Prefix (type 0x2003) LSA. + + Note that under these rules, the PE represents itself as an Area + Border Router (ABR) regardless of whether or not the route is being + advertised into the same area number from which the remote PE learned + it (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 + + A PE considers an IPv6 route to be external under the following + circumstances: + + The OSPFv3 domain from which the route was learned is different + (as determined by the Domain ID) from the domain of the OSPFv3 + instance into which it is redistributed; or + + + + + + + +Pillay-Esnault, et al. Standards Track [Page 10] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + + The OSPFv3 domain from which the route was learned is the same as + the domain of the OSPFv3 instance into which it is redistributed, + 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 determine if the learned route is from a different domain, the + Domain ID associated with the VPN-IPv6 route (in the OSPF Domain ID + Extended Communities attribute or attributes) is compared with the + local OSPFv3 Domain ID, if configured. Compared Domain IDs are + considered identical if: + + 1. All 8 bytes are identical; or + + 2. Both Domain IDs are NULL (all zeroes). + + Note that if the VPN-IPv6 route does not have a Domain ID in its + attributes, or if the local OSPFv3 instance does not have a + configured Domain ID (i.e., in either case), the route is considered + to have a NULL Domain ID. + + An IPv6 route that is determined to be external might or might not be + advertised to a connected CE, depending on the type of area to which + the PE-CE link belongs and whether there is a configured policy + restricting its advertisement. + + If there are multiple external routes to the same prefix, the + standard OSPFv3 decision process is used to select the "best" route. + + If the external route is to be advertised and the area type of the + PE-CE link is NSSA, the PE advertises the route in an NSSA-LSA (type + 0x2007); otherwise, the external route is advertised in an + AS-External-LSA (type 0x4005). + + The DN-bit of the LSA advertising the external route MUST be set, as + described in Section 4.5.1. + + If the VPN-IPv6 route indicates a route Type-1 metric, the PE should + advertise the external route with that metric-type; otherwise, the + metric-type of the external IPv6 route is set to Type-2 by default. + Note that, by default, a PE should advertise an external route with a + Type-2 metric if the IPv6 route's Domain ID is different than the + local OSPFv3 instance, unless specified otherwise by local policy. + + + + + + + +Pillay-Esnault, et al. Standards Track [Page 11] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + +4.4. BGP Extended Communities Attributes + + OSPFv3 routes from one site are translated and delivered + transparently to the remote site as BGP VPN-IPv6 routes. The + original OSPFv3 routes carry OSPFv3-specific information that needs + to be communicated to the remote PE to ensure transparency. BGP + Extended Communities are used to carry the needed information to + enable the receiving side to reconstruct a database just as in the + OSPFv2 case. + + All OSPFv3 routes added to the VRF routing table on a PE router are + examined to create a corresponding VPN-IPv6 route in BGP. Each of + the OSPFv3 routes MUST have the corresponding BGP Extended + Communities Attributes that contain and preserve the OSPFv3 + information of the original OSPFv3 route. The BGP Extended + Communities attributes defined in [RFC4577] are reused for + convenience. + + OSPF Domain Identifier Extended Communities Attribute + + Each OSPFv3 Instance within a VRF MUST have a Domain ID. The Domain + ID is configured per OSPFv3 Instance. The OSPFv3 Domain ID is 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 Attribute + + OSPFv3 Domain IDs field : 6 bytes + + Each OSPFv3 Instance within a VRF MUST have a Domain ID and its + default value (if none is configured) 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 as in OSPFv2. This attribute + has a 2-byte type field, encoded with a value of 0x0107. + + + + + + +Pillay-Esnault, et al. Standards Track [Page 12] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + + 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 Attribute + + OSPFv3 Router ID field : 4 bytes + + The OSPFv3 Router ID is a 32-bit number 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 contains a 2-byte type field, encoded with a value of 0x0306. The + remaining 6 bytes are divided 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 Attribute + + Area Number : 4 bytes + + The area number indicates the 32-bit Area ID to which the route + belongs. + + Route Types : 1 byte + + + + + + + + + + + + + +Pillay-Esnault, et al. Standards Track [Page 13] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + + To accommodate OSPFv3 LSA types (as registered by [RFC5340]), the + Route Type field is encoded as follows: + + 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 Encoding + + Options : 1 byte + + The Options field indicates the options that are associated with + the OSPFv3 route. + + 8 7 6 5 4 3 2 1 + +---+---+---+---+---+---+---+---+ + | | | | | | | | E | + +---+---+---+---+---+---+---+---+ + + The OSPFv3 Route Options Field + + The least significant bit (i.e., bit E) in this field designates + the external metric-type. 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 + + In some topologies, it is possible for routing loops to occur due to + the nature and manner of route reachability propagation. One such + example is the case of a dual-homed CE router connected to two PEs; + those PE routers would receive reachability information both through + their CE and their peer PE. As there is transparent transport of + OSPFv3 routes over the VPN backbone, it is not possible for the PE + routers to determine whether they are within a loop. + + The loop scenarios in OSPFv3 topologies are identical to those in the + OSPFv2 topologies described in Sections 4.2.5.1 and 4.2.5.2 of + [RFC4577]. Of the two loop prevention mechanisms described in the + aforementioned sections, only the DN-bit option will be supported in + the OSPFv3 implementation. + + + + + + +Pillay-Esnault, et al. Standards Track [Page 14] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + +4.5.1. OSPFv3 Down Bit + + [RFC4576] describes the usage of the DN-bit for OSPFv2 and is + applicable for OSPFv3 for Inter-area-prefix LSAs, NSSA LSAs, and + External LSAs. Similarly, the DN-bit MUST be set in Inter-area- + prefix LSAs, NSSA LSAs, and AS-External LSAs, when these are + originated from a PE to a CE, to prevent those prefixes from being + 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 described in Section 4.5.1 of this document is + sufficient to prevent looping if the DN-bit information attached to a + prefix is preserved in the OSPF domain. As described in Section + 4.2.5.3 of [RFC4577], caution must be exercised if mutual + redistribution that is performed on a PE causes loss of loop + prevention information. + +5. OSPFv3 Sham Links + + This section modifies the specification of OSPFv2 sham links (defined + in Section 4.2.7 of [RFC4577]) to support OSPFv3. Support for OSPFv3 + sham links is an OPTIONAL feature of this specification. + + A sham link enables a VPN backbone to act as an intra-area link. It + is needed when two sites are connected by an intra-area "backdoor" + link and the inter-area VPN backbone route would be less preferable + due to OSPF route preference rules. The figure below shows the + instantiation of 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 Link + + Much of the operation of sham links remains semantically identical to + what was previously specified. There are, however, several + differences that need to be defined to ensure the proper operation of + OSPFv3 sham links. + + + +Pillay-Esnault, et al. Standards Track [Page 15] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + + One of the primary differences between sham links for OSPFv3 and sham + links as specified in [RFC4577] is for configurations where multiple + OSPFv3 instances populate a VRF. It may be desirable to provide + separate intra-area links between these instances over the same sham + link. To achieve this, multiple OSPFv3 instances may be established + across the PE-PE sham link to provide intra-area connectivity between + PE-CE OSPFv3 instances. + + Note that even though multiple OSPFv3 instances may be associated + with a VRF, a sham link is still thought of as a relation between two + VRFs. + + Another modification to OSPFv2 sham links is that OSPFv3 sham links + are now identified by 128-bit endpoint addresses. Since sham link + endpoint addresses are now 128 bits, they can no longer default to + the RouterID, which 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 specified in Section 4.2.7.1 of [RFC4577], these endpoint + addresses MUST NOT be advertised by OSPFv3; if there is no BGP route + to the sham link endpoint address, that address is to appear + unreachable, so that the sham link appears to be down. + + If there is a BGP route to the remote sham link endpoint address, the + sham link appears to be up. Conversely, if there is no BGP route to + the sham link endpoint address, the sham link appears to be down. + +5.1. Creating a Sham Link + + The procedures for creating an OSPFv3 sham link are identical to + those specified in Section 4.2.7.2 of [RFC4577]. Note that the + creation of OSPFv3 sham links requires the configuration of both + local and remote 128-bit sham link endpoint addresses. The local + sham link endpoint address associated with a VRF MAY be used by all + OSPFv3 instances that are attached to that VRF. The OSPFv3 PE-PE + "link" Instance ID in the protocol packet header is used to + demultiplex multiple OSPFv3 instance protocol packets exchanged over + the sham link. + +5.2. OSPF Protocol on Sham Link + + Much of the operation of OSPFv3 over a sham link is semantically the + same as the operation of OSPFv2 over a sham link, as described in + Section 4.2.7.3 of [RFC4577]. This includes the methodology for + sending and receiving OSPFv3 packets over sham links, as well as + + + + +Pillay-Esnault, et al. Standards Track [Page 16] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + + Hello/Router Dead Intervals. Furthermore, the procedures associated + with the assignment of sham link metrics adhere to those set forth + for OSPFv2. OSPFv3 sham links are treated as on-demand circuits. + + Although the operation of the OSPFv3 protocol over the sham link is + the same as OSPFv2, multiple OSPFv3 instances may be instantiated + across this link. By instantiating multiple instances across the + sham link, distinct intra-area connections can be established between + PE-PE OSPFv3 instances associated with the endpoint addresses. + + For example, if 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, it may be desirable to connect O1 and O3 with an intra-area link, + and O2 and O4 with an intra-area link. This can be accomplished by + instantiating two OSPFv3 instances across the sham link, which + connects V1 and V2. O1 and O3 can be mapped to one of the sham link + OSPFv3 instances; O2 and O4 can be mapped to the other sham link + OSPFv3 instance. + +5.3. OSPF Packet Forwarding on Sham Link + + The rules associated with route redistribution, stated in Section + 4.2.7.4 of [RFC4577], remain unchanged in this specification. + 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 redistributing these LSAs into BGP, they are encoded with the + BGP Extended Communities Attributes, as defined in Section 4.4 of + this document. + + 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 + + The support of multiple address families (AFs) in OSPFv3 is described + in [RFC5838]. [RFC5838] differentiates between AFs by using reserved + ranges of Instance IDs for each AF. + + + + +Pillay-Esnault, et al. Standards Track [Page 17] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + + The architecture described 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 described in this document are specific to the use of + OSPFv3 as the PE-CE protocol and do not introduce any new security + concerns other than those already defined in Section 6 of [RFC4577]. + +8. IANA Considerations + + An early version of this document resulted in the allocation of + OSPFv3 Route Attributes (0x0004) entry in the BGP IPv6 Address + Specific Extended Community. This allocation is no longer required. + 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 would like to thank Kelvin Upson, Seiko Okano, Matthew + Everett, Dr. Vineet Mehta, Paul Wells, and Marek Karasek for their + support of this work. Thanks 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. + + + + + + +Pillay-Esnault, et al. Standards Track [Page 18] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + +Pillay-Esnault, et al. Standards Track [Page 19] + +RFC 6565 OSPFv3 as a PE-CE Routing Protocol June 2012 + + +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 + + + + + + +Pillay-Esnault, et al. Standards Track [Page 20] + -- cgit v1.2.3