idnits 2.17.1 draft-ietf-ospf-rfc2370bis-05.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, updated by RFC 4748 on line 714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 725. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 738. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 8, 2008) is 5826 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) == Missing Reference: 'Moy' is mentioned on line 491, but not defined == Missing Reference: 'RFC3623' is mentioned on line 492, but not defined == Missing Reference: 'RFC4970' is mentioned on line 493, but not defined ** Obsolete undefined reference: RFC 4970 (Obsoleted by RFC 7770) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- No information found for draft-ietf-ospf-mt- - is the name correct? == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-update-21 -- Obsolete informational reference (is this intentional?): RFC 2370 (Obsoleted by RFC 5250) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (LabN) 2 Obsoletes: 2370 Igor Bryskin (Adva) 3 Category: Standards Track Alex Zinin (Alcatel) 4 Expiration Date: November 8, 2008 Original Author: 5 Rob Coltun (Acoustra Productions) 7 May 8, 2008 9 The OSPF Opaque LSA Option 11 draft-ietf-ospf-rfc2370bis-05.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 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on November 8, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document defines enhancements to the OSPF protocol to support a 45 new class of link-state advertisements (LSA) called Opaque LSAs. 46 Opaque LSAs provide a generalized mechanism to allow for the future 47 extensibility of OSPF. Opaque LSAs consist of a standard LSA header 48 followed by application-specific information. The information field 49 may be used directly by OSPF or by other applications. Standard OSPF 50 link-state database flooding mechanisms are used to distribute Opaque 51 LSAs to all or some limited portion of the OSPF topology. 53 This document replaces RFC 2370 and adds to it a mechanism to enable 54 an OSPF router to validate AS-scope opaque LSAs originated outside of 55 the router's OSPF area. 57 Table of Contents 59 1 Conventions used in this document ......................... 3 60 2 Introduction .............................................. 3 61 2.1 Organization Of This Document ............................. 3 62 2.2 Acknowledgments ........................................... 4 63 3 The Opaque LSA ............................................ 4 64 3.1 Flooding Opaque LSAs ...................................... 5 65 3.2 Modifications To The Neighbor State Machine ............... 6 66 4 Protocol Data Structures .................................. 7 67 4.1 Additions To The OSPF Neighbor Structure .................. 8 68 5 Inter-Area Considerations ................................. 8 69 6 Management Considerations ................................. 9 70 7 Backward Compatibility .................................... 9 71 8 Security Considerations ................................... 10 72 9 IANA Considerations ....................................... 11 73 10 References ................................................ 12 74 10.1 Normative References ...................................... 12 75 10.2 Informative References .................................... 12 76 11 Author's Addresses ........................................ 13 77 12 Appendix A: OSPF Data formats ............................. 13 78 12.1 The Options Field ......................................... 13 79 12.2 The Opaque LSA ............................................ 15 80 13 Full Copyright Statement .................................. 16 81 14 Intellectual Property ..................................... 16 82 1. Conventions used in this document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2. Introduction 90 Over the last several years the OSPF routing protocol [OSPF] has been 91 widely deployed throughout the Internet. As a result of this 92 deployment and the evolution of networking technology, OSPF has been 93 extended to support many options; this evolution will obviously 94 continue. 96 This document defines enhancements to the OSPF protocol to support a 97 new class of link-state advertisements (LSA) called Opaque LSAs. 98 Opaque LSAs provide a generalized mechanism to allow for the future 99 extensibility of OSPF. The information contained in Opaque LSAs may 100 be used directly by OSPF or indirectly by some application wishing to 101 distribute information throughout the OSPF domain. The exact use of 102 Opaque LSAs is beyond the scope of this document. 104 Opaque LSAs consist of a standard LSA header followed by a 32-bit 105 aligned application-specific information field. Like any other LSA, 106 the Opaque LSA uses the link-state database distribution mechanism 107 for flooding this information throughout the topology. The link- 108 state type field of the Opaque LSA identifies the LSA's range of 109 topological distribution. This range is referred to as the Flooding 110 Scope. 112 It is envisioned that an implementation of the Opaque option provides 113 an application interface for 1) encapsulating application-specific 114 information in a specific Opaque type, 2) sending and receiving 115 application-specific information, and 3) if required, informing the 116 application of the change in validity of previously received 117 information when topological changes are detected. 119 2.1. Organization Of This Document 121 This document first defines the three types of Opaque LSAs followed 122 by a description of OSPF packet processing. The packet processing 123 sections include modifications to the flooding procedure and to the 124 neighbor state machine. Appendix A then gives the packet formats. 126 2.2. Acknowledgments 128 We would like to thank Acee Lindem for his detailed review and useful 129 feedback. The handling of AS-scope opaque LSAs described in this 130 document is taken from draft-bryskin-ospf-lsa- 131 type11-validation-00.txt. 133 3. The Opaque LSA 135 Opaque LSAs are types 9, 10, and 11 link-state advertisements. 136 Opaque LSAs consist of a standard LSA header followed by a 32-bit 137 aligned application-specific information field. Standard link-state 138 database flooding mechanisms are used for distribution of Opaque 139 LSAs. The range of topological distribution (i.e., the flooding 140 scope) of an Opaque LSA is identified by its link-state type. This 141 section documents the flooding of Opaque LSAs. 143 The flooding scope associated with each Opaque link-state type is 144 defined as follows. 146 o Link-state type-9 denotes a link-local scope. Type-9 Opaque 147 LSAs are not flooded beyond the local (sub)network. 149 o Link-state type-10 denotes an area-local scope. Type-10 Opaque 150 LSAs are not flooded beyond the borders of their associated area. 152 o Link-state type-11 denotes that the LSA is flooded throughout 153 the Autonomous System (AS). The flooding scope of type-11 154 LSAs are equivalent to the flooding scope of AS-external (type-5) 155 LSAs. Specifically, type-11 Opaque LSAs are 1) flooded 156 throughout all transit areas, 2) not flooded into stub areas or 157 Not-So-Stubby Areas (NSSAs), see [NSSA], from the backbone and 158 3) not originated by routers into their connected stub areas 159 or NSSAs. As with type-5 LSAs, if a type-11 Opaque LSA is 160 received in a stub area or NSSA from a neighboring router 161 within the stub area or NSSA the LSA is rejected. 163 The link-state ID of the Opaque LSA is divided into an Opaque type 164 field (the first 8 bits) and a type-specific ID (the remaining 24 165 bits). The packet format of the Opaque LSA is given in Appendix A. 166 Section 7 describes Opaque type allocation and assignment. 168 The responsibility for proper handling of the Opaque LSA's flooding 169 scope is placed on both the sender and receiver of the LSA. The 170 receiver must always store a valid received Opaque LSA in its link- 171 state database. The receiver must not accept Opaque LSAs that 172 violate the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA 173 is not accepted in a stub area or NSSA). The flooding scope effects 174 both the synchronization of the link-state database and the flooding 175 procedure. 177 The following describes the modifications to these procedures that 178 are necessary to insure conformance to the Opaque LSA's Scoping 179 Rules. 181 3.1. Flooding Opaque LSAs 183 The flooding of Opaque LSAs MUST follow the rules of Flooding Scope 184 as specified in this section. Section 13 of [OSPF] describes the 185 OSPF flooding procedure. Those procedures MUST be followed as 186 defined except where modified in this section. The following 187 describes the Opaque LSA's type-specific flooding restrictions. 189 o If the Opaque LSA is type-9 (the flooding scope is link-local) 190 and the interface that the LSA was received on is not the same 191 as the target interface (e.g., the interface associated with a 192 particular target neighbor), the Opaque LSA MUST be discarded 193 and not acknowledged. An implementation SHOULD keep track of 194 the IP interface associated with each Opaque LSA having a 195 link-local flooding scope. 197 o If the Opaque LSA is type-10 (the flooding scope is area-local) 198 and the area associated with the Opaque LSA (as identified 199 during origination or from a received LSA's associated OSPF 200 packet header) is not the same as the area associated with the 201 target interface, the Opaque LSA MUST be discarded and not 202 acknowledged. An implementation SHOULD keep track of the OSPF 203 area associated with each Opaque LSA having an area-local 204 flooding scope. 206 o If the Opaque LSA is type-11 (the LSA is flooded throughout the 207 AS) and the target interface is associated with a stub area or 208 NSSA, the Opaque LSA MUST NOT be flooded out the interface. A 209 type-11 Opaque LSA that is received on an interface associated 210 with a stub area or NSSA MUST be discarded and not acknowledged 211 (the neighboring router has flooded the LSA in error). 213 When opaque-capable routers and non-opaque-capable OSPF routers are 214 mixed together in a routing domain, the Opaque LSAs are typically not 215 flooded to the non-opaque-capable routers. As a general design 216 principle, optional OSPF advertisements are only flooded to those 217 routers that understand them. 219 An opaque-capable router learns of its neighbor's opaque capability 220 at the beginning of the "Database Exchange Process" (see Section 10.6 221 of [OSPF], receiving Database Description packets from a neighbor in 222 state ExStart). A neighbor is opaque-capable if and only if it sets 223 the O-bit in the Options field of its Database Description packets; 224 the O-bit SHOULD NOT be set and MUST be ignored when received in 225 packets other than Database Description packets. Using the O-bit in 226 OSPF packets other than Database Description packets will result in 227 interoperability issues. The setting of the O-bit is a "SHOULD NOT" 228 rather than a "MUST NOT" to remain compatible with earlier 229 specifications. 231 In the next step of the Database Exchange process, Opaque LSAs are 232 included in the Database summary list that is sent to the neighbor 233 (see Sections 3.2 below and 10.3 of [OSPF]) when the neighbor is 234 opaque capable. 236 When flooding Opaque-LSAs to adjacent neighbors, an opaque-capable 237 router looks at the neighbor's opaque capability. Opaque LSAs are 238 only flooded to opaque-capable neighbors. To be more precise, in 239 Section 13.3 of [OSPF], Opaque LSAs MUST be placed on the link-state 240 retransmission lists of opaque-capable neighbors and MUST NOT be 241 placed on the link-state retransmission lists of non-opaque-capable 242 neighbors. However, when sending Link State Update packets as 243 multicasts, a non-opaque-capable neighbor may (inadvertently) receive 244 Opaque LSAs. The non-opaque-capable router will then simply discard 245 the LSA (see Section 13 of [OSPF], receiving LSAs having unknown LS 246 types). 248 Information contained in received opaque LSAs SHOULD only be used 249 when the router originating the LSA is reachable. As mentioned in 250 [OSPFv3], reachability validation MAY be done less frequently than 251 every SPF calculation. Additionally, routers processing received 252 opaque LSAs MAY choose to give priority to processing base OSPF LSA 253 types over opaque LSA types. 255 3.2. Modifications To The Neighbor State Machine 257 The state machine as it exists in section 10.3 of [OSPF] remains 258 unchanged except for the action associated with State: ExStart, 259 Event: NegotiationDone which is where the Database summary list is 260 built. To incorporate the Opaque LSA in OSPF this action is changed 261 to the following. 263 State(s): ExStart 265 Event: NegotiationDone 267 New state: Exchange 269 Action: The router MUST list the contents of its entire area 270 link-state database in the neighbor Database summary 271 list. The area link-state database consists of the 272 Router LSAs, Network LSAs, Summary LSAs, type-9 opaque 273 LSAs, and type-10 opaque LSAs contained in the area 274 structure, along with AS External and type-11 Opaque 275 LSAs contained in the global structure. AS External 276 and type-11 Opaque LSAs MUST be omitted from a 277 virtual neighbor's Database summary list. AS External 278 LSAs and type-11 Opaque LSAs MUST be omitted from the 279 Database summary list if the area has been configured 280 as a stub area or NSSA (see Section 3.6 of [OSPF]). 282 Type-9 Opaque LSAs MUST be omitted from the Database 283 summary list if the interface associated with the 284 neighbor is not the interface associated with the Opaque 285 LSA (as noted upon reception). 287 Any advertisement whose age is equal to MaxAge MUST be 288 omitted from the Database summary list. It MUST instead 289 be added to the neighbor's link-state retransmission 290 list. A summary of the Database summary list will be 291 sent to the neighbor in Database Description packets. 292 Only one Database Description Packet is allowed to be 293 outstanding at any one time. For more detail on the 294 sending and receiving of Database Description packets, 295 see Sections 10.6 and 10.8 of [OSPF]. 297 4. Protocol Data Structures 299 The Opaque option is described herein in terms of its operation on 300 various protocol data structures. These data structures are included 301 for explanatory uses only. They are not intended to constrain an 302 implementation. In addition to the data structures listed below, this 303 specification references the various data structures (e.g., OSPF 304 neighbors) defined in [OSPF]. 306 In an OSPF router, the following item is added to the list of global 307 OSPF data structures described in Section 5 of [OSPF]: 309 o Opaque capability. Indicates whether the router is running the 310 Opaque option (i.e., capable of storing Opaque LSAs). Such a 311 router will continue to inter-operate with non-opaque-capable 312 OSPF routers. 314 4.1. Additions To The OSPF Neighbor Structure 316 The OSPF neighbor structure is defined in Section 10 of [OSPF]. In 317 an opaque-capable router, the following items are added to the OSPF 318 neighbor structure: 320 o Neighbor Options. This field was already defined in the OSPF 321 specification. However, in opaque-capable routers there is a new 322 option which indicates the neighbor's Opaque capability. This new 323 option is learned in the Database Exchange process through 324 reception of the neighbor's Database Description packets and 325 determines whether Opaque LSAs are flooded to the neighbor. For a 326 more detailed explanation of the flooding of the Opaque LSA see 327 section 3 of this document. 329 5. Inter-Area Considerations 331 As defined above, link-state type-11 opaque LSAs are flooded 332 throughout the Autonomous System (AS). One issue related to such AS 333 scoped Opaque LSAs is that there must be a way for OSPF routers in 334 remote areas to check availability of the LSA originator. 335 Specifically, if an OSPF router originates a type-11 LSA and, after 336 that, goes out of service, OSPF routers located outside of the 337 originator's OSPF area have no way of detecting this fact and may use 338 the stale information for a considerable period of time (up to 60 339 minutes). This could prove to be suboptimal for some applications and 340 may result in others not functioning. 342 Type-9 opaque LSAs and type-10 opaque LSAs do not have this problem 343 as a receiving router can detect if the advertising router is 344 reachable within the LSA's respective flooding scope. In the case of 345 type-9 LSAs, the originating router must be an OSPF neighbor in 346 Exchange state or greater. In the case of type-10 Opaque LSAs, the 347 intra-area SPF calculation will determine the advertising router's 348 reachability. 350 There is a parallel issue in OSPF for the AS scoped AS-external-LSAs 351 (type-5 LSAs). OSPF addresses this by using AS border information 352 advertised in AS boundary router (ASBR) summary-LSAs (type-4 LSAs), 353 see [OSPF] Section 16.4. This same mechanism is reused by this 354 document for type-11 opaque LSAs. 356 To enable OSPF routers in remote areas to check availability of the 357 originator of link-state type-11 opaque LSAs, the originators 358 advertise themselves as ASBRs. This will enable routers to track the 359 reachability of the LSA originator either directly via the SPF 360 calculation (for routers in the same area) or indirectly via type-4 361 LSAs originated by ABRs (for routers in other areas). It is important 362 to note that per [OSPF] this solution does not apply to OSPF stub 363 areas or NSSAs as AS scoped opaque LSAs are not flooded into these 364 area types. 366 The procedures related to inter-area opaque LSAs are as follows: 368 (1) An OSPF router that is configured to originate AS-scope opaque 369 LSAs will advertise itself as an ASBR and MUST follow the 370 requirements related to setting of the Options field E-bit in 371 OSPF LSA headers as specified in [OSPF]. 373 (2) When processing a received type-11 Opaque LSA, the router MUST 374 look up the routing table entries (potentially one per attached 375 area) for the AS boundary router (ASBR) that originated the LSA. 376 If no entries exist for router ASBR (i.e., the ASBR is 377 unreachable), the router MUST do nothing with this LSA. It also 378 MUST discontinue using all Opaque LSAs injected into the network 379 by the same originator whenever it is detected that the 380 originator is unreachable. 382 6. Management Considerations 384 The updated OSPF MIB, [RFC4750], provides explicit support for opaque 385 LSAs and SHOULD be used to support implementations of this document. 386 See Section 12.3 of [RFC4750] for details. In addition to that 387 section, implementations supporting [RFC4750] will also include 388 opaque LSAs in all appropriate generic LSA objects, e.g., 389 ospfOriginateNewLsas, and ospfLsdbTable. 391 7. Backward Compatibility 393 The solution proposed in this document introduces no interoperability 394 issues. In the case that a non-opaque-capable neighbor receives 395 Opaque LSAs, per [OSPF], the non-opaque-capable router will simply 396 discard the LSA. 398 Note that OSPF routers that implement [RFC2370] will continue using 399 stale type-11 LSAs even when the LSA originator implements the Inter- 400 area procedures described in Section 6 of this document. 402 8. Security Considerations 404 There are two types of issues that need be addressed when looking at 405 protecting routing protocols from misconfigurations and malicious 406 attacks. The first is authentication and certification of routing 407 protocol information. The second is denial of service attacks 408 resulting from repetitive origination of the same router 409 advertisement or origination of a large number of distinct 410 advertisements resulting in database overflow. Note that both of 411 these concerns exist independently of a router's support for the 412 Opaque option. 414 To address the authentication concerns, OSPF protocol exchanges are 415 authenticated. OSPF supports multiple types of authentication; the 416 type of authentication in use can be configured on a per network 417 segment basis. One of OSPF's authentication types, namely the 418 Cryptographic authentication option, is believed to be secure against 419 passive attacks and provide significant protection against active 420 attacks. When using the Cryptographic authentication option, each 421 router appends a "message digest" to its transmitted OSPF packets. 422 Receivers then use the shared secret key and received digest to 423 verify that each received OSPF packet is authentic. 425 The quality of the security provided by the Cryptographic 426 authentication option depends completely on the strength of the 427 message digest algorithm (MD5 is currently the only message digest 428 algorithm specified), the strength of the key being used, and the 429 correct implementation of the security mechanism in all communicating 430 OSPF implementations. It also requires that all parties maintain the 431 secrecy of the shared secret key. None of the standard OSPF 432 authentication types provide confidentiality. Nor do they protect 433 against traffic analysis. For more information on the standard OSPF 434 security mechanisms, see Sections 8.1, 8.2, and Appendix D of [OSPF]. 436 Repetitive origination of advertisements is addressed by OSPF by 437 mandating a limit on the frequency that new instances of any 438 particular LSA can be originated and accepted during the flooding 439 procedure. The frequency at which new LSA instances may be 440 originated is set equal to once every MinLSInterval seconds, whose 441 value is 5 seconds (see Section 12.4 of [OSPF]). The frequency at 442 which new LSA instances are accepted during flooding is once every 443 MinLSArrival seconds, whose value is set to 1 (see Section 13, 444 Appendix B and G.5 of [OSPF]). 446 Proper operation of the OSPF protocol requires that all OSPF routers 447 maintain an identical copy of the OSPF link-state database. However, 448 when the size of the link-state database becomes very large, some 449 routers may be unable to keep the entire database due to resource 450 shortages; we term this "database overflow". When database overflow 451 is anticipated, the routers with limited resources can be 452 accommodated by configuring OSPF stub areas and NSSAs. [OVERFLOW] 453 details a way of gracefully handling unanticipated database 454 overflows. 456 In the case of type-11 Opaque LSAs, this document reuses an ASBR 457 tracking mechanism that is already employed in basic OSPF for type-5 458 LSAs. Therefore, applying it to type-11 Opaque LSAs does not create 459 any threats that are not already known for type-5 LSAs. 461 9. IANA Considerations 463 This document updates the requirements for the OSPF Opaque LSA type 464 registry, see http://www.iana.org/assignments/ospf-opaque-types. 465 Three changes are requested. The first is for references to 466 [RFC2370] to be replaced with references to this document. The second 467 change is for the Opaque type values in the range of 128-255 to be 468 reserved for "Private Use" as defined in [RFC2434]. The final change 469 is for the reference for registry value 1, Traffic Engineering LSA, 470 to be updated to [RFC3630]. 472 With these changes integrated, the registry should read: 474 Open Shortest Path First (OSPF) Opaque Link-State 475 Advertisements (LSA) Option Types 477 Registries included below: 478 - Opaque Link-State Advertisements (LSA) Option Types 480 Registry Name: Opaque Link-State Advertisements (LSA) Option Types 481 Reference: [This document] 482 Range Registration Procedures Notes 483 -------- ------------------------------------------ -------- 484 0-127 IETF Consensus 485 128-255 Private Use 487 Registry: 488 Value Opaque Type Reference 489 ------- ------------------------------------------ --------- 490 1 Traffic Engineering LSA [RFC3630] 491 2 Sycamore Optical Topology Descriptions [Moy] 492 3 grace-LSA [RFC3623] 493 4 Router Information (RI) [RFC4970] 494 5-127 Unassigned 495 128-255 Private Use 497 10. References 499 10.1. Normative References 501 [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 502 1793, April 1995. 504 [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 506 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 507 requirements levels", RFC 2119, March 1997. 509 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an 510 IANA Considerations Section in RFCs ", RFC 2434, October 511 1998. 513 [RFC4750] Joyal, D., et al., "OSPF Version 2 Management Information 514 Base", RFC 4750, November 2006. 516 10.2. Informative References 518 [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 519 1994. 521 [NSSA] Murphy P., "The OSPF Not-So-Stubby Area (NSSA) Option", 522 RFC 3101, January 2003. 524 [OSPF-MT] Psenak, P., et al., "Multi-Topology (MT) Routing in OSPF", 525 draft-ietf-ospf-mt-, January 2007. 527 [OSPFv3] Coltun, R., et al. "OSPF for IPv6", 528 draft-ietf-ospf-ospfv3-update-21.txt, April 2008. 530 [OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995. 532 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 533 July 1998. 535 [RFC3630] Katz, D., Kompella, K., Yeund, D., "Traffic Engineering 536 (TE) Extensions to OSPF Version 2", RFC 3630, September 537 2003. 539 [RFC4576] Rosen, E., et al., "Using a Link State Advertisement 540 (LSA) Options Bit to Prevent Looping in BGP/MPLS IP 541 Virtual Private Networks (VPNs)", RFC 4576, June 2006. 543 11. Author's Addresses 545 Lou Berger 546 LabN Consulting, L.L.C. 547 Email: lberger@labn.net 549 Igor Bryskin 550 ADVA Optical Networking Inc 551 7926 Jones Branch Drive 552 Suite 615 553 McLean, VA - 22102 554 Email: ibryskin@advaoptical.com 556 Alex Zinin 557 Alcatel 558 Email: zinin@psg.com 560 Original Author: 561 Rob Coltun 562 Acoustra Productions 564 12. Appendix A: OSPF Data formats 566 This appendix describes the format of the Options Field followed by 567 the packet format of the Opaque LSA. 569 12.1. The Options Field 571 The OSPF Options field is present in OSPF Hello packets, Database 572 Description packets and all link-state advertisements. The Options 573 field enables OSPF routers to support (or not support) optional 574 capabilities, and to communicate their capability level to other OSPF 575 routers. Through this mechanism routers of differing capabilities can 576 be mixed within an OSPF routing domain. 578 When used in Hello packets, the Options field allows a router to 579 reject a neighbor because of a capability mismatch. Alternatively, 580 when capabilities are exchanged in Database Description packets a 581 router can choose not to flood certain link-state advertisements to a 582 neighbor because of its reduced functionality. Lastly, listing 583 capabilities in link-state advertisements allows routers to forward 584 traffic around reduced functionality routers by excluding them from 585 parts of the routing table calculation. 587 All eight bits of the OSPF Options field have been assigned, although 588 only the O-bit is described completely by this document. Each bit is 589 described briefly below. Routers SHOULD reset (i.e., clear) 590 unrecognized bits in the Options field when sending Hello packets or 591 Database Description packets and when originating link-state 592 advertisements. Conversely, routers encountering unrecognized Option 593 bits in received Hello Packets, Database Description packets or link- 594 state advertisements SHOULD ignore the capability and process the 595 packet/advertisement normally. 597 +--------------------------------------+ 598 | DN | O | DC | EA | N/P | MC | E | MT | 599 +--------------------------------------+ 601 The Options Field 603 MT-bit 604 This bit describes the router's multi-topology link-excluding 605 capability, as described in [OSPF-MT]. 607 E-bit 608 This bit describes the way AS-external-LSAs are flooded, as 609 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF]. 611 MC-bit 612 This bit describes whether IP multicast datagrams are forwarded 613 according to the specifications in [MOSPF]. 615 N/P-bit 616 This bit describes the handling of Type-7 LSAs, as specified in 617 [NSSA]. 619 DC-bit 620 This bit describes the router's handling of demand circuits, as 621 specified in [DEMD]. 623 EA-bit 624 This bit describes the router's willingness to receive and 625 forward External-Attributes-LSAs. While defined, the 626 documents specifying this bit have all expired. The use 627 of this bit may be deprecated in the future. 629 O-bit 630 This bit describes the router's willingness to receive and 631 forward Opaque-LSAs as specified in this document. 633 DN-bit 634 This bit is used to prevent looping in BGP/MPLS IP VPNs, 635 as specified in [RFC4576]. 637 12.2. The Opaque LSA 639 Opaque LSAs are Type 9, 10, and 11 link-state advertisements. These 640 advertisements MAY be used directly by OSPF or indirectly by some 641 application wishing to distribute information throughout the OSPF 642 domain. The function of the Opaque LSA option is to provide for 643 future OSPF extensibility. 645 Opaque LSAs contain some number of octets (of application-specific 646 data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA 647 uses the link-state database distribution mechanism for flooding this 648 information throughout the topology. However, the Opaque LSA has a 649 flooding scope associated with it so that the scope of flooding may 650 be link-local (type-9), area-local (type-10) or the entire OSPF 651 routing domain (type-11). Section 3 of this document describes the 652 flooding procedures for the Opaque LSA. 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | LS age | Options | 9, 10, or 11 | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Opaque Type | Opaque ID | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Advertising Router | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | LS Sequence Number | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | LS checksum | Length | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | | 668 + + 669 | Opaque Information | 670 + + 671 | ... | 673 Link-State Type 675 The link-state type of the Opaque LSA identifies the LSA's range of 676 topological distribution. This range is referred to as the Flooding 677 Scope. The following explains the flooding scope of each of the 678 link-state types. 680 o A value of 9 denotes a link-local scope. Opaque LSAs with a 681 link-local scope MUST NOT be flooded beyond the local 682 (sub)network. 684 o A value of 10 denotes an area-local scope. Opaque LSAs with a 685 area-local scope MUST NOT be flooded beyond their area of 686 origin. 688 o A value of 11 denotes that the LSA is flooded throughout the 689 Autonomous System (e.g., has the same scope as type-5 LSAs). 690 Opaque LSAs with AS-wide scope MUST NOT be flooded into stub 691 areas or NSSAs. 693 Syntax Of The Opaque LSA's Link-State ID 695 The link-state ID of the Opaque LSA is divided into an Opaque Type 696 field (the first 8 bits) and an Opaque ID (the remaining 24 bits). 697 See section 7 of this document for a description of Opaque type 698 allocation and assignment. 700 13. Full Copyright Statement 702 Copyright (C) The IETF Trust (2008). 704 This document is subject to the rights, licenses and restrictions 705 contained in BCP 78, and except as set forth therein, the authors 706 retain all their rights. 708 This document and the information contained herein are provided on an 709 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 710 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 711 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 712 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 713 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 714 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 716 14. Intellectual Property 718 The IETF takes no position regarding the validity or scope of any 719 Intellectual Property Rights or other rights that might be claimed 720 to pertain to the implementation or use of the technology 721 described in this document or the extent to which any license 722 under such rights might or might not be available; nor does it 723 represent that it has made any independent effort to identify any 724 such rights. Information on the procedures with respect to rights 725 in RFC documents can be found in BCP 78 and BCP 79. 727 Copies of IPR disclosures made to the IETF Secretariat and any 728 assurances of licenses to be made available, or the result of an 729 attempt made to obtain a general license or permission for the use 730 of such proprietary rights by implementers or users of this 731 specification can be obtained from the IETF on-line IPR repository 732 at http://www.ietf.org/ipr. 734 The IETF invites any interested party to bring to its attention 735 any copyrights, patents or patent applications, or other 736 proprietary rights that may cover technology that may be required 737 to implement this standard. Please address the information to the 738 IETF at ietf-ipr@ietf.org. 740 Acknowledgement 742 Funding for the RFC Editor function is provided by the IETF 743 Administrative Support Activity (IASA). 745 Generated on: Thu May 8 16:11:50 EDT 2008