idnits 2.17.1 draft-ietf-l3vpn-ospfv3-pece-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 3 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 10, 2012) is 4489 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: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: July 13, 2012 Pollere, Inc 6 J. Doyle 7 Jeff Doyle and Associates 8 E. Ertekin 9 M. Lundberg 10 Booz Allen Hamilton 11 January 10, 2012 13 OSPFv3 as a PE-CE routing protocol 14 draft-ietf-l3vpn-ospfv3-pece-11 16 This document may contain material from IETF Documents or IETF 17 Contributions published or made publicly available before November 18 10, 2008. The person(s) controlling the copyright in some of this 19 material may not have granted the IETF Trust the right to allow 20 modifications of such material outside the IETF Standards Process. 21 Without obtaining an adequate license from the person(s) controlling 22 the copyright in such materials, this document may not be modified 23 outside the IETF Standards Process, and derivative works of it may 24 not be created outside the IETF Standards Process, except to format 25 it for publication as an RFC or to translate it into languages other 26 than English. 28 Abstract 30 Many Service Providers (SPs) offer Virtual Private Network (VPN) 31 services to their customers using a technique in which Customer Edge 32 (CE) routers are routing peers of Provider Edge (PE) routers. The 33 Border Gateway Protocol (BGP) is used to distribute the customer's 34 routes across the provider's IP backbone network, and Multiprotocol 35 Label Switching (MPLS) is used to tunnel customer packets across the 36 provider's backbone. Support currently exists for both IPv4 and IPv6 37 VPNs, however only Open Shortest Path First protocol version 2 38 (OSPFv2) as PE-CE protocol is specified. This document extends those 39 specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing 40 protocol. The OSPFv3 PE-CE functionality is identical to that of 41 OSPFv2 except for the differences described in this document. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on July 13, 2012. 60 Copyright Notice 62 Copyright (c) 2012 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 This document may contain material from IETF Documents or IETF 76 Contributions published or made publicly available before November 77 10, 2008. The person(s) controlling the copyright in some of this 78 material may not have granted the IETF Trust the right to allow 79 modifications of such material outside the IETF Standards Process. 80 Without obtaining an adequate license from the person(s) controlling 81 the copyright in such materials, this document may not be modified 82 outside the IETF Standards Process, and derivative works of it may 83 not be created outside the IETF Standards Process, except to format 84 it for publication as an RFC or to translate it into languages other 85 than English. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 90 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 91 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 92 3.1. OSPFv3 Specificities . . . . . . . . . . . . . . . . . . . 5 93 4. BGP/OSPFv3 Interaction Procedures for PE Routers . . . . . . . 5 94 4.1. VRFs and OSPFv3 Instances . . . . . . . . . . . . . . . . 5 95 4.1.1. Independent OSPFv3 Instances in PEs . . . . . . . . . 6 96 4.1.2. OSPFv3 Domain Identifier . . . . . . . . . . . . . . . 6 97 4.2. OSPFv3 Areas . . . . . . . . . . . . . . . . . . . . . . . 7 98 4.3. VRFs and Routes . . . . . . . . . . . . . . . . . . . . . 7 99 4.3.1. OSPFv3 Routes on PE . . . . . . . . . . . . . . . . . 8 100 4.3.2. VPN-IPv6 Routes Received from MP-BGP . . . . . . . . . 9 101 4.4. BGP Extended Communities Attribute . . . . . . . . . . . . 11 102 4.5. Loop Prevention Techniques . . . . . . . . . . . . . . . . 14 103 4.5.1. OSPFv3 Down Bit . . . . . . . . . . . . . . . . . . . 14 104 4.5.2. Other Possible Loops . . . . . . . . . . . . . . . . . 14 105 5. OSPFv3 Sham Links . . . . . . . . . . . . . . . . . . . . . . 15 106 5.1. Creating A Sham link . . . . . . . . . . . . . . . . . . . 16 107 5.2. OSPF Protocol On Sham link . . . . . . . . . . . . . . . . 16 108 5.3. OSPF Packet Forwarding On Sham Link . . . . . . . . . . . 17 109 6. Multiple Address Family Support . . . . . . . . . . . . . . . 17 110 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 111 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 112 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 113 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 114 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 115 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 116 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 118 1. Introduction 120 [rfc4364] offers Service Providers (SPs) a method for providing 121 Layer-3 Virtual Private Network (VPN) services to subtending customer 122 networks. Using the procedures defined in [rfc4364], provider edge 123 (PE) routers separate customer VPN routing information into Virtual 124 Routing and Forwarding (VRF) tables. The Border Gateway Protocol 125 (BGP) is used to disseminate customer network VPN routes between PE 126 VRFs configured in the same VPN. 128 The initial BGP/MPLS IP VPN specification enabled PE routers to learn 129 routes within customer sites through static routing, or through a 130 dynamic routing protocol instantiated on the PE-CE link. 131 Specifically, [rfc4364] (and its predecessor, [rfc2547]) included 132 support for dynamic routing protocols such as BGP, RIP, and OSPFv2. 133 The OSPFv2 as the Provider/Customer Edge Protocol specification 134 [rfc4577] further updates the operation of OSPFv2 as the PE-CE 135 routing protocol by detailing additional extensions to enable intra- 136 domain routing connectivity between OSPFv2-based customer sites. 138 While [rfc4364] was defined for IPv4 based networks, [rfc4659] 139 extends support to IPv6 VPNs. It is expected that OSPFv3 will be 140 used as the IGP for some IPv6 VPNs just as the OSPFv2 was used for 141 IPv4 VPNs. The advantages of using OSPFv3 as a PE-CE protocol are 142 the same as for the IPv4 VPN deployment. 144 This document defines the mechanisms required to enable the operation 145 of OSPFv3 as the PE-CE Routing Protocol. In doing so, it reuses, and 146 extends where necessary, methods defined in [rfc4659], and [rfc4577]. 147 This document also includes the specifications for maintaining intra- 148 domain routing connectivity between OSPFv3-based customer sites 149 across a SP backbone. 151 We presuppose familiarity with the contents of [rfc4364], [rfc4659], 152 [rfc4577], [rfc4576], [rfc5340] and [rfc2328]. 154 2. Specification of Requirements 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 3. Requirements 162 The benefits and considerations associated with deploying OSPFv3 as 163 the PE-CE routing protocol are similar to those described in 164 [rfc4577]. The requirements described in Section 3 of [rfc4577] 165 remain semantically identical for the deployment of OSPFv3. 167 [rfc5340] describes the modifications required to OSPF to support 168 IPv6. In that specification, many of the fundamental mechanisms 169 associated with OSPFv2 remain unchanged for OSPFv3. Consequently, 170 the operation of OSPFv3 as the PE-CE routing protocol is very similar 171 to OSPFv2 as the PE-CE protocol. 173 3.1. OSPFv3 Specificities 175 Section 2.0 of [rfc5340] describes differences between OSPFv3 and 176 OSPFv2. Several of these changes will require modifications to the 177 architecture described in [rfc4577]. These differences and their 178 corresponding impact to [rfc4577] are described below: 180 New LSA types: 182 For an IPv6 VPN architecture where customers interface to 183 providers through OSPFv3, traditional BGP/OSPF interactions 184 specify that VPN-IPv6 reachability information redistributed into 185 OSPFv3 will be expressed as AS-External OSPFv3 LSAs. Instead, it 186 may be desirable to view these LSAs as inter-area-prefix LSAs. 187 The OSPF Route Type Extended Communities attribute defined in 188 [rfc4577] is extended to include OSPFv3 route types. These new 189 encodings are defined in Section 4.4. 191 Multiple instances over a link: 193 OSPFv3 operates on a per-link basis as opposed to OSPFv2, which 194 operates on a per-IP-subnet basis. The support of multiple OSPFv3 195 protocol instances on a link changes the architecture described in 196 [rfc4577]. [rfc4577] specifies that each interface belongs to no 197 more than one OSPF instance. For OSPFv3, multiple instances can 198 be established over a single interface, and associated with the 199 same VRF. 201 In addition to establishing multiple OSPFv3 instances over a 202 single PE-CE link, multiple OSPFv3 instances can also be 203 established across a sham link. This enables multiple OSPFv3 204 instances associated with a VRF to independently establish intra- 205 area connectivity to other OSPFv3 instances attached to a remote 206 PE VRF. Support for multiple OSPFv3 instances across the sham 207 link is described in Section 5. 209 4. BGP/OSPFv3 Interaction Procedures for PE Routers 211 4.1. VRFs and OSPFv3 Instances 213 The relationship between VRFs, interfaces, and OSPFv3 instances on a 214 PE router is described in the following section. 216 As defined in [rfc4364], a PE router can be configured with one or 217 more VRFs. Each VRF configured on the PE corresponds to a customer 218 VPN, and retains the destinations that are reachable within that VPN. 219 Each VRF may be associated with one or more interfaces, which allows 220 multiple sites to participate in the same VPN. If OSPFv3 is 221 instantiated on an interface associated with a VRF, the VRF will be 222 populated with OSPFv3 routing information. 224 As OSPFv3 supports multiple instances on a single interface, it is 225 therefore possible that multiple customer sites can connect to the 226 same interface of a PE router (e.g., through a layer 2 switch) using 227 distinct OSPFv3 instances. A PE interface can be associated with 228 only one VRF, and all OSPFv3 instances running on the same interface 229 MUST be associated with the same VRF. Configurations where a PE 230 interface is associated with multiple VRFs are out of scope for this 231 document. 233 4.1.1. Independent OSPFv3 Instances in PEs 235 Similar to [rfc4577], the PE must associate at least one OSPFv3 236 instance for each OSPFv3 domain to which it attaches, and each 237 instance of OSPFv3 MUST be associated with a single VRF. 239 The support of multiple PE-CE OSPFv3 instances per PE interface does 240 not change the paradigm that an OSPF instance can be associated with 241 only a single VRF. Furthermore, for each instance instantiated on 242 the interface, the PE establishes adjacencies with corresponding CEs 243 associated with the instance. Note that although multiple instances 244 may populate a common VRF, they do not leak routes to one another, 245 unless configured to do so. 247 4.1.2. OSPFv3 Domain Identifier 249 The OSPFv3 Domain ID describes the administrative domain of the OSPF 250 instance which originated the route. It has an AS wide significance 251 and is one of the parameters used to determine whether a VPN-IPv6 252 route should be translated as an Inter-area-prefix-LSA or External- 253 LSA. Each OSPFv3 instance MUST have a primary Domain ID which is 254 transported along with the VPN-IPv6 route in a BGP attribute over the 255 VPN backbone. Each OSPFv3 instance may have a set of secondary 256 Domain IDs which applies to other OSPFv3 instances within its 257 administrative domain. 259 The primary Domain ID may either be configured or may be set to a 260 value of NULL. The secondary Domain IDs are only allowed if a non- 261 null primary Domain ID is configured. The Domain ID MUST be 262 configured on a per-OSPFv3 instance basis. 264 The Domain ID is used to determine whether an incoming VPN-IPv6 route 265 belongs to the same domain as the receiving OSPFv3 instance. An 266 incoming VPN-IPv6 route is said to belong to the same domain if a 267 non-NULL incoming Domain ID matches either the local primary or one 268 of the secondary Domain IDs. If the local Domain ID and incoming 269 Domain ID are NULL, it is considered a match. 271 4.2. OSPFv3 Areas 273 Sections 4.1.4 and 4.2.3 of [rfc4577] describe the characteristics of 274 a PE router within an OSPFv2 domain. The mechanisms and expected 275 behavior described in [rfc4577] are applicable to an OSPFv3 domain. 277 4.3. VRFs and Routes 279 From the perspective of the CE, the PE appears as any other OSPFv3 280 neighbor. There is no requirement for the CE to support any 281 mechanisms of IPv6 BGP/MPLS VPNs or for the CE to have any awareness 282 of the VPNs, thereby enabling any OSPFv3 implementation to be used on 283 a CE. 285 Because the export and import policies might cause different routes 286 to be installed in different VRFs of the same OSPFv3 domain, the VPN 287 backbone cannot be considered as a single router from the perspective 288 of the domain's CEs. Rather, each CE should view its connected PE as 289 a separate router. 291 The PE uses OSPFv3 to distribute routes to CEs, and MP-BGP [rfc2858] 292 to distribute VPN-IPv6 routes to other (remote) PE routers as defined 293 in [rfc4659]. An IPv6 prefix installed in the VRF by OSPFv3 is 294 changed to a VPN-IPv6 prefix by the addition of an 8-octet Route 295 Distinguisher (RD) as discussed in Section 2 of [rfc4659]. This VPN- 296 IPv6 route can then be redistributed into MP-BGP according to an 297 export policy that adds a Route Target Extended Communities (RT) 298 attribute to the Network Layer Reachability Information (NLRI) 299 [rfc4360]. 301 Domain IDs are used to distinguish between OSPFv3 instances. When an 302 OSPFv3 distributed route is redistributed into MP-BGP, the Domain ID, 303 OSPFv3 Router ID, Area, OSPFv3 Route Type, and Options fields 304 (External Route Type) are also carried in Extended Community 305 Attributes of the MP-BGP route. 307 A PE receiving a VPN-IPv6 NLRI from MP-BGP uses an import policy to 308 determine, based on the RT, whether the route is eligible to be 309 installed in one of its local VRFs. The BGP decision process selects 310 which of the eligible routes are to be installed in the associated 311 VRF, and the selected set of VPN-IPv6 routes are converted into IPv6 312 routes by removing the RD before installation. 314 An IPv6 route learned from MP-BGP and installed in a VRF might or 315 might not be redistributed into OSPFv3, depending on the local 316 configuration. For example, the PE might be configured to advertise 317 only a default route to CEs of a particular OSPFv3 instance. 318 Further, if the route is to be redistributed into multiple OSPFv3 319 instances, the route might be advertised using different LSA types in 320 different instances. 322 If an IPv6 route learned from MP-BGP is to be redistributed into a 323 particular OSPFv3 instance, the OSPF Domain Identifier Extended 324 Communities attribute of the VPN-IPv6 route is used to determine 325 whether the OSPFv3 instance from which the route was learned is the 326 same as the OSPFv3 instance into which the route is to be 327 redistributed. 329 4.3.1. OSPFv3 Routes on PE 331 VRFs may be populated by both OSPFv3 routes from a CE or VPN-IPv6 332 routes from other PEs via MP-BGP. OSPFv3 routes are installed in a 333 VRF using the OSPFv3 decision process. They may be redistributed 334 into BGP and disseminated to other PEs participating in the VPN. At 335 these remote PEs, the VPN-IPv6 routes may be imported into a VRF and 336 redistributed into the OSPFv3 instance(s) associated with that VRF. 338 As specified in [rfc4659], routes imported and exported into a VRF 339 are controlled by the Route Target (RT) Extended Communities 340 attribute. OSPFv3 routes that are redistributed into BGP are given a 341 RT that corresponds to the VRF. This RT is examined at remote PEs. 342 In order to import a route, a VRF must have an import RT that is 343 identical to the route's RT. For routes which are eligible to be 344 imported into the VRF, the standard BGP decision process is used to 345 choose the "best" route(s). 347 When a route is advertised from a CE to a PE via OSPFv3 and that 348 route is installed in the VRF associated with the CE, the route is 349 advertised to other locally attached CEs under normal OSPFv3 350 procedures. 352 The route is also redistributed into MP-BGP to be advertised to 353 remote PEs. The information necessary for accurate redistribution 354 back into OSPFv3 by the remote PEs is carried in the OSPF Route Type, 355 OSPF Domain ID, and OSPF Router ID Extended Communities attributes 356 (Section 4.4). The relevant local OSPFv3 information encoded into 357 these attributes are: 359 The Area ID of the PE-CE link. 361 The Route Type, as determined by the LSA type from which the route 362 was learned. 364 The Options fields (External metric-type) 366 The Domain ID of the OSPFv3 process. If no Domain ID is 367 configured, the NULL identifier is used. 369 The PE's Router ID associated with the OSPFv3 instance. 371 A Multi-Exit-Discriminator (MED) attribute SHOULD also be set to the 372 value of the OSPFv3 metric associated with the route plus 1, when the 373 OSPFv3 route is redistributed into the MP-BGP. 375 4.3.2. VPN-IPv6 Routes Received from MP-BGP 377 When a PE receives a valid VPN-IPv6 route from MP-BGP and has 378 identified an association with a local VRF, it must determine: 380 Whether a route to the corresponding IPv6 prefix is to be 381 installed in the VRF; 383 Whether the installed IPv6 route is to be redistributed to one or 384 more local OSPFv3 instances; and 386 What OSPFv3 LSA type is to be used when advertising the route into 387 each OSPFv3 instance 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 405 Redistribution of a BGP learned IPv6 route into OSPF is based on 406 local policy. 408 The subsequent sections discuss the advertisement of routes learned 409 from MP-BGP, and the rules for determining what LSA types and what 410 CEs to advertise the routes to. 412 When the PE sends an LSA to a CE, it sets the DN bit in the LSA to 413 prevent looping. The DN bit is discussed in Section 4.5.1. 415 4.3.2.1. OSPF Inter-Area Routes 417 A PE advertises an IPv6 route using an Inter-Area-Prefix (type 418 0x2003) LSA under the following circumstances: 420 The OSPFv3 domain from which the IPv6 route was learned is the 421 same (as determined by the Domain ID) as the domain of the OSPFv3 422 instance into which it is to be redistributed; AND 424 The IPv6 route was advertised to a remote PE in an Intra-Area- 425 Prefix (type 0x2009) OR an Inter-Area-Prefix (type 0x2003) LSA. 427 Note that under these rules the PE represents itself as an Area 428 Border Router (ABR) regardless of whether or not the route is being 429 advertised into the same area number from which the remote PE learned 430 it (that is, whether the VPN-IPv6 route carries the same or different 431 area numbers). 433 4.3.2.2. OSPF Intra-Area Route 435 A route is advertised as an intra-area route using an Intra-Area- 436 Prefix (type 0x2009) LSA only when sham links are used, as described 437 in Section 5. Otherwise routes are advertised as either inter-area 438 (Section 4.3.2.1) or external/Not-So-Stubby Area (NSSA) (Sections 439 4.3.2.3) routes. 441 4.3.2.3. OSPF External Routes And NSSA Routes 443 A PE considers an IPv6 route to be external under the following 444 circumstances: 446 The OSPFv3 domain from which the route was learned is different 447 (as determined by the Domain ID) from the domain of the OSPFv3 448 instance into which it is redistributed; OR 450 The OSPFv3 domain from which the route was learned is the same as 451 the domain of the OSPFv3 instance into which it is redistributed 452 AND it was advertised to the remote PE in an AS-External (type 453 0x4005) or a Type-7 (type 0x2007, NSSA) LSA; OR 455 The route was not learned from an OSPFv3 instance 457 To determine if the learned route is from a different domain, the 458 Domain ID associated with the VPN-IPv6 route (in the OSPF Domain ID 459 Extended Communities attribute or attributes) is compared with the 460 local OSPFv3 Domain ID, if configured. Compared Domain IDs are 461 considered identical if: 463 1. All eight bytes are identical; or 465 2. Both Domain IDs are NULL (all zeroes). 467 Note that if the VPN-IPv6 route does not have a Domain ID in its 468 attributes, or if the local OSPFv3 instance does not have a 469 configured Domain ID, in either case the route is considered to have 470 a NULL Domain ID. 472 An IPv6 route that is determined to be external might or might not be 473 advertised to a connected CE, depending on the type of area to which 474 the PE-CE link belongs and whether there is a configured policy 475 restricting its advertisement. 477 If there are multiple external routes to the same prefix, the 478 standard OSPFv3 decision process is used to select the "best" route. 480 If the external route is to be advertised and the area type of the 481 PE-CE link is NSSA, the PE advertises the route in a Type-7 (type 482 0x2007) LSA; otherwise the external route is advertised in an AS- 483 External (type 0x4005) LSA. 485 The DN bit of the LSA advertising the external route MUST be set, as 486 described in Section 4.5.1. 488 If the VPN-IPv6 route indicates a route type-1 metric, the PE should 489 advertise the external route with that metric-type; otherwise the 490 metric-type of the external IPv6 route is set to type-2 by default. 491 Note that by default, a PE should advertise an external route with a 492 type-2 metric if the IPv6 route's Domain ID is different than the 493 local OSPFv3 instance, unless specified otherwise by local policy. 495 4.4. BGP Extended Communities Attribute 497 OSPFv3 routes from one site are translated and delivered 498 transparently to the remote site as BGP VPN-IPv6 routes. The 499 original OSPFv3 routes carry OSPFv3 specific information which need 500 to be communicated to the remote PE to ensure transparency. BGP 501 Extended Communities are used to carry the needed information to 502 enable the receiving side to reconstruct a database just as in the 503 OSPFv2 case. 505 All OSPFv3 routes added to the VRF routing table on a PE router are 506 examined to create a corresponding VPN-IPv6 route in BGP. Each of 507 the OSPFv3 routes MUST have corresponding the BGP Extended 508 Communities Attributes which contain and preserve the OSPFv3 509 information of the original OSPFv3 route. The BGP Extended 510 Communities attributes defined in [rfc4577] are reused for 511 convenience. 513 OSPF Domain Identifier Extended Communities Attribute 515 Each OSPFv3 Instance within a VRF MUST have a Domain ID. The Domain 516 ID is configured per OSPFv3 Instance. The OSPFv3 Domain ID is a 517 6-byte number and its default value is 0. This attribute has a two 518 byte type field, encoded with a value of 0x0005, 0x0105, or 0x0205. 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Type Value | Domain Identifier | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Domain Identifier Cont. | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 The OSPF Domain Identifier Extended Communities Attribute 530 OSPFv3 Domain IDs field : 6 bytes 532 Each OSPFv3 Instance within a VRF MUST have a Domain ID and its 533 default value (if none is configured) is 0. The Domain ID is 534 configured per OSPFv3 Instance. 536 OSPF Router ID Extended Communities Attribute 538 The OSPFv3 Router ID is a 32-bit number as in OSPFv2. This attribute 539 has a two byte type field, encoded with a value of 0x0107. 541 0 1 2 3 542 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 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Type Value | Router ID | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Router ID Cont. | UNUSED | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 The OSPF Router ID Extended Communities Attribute 550 OSPFv3 Router ID field : 4 bytes 552 The OSPFv3 Router ID is a 32 bit number as in OSPFv2. Setting 553 this field is OPTIONAL and its default value is 0. 555 OSPF Route Type Extended Communities Attribute 557 The OSPF Route Type Extended Communities attribute MUST be present. 558 It contains a two byte type field, encoded with a value of 0x0306. 559 The remaining six bytes are divided into three fields, an Area 560 Number, a Route Type, and an Options field 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Type Value | Area Number | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Area Number Cont. | Route Type | Options | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 The OSPF Route Type Extended Communities Attribute 572 Area Number : 4 bytes 574 The area number indicates the 32-bit Area ID to which the route 575 belongs. 577 Route Types : 1 byte 579 To accommodate OSPFv3 LSA types, the Route Type field is encoded 580 as follows: 582 Route Type Route Type LSA Type Description 583 Code 584 ----------------------------------------------------------- 585 3 Inter-area 0x2003 Inter-area-prefix-LSA 586 5 External 0x4005 AS-external-LSA 587 7 NSSA 0x2007 NSSA-LSA 588 1 or 2 Intra-area-prefix 0x2009 Intra-area-prefix-LSA 590 Route Type Field Encoding 592 Options : 1 byte 594 The Options field indicates the options that are associated with 595 the OSPFv3 route. 597 8 7 6 5 4 3 2 1 598 +---+---+---+---+---+---+---+---+ 599 | | | | | | | | E | 600 +---+---+---+---+---+---+---+---+ 602 The OSPFv3 Route Options Field 604 The least significant bit (i.e., bit E) in this field designates 605 the external metric type. If the bit is clear, the route carries 606 a Type-1 external metric; if the bit is set, the route carries a 607 Type-2 external metric. 609 4.5. Loop Prevention Techniques 611 In some topologies, it is possible for routing loops to occur due to 612 the nature and manner of route reachability propagation. One such 613 example is the case of a dual homed CE router connected to two PEs; 614 those PE routers would receive reachability information both through 615 their CE and their peer PE. As there is transparent transport of 616 OSPFv3 routes over the VPN backbone, it is not possible for the PE 617 routers to determine whether they are within a loop. 619 The loop scenarios in OSPFv3 topologies are identical to those in the 620 OSPFv2 topologies described in Section 4.2.5.1 and Section 4.2.5.2 of 621 [rfc4577]. Of the two loop preventions mechanisms described in the 622 sections aforementioned, only the DN bit option will be supported in 623 the OSPFv3 implementation. 625 4.5.1. OSPFv3 Down Bit 627 Section 1 and Section 3 of [rfc4576] describe the usage of the DN-bit 628 for OSPFv2 and are applicable for OSPFv3 for inter-area-prefix LSAs, 629 NSSA LSAs and External LSAs. Similarly, the DN-bit MUST be set in 630 inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these 631 are originated from a PE to a CE, to prevent those prefixes from 632 being re-advertised into BGP. As in [rfc4577], any LSA with the DN 633 bit set must not be used for route calculations on PE routers. 635 The DN bit MUST be clear in all other LSA types. The OSPFv3 DN-bit 636 format is described in Appendix 4.1.1 of [rfc5340]. 638 4.5.2. Other Possible Loops 640 The mechanism described in Section 4.5.1 of this document is 641 sufficient to prevent looping if the DN bit information attached to a 642 prefix is preserved in the OSPF domain. As described in Section 643 4.2.5.3 of [rfc4576], caution must be exercised if mutual 644 redistribution is performed on a PE causing loss of loop prevention 645 information. 647 5. OSPFv3 Sham Links 649 This section modifies the specification of OSPFv2 sham links (defined 650 in Section 4.2.7 of [rfc4577]) to support OSPFv3. Support for OSPFv3 651 sham links is an OPTIONAL feature of this specification. 653 A sham link enables a VPN backbone to act as an intra-area link. It 654 is needed when two sites are connected by an intra-area "backdoor" 655 link and the inter-area VPN backbone route would be less preferable 656 due to OSPF route preference rules. The figure below shows the 657 instantiation of a sham link between two VPN sites. 659 (VPN backbone) 660 (site-1) <-------- sham link --------> (site-2) 661 CE1 -------- PE1 -------- P ---------- PE2 -------- CE2 662 | | 663 |___________________________________________________| 664 <------------ backdoor link --------------> 665 (OSPF intra-area link) 667 Sham Link 669 Much of the operation of sham links remains semantically identical to 670 what was previously specified. There are, however, several 671 differences that need to be defined to ensure the proper operation of 672 OSPFv3 sham links. 674 One of the primary differences between sham links for OSPFv3 and sham 675 links as specified in [rfc4577] are for configurations where multiple 676 OSPFv3 instances populate a VRF. It may be desirable to provide 677 separate intra-area links between these instances over the same sham 678 link. To achieve this, multiple OSPFv3 instances may be established 679 across the PE-PE sham link to provide intra-area connectivity between 680 PE-CE OSPFv3 instances. 682 Note that even though multiple OSPFv3 instances may be associated 683 with a VRF, a sham link is still thought of as a relation between two 684 VRFs. 686 Another modification to OSPFv2 sham links is that OSPFv3 sham links 687 are now identified by 128-bit endpoint addresses. Since sham links 688 end-point addresses are now 128-bits, they can no longer default to 689 the RouterID, which is a 32-bit number. Sham link endpoint addresses 690 MUST be configured. 692 Sham link endpoint addresses MUST be distributed by BGP as routeable 693 VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. As 694 specified in section 4.2.7.1 of [rfc4577], these endpoint addresses 695 MUST NOT be advertised by OSPFv3; if there is no BGP route to the 696 sham link endpoint address, that address is to appear unreachable, so 697 that the sham link appears to be down. 699 If there is a BGP route to the remote sham link endpoint address, the 700 sham link appears to be up. Conversely, if there is no BGP route to 701 the sham link endpoint address, the sham link appears to be down. 703 5.1. Creating A Sham link 705 The procedures for creating an OSPFv3 sham link are identical to 706 those specified in Section 4.2.7.2 of [rfc4577]. Note that the 707 creation of OSPFv3 sham links requires the configuration of both 708 local and remote 128-bit sham link endpoint addresses. The local 709 Sham link endpoint address associated with a VRF MAY be used by all 710 OSPFv3 instances that are attached to that VRF. The OSPFv3 PE-PE 711 "link" Instance ID in the protocol packet header is used to 712 demultiplex multiple OSPFv3 instance protocol packets exchanged over 713 the sham link. 715 5.2. OSPF Protocol On Sham link 717 Much of the operation of OSPFv3 over a sham link is semantically the 718 same as the operation of OSPFv2 over a sham link, as described in 719 Section 4.2.7.3 of [rfc4577]. This includes the methodology for 720 sending and receiving OSPFv3 packets over sham links, as well as 721 Hello/Router Dead Intervals. Furthermore, the procedures associated 722 with the assignment of sham link metrics adhere to those set forth 723 for OSPFv2. OSPFv3 sham links are treated as on demand circuits. 725 Although the operation of the OSPFv3 protocol over the sham link is 726 the same as OSPFv2, multiple OSPFv3 instances may be instantiated 727 across this link. By instantiating multiple instances across the 728 sham link, distinct intra-area connections can be established between 729 PE-PE OSPFv3 instances associated with the endpoint addresses. 731 For example, if two OSPFv3 instances (O1, O2) attach to a VRF V1, and 732 on a remote PE, two other OSPFv3 instances (O3, O4) attach to a VRF 733 V2, it may be desirable to connect, O1 and O3 with an intra-area 734 link, and O2 and O4 with an intra-area link. This can be 735 accomplished by instantiating two OSPFv3 instances across the sham 736 link, which connects V1 and V2. O1 and O3 can be mapped to one of 737 the sham link OSPFv3 instances; O2 and O4 can be mapped to the other 738 sham link OSPFv3 instance. 740 5.3. OSPF Packet Forwarding On Sham Link 742 The rules associated with route redistribution, stated in Section 743 4.2.7.4 of [rfc4577], remain unchanged in this specification. 744 Specifically: 746 If the next hop interface for a particular route is a sham link, 747 then the PE SHOULD NOT redistribute that route into BGP as a VPN- 748 IPv6 route. 750 Any other route advertised in an LSA that is transmitted over a 751 sham link MUST also be redistributed (by the PE flooding the LSA 752 over the sham link) into BGP. 754 When redistributing these LSAs into BGP, they are encoded with the 755 BGP Extended Communities Attributes, as defined in Section 4.4 of 756 this document. 758 When forwarding a packet, if the preferred route for that packet has 759 the sham link as its next hop interface, then the packet MUST be 760 forwarded according to the corresponding BGP route (as defined in 761 [rfc4364] and [rfc4659]). 763 6. Multiple Address Family Support 765 The support of multiple address families (AF) in OSPFv3 is described 766 in [rfc5838]. [rfc5838] differentiates between AF using reserved 767 ranges of Instance IDs for each AF. 769 The architecture described in this document is fully compatible with 770 [rfc5838]. The OSPFv3 PE-CE protocol can support multiple address 771 families across a VPN backbone. All AFs redistributed from OSPFv3 772 into BGP on a PE MUST contain the BGP Extended Communities Attributes 773 as described in Section 4.4. 775 7. Security Considerations 777 The extensions described in this document are specific to the use of 778 OSPFv3 as the PE-CE protocol and do not introduce any new security 779 concerns other than those already defined in Section 6 of [rfc4577]. 781 8. IANA Considerations 783 A early draft of this document resulted in the allocation of OSPFv3 784 Route Attributes (0x0004) entry in the BGP IPv6 Address Specific 785 Extended Community. This allocation is no longer required. IANA is 786 requested to mark the OSPFv3 Route Attributes (0x0004) entry in the 787 BGP IPv6 Address Specific Extended Community registry as deprecated. 789 The BGP Extended Communities Attributes in this document are already 790 referenced in IANA. 792 9. Contributors 794 Joe Lapolito 796 10. Acknowledgments 798 The authors would like to thank Kelvin Upson, Seiko Okano, Matthew 799 Everett, Dr. Vineet Mehta, Paul Wells and Marek Karasek for their 800 support of this work. Thanks to Peter Psenak, Abhay Roy, Acee 801 Lindem, Nick Weeds, Robert Hanzl and Daniel Cohn for their last call 802 comments. Special thanks to Stewart Bryant, Stephen Farrel and Fred 803 Baker for their thorough review. 805 This document was produced using Marshall Rose's xml2rfc tool. 807 11. References 809 11.1. Normative References 811 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 812 Requirement Levels", BCP 14, RFC 2119, March 1997. 814 [rfc2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 816 [rfc2858] Bates, T., Rehkter, Y., Chandra, R., and D. Katz, 817 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 819 [rfc4360] Sangli, S., Tappan, D., and Y. Rehkter, "BGP Extended 820 Communities Attribute", RFC 4360, February 2006. 822 [rfc4364] Rosen, E. and Y. Rehkter, "BGP/MPLS IP Virtual Private 823 Networks (VPNs)", RFC 4364, February 2006. 825 [rfc4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a 826 Link State Advertisement (LSA) Options Bit to Prevent 827 Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", 828 RFC 4576, June 2006. 830 [rfc4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the 831 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual 832 Private Networks (VPNs)", RFC 4577, June 2006. 834 [rfc4659] De Clercq, J., Ooms, D., Carugi, M., and F. Lefaucheur, 835 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 836 IPv6 VPN", RFC 4659, September 2006. 838 [rfc5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 839 for IPv6", RFC 5340, July 2008. 841 [rfc5838] Mirtorabi, S., Roy, A., Barnes, M., Aggarwal, R., and A. 842 Lindem, "Support of address families in OSPFv3", 843 April 2010. 845 11.2. Informative References 847 [rfc2547] Rosen, E. and Y. Rehkter, "BGP/MPLS VPNs", RFC 2547, 848 March 1999. 850 Authors' Addresses 852 Padma Pillay-Esnault 853 Cisco Systems 854 510 McCarty Blvd 855 Milpitas, CA 95035 856 USA 858 EMail: ppe@cisco.com 860 Peter Moyer 861 Pollere, Inc 862 325M Sharon Park Drive #214 863 Menlo Park, CA 94025 864 USA 866 EMail: pete@pollere.net 868 Jeff Doyle 869 Jeff Doyle and Associates 870 9878 Teller Ct. 871 Westminster, CO 80021 872 USA 874 EMail: jdoyle@doyleassociates.net 875 Emre Ertekin 876 Booz Allen Hamilton 877 5220 Pacific Concourse Drive 878 Los Angeles, CA 90045 879 USA 881 EMail: ertekin_emre@bah.com 883 Michael Lundberg 884 Booz Allen Hamilton 885 22 Batterymarch Street 886 Boston, MA 02109 887 USA 889 EMail: lundberg_michael@bah.com