idnits 2.17.1 draft-ietf-ospf-opaque-05.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1.0 Abstract' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6.0 Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 181 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The abstract seems to contain references ([MOSPF], [NSSA], [OSPFMIB], [OSPF], [OVERFLOW], [EAL], [DEMD], [DIGI], [ARA]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 1998) is 9476 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 section? 'OSPF' on line 523 looks like a reference -- Missing reference section? 'ARA' on line 460 looks like a reference -- Missing reference section? 'OSPFMIB' on line 477 looks like a reference -- Missing reference section? 'DIGI' on line 466 looks like a reference -- Missing reference section? 'OVERFLOW' on line 480 looks like a reference -- Missing reference section? 'DEMD' on line 535 looks like a reference -- Missing reference section? 'MOSPF' on line 527 looks like a reference -- Missing reference section? 'NSSA' on line 531 looks like a reference -- Missing reference section? 'EAL' on line 539 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Opaque May 1998 4 Expiration Date: November 1998 FORE Systems 5 File name: draft-ietf-ospf-opaque-05.txt 7 The OSPF Opaque LSA Option 9 Rob Coltun 10 FORE Systems 11 (703) 245-4543 12 rcoltun@fore.com 14 Status Of This Memo 16 This document is an Internet-Draft. Internet-Drafts are working docu- 17 ments of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note that other groups may also distribute work- 19 ing documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress". 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 28 Directories on ds.internic.net (US East Coast), nic.nordu.net 29 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 31 Table Of Contents 33 1.0 Abstract ................................................. 3 35 2.0 Overview ................................................. 3 37 2.1 Organization Of This Document ............................ 3 39 2.2 Acknowledgments .......................................... 4 41 3.0 The Opaque LSA ........................................... 4 43 3.1 Flooding Opaque LSAs ..................................... 5 45 3.2 Modifications To The Neighbor State Machine .............. 6 47 4.0 Protocol Data Structures ................................. 8 49 4.1 Additions To The OSPF Neighbor Structure ................. 8 51 5.0 Management Considerations ................................ 8 53 6.0 Security Considerations .................................. 10 55 7.0 References ............................................... 12 57 Appendix A: OSPF Data Formats ................................ 13 59 A.1 The Options Field ........................................ 13 61 A.2 Opaque LSA ............................................... 15 63 1.0 Abstract 65 This memo defines enhancements to the OSPF protocol to support a new 66 class of link-state advertisements (LSA) called Opaque LSAs. Opaque 67 LSAs provide a generalized mechanism to allow for the future extensi- 68 bility of OSPF. Opaque LSAs consist of a standard LSA header followed 69 by application-specific information. The information field may be 70 used directly by OSPF or by other applications. Standard OSPF link- 71 state database flooding mechanisms are used to distribute Opaque LSAs 72 to all or some limited portion of the OSPF topology. 74 2.0 Overview 76 Over the last several years the OSPF routing protocol [OSPF] has been 77 widely deployed throughout the Internet. As a result of this deploy- 78 ment and the evolution of networking technology, OSPF has been 79 extended to support many options; this evolution will obviously con- 80 tinue. 82 This memo defines enhancements to the OSPF protocol to support a new 83 class of link-state advertisements (LSA) called Opaque LSAs. Opaque 84 LSAs provide a generalized mechanism to allow for the future extensi- 85 bility of OSPF. The information contained in Opaque LSAs may be used 86 directly by OSPF or indirectly by some application wishing to distri- 87 bute information throughout the OSPF domain. For example, the OSPF 88 LSA may be used by routers to distribute IP to link-layer address 89 resolution information (see [ARA] for more information). The exact 90 use of Opaque LSAs is beyond the scope of this draft. 92 Opaque LSAs consist of a standard LSA header followed by a 32-bit 93 aligned application-specific information field. Like any other LSA, 94 the Opaque LSA uses the link-state database distribution mechanism for 95 flooding this information throughout the topology. The link-state 96 type field of the Opaque LSA identifies the LSA's range of topological 97 distribution. This range is referred to as the Flooding Scope. 99 It is envisioned that an implementation of the Opaque option provides 100 an application interface for 1) encapsulating application-specific 101 information in a specific Opaque type, 2) sending and receiving 102 application-specific information, and 3) if required, informing the 103 application of the change in validity of previously received informa- 104 tion when topological changes are detected. 106 2.1 Organization Of This Document 108 This document first defines the three types of Opaque LSAs followed by 109 a description of OSPF packet processing. The packet processing sec- 110 tions include modifications to the flooding procedure and to the 111 neighbor state machine. Appendix A then gives the packet formats. 113 2.2 Acknowledgments 115 The author would like to thank Dennis Ferguson, Acee Lindem, John Moy, 116 Sandra Murphy, Man-Kit Yeung, Zhaohui "Jeffrey" Zhang and the rest of 117 the OSPF Working Group for the ideas and support they have given to 118 this project. 120 3.0 The Opaque LSA 122 Opaque LSAs are types 9, 10 and 11 link-state advertisements. Opaque 123 LSAs consist of a standard LSA header followed by a 32-bit aligned 124 application-specific information field. Standard link-state database 125 flooding mechanisms are used for distribution of Opaque LSAs. The 126 range of topological distribution (i.e., the flooding scope) of an 127 Opaque LSA is identified by its link-state type. This section docu- 128 ments the flooding of Opaque LSAs. 130 The flooding scope associated with each Opaque link-state type is 131 defined as follows. 133 o Link-state type 9 denotes a link-local scope. Type-9 Opaque 134 LSAs are not flooded beyond the local (sub)network. 136 o Link-state type 10 denotes an area-local scope. Type-10 Opaque 137 LSAs are not flooded beyond the borders of their associated area. 139 o Link-state type 11 denotes that the LSA is flooded throughout 140 the Autonomous System (AS). The flooding scope of type-11 LSAs 141 are equivalent to the flooding scope of AS-external (type-5) 142 LSAs. Specifically type-11 Opaque LSAs are 1) flooded throughout 143 all transit areas, 2) not flooded into stub areas from the back- 144 bone and 3) not originated by routers into their connected stub 145 areas. As with type-5 LSAs, if a type-11 Opaque LSA is received 146 in a stub area from a neighboring router within the stub area the 147 LSA is rejected. 149 The link-state ID of the Opaque LSA is divided into an Opaque type 150 field (the first 8 bits) and a type-specific ID (the remaining 24 151 bits). Opaque type values in the range of 0-127 are reserved for 152 definition by the IANA (iana@ISI.EDU) whereas Opaque type values in 153 the range of 128-255 are reserved for private and experimental use. 155 The packet format of the Opaque LSA is given in Appendix A. 157 The responsibility for proper handling of the Opaque LSA's flooding 158 scope is placed on both the sender and receiver of the LSA. The 159 receiver must always store a valid received Opaque LSA in its link- 160 state database. The receiver must not accept Opaque LSAs that violate 161 the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA is not 162 accepted in a stub area). The flooding scope effects both the build- 163 ing of the Database Summary List during the initial synchronization of 164 the link-state database and the flooding procedure. 166 The following describes the modifications to these procedures that are 167 necessary to insure conformance to the Opaque LSA's Scoping Rules. 169 3.1 Flooding Opaque LSAs 171 The flooding of Opaque LSAs must follow the rules of Flooding Scope as 172 specified in this section. Section 13 of [OSPF] describes the OSPF 173 flooding procedure. The following describes the Opaque LSA's type- 174 specific flooding restrictions. 176 o If the Opaque LSA is type 9 (the flooding scope is link-local) 177 and the interface that the LSA was received on is not the same as 178 the target interface (e.g., the interface associated with a par- 179 ticular target neighbor), the Opaque LSA must not be flooded out 180 that interface (or to that neighbor). An implementation should 181 keep track of the IP interface associated with each Opaque LSA 182 having a link-local flooding scope. 184 o If the Opaque LSA is type 10 (the flooding scope is area-local) 185 and the area associated with Opaque LSA (upon reception) is not 186 the same as the area associated with the target interface, the 187 Opaque LSA must not be flooded out the interface. An implementa- 188 tion should keep track of the OSPF area associated with each 189 Opaque LSA having an area-local flooding scope. 191 o If the Opaque LSA is type 11 (the LSA is flooded throughout the 192 AS) and the target interface is associated with a stub area the 193 Opaque LSA must not be flooded out the interface. A type-11 194 Opaque LSA that is received on an interface associated with a 195 stub area must be discarded and not acknowledged (the neighboring 196 router has flooded the LSA in error). 198 When opaque-capable routers and non-opaque-capable OSPF routers are 199 mixed together in a routing domain, the Opaque LSAs are not flooded to 200 the non-opaque-capable routers. As a general design principle, 201 optional OSPF advertisements are only flooded to those routers that 202 understand them. 204 An opaque-capable router learns of its neighbor's opaque capability at 205 the beginning of the "Database Exchange Process" (see Section 10.6 of 206 [OSPF], receiving Database Description packets from a neighbor in 207 state ExStart). A neighbor is opaque-capable if and only if it sets 208 the O-bit in the Options field of its Database Description packets; 209 the O-bit is not set in packets other than Database Description pack- 210 ets. Then, in the next step of the Database Exchange process, Opaque 211 LSAs are included in the Database summary list that is sent to the 212 neighbor (see Sections 3.2 below and 10.3 of [OSPF]) if and only if 213 the neighbor is opaque capable. 215 When flooding Opaque-LSAs to adjacent neighbors, a opaque-capable 216 router looks at the neighbor's opaque capability. Opaque LSAs are 217 only flooded to opaque-capable neighbors. To be more precise, in Sec- 218 tion 13.3 of [OSPF], Opaque LSAs are only placed on the link-state 219 retransmission lists of opaque-capable neighbors. However, when send- 220 ing Link State Update packets as multicasts, a non-opaque-capable 221 neighbor may (inadvertently) receive Opaque LSAs. The non-opaque- 222 capable router will then simply discard the LSA (see Section 13 of 223 [OSPF], receiving LSAs having unknown LS types). 225 3.2 Modifications To The Neighbor State Machine 227 The state machine as it exists in section 10.3 of [OSPF] remains 228 unchanged except for the action associated with State: ExStart, Event: 229 NegotiationDone which is where the Database summary list is built. To 230 incorporate the Opaque LSA in OSPF this action is changed to the fol- 231 lowing. 233 State(s): ExStart 235 Event: NegotiationDone 237 New state: Exchange 239 Action: The router must list the contents of its entire area 240 link-state database in the neighbor Database summary 241 list. The area link-state database consists of the 242 Router LSAs, Network LSAs, Summary LSAs and types 9 243 and 10 Opaque LSAs contained in the area structure, 244 along with AS External and type-11 Opaque LSAs 245 contained in the global structure. AS External and 246 type-11 Opaque LSAs are omitted from a virtual 247 neighbor's Database summary list. AS External LSAs 248 and type-11 Opaque LSAs are omitted from the 249 Database summary list if the area has been 250 configured as a stub area (see Section 3.6 of [OSPF]). 252 Type-9 Opaque LSAs are omitted from the Database 253 summary list if the interface associated with the 254 neighbor is not the interface associated with the 255 Opaque LSA (as noted upon reception). 257 Any advertisement whose age is equal to MaxAge is 258 omitted from the Database summary list. It is 259 instead added to the neighbor's link-state 260 retransmission list. A summary of the Database 261 summary list will be sent to the neighbor in 262 Database Description packets. Each Database 263 Description Packet has a DD sequence number, and is 264 explicitly acknowledged. Only one Database 265 Description Packet is allowed to be outstanding at 266 any one time. For more detail on the sending and 267 receiving of Database Description packets, see 268 Sections 10.6 and 10.8 of [OSPF]. 270 4.0 Protocol data structures 272 The Opaque option is described herein in terms of its operation on 273 various protocol data structures. These data structures are included 274 for explanatory uses only, and are not intended to constrain an imple- 275 mentation. In addition to the data structures listed below, this 276 specification references the various data structures (e.g., OSPF 277 neighbors) defined in [OSPF]. 279 In an OSPF router, the following item is added to the list of global 280 OSPF data structures described in Section 5 of [OSPF]: 282 o Opaque capability. Indicates whether the router is running the 283 Opaque option (i.e., capable of storing Opaque LSAs). Such a 284 router will continue to inter-operate with non-opaque-capable 285 OSPF routers. 287 4.1 Additions To The OSPF Neighbor Structure 289 The OSPF neighbor structure is defined in Section 10 of [OSPF]. In an 290 opaque-capable router, the following items are added to the OSPF 291 neighbor structure: 293 o Neighbor Options. This field was already defined in the OSPF 294 specification. However, in opaque-capable routers there is a new 295 option which indicates the neighbor's Opaque capability. This new 296 option is learned in the Database Exchange process through recep- 297 tion of the neighbor's Database Description packets, and deter- 298 mines whether Opaque LSAs are flooded to the neighbor. For a more 299 detailed explanation of the flooding of the Opaque LSA see sec- 300 tion 3 of this document. 302 5.0 Management Considerations 304 This section identifies the current OSPF MIB [OSPFMIB] capabilities 305 that are applicable to the Opaque option and lists the additional 306 management information which is required for its support. 308 Opaque LSAs are types 9, 10 and 11 link-state advertisements. The 309 link-state ID of the Opaque LSA is divided into an Opaque type field 310 (the first 8 bits) and a type-specific ID (the remaining 24 bits). 311 The packet format of the Opaque LSA is given in Appendix A. The range 312 of topological distribution (i.e., the flooding scope) of an Opaque 313 LSA is identified by its link-state type. 315 o Link-State type 9 Opaque LSAs have a link-local scope. Type-9 316 Opaque LSAs are flooded on a single local (sub)network but are 317 not flooded beyond the local (sub)network. 319 o Link-state type 10 Opaque LSAs have an area-local scope. Type- 320 10 Opaque LSAs are flooded throughout a single area but are not 321 flooded beyond the borders of the associated area. 323 o Link-state type 11 Opaque LSAs have an Autonomous-System-wide 324 scope. The flooding scope of type-11 LSAs are equivalent to the 325 flooding scope of AS-external (type-5) LSAs. 327 The OSPF MIB provides a number of objects that can be used to manage 328 and monitor an OSPF router's Link-State Database. The ones that are 329 relevant to the Opaque option are as follows. 331 The ospfGeneralGroup defines two objects for keeping track of 332 newly originated and newly received LSAs (ospfOriginateNewLsas 333 and ospfRxNewLsas respectively). 335 The OSPF MIB defines a set of optional traps. The ospfOrigina- 336 teLsa trap signifies that a new LSA has been originated by a 337 router and the ospfMaxAgeLsa trap signifies that one of the LSAs 338 in the router's link-state database has aged to MaxAge. 340 The ospfAreaTable describes the configured parameters and cumula- 341 tive statistics of the router's attached areas. This table 342 includes a count of the number of LSAs contained in the area's 343 link-state database (ospfAreaLsaCount), and a sum of the LSA's LS 344 checksums contained in this area (ospfAreaLsaCksumSum). This sum 345 can be used to determine if there has been a change in a router's 346 link-state database, and to compare the link-state database of 347 two routers. 349 The ospfLsdbTable describes the OSPF Process's link-state data- 350 base (excluding AS-external LSAs). Entries in this table are 351 indexed with an Area ID, a link-state type, a link-state ID and 352 the originating router's Router ID. 354 The management objects that are needed to support the Opaque option 355 are as follows. 357 An Opaque-option-enabled object is needed to indicate if the 358 Opaque option is enabled on the router. 360 The origination and reception of new Opaque LSAs should be 361 reflected in the counters ospfOriginateNewLsas and ospfRxNewLsas 362 (inclusive for types 9, 10 and 11 Opaque LSAs). 364 If the OSPF trap option is supported, the origination of new 365 Opaque LSAs and purging of MaxAge Opaque LSAs should be reflected 366 in the ospfOriginateLsa and ospfMaxAgeLsa traps (inclusive for 367 types 9, 10 and 11 Opaque LSAs). 369 The number of type-10 Opaque LSAs should be reflected in 370 ospfAreaLsaCount; the checksums of type-10 Opaque LSAs should be 371 included in ospfAreaLsaChksumSum. 373 Type-10 Opaque LSAs should be included in the ospfLsdbTable. 374 Note that this table does not include a method of examining the 375 Opaque type field (in the Opaque option this is a sub-field of 376 the link-state ID). 378 Up until now, LSAs have not had a link-local scope so there is no 379 method of requesting the number of, or examining the LSAs that 380 are associated with a specific OSPF interface. A new group of 381 management objects are required to support type-9 Opaque LSAs. 382 These objects should include a count of type-9 Opaque LSAs, a 383 checksum sum and a table for displaying the link-state database 384 for type-9 Opaque LSAs on a per-interface basis. Entries in this 385 table should be indexed with an Area ID, interface's IP address, 386 Opaque type, link-state ID and the originating router's Router 387 ID. 389 Prior to the introduction of type-11 Opaque LSAs, AS-External 390 (type-5) LSAs have been the only link-state types which have an 391 Autonomous-System-wide scope. A new group of objects are 392 required to support type-11 Opaque LSAs. These objects should 393 include a count of type-11 Opaque LSAs, a type-11 checksum sum 394 and a table for displaying the type-11 link-state database. 395 Entries in this table should be indexed with the Opaque type, 396 link-state ID and the originating router's Router ID. The type- 397 11 link-state database table will allow type-11 LSAs to be 398 displayed once for the router rather than once in each non-stub 399 area. 401 6.0 Security Considerations 403 There are two types of issues that need be addressed when looking at 404 protecting routing protocols from misconfigurations and malicious 405 attacks. The first is authentication and certification of routing 406 protocol information. The second is denial of service attacks result- 407 ing from repetitive origination of the same router advertisement or 408 origination a large number of distinct advertisements resulting in 409 database overflow. Note that both of these concerns exist indepen- 410 dently of a router's support for the Opaque option. 412 To address the authentication concerns, OSPF protocol exchanges are 413 authenticated. OSPF supports multiple types of authentication; the 414 type of authentication in use can be configured on a per network seg- 415 ment basis. One of OSPF's authentication types, namely the Crypto- 416 graphic authentication option, is believed to be secure against pas- 417 sive attacks and provide significant protection against active 418 attacks. When using the Cryptographic authentication option, each 419 router appends a "message digest" to its transmitted OSPF packets. 420 Receivers then use the shared secret key and received digest to verify 421 that each received OSPF packet is authentic. 423 The quality of the security provided by the Cryptographic authentica- 424 tion option depends completely on the strength of the message digest 425 algorithm (MD5 is currently the only message digest algorithm speci- 426 fied), the strength of the key being used, and the correct implementa- 427 tion of the security mechanism in all communicating OSPF implementa- 428 tions. It also requires that all parties maintain the secrecy of the 429 shared secret key. None of the standard OSPF authentication types 430 provide confidentiality. Nor do they protect against traffic analysis. 431 For more information on the standard OSPF security mechanisms, see 432 Sections 8.1, 8.2, and Appendix D of [OSPF]. 434 [DIGI] describes the extensions to OSPF required to add digital signa- 435 ture authentication to Link State data and to provide a certification 436 mechanism for router data. [DIGI] also describes the added LSA pro- 437 cessing and key management as well as a method for migration from, or 438 co-existence with, standard OSPF V2. 440 Repetitive origination of advertisements are addressed by OSPF by man- 441 dating a limit on the frequency that new instances of any particular 442 LSA can be originated and accepted during the flooding procedure. The 443 frequency at which new LSA instances may be originated is set equal to 444 once every MinLSInterval seconds, whose value is 5 seconds (see Sec- 445 tion 12.4 of [OSPF]). The frequency at which new LSA instances are 446 accepted during flooding is once every MinLSArrival seconds, whose 447 value is set to 1 (see Section 13, Appendix B and G.5 of [OSPF]). 449 Proper operation of the OSPF protocol requires that all OSPF routers 450 maintain an identical copy of the OSPF link-state database. However, 451 when the size of the link-state database becomes very large, some 452 routers may be unable to keep the entire database due to resource 453 shortages; we term this "database overflow". When database overflow 454 is anticipated, the routers with limited resources can be accommodated 455 by configuring OSPF stub areas and NSSAs. [OVERFLOW] details a way of 456 gracefully handling unanticipated database overflows. 458 7.0 References 460 [ARA] Coltun, R., Heinanen, J., "The OSPF Address Resolution 461 Advertisement Option", work in progress. 463 [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, 464 Cascade, April 1995. 466 [DIGI] S. Murphy, M. Badger, B. Wellington, "OSPF with Digital Signatures", 467 RFC 2154, Trusted Information Systems, June 1997. 469 [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, 470 Inc., March 1994. 472 [NSSA] Coltun, R., Fuller, V., "The OSPF NSSA Option", RFC 1587, 473 March 1994. 475 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, Cascade, April 1998. 477 [OSPFMIB] F. Baker, R. Coltun, "OSPF Version 2 Management Information 478 Base", RFC 1850, November 1995. 480 [OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, 481 Cascade, March 1995. 483 Appendix A: OSPF Data formats 485 This appendix describes the format of the Options Field followed by 486 the packet format of the Opaque LSA. 488 A.1 The Options Field 490 The OSPF Options field is present in OSPF Hello packets, Database 491 Description packets and all link-state advertisements. The Options 492 field enables OSPF routers to support (or not support) optional capa- 493 bilities, and to communicate their capability level to other OSPF 494 routers. Through this mechanism routers of differing capabilities can 495 be mixed within an OSPF routing domain. 497 When used in Hello packets, the Options field allows a router to 498 reject a neighbor because of a capability mismatch. Alternatively, 499 when capabilities are exchanged in Database Description packets a 500 router can choose not to forward certain link-state advertisements to 501 a neighbor because of its reduced functionality. Lastly, listing 502 capabilities in link-state advertisements allows routers to forward 503 traffic around reduced functionality routers by excluding them from 504 parts of the routing table calculation. 506 Six bits of the OSPF Options field have been assigned, although only 507 the O-bit is described completely by this memo. Each bit is described 508 briefly below. Routers should reset (i.e., clear) unrecognized bits in 509 the Options field when sending Hello packets or Database Description 510 packets and when originating link-state advertisements. Conversely, 511 routers encountering unrecognized Option bits in received Hello Pack- 512 ets, Database Description packets or link-state advertisements should 513 ignore the capability and process the packet/advertisement normally. 515 +------------------------------------+ 516 | * | O | DC | EA | N/P | MC | E | * | 517 +------------------------------------+ 519 The Options Field 521 E-bit 522 This bit describes the way AS-external-LSAs are flooded, as 523 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF]. 525 MC-bit 526 This bit describes whether IP multicast datagrams are forwarded 527 according to the specifications in [MOSPF]. 529 N/P-bit 530 This bit describes the handling of Type-7 LSAs, as specified in 531 [NSSA]. 533 DC-bit 534 This bit describes the router's handling of demand circuits, as 535 specified in [DEMD]. 537 EA-bit 538 This bit describes the router's willingness to receive and for- 539 ward External-Attributes-LSAs, as specified in [EAL]. 541 O-bit 542 This bit describes the router's willingness to receive and for- 543 ward Opaque-LSAs as specified in this document. 545 A.2 Opaque LSA 547 Opaque LSAs are Type 9, 10 and 11 link-state advertisements. These 548 advertisements may be used directly by OSPF or indirectly by some 549 application wishing to distribute information throughout the OSPF 550 domain. The function of the Opaque LSA option is to provide for 551 future extensibility of OSPF. 553 Opaque LSAs contain some number of octets (of application-specific 554 data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA 555 uses the link-state database distribution mechanism for flooding this 556 information throughout the topology. However, the Opaque LSA has a 557 flooding scope associated with it so that the scope of flooding may be 558 link-local (type 9), area-local (type 10) or the entire OSPF routing 559 domain (type 11). Section 3 of this document describes the flooding 560 procedures for the Opaque LSA. 562 0 1 2 3 563 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | LS age | Options | 9, 10 or 11 | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Opaque Type | Opaque ID | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Advertising Router | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | LS Sequence Number | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | LS checksum | Length | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | | 576 + + 577 | Opaque Information | 578 + + 579 | ... | 581 Link-State Type 583 The link-state type of the Opaque LSA identifies the LSA's range 584 of topological distribution. This range is referred to as the 585 Flooding Scope. The following explains the flooding scope of 586 each of the link-state types. 588 o A value of 9 denotes a link-local scope. Opaque LSAs with a 589 link-local scope are not flooded beyond the local (sub)network. 591 o A value of 10 denotes an area-local scope. Opaque LSAs with a 592 area-local scope are not flooded beyond the area that they are 593 originated into. 595 o A value of 11 denotes that the LSA is flooded throughout the 596 Autonomous System (e.g., has the same scope as type-5 LSAs). 597 Opaque LSAs with AS-wide scope are not flooded into stub areas. 599 Syntax Of The Opaque LSA's Link-State ID 601 The link-state ID of the Opaque LSA is divided into an Opaque 602 Type field (the first 8 bits) and an Opaque ID (the remaining 24 603 bits). Opaque type values in the range of 0-127 are reserved for 604 definition by the IANA (iana@ISI.EDU) whereas Opaque type values 605 in the range of 128-255 are reserved for private and experimental 606 use.