idnits 2.17.1 draft-ietf-l3vpn-ospf-2547-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1154. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1165. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1172. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1178. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6616 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) == Unused Reference: 'BGP' is defined on line 1132, but no explicit reference was found in the text == Unused Reference: 'RIP' is defined on line 1135, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric C. Rosen 3 Internet Draft Peter Psenak 4 Expiration Date: August 2006 Padma Pillay-Esnault 5 Updates: RFC4364 Cisco Systems, Inc. 7 February 2006 9 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs 11 draft-ietf-l3vpn-ospf-2547-06.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 Many Service Providers offer Virtual Private Network ("VPN") services 38 to their customers, using a technique in which customer edge routers 39 ("CE routers") are routing peers of provider edge routers ("PE 40 routers"). The Border Gateway Protocol ("BGP") is used to distribute 41 the customer's routes across the provider's IP backbone network, and 42 Multiprotocol Label Switching ("MPLS") is used to tunnel customer 43 packets across the provider's backbone. This is known as a "BGP/MPLS 44 IP VPN". The base specification for BGP/MPLS IP VPNs presumes that 45 the routing protocol on the interface between a PE router and a CE 46 router is BGP. This document extends that specification by allowing 47 the routing protocol on the PE/CE interface to be the Open Shortest 48 Path First ("OSPF") protocol. 50 This document updates draft-ietf-l3vpn-rfc2547bis-03.txt. 52 Table of Contents 54 1 Specification of Requirements ........................ 3 55 2 Introduction ......................................... 3 56 3 Requirements ......................................... 4 57 4 BGP/OSPF Interaction Procedures for PE routers ....... 6 58 4.1 Overview ............................................. 6 59 4.1.1 VRFs and OSPF Instances .............................. 6 60 4.1.2 VRFs and Routes ...................................... 6 61 4.1.3 Inter-Area, Intra-Area, and External Routes .......... 7 62 4.1.4 PEs and OSPF Area 0 .................................. 9 63 4.1.5 Prevention of Loops .................................. 9 64 4.2 Details .............................................. 10 65 4.2.1 Independent OSPF Instances in PEs .................... 10 66 4.2.2 Router ID ............................................ 10 67 4.2.3 OSPF Areas ........................................... 10 68 4.2.4 OSPF Domain Identifiers .............................. 11 69 4.2.5 Loop Prevention ...................................... 12 70 4.2.5.1 The DN Bit ........................................... 12 71 4.2.5.2 Use of OSPF Route Tags ............................... 13 72 4.2.5.3 Other Possible Loops ................................. 14 73 4.2.6 Handling LSAs from the CE ............................ 14 74 4.2.7 Sham Links ........................................... 17 75 4.2.7.1 Intra-Area Routes .................................... 17 76 4.2.7.2 Creating Sham Links .................................. 18 77 4.2.7.3 OSPF Protocol on Sham Links .......................... 18 78 4.2.7.4 Routing and Forwarding on Sham Links ................. 19 79 4.2.8 VPN-IPv4 routes received via BGP ..................... 20 80 4.2.8.1 External Routes ...................................... 21 81 4.2.8.2 Summary Routes ....................................... 22 82 4.2.8.3 NSSA Routes .......................................... 23 83 5 IANA Considerations .................................. 23 84 6 Security Considerations .............................. 23 85 7 Acknowledgments ...................................... 24 86 8 Authors' Addresses ................................... 24 87 9 Normative References ................................. 25 88 10 Informative References ............................... 25 89 11 Full Copyright Statement ............................. 25 90 12 Intellectual Property ................................ 26 92 1. Specification of Requirements 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. Introduction 100 [VPN] describes a method by which a Service Provider (SP) can use its 101 IP backbone to provide a VPN ("Virtual Private Network") service to 102 customers. In that method, a customer's edge devices ("CE" devices) 103 are connected to the provider's edge routers ("PE" routers). If the 104 CE device is a router, then the PE router may become a routing peer 105 of the CE router (in some routing protocol), and may as a result 106 learn the routes which lead to the CE's site and which need to be 107 distributed to other PE routers that attach to the same VPN. 109 The PE routers which attach to a common VPN use BGP ("Border Gateway 110 Protocol") to distribute the VPN's routes to each other. A CE router 111 can then learn the routes to other sites in the VPN by peering with 112 its attached PE router in a routing protocol. CE routers at 113 different sites do not, however, peer with each other. 115 It can be expected that many VPNs will use OSPF ("Open Shortest Path 116 First") as their IGP ("Interior Gateway Protocol"), i.e., the routing 117 protocol used by a network for the distribution of internal routes 118 within that network). This does not necessarily mean that the PE 119 routers need to use OSPF to peer with the CE routers. Each site in a 120 VPN can use OSPF as its intra-site routing protocol, while using, 121 e.g., BGP or RIP ("Routing Information Protocol") to distribute 122 routes to a PE router. However, it is certainly convenient, when 123 OSPF is being used intra-site, to use it on the PE-CE link as well, 124 and [VPN] explicitly allows this. 126 Like anything else, the use of OSPF on the PE-CE link has advantages 127 and disadvantages. The disadvantage to using OSPF on the PE-CE link 128 is that it gets the SP's PE router involved, however peripherally, in 129 a VPN site's IGP. The advantages though are: 131 - The administrators of the CE router need not have any expertise 132 in any routing protocol other than OSPF. 134 - The CE routers do not need to have support for any routing 135 protocols other than OSPF. 137 - If a customer is transitioning his network from a traditional 138 OSPF backbone to the VPN service described in [VPN], the use of 139 OSPF on the PE-CE link eases the transitional issues. 141 It seems likely that some SPs and their customers will resolve these 142 trade-offs in favor of the use of OSPF on the PE-CE link. Thus we 143 need to specify the procedures which must be implemented by a PE 144 router in order to make this possible. (No special procedures are 145 needed in the CE router though; CE routers just run whatever OSPF 146 implementations they may have.) 148 3. Requirements 150 Consider a set of VPN sites which are thought of as being in the same 151 "OSPF domain". Two sites are considered to be in the same OSPF domain 152 if it is intended that routes from one site to the other be 153 considered to be intra-network routes. A set of OSPF sites in the 154 same domain will almost certainly be a set of sites which together 155 constitute an "intranet", and each of which runs OSPF as its intra- 156 site routing protocol. 158 Per [VPN], the VPN routes are distributed among the PE routers by 159 BGP. If the PE uses OSPF to distribute routes to the CE router, the 160 standard procedures governing BGP/OSPF interactions [OSPFv2] would 161 cause routes from one site to be delivered to another in type 5 LSAs 162 ("Link State Advertisements"), as "AS-external" routes. This is 163 undesirable; it would be much better to deliver such routes in type 3 164 LSAs (as inter-area routes), so that they can be distinguished from 165 any "real" AS-external routes that may be circulating in the VPN. 166 (That is, so that they can be distinguished by OSPF from routes which 167 really do not come from within the VPN.) Hence it is necessary for 168 the PE routers to implement a modified version of the BGP/OSPF 169 interaction procedures. 171 In fact, we would like to have a very general set of procedures which 172 allows a customer to easily replace a legacy private OSPF backbone 173 with the VPN service. We would like this procedure to meet the 174 following set of requirements: 176 - The procedures should not make assumptions about the OSPF 177 topology. In particular, it should not be assumed that customer 178 sites are OSPF stub sites or NSSA ("Not So Stubby Area") sites. 179 Nor should it be assumed that a customer site contains only one 180 OSPF area, or that it has no area 0 routers. 182 - If VPN sites A and B are in the same OSPF domain, then routes 183 from one should be presented to the other as OSPF intra-network 184 routes. In general, this can be done by presenting such routes 185 as inter-area routes, in type 3 LSAs. 187 Note that this allows two VPN sites to be connected via an "OSPF 188 backdoor link". That is, one can have an OSPF link between the 189 two sites which is used only when the VPN backbone is 190 unavailable. (This would not be possible with the ordinary 191 BGP/OSPF interaction procedures. The ordinary procedures would 192 present routes via the VPN backbone as AS-external routes, and 193 these could never be preferred to intra-network routes.) This 194 may be very useful during a period of transition from a legacy 195 OSPF backbone to a VPN backbone. 197 - It should be possible to make use of an "OSPF backdoor link" 198 between two sites, even if the two sites are in the same OSPF 199 area, and neither of the routers attached to the inter-site 200 backdoor link is an area 0 router. This can also be very useful 201 during a transition period, and eliminates any need to 202 reconfigure the sites' routers to be ABRs ("Area Border 203 Routers"). 205 Assuming that it is desired to have the route via the VPN 206 backbone be preferred to the backdoor route, the VPN backbone 207 itself must be presented to the CE routers at each site as a link 208 between the two PE routers to which the CE routers are 209 respectively attached. 211 - CE routers, connected to PE routers of the VPN service, may 212 themselves function as OSPF backbone (area 0) routers. An OSPF 213 backbone may even consist of several "segments" which are 214 interconnected themselves only via the VPN service. In such a 215 scenario, full intercommunication between sites connected to 216 different segments of the OSPF backbone should still be possible. 218 - The transition from the legacy private OSPF backbone to the VPN 219 service must be simple and straightforward. The transition is 220 likely to be phased, such that customer sites are migrated one by 221 one from the legacy private OSPF backbone to the VPN service. 222 During the transition, any given site might be connected to the 223 VPN service, to the legacy OSPF backbone, or to both. Complete 224 connectivity among all such sites must be maintained. 226 Since the VPN service is to replace the legacy backbone, it must 227 be possible, by suitable adjustment of the OSPF metrics, to make 228 OSPF prefer routes which traverse the SP's VPN backbone to 229 alternative routes which do not. 231 - The OSPF metric assigned to a given route should be carried 232 transparently over the VPN backbone. 234 Routes from sites which are not in the same OSPF domain will appear 235 as AS-external routes. 237 We presuppose familiarity with the contents of [OSPFv2], including 238 the OSPF LSA types, and will refer without further exegesis to type 239 1, 2, 3, etc., LSAs. Familiarity with [VPN] is also presupposed. 241 4. BGP/OSPF Interaction Procedures for PE routers 243 4.1. Overview 245 4.1.1. VRFs and OSPF Instances 247 A PE router which attaches to more than one OSPF domain MUST run an 248 independent instance of OSPF for each domain. If the PE is running 249 OSPF as its IGP ("Interior Gateway Protocol"), the instance of OSPF 250 running as the IGP must be separate and independent from any other 251 instance of OSPF which the PE is running. (Whether these instances 252 are realized as separate processes, or merely as separate contexts of 253 a common process, is an implementation matter.) Each interface that 254 attaches to a VPN site belongs to no more than one OSPF instance. 256 [VPN] defines the notion of a Per-Site Routing and Forwarding Table, 257 or VRF. Each VRF is associated with a set of interfaces. If a VRF 258 is associated with a particular interface, and that interface belongs 259 to a particular OSPF instance, then that OSPF instance is said to be 260 associated with the VRF. If two interfaces belong to the same OSPF 261 instance, then both interfaces must be associated with the same VRF. 263 If an interface attaches a PE to a CE, and that interface is 264 associated with a VRF, we will speak of the CE as being associated 265 with the VRF. 267 4.1.2. VRFs and Routes 269 OSPF is used to distribute routes from a CE to a PE. The standard 270 OSPF decision process is used to install the best OSPF-distributed 271 routes in the VRF. 273 Per [VPN], BGP is used to distribute VPN-IPv4 routes among PE 274 routers. An OSPF route installed in a VRF may be "exported" by being 275 redistributed into BGP as a VPN-IPv4 route. It may then be 276 distributed by BGP to other PEs. At the other PEs, a VPN-IPv4 route 277 may "imported" by a VRF, and may then be redistributed into one or 278 more of the OSPF instances associated with that VRF. 280 Import from and export to particular VRFs is controlled by the use of 281 the Route Target Extended Communities attribute (or more simply, 282 "Route Target" or "RT"), as specified in [VPN]. 284 A VPN-IPv4 route is "eligible for import" into a particular VRF if 285 its Route Target is identical to one of the VRF's import Route 286 Targets. The standard BGP decision process is used to select, from 287 among the routes eligible for import, the set of VPN-IPv4 routes to 288 be "installed" in the VRF. 290 If a VRF contains both an OSPF-distributed route and a VPN-IPv4 route 291 for the same IPv4 prefix, then the OSPF-distributed route is 292 preferred. In general, this means that forwarding is done according 293 to the OSPF route. The one exception to this rule has to do with the 294 "sham link". If the next hop interface for an installed (OSPF- 295 distributed) route is the sham link, forwarding is done according to 296 a corresponding BGP route. This is detailed in section 4.2.7.4. 298 To meet the requirements of section 3, a PE that installs a 299 particular route into a particular VRF needs to know whether that 300 route was originally an OSPF route, and if so, whether the OSPF 301 instance from which it was redistributed into BGP is in the same 302 domain as the OSPF instances into which the route may be 303 redistributed. Therefore a domain identifier is encoded as a BGP 304 Extended Communities attribute [EXTCOMM], and distributed by BGP 305 along with the VPN-IPv4 route. The route's OSPF metric and OSPF 306 route type are also carried as BGP attributes of the route. 308 4.1.3. Inter-Area, Intra-Area, and External Routes 310 If a PE installs a particular VPN-IPv4 route (learned via BGP) in a 311 VRF, and if this is the preferred BGP route for the corresponding 312 IPv4 prefix, then the corresponding IPv4 route is then "eligible for 313 redistribution" into each OSPF instance that is associated with the 314 VRF. As a result, it may be advertised to each CE in an LSA. 316 Whether a route which is eligible for redistribution into OSPF is 317 actually redistributed into a particular OSPF instance may depend 318 upon the configuration. For instance, the PE may be configured to 319 only distribute the default route into a given OSPF instance. In 320 this case, the routes which are eligible for redistribution would not 321 actually be redistributed. 323 In the following, we discuss the procedures for redistributing a 324 BGP-distributed VPN-IPv4 route into OSPF; these are the procedures to 325 be followed whenever such a route is eligible to be redistributed 326 into OSPF and the configuration does not prevent such redistribution. 328 If the route is from a different OSPF domain than OSPF instance into 329 which it is being redistributed, or if the route is not from an OSPF 330 domain at all, then the route is considered to be an external route. 332 If the route is from the same OSPF domain as the OSPF instance into 333 which it is being redistributed, and if it was originally advertised 334 to a PE as an OSPF external route or an OSPF NSSA route, it will be 335 treated as an external route. Following the normal OSPF procedures, 336 external routes may be advertised to the CE in type 5 LSAs, or in 337 type 7 LSAs, or not at all, depending on the type of area to which 338 the PE/CE link belongs. 340 If the route is from the same OSPF domain as the OSPF instance into 341 which it is being redistributed, and and if it was originally 342 advertised to a PE as an inter-area or intra-area route, the route 343 will generally be advertised to the CE as an inter-area route (in a 344 type 3 LSA). 346 As a special case, suppose PE1 attaches to CE1, and PE2 attaches to 347 CE2, where: 349 - the OSPF instance containing the PE1-CE1 link and the OSPF 350 instance containing the PE2-CE2 link are in the same OSPF domain, 351 and 353 - the PE1-CE1 and PE2-CE2 links are in the same OSPF area A (as 354 determined by the configured OSPF area number), 356 then PE1 may flood to CE1 a type 1 LSA advertising a link to PE2, and 357 PE2 may flood to CE2 a type 1 LSA advertising a link to PE1. The 358 link advertised in these LSAs is known as a "sham link", and it is 359 advertised as a link in area A. This makes it look to routers within 360 area A as if the path from CE1 to PE1 across the service provider's 361 network to PE2 to CE2 is an intra-area path. Sham links are an 362 OPTIONAL feature of this specification, and are used only when it is 363 necessary to have the service provider's network treated as an 364 intra-area link. See section 4.2.7 for further details about the sham 365 link. 367 The precise details by which a PE determines the type of LSA used to 368 advertise a particular route to a CE are specified in section 4.2.8. 369 Note that if the VRF is associated with multiple OSPF instances, the 370 type of LSA used to advertise the route might be different in 371 different instances. 373 Note that if a VRF is associated with several OSPF instances, a given 374 route may be redistributed into some or all of those OSPF instances, 375 depending on the characteristics of each instance. If redistributed 376 into two or more OSPF instances, it may be advertised within each 377 instance using a different type of LSA, again depending on the 378 characteristics of each instance. 380 4.1.4. PEs and OSPF Area 0 382 Within a given OSPF domain, a PE may attach to multiple CEs. Each 383 PE/CE link is assigned (by configuration) to an OSPF area. Any link 384 can be assigned to any area, including area 0. 386 If a PE attaches to a CE via a link which is in a non-zero area, then 387 the PE serves as an ABR for that area. 389 PEs can thus be considered to be OSPF "area 0 routers", i.e., they 390 can be considered to be part of the "OSPF backbone". Thus they are 391 allowed to distribute inter-area routes to the CE via Type 3 LSAs. 393 If the OSPF domain has any area 0 routers other than the PE routers, 394 then at least one of those MUST be a CE router, and MUST have an area 395 0 link to at least one PE router. This adjacency MAY be via an OSPF 396 virtual link. (The ability to use an OSPF virtual link in this way is 397 an OPTIONAL feature.) This is necessary to ensure that inter-area 398 routes and AS-external routes can be leaked between the PE routers 399 and the non-PE OSPF backbone. 401 Two sites which are not in the same OSPF area will see the VPN 402 backbone as being an integral part of the OSPF backbone. However, if 403 there are area 0 routers which are NOT PE routers, then the VPN 404 backbone actually functions as a sort of higher level backbone, 405 providing a third level of hierarchy above area 0. This allows a 406 legacy OSPF backbone to become disconnected during a transition 407 period, as long as the various segments all attach to the VPN 408 backbone. 410 4.1.5. Prevention of Loops 412 If a route sent form a PE router to a CE router could then be 413 received by another PE router from one of its own CE routers, it 414 would be possible for routing loops to occur. To prevent this, a PE 415 sets the DN bit [OSPF-DN] in any LSA that it sends to a CE, and a PE 416 ignores any LSA received from a CE which already has the DN bit sent. 418 Older implementations may use an OSPF Route Tag instead of the DN 419 bit, in some cases. See sections 4.2.5.1 and 4.2.5.2. 421 4.2. Details 423 4.2.1. Independent OSPF Instances in PEs 425 The PE MUST support one OSPF instance for each OSPF domain to which 426 it attaches. These OSPF instances function independently and do not 427 leak routes to each other. Each instance of OSPF MUST be associated 428 with a single VRF. If n CEs associated with that VRF are running 429 OSPF on their respective PE/CE links, then those n CEs are OSPF 430 adjacencies of the PE in the corresponding instance of OSPF. 432 Generally, though not necessarily, if the PE attaches to several CEs 433 in the same OSPF domain, it will associate the interfaces to those 434 PEs with a single VRF. 436 4.2.2. Router ID 438 If a PE and a CE are communicating via OSPF, the PE will have an OSPF 439 Router ID which is valid (i.e., unique) within the OSPF domain. More 440 precisely, each OSPF instance has a Router ID. Different OSPF 441 instances may have different Router IDs. 443 4.2.3. OSPF Areas 445 A PE-CE link may be in any area, including area 0; this is a matter 446 of the OSPF configuration. 448 If a PE has a link which belongs to a non-zero area, the PE functions 449 as an Area Border Router (ABR) for that area. 451 PEs do not pass along the link state topology from one site to 452 another (except in the case where a sham link is used, see section 453 4.2.7). 455 Per [OSPF, section 3.1], "the OSPF backbone always contains all area 456 border routers". The PE routers are therefore considered to be area 457 0 routers. Section 3.1 of [OSPFv2] also requires that area 0 be 458 contiguous. It follows that if the OSPF domain has any area 0 459 routers other than the PE routers, at least one of those MUST be a CE 460 router, and it MUST have an area 0 link (possibly a virtual link) to 461 at least one PE router. 463 4.2.4. OSPF Domain Identifiers 465 Each OSPF instance MUST be associated with one or more Domain 466 Identifiers. This MUST be configurable, and the default value (if 467 none is configured) SHOULD be NULL. 469 If an OSPF instance has multiple Domain Identifiers, one of these is 470 considered to be its "primary" Domain Identifier; this MUST be 471 determinable by configuration. If an OSPF instance has exactly one 472 Domain Identifier, this is of course its primary Domain Identifier. 473 If an OSPF instance has more than one Domain Identifiers, the NULL 474 Domain Identifier MUST NOT be one of them. 476 If a route is installed in a VRF by a particular OSPF instance, the 477 primary Domain Identifier of that OSPF instance is considered to be 478 the route's Domain Identifier. 480 Consider a route R which is installed in a VRF by OSPF instance I1, 481 then redistributed into BGP as a VPN-IPv4 route, then installed by 482 BGP in another VRF. If R needs to be redistributed into OSPF instance 483 I2, associated with the latter VRF, the way in which R is advertised 484 in I2 will depend upon whether R's Domain Identifier is one of I2's 485 Domain Identifiers. If R's Domain Identifier is not one of I2's 486 Domain Identifiers, then if R is redistributed into I2, R will be 487 advertised as an AS-external route, no matter what its OSPF route 488 type is. If, on the other hand, R's Domain Identifier is one of I2's 489 Domain Identifiers, how R is advertised will depend upon R's OSPF 490 route type. 492 If two OSPF instances are in the same OSPF domain, then either: 494 1. They both have the NULL Domain Identifier, OR 496 2. Each OSPF instance has the primary Domain Identifier of the 497 other as one of its own Domain Identifiers. 499 If two OSPF instances are in different OSPF domains, then either: 501 3. They both have the NULL Domain Identifier, OR 503 4. Neither OSPF instance has the Primary Domain Identifier of the 504 other as one of its own Domain Identifiers. 506 (Note that if two OSPF instances each have the NULL Domain 507 Identifier, we cannot tell from the Domain Identifier whether they 508 are in the same OSPF Domain or not. If they are in different 509 domains, and if routes from one are distributed into the other, the 510 routes will appear as intra-network routes, which may not be what is 511 intended.) 513 A Domain Identifier is an eight-byte quantity which is a valid BGP 514 Extended Communities attribute, as specified in section 4.2.4. If a 515 particular OSPF instance has a non-NULL Domain Identifier, when 516 routes from that OSPF instance are distributed by BGP as VPN-IPv4 517 routes, the routes MUST carry the Domain Identifier Extended 518 Communities attribute which corresponds to the OSPF instance's 519 Primary Domain Identifier. If the OSPF instance's Domain Identifier 520 is NULL, the Domain Identifier Extended Communities attribute MAY be 521 omitted when routes from that OSPF instance are distributed by BGP; 522 alternatively, a value of the Domain Identifier Extended Communities 523 attribute which represents NULL (see section 4.2.4) MAY be carried 524 with the route. 526 If the OSPF instances of an OSPF domain are given one or more non- 527 NULL Domain Identifiers, this procedure allows us to determine 528 whether a particular OSPF-originated VPN-IPv4 route belongs to the 529 same domain as a given OSPF instance. We can then determine whether 530 the route should be redistributed to that OSPF instance as an inter- 531 area route or as an OSPF AS-external route. Details can be found in 532 sections 4.2.4 and 4.2.8.1. 534 4.2.5. Loop Prevention 536 4.2.5.1. The DN Bit 538 When a type 3 LSA is sent from a PE router to a CE router, the DN bit 539 [OSPF-DN] in the LSA Options field MUST be set. This is used to 540 ensure that if any CE router sends this type 3 LSA to a PE router, 541 the PE router will not further redistribute it. 543 When a PE router needs to distribute to a CE router a route that 544 comes from a site outside the latter's OSPF domain, the PE router 545 presents itself as an ASBR ("Autonomous System Border Router"), and 546 distributes the route in a type 5 LSA. The DN bit [OSPF-DN] MUST be 547 set in these LSAs, to ensure that they will be ignored by any other 548 PE routers that receive them. 550 There are deployed implementations which do not set the DN bit, but 551 instead use OSPF route tagging to ensure that a type 5 LSA generated 552 by a PE router will be ignored by any other PE router that may 553 receive it. A special OSPF route tag, which we will call the VPN 554 Route Tag (see section 4.2.5.2), is used for this purpose. To ensure 555 backwards compatibility, all implementations adhering to this 556 specification MUST by default support the VPN Route Tag procedures 557 specified in sections 4.2.5.2, 4.2.8.1 and 4.2.8.2. When it is no 558 longer necessary to use the VPN Route Tag in a particular deployment, 559 its use (both sending and receiving) may be disabled by 560 configuration. 562 4.2.5.2. Use of OSPF Route Tags 564 If a particular VRF in a PE is associated with an instance of OSPF, 565 then by default it MUST be configured with a special OSPF route tag 566 value, which we call the VPN Route Tag. By default, this route tag 567 MUST be included in the Type 5 LSAs which the PE originates (as the 568 result of receiving a BGP-distributed VPN-IPv4 route, see section 569 4.2.8) and sends to any of the attached CEs. 571 The configuration and inclusion of the VPN Route Tag is required for 572 backwards compatibility with deployed implementations that do not set 573 the DN bit in type 5 LSAs. The inclusion of the VPN Route Tag may be 574 disabled by configuration, if it has been determined that it is no 575 longer needed for backwards compatibility. 577 The value of the VPN Route Tag is arbitrary, but must be distinct 578 from any OSPF Route Tag being used within the OSPF domain. Its value 579 MUST therefore be configurable. If the Autonomous System number of 580 the VPN backbone is two bytes long, the default value SHOULD be an 581 automatically computed tag based on that Autonomous System number: 583 Tag = 585 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 586 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 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 |1|1|0|1| ArbitraryTag | AutonomousSystem | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 _AS number of the VPN Backbone_ 593 If the Autonomous System number is four bytes long, then a Route Tag 594 value MUST be configured, and it MUST be distinct from any Route Tag 595 used within the VPN itself. 597 If a PE router needs to use OSPF to distribute to a CE router a route 598 which comes from a site outside the CE router's OSPF domain, the PE 599 router SHOULD present itself to the CE router as an Autonomous System 600 Border Router (ASBR), and SHOULD report such routes as AS-external 601 routes. That is, these PE routers originate Type 5 LSAs reporting 602 the extra-domain routes as AS-external routes. Each such Type 5 LSA 603 MUST contain an OSPF route tag whose value is that of the VPN Route 604 Tag. This tag identifies the route as having come from a PE router. 605 The VPN Route Tag MUST be used to ensure that a Type 5 LSA originated 606 by a PE router is not redistributed through the OSPF area to another 607 PE router. 609 4.2.5.3. Other Possible Loops 611 The procedures specified in this document ensure that if routing 612 information derived from a BGP-distributed VPN-IPv4 route is 613 distributed into OSPF, it cannot be redistributed back into BGP as a 614 VPN-IPv4 route, as long as the DN bit and/or VPN route tag is 615 maintained within the OSPF domain. This does not eliminate all 616 possible sources of loops. For example, if a BGP VPN-IPv4 route is 617 distributed into OSPF, and then distributed into RIP (where all the 618 information needed to prevent looping is lost), and then distributed 619 back into OSPF, then it is possible that it could be distributed back 620 into BGP as a VPN-IPv4 route, thereby causing a loop. 622 Therefore extreme care must be taken if there is any mutual 623 redistribution of routes between the OSPF domain and any third (i.e., 624 not the VPN backbone) routing domain. (If the third routing domain 625 is a BGP domain, e.g., the public Internet, the ordinary BGP route 626 prevention measures will prevent the route from reentering the OSPF 627 domain.) 629 4.2.6. Handling LSAs from the CE 631 This section specifies the way in which a PE router handles the OSPF 632 LSAs it receives from a CE router. 634 When a PE router receives, from a CE router, any LSA with the DN bit 635 [OSPF-DN] set, the information from that LSA MUST NOT be used by the 636 route calculation. If a Type 5 LSA is received from the CE, and if 637 it has an OSPF route tag value equal to the VPN Route Tag (see 638 section 4.2.5.2), then the information from that LSA MUST NOT be used 639 by the route calculation. 641 Otherwise, the PE must examine the corresponding VRF. For every 642 address prefix which was installed in the VRF by one of its 643 associated OSPF instances, the PE must create a VPN-IPv4 route in 644 BGP. Each such route will have some of the following Extended 645 Communities attributes: 647 - The OSPF Domain Identifier Extended Communities attribute. If 648 the OSPF instance which installed the route has a non-NULL 649 primary Domain Identifier, this MUST be present; if that OSPF 650 instance has only a NULL Domain Identifier, it MAY be omitted. 651 This attribute is encoded with a two-byte type field, and its 652 type is either 0005, 0105, or 0205. For backwards compatibility, 653 the type 8005 MAY be used as well, and is treated as if it were 654 0005. If the OSPF instance has a NULL Domain Identifier, and the 655 OSPF Domain Identifier Extended Communities attribute is present, 656 then the attribute's value field must be all zeroes, and its type 657 field may be any of 0005, 0105, 0205, or 8005. 659 - OSPF Route Type Extended Communities Attribute. This attribute 660 MUST be present. It is encoded with a two-byte type field, and 661 its type is 0306. To ensure backwards compatibility, the type 662 8000 SHOULD be accepted as well, and treated as if it were type 663 0306. The remaining six bytes of the Attribute are encoded as 664 follows: 666 +-------+-------+-------+-------+-------+-------+ 667 | Area Number | Route |Options| 668 | | Type | | 669 +-------+-------+-------+-------+-------+-------+ 671 * Area Number: 4 bytes, encoding a 32-bit area number. For AS- 672 external routes, the value is 0. A non-zero value identifies 673 the route as being internal to the OSPF domain, and as being 674 within the identified area. Area numbers are relative to a 675 particular OSPF domain. 677 * OSPF Route Type: 1 byte, encoded as follows: 679 ** 1 or 2 for intra-area routes (depending on whether the 680 route came from a type 1 or a type 2 LSA). 682 ** 3 for inter-area routes 684 ** 5 for external routes (area number must be 0) 686 ** 7 for NSSA routes. 688 Note that the procedures of section 4.2.8 do not make any 689 distinction between routes types 1, 2, and 3. If BGP 690 installs a route of one of these types in the VRF, and if 691 that route is selected for redistribution into OSPF, it will 692 be advertised by OSPF in either a type 3 or a type 5 LSA, 693 depending on the domain identifier. 695 * Options: 1 byte. Currently this is only used if the route 696 type is 5 or 7. Setting the least significant bit in the 697 field indicates that the route carries a type 2 metric. 699 - OSPF Router ID Extended Communities Attribute. This OPTIONAL 700 attribute specifies the OSPF Router ID of the system that is 701 identified in the BGP Next Hop attribute. More precisely, it 702 specifies the OSPF Router Id of the PE in the OSPF instance which 703 installed the route into the VRF from which this route was 704 exported. This attribute is encoded with a two-byte type field, 705 and its type is 0107, with the Router ID itself carried in the 706 first 4 bytes of the value field. The type 8001 SHOULD be 707 accepted as well, to ensure backwards compatibility, and should 708 be treated as if it were 0107. 710 - MED ("Multi_EXIT_DISC attribute"). By default, this SHOULD be set 711 to the value of the OSPF distance associated with the route, plus 712 1. 714 The intention of all this is the following. OSPF Routes from one site 715 are converted to BGP, distributed across the VPN backbone, and 716 possibly converted back to OSPF routes before being distributed into 717 another site. With these attributes, BGP carries enough information 718 about the route to enable the route to be converted back into OSPF 719 "transparently", just as if BGP had not been involved. 721 Routes which a PE receives in type 4 LSAs MUST NOT be redistributed 722 to BGP. 724 The attributes specified above are in addition to any other 725 attributes which routes must carry in accord with the [VPN]. 727 The Site of Origin attribute, which is usually required by [VPN], is 728 OPTIONAL for routes which a PE learns from a CE via OSPF. 730 Use of the Site of Origin attribute would, in the case of a multiply 731 homed site (i.e., a site attached to several PE routers), prevent an 732 intra-site route from being reinjected into a site from the VPN 733 backbone. Such a reinjection would not harm the routing, because the 734 route via the VPN backbone would be advertised in a type 3 LSA, and 735 hence would appear to be an inter-area route; the real intra-area 736 route would be preferred. But unnecessary overhead would be 737 introduced. On the other hand, if the Site of Origin attribute is not 738 used, a partitioned site will find itself automatically repaired, 739 since traffic from one partition to the other will automatically 740 travel via the VPN backbone. Therefore the use of a Site of Origin 741 attribute is optional, so that a trade-off can be made between the 742 cost of the increased overhead and the value of automatic partition 743 repair. 745 4.2.7. Sham Links 747 This section describes the protocol and procedures necessary for the 748 support of "Sham Links," as defined herein. Support for sham links 749 is an OPTIONAL feature of this specification. 751 4.2.7.1. Intra-Area Routes 753 Suppose there are two sites in the same OSPF area. Each site is 754 attached to a different PE router, and there is also an intra-area 755 OSPF link connecting the two sites. 757 It is possible to treat these two sites as a single VPN site which 758 just happens to be multihomed to the backbone. This is in fact the 759 simplest thing to do, and is perfectly adequate, providing that the 760 preferred route between the two sites is via the intra-area OSPF link 761 (a "backdoor link"), rather than via the VPN backbone. There will be 762 routes between sites that go through the PE routers, but these routes 763 will appear to be inter-area routes, and OSPF will consider them to 764 be less preferable than the intra-area routes through the backdoor 765 link. 767 If it is desired to have OSPF prefer the routes through the backbone 768 over the routes through the backdoor link, then the routes through 769 the backbone must be appear to be intra-area routes. To make a route 770 through the backbone appear to be an intra-area route, it is 771 necessary to make it appear as if there is an intra-area link 772 connecting the two PE routers. This is what we refer to as a "sham 773 link". (If the two sites attach to the same PE router, this of 774 course is not necessary.) 776 A sham link can be thought of as a relation between two VRFs. If two 777 VRFs are to be connected by a sham link, each VRF must be associated 778 with a "Sham Link Endpoint Address", a 32-bit IPv4 address which is 779 treated as an address of the PE router containing that VRF. The Sham 780 Link Endpoint Address is an address in the VPN's address space, not 781 the SP's address space. The Sham Link Endpoint Address associated 782 with a VRF MUST be configurable. If the VRF is associated with only 783 a single OSPF instance, and if the PE's router id in that OSPF 784 instance is an IP address, then the Sham Link Endpoint Address MAY 785 default to that Router ID. If a VRF is associated with several OSPF 786 instances, each sham link belongs to a single OSPF instance. 788 For a given OSPF instance, a VRF needs only a single Sham Link 789 Endpoint Address, no matter how many sham links it has. The Sham 790 Link Endpoint Address MUST be distributed by BGP as a VPN-IPv4 791 address whose IPv4 address prefix part is 32 bits long. The Sham 792 Link Endpoint Address MUST NOT be advertised by OSPF; if there is no 793 BGP route to the Sham Link Endpoint Address, that address is to 794 appear to be unreachable, so that the sham link appears to be down. 796 4.2.7.2. Creating Sham Links 798 Sham links are manually configured. 800 For a sham link to exist between two VRFs, each VRF has to be 801 configured to create a sham link to the other, where the "other" is 802 identified by its sham link endpoint address. No more than one sham 803 link with the same pair of sham link endpoint addresses will ever be 804 created. This specification does not include procedures for single- 805 ended manual configuration of the sham link. 807 Note that sham links may be created for any area, including area 0. 809 A sham link connecting two VRFs is considered to be up if and only if 810 a route to the 32-bit remote endpoint address of the sham link has 811 been installed in VRF. 813 The sham link endpoint address MUST NOT be used as the endpoint 814 address of an OSPF Virtual Link. 816 4.2.7.3. OSPF Protocol on Sham Links 818 An OSPF protocol packet sent on a Sham Link from one PE to another 819 must have as its IP source address the Sham Link Endpoint Address of 820 the sender, and as its IP destination address the Sham Link Endpoint 821 Address of the receiver. The packet will travel from one PE router to 822 the other over the VPN backbone, which means that it can be expected 823 to traverse multiple hops. As such, it's TTL ("Time to Live") field 824 must be set appropriately. 826 An OSPF protocol packet is regarded as having been received on a 827 particular sham link if and only if the following three conditions 828 hold: 830 - The packet arrives as an MPLS packet, and its MPLS label stack 831 causes it to be "delivered" to the local sham link endpoint 832 address; 834 - The packet's IP destination address is the local sham link 835 endpoint address; 837 - The packet's IP source address is the remote sham link endpoint 838 address. 840 Sham links SHOULD be treated by OSPF as OSPF Demand Circuits. This 841 means that LSAs will be flooded over them, but periodic refresh 842 traffic is avoided. Note that, as long as the backdoor link is up, 843 flooding the LSAs over the sham link serves no purpose. However, if 844 the backdoor link goes down, OSPF does not have mechanisms enabling 845 the routers in one site to rapidly flush the LSAs from the other 846 site. Therefore it is still necessary to maintain synchronization 847 among the LSA databases at the two sites, hence the flooding over the 848 sham link. 850 The sham link is an unnumbered point-to-point intra-area link, and is 851 advertised as a type 1 link in a type 1 LSA. 853 The OSPF metric associated with a sham link MUST be configurable (and 854 there MUST be a configurable default). Whether traffic between the 855 sites flows via a backdoor link or via the VPN backbone (i.e., via 856 the sham link) depends on the settings of the OSPF link metrics. The 857 metrics can be set so that the backdoor link is not used unless 858 connectivity via the VPN backbone fails, for example. 860 The default Hello Interval for sham links is 10 seconds, and the 861 default Router Dead Interval for sham links is 40 seconds. 863 4.2.7.4. Routing and Forwarding on Sham Links 865 If a PE determines that the next hop interface for a particular route 866 is a sham link, then the PE SHOULD NOT redistribute that route into 867 BGP as a VPN-IPv4 route. 869 Any other route advertised in an LSA which is transmitted over a sham 870 link MUST also be redistributed (by the PE flooding the LSA over the 871 sham link) into BGP. This means that if the preferred (OSPF) route 872 for a given address prefix has the sham link as its next hop 873 interface, then there will also be a "corresponding BGP route", for 874 that same address prefix, installed in the VRF. Per section 4.1.2, 875 the OSPF route is preferred. However, when forwarding a packet, if 876 the preferred route for that packet has the sham link as its next hop 877 interface, then the packet MUST be forwarded according to the 878 corresponding BGP route. That is, it will be forwarded as if the 879 corresponding BGP route had been the preferred route. The 880 "corresponding BGP route" is always a VPN-IPv4 route; the procedure 881 for forwarding a packet over a VPN-IPv4 route is described in [VPN]. 883 This same rule applies to any packet whose IP destination address is 884 the remote endpoint address of a sham link. Such packets MUST be 885 forwarded according to the corresponding BGP route. 887 4.2.8. VPN-IPv4 routes received via BGP 889 This section describes how the PE router handles VPN-IPv4 routes 890 received via BGP. 892 If a received BGP VPN-IPv4 route is not installed in the VRF, nothing 893 is reported to the CE. A received route will not be installed into 894 the VRF if the BGP decision process regards some other some other 895 route is preferable. When installed in the VRF, the route appears to 896 be an IPv4 route. 898 A BGP route installed in the VRF is not necessarily used for 899 forwarding. If an OSPF route for the same IPv4 address prefix has 900 been installed in the VRF, the OSPF route will be used for 901 forwarding, except in the case where the OSPF route's next hop 902 interface is a sham link. 904 If a BGP route installed in the VRF is used for forwarding, then the 905 BGP route is redistributed into OSPF, and possibly reported to the 906 CEs in an OSPF LSA. The sort of LSA, if any, to be generated depends 907 on various characteristics of the BGP route, as detailed in 908 subsequent sections of this document. 910 The procedure for forwarding a packet over a VPN-IPv4 route is 911 described in [VPN]. 913 In the following, we specify what is reported, in OSPF LSAs, by the 914 PE to the CE, assuming that the PE is not configured to do any 915 further summarization or filtering of the routing information before 916 reporting it to the CE. 918 When sending an LSA to the CE, it may be necessary to set the DN bit. 919 See section 4.2.5.1 for the rules regarding the DN bit. 921 When sending an LSA to the CE, it may be necessary to set the OSPF 922 Route Tag. See section 4.2.5.2 for the rules about setting the OSPF 923 Route Tag. 925 When type 5 LSAs are sent, the Forwarding Address is set to 0. 927 4.2.8.1. External Routes 929 With respect to a particular OSPF instance associated with a VRF, a 930 VPN-IPv4 route which is installed in the VRF and then selected as the 931 preferred route is treated as an External Route if one of the 932 following conditions holds: 934 - the route type field of the OSPF Route Type Extended Community 935 has an OSPF route type of "external", 937 - the route is from a different domain than the domain of the OSPF 938 instance. 940 The rules for determining whether a route is from a different domain 941 than a particular OSPF instance are the following. The OSPF Domain 942 Identifier Extended Communities attribute carried by the route is 943 compared with the OSPF Domain Identifier Extended Communities 944 attribute(s) with which the OSPF instance has been configured (if 945 any). In general, when two such attributes are compared, all eight 946 bytes must be compared. Thus two OSPF Domain Identifier Extended 947 Communities attributes are regarded as equal if and only if one of 948 the following three conditions holds: 950 1. They are identical in all eight bytes. 952 2. They are identical in their lower order six bytes (value 953 field), but one attribute has two high order bytes (type field) 954 of 0005 and the other has two high order bytes (type field) of 955 8005. (This condition is for backwards compatibility.) 957 3. The lower order six bytes (value field) of both attributes 958 consist entirely of zeroes. In this case, the two attributes 959 are considered to be identical irrespective of their type 960 fields, and they are regarded as representing the NULL Domain 961 Identifier. 963 If a VPN-IPv4 route has an OSPF Domain Identifier Extended 964 Communities attribute, we say that that route is in the identified 965 domain. If the value field of the Extended Communities attribute 966 consists of all zeroes, then the identified domain is the NULL 967 domain, and the route is said to belong to the NULL domain. If the 968 route does not have an OSPF Domain Identified Extended Communities 969 attribute, then the route belongs to the NULL domain. 971 Every OSPF instance is associated with one or more Domain 972 Identifiers, though possibly only with the NULL domain identifier. 973 If an OSPF instance is associated with a particular Domain 974 Identifier, we will say that it belongs to the identified domain. 976 If a VPN-IPv4 route is to be redistributed to a particular instance, 977 it must be determined whether that route belongs and that OSPF 978 instance belong to the same domain. A route and an OSPF instance 979 belong to the same domain if and only if one of the following 980 conditions holds: 982 1. The route and the OSPF instance each belong to the NULL domain. 984 2. The domain to which the route belongs is the domain to which 985 the OSPF instance belongs. (I.e., the route's Domain 986 Identifier is equal to the OSPF instance's domain identifier, 987 as determined by the definitions given earlier in this 988 section.) 990 If the route and the VRF do not belong to the same domain, the route 991 is treated as an external route. 993 If an external route is redistributed into an OSPF instance, the 994 route may or may not be advertised to a particular CE, depending on 995 the configuration and on the type of area to which the PE/CE link 996 belongs. If the route is advertised, and the PE/CE link belongs to a 997 NSSA area, it is advertised in a type 7 LSA. Otherwise, if the route 998 is advertised it is advertised in a type 5 LSA. The LSA will be 999 originated by the PE. 1001 The DN bit (section 4.2.5.1) MUST be set in the LSA. The VPN Route 1002 Tag (see section 4.2.5.2) MUST be placed in the LSA, unless the use 1003 of the VPN Route Tag has been turned off by configuration. 1005 By default, a type 2 metric value is included in the LSA, unless the 1006 options field of the OSPF Route Type Extended Communities attribute 1007 of the VPN-IPv4 route specifies that the metric should be type 1. 1009 By default, the value of the metric its value is taken from the MED 1010 attribute of the VPN-IPv4 route. If the MED is not present, a 1011 default metric value is used. (The default type 1 metric and the 1012 default type 2 metric MAY be different.) 1014 Note that this way of handling external routes makes every PE appear 1015 to be an ASBR attached to all the external routes. In a multihomed 1016 site, this can result in a number of type 5 LSAs containing the same 1017 information. 1019 4.2.8.2. Summary Routes 1021 If a route and the VRF into which it is imported belong to the same 1022 domain, then the route should be treated as if it had been received 1023 in an OSPF type 3 LSA. This means that the PE will report the route 1024 in a type 3 LSA to the CE. (Note that this case is possible even if 1025 the VPN-IPv4 route carries an area number identical to that of the CE 1026 router. This means that if an area is "partitioned" such that the 1027 two pieces are connected only via the VPN backbone, it appears to be 1028 two areas, with inter-area routes between them.) 1030 4.2.8.3. NSSA Routes 1032 NSSA routes are treated the same as external routes, as described in 1033 section 4.2.8.1. 1035 5. IANA Considerations 1037 Section 11 of [EXTCOMM] calls upon IANA to create a registry for BGP 1038 Extended Communities Type Field and Extended Type Field values. 1039 Section 4.2.6 of this document assigns new values for the BGP 1040 Extended Communities Extended Type Field. These values all fall 1041 within the range of values which [EXTCOMM] states "are to be assigned 1042 by IANA, using the 'First Come, First Served' policy defined in RFC 1043 2434". 1045 The BGP Extended Communities Extended Type Field values assigned in 1046 section 4.2.6 of this document are: 1048 - OSPF Domain Identifier: Extended Types 0005, 0105, and 0205. 1050 - OSPF Route Type: Extended Type 0306 1052 - OSPF Router ID: Extended Type 0107 1054 6. Security Considerations 1056 Security considerations which are relevant in general to BGP/MPLS IP 1057 VPNS are discussed in [VPN] and [VPN-AS]. We discuss here only those 1058 security considerations that are specific to the use of OSPF as the 1059 PE/CE protocol. 1061 A single PE may be running OSPF as the IGP of the SP backbone 1062 network, as well as running OSPF as the IGP of one or more VPNs. 1063 This requires the use of multiple, independent OSPF instances, so 1064 that routes are not inadvertently leaked between the backbone and any 1065 VPN. The OSPF instances for different VPNs must also be independent 1066 OSPF instances, to prevent inadvertent leaking of routes between 1067 VPNs. 1069 OSPF provides a number of procedures which allow the OSPF control 1070 messages between a PE and a CE to be authenticated. OSPF 1071 "cryptographic authentication" SHOULD be used between a PE and a CE. 1072 It MUST be implemented on each PE. 1074 In the absence of such authentication, it is possible that the CE 1075 might not really belong to the VPN to which the PE assigns it. It 1076 may also be possible for an attacker to insert spoofed messages on 1077 the PE/CE link, in either direction. Spoofed messages sent to the CE 1078 could compromise the routing at the CE's site. Spoofed messages sent 1079 to the PE could result in improper VPN routing, or in a denial of 1080 service attack on the VPN. 1082 7. Acknowledgments 1084 Major contributions to this work have been made by Derek Yeung and 1085 Yakov Rekhter. 1087 Thanks to Ross Callon, Ajay Singhal, Russ Housley, and Alex Zinin for 1088 their review and comments. 1090 8. Authors' Addresses 1092 Eric C. Rosen 1093 Cisco Systems, Inc. 1094 1414 Massachusetts Avenue 1095 Boxborough, MA 01719 1097 E-mail: erosen@cisco.com 1099 Peter Psenak 1100 Parc Pegasus, 1101 De Kleetlaan 6A 1102 1831 Diegem 1103 Belgium 1105 E-mail: ppsenak@cisco.com 1106 Padma Pillay-Esnault 1107 Cisco Systems, Inc. 1108 170 Tasman Drive 1109 San Jose, CA, 95134 1111 E-mail: ppe@cisco.com 1113 9. Normative References 1115 [EXTCOMM] "BGP Extended Communities Attribute", RFC 4360, Sangli, S., 1116 Tappan, D., Rekhter, Y., February 2006 1118 [OSPFv2] "OSPF Version 2", RFC 2328, Moy, J., April 1998 1120 [OSPF-DN] "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP 1121 VPNs", draft-ietf-ospf-2547-dnbit-04.txt, Rosen, Psenak, Pillay- 1122 Esnault, March 2004 1124 [RFC2119] "Key words for use in RFCs Indicate Requirement Levels", 1125 RFC 2119, Bradner, S., March 1997 1127 [VPN] "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, E. 1128 Rosen and Y. Rekhter, February 2006 1130 10. Informative References 1132 [BGP] "A Border Gateway Protocol 4 (BGP-4)", Rekhter, Y., Li, T., 1133 Hares, S., RFC 4271, January 2006 1135 [RIP] "RIP Version 2", Malkin, G., RFC 2453, November 1998 1137 [VPN-AS] "Applicability Statement for BGP/MPLS IP Virtual Private 1138 Networks (VPNs)", RFC 4365, E. Rosen, February 2006 1140 11. Full Copyright Statement 1142 Copyright (C) The Internet Society (2006). 1144 This document is subject to the rights, licenses and restrictions 1145 contained in BCP 78, and except as set forth therein, the authors 1146 retain all their rights. 1148 This document and the information contained herein are provided on an 1149 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1150 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1151 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1152 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1153 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1154 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1156 12. Intellectual Property 1158 The IETF takes no position regarding the validity or scope of any 1159 Intellectual Property Rights or other rights that might be claimed to 1160 pertain to the implementation or use of the technology described in 1161 this document or the extent to which any license under such rights 1162 might or might not be available; nor does it represent that it has 1163 made any independent effort to identify any such rights. Information 1164 on the procedures with respect to rights in RFC documents can be 1165 found in BCP 78 and BCP 79. 1167 Copies of IPR disclosures made to the IETF Secretariat and any 1168 assurances of licenses to be made available, or the result of an 1169 attempt made to obtain a general license or permission for the use of 1170 such proprietary rights by implementers or users of this 1171 specification can be obtained from the IETF on-line IPR repository at 1172 http://www.ietf.org/ipr. 1174 The IETF invites any interested party to bring to its attention any 1175 copyrights, patents or patent applications, or other proprietary 1176 rights that may cover technology that may be required to implement 1177 this standard. Please address the information to the IETF at ietf- 1178 ipr@ietf.org.