Summary

  • RFC 2370 reused OSPF's link-state machinery to carry application-specific information in Type 9, 10 and 11 Opaque LSAs, with link-local, area-local and AS-wide flooding scopes.
  • An O-bit, retransmission acknowledgement and LSDB entry could prove capability and carriage, but not that an application understood the payload, accepted its freshness, computed a path, installed forwarding state or moved traffic successfully.

In a link-state protocol, every advertisement usually arrives with an obvious reason to exist. A router LSA describes a router's links. A network LSA describes a shared network. Summary and external advertisements feed a known routing calculation. RFC 2370 introduced a more disciplined ambiguity: OSPF would distribute a record whose body belonged to some other application.

The word “opaque” did not mean encrypted or secret. It meant that the common carrier did not own the body's semantics. The LSA still had a standard age, options field, type, identifier, advertising router, sequence number, checksum and length. Behind that familiar header sat 32-bit-aligned application-specific information. OSPF could move and synchronize the object without pretending that the 1998 document had specified every future use.

That was the extension mechanism's constitutional choice. The common layer supplied a narrow service: identity, scope, flooding, acknowledgement, ageing and database storage. A separately specified application supplied meaning. Running software still had to connect the two.

Three numbers drew three different boundaries

RFC 2370 assigned LSA types 9, 10 and 11 to the Opaque family. Their difference was not the content's importance. It was how far OSPF was permitted to distribute it.

A Type 9 Opaque LSA was link-local. It could travel only on its associated local network. An implementation needed to remember the interface to which the record belonged and keep it from leaking through another interface. Type 10 was area-local. The receiving or originating area became part of the record's handling, and the LSA could not cross that area's border. Type 11 was AS-scoped, following the broad pattern of an AS-external LSA while remaining outside stub areas.

Scope was therefore executable metadata. A correct Type 10 checksum did not authorize an area border router to export the record. A valid Type 11 arriving inside a stub area was not merely irrelevant; it violated the distribution contract and had to be rejected. The sender and receiver both carried responsibility for keeping the envelope inside its declared topological boundary.

The 32-bit Link State ID added another division. Its first eight bits were the Opaque Type, an application namespace. The remaining 24 bits formed a type-specific identifier. This named what kind of extension was being carried and distinguished its instances. It did not certify the payload's factual truth, confer authority on the originator or tell a consumer what operational action to take.

Capability was willingness to carry, not mastery of every payload

Mixed deployments were a first-order concern. An opaque-capable router announced an O-bit in Database Description packets during the database-exchange process. Its neighbour used that signal when building the database summary and retransmission lists. Opaque LSAs went onto the retransmission lists of capable neighbours, not incapable ones. A multicast update might still be overheard by a router that did not understand the LS type; that router discarded it.

The O-bit answered a bounded question: is this neighbour willing to receive and forward the Opaque LSA machinery? It did not enumerate every Opaque Type or prove that a local application existed for each payload. A router could participate in carrying an extension while having no business logic that consumed it. Conversely, an application could be installed but receive an incomplete view because an intervening capability boundary stopped part of the distribution.

This is why database synchronization and application convergence must be audited separately. At the protocol layer, a valid in-scope LSA was stored in the LSDB and acknowledged through normal flooding. At the application layer, software had to select the relevant Opaque Type, parse its body, validate the originator and freshness rules that mattered to that application, reconcile it with other state and decide whether to act.

An LSDB row was evidence that OSPF accepted a protocol object. It was not a receipt from the application.

Sequence, age and checksum did not make the claim current

Opaque LSAs inherited OSPF's lifecycle. Sequence numbers distinguished newer instances. Checksums detected covered corruption. LS age and MaxAge supported expiry and flushing. MinLSInterval and MinLSArrival limited rapid replacement. Retransmission lists and acknowledgements closed the adjacency-level delivery loop.

Each mechanism answered a real question, but none answered all of them. A checksum could validate bytes without validating semantics. A newer sequence could replace an older instance without proving that the originating application's input was fresh. An acknowledgement could prove neighbour receipt without proving application use. An LSA could remain in a remote database after the originator had become unreachable.

That last gap mattered especially for Type 11. RFC 5250 replaced RFC 2370 in 2008 partly because routers outside the originator's area could keep AS-scoped Opaque information for as long as an hour after the originator disappeared. The replacement required an AS-scoped originator to make itself reachable as an AS boundary router and required consumers to stop using its Opaque LSAs when that reachability vanished.

The repair is historically revealing. The original carrier could perform its documented ageing and flooding duties while an application still acted on stale information. More distribution did not automatically create more truth. Reachability of the claimant had to become an explicit input to use.

Traffic engineering showed what “opaque” bought—and what it did not

RFC 3630 later used area-scoped Type 10 Opaque LSAs for traffic-engineering attributes. A router could advertise bandwidth and administrative constraints; receiving devices could build a traffic-engineering database. Non-TE-capable nodes could still flood those LSAs as Opaque objects, allowing the carrier to cross routers that did not consume the semantics.

That reuse was the design's payoff. OSPF did not need a new flooding protocol for each application. The later specification could define its own TLVs inside the common envelope and choose an appropriate scope.

It also exposed the evidence boundary. RFC 3630 said a changed TE LSA updated the TE database but required no normal SPF calculation. It left path instantiation outside its mechanism and warned that partial participation could leave holes in the TE topology. A device might possess a synchronized Opaque record and still lack a complete application view. A computed path might never be installed. Installed state might never carry the intended traffic.

RFC 7684 later used Opaque LSAs for extended prefix and link attributes. The current IANA OSPFv2 registries preserve Type 9, 10 and 11 and the later extension namespaces. Those records prove that identifiers were assigned and maintained. They do not prove that a named network enabled, interpreted or benefited from them.

Authentication protected an exchange, not the whole claim

RFC 2370 carried OSPF's security concerns into the new channel. Authentication could protect protocol exchanges against classes of forgery, while origination limits reduced repetitive-update pressure. The document also recognized database-overflow risk from many distinct advertisements. RFC 5709 later strengthened OSPFv2 cryptographic authentication with HMAC-SHA algorithms.

Even authenticated carriage left several authorities distinct. The credential established which OSPF peer produced an authenticated packet under a configured key. The LSA header identified an advertising router and instance. The application still had to decide whether that router was entitled to make the particular claim, whether the claim matched other evidence, whether it was recent enough and whether policy allowed the resulting action.

This separation follows the narrow common-layer logic in Heng Lu's Running-Code Primacy and Minimum Initial Specification. The shared protocol should define only what participants must agree on to interoperate. Later applications can be specified, implemented, refused or adopted without turning the carrier into a universal policy engine. Publication makes an extension available; running code, compatible deployment and observed result make it operational.

RFC 2370 therefore matters beyond OSPF history. It showed how a mature protocol could carry future information without claiming future knowledge. The envelope could arrive. The database could agree. The application still had to believe for stated reasons, and the network still had to prove what happened next.

Sources