Summary
- RFC 5302 lets selected Level 2 reachability move into a Level 1 area by marking the advertisement as downward, but an older Level 1/Level 2 border can ignore that mark and advertise the prefix back into Level 2.
- Mixed-version safety is role-specific: an old Level 1-only receiver may accept the route without creating the decisive return path, while every border in an enabled area must understand and enforce the up/down rule.
The first green light answers the wrong question
Imagine a maintenance review in which a leaked prefix appears on an older Level 1 router. SPF completes, the route enters the RIB, the FIB programs, and a test packet takes the intended shorter path. The result looks like compatibility. It proves only that this receiver can consume the advertisement. It says nothing about whether another router with both Level 1 and Level 2 duties will later treat the same prefix as local Level 1 knowledge and send it upward.
The original two-level IS-IS model in RFC 1195 gave Level 1 routers a default route toward the nearest attached border for destinations beyond the area. It allowed Level 1 reachability to move into Level 2, but did not define the reverse flow. RFC 5302 adds selected Level 2-to-Level 1 distribution. The benefit is precision: an area can learn a better route than a default. The danger is a feedback path. Information that came down from Level 2 can be mistaken for a native Level 1 origin and re-enter Level 2.
That is why “the route was accepted” is weak evidence. Reception, selection, installation, advertisement and forwarding are different events. The control has to survive the entire circuit.
One bit carries a boundary, not a verdict
RFC 1195 defined TLV 128 for IP Internal Reachability Information and TLV 130 for IP External Reachability Information. In each, the high-order bit of the default Metric field was reserved: senders wrote zero and receivers ignored it. RFC 5302 assigns that position to the up/down bit.
When a Level 1/Level 2 router derives a prefix from Level 2 and advertises it in a Level 1 LSP, it sets the bit to one. For other prefixes in the two-level model, the bit remains zero. A border that learns a prefix through Level 1 with the bit set must not advertise that prefix into Level 2. The mark is therefore a compact statement of direction: this information crossed the hierarchy downward and may not cross back.
It is not an assurance that the route won SPF, entered a global RIB, reached the FIB or delivered a packet. Nor does authentication give it those meanings. A correctly authenticated LSP can be produced by a legitimate border whose software is too old to understand the repurposed bit. Cryptographic origin and distribution correctness are separate claims.
Compatibility ends at the border role
The elegant part of the design is also the trap in a superficial test. An RFC 1195-era receiver was already required to ignore the reserved bit. An older Level 1-only router can consequently accept a new down-marked prefix and treat it as ordinary intra-area reachability. RFC 5302 says this does not, by itself, create a routing loop among Level 1-only routers.
Move the same behavior to a Level 1/Level 2 router and the meaning changes. The router can erase the directional distinction simply by not recognizing it. Believing the route to be a normal Level 1 origin, it can advertise the prefix into Level 2. The return path is open. RFC 5302 names routing loops, suboptimal routing and additional instability as possible consequences.
The upgrade unit is therefore not “all routers” and not “the router that originates the leak.” It is every Level 1/Level 2 router in every area where downward distribution is enabled. A quiet standby border, a rarely used maintenance path or a device that never originates the selected prefix still belongs to the proof if it can participate in re-advertisement. Role, not apparent activity, defines exposure.
TLV and metric type are two axes
A second shortcut can hide inside a successful test: treating the TLV number as a complete route classification. TLV 128 and TLV 130 distinguish internal and external reachability information, while the metric field separately carries an internal or external metric type. An external metric type is valid only for an external prefix. A receiver must ignore the invalid combination of TLV 128 with an external metric type.
For IS-IS SPF preference, an internal prefix and an external prefix carrying an internal metric type have equal standing. An external prefix carrying an external metric type is less preferred than the same prefix with an internal metric, regardless of the numerical metric. Ordinary Level 1 routes precede Level 2 routes, which precede Level 2-to-Level 1 inter-area routes; external-metric classes follow. The verified correction in Errata 3994 matters here: an external inter-area route with external metric is derived during Level 2 SPF, not Level 1 SPF.
Compressing all of this to installed=true loses the facts needed to explain a later choice. A useful record retains the original level, source LSP, TLV, route type, metric type and value, up/down state, SPF source, RIB decision and FIB outcome.
Default-off is an authorization boundary
RFC 5302 recommends that Level 1/Level 2 routers not advertise Level 2 routes into Level 1 by default. The administrator should have to enable the behavior manually. That is more than cautious configuration. It creates a moment when authority can be bound to a precise scope: which areas, which prefixes, which policy generation, which borders, which filters or summaries, what observation period, and what rollback condition.
Enabling one border cannot stand as evidence for its peers. Before the change, the operator needs a complete border inventory and capability proof. During the change, multiple observation points should show the marked advertisement entering Level 1. After the change, every other border should show the prefix absent from prohibited Level 2 advertisements. The negative observation is central: no return is the property being purchased.
Nor should a border copy every prefix visible in the Level 1 database. RFC 5302 says a Level 1/Level 2 router should advertise into Level 2 only the Level 1 routes it actually uses for forwarding. Filtering and summarization remain policy decisions, not implementation trivia.
Later clarification prevents a false universal rule
The up/down bit does not mean “reject this route wherever it appears.” In the RFC 5302 two-level model it has no operational purpose in a Level 2 LSP; the document recommends ignoring it there and accepting the prefix. RFC 7775 later reinforces that there is no Level 2 inter-area route type in this model and corrects inconsistent IPv6 preference language inherited through RFC 5308.
That distinction protects the article from turning a Level 1 re-export prohibition into a universal packet filter. The evidence has to name the level in which the LSP was observed and the role of the receiving system. A bit without that context is not a policy conclusion.
The receipt must prove absence at every return path
A non-secret change receipt can join the prefix and address family to its original level, source system and LSP; the TLV; internal or external route type; metric type and value; the bit at ingress; approved downward policy and generation; every border’s software and capability status; the Level 1 advertisement; observations at every alternate border; explicit absence of upward re-advertisement; SPF source; RIB choice; FIB installation; forwarding result; and rollback decision.
This is a chain, not a dashboard total. received, accepted, selected, installed, advertised, suppressed, forwarded and delivered should remain separate states. A count of installed routes can be perfectly green while the forbidden advertisement has already escaped from a different border.
Sources
- https://www.rfc-editor.org/rfc/rfc5302.html
- https://www.rfc-editor.org/rfc/rfc5302.txt
- https://www.rfc-editor.org/info/rfc5302/
- https://datatracker.ietf.org/doc/rfc5302/
- https://datatracker.ietf.org/doc/rfc5302/history/
- https://datatracker.ietf.org/doc/rfc5302/references/
- https://datatracker.ietf.org/doc/rfc5302/referencedby/
- https://www.rfc-editor.org/errata/rfc5302
- https://www.rfc-editor.org/rfc/rfc1195.html
- https://www.rfc-editor.org/rfc/rfc2966.html
- https://www.rfc-editor.org/rfc/rfc5305.html
- https://www.rfc-editor.org/rfc/rfc5308.html
- https://www.rfc-editor.org/rfc/rfc7775.html
- https://www.rfc-editor.org/rfc/rfc5120.html
- https://www.rfc-editor.org/rfc/rfc3784.html
- https://www.rfc-editor.org/rfc/rfc5304.html
- https://www.rfc-editor.org/rfc/rfc5310.html
- https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
