IS-IS Registry Extension for Purges
updates
Extracted elements (15)
Extending the registry with a Purge column serves as an aid to subsequent documents (which can reference the registry as the definitive list) and to implementers (providing an easily accessible compendium), rather than scattering purge-TLV rules across multiple RFCs.
The purge status defined for a given TLV applies to all sub-TLVs defined for that TLV, simplifying the registry by avoiding per-sub-TLV entries.
This document updates RFC 5304 and RFC 5310 by generalizing their authentication acceptance rules: previously, purges were only accepted if they contained only the Authentication TLV; now acceptance is governed by the registry-based Purge column.
All TLVs not listed in the 'IS-IS TLV Codepoints' registry as permissible in purges MUST NOT appear in purges.
An implementation MUST NOT accept a purge that contains a TLV not listed in the registry unless the purge also contains the Purge Originator Identification (POI) TLV (RFC 6232).
An implementation that implements authentication MUST NOT accept a purge that contains any TLV listed in the registry that is not acceptable in a purge.
If an authentication-implementing IS accepts a purge without the POI TLV and inserts the POI TLV, it MUST also recompute authentication.
If multiple purges are received for the same LSP, the implementation MAY propagate any one of the purges.
ISs MUST NOT accept LSPs with a non-zero Remaining Lifetime that contain the POI TLV.
Purges that are accepted MUST be propagated without removal of TLVs.
When generating a purge, an implementation that implements authentication MUST first remove any TLVs not listed in the registry as acceptable in purges, then MUST add the POI TLV, then MAY add other registry-permitted TLVs, and finally adds authentication.
A purge is an LSP with a zero Remaining Lifetime used to cause IS-IS routers to discard stored link-state information. Per ISO 10589, purge generation originally retained only the LSP header, discarding all TLVs; subsequent extensions (RFC 5304, RFC 5310) allow certain TLVs to be included.
The Purge Originator Identification (POI) TLV (defined in RFC 6232) serves as the key authenticating element in purges and must be added during purge generation by authentication-capable implementations.
The 'IS-IS TLV Codepoints' registry (originally defined in RFC 3563) is extended with a new 'Purge' column. A 'y' indicates the TLV MAY appear in a purge; an 'n' indicates it MUST NOT. Initially, TLV type 10 (Authentication) and TLV type 137 (Dynamic hostname) are marked 'y'; all others are 'n'.
This document introduces no new security issues. The registry extension and authentication rule updates are procedural improvements that clarify existing behavior without expanding the attack surface.