idnits 2.17.1 draft-ietf-ospf-opaque-04.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-19) 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 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: ' 5.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 152 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], [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 (February 1998) is 9560 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 411 looks like a reference -- Missing reference section? 'ARA' on line 351 looks like a reference -- Missing reference section? 'DIGI' on line 357 looks like a reference -- Missing reference section? 'OVERFLOW' on line 368 looks like a reference -- Missing reference section? 'DEMD' on line 423 looks like a reference -- Missing reference section? 'MOSPF' on line 415 looks like a reference -- Missing reference section? 'NSSA' on line 419 looks like a reference -- Missing reference section? 'EAL' on line 427 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Opaque February 1998 4 Expiration Date: August 1998 FORE Systems 5 File name: draft-ietf-ospf-opaque-04.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 .......................................... 3 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 Security Considerations .................................. 8 53 6.0 References ............................................... 10 55 Appendix A: OSPF Data Formats ................................ 11 57 A.1 The Options Field ........................................ 11 59 A.2 Opaque LSA ............................................... 13 61 1.0 Abstract 63 This memo defines enhancements to the OSPF protocol to support a new 64 class of link-state advertisements (LSA) called Opaque LSAs. Opaque 65 LSAs provide a generalized mechanism to allow for the future extensi- 66 bility of OSPF. Opaque LSAs consist of a standard LSA header followed 67 by application-specific information. The information field may be 68 used directly by OSPF or by other applications. Standard OSPF link- 69 state database flooding mechanisms are used to distribute Opaque LSAs 70 to all or some limited portion of the OSPF topology. 72 2.0 Overview 74 Over the last several years the OSPF routing protocol [OSPF] has been 75 widely deployed throughout the Internet. As a result of this deploy- 76 ment and the evolution of networking technology, OSPF has been 77 extended to support many options; this evolution will obviously con- 78 tinue. 80 This memo defines enhancements to the OSPF protocol to support a new 81 class of link-state advertisements (LSA) called Opaque LSAs. Opaque 82 LSAs provide a generalized mechanism to allow for the future extensi- 83 bility of OSPF. The information contained in Opaque LSAs may be used 84 directly by OSPF or indirectly by some application wishing to distri- 85 bute information throughout the OSPF domain. For example, the OSPF 86 LSA may be used by routers to distribute IP to link-layer address 87 resolution information (see [ARA] for more information). The exact 88 use of Opaque LSAs is beyond the scope of this draft. 90 Opaque LSAs consist of a standard LSA header followed by a 32-bit 91 aligned application-specific information field. Like any other LSA, 92 the Opaque LSA uses the link-state database distribution mechanism for 93 flooding this information throughout the topology. The link-state 94 type field of the Opaque LSA identifies the LSA's range of topological 95 distribution. This range is referred to as the Flooding Scope. 97 2.1 Organization Of This Document 99 This document first defines the three types of Opaque LSAs followed by 100 a description of OSPF packet processing. The packet processing sec- 101 tions include modifications to the flooding procedure and to the 102 neighbor state machine. Appendix A then gives the packet formats. 104 2.2 Acknowledgments 105 The author would like to thank Dennis Ferguson, Acee Lindem, John Moy, 106 Sandra Murphy, Zhaohui "Jeffrey" Zhang and the rest of the OSPF Work- 107 ing Group for the ideas and support they have given to this project. 109 3.0 The Opaque LSA 111 Opaque LSAs are types 9, 10 and 11 link-state advertisements. Each 112 type has a unique flooding scope. Opaque LSAs consist of a standard 113 LSA header followed by a 32-bit aligned application-specific informa- 114 tion field. Standard link-state database flooding mechanisms are used 115 for distribution of Opaque LSAs. The range of topological distribu- 116 tion (i.e., the flooding scope) of an Opaque LSA is identified by its 117 link-state type. This section documents the flooding of Opaque LSAs. 119 The flooding scope associated with each Opaque link-state type is 120 defined as follows. 122 o Link-state type 9 denotes a link-local scope. Type-9 Opaque 123 LSAs are not flooded beyond the local (sub)network. 125 o Link-state type 10 denotes an area-local scope. Type-10 Opaque 126 LSAs are not flooded beyond the borders of their associated area. 128 o Link-state type 11 denotes that the LSA is flooded throughout 129 the Autonomous System (AS). The flooding scope of type-11 LSAs 130 are equivalent to the flooding scope of AS-external (type-5) 131 LSAs. Specifically type-11 Opaque LSAs are 1) flooded throughout 132 all transit areas, 2) not flooded into stub areas from the back- 133 bone and 3) not originated by routers into their connected stub 134 areas. As with type-5 LSAs, if a type-11 Opaque LSA is received 135 in a stub area from a neighboring router within the stub area the 136 LSA is rejected. 138 The link-state ID of the Opaque LSA is divided into a type field (the 139 first 8 bits) and a type-specific ID (the remaining 24 bits). The 140 packet format of the Opaque LSA is given in Appendix A. 142 The responsibility for proper handling of the Opaque LSA's flooding 143 scope is placed on both the sender and receiver of the LSA. The 144 receiver must always store a valid received Opaque LSA in its link- 145 state database. The receiver must not accept Opaque LSAs that violate 146 the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA is not 147 accepted in a stub area). The flooding scope effects both the build- 148 ing of the Database Summary List during the initial synchronization of 149 the link-state database and the flooding procedure. 151 The following describes the modifications to these procedures that are 152 necessary to insure conformance to the Opaque LSA's Scoping Rules. 154 3.1 Flooding Opaque LSAs 156 The flooding of Opaque LSAs must follow the rules of Flooding Scope as 157 specified in this section. Section 13 of [OSPF] describes the OSPF 158 flooding procedure. The following describes the Opaque LSA's type- 159 specific flooding restrictions. 161 o If the Opaque LSA is type 9 (the flooding scope is link-local) 162 and the interface that the LSA was received on is not the same as 163 the target interface (e.g., the interface associated with a par- 164 ticular target neighbor), the Opaque LSA must not be flooded out 165 that interface (or to that neighbor). An implementation should 166 keep track of the IP interface associated with each Opaque LSA 167 having a link-local flooding scope. 169 o If the Opaque LSA is type 10 (the flooding scope is area-local) 170 and the area associated with Opaque LSA (upon reception) is not 171 the same as the area associated with the target interface, the 172 Opaque LSA must not be flooded out the interface. An implementa- 173 tion should keep track of the OSPF area associated with each 174 Opaque LSA having an area-local flooding scope. 176 o If the Opaque LSA is type 11 (the LSA is flooded throughout the 177 AS) and the target interface is associated with a stub area the 178 Opaque LSA must not be flooded out the interface. A type-11 179 Opaque LSA that is received on an interface associated with a 180 stub area must be discarded and not acknowledged (the neighboring 181 router has flooded the LSA in error). 183 When opaque-capable routers and non-opaque-capable OSPF routers are 184 mixed together in a routing domain, the Opaque LSAs are not flooded to 185 the non-opaque-capable routers. As a general design principle, 186 optional OSPF advertisements are only flooded to those routers that 187 understand them. 189 An opaque-capable router learns of its neighbor's opaque capability at 190 the beginning of the "Database Exchange Process" (see Section 10.6 of 191 [OSPF], receiving Database Description packets from a neighbor in 192 state ExStart). A neighbor is opaque-capable if and only if it sets 193 the O-bit in the Options field of its Database Description packets. 194 Then, in the next step of the Database Exchange process, Opaque LSAs 195 are included in the Database summary list that is sent to the neighbor 196 (see Sections 3.2 below and 10.3 of [OSPF]) if and only if the 197 neighbor is opaque capable. 199 When flooding Opaque-LSAs to adjacent neighbors, a opaque-capable 200 router looks at the neighbor's opaque capability. Opaque LSAs are 201 only flooded to opaque-capable neighbors. To be more precise, in Sec- 202 tion 13.3 of [OSPF], Opaque LSAs are only placed on the link-state 203 retransmission lists of opaque-capable neighbors. However, when send- 204 ing Link State Update packets as multicasts, a non-opaque-capable 205 neighbor may (inadvertently) receive Opaque LSAs. The non-opaque- 206 capable router will then simply discard the LSA (see Section 13 of 207 [OSPF], receiving LSAs having unknown LS types). 209 3.2 Modifications To The Neighbor State Machine 211 The state machine as it exists in section 10.3 of [OSPF] remains 212 unchanged except for the action associated with State: ExStart, Event: 213 NegotiationDone which is where the Database summary list is built. To 214 incorporate the Opaque LSA in OSPF this action is changed to the fol- 215 lowing. 217 State(s): ExStart 219 Event: NegotiationDone 221 New state: Exchange 223 Action: The router must list the contents of its entire area 224 link-state database in the neighbor Database summary 225 list. The area link-state database consists of the 226 Router LSAs, Network LSAs, Summary LSAs and types 9 227 and 10 Opaque LSAs contained in the area structure, 228 along with AS External and type-11 Opaque LSAs 229 contained in the global structure. AS External and 230 type-11 Opaque LSAs are omitted from a virtual 231 neighbor's Database summary list. AS External LSAs 232 and type-11 Opaque LSAs are omitted from the 233 Database summary list if the area has been 234 configured as a stub area (see Section 3.6 of [OSPF]). 236 Opaque LSAs are omitted from the Database 237 summary list if the following conditions exist. 238 1) the LSA type is type 9 (the flooding scope 239 is link-local) and interface associated with the 240 neighbor is not the interface associated with 241 the Opaque LSA (as noted upon reception); 242 2) the LSA type is 10 (the flooding scope is 243 area-local) and the area associated with the 244 neighbor's interface is not the area associated 245 with the Opaque LSA (as noted upon reception). 247 Any advertisement whose age is equal to MaxAge is 248 omitted from the Database summary list. It is 249 instead added to the neighbor's link-state 250 retransmission list. A summary of the Database 251 summary list will be sent to the neighbor in 252 Database Description packets. Each Database 253 Description Packet has a DD sequence number, and is 254 explicitly acknowledged. Only one Database 255 Description Packet is allowed to be outstanding at 256 any one time. For more detail on the sending and 257 receiving of Database Description packets, see 258 Sections 10.6 and 10.8 of [OSPF]. 260 4.0 Protocol data structures 262 The Opaque option is described herein in terms of its operation on 263 various protocol data structures. These data structures are included 264 for explanatory uses only, and are not intended to constrain an imple- 265 mentation. In addition to the data structures listed below, this 266 specification references the various data structures (e.g., OSPF 267 neighbors) defined in [OSPF]. 269 In an OSPF router, the following item is added to the list of global 270 OSPF data structures described in Section 5 of [OSPF]: 272 o Opaque capability. Indicates whether the router is running the 273 Opaque option (i.e., capable of storing Opaque LSAs). Such a 274 router will continue to inter-operate with non-opaque-capable 275 OSPF routers. 277 4.1 Additions To The OSPF Neighbor Structure 279 The OSPF neighbor structure is defined in Section 10 of [OSPF]. In an 280 opaque-capable router, the following items are added to the OSPF 281 neighbor structure: 283 o Neighbor Options. This field was already defined in the OSPF 284 specification. However, in opaque-capable routers there is a new 285 option which indicates the neighbor's Opaque capability. This new 286 option is learned in the Database Exchange process through recep- 287 tion of the neighbor's Database Description packets, and deter- 288 mines whether Opaque LSAs are flooded to the neighbor. For a more 289 detailed explanation of the flooding of the Opaque LSA see sec- 290 tion 3 of this document. 292 5.0 Security Considerations 294 There are two types of issues that need be addressed when looking at 295 protecting routing protocols from misconfigurations and malicious 296 attacks. The first is authentication and certification of routing 297 protocol information. The second is denial of service attacks result- 298 ing from repetitive origination of the same router advertisement or 299 origination a large number of distinct advertisements resulting in 300 database overflow. Note that both of these concerns exist indepen- 301 dently of a router's support for the Opaque option. 303 To address the authentication concerns, OSPF protocol exchanges are 304 authenticated. OSPF supports multiple types of authentication; the 305 type of authentication in use can be configured on a per network seg- 306 ment basis. One of OSPF's authentication types, namely the Crypto- 307 graphic authentication option, is believed to be secure against pas- 308 sive attacks and provide significant protection against active 309 attacks. When using the Cryptographic authentication option, each 310 router appends a "message digest" to its transmitted OSPF packets. 311 Receivers then use the shared secret key and received digest to verify 312 that each received OSPF packet is authentic. 314 The quality of the security provided by the Cryptographic authentica- 315 tion option depends completely on the strength of the message digest 316 algorithm (MD5 is currently the only message digest algorithm speci- 317 fied), the strength of the key being used, and the correct implementa- 318 tion of the security mechanism in all communicating OSPF implementa- 319 tions. It also requires that all parties maintain the secrecy of the 320 shared secret key. None of the standard OSPF authentication types 321 provide confidentiality. Nor do they protect against traffic analysis. 322 For more information on the standard OSPF security mechanisms, see 323 Sections 8.1, 8.2, and Appendix D of [OSPF]. 325 [DIGI] describes the extensions to OSPF required to add digital signa- 326 ture authentication to Link State data and to provide a certification 327 mechanism for router data. [DIGI] also describes the added LSA pro- 328 cessing and key management as well as a method for migration from, or 329 co-existence with, standard OSPF V2. 331 Repetitive origination of advertisements are addressed by OSPF by man- 332 dating a limit on the frequency that new instances of any particular 333 LSA can be originated and accepted during the flooding procedure. The 334 frequency at which new LSA instances may be originated is set equal to 335 once every MinLSInterval seconds, whose value is 5 seconds (see Sec- 336 tion 12.4 of [OSPF]). The frequency at which new LSA instances are 337 accepted during flooding is once every MinLSArrival seconds, whose 338 value is set to 1 (see Section 13, Appendix B and G.5 of [OSPF]). 340 Proper operation of the OSPF protocol requires that all OSPF routers 341 maintain an identical copy of the OSPF link-state database. However, 342 when the size of the link-state database becomes very large, some 343 routers may be unable to keep the entire database due to resource 344 shortages; we term this "database overflow". When database overflow 345 is anticipated, the routers with limited resources can be accommodated 346 by configuring OSPF stub areas and NSSAs. [OVERFLOW] details a way of 347 gracefully handling unanticipated database overflows. 349 6.0 References 351 [ARA] Coltun, R., Heinanen, J., "The OSPF Address Resolution 352 Advertisement Option", draft-ietf-ospf-ara-01.txt, November 1997. 354 [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, 355 Cascade, April 1995. 357 [DIGI] S. Murphy, M. Badger, B. Wellington, "OSPF with Digital Signatures", 358 RFC 2154, Trusted Information Systems, June 1997. 360 [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, 361 Inc., March 1994. 363 [NSSA] Coltun, R., Fuller, V., Murphy, P., "The OSPF NSSA Option", 364 draft-ietf-ospf-nssa-update-02.txt, April 1997. 366 [OSPF] Moy, J., "OSPF Version 2", RFC 2178 Cascade, July 1997. 368 [OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, 369 Cascade, March 1995. 371 Appendix A: OSPF Data formats 373 This appendix describes the format of the Options Field followed by 374 the packet format of the Opaque LSA. 376 A.1 The Options Field 378 The OSPF Options field is present in OSPF Hello packets, Database 379 Description packets and all link-state advertisements. The Options 380 field enables OSPF routers to support (or not support) optional capa- 381 bilities, and to communicate their capability level to other OSPF 382 routers. Through this mechanism routers of differing capabilities can 383 be mixed within an OSPF routing domain. 385 When used in Hello packets, the Options field allows a router to 386 reject a neighbor because of a capability mismatch. Alternatively, 387 when capabilities are exchanged in Database Description packets a 388 router can choose not to forward certain link-state advertisements to 389 a neighbor because of its reduced functionality. Lastly, listing 390 capabilities in link-state advertisements allows routers to forward 391 traffic around reduced functionality routers by excluding them from 392 parts of the routing table calculation. 394 Six bits of the OSPF Options field have been assigned, although only 395 the O-bit is described completely by this memo. Each bit is described 396 briefly below. Routers should reset (i.e., clear) unrecognized bits in 397 the Options field when sending Hello packets or Database Description 398 packets and when originating link-state advertisements. Conversely, 399 routers encountering unrecognized Option bits in received Hello Pack- 400 ets, Database Description packets or link-state advertisements should 401 ignore the capability and process the packet/advertisement normally. 403 +------------------------------------+ 404 | * | O | DC | EA | N/P | MC | E | * | 405 +------------------------------------+ 407 The Options Field 409 E-bit 410 This bit describes the way AS-external-LSAs are flooded, as 411 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF]. 413 MC-bit 414 This bit describes whether IP multicast datagrams are forwarded 415 according to the specifications in [MOSPF]. 417 N/P-bit 418 This bit describes the handling of Type-7 LSAs, as specified in 419 [NSSA]. 421 DC-bit 422 This bit describes the router's handling of demand circuits, as 423 specified in [DEMD]. 425 EA-bit 426 This bit describes the router's willingness to receive and for- 427 ward External-Attributes-LSAs, as specified in [EAL]. 429 O-bit 430 This bit describes the router's willingness to receive and for- 431 ward Opaque-LSAs as specified in this document. 433 A.2 Opaque LSA 435 Opaque LSAs are Type 9, 10 and 11 link-state advertisements. These 436 advertisements may be used directly by OSPF or indirectly by some 437 application wishing to distribute information throughout the OSPF 438 domain. The function of the Opaque LSA option is to provide for 439 future extensibility of OSPF. 441 Opaque LSAs contain some number of octets (of application-specific 442 data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA 443 uses the link-state database distribution mechanism for flooding this 444 information throughout the topology. However, the Opaque LSA has a 445 flooding scope associated with it so that the scope of flooding may be 446 link-local (type 9), area-local (type 10) or the entire OSPF routing 447 domain (type 11). Section 3 of this document describes the flooding 448 procedures for the Opaque LSA. 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | LS age | Options | 9, 10 or 11 | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Opaque Type | Opaque ID | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Advertising Router | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | LS Sequence Number | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | LS checksum | Length | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | | 464 + + 465 | Opaque Information | 466 + + 467 | ... | 469 Link-State Type 471 The link-state type of the Opaque LSA identifies the LSA's range 472 of topological distribution. This range is referred to as the 473 Flooding Scope. The following explains the flooding scope of 474 each of the link-state types. 476 o A value of 9 denotes a link-local scope. Opaque LSAs with a 477 link-local scope are not flooded beyond the local (sub)network. 479 o A value of 10 denotes an area-local scope. Opaque LSAs with a 480 area-local scope are not flooded beyond the area that they are 481 originated into. 483 o A value of 11 denotes that the LSA is flooded throughout the 484 Autonomous System (e.g., has the same scope as type-5 LSAs). 485 Opaque LSAs with AS-wide scope are not flooded into stub areas. 487 Syntax Of The Opaque LSA's Link-State ID 489 The link-state ID of the Opaque LSA is divided into an Opaque 490 Type field (the first 8 bits) and an Opaque ID (the remaining 24 491 bits). Opaque type values in the range of 128-255 are reserved 492 for private and experimental use.