idnits 2.17.1 draft-ietf-l3vpn-ospfv3-pece-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 916. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 940. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5625 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Pillay-Esnault 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track P. Moyer 5 Expires: May 7, 2009 Pollere LLC 6 J. Doyle 7 Jeff Doyle and Associates 8 E. Ertekin 9 M. Lundberg 10 Booz Allen Hamilton 11 November 3, 2008 13 OSPFv3 as a PE-CE routing protocol 14 draft-ietf-l3vpn-ospfv3-pece-01 16 Status of This Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 7, 2009. 41 Abstract 43 Many Service Providers (SPs) offer the Virtual Private Network (VPN) 44 services to their customers, using a technique in which Customer Edge 45 (CE) routers are routing peers of Provider Edge (PE) routers. The 46 Border Gateway Protocol (BGP) is used to distribute the customer's 47 routes across the provider's IP backbone network, and Multiprotocol 48 Label Switching (MPLS) is used to tunnel customer packets across the 49 provider's backbone. This is known as a "BGP/MPLS IP VPN". 50 Originally only IPv4 was supported and it was later extended to 51 support IPv6 VPNs as well. Extensions were later added for the 52 support of the Open Shortest Path First protocol version 2 (OSPFv2) 53 as a PE-CE routing protocol for the IPv4 VPNs. This document extends 54 those specifications to support OSPF version 3 (OSPFv3) as a PE-CE 55 routing protocol. The OSPFv3 PE-CE functionality is identical to 56 that of OSPFv2 except for the differences described in this document. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 62 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. OSPFv3 Specificities . . . . . . . . . . . . . . . . . . . 4 64 4. BGP/OSPFv3 Interaction Procedures for PE Routers . . . . . . . 5 65 4.1. VRFs and OSPFv3 Instances . . . . . . . . . . . . . . . . 5 66 4.1.1. Independent OSPFv3 Instances in PEs . . . . . . . . . 5 67 4.1.2. OSPFv3 Domain and PE-PE Link Instance Identifiers . . 6 68 4.2. OSPFv3 Areas . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.3. VRFs and Routes . . . . . . . . . . . . . . . . . . . . . 7 70 4.3.1. OSPFv3 Routes on PE . . . . . . . . . . . . . . . . . 8 71 4.3.2. VPN-IPv6 Routes Received from MP-BGP . . . . . . . . . 9 72 4.4. OSPFv3 Route Extended Communities Attribute . . . . . . . 11 73 4.5. Loop Prevention Techniques . . . . . . . . . . . . . . . . 13 74 4.5.1. OSPFv3 Down Bit . . . . . . . . . . . . . . . . . . . 14 75 4.5.2. Other Possible Loops . . . . . . . . . . . . . . . . . 14 76 5. OSPFv3 Sham Links . . . . . . . . . . . . . . . . . . . . . . 14 77 5.1. Creating A Sham link . . . . . . . . . . . . . . . . . . . 15 78 5.2. OSPF Protocol On Sham link . . . . . . . . . . . . . . . . 15 79 5.3. OSPF Packet Forwarding On Sham Link . . . . . . . . . . . 16 80 6. Multiple Address Family Support . . . . . . . . . . . . . . . 17 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 83 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 87 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 [rfc4364] offers Service Providers (SPs) a method for providing 92 Layer-3 Virtual Private Network (VPN) services to subtending customer 93 networks. Using the procedures defined in [rfc4364], provider edge 94 (PE) routers separate customer VPN routing information into Virtual 95 Routing and Forwarding (VRF) tables. The Border Gateway Protocol 96 (BGP) is used to disseminate customer network VPN routes between PE 97 VRFs configured in the same VPN. 99 Initially, the BGP/MPLS IP VPN specification enabled PE routers to 100 learn routes within customer sites through static routing, or through 101 a dynamic routing protocol instantiated on the PE-CE link. 102 Specifically, [rfc4364] (and its predecessor, [rfc2547]) included 103 support for dynamic routing protocols such as BGP, RIP, and OSPFv2. 104 The OSPFv2 as the Provider/Customer Edge Protocol for BGP/MPLS IP 105 Virtual Private Networks specification [rfc4577] further updates the 106 operation of OSPFv2 as the PE-CE routing protocol by detailing 107 additional extensions to enable intra-domain routing connectivity 108 between OSPFv2-based customer sites. 110 While [rfc4364] was defined for IPv4 based networks, [rfc4659] 111 extends the BGP/MPLS IP VPN framework to support IPv6 VPNs. This 112 includes the capability to connect IPv6 based sites over an IPv4 or 113 IPv6 SP backbone. It is expected that OSPFv3 will be used as the IGP 114 for some IPv6 VPNs just as the OSPFv2 was used for IPv4 VPNs. The 115 advantages of using OSPFv3 as a PE-CE protocol are the same as for 116 the IPv4 VPN deployment. 118 This document defines the mechanisms required to enable the operation 119 of OSPFv3 as the PE-CE Routing Protocol in BGP MPLS/IP VPNs. In 120 doing so, it reuses, and extends where necessary, the "BGP/MPLS IP 121 VPN" method for IPv6 VPNs defined in [rfc4659], and OSPFv2 as the 122 PE-CE routing protocol defined in [rfc4577]. This document also 123 includes the specifications for maintaining intra-domain routing 124 connectivity between OSPFv3-based customer sites across a SP 125 backbone. 127 We presuppose familiarity with the contents of [rfc4364], [rfc4659], 128 [rfc4577], [rfc4576], [rfc5340] and [rfc2328]. 130 2. Specification of Requirements 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 3. Requirements 138 The benefits and considerations associated with deploying OSPFv3 as 139 the PE-CE routing protocol are similar to those described in 140 [rfc4577]. The requirements described in Section 3 of [rfc4577] 141 remain semantically identical for the deployment of OSPFv3. 143 [rfc5340] describes the modifications required to OSPF to support 144 IPv6. In that specification, many of the fundamental mechanisms 145 associated with OSPFv2 remain unchanged for OSPFv3. Consequently, 146 the operation of OSPFv3 as the PE-CE routing protocol is very similar 147 to OSPFv2 as the PE-CE protocol. 149 3.1. OSPFv3 Specificities 151 Section 2.0 of [rfc5340] describes differences between OSPFv3 and 152 OSPFv2. Several of these changes will require modifications to the 153 architecture described in [rfc4577]. These differences and their 154 corresponding impact to [rfc4577] are described below: 156 New LSA types: 158 For an IPv6 MPLS/VPN architecture where customers interface to 159 providers through OSPFv3, traditional BGP/OSPF interactions 160 specify that VPN-IPv6 reachability information redistributed into 161 OSPFv3 will be expressed as an AS-External OSPFv3 LSAs. Instead, 162 it may be desirable to view these LSAs as AS-internal (inter-area- 163 prefix, and intra-area-prefix) LSAs. For the encoding of OSPFv3 164 LSAs, a new OSPFv3 Route Extended Community attribute is defined 165 in Section 4.4. 167 Multiple instances over a link: 169 OSPFv3 operates on a per-link basis as opposed to OSPFv2, which 170 operates on a per-IP-subnet basis. The support of multiple OSPFv3 171 protocol instances on a link changes the architecture described in 172 [rfc4577]. [rfc4577] specifies that each interface belongs to no 173 more than one OSPF instance. For OSPFv3, multiple instances can 174 be established over a single interface, and associated with the 175 same VRF. To distinguish between routes originated from different 176 OSPFv3 instances, an Instance ID field is carried in a newly- 177 defined OSPFv3 Route Extended Community attribute. 179 In addition to establishing multiple OSPFv3 instances over a 180 single PE-CE link, multiple OSPFv3 instances can also be 181 established across a sham link. This enables multiple OSPFv3 182 instances associated with a VRF to independently establish intra- 183 area connectivity to other OSPFv3 instances attached to a remote 184 PE VRF. Support for multiple OSPFv3 instances across the sham 185 link is described in Section 5. 187 4. BGP/OSPFv3 Interaction Procedures for PE Routers 189 4.1. VRFs and OSPFv3 Instances 191 The relationship between VRFs, interfaces, and OSPFv3 instances on a 192 PE router is described in the following section. 194 As defined in [rfc4364], a PE router can be configured with one or 195 more VRFs. Each VRF configured on the PE corresponds to a customer 196 VPN, and retains the destinations that are reachable within that VPN. 197 Each VRF may be associated with one or more interfaces, which allows 198 multiple sites to participate in the same VPN. If OSPFv3 is 199 instantiated on an interface associated with a VRF, the VRF will be 200 populated with OSPFv3 routing information. 202 As OSPFv3 supports multiple instances on a single interface, it is 203 therefore possible that multiple customer sites can connect to the 204 same interface of a PE router (e.g., through a layer 2 switch) using 205 distinct OSPFv3 instances. However, since a PE interface can be 206 associated with only one VRF, all OSPFv3 instances running on the 207 same interface MUST be associated with the same VRF. 209 Since multiple OSPFv3 instances can be associated with a single VRF, 210 an additional mechanism is needed to demultiplex routes across these 211 instances. When a PE supports multiple OSPFv3 instances in a VRF, a 212 local Instance ID is assigned to the "link" that spans over the MPLS 213 VPN backbone (PE-PE). As specified in [rfc5340], the Instance ID has 214 link-local significance only. Therefore, the Instance IDs assigned 215 to the PE-PE "link" need not be the same as the Instance IDs assigned 216 to the PE-CE links. By default, this Instance ID is set to NULL. 217 The OSPFv3 Domain ID and local Instance ID associated with the MPLS 218 backbone may be used to demultiplex routes for multiple instances. 219 Further details on Domain and Instance IDs are provided in Section 220 4.1.2. 222 4.1.1. Independent OSPFv3 Instances in PEs 224 Similar to [rfc4577], the PE must associate at least one OSPFv3 225 instance for each OSPFv3 domain to which it attaches, and each 226 instance of OSPFv3 MUST be associated with a single VRF. 228 The support of multiple PE-CE OSPFv3 instances per PE interface does 229 not change the paradigm that an OSPF instance can be associated with 230 only a single VRF. Furthermore, for each instance instantiated on 231 the interface, the PE establishes adjacencies with corresponding CEs 232 associated with the instance. Note that although multiple instances 233 may populate a common VRF, they do not leak routes to one another, 234 unless configured to do so. 236 4.1.2. OSPFv3 Domain and PE-PE Link Instance Identifiers 238 The OSPFv3 Domain ID describes the administrative domain of the OSPF 239 instance which originated the route. It has an AS wide significance 240 and is one of the parameters used to determine whether a VPN-IPv6 241 route should be translated as an Inter-area-prefix-LSA or External- 242 LSA. Each OSPFv3 instance MUST have a primary Domain ID which is 243 transported along with the VPN-IPv6 route in a BGP attribute over the 244 MPLS VPN backbone. Each OSPFv3 instance may have a set of secondary 245 Domain IDs which applies to other OSPFv3 instances within its 246 administrative domain. 248 The primary Domain ID may either be configured or may be set to a 249 value of NULL. The secondary Domain IDs are only allowed if a non- 250 null primary Domain ID is configured. The Domain ID may be 251 configured on a per-OSPFv3 instance basis or per-VRF. If the Domain 252 ID is configured on the VRF level, consequently all OSPFv3 instances 253 associated with the VRF will share the same Domain ID. 255 The OSPFv3 PE-PE "link" Instance ID has local significance for the 256 PE-PE link over the MPLS VPN backbone within a VRF. This link 257 Instance ID is used for the support of multiple OSPFv3 instances 258 within the same VRF and it is also transported along with the VPN- 259 IPv6 route in a BGP attribute over the MPLS VPN backbone. A PE-PE 260 "link" Instance ID is needed only if multiple OSPFv3 instances are 261 supported, otherwise it is set to NULL. When multiple instances are 262 associated with a VRF, each instance should have a unique PE-PE 263 "link" Instance ID. 265 The tuple is used to determine whether an 266 incoming VPN-IPv6 route belongs to the same Domain as the receiving 267 OSPFv3 instance. An incoming VPN-IPv6 route is said to belong to the 268 same domain if both conditions below are met 270 1. The non-NULL incoming Domain ID matches either the local primary 271 or one of the secondary Domain IDs. If the local Domain ID or 272 incoming Domain ID is NULL, it is considered a match. 274 2. The non-NULL incoming Instance ID matches the local Instance ID. 275 If the local Instance ID or incoming Instance ID is NULL, it is 276 considered a match. 278 4.2. OSPFv3 Areas 280 Sections 4.1.4 and 4.2.3 of [rfc4577] describe the characteristics of 281 a PE router within an OSPFv2 domain. The mechanisms and expected 282 behavior described in [rfc4577] are applicable to an OSPFv3 Domain. 284 4.3. VRFs and Routes 286 From the perspective of the CE, the PE appears as any other OSPFv3 287 neighbor. There is no requirement for the CE to support any 288 mechanisms of IPv6 BGP/MPLS VPNs or for the CE to have any awareness 289 of the VPNs, thereby enabling any OSPFv3 implementation to be used on 290 a CE. 292 Because the export and import policies might cause different routes 293 to be installed in different VRFs of the same OSPFv3 Domain, the MPLS 294 VPN backbone cannot be considered as a single router from the 295 perspective of the Domain's CEs. Rather, each CE should view its 296 connected PE as a separate router. 298 The PE uses OSPFv3 to distribute routes to CEs, and MP-BGP [rfc2858] 299 to distribute VPN-IPv6 routes to other (remote) PE routers as defined 300 in [rfc4659]. An IPv6 prefix installed in the VRF by OSPFv3 is 301 changed to a VPN-IPv6 prefix by the addition of an 8-octet Route 302 Distinguisher (RD) as discussed in Section 2 of [rfc4659]. This VPN- 303 IPv6 route can then be redistributed into MP-BGP according to an 304 export policy that adds a Route Target Extended Communities (RT) 305 attribute to the NLRI [rfc4360]. An IPv6 Address Specific BGP 306 Extended Communities attribute as described in [BGP-EXTCOMM-IPV6] may 307 also be attached to the route. 309 Domain IDs and Instance IDs are used to distinguish between OSPFv3 310 instances. When an OSPFv3-distributed route is redistributed into 311 MP-BGP, the Domain ID, OSPFv3 Router ID, Area, OSPFv3 Route Type, 312 External Route Type, Options fields, and Instance ID are also carried 313 in an attribute of the MP-BGP route. 315 A PE receiving a VPN-IPv6 NLRI from MP-BGP uses an import policy to 316 determine, based on the RT, whether the route is eligible to be 317 installed in one of its local VRFs. The BGP decision process selects 318 which of the eligible routes are to be installed in the associated 319 VRF, and the selected set of VPN-IPv6 routes are converted into IPv6 320 routes by removing the RD before installation. 322 An IPv6 route learned from MP-BGP and installed in a VRF might or 323 might not be redistributed into OSPFv3, depending on the local 324 configuration. For example, the PE might be configured to advertise 325 only a default route to CEs of a particular OSPFv3 instance. 327 Further, if the route is to be redistributed into multiple OSPFv3 328 instances, the route might be advertised using different LSA types in 329 different instances. 331 If an IPv6 route learned from MP-BGP is to be redistributed into a 332 particular OSPFv3 instance, the OSPFv3 Route Extended Community 333 attribute (Section 4.4) of the VPN-IPv6 route is used to determine 334 whether the OSPFv3 instance from which the route was learned is the 335 same as the OSPFv3 instance into which the route is to be 336 redistributed. 338 4.3.1. OSPFv3 Routes on PE 340 VRFs may be populated by both OSPFv3 routes from a CE or VPN-IPv6 341 routes from other PEs via BGP. OSPFv3 routes are installed in a VRF 342 using the OSPFv3 decision process. As described in [rfc4577], OSPFv2 343 routes installed in a VRF may be redistributed into BGP and 344 disseminated to other PEs participating in the VPN. At these remote 345 PEs, the VPN-IPv6 routes may be imported into a VRF and redistributed 346 into the OSPFv3 instance(s) associated with that VRF. 348 As specified in [rfc4659], routes imported and exported into a VRF 349 are controlled by the Route Target (RT) Extended Communities 350 attribute. OSPFv3 routes that are redistributed into BGP are given a 351 RT that corresponds to the VRF. This RT is examined at remote PEs. 352 In order to import a route, a VRF must have a RT that is identical to 353 the route's RT. For routes which are eligible to be imported into 354 the VRF, the standard BGP decision process is used to choose the 355 "best" route(s). 357 When a route is advertised from a CE to a PE via OSPFv3 and that 358 route is installed in the VRF associated with the CE, the route is 359 advertised to other locally attached CEs under normal OSPFv3 360 procedures. 362 The route is also redistributed into MP-BGP to be advertised to 363 remote PEs. The information necessary for accurate redistribution 364 back into OSPFv3 by the remote PEs is carried in an OSPFv3 Route 365 Extended Communities attribute (Section 4.4). The relevant local 366 OSPFv3 information encoded into the attribute is: 368 The Domain ID of the local OSPFv3 process. If no Domain ID is 369 configured, the NULL identifier is used. 371 The Instance ID of the PE-PE link 373 The Area ID of the PE-CE link. 375 The PE's Router ID associated with the OSPFv3 instance. 377 The Route Type, as determined by the LSA type from which the route 378 was learned. 380 The Options fields (External metric-type) 382 A Multi-Exit-Discriminator (MED) attribute SHOULD also be set to the 383 value of the OSPFv3 distance associated with the route plus 1, when 384 the OSPFv3 route is redistributed into the MP-BGP. 386 4.3.2. VPN-IPv6 Routes Received from MP-BGP 388 When a PE receives a valid VPN-IPv6 route from MP-BGP and has 389 identified an association with a local VRF, it must determine: 391 Whether a route to the corresponding IPv6 prefix is to be 392 installed in the VRF; 394 Whether the installed IPv6 route is to be redistributed to one or 395 more local OSPFv3 instances; and 397 What OSPFv3 LSA type is to be used when advertising the route into 398 each OSPFv3 instance 400 An IPv6 route derived from a received VPN-IPv6 route is not installed 401 in the associated local VRF if: 403 The BGP decision process identifies a better route to the 404 destination NLRI 406 A configured import policy prohibits the installation of the route 408 The PE advertises the IPv6 route learned from MP-BGP to attached CEs 409 via OSPFv3 if: 411 No configured filtering prohibits redistributing the route to 412 OSPFv3 414 No configured policy blocks the route in favor of a less-specific 415 summary route 417 No OSPFv3 route to the same prefix exists in the VRF, as discussed 418 in Section 4.3.2.4. 420 The subsequent sections discuss the advertisement of routes learned 421 from MP-BGP, and the rules for determining what LSA types and what 422 CEs to advertise the routes to. 424 When the PE sends an LSA to a CE, it sets the DN bit in the LSA to 425 prevent looping. The DN bit is discussed in Section 4.5.1. 427 4.3.2.1. OSPF Inter-Area Routes 429 A PE advertises an IPv6 route using an Inter-Area-Prefix (type 430 0x2003) LSA under the following circumstances: 432 The OSPFv3 domain from which the IPv6 route was learned is the 433 same (as determined by the tuple) as the 434 domain of the OSPFv3 instance into which it is to be 435 redistributed; AND 437 The IPv6 route was advertised to a remote PE in an Intra-Area- 438 Prefix (type 0x2009) OR an Inter-Area-Prefix (type 0x2003) LSA. 440 Note that under these rules the PE represents itself as an ABR 441 regardless of whether or not the route is being advertised into the 442 same area number from which the remote PE learned it (that is, 443 whether the VPN-IPv6 route carries the same or different area 444 numbers). 446 4.3.2.2. OSPF Intra-Area Route 448 A route is advertised from a PE to a CE as an intra-area route using 449 an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used, 450 as described in Section 5. Otherwise routes are advertised as either 451 inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) routes. 453 4.3.2.3. OSPF External Routes And NSSA Routes 455 A PE considers an IPv6 route to be external under the following 456 circumstances: 458 The OSPFv3 domain from which the route was learned is different 459 (as determined by the tuple) from the 460 domain of the OSPFv3 instance into which it is redistributed; OR 462 The OSPFv3 Domain from which the route was learned is the same as 463 the domain of the OSPFv3 instance into which it is redistributed 464 AND it was advertised to the remote PE in an AS-External (type 465 0x4005) or a Type-7 (type 0x2007, NSSA) LSA; OR 467 The route was not learned from an OSPFv3 instance 469 To determine if the learned route is from a different domain, the 470 tuple associated with the VPN-IPv6 route (in 471 the OSPFv3 Route Extended Communities attribute or attributes) is 472 compared with the local OSPFv3 Domain ID and Instance ID, if 473 configured. Compared Domain IDs are considered identical if: 475 1. All six bytes are identical; or 477 2. Both Domain IDs are NULL (all zeroes). 479 Note that if the VPN-IPv6 route does not have a Domain ID in its 480 attributes, or if the local OSPFv3 instance does not have a 481 configured Domain ID, in either case the route is considered to have 482 a NULL Domain ID. 484 An IPv6 route that is determined to be external might or might not be 485 advertised to a connected CE, depending on the type of area to which 486 the PE-CE link belongs and whether there is a configured policy 487 restricting its advertisement. 489 If there are multiple external routes to the same prefix, the 490 standard OSPFv3 decision process is used to select the "best" route. 492 If the external route is to be advertised and the area type of the 493 PE/CE link is NSSA, the PE advertises the route in a Type-7 (type 494 0x2007) LSA; otherwise the external route is advertised in an AS- 495 External (type 0x4005) LSA. 497 The DN bit of the LSA advertising the external route MUST be set, as 498 described in Section 4.5.1. 500 If the VPN-IPv6 route indicates a route type-1 metric, the PE 501 advertises the external route with that metric-type; otherwise the 502 metric-type of the external IPv6 route is set to type-2 by default. 504 4.4. OSPFv3 Route Extended Communities Attribute 506 OSPFv3 routes from one site are translated and delivered 507 transparently to the remote site as BGP VPN-IPv6 routes. The 508 original OSPFv3 routes carry OSPFv3 specific information which need 509 to be communicated to the remote PE to ensure transparency. BGP 510 extended communities are used to carry the needed information to 511 enable the receiving side to reconstruct a database just as in the 512 OSPFv2 case. 514 All OSPFv3 routes added to the VRF routing table on a PE router are 515 examined to create a corresponding VPN-IPv6 route in BGP. Each of 516 the OSPFv3 routes need to carry a BGP Extended Community Attribute 517 which contains and preserves the OSPFv3 information attached to the 518 original OSPFv3 route. 520 This document defines a new BGP attribute in the proposed "IPv6 521 Address Specific Extended Community" registry described in Section 3 522 of [BGP-EXTCOMM-IPV6]. The OSPFv3 Route Extended Community Attribute 523 has the Sub-type value of 0x0004. It carries an OSPFv3 Domain ID, 524 OSPFv3 Router ID, OSPFv3 Area ID, OSPFv3 Route type, Options, and an 525 OSPFv3 Instance ID field. 527 0 1 2 3 528 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | 0x00 | 4 | OSPF Domain ID | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | OSPF Domain ID (Cont.) | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | OSPF Router ID | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Area ID | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Route Type | Options |OSPF InstanceID| UNUSED | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 The OSPFv3 Route Extended Community Attribute 544 This attribute is MANDATORY for all OSPFv3 routes in a VRF instance 545 on a PE router. The fields of this new BGP Extended Community 546 attribute are described in the following sections. 548 OSPFv3 Domain IDs field : 6 bytes 550 Each OSPFv3 Instance within a VRF MUST have a Domain ID. The 551 Domain ID may be configured at the VRF level or at the OSPFv3 552 Instance level. The OSPFv3 Domain ID is a 6-byte number and its 553 default value if none is configured should be NULL. 555 OSPFv3 Router ID field : 4 bytes 557 The OSPFv3 Router ID is a 32 bit number as in OSPFv2. This field 558 is OPTIONAL and may be set to 0. 560 OSPFv3 Area ID : 4 bytes 562 The Area ID field indicates the 32-bit Area ID to which the route 563 belongs. 565 OSPFv3 Route Types : 1 byte 567 To accommodate OSPFv3 LSA types, the OSPF Route Type field is 568 encoded as follows: 570 Route Type Route Type LSA Type Description 571 Code 572 ----------------------------------------------------------- 573 0x30 Inter-area 0x2003 Inter-area-prefix-LSA 574 0x50 External 0x2005 AS-external-LSA 575 0x70 NSSA 0x2007 NSSA-LSA 576 0x90 Intra-area-prefix 0x2009 Intra-area-prefix-LSA 578 The OSPFv3 Route Type Field Encoding 580 OSPFv3 Options : 1 byte 582 The Options field indicates if the route carries a type-1 or 583 type-2 metric. Setting the least significant bit in the field 584 indicates that the route carries a External type-2 metric. 586 OSPFv3 Instance ID field : 1 byte 588 The OSPFv3 Instance ID field is defined to carry the OSPFv3 589 Instance ID which is a one-byte number. The OSPFv3 Instance ID is 590 configured for the "link" simulated by the MPLS VPN backbone. 591 This attribute MAY be present whether several OSPFv3 instances are 592 defined or not. The Instance ID default value is 0. 594 4.5. Loop Prevention Techniques 596 In some topologies, it is possible for routing loops to occur due to 597 the nature and manner of route reachability propagation. One such 598 example is the case of a dual homed CE router connected to two PEs; 599 those PE routers would receive this information both through their CE 600 and their peer PE. As there is transparent transport of OSPFv3 601 routes over the BGP/MPLS backbone, it is not possible for the PE 602 routers to determine whether they are within a loop. 604 The loop scenarios in OSPFv3 topologies are identical to those in the 605 OSPFv2 topologies described in Section 4.2.5.1 and Section 4.2.5.2 of 606 [rfc4577]. Of the two loop preventions mechanisms described in the 607 sections aforementioned, only the DN bit option will be supported in 608 the OSPFv3 implementation. 610 4.5.1. OSPFv3 Down Bit 612 Section 1 and Section 3 of [rfc4576] describe the usage of the DN-bit 613 for OSPFv2 and are applicable for OSPFv3 for inter-area-prefix LSAs, 614 NSSA LSAs and External LSAs. Similarly, the DN-bit must be set in 615 inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these 616 are originated from a PE to a CE, to prevent those prefixes from 617 being re-advertised into BGP. As in [rfc4577], any LSA with the DN 618 bit set must not be used for route calculations. 620 The DN bit MUST be clear in all other LSA types. The OSPFv3 DN-bit 621 format is described in Appendix 4.1.1 of [rfc5340]. 623 4.5.2. Other Possible Loops 625 The mechanism described in Section 4.5.1 of this document is 626 sufficient to prevent looping if the DN bit information attached to a 627 prefix is preserved in the OSPF domain. As described in Section 628 4.2.5.3 of [rfc4576], caution must be exercised if mutual 629 redistribution is performed on a PE causing loss of loop prevention 630 information. 632 5. OSPFv3 Sham Links 634 This section modifies the specification of OSPFv2 sham links (defined 635 in Section 4.2.7 of [rfc4577]) to support OSPFv3. Support for OSPFv3 636 sham links is an OPTIONAL feature of this specification. 638 A sham link enables a VPN backbone to act as an intra-area link. It 639 is needed when two sites are connected by an intra-area "backdoor" 640 link and the inter-area MPLS VPN backbone route would be less 641 preferable due to OSPF route preference rules. The figure below 642 shows the instantiation of a sham link between two VPN sites. 644 (VPN backbone) 645 (site-1) <-------- sham link --------> (site-2) 646 CE1 -------- PE1 -------- P ---------- PE2 -------- CE2 647 | | 648 |___________________________________________________| 649 <------------ backdoor link --------------> 650 (OSPF intra-area link) 652 Sham Link 654 Much of the operation of sham links remains semantically identical to 655 what was previously specified. There are, however, several 656 differences that need to be defined to ensure the proper operation of 657 OSPFv3 sham links. 659 One of the primary differences between sham links for OSPFv3 and sham 660 links as specified in [rfc4577] are for configurations where multiple 661 OSPFv3 instances populate a VRF. It may be desirable to provide 662 separate intra-area links between these instances over the same sham 663 link. To achieve this, multiple OSPFv3 instances may be established 664 across the PE-PE sham link to provide intra-area connectivity between 665 PE-CE OSPFv3 instances. 667 Note that even though multiple OSPFv3 instances may be associated 668 with a VRF, a sham link is still thought of as a relation between two 669 VRFs. 671 Another modification to OSPFv2 sham links is that OSPFv3 sham links 672 are now identified by 128-bit endpoint addresses. Since sham links 673 end-point addresses are now 128-bits, they can no longer default to 674 the RouterID, which is a 32-bit number. Sham link endpoint addresses 675 MUST be configured. 677 Sham link endpoint addresses MUST be distributed by BGP as routeable 678 VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. As 679 specified in [rfc4577], these endpoint addresses MUST NOT be 680 advertised by OSPFv3. 682 If there is a BGP route to the remote sham link endpoint address, the 683 sham link appears to be up. Conversely, if there is no BGP route to 684 the sham link endpoint address, the sham link appears to be down. 686 5.1. Creating A Sham link 688 The procedures for creating an OSPFv3 sham link are identical to 689 those specified in Section 4.2.7.2 of [rfc4577]. Note that the 690 creation of OSPFv3 sham links requires the configuration of both 691 local and remote 128-bit sham link endpoint addresses. The local 692 Sham link endpoint address associated with a VRF MAY be used by all 693 OSPFv3 instances that are attached to that VRF. The OSPFv3 PE-PE 694 link Instance ID is used to demultiplex multiple OSPFv3 instance 695 protocol packets exchanged over the sham link. 697 5.2. OSPF Protocol On Sham link 699 Much of the operation of OSPFv3 over a sham link is semantically the 700 same as the operation of OSPFv2 over a sham link, as described in 701 Section 4.2.7.3 of [rfc4577]. This includes the methodology for 702 sending and receiving OSPFv3 packets over sham links, as well as 703 Hello/Router Dead Intervals. Furthermore, the procedures associated 704 with the assignment of sham link metrics adhere to those set forth 705 for OSPFv2. OSPFv3 sham links are treated as on demand circuits. 707 Although the operation of the OSPFv3 protocol over the sham link is 708 the same as OSPFv2, multiple OSPFv3 instances may be instantiated 709 across this link. By instantiating multiple instances across the 710 sham link, distinct intra-area connections can be established between 711 PE-PE OSPFv3 instances associated with the endpoint addresses. 713 For example, if two OSPFv3 instances (O1, O2) attach to a VRF V1, and 714 on a remote PE, two other OSPFv3 instances (O3, O4) attach to a VRF 715 V2, it may be desirable to connect, O1 and O3 with an intra-area 716 link, and O2 and O4 with an intra-area link. This can be 717 accomplished by instantiating two OSPFv3 instances across the sham 718 link, which connects V1 and V2. O1 and O3 can be mapped to one of 719 the sham link OSPFv3 instances; O2 and O4 can be mapped to the other 720 sham link OSPFv3 instance. 722 One difference from Section 4.2.7.3 of [rfc4577] is the addition of 723 Type 0x2009 intra-area-prefix LSAs, and the flooding of these LSAs 724 across the sham link. Furthermore, where prefixes associated with 725 OSPFv2 sham links are advertised in Type-1 LSAs, prefixes associated 726 with OSPFv3 sham links are advertised as OSPFv3 Type 0x2009 LSAs. 727 This change is required based on [rfc5340], which states that 728 loopback interfaces are advertised in intra-area-prefix LSAs. 730 5.3. OSPF Packet Forwarding On Sham Link 732 The rules associated with route redistribution, stated in Section 733 4.2.7.4 of [rfc4577], remain unchanged in this specification. 734 Specifically: 736 If the next hop interface for a particular route is a sham link, 737 then the PE SHOULD NOT redistribute that route into BGP as a VPN- 738 IPv6 route. 740 Any other route advertised in an LSA that is transmitted over a 741 sham link MUST also be redistributed (by the PE flooding the LSA 742 over the sham link) into BGP. 744 When redistributing these LSAs into BGP, they are encoded with the 745 OSPFv3 Route Extended Community, as defined in Section 4.4 of this 746 document. 748 When forwarding a packet, if the preferred route for that packet has 749 the sham link as its next hop interface, then the packet MUST be 750 forwarded according to the corresponding BGP route (as defined in 751 [rfc4364] and [rfc4659]). 753 6. Multiple Address Family Support 755 The support of multiple address families (AF) in OSPFv3 is described 756 in [OSPF-AF-ALT]. [OSPF-AF-ALT] differentiates between AF using 757 reserved ranges of InstanceIDs for each AF. 759 The architecture described in this document is fully compatible with 760 [OSPF-AF-ALT]. The OSPFv3 PE-CE protocol can support multiple 761 address families across a MPLS VPN backbone. All AFs redistributed 762 from OSPFv3 into BGP on a PE MUST contain the OSPFv3 Route Extended 763 Community Attribute. 765 Note that since [OSPF-AF-ALT] does not support multiple AFs across 766 virtual links, this document only addresses support for unicast IPv6 767 addresses across the sham link. 769 7. Security Considerations 771 The extensions described in this document are specific to the use of 772 OSPFv3 as the PE-CE protocol and do not introduce any concerns 773 regarding the use of BGP as transport of IPv6 reachability over the 774 MPLS Backbone. The Security considerations for the transport of IPv6 775 reachability information using BGP are discussed in Section 11 of 776 [rfc4659] and are not altered. 778 The new extensions defined in this document do not introduce any new 779 security concerns other than those already defined in Section 6 of 780 [rfc4577]. 782 8. IANA Considerations 784 This document defines a new BGP attribute in the proposed "IPv6 785 Address Specific Extended Community" registry described in Section 3 786 of [BGP-EXTCOMM-IPV6]. This document makes the following assignments 787 in the "IPv6 Address Specific Extended Community" registry. 789 Name Sub-type Value 790 ---- -------------- 791 OSPFv3 Route Attributes 0x0004 793 The OSPFv3 specific BGP Extended Community types 795 9. Contributors 797 Joe Lapolito 799 10. Acknowledgments 801 The authors would like to thank Kelvin Upson, Seiko Okano, and Dr. 802 Vineet Mehta for their support of this work. 804 This document was produced using Marshall Rose's xml2rfc tool. 806 11. References 808 11.1. Normative References 810 [RFC2119] Bradner, S., "Key words for use in RFC's to 811 Indicate Requirement Levels", BCP 14, RFC 2119, 812 March 1997. 814 [rfc2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 816 [rfc2547] Rosen, E. and Y. Rehkter, "BGP/MPLS VPNs", 817 RFC 2547, March 1999. 819 [rfc2858] Bates, T., Rehkter, Y., Chandra, R., and D. Katz, 820 "Multiprotocol Extensions for BGP-4", RFC 2858, 821 June 2000. 823 [rfc4360] Sangli, S., Tappan, D., and Y. Rehkter, "BGP 824 Extended Communities Attribute", RFC 4360, 825 February 2006. 827 [rfc4364] Rosen, E. and Y. Rehkter, "BGP/MPLS IP Virtual 828 Private Networks (VPNs)", RFC 4364, 829 February 2006. 831 [rfc4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, 832 "Using a Link State Advertisement (LSA) Options 833 Bit to Prevent Looping in BGP/MPLS IP Virtual 834 Private Networks (VPNs)", RFC 4576, June 2006. 836 [rfc4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, 837 "OSPF as the Provider/Customer Edge Protocol for 838 BGP/MPLS IP Virtual Private Networks (VPNs)", 839 RFC 4577, June 2006. 841 [rfc4659] De Clercq, J., Ooms, D., Carugi, M., and F. 842 Lefaucheur, "BGP-MPLS IP Virtual Private Network 843 (VPN) Extension for IPv6 VPN", RFC 4659, 844 September 2006. 846 [rfc5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, 847 "OSPF for IPv6", RFC 5340, July 2008. 849 11.2. Informative References 851 [BGP-EXTCOMM-IPV6] Rehkter, Y., "IPv6 Address Specific BGP Extended 852 Communities Attribute", October 2008, . 856 [OSPF-AF-ALT] Mirtorabi, S., Roy, A., Barnes, M., Aggarwal, R., 857 and A. Lindem, "Support of address families in 858 OSPFv3", October 2008, . 861 Authors' Addresses 863 Padma Pillay-Esnault 864 Cisco Systems 865 510 McCarty Blvd 866 Milpitas, CA 95035 867 USA 869 EMail: ppe@cisco.com 871 Peter Moyer 872 Pollere LLC 873 325M Sharon Park Drive #214 874 Menlo Park, CA 94025 875 USA 877 EMail: pete@pollere.net 879 Jeff Doyle 880 Jeff Doyle and Associates 881 9878 Teller Ct. 882 Westminster, CO 80021 883 USA 885 EMail: jdoyle@doyleassociates.net 886 Emre Ertekin 887 Booz Allen Hamilton 888 5220 Pacific Concourse Drive 889 Los Angeles, CA 90045 890 USA 892 EMail: ertekin_emre@bah.com 894 Michael Lundberg 895 Booz Allen Hamilton 896 35 Corporate Dr. 897 Burlington, MA 01803 898 USA 900 EMail: lundberg_michael@bah.com 902 Full Copyright Statement 904 Copyright (C) The IETF Trust (2008). 906 This document is subject to the rights, licenses and restrictions 907 contained in BCP 78, and except as set forth therein, the authors 908 retain all their rights. 910 This document and the information contained herein are provided on an 911 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 912 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 913 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 914 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 915 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 916 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 918 Intellectual Property 920 The IETF takes no position regarding the validity or scope of any 921 Intellectual Property Rights or other rights that might be claimed to 922 pertain to the implementation or use of the technology described in 923 this document or the extent to which any license under such rights 924 might or might not be available; nor does it represent that it has 925 made any independent effort to identify any such rights. Information 926 on the procedures with respect to rights in RFC documents can be 927 found in BCP 78 and BCP 79. 929 Copies of IPR disclosures made to the IETF Secretariat and any 930 assurances of licenses to be made available, or the result of an 931 attempt made to obtain a general license or permission for the use of 932 such proprietary rights by implementers or users of this 933 specification can be obtained from the IETF on-line IPR repository at 934 http://www.ietf.org/ipr. 936 The IETF invites any interested party to bring to its attention any 937 copyrights, patents or patent applications, or other proprietary 938 rights that may cover technology that may be required to implement 939 this standard. Please address the information to the IETF at 940 ietf-ipr@ietf.org.