RFC 2966 - Domain-wide Prefix Distribution with Two-Level IS-IS

Overview

Positive

what Ze has

Neutral

measures that are neither good news nor bad

The 8 shares marked as a part above are the whole of the 6 gated MUSTs: they add to 100%. Proven by a recorded break is a share of TAGGED UNITS, a different population, so it is not one of them.

At a glance

Enrolment

Enrolled: Domain-wide Prefix Distribution with Two-Level IS-IS (the RFC 2966 up/down bit): five MUST-level requirements after the 2026-09-21 extraction walk, which added RFC2966-3.2-1 (the six-level route preference order of Section 3.2) with no test and no annotation. The other four are over the pure inter-level leak producer LeakPrefixes/leakInto (internal/plugins/isis/spf/leak.go). RFC2966-2-1 (up/down bit set for L2->L1 prefixes, clear otherwise) both polarities via TestISISLeakOriginationL1L2: an L2-derived prefix leaks DOWN into L1 with up/down=true, an L1-native prefix leaks UP into L2 with up/down=false. RFC2966-2-2 (MUST NOT re-advertise up/down-set L1-learned prefixes back into L2) both polarities via TestISISLeakOriginationL1L2: a prefix already carrying the down bit is skipped (leakInto skips p.UpDown) while a clear-bit L1 prefix is still leaked. RFC2966-2-3 (L1L2 routers never advertise L2->L1 routes back into L2) both polarities via TestISISLeakFixpoint: a re-originated down-bit prefix is not leaked back up, while the same prefix without the down bit does leak down. RFC2966-x-1 (ignore internal-reachability-with-external-metric-type on receipt) is {not-applicable}: Ze does not decode the old narrow TLV 128/130 (only the wide TLV 135/236), so the internal/external-metric-type conflict never arises. No SHOULD/MAY requirements are gated. On 2026-09-30 the zero half of the §2 sender rule ("The bit must be set to zero for all other IP prefixes in L1 or L2 LSPs.") was given its own row, RFC2966-2-4, since the RFC2966-2-1 sentence states only the set-to-one half; it is proven on the decoded L2 LSPs of TestISISEngineLeakOrigination and TestRFC2966NarrowLeakUpDownBit, on the decoded L1 and L2 LSPs of TestRFC2966NativePrefixesGoOutWithBitZero (a connected and a redistributed prefix go out with the bit zero beside a down-leaked prefix that carries it) and, negatively, by TestISISLeakOriginationL1L2 (an L1 prefix already carrying the bit never reaches L2).

What the public ledger says

Status: Experimental

What the ledger says is covered:

What the ledger says remains:

Coverage

Positive and negative tests (6): RFC2966-2-1, RFC2966-2-2, RFC2966-2-3, RFC2966-2-4, RFC2966-3.2-1, RFC2966-x-1

Requirements

Gaps and untested MUSTs

RFC 2966 declares no gap, and every gated MUST it carries has a test bound to it.

Proof state

A tagged unit reads unproven where no discrimination record exists for it: nothing in this tree has been observed to break it, so the claim its tag makes is unproven.

RFC2966-2-1

L1L2 routers must set this bit to one for prefixes that are derived from L2 routing and are advertised into L1 LSPs. (Section 2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-09-30: TestISISEngineLeakOrigination, TestRFC2966NarrowLeakUpDownBit and spf TestISISLeakOriginationL1L2 gained only RFC2966-2-4 tag comments; bodies byte-identical. Positive: TestRFC2966NarrowLeakUpDownBit requires 0x80 on the default-metric octet of the L2->L1 internal (TLV 128) and external (TLV 130) narrow leaks in the originated L1 LSP, TestISISEngineLeakOrigination the TLV 135 bit, spf leakInto sets UpDown only for IntoL1. Negative: the L1-derived prefix leaked into L2 goes out with the bit clear on both encodings.

RFC2966-2-2

Prefixes with the up/down bit set that are learned via L1 routing, must never be advertised by L1L2 routers back into L2. (§2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-09-30: TestISISLeakOriginationL1L2 gained only RFC2966-2-4 tag comments; body byte-identical. Assertion 3 (hasPrefix(leak.IntoL2, alreadyDown) -> t.Errorf) goes red if leakInto stops skipping p.UpDown; assertion 1 keeps a clear-bit L1 prefix leaking up, so a blanket drop also goes red.

RFC2966-2-3

However, to prevent routing-loops, L1L2 routers must never advertise L2->L1 inter-area routes that they learn via L1 routing, back into L2. (§2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Forbidden behaviour: an L1L2 router advertising back into L2 an L2->L1 inter-area route it learned via L1. TestISISLeakFixpoint round 2 re-injects the leaked-down prefix as an L1 advertisement with UpDown set and fails on hasPrefix(r2.IntoL2, l2Derived); round 1 (negative) requires the same L2 prefix to leak down, so suppressing all leaking goes red too.

RFC2966-2-4

The bit must be set to zero for all other IP prefixes in L1 or L2 LSPs. (§2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-09-30 after the L1 half was added. Positive: TestRFC2966NativePrefixesGoOutWithBitZero runs a started engine, stores a connected prefix (ConnectedPrefixInfos) and a redistributed one (Consumer.InjectRoute) at both levels, down-leaks 10.2/24 into L1, then decodes TLV 135 from the stored L1 AND L2 LSPs: the down-leaked prefix carries the bit, the connected and redistributed prefixes carry it zero in both LSPs, so an originator setting the bit on every L1 entry or on own prefixes goes red (per-prefix, read from the wire). The L2 half stays on TestISISEngineLeakOrigination (TLV 135) and TestRFC2966NarrowLeakUpDownBit (TLV 128 bit 8). Negative: spf TestISISLeakOriginationL1L2 keeps the down-bit alreadyDown out of IntoL2 while the clear-bit L1 prefix leaks up with the bit false. Each cover holds an observed-red revert record (ConnectedPrefixInfos, narrowIPReachEntryBytes, leakedToPrefixInfos, leakInto).

RFC2966-3.2-1

Some types of routes must always preferred over others, regardless of the costs that were computed in the Dijkstra calculation. One of the reasons for this is that inter-area routes can only be advertised with a maximum metric of 63. Another reason is that this maximum value of 63 does not mean infinity (e.g. like a hop count of 16 in RIP denotes unreachable). Introducing a value for infinity cost in IS-IS inter-area routes would introduce counting- to-infinity behavior via two or more L1L2 routers, which would have a bad impact on network stability. The order of preference of IP routes in IS-IS is based on a few assumptions. - RFC 1195 defines that routes derived from L1 routing are preferred over routes derived from L2 routing. - The note in RFC 1195 paragraph 3.10.2, item 2c) defines that internal routes with internal metric-type and external prefixes with internal metric-type have the same preference. - RFC 1195 defines that external routes with internal metric-type are preferred over external routes with external metric type. - Routes derived from L2 routing are preferred over L2->L1 routes derived from L1 routing. Based on these assumptions, this document defines the following route preferences. 1) L1 intra-area routes with internal metric L1 external routes with internal metric 2) L2 intra-area routes with internal metric L2 external routes with internal metric L1->L2 inter-area routes with internal metric L1->L2 inter-area external routes with internal metric 3) L2->L1 inter-area routes with internal metric L2->L1 inter-area external routes with internal metric 4) L1 external routes with external metric 5) L2 external routes with external metric L1->L2 inter-area external routes with external metric 6) L2->L1 inter-area external routes with external metric (§3.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Forbidden: a less preferred class selected for a lower metric, or two members of one class ranked against each other. TestRFC2966EveryClassMemberOutranksNextClass drives every member of each class the fixture can express (L1 internal and external-with-internal-metric; L2 internal and external-with-internal-metric, which is also the L1->L2 inter-area member to the receiver; L2->L1 internal and external-with-internal-metric; L1 external-metric; L2 external-metric; L2->L1 external-metric) against every member of the next class, preferred one at cost 100/metric 60 against 1/1. TestRFC2966EqualClassMembersCompareByMetric requires the lower metric to win between two members of one class in both orders, so a member ranked apart from its class goes red. Recorded red on preferenceRank and better; the older adjacent-pair tests remain.

RFC2966-x-1

Upon receipt of an IP prefix with this combination, routers must ignore this prefix. (§3.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Forbidden behaviour: accepting an IP Internal Reachability (TLV 128) prefix whose metric-type bit says external. TestRFC2966InvalidInternalExternalMetricExcluded sets bit 0x40 on the TLV 128 entry of the cheaper route and requires metricWinner to pick the dearer valid route (id 2, 160); clearing the bit requires the cheap route back (id 3, 2), so both an accept-anyway and a drop-everything implementation go red.

Extraction sign-off

Sections

Excluded sentences

Superseded

No document obsoletes RFC 2966, so its obligations are stated where they were written.