idnits 2.17.1 draft-ietf-l3vpn-ospfv3-pece-00.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 (October 7, 2008) is 5678 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: April 10, 2009 Pollere LLC 6 J. Doyle 7 Jeff Doyle and Associates 8 E. Ertekin 9 M. Lundberg 10 Booz Allen Hamilton 11 October 7, 2008 13 OSPFv3 as a PE-CE routing protocol 14 draft-ietf-l3vpn-ospfv3-pece-00 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 April 10, 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 . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . 13 75 4.5.2. Other Possible Loops . . . . . . . . . . . . . . . . . 14 76 5. OSPFv3 VRF Instance Processing . . . . . . . . . . . . . . . . 14 77 5.1. OSPFv3 VRF LSA Handling From CE . . . . . . . . . . . . . 14 78 5.2. OSPFv3 Sham Links . . . . . . . . . . . . . . . . . . . . 14 79 5.2.1. Creating A Sham link . . . . . . . . . . . . . . . . . 16 80 5.2.2. OSPF Protocol On Sham link . . . . . . . . . . . . . . 16 81 5.2.3. OSPF Packet Forwarding On Sham Link . . . . . . . . . 16 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 90 1. Introduction 92 [rfc4364] offers Service Providers (SPs) a method for providing 93 Layer-3 Virtual Private Network (VPN) services to subtending customer 94 networks. Using the procedures defined in [rfc4364], provider edge 95 (PE) routers separate customer VPN routing information into Virtual 96 Routing and Forwarding (VRF) tables. The Border Gateway Protocol 97 (BGP) is used to disseminate customer network VPN routes between PE 98 VRFs configured in the same VPN. 100 Initially, the BGP/MPLS IP VPN specification enabled PE routers to 101 learn routes within customer sites through static routing, or through 102 a dynamic routing protocol instantiated on the PE-CE link. 103 Specifically, [rfc4364] (and its predecessor, [rfc2547]) included 104 support for dynamic routing protocols such as BGP, RIP, and OSPFv2. 105 The OSPFv2 as the Provider/Customer Edge Protocol for BGP/MPLS IP 106 Virtual Private Networks specification [rfc4577] further updates the 107 operation of OSPFv2 as the PE-CE routing protocol by detailing 108 additional extensions to enable intra-domain routing connectivity 109 between OSPFv2-based customer sites. 111 While [rfc4364] was defined for IPv4 based networks, [rfc4659] 112 extends the BGP/MPLS IP VPN framework to support IPv6 VPNs. This 113 includes the capability to connect IPv6 based sites over an IPv4 or 114 IPv6 SP backbone. It is expected that OSPFv3 will be used as the IGP 115 for some IPv6 VPNs just as the OSPFv2 was used for IPv4 VPNs. The 116 advantages of using OSPFv3 as a PE-CE protocol are the same as for 117 the IPv4 VPN deployment. 119 This document defines the mechanisms required to enable the operation 120 of OSPFv3 as the PE-CE Routing Protocol in BGP MPLS/IP VPNs. In 121 doing so, it reuses, and extends where necessary, the "BGP/MPLS IP 122 VPN" method for IPv6 VPNs defined in [rfc4659], and OSPFv2 as the 123 PE-CE routing protocol defined in [rfc4577]. This document also 124 includes the specifications for maintaining intra-domain routing 125 connectivity between OSPFv3-based customer sites across a SP 126 backbone. 128 We presuppose familiarity with the contents of [rfc4364], [rfc4659], 129 [rfc4577], [rfc4576], [rfc5340] and [rfc2328]. 131 2. Specification of Requirements 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 3. Requirements 139 The benefits and considerations associated with deploying OSPFv3 as 140 the PE-CE routing protocol are similar to those described in 141 [rfc4577]. The requirements described in Section 3 of [rfc4577] 142 remain semantically identical for the deployment of OSPFv3 for IPv6 143 VPNs. 145 [rfc5340] describes the modifications required to OSPF to support 146 IPv6. In that specification, many of the fundamental mechanisms 147 associated with OSPFv2 remain unchanged for OSPFv3. Consequently, 148 the operation of OSPFv3 as the PE-CE routing protocol is very similar 149 to OSPFv2 as the PE-CE protocol. 151 3.1. OSPFv3 Specificities 153 Section 2.0 of [rfc5340] describes differences between OSPFv3 and 154 OSPFv2. Several of these changes will require modifications to the 155 architecture described in [rfc4577]. These differences and their 156 corresponding impact to [rfc4577] are described below: 158 New LSA types: 160 For an IPv6 MPLS/VPN architecture where customers interface to 161 providers through OSPFv3, traditional BGP/OSPF interactions 162 specify that VPN-IPv6 reachability information redistributed into 163 OSPFv3 will be expressed as an AS-External OSPFv3 LSAs. Instead, 164 it may be desirable to view these LSAs as AS-internal (inter-area- 165 prefix, and intra-area-prefix) LSAs. For the encoding of OSPFv3 166 LSAs, a new OSPFv3 Route Extended Community attribute is defined 167 in Section 4.4. 169 Multiple instances over a link: 171 OSPFv3 operates on a per-link basis as opposed to OSPFv2, which 172 operates on a per-IP-subnet basis. The support of multiple OSPFv3 173 protocol instances on a link changes the architecture described in 174 [rfc4577]. [rfc4577] specifies that each interface belongs to no 175 more than one OSPF instance. For OSPFv3, multiple instances can 176 be established over a single interface, and associated with the 177 same VRF. To distinguish between routes originated from different 178 OSPFv3 instances, an Instance ID field is carried in the newly- 179 defined OSPFv3 Route Extended Community attribute. 181 In addition to establishing multiple OSPFv3 instances over a 182 single PE-CE link, multiple OSPFv3 instances can also be 183 established across a sham link. This enables multiple OSPFv3 184 instances associated with a VRF to independently establish intra- 185 area connectivity to other OSPFv3 instances attached to a remote 186 PE VRF. Support for multiple OSPFv3 instances across the sham 187 link is described in Section 5.2. 189 4. BGP/OSPFv3 Interaction Procedures for PE Routers 191 4.1. VRFs and OSPFv3 Instances 193 The relationship between VRFs, interfaces, and OSPFv3 instances on a 194 PE router is described in the following section. 196 As defined in [rfc4364], a PE router can be configured with one or 197 more VRFs. Each VRF configured on the PE corresponds to a customer 198 VPN, and retains the destinations that are reachable within that VPN. 199 Each VRF may be associated with one or more interfaces, which allows 200 multiple sites to participate in the same VPN. If OSPFv3 is 201 instantiated on an interface associated with a VRF, the VRF will be 202 populated with OSPFv3 routing information. 204 As OSPFv3 supports multiple instances on a single interface, it is 205 therefore possible that multiple customer sites can connect to the 206 same interface of a PE router (e.g., through a layer 2 switch) using 207 distinct OSPFv3 instances. However, since a PE interface can be 208 associated with only one VRF, all OSPFv3 instances running on the 209 same interface MUST be associated with the same VRF. 211 Since multiple OSPFv3 instances can be associated with a single VRF, 212 an additional mechanism is needed to demultiplex routes across these 213 instances. When a PE supports multiple OSPFv3 instances in a VRF, a 214 local Instance ID is assigned to the "link" that spans over the MPLS 215 VPN backbone (PE-PE). By default, this Instance ID is set to NULL. 216 The OSPFv3 Domain ID and local Instance ID associated with the MPLS 217 backbone may be used to demultiplex routes for multiple instances. 218 The detailed mechanism is described in Section 4.1.2. 220 4.1.1. Independent OSPFv3 Instances in PEs 222 Similar to [rfc4577], the PE must associate at least one OSPFv3 223 instance for each OSPFv3 domain to which it attaches, and each 224 instance of OSPFv3 MUST be associated with a single VRF. 226 The support of multiple PE-CE OSPFv3 instances per PE interface does 227 not change the paradigm that an OSPF instance can be associated with 228 only a single VRF. Furthermore, for each instance instantiated on 229 the interface, the PE establishes adjacencies with corresponding CEs 230 associated with the instance. Note that although multiple instances 231 may populate a common VRF, they do not leak routes to one another, 232 unless configured to do so. 234 4.1.2. OSPFv3 Domain and PE-PE Link Instance Identifiers 236 The OSPFv3 Domain ID describes the administrative domain of the OSPF 237 instance which originated the route. It has an AS wide significance 238 and is one of the parameters used to determine whether a VPN-IPv6 239 route should be translated as an Inter-area-prefix-LSA or External- 240 LSA. Each OSPFv3 instance MUST have a primary Domain ID which is 241 transported along with the VPN-IPv6 route in a BGP attribute over the 242 MPLS VPN backbone. Each OSPFv3 instance may have a set of secondary 243 Domain IDs which applies to other OSPFv3 instances within its 244 administrative domain. 246 The primary Domain ID may either be configured or may be set to a 247 value of NULL. The secondary Domain IDs are only allowed if a non- 248 null primary Domain ID is configured. The Domain ID may be 249 configured on a per-OSPFv3 Instance basis or per-VRF. If the Domain 250 ID is configured on the VRF level, consequently all OSPFv3 instances 251 associated with the VRF will share the same Domain ID. 253 The OSPFv3 PE-PE Link Instance ID has local significance for the 254 PE-PE link over the MPLS VPN backbone within a VRF. This link 255 Instance ID is used for the support of multiple OSPFv3 instances 256 within the same VRF and it is also transported along with the VPN- 257 IPv6 route in a BGP attribute over the MPLS VPN backbone. A PE-PE 258 Link Instance ID is needed only if multiple OSPFv3 instances are 259 supported, otherwise it is set to NULL. When multiple instances are 260 associated with a VRF, each instance should have a unique PE-PE Link 261 Instance ID. 263 The tuple is used to determine whether an 264 incoming VPN-IPv6 route belongs to the same Domain as in the 265 receiving OSPFv3 instance. An incoming VPN-IPv6 route is said to 266 belong to the same domain if both conditions below are met 268 1. The non-NULL incoming Domain ID matches either the local primary 269 or one of the secondary Domain IDs. If the local Domain ID or 270 incoming Domain ID is NULL, it is considered a match. 272 2. The non-NULL incoming Instance ID matches the local Instance ID. 273 If the local Instance ID or incoming Instance ID is NULL, it is 274 considered a match. 276 4.2. OSPFv3 Areas 278 Sections 4.1.4 and 4.2.3 of [rfc4577] describe the characteristics of 279 a PE router within an OSPF domain. The mechanisms and expected 280 behavior described in [rfc4577] are applicable to an OSPFv3 Domain. 282 4.3. VRFs and Routes 284 From the perspective of the CE, the PE appears as any other OSPFv3 285 neighbor. There is no requirement for the CE to support any 286 mechanisms of IPv6 BGP/MPLS VPNs or for the CE to have any awareness 287 of the VPNs, thereby enabling any OSPFv3 implementation to be used on 288 a CE. 290 Because the export and import policies might cause different routes 291 to be installed in different VRFs of the same OSPFv3 Domain, the MPLS 292 VPN backbone cannot be considered as a single router from the 293 perspective of the Domain's CEs. Rather, each CE should view its 294 connected PE as a separate router. 296 The PE uses OSPFv3 to distribute routes to CEs, and MP-BGP [rfc2858] 297 to distribute VPN-IPv6 routes to other (remote) PE routers as defined 298 in [rfc4659]. An IPv6 prefix installed in the VRF by OSPFv3 is 299 changed to a VPN-IPv6 prefix by the addition of an 8-octet Route 300 Distinguisher (RD) as discussed in Section 2 of [rfc4659]. This VPN- 301 IPv6 route can then be redistributed into MP-BGP according to an 302 export policy that adds a Route Target Extended Communities (RT) 303 attribute to the NLRI [rfc4360]. An IPv6 Address Specific BGP 304 Extended Communities attribute as described in [BGP-EXTCOMM-IPV6] may 305 also be attached to the route. 307 Domain IDs and Instance IDs are used to distinguish between OSPFv3 308 instances. When an OSPFv3-distributed route is redistributed into 309 MP-BGP, the Domain ID, OSPFv3 Router ID, Area, OSPFv3 Route Type, 310 External Route Type, and Instance ID are also carried in an attribute 311 of the MP-BGP route. 313 A PE receiving a VPN-IPv6 NLRI from MP-BGP uses an import policy to 314 determine, based on the RT, whether the route is eligible to be 315 installed in one of its local VRFs. The BGP decision process selects 316 which of the eligible routes are to be installed in the associated 317 VRF, and the selected set of VPN-IPv6 routes are converted into IPv6 318 routes by removing the RD before installation. 320 An IPv6 route learned from MP-BGP and installed in a VRF might or 321 might not be redistributed into OSPFv3, depending on the local 322 configuration. For example, the PE might be configured to advertise 323 only a default route to CEs of a particular OSPFv3 instance. 324 Further, if the route is to be redistributed into multiple OSPFv3 325 instances, the route might be advertised using different LSA types in 326 different instances. 328 If an IPv6 route learned from MP-BGP is to be redistributed into a 329 particular OSPFv3 instance, the OSPFv3 Route Extended Community 330 attribute (Section 4.4) of the VPN-IPv6 route is used to determine 331 whether the OSPFv3 instance from which the route was learned is the 332 same as the OSPFv3 instance into which the route is to be 333 redistributed. 335 4.3.1. OSPFv3 Routes on PE 337 VRFs may be populated by both OSPFv3 routes from a CE or VPN-IPv6 338 routes from other PEs via BGP. OSPFv3 routes are installed in a VRF 339 using the OSPFv3 decision process. As described in [rfc4577], OSPF 340 routes installed in a VRF may be redistributed into BGP and 341 disseminated to other PEs participating in the VPN. At these remote 342 PEs, the VPN-IPv6 routes may be imported into a VRF and redistributed 343 into the OSPFv3 instance(s) associated with that VRF. 345 As specified in [rfc4659], routes imported and exported into a VRF 346 are controlled by the Route Target (RT) Extended Communities 347 attribute. OSPFv3 routes that are redistributed into BGP are given a 348 RT that corresponds to the VRF. This RT is examined at remote PEs. 349 In order to import a route, a VRF must have a RT that is identical to 350 the route's RT. For routes which are eligible to be imported into 351 the VRF, the standard BGP decision process is used to choose the 352 "best" route(s). 354 When a route is advertised from a CE to a PE via OSPFv3 and that 355 route installed in the VRF associated with the CE, the route is 356 advertised to other locally attached CEs under normal OSPFv3 357 procedures. 359 The route is also redistributed into MP-BGP to be advertised to 360 remote PEs. The information necessary for accurate redistribution 361 back into OSPFv3 by the remote PEs is carried in an OSPFv3 Route 362 Extended Communities attribute (Section 4.4). The relevant local 363 OSPFv3 information encoded into the attribute is: 365 The Domain ID of the local OSPFv3 process. If no Domain ID is 366 configured, the NULL identifier is used. 368 The Instance ID of the PE-PE link 370 The Area ID of the PE-CE link. 372 The PE's Router ID associated with the OSPFv3 instance. The Route 373 Type, as determined by the LSA type from which the route was 374 learned. 376 4.3.2. VPN-IPv6 Routes Received from MP-BGP 378 When a PE receives a valid VPN-IPv6 route from MP-BGP and has 379 identified an association with a local VRF, it must determine: 381 Whether a route to the corresponding IPv6 prefix is to be 382 installed in the VRF; 384 Whether the installed IPv6 route is to be redistributed to one or 385 more local OSPFv3 instances; and 387 What OSPFv3 LSA type is to be used to advertise the route 389 An IPv6 route derived from a received VPN-IPv6 route is not installed 390 in the associated local VRF if: 392 The BGP decision process identifies a better route to the 393 destination NLRI 395 A configured import policy prohibits the installation of the route 397 The PE advertises the IPv6 route learned from MP-BGP to attached CEs 398 via OSPFv3 if: 400 No configured filtering prohibits redistributing the route to 401 OSPFv3 403 No configured policy blocks the route in favor of a less-specific 404 summary route 406 No OSPFv3 route to the same prefix exists in the VRF, as discussed 407 in Section 4.3.2.4. 409 The subsequent sections discuss the advertisement of routes learned 410 from MP-BGP, and the rules for determining what LSA types and what 411 CEs to advertise the routes to. 413 When the PE sends an LSA to a CE, it sets the DN bit in the LSA to 414 prevent looping. The DN bit is discussed in Section 4.5.1. 416 4.3.2.1. OSPF Inter-Area Routes 418 A PE advertises an IPv6 route using an Inter-Area-Prefix (type 419 0x2003) LSA under the following circumstances: 421 The OSPFv3 domain from which the IPv6 route was learned is the 422 same (as determined by the tuple) as the 423 domain of the OSPFv3 instance into which it is to be 424 redistributed; AND 426 The IPv6 route was advertised to a remote PE in an Intra-Area- 427 Prefix (type 0x2009) OR an Inter-Area-Prefix (type 0x2003) LSA. 429 Note that under these rules the PE represents itself as an ABR 430 regardless of whether or not the route is being advertised into the 431 same area number from which the remote PE learned it (that is, 432 whether the VPN-IPv6 route carries the same or different area 433 numbers). This insures that if an area becomes partitioned, so that 434 two areas with the same area ID are separated by the VPN MPLS 435 backbone connectivity is maintained through an inter-area route. 437 4.3.2.2. OSPF Intra-Area Route 439 A route is advertised from a PE to a CE as an intra-area route using 440 an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used, 441 as described in Section 5.2. Otherwise routes are advertised as 442 either inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) 443 routes. 445 4.3.2.3. OSPF External Routes And NSSA Routes 447 A PE considers an IPv6 route to be external under the following 448 circumstances: 450 The OSPFv3 domain from which the route was learned is different 451 (as determined by the tuple) from the 452 domain of the OSPFv3 instance into which it is redistributed; OR 454 The OSPFv3 Domain from which the route was learned is the same as 455 the domain of the OSPFv3 instance into which it is redistributed 456 AND it was advertised to the remote PE in an AS-External (type 457 0x4005) or a Type-7 (type 0x2007, NSSA) LSA; OR 459 The route was not learned from an OSPFv3 instance 461 To determine if the learned route is from a different domain, the 462 tuple associated with the VPN-IPv6 route (in 463 the route OSPFv3 Route Extended Communities attribute or attributes) 464 is compared with the local OSPFv3 Domain ID and Instance ID, if 465 configured. Compared Domain IDs are considered identical if: 467 1. All six bytes are identical; or 469 2. Both Domain IDs are NULL (all zeroes). 471 Note that if the VPN-IPv6 route does not have a Domain ID in its 472 attributes, or if the local OSPFv3 instance does not have a 473 configured Domain ID, in either case the route is considered to have 474 a NULL Domain ID. 476 An IPv6 route that is determined to be external might or might not be 477 advertised to a connected CE, depending on the type of area to which 478 the PE-CE link belongs and whether there is a configured policy 479 restricting its advertisement. 481 If there are multiple external routes to the same prefix, the 482 standard OSPFv3 decision process is used to select the "best" route. 484 If the external route is to be advertised and the area type of the 485 PE/CE link is NSSA, the PE advertises the route in a Type-7 (type 486 0x2007) LSA; otherwise the external route is advertised in an AS- 487 External (type 0x4005) LSA. 489 The DN bit of the LSA advertising the external route MUST be set, as 490 described in Section 4.5.1. 492 The PE sets the metric of the advertised external IPv6 route to the 493 same value as the MED attribute of the VPN-IPv6 route from which the 494 IPv6 route was derived. If the VPN-IPv6 route has no associated MED 495 attribute, a default metric value is used. 497 If the VPN-IPv6 route indicates a route type of 1, the PE advertises 498 the external route with that route type; otherwise the route type of 499 the external IPv6 route is set to 2 by default. 501 4.4. OSPFv3 Route Extended Communities Attribute 503 OSPFv3 routes from one site are translated and delivered 504 transparently to the remote site as BGP VPN-IPv6 routes. The 505 original OSPFv3 routes carry OSPFv3 specific information which need 506 to be communicated to the remote PE to ensure transparency. BGP 507 extended communities are used to carry the needed information to 508 enable the receiving side to reconstruct a database just as in the 509 OSPFv2 case. 511 All OSPFv3 routes added to the VRF routing table on a PE router are 512 examined to create a corresponding VPN-IPv6 route in BGP. Each of 513 the OSPFv3 routes need to carry a BGP Extended Community Attribute 514 which contains and preserves the OSPFv3 information attached to the 515 original OSPFv3 route. 517 This document defines a new BGP attribute in the proposed "IPv6 518 Address Specific Extended Community" registry described in Section 3 519 of [BGP-EXTCOMM-IPV6]. The OSPFv3 Route Extended Community Attribute 520 has the Sub-type value of 0x0004. It carries an OSPFv3 Domain ID, 521 OSPFv3 Router ID, OSPFv3 Area ID OSPFv3 Route type, Options, and an 522 OSPFv3 Instance ID field. 524 0 1 2 3 525 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | 0x00 | 4 | OSPF Domain ID | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | OSPF Domain ID (Cont.) | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | OSPF Router ID | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Area ID | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Route Type | Options |OSPF InstanceID| UNUSED | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 The OSPFv3 Route Extended Community Attribute 541 This attribute is MANDATORY for all OSPFv3 routes in a VRF instance 542 on a PE router. The fields of this new BGP Extended Community 543 attribute are described in the following sections. 545 OSPFv3 Domain IDs field : 6 bytes 547 Each OSPFv3 Instance within a VRF MUST have a Domain ID. The 548 Domain ID may be configured at the VRF level or at the OSPFv3 549 Instance level. The OSPFv3 Domain ID is a 6-byte number and its 550 default value if none is configured should be NULL. 552 OSPFv3 Router ID field : 4 bytes 554 The OSPFv3 Router ID is a 32 bit number as in OSPFv2. This field 555 is OPTIONAL and may be set to 0. 557 OSPFv3 Area ID : 4 bytes 559 The Area ID field indicates the 32-bit Area ID to which the route 560 belongs. 562 OSPFv3 Route Types : 1 byte 564 To accommodate OSPFv3 LSA types, the OSPF Route Type field is 565 encoded as follows: 567 Route Type Route Type LSA Type Description 568 Code 569 ----------------------------------------------------------- 570 0x30 Inter-area 0x2003 Inter-area-prefix-LSA 571 0x50 External 0x2005 AS-external-LSA 572 0x70 NSSA 0x2007 NSSA-LSA 573 0x90 Intra-area-prefix 0x2009 Intra-area-prefix-LSA 575 The OSPFv3 Route Type Field Encoding 577 OSPFv3 Options : 1 byte 579 The Options field indicates if the route carries a type-1 or 580 type-2 metric. Setting the least significant bit in the field 581 indicates that the route carries a External type-2 metric. 583 OSPFv3 Instance ID field : 1 byte 585 The OSPFv3 Instance ID field is defined to carry the OSPFv3 586 Instance ID which is a one-byte number. The OSPFv3 Instance ID is 587 configured for the "link" simulated by the MPLS VPN backbone. 588 This attribute MAY be present whether several OSPFv3 instances are 589 defined or not. The Instance ID default value is 0. 591 4.5. Loop Prevention Techniques 593 In some topologies, it is possible for routing loops to occur due to 594 the nature and manner of route reachability propagation. One such 595 example is the case of a dual homed CE router connected to two PEs; 596 those PE routers would received this information both through their 597 CE and their peer PE. As there is transparent transport of OSPFv3 598 routes over the BGP/MPLS backbone, it is not possible for the PE 599 routers to determine whether they are within a loop. 601 The loop scenarios in OSPFv3 topologies are identical to those in the 602 OSPFv2 topologies described in Section 4.2.5.1 and Section 4.2.5.2 of 603 [rfc4577]. Of the two loop preventions mechanisms described in the 604 sections aforementioned, only the DN bit option will be supported in 605 the OSPFv3 implementation. 607 4.5.1. OSPFv3 Down Bit 609 Section 1 and Section 3 of [rfc4576] describe the usage of the DN-bit 610 for OSPFv2 and are applicable for OSPFv3 for inter-area-prefix LSAs, 611 NSSA LSAs and External LSAs. Similarly, the DN-bit must be set in 612 inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these 613 are originated from a PE to a CE, to prevent those prefixes from 614 being re-advertised into BGP. 616 The DN bit MUST be clear in all other LSA types. The OSPFv3 DN-bit 617 format is described in Appendix 4.1.1 of [rfc5340]. 619 4.5.2. Other Possible Loops 621 The mechanism described in Section 4.5.1 of this document is 622 sufficient to prevent looping if the DN bit information attached to a 623 prefix is preserved in the OSPF domain. As described in Section 624 4.2.5.3 of [rfc4576], caution must be exercised if mutual 625 redistribution is performed on a PE causing loss of loop prevention 626 information. 628 5. OSPFv3 VRF Instance Processing 630 5.1. OSPFv3 VRF LSA Handling From CE 632 Much like [rfc4577], any LSA with the DN bit set must not be used for 633 route calculation. The DN bit for OSPFv3 LSAs is defined in 634 [rfc5340]. 636 Section 4.2.6 of [rfc4577] states that a PE router must create a VPN 637 route in BGP for "every address prefix that was installed in the VRF 638 by one of its associated OSPFv3 instances". This holds true for 639 OSPFv3 as well. 641 Each VPN-IPv6 route created by a PE will carry an OSPFv3 Route 642 Extended Community Attribute, as defined in Section 4.4. The Domain 643 ID, Router ID, and area ID, Route Type and options fields within this 644 extended community correspond to the attributes defined in [rfc4577], 645 as they convey information about an OSPFv3 route in BGP. One new 646 addition is the Instance ID field. This field is used to encode 647 information about the OSPFv3 instances associated with a VRF. 649 Note that the new OSPFv3 Route Extended Community Attribute contains 650 all extended community attributes specified in [rfc4577] and the 651 OSPFv3 Instance ID but packs them into one attribute. 653 5.2. OSPFv3 Sham Links 655 This section modifies the specification of OSPFv2 sham links (defined 656 in Section 4.2.7 of [rfc4577]) to support OSPFv3. Support for OSPFv3 657 sham links is an OPTIONAL feature of this specification. 659 Sham links are used to allow two sites that have an intra-area 660 connection between them to act as a single VPN site that is multi- 661 homed to the backbone. Figure 1 shows the instantiation of a sham 662 link between two VPN sites. 664 (VPN backbone) 665 (site-1) <-------- sham link --------> (site-2) 666 CE1 -------- PE1 -------- P ---------- PE2 -------- CE2 667 | | 668 |___________________________________________________| 669 <------------ backdoor link --------------> 670 (OSPF intra-area link) 672 Sham Link 674 Much of the operation of sham links remains semantically identical to 675 what was previously specified. There are, however, several 676 differences that need to be defined to ensure the proper operation of 677 OSPFv3 sham links. 679 One of the primary differences between sham links for OSPFv3 and sham 680 links as specified in [rfc4577] are for configurations where multiple 681 OSPFv3 instances populate a VRF. It may be desirable to provide 682 separate intra-area links between these instances over the same sham 683 link. To achieve this, multiple OSPFv3 instances may be established 684 across the PE-PE sham link to provide intra-area connectivity between 685 PE-CE OSPFv3 instances. 687 Note that even though multiple OSPFv3 instances may be associated 688 with a VRF, a sham link is still thought of as a relation between two 689 VRFs. 691 Another modification to OSPFv2 sham links is that OSPFv3 sham links 692 are now identified by 128-bit endpoint addresses. Since sham links 693 end-point addresses are now 128-bits, they can no longer default to 694 the RouterID, which is 32-bits number. Sham link endpoint addresses 695 MUST be configured. 697 Sham link endpoint addresses MUST be distributed by BGP as routeable 698 VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. As 699 specified in [rfc4577], these endpoint addresses MUST NOT be 700 advertised by OSPFv3. 702 If there is a BGP route to the remote sham link endpoint address, the 703 sham link appears to be up. Conversely, if there is no BGP route to 704 the sham link endpoint address, the sham link appears to be down. 706 5.2.1. Creating A Sham link 708 The procedures for creating an OSPFv3 sham link are identical to 709 those specified in Section 4.2.7.2 of [rfc4577]. Note that the 710 creation of OSPFv3 sham links requires the configuration of both 711 local and remote 128-bit sham link endpoint addresses. The local 712 Sham link endpoint address associated with a VRF MAY be used by all 713 OSPFv3 instances that are attached to that VRF. The OSPFv3 PE-PE 714 link Instance ID is used to demultiplex multiple OSPFv3 instance 715 protocol packets exchanged over the sham link. 717 5.2.2. OSPF Protocol On Sham link 719 Much of the operation of OSPFv3 over a sham link is semantically the 720 same as the operation of OSPFv2 over a sham link, as described in 721 Section 4.2.7.3 of [rfc4577]. This includes the methodology for 722 sending and receiving OSPFv3 packets over sham links, as well as 723 Hello/Router Dead Intervals. Furthermore, the procedures associated 724 with the assignment of sham link metrics adhere to those set forth 725 for OSPFv2. OSPFv3 sham links are treated as on demand circuits. 727 Although the operation of the OSPFv3 protocol over the sham link is 728 the same as OSPFv2, multiple OSPFv3 instances may be instantiated 729 across this link. By instantiating multiple instances across the 730 sham link, distinct intra-area connections can be established between 731 PE-PE OSPFv3 instances associated with the endpoint addresses. 733 For example, if two OSPFv3 instances (O1, O2) attach to a VRF V1, and 734 on a remote PE, two other OSPFv3 instances (O3, O4) attach to a VRF 735 V2, it may be desirable to connect, O1 and O3 with an intra-area 736 link, and O2 and O4 with an intra-area link. This can be 737 accomplished by instantiating two OSPFv3 instances across the sham 738 link, which connects V1 and V2. O1 and O3 can be mapped to one of 739 the sham link OSPFv3 instances; O2 and O4 can be mapped to the other 740 sham link OSPFv3 instance. 742 One difference from Section 4.2.7.3 of [rfc4577] is the addition of 743 Type 0x2009 intra-area-prefix LSAs, and the flooding of these LSAs 744 across the sham link. Furthermore, where OSPFv2 sham links are 745 advertised in Type-1 LSAs, prefixes associated with OSPFv3 sham links 746 are advertised as OSPFv3 Type 0x2009 LSAs. This change is required 747 based on [rfc5340], which states that loopback interfaces are 748 advertised in intra-area-prefix LSAs. 750 5.2.3. OSPF Packet Forwarding On Sham Link 752 The rules associated with route redistribution, stated in Section 753 4.2.7.4 of [rfc4577], remain unchanged in this specification. 755 Specifically: 757 If the next hop interface for a particular route is a sham link, 758 then the PE SHOULD NOT redistribute that route into BGP as a VPN- 759 IPv6 route. 761 Any other route advertised in an LSA that is transmitted over a 762 sham link MUST also be redistributed (by the PE flooding the LSA 763 over the sham link) into BGP. 765 When redistributing these LSAs into BGP, they are encoded with the 766 OSPFv3 Route Extended Community, as defined in Section 4.4 of this 767 document. 769 When forwarding a packet, if the preferred route for that packet has 770 the sham link as its next hop interface, then the packet MUST be 771 forwarded according to the corresponding BGP route (as defined in 772 [rfc4364] and [rfc4659]). 774 6. Security Considerations 776 The extensions described in this document are specific to the use of 777 OSPFv3 as the PE-CE protocol and do not introduce any concerns 778 regarding the use of BGP as transport of IPv6 reachability over the 779 MPLS Backbone. The Security considerations for the transport of IPv6 780 reachability information using BGP are discussed in Section 11 of 781 [rfc4659] and are not altered. 783 The new extensions defined in this document do not introduce any new 784 security concerns other than those already defined in Section 6 of 785 [rfc4577]. 787 7. IANA Considerations 789 This document defines a new BGP attribute in the proposed "IPv6 790 Address Specific Extended Community" registry described in Section 3 791 of [BGP-EXTCOMM-IPV6]. This document makes the following assignments 792 in the "IPv6 Address Specific Extended Community" registry. 794 Name Sub-type Value 795 ---- -------------- 796 OSPFv3 Route Attributes 0x0004 798 The OSPFv3 specific BGP Extended Community types 800 8. Contributors 802 Joe Lapolito 804 9. Acknowledgments 806 The authors would like to thank Kelvin Upson, Seiko Okano, and Dr. 807 Vineet Mehta for their support of this work. 809 This document was produced using Marshall Rose's xml2rfc tool. 811 10. References 813 10.1. Normative References 815 [RFC2119] Bradner, S., "Key words for use in RFC's to 816 Indicate Requirement Levels", BCP 14, RFC 2119, 817 March 1997. 819 [rfc2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 821 [rfc2547] Rosen, E. and Y. Rehkter, "BGP/MPLS VPNs", 822 RFC 2547, March 1999. 824 [rfc2858] Bates, T., Rehkter, Y., Chandra, R., and D. Katz, 825 "Multiprotocol Extensions for BGP-4", RFC 2858, 826 June 2000. 828 [rfc4360] Sangli, S., Tappan, D., and Y. Rehkter, "BGP 829 Extended Communities Attribute", RFC 4360, 830 February 2006. 832 [rfc4364] Rosen, E. and Y. Rehkter, "BGP/MPLS IP Virtual 833 Private Networks (VPNs)", RFC 4364, 834 February 2006. 836 [rfc4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, 837 "Using a Link State Advertisement (LSA) Options 838 Bit to Prevent Looping in BGP/MPLS IP Virtual 839 Private Networks (VPNs)", RFC 4576, June 2006. 841 [rfc4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, 842 "OSPF as the Provider/Customer Edge Protocol for 843 BGP/MPLS IP Virtual Private Networks (VPNs)", 844 RFC 4577, June 2006. 846 [rfc4659] De Clercq, J., Ooms, D., Carugi, M., and F. 847 Lefaucheur, "BGP-MPLS IP Virtual Private Network 848 (VPN) Extension for IPv6 VPN", RFC 4659, 849 September 2006. 851 [rfc5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, 852 "OSPF for IPv6", RFC 5340, July 2008. 854 10.2. Informative References 856 [BGP-EXTCOMM-IPV6] Rehkter, Y., "IPv6 Address Specific BGP Extended 857 Communities Attribute", 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.