The OSPF Opaque LSA Option
obsoleted by
- rfc-5250 — The OSPF Opaque LSA Option
updated by
- rfc-3630 — Traffic Engineering (TE) Extensions to OSPF Version 2
Extracted elements (21)
The link-state ID is split into an 8-bit Opaque Type and a 24-bit Opaque ID rather than using the LSA type field alone. This allows multiple independent applications to share a single LSA type number while each having its own ID space within the type.
Three distinct flooding scopes (link-local, area-local, AS-wide) were defined to provide a generalized extensibility mechanism for OSPF. Applications can distribute information at the appropriate topological granularity without requiring new flooding procedures.
When opaque-capable and non-opaque-capable routers coexist, Opaque LSAs are not flooded to non-opaque-capable routers. This follows the general OSPF design principle that optional advertisements are only flooded to routers that understand them, enabling backward compatibility.
When flooding Link State Update packets as multicasts, a non-opaque-capable neighbor may inadvertently receive Opaque LSAs. The non-opaque-capable router will simply discard the LSA per Section 13 of RFC 2328 (receiving LSAs with unknown LS types), so this does not cause a protocol error.
A neighbor is considered opaque-capable if and only if it sets the O-bit in the Options field of its Database Description packets. The O-bit is not set in packets other than Database Description packets.
A receiver must always store a valid received Opaque LSA in its link-state database. The receiver must not accept Opaque LSAs that violate the flooding scope (e.g., a type-11 domain-wide Opaque LSA must not be accepted in a stub area).
A type-11 Opaque LSA must not be flooded out an interface associated with a stub area. A type-11 Opaque LSA received on a stub area interface must be discarded and not acknowledged, as the neighboring router has flooded it in error.
If a type-10 (area-local scope) Opaque LSA's associated area does not match the target interface's area, the Opaque LSA must not be flooded out that interface. An implementation should track the OSPF area associated with each area-local Opaque LSA.
If a type-9 (link-local scope) Opaque LSA is to be flooded, it must not be sent out any interface other than the one it was received on. An implementation should track the IP interface associated with each link-local Opaque LSA.
Opaque LSAs are only flooded to opaque-capable neighbors. Specifically, Opaque LSAs are only placed on the link-state retransmission lists of opaque-capable neighbors (per Section 13.3 of RFC 2328).
A global Opaque capability flag is added to the OSPF router data structure to indicate whether the router is running the Opaque option (capable of storing Opaque LSAs). An opaque-capable router continues to interoperate with non-opaque-capable OSPF routers.
Opaque LSAs are link-state advertisement types 9, 10, and 11. Type 9 has link-local flooding scope, type 10 has area-local flooding scope, and type 11 is flooded throughout the entire Autonomous System (equivalent to type-5 AS-external LSAs).
The OSPF neighbor structure is extended with a Neighbor Options field entry for Opaque capability, learned during the Database Exchange process via the neighbor's Database Description packets. This field determines whether Opaque LSAs are flooded to that neighbor.
IANA maintains the Opaque type registry. Opaque type values 0–127 are allocated through IETF Consensus; values 128–255 are reserved for private and experimental use. New Opaque types require review by the OSPF working group or a designated expert.
Database overflow risk is heightened by Opaque LSAs introducing new advertisement types. Routers with limited resources can be accommodated by configuring OSPF stub areas and NSSAs; RFC 1765 describes handling unanticipated database overflows.
Denial-of-service via repetitive LSA origination is mitigated by OSPF's MinLSInterval (5 seconds minimum between new instances of any particular LSA) and MinLSArrival (1 second minimum acceptance rate during flooding). These limits apply equally to Opaque LSAs.
OSPF's Cryptographic authentication option (using MD5 message digests with a shared secret key) provides protection against passive and active attacks on Opaque LSAs. However, it does not provide confidentiality or protection against traffic analysis.
The OSPF neighbor state machine is modified at the ExStart/NegotiationDone transition (moving to Exchange state). The Database summary list action is extended to include type-9 and type-10 Opaque LSAs from the area structure and type-11 Opaque LSAs from the global structure, with type-9 LSAs omitted if the neighbor's interface differs from the LSA's recorded interface, and type-11 LSAs omitted for virtual neighbors and stub areas.
The link-state ID of the Opaque LSA is divided into an Opaque Type field occupying the first 8 bits and a type-specific Opaque ID occupying the remaining 24 bits.
The O-bit is a newly defined bit in the OSPF Options field that indicates a router's willingness to receive and forward Opaque LSAs. The O-bit is set only in Database Description packets, not in Hello packets or LSAs.
The Opaque LSA packet format consists of a standard LSA header (LS age, Options, LS type 9/10/11, Advertising Router, LS Sequence Number, LS checksum, Length) followed by an 8-bit Opaque Type field and a 24-bit Opaque ID in the Link-State ID position, then variable-length Opaque Information padded to 32-bit alignment.