idnits 2.17.1 draft-ietf-l3vpn-ospfv3-pece-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (July 10, 2009) is 5403 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) -- Unexpected draft version: The latest known version of draft-rekhter-v6-ext-communities is -02, but you're referring to -03. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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: January 11, 2010 Pollere, Inc 6 J. Doyle 7 Jeff Doyle and Associates 8 E. Ertekin 9 M. Lundberg 10 Booz Allen Hamilton 11 July 10, 2009 13 OSPFv3 as a PE-CE routing protocol 14 draft-ietf-l3vpn-ospfv3-pece-03 16 Status of This Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may contain material 20 from IETF Documents or IETF Contributions published or made publicly 21 available before November 10, 2008. The person(s) controlling the 22 copyright in some of this material may not have granted the IETF 23 Trust the right to allow modifications of such material outside the 24 IETF Standards Process. Without obtaining an adequate license from 25 the person(s) controlling the copyright in such materials, this 26 document may not be modified outside the IETF Standards Process, and 27 derivative works of it may not be created outside the IETF Standards 28 Process, except to format it for publication as an RFC or to 29 translate it into languages other than English. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on January 11, 2010. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents in effect on the date of 56 publication of this document (http://trustee.ietf.org/license-info). 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Abstract 74 Many Service Providers (SPs) offer Virtual Private Network (VPN) 75 services to their customers using a technique in which Customer Edge 76 (CE) routers are routing peers of Provider Edge (PE) routers. The 77 Border Gateway Protocol (BGP) is used to distribute the customer's 78 routes across the provider's IP backbone network, and Multiprotocol 79 Label Switching (MPLS) is used to tunnel customer packets across the 80 provider's backbone. This is known as a "BGP/MPLS IP VPN". 81 Originally only IPv4 was supported and it was later extended to 82 support IPv6 VPNs as well. Extensions were later added for the 83 support of the Open Shortest Path First protocol version 2 (OSPFv2) 84 as a PE-CE routing protocol for the IPv4 VPNs. This document extends 85 those specifications to support OSPF version 3 (OSPFv3) as a PE-CE 86 routing protocol. The OSPFv3 PE-CE functionality is identical to 87 that of OSPFv2 except for the differences described in this document. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 92 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 93 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 94 3.1. OSPFv3 Specificities . . . . . . . . . . . . . . . . . . . 5 95 4. BGP/OSPFv3 Interaction Procedures for PE Routers . . . . . . . 6 96 4.1. VRFs and OSPFv3 Instances . . . . . . . . . . . . . . . . 6 97 4.1.1. Independent OSPFv3 Instances in PEs . . . . . . . . . 6 98 4.1.2. OSPFv3 Domain and PE-PE Link Instance Identifiers . . 7 99 4.2. OSPFv3 Areas . . . . . . . . . . . . . . . . . . . . . . . 8 100 4.3. VRFs and Routes . . . . . . . . . . . . . . . . . . . . . 8 101 4.3.1. OSPFv3 Routes on PE . . . . . . . . . . . . . . . . . 9 102 4.3.2. VPN-IPv6 Routes Received from MP-BGP . . . . . . . . . 10 103 4.4. OSPFv3 Route Extended Communities Attribute . . . . . . . 12 104 4.5. Loop Prevention Techniques . . . . . . . . . . . . . . . . 14 105 4.5.1. OSPFv3 Down Bit . . . . . . . . . . . . . . . . . . . 15 106 4.5.2. Other Possible Loops . . . . . . . . . . . . . . . . . 15 107 5. OSPFv3 Sham Links . . . . . . . . . . . . . . . . . . . . . . 15 108 5.1. Creating A Sham link . . . . . . . . . . . . . . . . . . . 16 109 5.2. OSPF Protocol On Sham link . . . . . . . . . . . . . . . . 16 110 5.3. OSPF Packet Forwarding On Sham Link . . . . . . . . . . . 17 111 6. Multiple Address Family Support . . . . . . . . . . . . . . . 18 112 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 113 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 114 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 115 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 116 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 117 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 118 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 120 1. Introduction 122 [rfc4364] offers Service Providers (SPs) a method for providing 123 Layer-3 Virtual Private Network (VPN) services to subtending customer 124 networks. Using the procedures defined in [rfc4364], provider edge 125 (PE) routers separate customer VPN routing information into Virtual 126 Routing and Forwarding (VRF) tables. The Border Gateway Protocol 127 (BGP) is used to disseminate customer network VPN routes between PE 128 VRFs configured in the same VPN. 130 The initial BGP/MPLS IP VPN specification enabled PE routers to learn 131 routes within customer sites through static routing, or through a 132 dynamic routing protocol instantiated on the PE-CE link. 133 Specifically, [rfc4364] (and its predecessor, [rfc2547]) included 134 support for dynamic routing protocols such as BGP, RIP, and OSPFv2. 135 The OSPFv2 as the Provider/Customer Edge Protocol for BGP/MPLS IP 136 Virtual Private Networks specification [rfc4577] further updates the 137 operation of OSPFv2 as the PE-CE routing protocol by detailing 138 additional extensions to enable intra-domain routing connectivity 139 between OSPFv2-based customer sites. 141 While [rfc4364] was defined for IPv4 based networks, [rfc4659] 142 extends the BGP/MPLS IP VPN framework to support IPv6 VPNs. This 143 includes the capability to connect IPv6 based sites over an IPv4 or 144 IPv6 SP backbone. It is expected that OSPFv3 will be used as the IGP 145 for some IPv6 VPNs just as the OSPFv2 was used for IPv4 VPNs. The 146 advantages of using OSPFv3 as a PE-CE protocol are the same as for 147 the IPv4 VPN deployment. 149 This document defines the mechanisms required to enable the operation 150 of OSPFv3 as the PE-CE Routing Protocol in BGP MPLS/IP VPNs. In 151 doing so, it reuses, and extends where necessary, the "BGP/MPLS IP 152 VPN" method for IPv6 VPNs defined in [rfc4659], and OSPFv2 as the 153 PE-CE routing protocol defined in [rfc4577]. This document also 154 includes the specifications for maintaining intra-domain routing 155 connectivity between OSPFv3-based customer sites across a SP 156 backbone. 158 We presuppose familiarity with the contents of [rfc4364], [rfc4659], 159 [rfc4577], [rfc4576], [rfc5340] and [rfc2328]. 161 2. Specification of Requirements 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 3. Requirements 169 The benefits and considerations associated with deploying OSPFv3 as 170 the PE-CE routing protocol are similar to those described in 171 [rfc4577]. The requirements described in Section 3 of [rfc4577] 172 remain semantically identical for the deployment of OSPFv3. 174 [rfc5340] describes the modifications required to OSPF to support 175 IPv6. In that specification, many of the fundamental mechanisms 176 associated with OSPFv2 remain unchanged for OSPFv3. Consequently, 177 the operation of OSPFv3 as the PE-CE routing protocol is very similar 178 to OSPFv2 as the PE-CE protocol. 180 3.1. OSPFv3 Specificities 182 Section 2.0 of [rfc5340] describes differences between OSPFv3 and 183 OSPFv2. Several of these changes will require modifications to the 184 architecture described in [rfc4577]. These differences and their 185 corresponding impact to [rfc4577] are described below: 187 New LSA types: 189 For an IPv6 MPLS/VPN architecture where customers interface to 190 providers through OSPFv3, traditional BGP/OSPF interactions 191 specify that VPN-IPv6 reachability information redistributed into 192 OSPFv3 will be expressed as an AS-External OSPFv3 LSAs. Instead, 193 it may be desirable to view these LSAs as AS-internal (inter-area- 194 prefix, and intra-area-prefix) LSAs. For the encoding of OSPFv3 195 LSAs, a new OSPFv3 Route Extended Community attribute is defined 196 in Section 4.4. 198 Multiple instances over a link: 200 OSPFv3 operates on a per-link basis as opposed to OSPFv2, which 201 operates on a per-IP-subnet basis. The support of multiple OSPFv3 202 protocol instances on a link changes the architecture described in 203 [rfc4577]. [rfc4577] specifies that each interface belongs to no 204 more than one OSPF instance. For OSPFv3, multiple instances can 205 be established over a single interface, and associated with the 206 same VRF. To distinguish between routes originated from different 207 OSPFv3 instances, an Instance ID field is carried in a newly- 208 defined OSPFv3 Route Extended Community attribute. 210 In addition to establishing multiple OSPFv3 instances over a 211 single PE-CE link, multiple OSPFv3 instances can also be 212 established across a sham link. This enables multiple OSPFv3 213 instances associated with a VRF to independently establish intra- 214 area connectivity to other OSPFv3 instances attached to a remote 215 PE VRF. Support for multiple OSPFv3 instances across the sham 216 link is described in Section 5. 218 4. BGP/OSPFv3 Interaction Procedures for PE Routers 220 4.1. VRFs and OSPFv3 Instances 222 The relationship between VRFs, interfaces, and OSPFv3 instances on a 223 PE router is described in the following section. 225 As defined in [rfc4364], a PE router can be configured with one or 226 more VRFs. Each VRF configured on the PE corresponds to a customer 227 VPN, and retains the destinations that are reachable within that VPN. 228 Each VRF may be associated with one or more interfaces, which allows 229 multiple sites to participate in the same VPN. If OSPFv3 is 230 instantiated on an interface associated with a VRF, the VRF will be 231 populated with OSPFv3 routing information. 233 As OSPFv3 supports multiple instances on a single interface, it is 234 therefore possible that multiple customer sites can connect to the 235 same interface of a PE router (e.g., through a layer 2 switch) using 236 distinct OSPFv3 instances. However, since a PE interface can be 237 associated with only one VRF, all OSPFv3 instances running on the 238 same interface MUST be associated with the same VRF. 240 Since multiple OSPFv3 instances can be associated with a single VRF, 241 an additional mechanism is needed to demultiplex routes across these 242 instances. When a PE supports multiple OSPFv3 instances in a VRF, a 243 local Instance ID is assigned to the "link" that spans over the MPLS 244 VPN backbone (PE-PE). As specified in [rfc5340], the Instance ID has 245 link-local significance only. Therefore, the Instance IDs assigned 246 to the PE-PE "link" need not be the same as the Instance IDs assigned 247 to the PE-CE links. By default, this Instance ID is set to NULL. 248 The OSPFv3 Domain ID and local Instance ID associated with the MPLS 249 backbone may be used to demultiplex routes for multiple instances. 250 Further details on Domain IDs and Instance IDs are provided in 251 Section 4.1.2. 253 4.1.1. Independent OSPFv3 Instances in PEs 255 Similar to [rfc4577], the PE must associate at least one OSPFv3 256 instance for each OSPFv3 domain to which it attaches, and each 257 instance of OSPFv3 MUST be associated with a single VRF. 259 The support of multiple PE-CE OSPFv3 instances per PE interface does 260 not change the paradigm that an OSPF instance can be associated with 261 only a single VRF. Furthermore, for each instance instantiated on 262 the interface, the PE establishes adjacencies with corresponding CEs 263 associated with the instance. Note that although multiple instances 264 may populate a common VRF, they do not leak routes to one another, 265 unless configured to do so. 267 4.1.2. OSPFv3 Domain and PE-PE Link Instance Identifiers 269 The OSPFv3 Domain ID describes the administrative domain of the OSPF 270 instance which originated the route. It has an AS wide significance 271 and is one of the parameters used to determine whether a VPN-IPv6 272 route should be translated as an Inter-area-prefix-LSA or External- 273 LSA. Each OSPFv3 instance MUST have a primary Domain ID which is 274 transported along with the VPN-IPv6 route in a BGP attribute over the 275 MPLS VPN backbone. Each OSPFv3 instance may have a set of secondary 276 Domain IDs which applies to other OSPFv3 instances within its 277 administrative domain. 279 The primary Domain ID may either be configured or may be set to a 280 value of NULL. The secondary Domain IDs are only allowed if a non- 281 null primary Domain ID is configured. The Domain ID may be 282 configured on a per-OSPFv3 instance basis or per-VRF. If the Domain 283 ID is configured on the VRF level, consequently all OSPFv3 instances 284 associated with the VRF will share the same Domain ID. 286 The OSPFv3 PE-PE "link" Instance ID has local significance for the 287 PE-PE "link" over the MPLS VPN backbone within a VRF. This link 288 Instance ID is used for the support of multiple OSPFv3 instances 289 within the same VRF and it is also transported along with the VPN- 290 IPv6 route in a BGP attribute over the MPLS VPN backbone. A PE-PE 291 "link" Instance ID is needed only if multiple OSPFv3 instances are 292 supported, otherwise it is set to NULL. When multiple instances are 293 associated with a VRF, each instance should have a unique PE-PE 294 "link" Instance ID. 296 The tuple is used to determine whether an 297 incoming VPN-IPv6 route belongs to the same domain as the receiving 298 OSPFv3 instance. An incoming VPN-IPv6 route is said to belong to the 299 same domain if both conditions below are met 301 1. A non-NULL incoming Domain ID matches either the local primary or 302 one of the secondary Domain IDs. If the local Domain ID and 303 incoming Domain ID are NULL, it is considered a match. 305 2. A non-NULL incoming Instance ID matches the local Instance ID. 306 If the local Instance ID and incoming Instance ID are NULL, it is 307 considered a match. 309 4.2. OSPFv3 Areas 311 Sections 4.1.4 and 4.2.3 of [rfc4577] describe the characteristics of 312 a PE router within an OSPFv2 domain. The mechanisms and expected 313 behavior described in [rfc4577] are applicable to an OSPFv3 domain. 315 4.3. VRFs and Routes 317 From the perspective of the CE, the PE appears as any other OSPFv3 318 neighbor. There is no requirement for the CE to support any 319 mechanisms of IPv6 BGP/MPLS VPNs or for the CE to have any awareness 320 of the VPNs, thereby enabling any OSPFv3 implementation to be used on 321 a CE. 323 Because the export and import policies might cause different routes 324 to be installed in different VRFs of the same OSPFv3 domain, the MPLS 325 VPN backbone cannot be considered as a single router from the 326 perspective of the domain's CEs. Rather, each CE should view its 327 connected PE as a separate router. 329 The PE uses OSPFv3 to distribute routes to CEs, and MP-BGP [rfc2858] 330 to distribute VPN-IPv6 routes to other (remote) PE routers as defined 331 in [rfc4659]. An IPv6 prefix installed in the VRF by OSPFv3 is 332 changed to a VPN-IPv6 prefix by the addition of an 8-octet Route 333 Distinguisher (RD) as discussed in Section 2 of [rfc4659]. This VPN- 334 IPv6 route can then be redistributed into MP-BGP according to an 335 export policy that adds a Route Target Extended Communities (RT) 336 attribute to the NLRI [rfc4360]. An IPv6 Address Specific BGP 337 Extended Communities attribute as described in [BGP-EXTCOMM-IPV6] may 338 also be attached to the route. 340 Domain IDs and Instance IDs are used to distinguish between OSPFv3 341 instances. When an OSPFv3-distributed route is redistributed into 342 MP-BGP, the Domain ID, OSPFv3 Router ID, Area, OSPFv3 Route Type, 343 External Route Type, Options fields, and Instance ID are also carried 344 in an attribute of the MP-BGP route. 346 A PE receiving a VPN-IPv6 NLRI from MP-BGP uses an import policy to 347 determine, based on the RT, whether the route is eligible to be 348 installed in one of its local VRFs. The BGP decision process selects 349 which of the eligible routes are to be installed in the associated 350 VRF, and the selected set of VPN-IPv6 routes are converted into IPv6 351 routes by removing the RD before installation. 353 An IPv6 route learned from MP-BGP and installed in a VRF might or 354 might not be redistributed into OSPFv3, depending on the local 355 configuration. For example, the PE might be configured to advertise 356 only a default route to CEs of a particular OSPFv3 instance. 358 Further, if the route is to be redistributed into multiple OSPFv3 359 instances, the route might be advertised using different LSA types in 360 different instances. 362 If an IPv6 route learned from MP-BGP is to be redistributed into a 363 particular OSPFv3 instance, the OSPFv3 Route Extended Community 364 attribute (Section 4.4) of the VPN-IPv6 route is used to determine 365 whether the OSPFv3 instance from which the route was learned is the 366 same as the OSPFv3 instance into which the route is to be 367 redistributed. 369 4.3.1. OSPFv3 Routes on PE 371 VRFs may be populated by both OSPFv3 routes from a CE or VPN-IPv6 372 routes from other PEs via MP-BGP. OSPFv3 routes are installed in a 373 VRF using the OSPFv3 decision process. As described in [rfc4577], 374 OSPFv2 routes installed in a VRF may be redistributed into BGP and 375 disseminated to other PEs participating in the VPN. At these remote 376 PEs, the VPN-IPv6 routes may be imported into a VRF and redistributed 377 into the OSPFv3 instance(s) associated with that VRF. 379 As specified in [rfc4659], routes imported and exported into a VRF 380 are controlled by the Route Target (RT) Extended Communities 381 attribute. OSPFv3 routes that are redistributed into BGP are given a 382 RT that corresponds to the VRF. This RT is examined at remote PEs. 383 In order to import a route, a VRF must have a RT that is identical to 384 the route's RT. For routes which are eligible to be imported into 385 the VRF, the standard BGP decision process is used to choose the 386 "best" route(s). 388 When a route is advertised from a CE to a PE via OSPFv3 and that 389 route is installed in the VRF associated with the CE, the route is 390 advertised to other locally attached CEs under normal OSPFv3 391 procedures. 393 The route is also redistributed into MP-BGP to be advertised to 394 remote PEs. The information necessary for accurate redistribution 395 back into OSPFv3 by the remote PEs is carried in an OSPFv3 Route 396 Extended Communities attribute (Section 4.4). The relevant local 397 OSPFv3 information encoded into the attribute is: 399 The Domain ID of the local OSPFv3 process. If no Domain ID is 400 configured, the NULL identifier is used. 402 The Instance ID of the PE-PE "link" 404 The Area ID of the PE-CE link. 406 The PE's Router ID associated with the OSPFv3 instance. 408 The Route Type, as determined by the LSA type from which the route 409 was learned. 411 The Options fields (External metric-type) 413 A Multi-Exit-Discriminator (MED) attribute SHOULD also be set to the 414 value of the OSPFv3 distance associated with the route plus 1, when 415 the OSPFv3 route is redistributed into the MP-BGP. 417 4.3.2. VPN-IPv6 Routes Received from MP-BGP 419 When a PE receives a valid VPN-IPv6 route from MP-BGP and has 420 identified an association with a local VRF, it must determine: 422 Whether a route to the corresponding IPv6 prefix is to be 423 installed in the VRF; 425 Whether the installed IPv6 route is to be redistributed to one or 426 more local OSPFv3 instances; and 428 What OSPFv3 LSA type is to be used when advertising the route into 429 each OSPFv3 instance 431 An IPv6 route derived from a received VPN-IPv6 route is not installed 432 in the associated local VRF if: 434 The BGP decision process identifies a better route to the 435 destination NLRI 437 A configured import policy prohibits the installation of the route 439 The PE advertises the IPv6 route learned from MP-BGP to attached CEs 440 via OSPFv3 if: 442 No configured filtering prohibits redistributing the route to 443 OSPFv3 445 No configured policy blocks the route in favor of a less-specific 446 summary route 448 No OSPFv3 route to the same prefix exists in the VRF. 450 The subsequent sections discuss the advertisement of routes learned 451 from MP-BGP, and the rules for determining what LSA types and what 452 CEs to advertise the routes to. 454 When the PE sends an LSA to a CE, it sets the DN bit in the LSA to 455 prevent looping. The DN bit is discussed in Section 4.5.1. 457 4.3.2.1. OSPF Inter-Area Routes 459 A PE advertises an IPv6 route using an Inter-Area-Prefix (type 460 0x2003) LSA under the following circumstances: 462 The OSPFv3 domain from which the IPv6 route was learned is the 463 same (as determined by the tuple) as the 464 domain of the OSPFv3 instance into which it is to be 465 redistributed; AND 467 The IPv6 route was advertised to a remote PE in an Intra-Area- 468 Prefix (type 0x2009) OR an Inter-Area-Prefix (type 0x2003) LSA. 470 Note that under these rules the PE represents itself as an ABR 471 regardless of whether or not the route is being advertised into the 472 same area number from which the remote PE learned it (that is, 473 whether the VPN-IPv6 route carries the same or different area 474 numbers). 476 4.3.2.2. OSPF Intra-Area Route 478 A route is advertised from a PE to a CE as an intra-area route using 479 an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used, 480 as described in Section 5. Otherwise routes are advertised as either 481 inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) routes. 483 4.3.2.3. OSPF External Routes And NSSA Routes 485 A PE considers an IPv6 route to be external under the following 486 circumstances: 488 The OSPFv3 domain from which the route was learned is different 489 (as determined by the tuple) from the 490 domain of the OSPFv3 instance into which it is redistributed; OR 492 The OSPFv3 domain from which the route was learned is the same as 493 the domain of the OSPFv3 instance into which it is redistributed 494 AND it was advertised to the remote PE in an AS-External (type 495 0x4005) or a Type-7 (type 0x2007, NSSA) LSA; OR 497 The route was not learned from an OSPFv3 instance 499 To determine if the learned route is from a different domain, the 500 tuple associated with the VPN-IPv6 route (in 501 the OSPFv3 Route Extended Communities attribute or attributes) is 502 compared with the local OSPFv3 Domain ID and Instance ID, if 503 configured. Compared Domain IDs are considered identical if: 505 1. All six bytes are identical; or 507 2. Both Domain IDs are NULL (all zeroes). 509 Note that if the VPN-IPv6 route does not have a Domain ID in its 510 attributes, or if the local OSPFv3 instance does not have a 511 configured Domain ID, in either case the route is considered to have 512 a NULL Domain ID. 514 An IPv6 route that is determined to be external might or might not be 515 advertised to a connected CE, depending on the type of area to which 516 the PE-CE link belongs and whether there is a configured policy 517 restricting its advertisement. 519 If there are multiple external routes to the same prefix, the 520 standard OSPFv3 decision process is used to select the "best" route. 522 If the external route is to be advertised and the area type of the 523 PE/CE link is NSSA, the PE advertises the route in a Type-7 (type 524 0x2007) LSA; otherwise the external route is advertised in an AS- 525 External (type 0x4005) LSA. 527 The DN bit of the LSA advertising the external route MUST be set, as 528 described in Section 4.5.1. 530 If the VPN-IPv6 route indicates a route type-1 metric, the PE 531 advertises the external route with that metric-type; otherwise the 532 metric-type of the external IPv6 route is set to type-2 by default. 534 4.4. OSPFv3 Route Extended Communities Attribute 536 OSPFv3 routes from one site are translated and delivered 537 transparently to the remote site as BGP VPN-IPv6 routes. The 538 original OSPFv3 routes carry OSPFv3 specific information which need 539 to be communicated to the remote PE to ensure transparency. BGP 540 extended communities are used to carry the needed information to 541 enable the receiving side to reconstruct a database just as in the 542 OSPFv2 case. 544 All OSPFv3 routes added to the VRF routing table on a PE router are 545 examined to create a corresponding VPN-IPv6 route in BGP. Each of 546 the OSPFv3 routes MUST have a corresponding BGP Extended Community 547 Attribute which contains and preserves the OSPFv3 information 548 attached to the original OSPFv3 route. 550 This document defines a new BGP attribute in the proposed "IPv6 551 Address Specific Extended Community" registry described in Section 3 552 of [BGP-EXTCOMM-IPV6]. The OSPFv3 Route Extended Community Attribute 553 has the Sub-type value of 0x0004. It carries an OSPFv3 Domain ID, 554 OSPFv3 Router ID, OSPFv3 Area ID, OSPFv3 Route type, Options, and an 555 OSPFv3 Instance ID field. 557 0 1 2 3 558 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | 0x00 | 4 | OSPF Domain ID | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | OSPF Domain ID (Cont.) | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | OSPF Router ID | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Area ID | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Route Type | Options |OSPF InstanceID| UNUSED | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 The OSPFv3 Route Extended Community Attribute 574 This attribute is MANDATORY for all OSPFv3 routes in a VRF instance 575 on a PE router. The fields of this new BGP Extended Community 576 attribute are described in the following sections. 578 OSPFv3 Domain IDs field : 6 bytes 580 Each OSPFv3 Instance within a VRF MUST have a Domain ID. The 581 Domain ID may be configured at the VRF level or at the OSPFv3 582 Instance level. The OSPFv3 Domain ID is a 6-byte number and its 583 default value if none is configured should be NULL. 585 OSPFv3 Router ID field : 4 bytes 587 The OSPFv3 Router ID is a 32 bit number as in OSPFv2. This field 588 is OPTIONAL and may be set to 0. 590 OSPFv3 Area ID : 4 bytes 592 The Area ID field indicates the 32-bit Area ID to which the route 593 belongs. 595 OSPFv3 Route Types : 1 byte 597 To accommodate OSPFv3 LSA types, the OSPF Route Type field is 598 encoded as follows: 600 Route Type Route Type LSA Type Description 601 Code 602 ----------------------------------------------------------- 603 0x30 Inter-area 0x2003 Inter-area-prefix-LSA 604 0x50 External 0x2005 AS-external-LSA 605 0x70 NSSA 0x2007 NSSA-LSA 606 0x90 Intra-area-prefix 0x2009 Intra-area-prefix-LSA 608 The OSPFv3 Route Type Field Encoding 610 OSPFv3 Options : 1 byte 612 The Options field indicates if the route carries a type-1 or 613 type-2 metric. Setting the least significant bit in the field 614 indicates that the route carries a External type-2 metric. 616 OSPFv3 Instance ID field : 1 byte 618 The OSPFv3 Instance ID field is defined to carry the OSPFv3 619 Instance ID which is a one-byte number. The OSPFv3 Instance ID is 620 configured for the "link" simulated by the MPLS VPN backbone. 621 This attribute MAY be present whether several OSPFv3 instances are 622 defined or not. The Instance ID default value is 0. 624 4.5. Loop Prevention Techniques 626 In some topologies, it is possible for routing loops to occur due to 627 the nature and manner of route reachability propagation. One such 628 example is the case of a dual homed CE router connected to two PEs; 629 those PE routers would receive this information both through their CE 630 and their peer PE. As there is transparent transport of OSPFv3 631 routes over the BGP/MPLS backbone, it is not possible for the PE 632 routers to determine whether they are within a loop. 634 The loop scenarios in OSPFv3 topologies are identical to those in the 635 OSPFv2 topologies described in Section 4.2.5.1 and Section 4.2.5.2 of 636 [rfc4577]. Of the two loop preventions mechanisms described in the 637 sections aforementioned, only the DN bit option will be supported in 638 the OSPFv3 implementation. 640 4.5.1. OSPFv3 Down Bit 642 Section 1 and Section 3 of [rfc4576] describe the usage of the DN-bit 643 for OSPFv2 and are applicable for OSPFv3 for inter-area-prefix LSAs, 644 NSSA LSAs and External LSAs. Similarly, the DN-bit must be set in 645 inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these 646 are originated from a PE to a CE, to prevent those prefixes from 647 being re-advertised into BGP. As in [rfc4577], any LSA with the DN 648 bit set must not be used for route calculations. 650 The DN bit MUST be clear in all other LSA types. The OSPFv3 DN-bit 651 format is described in Appendix 4.1.1 of [rfc5340]. 653 4.5.2. Other Possible Loops 655 The mechanism described in Section 4.5.1 of this document is 656 sufficient to prevent looping if the DN bit information attached to a 657 prefix is preserved in the OSPF domain. As described in Section 658 4.2.5.3 of [rfc4576], caution must be exercised if mutual 659 redistribution is performed on a PE causing loss of loop prevention 660 information. 662 5. OSPFv3 Sham Links 664 This section modifies the specification of OSPFv2 sham links (defined 665 in Section 4.2.7 of [rfc4577]) to support OSPFv3. Support for OSPFv3 666 sham links is an OPTIONAL feature of this specification. 668 A sham link enables a VPN backbone to act as an intra-area link. It 669 is needed when two sites are connected by an intra-area "backdoor" 670 link and the inter-area MPLS VPN backbone route would be less 671 preferable due to OSPF route preference rules. The figure below 672 shows the instantiation of a sham link between two VPN sites. 674 (VPN backbone) 675 (site-1) <-------- sham link --------> (site-2) 676 CE1 -------- PE1 -------- P ---------- PE2 -------- CE2 677 | | 678 |___________________________________________________| 679 <------------ backdoor link --------------> 680 (OSPF intra-area link) 682 Sham Link 684 Much of the operation of sham links remains semantically identical to 685 what was previously specified. There are, however, several 686 differences that need to be defined to ensure the proper operation of 687 OSPFv3 sham links. 689 One of the primary differences between sham links for OSPFv3 and sham 690 links as specified in [rfc4577] are for configurations where multiple 691 OSPFv3 instances populate a VRF. It may be desirable to provide 692 separate intra-area links between these instances over the same sham 693 link. To achieve this, multiple OSPFv3 instances may be established 694 across the PE-PE sham link to provide intra-area connectivity between 695 PE-CE OSPFv3 instances. 697 Note that even though multiple OSPFv3 instances may be associated 698 with a VRF, a sham link is still thought of as a relation between two 699 VRFs. 701 Another modification to OSPFv2 sham links is that OSPFv3 sham links 702 are now identified by 128-bit endpoint addresses. Since sham links 703 end-point addresses are now 128-bits, they can no longer default to 704 the RouterID, which is a 32-bit number. Sham link endpoint addresses 705 MUST be configured. 707 Sham link endpoint addresses MUST be distributed by BGP as routeable 708 VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. As 709 specified in [rfc4577], these endpoint addresses MUST NOT be 710 advertised by OSPFv3. 712 If there is a BGP route to the remote sham link endpoint address, the 713 sham link appears to be up. Conversely, if there is no BGP route to 714 the sham link endpoint address, the sham link appears to be down. 716 5.1. Creating A Sham link 718 The procedures for creating an OSPFv3 sham link are identical to 719 those specified in Section 4.2.7.2 of [rfc4577]. Note that the 720 creation of OSPFv3 sham links requires the configuration of both 721 local and remote 128-bit sham link endpoint addresses. The local 722 Sham link endpoint address associated with a VRF MAY be used by all 723 OSPFv3 instances that are attached to that VRF. The OSPFv3 PE-PE 724 "link" Instance ID is used to demultiplex multiple OSPFv3 instance 725 protocol packets exchanged over the sham link. 727 5.2. OSPF Protocol On Sham link 729 Much of the operation of OSPFv3 over a sham link is semantically the 730 same as the operation of OSPFv2 over a sham link, as described in 731 Section 4.2.7.3 of [rfc4577]. This includes the methodology for 732 sending and receiving OSPFv3 packets over sham links, as well as 733 Hello/Router Dead Intervals. Furthermore, the procedures associated 734 with the assignment of sham link metrics adhere to those set forth 735 for OSPFv2. OSPFv3 sham links are treated as on demand circuits. 737 Although the operation of the OSPFv3 protocol over the sham link is 738 the same as OSPFv2, multiple OSPFv3 instances may be instantiated 739 across this link. By instantiating multiple instances across the 740 sham link, distinct intra-area connections can be established between 741 PE-PE OSPFv3 instances associated with the endpoint addresses. 743 For example, if two OSPFv3 instances (O1, O2) attach to a VRF V1, and 744 on a remote PE, two other OSPFv3 instances (O3, O4) attach to a VRF 745 V2, it may be desirable to connect, O1 and O3 with an intra-area 746 link, and O2 and O4 with an intra-area link. This can be 747 accomplished by instantiating two OSPFv3 instances across the sham 748 link, which connects V1 and V2. O1 and O3 can be mapped to one of 749 the sham link OSPFv3 instances; O2 and O4 can be mapped to the other 750 sham link OSPFv3 instance. 752 One difference from Section 4.2.7.3 of [rfc4577] is the addition of 753 Type 0x2009 intra-area-prefix LSAs, and the flooding of these LSAs 754 across the sham link. Furthermore, where prefixes associated with 755 OSPFv2 sham links are advertised in Type-1 LSAs, prefixes associated 756 with OSPFv3 sham links are advertised as OSPFv3 Type 0x2009 LSAs. 757 This change is required based on [rfc5340], which states that 758 loopback interfaces are advertised in intra-area-prefix LSAs. 760 5.3. OSPF Packet Forwarding On Sham Link 762 The rules associated with route redistribution, stated in Section 763 4.2.7.4 of [rfc4577], remain unchanged in this specification. 764 Specifically: 766 If the next hop interface for a particular route is a sham link, 767 then the PE SHOULD NOT redistribute that route into BGP as a VPN- 768 IPv6 route. 770 Any other route advertised in an LSA that is transmitted over a 771 sham link MUST also be redistributed (by the PE flooding the LSA 772 over the sham link) into BGP. 774 When redistributing these LSAs into BGP, they are encoded with the 775 OSPFv3 Route Extended Community, as defined in Section 4.4 of this 776 document. 778 When forwarding a packet, if the preferred route for that packet has 779 the sham link as its next hop interface, then the packet MUST be 780 forwarded according to the corresponding BGP route (as defined in 781 [rfc4364] and [rfc4659]). 783 6. Multiple Address Family Support 785 The support of multiple address families (AF) in OSPFv3 is described 786 in [OSPF-AF-ALT]. [OSPF-AF-ALT] differentiates between AF using 787 reserved ranges of Instance IDs for each AF. 789 The architecture described in this document is fully compatible with 790 [OSPF-AF-ALT]. The OSPFv3 PE-CE protocol can support multiple 791 address families across a MPLS VPN backbone. All AFs redistributed 792 from OSPFv3 into BGP on a PE MUST contain the OSPFv3 Route Extended 793 Community Attribute. 795 Note that since [OSPF-AF-ALT] does not support multiple AFs across 796 virtual links, this document only addresses support for unicast IPv6 797 addresses across the sham link. 799 7. Security Considerations 801 The extensions described in this document are specific to the use of 802 OSPFv3 as the PE-CE protocol and do not introduce any concerns 803 regarding the use of BGP as transport of IPv6 reachability over the 804 MPLS Backbone. The Security considerations for the transport of IPv6 805 reachability information using BGP are discussed in Section 11 of 806 [rfc4659] and are not altered. 808 The new extensions defined in this document do not introduce any new 809 security concerns other than those already defined in Section 6 of 810 [rfc4577]. 812 8. IANA Considerations 814 This document defines a new BGP attribute in the proposed "IPv6 815 Address Specific Extended Community" registry described in Section 3 816 of [BGP-EXTCOMM-IPV6]. This document makes the following assignments 817 in the "IPv6 Address Specific Extended Community" registry. 819 Name Sub-type Value 820 ---- -------------- 821 OSPFv3 Route Attributes 0x0004 823 The OSPFv3 specific BGP Extended Community types 825 9. Contributors 827 Joe Lapolito 829 10. Acknowledgments 831 The authors would like to thank Kelvin Upson, Seiko Okano, Matthew 832 Everett, and Dr. Vineet Mehta for their support of this work. 834 This document was produced using Marshall Rose's xml2rfc tool. 836 11. References 838 11.1. Normative References 840 [RFC2119] Bradner, S., "Key words for use in RFC's to 841 Indicate Requirement Levels", BCP 14, RFC 2119, 842 March 1997. 844 [rfc2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 846 [rfc2547] Rosen, E. and Y. Rehkter, "BGP/MPLS VPNs", 847 RFC 2547, March 1999. 849 [rfc2858] Bates, T., Rehkter, Y., Chandra, R., and D. Katz, 850 "Multiprotocol Extensions for BGP-4", RFC 2858, 851 June 2000. 853 [rfc4360] Sangli, S., Tappan, D., and Y. Rehkter, "BGP 854 Extended Communities Attribute", RFC 4360, 855 February 2006. 857 [rfc4364] Rosen, E. and Y. Rehkter, "BGP/MPLS IP Virtual 858 Private Networks (VPNs)", RFC 4364, 859 February 2006. 861 [rfc4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, 862 "Using a Link State Advertisement (LSA) Options 863 Bit to Prevent Looping in BGP/MPLS IP Virtual 864 Private Networks (VPNs)", RFC 4576, June 2006. 866 [rfc4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, 867 "OSPF as the Provider/Customer Edge Protocol for 868 BGP/MPLS IP Virtual Private Networks (VPNs)", 869 RFC 4577, June 2006. 871 [rfc4659] De Clercq, J., Ooms, D., Carugi, M., and F. 872 Lefaucheur, "BGP-MPLS IP Virtual Private Network 873 (VPN) Extension for IPv6 VPN", RFC 4659, 874 September 2006. 876 [rfc5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, 877 "OSPF for IPv6", RFC 5340, July 2008. 879 11.2. Informative References 881 [BGP-EXTCOMM-IPV6] Rehkter, Y., "IPv6 Address Specific BGP Extended 882 Communities Attribute", October 2008, . 886 [OSPF-AF-ALT] Mirtorabi, S., Roy, A., Barnes, M., Aggarwal, R., 887 and A. Lindem, "Support of address families in 888 OSPFv3", October 2008, . 891 Authors' Addresses 893 Padma Pillay-Esnault 894 Cisco Systems 895 510 McCarty Blvd 896 Milpitas, CA 95035 897 USA 899 EMail: ppe@cisco.com 901 Peter Moyer 902 Pollere, Inc 903 325M Sharon Park Drive #214 904 Menlo Park, CA 94025 905 USA 907 EMail: pete@pollere.net 909 Jeff Doyle 910 Jeff Doyle and Associates 911 9878 Teller Ct. 912 Westminster, CO 80021 913 USA 915 EMail: jdoyle@doyleassociates.net 916 Emre Ertekin 917 Booz Allen Hamilton 918 5220 Pacific Concourse Drive 919 Los Angeles, CA 90045 920 USA 922 EMail: ertekin_emre@bah.com 924 Michael Lundberg 925 Booz Allen Hamilton 926 22 Batterymarch Street 927 Boston, MA 02109 928 USA 930 EMail: lundberg_michael@bah.com