IS-IS Extensions for Advertising Router Information
obsoletes
- rfc-4971 — Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information
Extracted elements (21)
RFC 4971 only allowed a 32-bit IPv4 Router ID in TLV 242's fixed header, which is unworkable in IPv6-only deployments. RFC 7981 resolves this by allowing 0.0.0.0 as a placeholder when IPv4 is unavailable, paired with a mandatory IPv6 TE Router ID sub-TLV.
The D bit mechanism (set on L2-to-L1 leaking, block L1-to-L2 re-leaking) is the chosen approach to prevent looping of domain-scoped capability TLVs, consistent with the general IS-IS down-bit pattern used for other inter-level information.
The IS-IS Router CAPABILITY TLV is intentionally a generic mechanism: it does not define specific capabilities itself but provides a container for application-specific sub-TLVs. This allows independent extension without modifying the base TLV structure.
The stale-TLV prohibition (MUST NOT use TLV from unreachable originator) prevents routers in remote areas from acting on outdated capability information when an area partitions, since there is no reliable way to choose between conflicting copies from different L1/L2 border routers.
Routers not supporting the IS-IS Router CAPABILITY TLV must silently ignore it. Partial support of sub-TLVs is permitted; unsupported sub-TLVs are ignored while supported ones are processed. The impact of partial support on advertised capabilities is outside the scope of this document.
A system MUST NOT use an IS-IS Router CAPABILITY TLV present in an LSP of a system that is not currently reachable via Level x paths, where x is the level in which the sending system advertised the TLV. This prevents use of stale capability information.
For IS-IS Router CAPABILITY TLVs with domain-wide scope originated by L1 routers to be flooded across the entire domain, at least one L1/L2 router in every area of the domain MUST support the Router CAPABILITY TLV.
If leaking of the IS-IS Router CAPABILITY TLV is required, the entire CAPABILITY TLV MUST be leaked into another level without change, except for changes to TLV flags as defined in Section 2, even if it contains sub-TLVs unsupported by the leaking router.
If the originating node does not support IPv4, the reserved value 0.0.0.0 MUST be used in the Router ID field, and the IPv6 TE Router ID sub-TLV (RFC 5316) MUST be present. TLVs with Router ID 0.0.0.0 lacking the IPv6 sub-TLV MUST NOT be used.
If the S bit is set, the IS-IS Router CAPABILITY TLV MUST be flooded across the entire routing domain. If the S bit is not set, the TLV MUST NOT be leaked between levels. The S bit MUST NOT be altered during TLV leaking.
Routers that do not support the IS-IS Router CAPABILITY TLV MUST silently ignore the TLV(s) and continue processing other TLVs in the same LSP. Routers that do not support specific sub-TLVs MUST silently ignore the unsupported sub-TLVs.
The Router ID SHOULD be identical to the Traffic Engineering Router ID TLV value (RFC 5305) if available; otherwise it SHOULD match an IP Interface Address advertised by the originating IS.
When advertising capabilities with different flooding scopes, a router MUST originate a minimum of two IS-IS Router CAPABILITY TLVs — one per scope — each carrying only the sub-TLVs applicable to that scope.
When the IS-IS Router CAPABILITY TLV is leaked from Level 2 to Level 1, the D bit MUST be set. IS-IS Router CAPABILITY TLVs with the D bit set MUST NOT be leaked from Level 1 to Level 2, preventing TLV looping.
Wherever possible, an implementation SHOULD advertise updates to an IS-IS Router CAPABILITY TLV in the same LSP fragment as the advertisement it replaces. Where not possible, the two affected LSP fragments should be flooded as an atomic action.
The D bit (0x02) in the Flags field is a down-bit for loop prevention. It MUST be set when the TLV is leaked from Level 2 to Level 1, and TLVs with D bit set MUST NOT be leaked from Level 1 to Level 2.
The IS-IS Router CAPABILITY TLV (Type 242) carries a 4-octet Router ID, a 1-octet Flags field, and an optional set of sub-TLVs (0–250 octets). The total value field length ranges from 5 to 255 octets. Sub-TLVs are formatted per RFC 5305.
The S bit (0x01) in the Flags field controls flooding scope: set means the TLV MUST be flooded across the entire routing domain; clear means the TLV MUST NOT be leaked between IS-IS levels. This bit MUST NOT be altered during leaking.
IANA originally assigned TLV codepoint 242 for the IS-IS Router CAPABILITY TLV under RFC 4971. RFC 7981 updates the entry in the 'TLV Codepoints Registry' to reference this document.
LSPs carrying the Router CAPABILITY TLV may be snooped or modified by an attacker, exposing router capability information. Specifications using this mechanism must describe their own security considerations, and an integrity mechanism such as RFC 5304 or RFC 5310 should be applied when capability modification poses high risk.
TLV 242 value field: Router ID (4 octets) identifying the source, Flags (1 octet) with S bit (0x01) and D bit (0x02) defined, followed by 0–250 octets of optional sub-TLVs. Total value length 5–255 octets.