Advertising Generic Information in IS-IS
Extracted elements (21)
GENINFO MUST use a non-zero IS-IS protocol instance (RFC 6822) to decouple non-routing information flooding and processing from the information necessary for correct routing. This allows non-routing information to be independently prioritized and prevents it from degrading IS-IS routing operation.
The GENINFO encoding was designed to minimize consumption of IS-IS TLV codepoints (limited to 256 total) and maximize format flexibility. A single TLV codepoint (251) with a 16-bit Application ID field allows up to 65535 applications without additional top-level codepoint allocations.
Sub-TLVs (APPsub-TLVs) are used in GENINFO to allow backwards-compatible addition of new application information; implementations are required to ignore sub-TLVs they do not understand, consistent with the general IS-IS TLV handling model from RFC 5305. Sub-TLV codepoints are scoped to the combination of GENINFO TLV codepoint and Application ID, making them private to each application.
A router performing downward leaking MUST check for duplicate GENINFO TLVs by comparing contents, and the set of LSPs generated by a router for a given level MUST NOT contain two or more copies of the same GENINFO TLV.
A system MUST NOT use a GENINFO TLV present in an LSP of a system that is not currently reachable via Level-x paths (where x matches the LSP level). This prohibition applies to leaking as well, preventing propagation of stale GENINFO information.
Advertisement of GENINFO MUST occur in the context of a non-zero instance of the IS-IS protocol as defined in RFC 6822, except when use in the zero instance is defined in a Standards Track RFC.
Documents that specify the use of GENINFO MUST define the expected rate of change of the information to be advertised, in order to prevent flooding storms caused by insufficiently dampened updates.
If the S bit is set, the GENINFO 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.
Information advertised in the GENINFO TLV MUST NOT alter basic IS-IS protocol operation including (but not limited to) the establishment of adjacencies, the update process, and the decision process.
Nested APPsub-TLVs (additional sub-TLV levels within application-specific information) MUST be encoded with a one-octet Type field, a one-octet Length field, and zero or more octets of Value — the same encoding as regular sub-TLVs.
The public specification defining GENINFO use for an application MUST include: a description of the sub-TLV allocation policy, discussion of security issues, discussion of the rate of change of the advertised information, and justification for the use of GENINFO.
When a GENINFO TLV is leaked from Level-2 to Level-1, the D bit MUST be set; otherwise it MUST be clear. GENINFO TLVs with the D bit set MUST NOT be leaked from Level-1 to Level-2, preventing TLV looping.
When different flooding scopes are required for the same Application ID, a router MUST originate a minimum of one GENINFO TLV per required flooding scope. Area/level-scoped TLVs have S bit clear and MUST NOT be leaked; domain-scoped TLVs have S bit set and MUST be leaked.
Whenever possible, an implementation SHOULD advertise an update to a GENINFO TLV in the LSP with the same number as the advertisement it replaces. Where this is not possible, the two affected LSPs SHOULD be flooded as an atomic action.
Where a receiving system has two copies of a GENINFO TLV with the same Application ID, non-conflicting attribute information MUST be considered additive. The procedure for resolving conflicting information is explicitly left undefined.
The GENINFO TLV (Type 251) carries application-specific information not directly related to IS-IS protocol operation. It is valid only in LSPs, not in IIH or SNP PDUs, and not in purge PDUs.
IANA created a new 'IS-IS GENINFO Application Identifiers' registry. Identifiers are unsigned 16-bit numbers from 1 to 65535 (0 reserved). Registration procedure is Expert Review. Each entry must specify: ID value, description, whether allowed in Instance zero (Y/N), and reference specification.
IANA registered IS-IS TLV codepoint 251 (Generic Information) in the 'IS-IS TLV Codepoints' registry. This TLV is valid in LSPs only (not IIH, SNP, or Purge PDUs).
The GENINFO TLV codepoint itself introduces no new security issues for IS-IS. However, information advertised by specific applications MAY introduce new security issues, and each application's public specification MUST discuss those issues. Use of IS-IS cryptographic authentication per RFC 5304 or RFC 5310 is recommended where appropriate.
The Flags octet defines four bits: S (0x01) for domain-wide flooding scope, D (0x02) set when leaking Level-2 to Level-1, I (0x04) indicating a 4-octet IPv4 address follows the Application ID, and V (0x08) indicating a 16-octet IPv6 address follows. The upper 4 bits are reserved.
The GENINFO TLV value field begins with a 1-octet Flags field, followed by a 2-octet Application ID, optional 4-octet IPv4 address (if I bit set), optional 16-octet IPv6 address (if V bit set), and then additional application-specific information. Total length is 3 to 255 octets.