Summary

  • Classic point-to-point IS-IS could treat a heard Hello as reachability even when the neighbor could not hear the return direction. RFC 5303 added Down, Initializing and Up three-way states so reciprocal IIH visibility becomes explicit.
  • Neighbor system identity and a four-octet extended circuit identity prevent a reply from silently attaching to the wrong endpoint or a reused circuit number. Yet three-way Up remains only one rung in an evidence ladder: it does not prove LSDB synchronization, FIB installation, bidirectional traffic delivery or service success.

The first Hello was never the whole conversation

The old point-to-point procedure carried an assumption from below the routing protocol. Each system heard the other system's Hello, declared it reachable, and sent a Complete Sequence Number PDU to begin database synchronization. That sequence works when the underlying subnetwork behaves as ISO 10589 expects. When the physical layer violates those expectations, the same control event can be true and misleading at once.

RFC 5303 catalogued three failures. In the first, a link returns or a system restarts, the CSNP is lost, and the link is the network's only cut. The two link-state databases can remain unsynchronized until the full LSP refresh period—up to eighteen hours. The Hello was received. The adjacency existed. The missing receipt sat one layer later.

The second failure is harsher because reachability elsewhere can camouflage it. One direction of a link fails, and only one router detects the loss. Ordinarily the resulting one-sided advertisement lets SPF ignore that link. Add a second parallel link, however, and SPF can still find a path between the routers. The router that never saw the failure may keep choosing the broken direction for traffic. A topology calculation that remains connected does not certify each member link.

The third failure is a problem of identity. Some physical systems can change interconnection without generating a link-layer-down event. Packets may arrive at a different system, or at a different link on the same system, while the receiver associates them with the old adjacency. The protocol has heard a voice. It has not yet proved which room the voice occupies.

RFC 5303 is a Standards Track document from 2008 and a minor edit of RFC 3373, advanced from Informational status. It is not evidence that these faults exist in a current product or network. Its continuing value is the shape of its correction: make the missing acknowledgment and identity binding visible rather than allowing a green adjacency to inherit facts it did not establish.

Three states create a return receipt

The extension carries a Point-to-Point Three-Way Adjacency option in the IIH. Its three-way state begins at Down: no IIH containing the option has been received on the circuit. It moves to Initializing when such an IIH arrives, because the local system now hears the neighbor but does not yet know whether the neighbor hears it. It reaches Up only when the local system knows that the neighbor receives its IIHs.

That sequence does not replace the adjacency state defined by ISO 10589. RFC 5303 says plainly that the two states are not equal or equivalent. An adjacency can have both. An ISH may affect the ISO adjacency while the three-way state remains Down. The design resists a familiar monitoring shortcut: one label cannot safely stand for two different state machines.

The transition table also carries information that a single boolean would erase. Local Up combined with a neighbor reporting Down returns the exchange to initialization. Local Down combined with a received Up can delete the adjacency with the reason “Neighbor restarted.” The state is not a decorative capability flag. It is a conversation about each side's view of the conversation.

Still, Up has a precise meaning: reciprocal IIH visibility under this mechanism. It says nothing by itself about whether a later CSNP arrived, whether every LSP converged, whether a route entered the FIB, whether the interface can carry the intended packet size, or whether an application obtained a response. Those are different receipts.

A return message also needs an address inside the machine

Reciprocity solves only part of the third failure. A return pulse could be real but attached to the wrong endpoint. RFC 5303 therefore lets an IIH report the neighbor's System ID and Neighbor Extended Local Circuit ID. When present, those values are checked against the local system and circuit; a mismatch causes the PDU to be discarded.

The extended identifier matters because the legacy circuit space invited reuse. IS-IS had an implicit 256-interface issue, though the actual LAN constraint was narrower, and implementations commonly reused point-to-point circuit IDs. Those values appeared only in IIHs and mainly helped detect a change at the far end. Reuse reduced that protection: move a link onto another interface that happens to carry the same local number, and a stale association can look continuous.

The new Extended Local Circuit ID is four octets and must be unique among the intermediate system's circuits when assigned. It need not relate to the old Local Circuit ID. In governance terms, this is not “more bits” as a cosmetic upgrade. It expands the namespace enough for the receipt to name the actual circuit rather than a locally recycled label.

There is a subtle limit. The three-way-state field is mandatory for a supporting system, but the remaining fields are specified as SHOULD. If neighbor identity fields are absent, processing can continue. RFC 5303 even notes that the state procedure works when neither neighbor field is ever included, preserving compatibility with an earlier form of the option. The operator must therefore distinguish “three-way state observed” from “three-way state plus neighbor and circuit binding verified.”

Compatibility is permission to accept a weaker proof

Backward compatibility is explicit. A router that does not understand the new option ignores it and does not emit it. When a received IIH lacks the option, the supporting router assumes the link works in both directions and follows the old procedure. That choice enabled staged deployment. It also means a fleet can display adjacency continuity while different sessions meet different evidentiary standards.

This is not a defect hidden in the text; it is the bargain the text announces. Compatibility prevents an upgrade from severing every relationship with an older neighbor. But an operational dashboard that collapses fallback and verified three-way sessions into the same green icon conceals the bargain from the people accountable for it.

The right inventory is therefore not “RFC 5303 supported: yes/no.” It records whether the local system emitted the option, whether the remote system returned it, which three-way state was observed, whether neighbor System ID and extended circuit identity were present, whether each matched, and whether the session fell back to the old assumption. Absence is not failure in the protocol. It is weaker evidence in the institutional record.

Authentication and liveness occupy different columns

RFC 5303 says it raises no new security issues and points to IS-IS authentication. That reference should not be stretched. Authentication can help show that an IIH came from a holder of accepted keying material and was not altered in transit. The three-way handshake shows reciprocal IIH visibility and, when supplied, neighbor/circuit binding. Neither statement subsumes the other.

An authenticated message can be attached to a miswired circuit. A correctly bound circuit can carry an unauthenticated message. Both can be true while databases remain divergent. And all three can be true while forwarding fails later. BFD, for example, defines a separate mechanism for rapid bidirectional forwarding detection. Its separate existence is a useful warning against declaring a universal liveness result from an adjacency handshake.

The evidence ledger should therefore keep at least these rows: physical carrier, IIH received, reciprocal IIH acknowledged, neighbor identity matched, circuit identity matched, authenticated control message, adjacency transition, CSNP exchange, LSDB synchronization, FIB installation, data-plane probe, and service observation. “Up” belongs to one row, not the heading of the ledger.

Limits of this analysis

RFC 5303 describes a protocol correction, not a present-day incident report. It does not establish that a named implementation mishandles one-way links, that an operator lacks the extension, or that eighteen-hour divergence has occurred in a current network. Such claims require implementation, configuration, telemetry and incident evidence.

Nor is every failure removed by deploying the option. Compatibility fallback deliberately retains the old assumption. Optional identity fields can leave the circuit binding less explicit. Authentication requires its own policy and key lifecycle. LSDB and forwarding verification occur after adjacency formation. A healthy service may even mask a failed parallel member until load, hashing or topology changes expose it.

The narrower claim is more useful: do not ask a Hello to testify about the return direction, do not ask a return direction to identify the circuit unless it actually names it, and do not ask an adjacency to certify what only later layers can observe.

Sources