The OSPF Opaque LSA Option
obsoletes
- rfc-2370 — The OSPF Opaque LSA Option
Extracted elements (21)
Type-11 Opaque LSA originators are required to advertise themselves as ASBRs because remote-area OSPF routers have no other mechanism to detect that a type-11 LSA originator has gone out of service; without this, stale information could persist for up to 60 minutes. This reuses the same ASBR tracking already used for type-5 AS External LSAs.
Type-9 and type-10 Opaque LSAs do not require the ASBR tracking mechanism because local reachability can be determined directly: type-9 originators must be OSPF neighbors in Exchange state or greater, and type-10 originator reachability is determined by the intra-area SPF calculation.
When opaque-capable and non-opaque-capable routers are mixed in a routing domain, Opaque LSAs are typically not flooded to non-opaque-capable routers. Non-opaque-capable routers receiving Opaque LSAs via multicast will simply discard the LSA per base OSPF processing of unknown LS types. OSPF routers implementing RFC 2370 will continue using stale type-11 LSAs even when the originator implements the new inter-area procedures.
A neighbor is opaque-capable if and only if it sets the O-bit in the Options field of its Database Description packets. The O-bit SHOULD NOT be set and MUST be ignored when received in packets other than Database Description packets, to avoid interoperability issues.
An OSPF router configured to originate AS-scope (type-11) Opaque LSAs MUST advertise itself as an ASBR and MUST follow requirements for setting the Options field E-bit in OSPF LSA headers, enabling routers in remote areas to track LSA originator reachability via type-4 Summary LSAs.
For type-10 (area-local) Opaque LSAs, if the area associated with the LSA differs from the area of the target interface, the LSA MUST be discarded and not acknowledged. An implementation SHOULD keep track of the OSPF area associated with each area-local Opaque LSA.
For type-11 (AS-scope) Opaque LSAs, the LSA MUST NOT be flooded out an interface associated with a stub area or NSSA. A type-11 Opaque LSA received on such an interface MUST be discarded and not acknowledged.
Information contained in received Opaque LSAs SHOULD only be used when the router originating the LSA is reachable. Reachability validation MAY be done less frequently than every SPF calculation. Routers MAY give priority to processing base OSPF LSA types over Opaque LSA types.
Opaque LSAs MUST be placed on the link-state retransmission lists of opaque-capable neighbors and MUST NOT be placed on the retransmission lists of non-opaque-capable neighbors. When sending Link State Update packets as multicasts, a non-opaque-capable neighbor may inadvertently receive Opaque LSAs but will discard them.
The flooding of Opaque LSAs MUST follow the rules of flooding scope. For type-9 LSAs, if the receiving interface differs from the target interface, the LSA MUST be discarded and not acknowledged. An implementation SHOULD keep track of the IP interface associated with each link-local Opaque LSA.
The receiver MUST always store a valid received Opaque LSA in its link-state database, and MUST NOT accept Opaque LSAs that violate the flooding scope (e.g., a type-11 Opaque LSA is not accepted in a stub area or NSSA).
When processing a received type-11 Opaque LSA, the router MUST look up routing table entries for the ASBR that originated the LSA. If no entries exist (ASBR unreachable), the router MUST do nothing with this LSA and MUST discontinue using all Opaque LSAs from the same originator whenever that originator is detected as unreachable.
An Opaque capability flag is added to the global OSPF router data structure indicating whether the router is running the Opaque option (capable of storing Opaque LSAs). An Opaque capability flag is also added to the OSPF neighbor structure, learned during Database Exchange by examining the O-bit in the neighbor's Database Description packets.
Opaque LSAs are types 9, 10, and 11 link state advertisements. Type-9 has link-local scope, type-10 has area-local scope, and type-11 is flooded throughout the AS with the same scope as AS-External (type-5) LSAs. Type-11 LSAs are not flooded into stub areas or NSSAs.
The link-state ID of the Opaque LSA is divided into an Opaque Type field (the first 8 bits) and a type-specific Opaque ID (the remaining 24 bits). The Opaque Type identifies the application using the Opaque LSA mechanism.
The OSPF Opaque Link-State Advertisements (LSA) Option Types registry is updated: values 0-127 require IETF Consensus, values 128-255 are reserved for Private Use. Assigned values include: 1 (Traffic Engineering LSA, RFC 3630), 2 (Sycamore Optical Topology Descriptions), 3 (grace-LSA, RFC 3623), 4 (Router Information RI, RFC 4970), 5-127 unassigned.
OSPF authentication, including the Cryptographic authentication option using MD5 message digests with a shared secret key, protects against passive and active attacks on routing protocol information. However, none of the standard authentication types provide confidentiality or protection against traffic analysis.
Repetitive LSA origination (denial-of-service) is mitigated by OSPF's MinLSInterval (5 seconds minimum between new instances of a given LSA) and MinLSArrival (1 second minimum acceptance rate during flooding). Database overflow is addressed by configuring stub areas and NSSAs, or via the graceful overflow mechanism of RFC 1765.
The OSPF neighbor state machine is modified at State ExStart, Event NegotiationDone → New State Exchange. The action is extended to include type-9 and type-10 Opaque LSAs in the area Database summary list, and type-11 Opaque LSAs in the global structure. Type-11 and AS External LSAs MUST be omitted for virtual neighbors and for stub areas or NSSAs. Type-9 LSAs MUST be omitted if the neighbor interface does not match the LSA's associated interface.
The Opaque LSA header contains: LS age (16 bits), Options (8 bits), LS type 9/10/11 (8 bits), Opaque Type (8 bits), Opaque ID (24 bits), Advertising Router (32 bits), LS Sequence Number (32 bits), LS checksum (16 bits), Length (16 bits), followed by variable-length Opaque Information padded to 32-bit alignment.
The OSPF Options field is an 8-bit field present in Hello packets, Database Description packets, and all LSAs. The O-bit indicates the router's willingness to receive and forward Opaque LSAs. The full layout is: DN | O | DC | EA | N/P | MC | E | MT.