OSPFv3 Link State Advertisement (LSA) Extensibility
Extracted elements (28)
Extended LSA function codes were assigned as legacy codes plus 32 (0x20) rather than by allocating a new bit in the LS Type field. The bit-based approach would have consumed half the LSA function code space solely to migrate eight existing fixed-format LSAs.
The Attached-Routers TLV uses a compact flat list of Router IDs rather than individual per-neighbor TLVs to discourage using the E-Network-LSA for anything beyond advertising attached routers, and to reduce the likelihood that the single E-Network-LSA per multi-access link will exceed the IPv6 MTU and require fragmentation.
The N-bit is introduced as distinct from the LA-bit to allow explicit identification of a router's own address (a 'Node' address) versus a local interface address. The LA-bit could also be set on anycast addresses, making it insufficient for applications such as Segment Routing Node SID identification that require selection of a prefix uniquely associated with the advertising router.
The Referenced LS Type and Referenced Link State ID fields from the legacy AS-External-LSA were omitted from the External-Prefix TLV because they have never been used or even formally specified. If needed in the future, they can be added as a sub-TLV.
Full migration from Legacy to Extended LSAs can be performed non-disruptively by running separate OSPFv3 instances—initially assigning the Extended-LSA instance a lower preference (higher administrative distance) than the Legacy instance, then reversing preference once the RIB is verified.
Sparse-mode backward compatibility allows Extended LSAs to be introduced into an existing routing domain without a full migration: Legacy LSAs are still used for SPF computation, and Extended LSAs are originated only when needed for new functionality, containing only the top-level TLVs required for that function.
The IPv6-Forwarding-Address sub-TLV (type 1) MUST be ignored for non-IPv6 address families, and the IPv4-Forwarding-Address sub-TLV (type 2) MUST be ignored for non-IPv4 address families. In both cases, only the first occurrence is used; subsequent instances MUST be ignored.
A single instance of the IPv6 Link-Local Address TLV SHOULD be included in the E-Link-LSA; instances after the first MUST be ignored. If the Link-Local Address TLV corresponding to the active address family is absent from the E-Link-LSA, the LSA is treated as malformed.
All OSPFv3 implementations supporting Extended LSAs MUST ignore unrecognized TLVs and sub-TLVs when parsing Extended LSAs. A TLV or sub-TLV whose length is below the defined minimum SHOULD NOT be acknowledged and SHOULD be logged with LSA type, Link State ID, originator, sequence number, and TLV identification.
Documents defining future TLVs or sub-TLVs for Extended LSAs MUST specify whether partial deployment is supported, and MUST provide backward-compatibility and deployment procedures accordingly. All future TLVs or sub-TLVs must be optional at the top level.
Each E-Inter-Area-Prefix-LSA MUST contain exactly one Inter-Area-Prefix TLV (type 3); duplicate instances MUST be ignored. Absence of the required TLV renders the LSA malformed.
Each E-Inter-Area-Router-LSA MUST contain exactly one Inter-Area-Router TLV; each E-AS-External-LSA MUST contain exactly one External-Prefix TLV. Instances subsequent to the first MUST be ignored, and absence of the required TLV renders the LSA malformed.
If the N-bit is set in PrefixOptions but the PrefixLength is not 128 (IPv6) or 32 (IPv4), the N-bit MUST be ignored.
Malformed Extended LSAs (inconsistent length, encoding errors, or missing required TLVs) MUST NOT be installed in the Link State Database, acknowledged, or flooded. Malformed LSA reception SHOULD be counted and/or logged.
The E-Network-LSA MUST include an Attached-Routers TLV; its absence renders the LSA malformed. Instances of the Attached-Routers TLV after the first MUST be ignored.
The U-bit MUST be set in the LS Type of all OSPFv3 Extended LSAs so that routers that do not understand them will still flood them throughout the OSPFv3 domain.
TLVs and sub-TLVs that appear in the wrong LSA type MUST be ignored. For example, a Router-Link TLV in an E-Network-LSA must be silently ignored; an Attached-Routers TLV in an E-Router-LSA must be silently ignored.
Nine new OSPFv3 Extended LSA types are defined with LS function codes 33–41 (skipping 38): E-Router-LSA (0xA021), E-Network-LSA (0xA022), E-Inter-Area-Prefix-LSA (0xA023), E-Inter-Area-Router-LSA (0xA024), E-AS-External-LSA (0xC025), E-Type-7-LSA (0xA027), E-Link-LSA (0x8028), and E-Intra-Area-Prefix-LSA (0xA029). These correspond to the eight original fixed-format LSAs with function code incremented by 32 (0x20).
The E-Intra-Area-Prefix-LSA (0xA029) includes a fixed header with two reserved octets, a 2-octet Referenced LS Type, a 4-octet Referenced Link State ID, and a 4-octet Referenced Advertising Router before the TLV body. The Referenced LS Type MUST be either E-Router-LSA (0xA021) or E-Network-LSA (0xA022).
The N-bit (value 0x20) is a new prefix option defined at bit position 5 of the PrefixOptions field. It identifies a host address (PrefixLength=128 for IPv6, 32 for IPv4) that is the router's own address, distinguishing it from anycast addresses that might also have the LA-bit set. It is propagated by ABRs in Inter-Area-Prefix-LSAs and by NSSA ABRs in E-AS-External-LSAs.
The N-bit is allocated in the OSPFv3 Prefix-Options registry with value 0x20 (bit position 5). This document also assigns nine new entries to the existing OSPFv3 LSA Function Codes registry for the Extended LSA types.
The 'OSPFv3 Extended LSA Sub-TLVs' registry is created within the existing OSPFv3 IANA registry. Values 0–3 are assigned (Reserved, IPv6-Forwarding-Address, IPv4-Forwarding-Address, Route-Tag). Range 4–32767: IETF Review/IESG Approval; 32768–33023: Experimental; 33024–45055: FCFS; 45056–65535: unassigned.
The 'OSPFv3 Extended LSA TLVs' registry is created within the existing OSPFv3 IANA registry. Values 0–8 are assigned (Reserved, Router-Link, Attached-Routers, Inter-Area-Prefix, Inter-Area-Router, External-Prefix, Intra-Area-Prefix, IPv6 Link-Local Address, IPv4 Link-Local Address). Range 9–32767: IETF Review/IESG Approval; 32768–33023: Experimental (MUST NOT appear in RFCs); 33024–45055: FCFS; 45056–65535: unassigned pending IETF specification.
Extensible OSPFv3 LSAs are subject to the same security concerns as RFC 5340. Implementations MUST assure that malformed TLV and sub-TLV permutations do not cause hard OSPFv3 failures (e.g., crashes or protocol restarts).
Each TLV in the Extended LSA body encodes a 2-octet Type, a 2-octet Length (value portion only, excluding padding), and a variable-length Value field. TLVs and nested sub-TLVs are padded to 4-octet alignment; padding bytes are not counted in the Length field.
The Attached-Routers TLV (type 2) encodes adjacent neighbor Router IDs as a compact list of 4-octet entries with no per-neighbor wrapper. It is applicable only within E-Network-LSAs.
The External-Prefix TLV (type 5) encodes a single OSPFv3 external prefix with an E-bit, 3-octet Metric, 1-octet PrefixLength, 1-octet PrefixOptions, and variable-length Address Prefix, followed by optional sub-TLVs. The IPv6/IPv4 Forwarding Address and External Route Tag are moved to sub-TLVs (types 1, 2, 3); the unused Referenced LS Type and Referenced Link State ID from the original AS-External-LSA are omitted entirely.
The Router-Link TLV (type 1) encodes a single OSPFv3 router link with fields: 1-octet Type, 1 reserved octet, 2-octet Metric, 4-octet Interface ID, 4-octet Neighbor Interface ID, 4-octet Neighbor Router ID, followed by optional sub-TLVs. It is applicable only within E-Router-LSAs.