IS-IS Route Preference for Extended IP and IPv6 Reachability
updates
- rfc-5308 — Routing IPv6 with IS-IS
Extracted elements (16)
RFC 5302 allowed the up/down bit to appear in L2 LSPs in anticipation of a future IS-IS extension supporting more than two levels. Since no such extension has been introduced and two levels remain the maximum, the bit is meaningless in L2 LSPs within a single IS-IS instance.
RFC 5305 introduced the up/down bit being set to 1 in L2 LSPs specifically to handle redistribution between multiple virtual IS-IS instances in different areas at the same level, a scenario not envisioned by RFC 5302.
RFC 5308 Section 5 erroneously introduced a 'Level 2 down prefix' route type and associated preference rule. No such route type is defined by RFC 5302, and this document corrects RFC 5308 to eliminate that route type, aligning IPv6 behavior with IPv4.
Appendix A documents a real-world routing loop caused by different vendors interpreting the up/down bit in Level 2 LSPs inconsistently: one vendor preferring routes without the up/down bit set (higher preference), another ignoring the bit and selecting by metric, resulting in a forwarding loop between R1 and R2.
Changing the use of the up/down bit in TLVs 236 and 237 (to correct RFC 5308) may introduce interoperability issues with existing implementations. Implementors may wish to support transition mechanisms from the RFC 5308 behavior to the behavior described in this document.
TLVs 135 and 235 do not support distinction between internal and external metrics (unlike TLVs 128 and 130). The Prefix Attribute Flags sub-TLV (from draft-ietf-isis-prefix-attributes) reintroduces internal/external route type distinction via X-Flag and R-Flag bits.
If a prefix is advertised from one area to another at the same level (e.g., L1-to-L1 or L2-to-L2 via multiple IS-IS instances), the up/down bit SHALL be set to 1, as specified in RFC 5305 Section 4.1.
It is RECOMMENDED that implementations ignore the up/down bit in L2 LSPs and accept the prefixes in L2 LSPs regardless of whether the up/down bit is set, as carried forward from RFC 5302 Section 3.3.
Routes that are leaked downwards (up/down bit set to 1) MUST NOT be leaked upwards in the IS-IS level hierarchy.
For TLVs 135 and 235 (IPv4), eight route types are defined: L1 intra-area (up/down=0, X-Flag=0, R-Flag=0), L1 external (up/down=0, X-Flag=1), L2 intra-area (up/down=0, X-Flag=0, R-Flag=0), L1->L2 inter-area (up/down=0, R-Flag=1), L2->L2 inter-area (up/down=1 ignored, X-Flag=1), L2 external (up/down=0, X-Flag=1), L2->L1 inter-area (up/down=1, R-Flag=1), and L1->L1 inter-area (up/down=1, X-Flag=1).
For TLVs 236 and 237 (IPv6), ten route types are defined, adding an 'external bit' field not present in IPv4 TLVs. L1->L2 external routes (up/down=0, external=1, R-Flag=1) and L2->L1 external routes (up/down=1, external=1, R-Flag=1) are additional types specific to IPv6.
L2->L2 inter-area routes for IPv4 (TLVs 135/235) have the up/down bit set to 1 but it is ignored and treated as if set to 0; these prefixes are learned from another IS-IS instance typically in another area, with X-Flag=1 and R-Flag=0 when the Prefix Attribute Flags sub-TLV is present.
L2->L2 inter-area routes for IPv6 (TLVs 236/237) have up/down=1 (ignored, treated as 0) and external bit=1; these are learned from another IS-IS instance in another area, with R-Flag=0. This corrects the RFC 5308 specification.
Route preference order for IPv4 (TLVs 135/235): (1) L1 intra-area and L1 external; (2) L2 intra-area, L2 external, L1->L2 inter-area, L2->L2 inter-area; (3) L2->L1 inter-area and L1->L1 inter-area. All types within the same preference level are treated equally.
Route preference order for IPv6 (TLVs 236/237): (1) L1 intra-area and L1 external; (2) L2 intra-area, L2 external, L1->L2 inter-area, L1->L2 external, L2->L2 inter-area; (3) L2->L1 inter-area, L2->L1 external, L1->L1 inter-area. This differs from RFC 5308 by eliminating the 'Level 2 down prefix' preference category.
This document raises no new security considerations. Security considerations for IS-IS are covered in ISO 10589, RFC 5304 (IS-IS Cryptographic Authentication), and RFC 5310 (IS-IS Generic Cryptographic Authentication).