rfc-7794

IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability

L. Ginsberg (Editor), B. Decraene, S. Previdi, X. Xu, U. Chunduri
date2016-03 streamIETF areartg wgisis statusPROPOSED STANDARD pages9 canonicalhttps://www.rfc-editor.org/rfc/rfc7794 doi10.17487/RFC7794
This document introduces new sub-TLVs to support advertisement of IPv4 and IPv6 prefix attribute flags and the source router ID of the router that originated a prefix advertisement.

Extracted elements (22)

design-rationale §1

Current formats of Extended Reachability TLVs for IPv4 and IPv6 are fixed and do not allow introduction of additional flags without backwards compatibility issues. A new sub-TLV is defined rather than modifying the fixed format to allow extensible flag advertisement.

routing

design-rationale §2.2

The Router ID advertised in the Source Router ID sub-TLVs is always the Router ID of the IS-IS instance that originated the advertisement, even if the prefix was learned from another protocol (X-flag set). This ensures consistent identification of the IS-IS originator.

routing

design-rationale §2.2

The Source Router ID sub-TLVs are introduced because when a reachability advertisement is leaked from one level to another, the source of the original advertisement is otherwise unknown. This is especially useful when the advertisement identifies the advertising router (N-flag set).

routing

interoperability-note §2.1

The X-Flag in the Prefix Attribute Flags sub-TLV conflicts with an existing X flag in the fixed format of TLVs 236 and 237 (IPv6 extended reachability TLVs). To avoid ambiguity, the sub-TLV X-Flag SHOULD always be sent as 0 and MUST be ignored in those TLVs.

routing

normative-requirement §2.1 SHOULD

Additional bit definitions for the Prefix Attribute Flags sub-TLV that may be defined in the future SHOULD be assigned in ascending bit order so as to minimize the number of bits that will need to be transmitted.

routing, registry

normative-requirement §2.2 MUST

If present, the IPv4 or IPv6 Source Router ID sub-TLV MUST be included when the prefix advertisement is leaked to another level.

routing

normative-requirement §2.1 MUST

If the N-flag is set and the prefix length is NOT a host prefix (/32 for IPv4, /128 for IPv6), then the N-flag MUST be ignored. The N-flag MUST be preserved when leaked between levels.

routing

normative-requirement §2.1 MUST

The X-Flag in TLVs 236 and 237 SHOULD always be sent as 0 and MUST be ignored on receipt, because an existing X flag is already defined in the fixed format of those TLVs per RFC 5308 and RFC 5120.

routing, interoperability-note

normative-requirement §2.1 MUST

Undefined bits in the Prefix Attribute Flags sub-TLV MUST be transmitted as 0 and MUST be ignored on receipt. Bits that are NOT transmitted MUST be treated as if set to 0 on receipt.

routing

normative-requirement §2.2 MUST

When the IPv4 Source Router ID sub-TLV is included, its value MUST be identical to the value advertised in the Traffic Engineering router ID (TLV 134) defined in RFC 5305.

routing

normative-requirement §2.2 MUST

When the IPv6 Source Router ID sub-TLV is included, its value MUST be identical to the value advertised in the IPv6 TE Router ID (TLV 140) defined in RFC 6119.

routing

normative-requirement §2.3 SHOULD

Whenever an IPv4 or IPv6 Source Router ID sub-TLV is used, the originating router SHOULD also advertise the corresponding address-family-specific router ID TLV (TLV 134 for IPv4, TLV 140 for IPv6).

routing

protocol-element §2.1

The N-Flag (Node Flag, Bit 2) is set when the prefix identifies the advertising router itself, typically a host prefix (/32 for IPv4, /128 for IPv6) associated with a loopback address. The advertising router MAY choose not to set this flag even when conditions are met.

routing

protocol-element §2.1

The R-Flag (Re-advertisement Flag, Bit 1) is set when the prefix has been leaked from one IS-IS level to another, either upwards or downwards.

routing

protocol-element §2.1

The X-Flag (External Prefix Flag, Bit 0) is set when a prefix has been redistributed from another protocol, including redistribution from another IS-IS instance in a multi-virtual-router scenario. It MUST be preserved when leaked between levels.

routing

protocol-element §2

Three new sub-TLVs are introduced for IS-IS Extended Reachability TLVs 135, 235, 236, and 237: Prefix Attribute Flags (Type 4), IPv4 Source Router ID (Type 11), and IPv6 Source Router ID (Type 12).

routing

registry §3

A new registry 'Bit Values for Prefix Attribute Flags Sub-TLV' is created under the IS-IS TLV Codepoints registry with Expert Review registration policy. Initial values: Bit 0 (X-flag), Bit 1 (R-flag), Bit 2 (N-flag).

routing, registry

registry §3

Three new sub-TLV codepoints are added to the IS-IS TLV Codepoints registry for sub-TLVs of TLVs 135, 235, 236, and 237: Value 4 (Prefix Attribute Flags), Value 11 (IPv4 Source Router ID), Value 12 (IPv6 Source Router ID).

routing, registry

security-consideration §4

Security concerns for IS-IS are addressed in RFC 5304 and RFC 5310. Advertisement of the additional prefix attribute information defined in this document introduces no new security concerns.

routing, security

wire-format §2.2

IPv4 Source Router ID sub-TLV (Type 11): Length is 4 octets; Value is the IPv4 Router ID of the source of the advertisement, which MUST be identical to the value in TLV 134.

routing, ip

wire-format §2.2

IPv6 Source Router ID sub-TLV (Type 12): Length is 16 octets; Value is the IPv6 Router ID of the source of the advertisement, which MUST be identical to the value in TLV 140.

routing, ip

wire-format §2.1

Prefix Attribute Flags sub-TLV (Type 4): Length is variable (number of octets of the Value field); the Value field contains (Length * 8) bits starting with X-flag at Bit 0, R-flag at Bit 1, and N-flag at Bit 2.

routing