idnits 2.17.1 draft-ietf-ospf-rfc2370bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 671. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 682. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 689. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 695. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2370]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2006) is 6341 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' -- No information found for draft-ietf-ospf-mib-update- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MIB-UPDATE' -- No information found for draft-ietf-ospf-mt- - is the name correct? -- No information found for draft-ietf-ospf-ospfv3-update- - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2370 (Obsoleted by RFC 5250) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 13 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: June 2007 Original Author: 5 Rob Coltun (Acoustra Productions) 7 December 2006 9 The OSPF Opaque LSA Option 11 draft-ietf-ospf-rfc2370bis-00.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 Abstract 38 This memo defines enhancements to the OSPF protocol to support a new 39 class of link-state advertisements (LSA) called Opaque LSAs. Opaque 40 LSAs provide a generalized mechanism to allow for the future 41 extensibility of OSPF. Opaque LSAs consist of a standard LSA header 42 followed by application-specific information. The information field 43 may be used directly by OSPF or by other applications. Standard OSPF 44 link-state database flooding mechanisms are used to distribute Opaque 45 LSAs to all or some limited portion of the OSPF topology. 47 This document replaces [RFC2370], and adds to it a mechanism to 48 enable an OSPF router to validate AS-scope opaque LSAs originated 49 outside of the router's OSPF area. 51 Contents 53 1 Conventions used in this document ......................... 3 54 2 Overview .................................................. 3 55 2.1 Organization Of This Document ............................. 3 56 2.2 Acknowledgments ........................................... 4 57 3 The Opaque LSA ............................................ 4 58 3.1 Flooding Opaque LSAs ...................................... 5 59 3.2 Modifications To The Neighbor State Machine ............... 6 60 4 Protocol Data Structures .................................. 7 61 4.1 Additions To The OSPF Neighbor Structure .................. 8 62 5 Inter-Area Considerations ................................. 8 63 6 Management Considerations ................................. 9 64 7 Backward Compatibility .................................... 9 65 8 Security Considerations ................................... 10 66 9 IANA Considerations ....................................... 11 67 10 References ................................................ 11 68 10.1 Normative References ...................................... 11 69 10.2 Informative References .................................... 12 70 11 Author's Addresses ........................................ 12 71 12 Appendix A: OSPF Data formats ............................. 13 72 12.1 The Options Field ......................................... 13 73 12.2 The Opaque LSA ............................................ 14 74 13 Full Copyright Statement .................................. 16 75 14 Intellectual Property ..................................... 16 76 1. Conventions used in this document 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 2. Overview 84 Over the last several years the OSPF routing protocol [OSPF] has been 85 widely deployed throughout the Internet. As a result of this 86 deployment and the evolution of networking technology, OSPF has been 87 extended to support many options; this evolution will obviously 88 continue. 90 This memo defines enhancements to the OSPF protocol to support a new 91 class of link-state advertisements (LSA) called Opaque LSAs. Opaque 92 LSAs provide a generalized mechanism to allow for the future 93 extensibility of OSPF. The information contained in Opaque LSAs may 94 be used directly by OSPF or indirectly by some application wishing to 95 distribute information throughout the OSPF domain. The exact use of 96 Opaque LSAs is beyond the scope of this memo. 98 Opaque LSAs consist of a standard LSA header followed by a 32-bit 99 aligned application-specific information field. Like any other LSA, 100 the Opaque LSA uses the link-state database distribution mechanism 101 for flooding this information throughout the topology. The link- 102 state type field of the Opaque LSA identifies the LSA's range of 103 topological distribution. This range is referred to as the Flooding 104 Scope. 106 It is envisioned that an implementation of the Opaque option provides 107 an application interface for 1) encapsulating application-specific 108 information in a specific Opaque type, 2) sending and receiving 109 application-specific information, and 3) if required, informing the 110 application of the change in validity of previously received 111 information when topological changes are detected. 113 2.1. Organization Of This Document 115 This document first defines the three types of Opaque LSAs followed 116 by a description of OSPF packet processing. The packet processing 117 sections include modifications to the flooding procedure and to the 118 neighbor state machine. Appendix A then gives the packet formats. 120 2.2. Acknowledgments 122 We would like to thank Acee Lindem for his review and useful 123 feedback. The handling of AS-scope opaque LSAs described in this 124 document is taken from draft-bryskin-ospf-lsa- 125 type11-validation-00.txt. 127 3. The Opaque LSA 129 Opaque LSAs are types 9, 10 and 11 link-state advertisements. Opaque 130 LSAs consist of a standard LSA header followed by a 32-bit aligned 131 application-specific information field. Standard link-state database 132 flooding mechanisms are used for distribution of Opaque LSAs. The 133 range of topological distribution (i.e., the flooding scope) of an 134 Opaque LSA is identified by its link-state type. This section 135 documents the flooding of Opaque LSAs. 137 The flooding scope associated with each Opaque link-state type is 138 defined as follows. 140 o Link-state type-9 denotes a link-local scope. Type-9 Opaque 141 LSAs are not flooded beyond the local (sub)network. 143 o Link-state type-10 denotes an area-local scope. Type-10 Opaque 144 LSAs are not flooded beyond the borders of their associated area. 146 o Link-state type-11 denotes that the LSA is flooded throughout 147 the Autonomous System (AS). The flooding scope of type-11 148 LSAs are equivalent to the flooding scope of AS-external (type-5) 149 LSAs. Specifically type-11 Opaque LSAs are 1) flooded throughout 150 all transit areas, 2) not flooded into stub areas or NSSAs from 151 the backbone and 3) not originated by routers into their 152 connected stub areas or NSSAs. As with type-5 LSAs, if a type-11 153 Opaque LSA is received in a stub area or NSSA from a neighboring 154 router within the stub area or NSSA the LSA is rejected. 156 The link-state ID of the Opaque LSA is divided into an Opaque type 157 field (the first 8 bits) and a type-specific ID (the remaining 24 158 bits). The packet format of the Opaque LSA is given in Appendix A. 159 Section 7 describes Opaque type allocation and assignment. 161 The responsibility for proper handling of the Opaque LSA's flooding 162 scope is placed on both the sender and receiver of the LSA. The 163 receiver must always store a valid received Opaque LSA in its link- 164 state database. The receiver must not accept Opaque LSAs that 165 violate the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA 166 is not accepted in a stub area or NSSA). The flooding scope effects 167 both the synchronization of the link-state database and the flooding 168 procedure. 170 The following describes the modifications to these procedures that 171 are necessary to insure conformance to the Opaque LSA's Scoping 172 Rules. 174 3.1. Flooding Opaque LSAs 176 The flooding of Opaque LSAs MUST follow the rules of Flooding Scope 177 as specified in this section. Section 13 of [OSPF] describes the 178 OSPF flooding procedure. Those procedures MUST be followed as 179 defined except where modified in this section. The following 180 describes the Opaque LSA's type-specific flooding restrictions. 182 o If the Opaque LSA is type-9 (the flooding scope is link-local) 183 and the interface that the LSA was received on is not the same 184 as the target interface (e.g., the interface associated with a 185 particular target neighbor), the Opaque LSA MUST be discarded 186 and not acknowledged. An implementation SHOULD keep track of 187 the IP interface associated with each Opaque LSA having a 188 link-local flooding scope. 190 o If the Opaque LSA is type-10 (the flooding scope is area-local) 191 and the area associated with Opaque LSA (as identified during 192 origination or from a received LSA's associated OSPF packet 193 header) is not the same as the area associated with the target 194 interface, the Opaque LSA MUST be discarded and not 195 acknowledged. An implementation SHOULD keep track of the OSPF 196 area associated with each Opaque LSA having an area-local 197 flooding scope. 199 o If the Opaque LSA is type-11 (the LSA is flooded throughout the 200 AS) and the target interface is associated with a stub area or 201 NSSA, the Opaque LSA MUST NOT be flooded out the interface. A 202 type-11 Opaque LSA that is received on an interface associated 203 with a stub area or NSSA MUST be discarded and not acknowledged 204 (the neighboring router has flooded the LSA in error). 206 When opaque-capable routers and non-opaque-capable OSPF routers are 207 mixed together in a routing domain, the Opaque LSAs are typically not 208 flooded to the non-opaque-capable routers. As a general design 209 principle, optional OSPF advertisements are only flooded to those 210 routers that understand them. 212 An opaque-capable router learns of its neighbor's opaque capability 213 at the beginning of the "Database Exchange Process" (see Section 10.6 214 of [OSPF], receiving Database Description packets from a neighbor in 215 state ExStart). A neighbor is opaque-capable if and only if it sets 216 the O-bit in the Options field of its Database Description packets; 217 the O-bit MUST NOT be set in packets other than Database Description 218 packets. Then, in the next step of the Database Exchange process, 219 Opaque LSAs are included in the Database summary list that is sent to 220 the neighbor (see Sections 3.2 below and 10.3 of [OSPF]) when the 221 neighbor is opaque capable. 223 When flooding Opaque-LSAs to adjacent neighbors, an opaque-capable 224 router looks at the neighbor's opaque capability. Opaque LSAs are 225 only flooded to opaque-capable neighbors. To be more precise, in 226 Section 13.3 of [OSPF], Opaque LSAs MUST placed on the link-state 227 retransmission lists of opaque-capable neighbors, and MUST NOT be 228 placed on the link-state retransmission lists of non-opaque-capable 229 neighbors. However, when sending Link State Update packets as 230 multicasts, a non-opaque-capable neighbor may (inadvertently) receive 231 Opaque LSAs. The non-opaque-capable router will then simply discard 232 the LSA (see Section 13 of [OSPF], receiving LSAs having unknown LS 233 types). 235 Information contained in received opaque LSAs SHOULD only be used 236 when the router originating the LSA is reachable. As mentioned in 237 [OSPFv3], reachability validation MAY be done less frequently than 238 every SPF calculation. Additionally, routers processing received 239 opaque LSAs MAY choose to give priority to processing base OSPF LSA 240 types over opaque LSA types. 242 3.2. Modifications To The Neighbor State Machine 244 The state machine as it exists in section 10.3 of [OSPF] remains 245 unchanged except for the action associated with State: ExStart, 246 Event: NegotiationDone which is where the Database summary list is 247 built. To incorporate the Opaque LSA in OSPF this action is changed 248 to the following. 250 State(s): ExStart 252 Event: NegotiationDone 254 New state: Exchange 256 Action: The router MUST list the contents of its entire area 257 link-state database in the neighbor Database summary 258 list. The area link-state database consists of the 259 Router LSAs, Network LSAs, Summary LSAs and types 9 and 260 10 Opaque LSAs contained in the area structure, along 261 with AS External and type-11 Opaque LSAs contained in 262 the global structure. AS External and type-11 Opaque 263 LSAs MUST be omitted from a virtual neighbor's Database 264 summary list. AS External LSAs and type-11 Opaque LSAs 265 MUST be omitted from the Database summary list if the 266 area has been configured as a stub area or NSSA (see 267 Section 3.6 of [OSPF]). 269 Type-9 Opaque LSAs MUST be omitted from the Database 270 summary list if the interface associated with the 271 neighbor is not the interface associated with the Opaque 272 LSA (as noted upon reception). 274 Any advertisement whose age is equal to MaxAge MUST be 275 omitted from the Database summary list. It MUST instead 276 be added to the neighbor's link-state retransmission 277 list. A summary of the Database summary list will be 278 sent to the neighbor in Database Description packets. 279 Each Database Description Packet MUST have a DD sequence 280 number, and MUST be explicitly acknowledged. Only one 281 Database Description Packet is allowed to be outstanding 282 at any one time. For more detail on the sending and 283 receiving of Database Description packets, see Sections 284 10.6 and 10.8 of [OSPF]. 286 4. Protocol Data Structures 288 The Opaque option is described herein in terms of its operation on 289 various protocol data structures. These data structures are included 290 for explanatory uses only, and are not intended to constrain an 291 implementation. In addition to the data structures listed below, this 292 specification references the various data structures (e.g., OSPF 293 neighbors) defined in [OSPF]. 295 In an OSPF router, the following item is added to the list of global 296 OSPF data structures described in Section 5 of [OSPF]: 298 o Opaque capability. Indicates whether the router is running the 299 Opaque option (i.e., capable of storing Opaque LSAs). Such a 300 router will continue to inter-operate with non-opaque-capable 301 OSPF routers. 303 4.1. Additions To The OSPF Neighbor Structure 305 The OSPF neighbor structure is defined in Section 10 of [OSPF]. In 306 an opaque-capable router, the following items are added to the OSPF 307 neighbor structure: 309 o Neighbor Options. This field was already defined in the OSPF 310 specification. However, in opaque-capable routers there is a new 311 option which indicates the neighbor's Opaque capability. This new 312 option is learned in the Database Exchange process through 313 reception of the neighbor's Database Description packets, and 314 determines whether Opaque LSAs are flooded to the neighbor. For a 315 more detailed explanation of the flooding of the Opaque LSA see 316 section 3 of this document. 318 5. Inter-Area Considerations 320 As defined above, link-state type-11 opaque LSAs are flooded 321 throughout the Autonomous System (AS). One issue related to such AS 322 scoped Opaque LSAs is that there must be a way for OSPF routers in 323 remote areas to check availability of the LSA originator. 324 Specifically, if an OSPF router originates a type-11 LSA and, after 325 that, goes out of service, OSPF routers located outside of the 326 originator's OSPF area have no way of detecting this fact and may use 327 the stale information for a considerable period of time (up to 60 328 minutes). This could prove to be suboptimal for some applications, 329 and may result in others not functioning. 331 Type-9 opaque LSAs and type-10 opaque LSAs do not have this problem 332 as a receiving router can detect an out of service router via the 333 loss of an OSPF adjacency, in the case of type-9 LSAs, or the loss of 334 the sequence of OSPF adjacencies, in the case of type-10 LSAs, 335 connecting the LSA receiving and originating routers. 337 There is a parallel issue in OSPF for the AS scoped AS-external-LSAs 338 (type-5 LSAs). OSPF addresses this by using AS border information 339 advertised in ASBR-summary-LSAs (type-4 LSAs), see [OSPF] Section 340 16.4. This same mechanism is reused by this document for type-11 341 opaque LSAs. 343 To enable OSPF routers in remote areas to check availability of the 344 originator of link-state type-11 opaque LSAs, the originators 345 advertise themselves as ASBRs. This will enable routers to track the 346 reachability of the LSA originator either directly via the SPF 347 calculation (for routers in the same area) or indirectly via type-4 348 LSAs originated by ABRs (for routers in other areas). It is important 349 to note that per [OSPF] this solution does not apply to OSPF stub 350 areas or NSSAs as neither are AS scoped Opaque LSAs flooded nor are 351 ASBR-summary-LSAs originated into such areas. 353 The procedures related to inter-area opaque LSAs are as follows: 355 (1) An OSPF router that is configured to originate AS-scope opaque 356 LSAs advertise themselves as ASBRs and MUST follow the related 357 requirements related to setting of the Options field E-bit in 358 OSPF LSA headers as specified in [OSPF]. 360 (2) When processing a received type-11 Opaque LSA, the router MUST 361 lookup the routing table entries (potentially one per attached 362 area) for the AS boundary router (ASBR) that originated the LSA. 363 If no entries exist for router ASBR (i.e., ASBR is unreachable), 364 the router MUST do nothing with this LSA. It also MUST 365 discontinue using all Opaque LSAs injected into the network by 366 the same originator whenever it is detected that the originator 367 is unreachable. 369 6. Management Considerations 371 The updated OSPF MIB provides explicit support for opaque LSAs and 372 SHOULD be used to support implementations of this document. See 373 Section 12.3 of [MIB-UPDATE] for details. In addition to this 374 section, implementation supporting [MIB-UPDATE] will include opaque 375 LSAs in all appropriate generic LSA objects, e.g., 376 ospfOriginateNewLsas, ospfOriginateNewLsas and ospfLsdbTable. 378 7. Backward Compatibility 380 The solution proposed in this memo introduces no interoperability 381 issues. In the case that a non-opaque-capable neighbor receives 382 Opaque LSAs, per [OSPF], the non-opaque-capable router will simply 383 discard the LSA. 385 Note, that OSPF routers that implement [RFC2370] will continue using 386 stale type-11 LSAs even when the LSA originator implements the Inter- 387 area procedures, see Section 6, of this document. 389 8. Security Considerations 391 There are two types of issues that need be addressed when looking at 392 protecting routing protocols from misconfigurations and malicious 393 attacks. The first is authentication and certification of routing 394 protocol information. The second is denial of service attacks 395 resulting from repetitive origination of the same router 396 advertisement or origination a large number of distinct 397 advertisements resulting in database overflow. Note that both of 398 these concerns exist independently of a router's support for the 399 Opaque option. 401 To address the authentication concerns, OSPF protocol exchanges are 402 authenticated. OSPF supports multiple types of authentication; the 403 type of authentication in use can be configured on a per network 404 segment basis. One of OSPF's authentication types, namely the 405 Cryptographic authentication option, is believed to be secure against 406 passive attacks and provide significant protection against active 407 attacks. When using the Cryptographic authentication option, each 408 router appends a "message digest" to its transmitted OSPF packets. 409 Receivers then use the shared secret key and received digest to 410 verify that each received OSPF packet is authentic. 412 The quality of the security provided by the Cryptographic 413 authentication option depends completely on the strength of the 414 message digest algorithm (MD5 is currently the only message digest 415 algorithm specified), the strength of the key being used, and the 416 correct implementation of the security mechanism in all communicating 417 OSPF implementations. It also requires that all parties maintain the 418 secrecy of the shared secret key. None of the standard OSPF 419 authentication types provide confidentiality. Nor do they protect 420 against traffic analysis. For more information on the standard OSPF 421 security mechanisms, see Sections 8.1, 8.2, and Appendix D of [OSPF]. 423 Repetitive origination of advertisements are addressed by OSPF by 424 mandating a limit on the frequency that new instances of any 425 particular LSA can be originated and accepted during the flooding 426 procedure. The frequency at which new LSA instances may be 427 originated is set equal to once every MinLSInterval seconds, whose 428 value is 5 seconds (see Section 12.4 of [OSPF]). The frequency at 429 which new LSA instances are accepted during flooding is once every 430 MinLSArrival seconds, whose value is set to 1 (see Section 13, 431 Appendix B and G.5 of [OSPF]). 433 Proper operation of the OSPF protocol requires that all OSPF routers 434 maintain an identical copy of the OSPF link-state database. However, 435 when the size of the link-state database becomes very large, some 436 routers may be unable to keep the entire database due to resource 437 shortages; we term this "database overflow". When database overflow 438 is anticipated, the routers with limited resources can be 439 accommodated by configuring OSPF stub areas and NSSAs. [OVERFLOW] 440 details a way of gracefully handling unanticipated database 441 overflows. 443 In the case of type-11 Opaque LSAs, this document reuses an ASBR 444 tracking mechanism that is already employed in basic OSPF for type-5 445 LSAs. Therefore, applying it to type-11 Opaque LSAs does not create 446 any threats that are not already known for type-5 LSAs. 448 9. IANA Considerations 450 Opaque types are maintained by the IANA. Extensions to OSPF which 451 require a new Opaque type must be reviewed by the OSPF working group. 452 In the event that the OSPF working group has disbanded the review 453 shall be performed by a recommended Designated Expert. 455 Following the policies outlined in [IANA], Opaque type values in the 456 range of 0-127 are allocated through an IETF Consensus action and 457 Opaque type values in the range of 128-255 are reserved for private 458 and experimental use. 460 10. References 462 10.1. Normative References 464 [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 465 1793, April 1995. 467 [IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA 468 Considerations Section in RFCs", BCP 26, October 1998. 470 [MIB-UPDATE] Joyal, D., et. al., "OSPF Version 2 Management 471 Information Base", draft-ietf-ospf-mib-update-, May 472 2006. 474 [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 476 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 477 requirements levels", RFC 2119, March 1997. 479 10.2. Informative References 481 [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 482 1994. 484 [NSSA] Murphy P., "The OSPF Not-So-Stubby Area (NSSA) Option", 485 RFC 3101, January 2003. 487 [OSPF-MT] Psenak, P., et al., "Multi-Topology (MT) Routing in OSPF", 488 draft-ietf-ospf-mt-, February 2006. 490 [OSPFv3] Coltun, R., et al. "OSPF for IPv6", 491 draft-ietf-ospf-ospfv3-update-, November 2006. 493 [OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995. 495 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 496 July 1998. 498 [RFC4576] Rosen, E., et. al., "Using a Link State Advertisement 499 (LSA) Options Bit to Prevent Looping in BGP/MPLS IP 500 Virtual Private Networks (VPNs)", RFC 4576, June 2006. 502 11. Author's Addresses 504 Lou Berger 505 LabN Consulting, L.L.C. 506 Email: lberger@labn.net 508 Igor Bryskin 509 ADVA Optical Networking Inc 510 7926 Jones Branch Drive 511 Suite 615 512 McLean, VA - 22102 513 Email: ibryskin@advaoptical.com 515 Alex Zinin 516 Alcatel 517 Email: zinin@psg.com 519 Original Author: 520 Rob Coltun 521 Acoustra Productions 523 12. Appendix A: OSPF Data formats 525 This appendix describes the format of the Options Field followed by 526 the packet format of the Opaque LSA. 528 12.1. The Options Field 530 The OSPF Options field is present in OSPF Hello packets, Database 531 Description packets and all link-state advertisements. The Options 532 field enables OSPF routers to support (or not support) optional 533 capabilities, and to communicate their capability level to other OSPF 534 routers. Through this mechanism routers of differing capabilities can 535 be mixed within an OSPF routing domain. 537 When used in Hello packets, the Options field allows a router to 538 reject a neighbor because of a capability mismatch. Alternatively, 539 when capabilities are exchanged in Database Description packets a 540 router can choose not to forward certain link-state advertisements to 541 a neighbor because of its reduced functionality. Lastly, listing 542 capabilities in link-state advertisements allows routers to forward 543 traffic around reduced functionality routers by excluding them from 544 parts of the routing table calculation. 546 All eight bits of the OSPF Options field have been assigned, although 547 only the O-bit is described completely by this memo. Each bit is 548 described briefly below. Routers SHOULD reset (i.e., clear) 549 unrecognized bits in the Options field when sending Hello packets or 550 Database Description packets and when originating link-state 551 advertisements. Conversely, routers encountering unrecognized Option 552 bits in received Hello Packets, Database Description packets or link- 553 state advertisements SHOULD ignore the capability and process the 554 packet/advertisement normally. 556 +--------------------------------------+ 557 | DN | O | DC | EA | N/P | MC | E | MT | 558 +--------------------------------------+ 560 The Options Field 562 MT-bit 563 This bit describes the router's multi-topology link-excluding 564 capability, as described in [OSPF-MT]. 566 E-bit 567 This bit describes the way AS-external-LSAs are flooded, as 568 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF]. 570 MC-bit 571 This bit describes whether IP multicast datagrams are forwarded 572 according to the specifications in [MOSPF]. 574 N/P-bit 575 This bit describes the handling of Type-7 LSAs, as specified in 576 [NSSA]. 578 DC-bit 579 This bit describes the router's handling of demand circuits, as 580 specified in [DEMD]. 582 EA-bit 583 This bit describes the router's willingness to receive and 584 forward External-Attributes-LSAs. While defined, the 585 documents specifying this bit have all expired. The use 586 of this bit may be deprecated in the future. 588 O-bit 589 This bit describes the router's willingness to receive and 590 forward Opaque-LSAs as specified in this document. 592 DN-bit 593 This bit is used to prevent looping in BGP/MPLS IP VPNs, 594 as specified in [RFC4576]. 596 12.2. The Opaque LSA 598 Opaque LSAs are Type 9, 10 and 11 link-state advertisements. These 599 advertisements MAY be used directly by OSPF or indirectly by some 600 application wishing to distribute information throughout the OSPF 601 domain. The function of the Opaque LSA option is to provide for 602 future extensibility of OSPF. 604 Opaque LSAs contain some number of octets (of application-specific 605 data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA 606 uses the link-state database distribution mechanism for flooding this 607 information throughout the topology. However, the Opaque LSA has a 608 flooding scope associated with it so that the scope of flooding may 609 be link-local (type-9), area-local (type-10) or the entire OSPF 610 routing domain (type-11). Section 3 of this document describes the 611 flooding procedures for the Opaque LSA. 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | LS age | Options | 9, 10 or 11 | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Opaque Type | Opaque ID | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Advertising Router | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | LS Sequence Number | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | LS checksum | Length | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | | 627 + + 628 | Opaque Information | 629 + + 630 | ... | 632 Link-State Type 634 The link-state type of the Opaque LSA identifies the LSA's range of 635 topological distribution. This range is referred to as the Flooding 636 Scope. The following explains the flooding scope of each of the 637 link-state types. 639 o A value of 9 denotes a link-local scope. Opaque LSAs with a 640 link-local scope MUST NOT be flooded beyond the local 641 (sub)network. 643 o A value of 10 denotes an area-local scope. Opaque LSAs with a 644 area-local scope MUST NOT be flooded beyond the area that they 645 are originated into. 647 o A value of 11 denotes that the LSA is flooded throughout the 648 Autonomous System (e.g., has the same scope as type-5 LSAs). 649 Opaque LSAs with AS-wide scope MUST NOTE be flooded into stub 650 areas or NSSAs. 652 Syntax Of The Opaque LSA's Link-State ID 654 The link-state ID of the Opaque LSA is divided into an Opaque Type 655 field (the first 8 bits) and an Opaque ID (the remaining 24 bits). 656 See section 7 of this document for a description of Opaque type 657 allocation and assignment. 659 13. Full Copyright Statement 661 Copyright (C) The Internet Society (2006). This document is subject 662 to the rights, licenses and restrictions contained in BCP 78, and 663 except as set forth therein, the authors retain all their rights. 665 This document and the information contained herein are provided on an 666 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 667 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 668 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 669 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 670 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 671 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 673 14. Intellectual Property 675 The IETF takes no position regarding the validity or scope of any 676 Intellectual Property Rights or other rights that might be claimed to 677 pertain to the implementation or use of the technology described in 678 this document or the extent to which any license under such rights 679 might or might not be available; nor does it represent that it has 680 made any independent effort to identify any such rights. Information 681 on the procedures with respect to rights in RFC documents can be 682 found in BCP 78 and BCP 79. 684 Copies of IPR disclosures made to the IETF Secretariat and any 685 assurances of licenses to be made available, or the result of an 686 attempt made to obtain a general license or permission for the use of 687 such proprietary rights by implementers or users of this 688 specification can be obtained from the IETF on-line IPR repository at 689 http://www.ietf.org/ipr. 691 The IETF invites any interested party to bring to its attention any 692 copyrights, patents or patent applications, or other proprietary 693 rights that may cover technology that may be required to implement 694 this standard. Please address the information to the IETF at ietf- 695 ipr@ietf.org. 697 Generated on: Mon Dec 4 12:09:53 EST 2006