idnits 2.17.1 draft-ietf-l3vpn-ospfv3-pece-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 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 (March 8, 2010) is 5134 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 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: September 9, 2010 Pollere, Inc 6 J. Doyle 7 Jeff Doyle and Associates 8 E. Ertekin 9 M. Lundberg 10 Booz Allen Hamilton 11 March 8, 2010 13 OSPFv3 as a PE-CE routing protocol 14 draft-ietf-l3vpn-ospfv3-pece-05 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. This is known as a "BGP/MPLS IP VPN". 37 Originally only IPv4 was supported and it was later extended to 38 support IPv6 VPNs as well. Extensions were later added for the 39 support of the Open Shortest Path First protocol version 2 (OSPFv2) 40 as a PE-CE routing protocol for the IPv4 VPNs. This document extends 41 those specifications to support OSPF version 3 (OSPFv3) as a PE-CE 42 routing protocol. The OSPFv3 PE-CE functionality is identical to 43 that of OSPFv2 except for the differences described in this document. 45 Status of This Memo 47 This Internet-Draft is submitted to IETF in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF), its areas, and its working groups. Note that 52 other groups may also distribute working documents as Internet- 53 Drafts. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 The list of current Internet-Drafts can be accessed at 61 http://www.ietf.org/ietf/1id-abstracts.txt. 63 The list of Internet-Draft Shadow Directories can be accessed at 64 http://www.ietf.org/shadow.html. 66 This Internet-Draft will expire on September 9, 2010. 68 Copyright Notice 70 Copyright (c) 2010 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the BSD License. 83 This document may contain material from IETF Documents or IETF 84 Contributions published or made publicly available before November 85 10, 2008. The person(s) controlling the copyright in some of this 86 material may not have granted the IETF Trust the right to allow 87 modifications of such material outside the IETF Standards Process. 88 Without obtaining an adequate license from the person(s) controlling 89 the copyright in such materials, this document may not be modified 90 outside the IETF Standards Process, and derivative works of it may 91 not be created outside the IETF Standards Process, except to format 92 it for publication as an RFC or to translate it into languages other 93 than English. 95 Table of Contents 97 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 98 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 99 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 100 3.1. OSPFv3 Specificities . . . . . . . . . . . . . . . . . . . 5 101 4. BGP/OSPFv3 Interaction Procedures for PE Routers . . . . . . . 6 102 4.1. VRFs and OSPFv3 Instances . . . . . . . . . . . . . . . . 6 103 4.1.1. Independent OSPFv3 Instances in PEs . . . . . . . . . 6 104 4.1.2. OSPFv3 Domain Identifier . . . . . . . . . . . . . . . 6 105 4.2. OSPFv3 Areas . . . . . . . . . . . . . . . . . . . . . . . 7 106 4.3. VRFs and Routes . . . . . . . . . . . . . . . . . . . . . 7 107 4.3.1. OSPFv3 Routes on PE . . . . . . . . . . . . . . . . . 8 108 4.3.2. VPN-IPv6 Routes Received from MP-BGP . . . . . . . . . 9 109 4.4. OSPFv3 Route Extended Communities Attribute . . . . . . . 11 110 4.5. Loop Prevention Techniques . . . . . . . . . . . . . . . . 13 111 4.5.1. OSPFv3 Down Bit . . . . . . . . . . . . . . . . . . . 14 112 4.5.2. Other Possible Loops . . . . . . . . . . . . . . . . . 14 113 5. OSPFv3 Sham Links . . . . . . . . . . . . . . . . . . . . . . 14 114 5.1. Creating A Sham link . . . . . . . . . . . . . . . . . . . 15 115 5.2. OSPF Protocol On Sham link . . . . . . . . . . . . . . . . 16 116 5.3. OSPF Packet Forwarding On Sham Link . . . . . . . . . . . 16 117 6. Multiple Address Family Support . . . . . . . . . . . . . . . 17 118 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 119 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 120 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 121 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 122 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 123 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 124 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 126 1. Introduction 128 [rfc4364] offers Service Providers (SPs) a method for providing 129 Layer-3 Virtual Private Network (VPN) services to subtending customer 130 networks. Using the procedures defined in [rfc4364], provider edge 131 (PE) routers separate customer VPN routing information into Virtual 132 Routing and Forwarding (VRF) tables. The Border Gateway Protocol 133 (BGP) is used to disseminate customer network VPN routes between PE 134 VRFs configured in the same VPN. 136 The initial BGP/MPLS IP VPN specification enabled PE routers to learn 137 routes within customer sites through static routing, or through a 138 dynamic routing protocol instantiated on the PE-CE link. 139 Specifically, [rfc4364] (and its predecessor, [rfc2547]) included 140 support for dynamic routing protocols such as BGP, RIP, and OSPFv2. 141 The OSPFv2 as the Provider/Customer Edge Protocol for BGP/MPLS IP 142 Virtual Private Networks specification [rfc4577] further updates the 143 operation of OSPFv2 as the PE-CE routing protocol by detailing 144 additional extensions to enable intra-domain routing connectivity 145 between OSPFv2-based customer sites. 147 While [rfc4364] was defined for IPv4 based networks, [rfc4659] 148 extends the BGP/MPLS IP VPN framework to support IPv6 VPNs. This 149 includes the capability to connect IPv6 based sites over an IPv4 or 150 IPv6 SP backbone. It is expected that OSPFv3 will be used as the IGP 151 for some IPv6 VPNs just as the OSPFv2 was used for IPv4 VPNs. The 152 advantages of using OSPFv3 as a PE-CE protocol are the same as for 153 the IPv4 VPN deployment. 155 This document defines the mechanisms required to enable the operation 156 of OSPFv3 as the PE-CE Routing Protocol in BGP MPLS/IP VPNs. In 157 doing so, it reuses, and extends where necessary, the "BGP/MPLS IP 158 VPN" method for IPv6 VPNs defined in [rfc4659], and OSPFv2 as the 159 PE-CE routing protocol defined in [rfc4577]. This document also 160 includes the specifications for maintaining intra-domain routing 161 connectivity between OSPFv3-based customer sites across a SP 162 backbone. 164 We presuppose familiarity with the contents of [rfc4364], [rfc4659], 165 [rfc4577], [rfc4576], [rfc5340] and [rfc2328]. 167 2. Specification of Requirements 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 3. Requirements 175 The benefits and considerations associated with deploying OSPFv3 as 176 the PE-CE routing protocol are similar to those described in 177 [rfc4577]. The requirements described in Section 3 of [rfc4577] 178 remain semantically identical for the deployment of OSPFv3. 180 [rfc5340] describes the modifications required to OSPF to support 181 IPv6. In that specification, many of the fundamental mechanisms 182 associated with OSPFv2 remain unchanged for OSPFv3. Consequently, 183 the operation of OSPFv3 as the PE-CE routing protocol is very similar 184 to OSPFv2 as the PE-CE protocol. 186 3.1. OSPFv3 Specificities 188 Section 2.0 of [rfc5340] describes differences between OSPFv3 and 189 OSPFv2. Several of these changes will require modifications to the 190 architecture described in [rfc4577]. These differences and their 191 corresponding impact to [rfc4577] are described below: 193 New LSA types: 195 For an IPv6 MPLS/VPN architecture where customers interface to 196 providers through OSPFv3, traditional BGP/OSPF interactions 197 specify that VPN-IPv6 reachability information redistributed into 198 OSPFv3 will be expressed as an AS-External OSPFv3 LSAs. Instead, 199 it may be desirable to view these LSAs as inter-area-prefix LSAs. 200 For the encoding of OSPFv3 LSAs, a new OSPFv3 Route Extended 201 Community attribute is defined in Section 4.4. 203 Multiple instances over a link: 205 OSPFv3 operates on a per-link basis as opposed to OSPFv2, which 206 operates on a per-IP-subnet basis. The support of multiple OSPFv3 207 protocol instances on a link changes the architecture described in 208 [rfc4577]. [rfc4577] specifies that each interface belongs to no 209 more than one OSPF instance. For OSPFv3, multiple instances can 210 be established over a single interface, and associated with the 211 same VRF. 213 In addition to establishing multiple OSPFv3 instances over a 214 single PE-CE link, multiple OSPFv3 instances can also be 215 established across a sham link. This enables multiple OSPFv3 216 instances associated with a VRF to independently establish intra- 217 area connectivity to other OSPFv3 instances attached to a remote 218 PE VRF. Support for multiple OSPFv3 instances across the sham 219 link is described in Section 5. 221 4. BGP/OSPFv3 Interaction Procedures for PE Routers 223 4.1. VRFs and OSPFv3 Instances 225 The relationship between VRFs, interfaces, and OSPFv3 instances on a 226 PE router is described in the following section. 228 As defined in [rfc4364], a PE router can be configured with one or 229 more VRFs. Each VRF configured on the PE corresponds to a customer 230 VPN, and retains the destinations that are reachable within that VPN. 231 Each VRF may be associated with one or more interfaces, which allows 232 multiple sites to participate in the same VPN. If OSPFv3 is 233 instantiated on an interface associated with a VRF, the VRF will be 234 populated with OSPFv3 routing information. 236 As OSPFv3 supports multiple instances on a single interface, it is 237 therefore possible that multiple customer sites can connect to the 238 same interface of a PE router (e.g., through a layer 2 switch) using 239 distinct OSPFv3 instances. However, since a PE interface can be 240 associated with only one VRF, all OSPFv3 instances running on the 241 same interface MUST be associated with the same VRF. 243 4.1.1. Independent OSPFv3 Instances in PEs 245 Similar to [rfc4577], the PE must associate at least one OSPFv3 246 instance for each OSPFv3 domain to which it attaches, and each 247 instance of OSPFv3 MUST be associated with a single VRF. 249 The support of multiple PE-CE OSPFv3 instances per PE interface does 250 not change the paradigm that an OSPF instance can be associated with 251 only a single VRF. Furthermore, for each instance instantiated on 252 the interface, the PE establishes adjacencies with corresponding CEs 253 associated with the instance. Note that although multiple instances 254 may populate a common VRF, they do not leak routes to one another, 255 unless configured to do so. 257 4.1.2. OSPFv3 Domain Identifier 259 The OSPFv3 Domain ID describes the administrative domain of the OSPF 260 instance which originated the route. It has an AS wide significance 261 and is one of the parameters used to determine whether a VPN-IPv6 262 route should be translated as an Inter-area-prefix-LSA or External- 263 LSA. Each OSPFv3 instance MUST have a primary Domain ID which is 264 transported along with the VPN-IPv6 route in a BGP attribute over the 265 MPLS VPN backbone. Each OSPFv3 instance may have a set of secondary 266 Domain IDs which applies to other OSPFv3 instances within its 267 administrative domain. 269 The primary Domain ID may either be configured or may be set to a 270 value of NULL. The secondary Domain IDs are only allowed if a non- 271 null primary Domain ID is configured. The Domain ID MUST be 272 configured on a per-OSPFv3 instance basis. 274 The Domain ID is used to determine whether an incoming VPN-IPv6 route 275 belongs to the same domain as the receiving OSPFv3 instance. An 276 incoming VPN-IPv6 route is said to belong to the same domain if a 277 non-NULL incoming Domain ID matches either the local primary or one 278 of the secondary Domain IDs. If the local Domain ID and incoming 279 Domain ID are NULL, it is considered a match. 281 4.2. OSPFv3 Areas 283 Sections 4.1.4 and 4.2.3 of [rfc4577] describe the characteristics of 284 a PE router within an OSPFv2 domain. The mechanisms and expected 285 behavior described in [rfc4577] are applicable to an OSPFv3 domain. 287 4.3. VRFs and Routes 289 From the perspective of the CE, the PE appears as any other OSPFv3 290 neighbor. There is no requirement for the CE to support any 291 mechanisms of IPv6 BGP/MPLS VPNs or for the CE to have any awareness 292 of the VPNs, thereby enabling any OSPFv3 implementation to be used on 293 a CE. 295 Because the export and import policies might cause different routes 296 to be installed in different VRFs of the same OSPFv3 domain, the MPLS 297 VPN backbone cannot be considered as a single router from the 298 perspective of the domain's CEs. Rather, each CE should view its 299 connected PE as a separate router. 301 The PE uses OSPFv3 to distribute routes to CEs, and MP-BGP [rfc2858] 302 to distribute VPN-IPv6 routes to other (remote) PE routers as defined 303 in [rfc4659]. An IPv6 prefix installed in the VRF by OSPFv3 is 304 changed to a VPN-IPv6 prefix by the addition of an 8-octet Route 305 Distinguisher (RD) as discussed in Section 2 of [rfc4659]. This VPN- 306 IPv6 route can then be redistributed into MP-BGP according to an 307 export policy that adds a Route Target Extended Communities (RT) 308 attribute to the NLRI [rfc4360]. An IPv6 Address Specific BGP 309 Extended Communities attribute as described in [rfc5701] may also be 310 attached to the route. 312 Domain IDs are used to distinguish between OSPFv3 instances. When an 313 OSPFv3 distributed route is redistributed into MP-BGP, the Domain ID, 314 OSPFv3 Router ID, Area, OSPFv3 Route Type, and Options fields 315 (External Route Type) are also carried in an attribute of the MP-BGP 316 route. 318 A PE receiving a VPN-IPv6 NLRI from MP-BGP uses an import policy to 319 determine, based on the RT, whether the route is eligible to be 320 installed in one of its local VRFs. The BGP decision process selects 321 which of the eligible routes are to be installed in the associated 322 VRF, and the selected set of VPN-IPv6 routes are converted into IPv6 323 routes by removing the RD before installation. 325 An IPv6 route learned from MP-BGP and installed in a VRF might or 326 might not be redistributed into OSPFv3, depending on the local 327 configuration. For example, the PE might be configured to advertise 328 only a default route to CEs of a particular OSPFv3 instance. 329 Further, if the route is to be redistributed into multiple OSPFv3 330 instances, the route might be advertised using different LSA types in 331 different instances. 333 If an IPv6 route learned from MP-BGP is to be redistributed into a 334 particular OSPFv3 instance, the OSPFv3 Route Extended Community 335 attribute (Section 4.4) of the VPN-IPv6 route is used to determine 336 whether the OSPFv3 instance from which the route was learned is the 337 same as the OSPFv3 instance into which the route is to be 338 redistributed. 340 4.3.1. OSPFv3 Routes on PE 342 VRFs may be populated by both OSPFv3 routes from a CE or VPN-IPv6 343 routes from other PEs via MP-BGP. OSPFv3 routes are installed in a 344 VRF using the OSPFv3 decision process. As described in [rfc4577], 345 OSPFv2 routes installed in a VRF may be redistributed into BGP and 346 disseminated to other PEs participating in the VPN. At these remote 347 PEs, the VPN-IPv6 routes may be imported into a VRF and redistributed 348 into the OSPFv3 instance(s) associated with that VRF. 350 As specified in [rfc4659], routes imported and exported into a VRF 351 are controlled by the Route Target (RT) Extended Communities 352 attribute. OSPFv3 routes that are redistributed into BGP are given a 353 RT that corresponds to the VRF. This RT is examined at remote PEs. 354 In order to import a route, a VRF must have a RT that is identical to 355 the route's RT. For routes which are eligible to be imported into 356 the VRF, the standard BGP decision process is used to choose the 357 "best" route(s). 359 When a route is advertised from a CE to a PE via OSPFv3 and that 360 route is installed in the VRF associated with the CE, the route is 361 advertised to other locally attached CEs under normal OSPFv3 362 procedures. 364 The route is also redistributed into MP-BGP to be advertised to 365 remote PEs. The information necessary for accurate redistribution 366 back into OSPFv3 by the remote PEs is carried in an OSPFv3 Route 367 Extended Communities attribute (Section 4.4). The relevant local 368 OSPFv3 information encoded into the attribute is: 370 The Domain ID of the local OSPFv3 process. If no Domain ID is 371 configured, the NULL identifier is used. 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 413 No configured policy blocks the route in favor of a less-specific 414 summary route 416 No OSPFv3 route to the same prefix exists in the VRF. 418 The subsequent sections discuss the advertisement of routes learned 419 from MP-BGP, and the rules for determining what LSA types and what 420 CEs to advertise the routes to. 422 When the PE sends an LSA to a CE, it sets the DN bit in the LSA to 423 prevent looping. The DN bit is discussed in Section 4.5.1. 425 4.3.2.1. OSPF Inter-Area Routes 427 A PE advertises an IPv6 route using an Inter-Area-Prefix (type 428 0x2003) LSA under the following circumstances: 430 The OSPFv3 domain from which the IPv6 route was learned is the 431 same (as determined by the Domain ID) as the domain of the OSPFv3 432 instance into which it is to be redistributed; AND 434 The IPv6 route was advertised to a remote PE in an Intra-Area- 435 Prefix (type 0x2009) OR an Inter-Area-Prefix (type 0x2003) LSA. 437 Note that under these rules the PE represents itself as an ABR 438 regardless of whether or not the route is being advertised into the 439 same area number from which the remote PE learned it (that is, 440 whether the VPN-IPv6 route carries the same or different area 441 numbers). 443 4.3.2.2. OSPF Intra-Area Route 445 A route is advertised as an intra-area route using an Intra-Area- 446 Prefix (type 0x2009) LSA only when sham links are used, as described 447 in Section 5. Otherwise routes are advertised as either inter-area 448 (Section 4.3.2.1) or external/NSSA (Sections 4.3.2.3) routes. 450 4.3.2.3. OSPF External Routes And NSSA Routes 452 A PE considers an IPv6 route to be external under the following 453 circumstances: 455 The OSPFv3 domain from which the route was learned is different 456 (as determined by the Domain ID) from the domain of the OSPFv3 457 instance into which it is redistributed; OR 459 The OSPFv3 domain from which the route was learned is the same as 460 the domain of the OSPFv3 instance into which it is redistributed 461 AND it was advertised to the remote PE in an AS-External (type 462 0x4005) or a Type-7 (type 0x2007, NSSA) LSA; OR 464 The route was not learned from an OSPFv3 instance 466 To determine if the learned route is from a different domain, the 467 Domain ID associated with the VPN-IPv6 route (in the OSPFv3 Route 468 Extended Communities attribute or attributes) is compared with the 469 local OSPFv3 Domain ID, if configured. Compared Domain IDs are 470 considered identical if: 472 1. All six bytes are identical; or 474 2. Both Domain IDs are NULL (all zeroes). 476 Note that if the VPN-IPv6 route does not have a Domain ID in its 477 attributes, or if the local OSPFv3 instance does not have a 478 configured Domain ID, in either case the route is considered to have 479 a NULL Domain ID. 481 An IPv6 route that is determined to be external might or might not be 482 advertised to a connected CE, depending on the type of area to which 483 the PE-CE link belongs and whether there is a configured policy 484 restricting its advertisement. 486 If there are multiple external routes to the same prefix, the 487 standard OSPFv3 decision process is used to select the "best" route. 489 If the external route is to be advertised and the area type of the 490 PE/CE link is NSSA, the PE advertises the route in a Type-7 (type 491 0x2007) LSA; otherwise the external route is advertised in an AS- 492 External (type 0x4005) LSA. 494 The DN bit of the LSA advertising the external route MUST be set, as 495 described in Section 4.5.1. 497 If the VPN-IPv6 route indicates a route type-1 metric, the PE 498 advertises the external route with that metric-type; otherwise the 499 metric-type of the external IPv6 route is set to type-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 MUST have a corresponding BGP Extended Community 514 Attribute which contains and preserves the OSPFv3 information 515 attached to the 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 [rfc5701]. The OSPFv3 Route Extended Community Attribute has the 520 Sub-type value of 0x0004. It carries an OSPFv3 Domain ID, OSPFv3 521 Router ID, OSPFv3 Area ID, OSPFv3 Route type, and Options field. 523 0 1 2 3 524 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | 0x00 | 4 | OSPF Domain ID | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | OSPF Domain ID (Cont.) | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | OSPF Router ID | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Area ID | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Route Type | Options | UNUSED | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 The OSPFv3 Route Extended Community Attribute 540 This attribute is MANDATORY for all OSPFv3 routes in a VRF instance 541 on a PE router. The fields of this new BGP Extended Community 542 attribute are described in the following sections. 544 OSPFv3 Domain IDs field : 6 bytes 546 Each OSPFv3 Instance within a VRF MUST have a Domain ID. The 547 Domain ID is configured per OSPFv3 Instance. The OSPFv3 Domain ID 548 is a 6-byte number and its default value is 0. 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 OSPFv3 Area ID : 4 bytes 557 The Area ID field indicates the 32-bit Area ID to which the route 558 belongs. 560 OSPFv3 Route Types : 1 byte 562 To accommodate OSPFv3 LSA types, the OSPF Route Type field is 563 encoded as follows: 565 Route Type Route Type LSA Type Description 566 Code 567 ----------------------------------------------------------- 568 0x30 Inter-area 0x2003 Inter-area-prefix-LSA 569 0x50 External 0x4005 AS-external-LSA 570 0x70 NSSA 0x2007 NSSA-LSA 571 0x90 Intra-area-prefix 0x2009 Intra-area-prefix-LSA 573 The OSPFv3 Route Type Field Encoding 575 OSPFv3 Route Options : 1 byte 577 The Options field indicates the options that are associated with 578 the OSPFv3 route. 580 8 7 6 5 4 3 2 1 581 +---+---+---+---+---+---+---+---+ 582 | | | | | | | | E | 583 +---+---+---+---+---+---+---+---+ 585 The OSPFv3 Route Options Field 587 The least significant bit (i.e., bit E) in this field designates 588 the external metric type. If the bit is clear, the route carries 589 a Type-1 external metric; if the bit is set, the route carries a 590 Type-2 external metric. 592 4.5. Loop Prevention Techniques 594 In some topologies, it is possible for routing loops to occur due to 595 the nature and manner of route reachability propagation. One such 596 example is the case of a dual homed CE router connected to two PEs; 597 those PE routers would receive this information both through their CE 598 and their peer PE. As there is transparent transport of OSPFv3 599 routes over the BGP/MPLS backbone, it is not possible for the PE 600 routers to determine whether they are within a loop. 602 The loop scenarios in OSPFv3 topologies are identical to those in the 603 OSPFv2 topologies described in Section 4.2.5.1 and Section 4.2.5.2 of 604 [rfc4577]. Of the two loop preventions mechanisms described in the 605 sections aforementioned, only the DN bit option will be supported in 606 the OSPFv3 implementation. 608 4.5.1. OSPFv3 Down Bit 610 Section 1 and Section 3 of [rfc4576] describe the usage of the DN-bit 611 for OSPFv2 and are applicable for OSPFv3 for inter-area-prefix LSAs, 612 NSSA LSAs and External LSAs. Similarly, the DN-bit MUST be set in 613 inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these 614 are originated from a PE to a CE, to prevent those prefixes from 615 being re-advertised into BGP. As in [rfc4577], any LSA with the DN 616 bit set must not be used for route calculations. 618 The DN bit MUST be clear in all other LSA types. The OSPFv3 DN-bit 619 format is described in Appendix 4.1.1 of [rfc5340]. 621 4.5.2. Other Possible Loops 623 The mechanism described in Section 4.5.1 of this document is 624 sufficient to prevent looping if the DN bit information attached to a 625 prefix is preserved in the OSPF domain. As described in Section 626 4.2.5.3 of [rfc4576], caution must be exercised if mutual 627 redistribution is performed on a PE causing loss of loop prevention 628 information. 630 5. OSPFv3 Sham Links 632 This section modifies the specification of OSPFv2 sham links (defined 633 in Section 4.2.7 of [rfc4577]) to support OSPFv3. Support for OSPFv3 634 sham links is an OPTIONAL feature of this specification. 636 A sham link enables a VPN backbone to act as an intra-area link. It 637 is needed when two sites are connected by an intra-area "backdoor" 638 link and the inter-area MPLS VPN backbone route would be less 639 preferable due to OSPF route preference rules. The figure below 640 shows the instantiation of a sham link between two VPN sites. 642 (VPN backbone) 643 (site-1) <-------- sham link --------> (site-2) 644 CE1 -------- PE1 -------- P ---------- PE2 -------- CE2 645 | | 646 |___________________________________________________| 647 <------------ backdoor link --------------> 648 (OSPF intra-area link) 650 Sham Link 652 Much of the operation of sham links remains semantically identical to 653 what was previously specified. There are, however, several 654 differences that need to be defined to ensure the proper operation of 655 OSPFv3 sham links. 657 One of the primary differences between sham links for OSPFv3 and sham 658 links as specified in [rfc4577] are for configurations where multiple 659 OSPFv3 instances populate a VRF. It may be desirable to provide 660 separate intra-area links between these instances over the same sham 661 link. To achieve this, multiple OSPFv3 instances may be established 662 across the PE-PE sham link to provide intra-area connectivity between 663 PE-CE OSPFv3 instances. 665 Note that even though multiple OSPFv3 instances may be associated 666 with a VRF, a sham link is still thought of as a relation between two 667 VRFs. 669 Another modification to OSPFv2 sham links is that OSPFv3 sham links 670 are now identified by 128-bit endpoint addresses. Since sham links 671 end-point addresses are now 128-bits, they can no longer default to 672 the RouterID, which is a 32-bit number. Sham link endpoint addresses 673 MUST be configured. 675 Sham link endpoint addresses MUST be distributed by BGP as routeable 676 VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. As 677 specified in section 4.2.7.1 of [rfc4577], these endpoint addresses 678 MUST NOT be advertised by OSPFv3; if there is no BGP route to the 679 sham link endpoint address, that address is to appear unreachable, so 680 that the sham link appears to be down. 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 in the protocol packet header is used to 695 demultiplex multiple OSPFv3 instance protocol packets exchanged over 696 the sham link. 698 5.2. OSPF Protocol On Sham link 700 Much of the operation of OSPFv3 over a sham link is semantically the 701 same as the operation of OSPFv2 over a sham link, as described in 702 Section 4.2.7.3 of [rfc4577]. This includes the methodology for 703 sending and receiving OSPFv3 packets over sham links, as well as 704 Hello/Router Dead Intervals. Furthermore, the procedures associated 705 with the assignment of sham link metrics adhere to those set forth 706 for OSPFv2. OSPFv3 sham links are treated as on demand circuits. 708 Although the operation of the OSPFv3 protocol over the sham link is 709 the same as OSPFv2, multiple OSPFv3 instances may be instantiated 710 across this link. By instantiating multiple instances across the 711 sham link, distinct intra-area connections can be established between 712 PE-PE OSPFv3 instances associated with the endpoint addresses. 714 For example, if two OSPFv3 instances (O1, O2) attach to a VRF V1, and 715 on a remote PE, two other OSPFv3 instances (O3, O4) attach to a VRF 716 V2, it may be desirable to connect, O1 and O3 with an intra-area 717 link, and O2 and O4 with an intra-area link. This can be 718 accomplished by instantiating two OSPFv3 instances across the sham 719 link, which connects V1 and V2. O1 and O3 can be mapped to one of 720 the sham link OSPFv3 instances; O2 and O4 can be mapped to the other 721 sham link OSPFv3 instance. 723 5.3. OSPF Packet Forwarding On Sham Link 725 The rules associated with route redistribution, stated in Section 726 4.2.7.4 of [rfc4577], remain unchanged in this specification. 727 Specifically: 729 If the next hop interface for a particular route is a sham link, 730 then the PE SHOULD NOT redistribute that route into BGP as a VPN- 731 IPv6 route. 733 Any other route advertised in an LSA that is transmitted over a 734 sham link MUST also be redistributed (by the PE flooding the LSA 735 over the sham link) into BGP. 737 When redistributing these LSAs into BGP, they are encoded with the 738 OSPFv3 Route Extended Community, as defined in Section 4.4 of this 739 document. 741 When forwarding a packet, if the preferred route for that packet has 742 the sham link as its next hop interface, then the packet MUST be 743 forwarded according to the corresponding BGP route (as defined in 744 [rfc4364] and [rfc4659]). 746 6. Multiple Address Family Support 748 The support of multiple address families (AF) in OSPFv3 is described 749 in [OSPF-AF-ALT]. [OSPF-AF-ALT] differentiates between AF using 750 reserved ranges of Instance IDs for each AF. 752 The architecture described in this document is fully compatible with 753 [OSPF-AF-ALT]. The OSPFv3 PE-CE protocol can support multiple 754 address families across a MPLS VPN backbone. All AFs redistributed 755 from OSPFv3 into BGP on a PE MUST contain the OSPFv3 Route Extended 756 Community Attribute. 758 Note that since [OSPF-AF-ALT] does not support multiple AFs across 759 virtual links, this document only addresses support for unicast IPv6 760 addresses across the sham link. 762 7. Security Considerations 764 The extensions described in this document are specific to the use of 765 OSPFv3 as the PE-CE protocol and do not introduce any concerns 766 regarding the use of BGP as transport of IPv6 reachability over the 767 MPLS Backbone. The Security considerations for the transport of IPv6 768 reachability information using BGP are discussed in Section 11 of 769 [rfc4659] and are not altered. 771 The new extensions defined in this document do not introduce any new 772 security concerns other than those already defined in Section 6 of 773 [rfc4577]. 775 8. IANA Considerations 777 This document defines a new BGP attribute in the proposed "IPv6 778 Address Specific Extended Community" registry described in Section 3 779 of [rfc5701]. This document makes the following assignments in the 780 "IPv6 Address Specific Extended Community" registry. 782 Name Sub-type Value 783 ---- -------------- 784 OSPFv3 Route Attributes 0x0004 785 The OSPFv3 specific BGP Extended Community types 787 This document also defines a new "OSPFv3 Route Attribute Options" 788 registry. Represented by 8 bits, the new registry documents the 789 contents of the Options field in the OSPFv3 Route Attributes Extended 790 Community. This document makes the following assignment in the 791 "OSPFv3 Route Attribute Options" registry. 793 Value Description Reference 794 ----- ----------- --------- 795 0x01 External Metric Type [rfcThis] 797 OSPFv3 Route Attribute Options 799 Following the policies outlined in [RFC5226], the IANA policy for 800 assigning the remaining bits for the "OSPFv3 Route Attribute Options" 801 registry shall be "Standards Action": values are assigned only for 802 Standards Track RFCs approved by the IESG. 804 9. Contributors 806 Joe Lapolito 808 10. Acknowledgments 810 The authors would like to thank Kelvin Upson, Seiko Okano, Matthew 811 Everett, and Dr. Vineet Mehta for their support of this work. Thanks 812 to Peter Psenak, Abhay Roy and Acee Lindem for their last call 813 comments. 815 This document was produced using Marshall Rose's xml2rfc tool. 817 11. References 819 11.1. Normative References 821 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 822 Requirement Levels", BCP 14, RFC 2119, March 1997. 824 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 825 an IANA Considerations Section in RFCs", BCP 26, 826 RFC 5226, May 2008. 828 [rfc2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 830 [rfc2858] Bates, T., Rehkter, Y., Chandra, R., and D. Katz, 831 "Multiprotocol Extensions for BGP-4", RFC 2858, 832 June 2000. 834 [rfc4360] Sangli, S., Tappan, D., and Y. Rehkter, "BGP Extended 835 Communities Attribute", RFC 4360, February 2006. 837 [rfc4364] Rosen, E. and Y. Rehkter, "BGP/MPLS IP Virtual Private 838 Networks (VPNs)", RFC 4364, February 2006. 840 [rfc4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a 841 Link State Advertisement (LSA) Options Bit to Prevent 842 Looping in BGP/MPLS IP Virtual Private Networks 843 (VPNs)", RFC 4576, June 2006. 845 [rfc4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as 846 the Provider/Customer Edge Protocol for BGP/MPLS IP 847 Virtual Private Networks (VPNs)", RFC 4577, June 2006. 849 [rfc4659] De Clercq, J., Ooms, D., Carugi, M., and F. 850 Lefaucheur, "BGP-MPLS IP Virtual Private Network (VPN) 851 Extension for IPv6 VPN", RFC 4659, September 2006. 853 [rfc5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, 854 "OSPF for IPv6", RFC 5340, July 2008. 856 [rfc5701] Rehkter, Y., "IPv6 Address Specific BGP Extended 857 Communities Attribute", November 2009. 859 11.2. Informative References 861 [OSPF-AF-ALT] Mirtorabi, S., Roy, A., Barnes, M., Aggarwal, R., and 862 A. Lindem, "Support of address families in OSPFv3", 863 December 2009, . 866 [rfc2547] Rosen, E. and Y. Rehkter, "BGP/MPLS VPNs", RFC 2547, 867 March 1999. 869 Authors' Addresses 871 Padma Pillay-Esnault 872 Cisco Systems 873 510 McCarty Blvd 874 Milpitas, CA 95035 875 USA 877 EMail: ppe@cisco.com 878 Peter Moyer 879 Pollere, Inc 880 325M Sharon Park Drive #214 881 Menlo Park, CA 94025 882 USA 884 EMail: pete@pollere.net 886 Jeff Doyle 887 Jeff Doyle and Associates 888 9878 Teller Ct. 889 Westminster, CO 80021 890 USA 892 EMail: jdoyle@doyleassociates.net 894 Emre Ertekin 895 Booz Allen Hamilton 896 5220 Pacific Concourse Drive 897 Los Angeles, CA 90045 898 USA 900 EMail: ertekin_emre@bah.com 902 Michael Lundberg 903 Booz Allen Hamilton 904 22 Batterymarch Street 905 Boston, MA 02109 906 USA 908 EMail: lundberg_michael@bah.com