Hi Mike,
The no-ext-capability keyword refers to handling one specific application of Opaque LSAs - in particular, the Router Information Opaque LSAs according to RFC 7770 (formerly RFC 4970).
These Router Information Opaque LSAs are optional extensions to OSPFv2, allowing router to advertise additional information about their capabilities (for example, support for Traffic Engineering, Stub Router, or Graceful Restart). Originally, OSPFv2 used the Options field in Hello packets and LSAs to advertise various capabilities, but since all these bits are already used up, RFC 7770 comes with an extensible way of advertising new capabilities using Opaque LSAs, and these LSAs are called, in short, the RI (Router Information) LSAs.
Depending on the nature of the capability, it can be advertised either as a link-scoped, area-scoped, or domain-local (also called AS-local) RI LSA - this naturally follows from the fact that Opaque LSAs have three flooding scopes: Type-9 Opaque LSAs are link-local, Type-10 Opaque LSAs are area-local, and Type-11 Opaque LSAs are AS-local.
With stubby and NSSA areas, ABRs do not inject external routes into these area types; that is why these areas have the "stubby" quality. However, since RI LSAs do not advertise topology or addressing information, it is not entirely clear whether it is okay for ABRs to flood received domain-local RI LSAs into stubby and NSSA areas. Flooding them certainly does not violate the stubby property of these areas, but may or may not be useful. This is what the no-ext-capability keyword does: If it is configured, domain-local RI LSAs will not be flooded into the respective area; without this keyword, despite the stubby area property, even domain-local RI LSAs will be flooded into stub or NSSA areas.
Please feel welcome to ask further!
Best regards,
Peter
