Summary

  • RFC 6860 lets OSPF retain the topology description needed for shortest-path calculation while withholding the numbered transit prefix that would otherwise create destination reachability. The link can remain operational even when its prefix is absent from an OSPF-derived RIB and FIB.
  • “Hidden” is deliberately narrow. OSPFv2 can still expose interface-address material in LSAs; older routers can install a host route in a partial broadcast-network deployment; management, forwarding-address and virtual-link dependencies can fail if the address was doing more than numbering a transit edge.

The route disappeared; the adjacency did not

The most useful way to read RFC 6860 is to begin with an apparently contradictory observation. A router reports an OSPF neighbor in Full state. The link remains part of the shortest-path graph. Traffic between destinations on opposite sides continues to cross it. Yet a remote show route no longer contains the IPv4 or IPv6 prefix assigned to the transit link.

None of those observations cancels another. OSPF needs to know that two routers are connected in order to calculate paths through them. It does not always need to make the link's numbered subnet a destination that every router can reach. RFC 6860 turns that distinction into a standards-track mechanism for networks that connect routers only.

For a numbered OSPFv2 point-to-point link, the ordinary Router-LSA carries two logically different descriptions. A Type 1 link names the neighboring router and supplies the topology edge used by SPF. A Type 3 stub link advertises the assigned subnet and causes a route to that subnet to enter the routing table. Prefix suppression omits the Type 3 description while retaining Type 1. The graph keeps the edge; the RIB loses the destination prefix.

That is the control surface in one sentence. It is not interface shutdown, adjacency suppression, metric inflation or address removal. It is a decision about which address information should become routed destination state.

The broadcast case needs a different signal

Point-to-point omission is not enough for every OSPF network type. On a broadcast network, the Designated Router originates a Network-LSA describing the attached routers. The LSA's Link State ID and mask also identify the network prefix. Removing the entire LSA would remove topology information that SPF still needs.

RFC 6860 therefore uses a special mask: 255.255.255.255. The DR continues to originate the Network-LSA with its attached-router list, but an upgraded receiver recognises the host mask as the instruction not to install the corresponding network route. NBMA networks that emulate broadcast operation use the same method.

The compatibility detail is important. A router without RFC 6860 support can treat the modified LSA as an ordinary /32 and install a host route to the DR's interface address. An upgraded router installs no route for that prefix. The RFC accepts that partial-deployment asymmetry because the obsolete receiver exposes one address rather than the entire transit subnet. But the asymmetry remains real.

An operator who says “the prefix is hidden across the area” must therefore name the receiving software set. One LSDB can lead to different RIB outcomes. Capability is part of the evidence, not a footnote to it.

OSPFv3 makes the separation cleaner

OSPFv3 moved addressing out of the main topology LSAs. Router-LSAs and Network-LSAs describe the graph without embedding network addresses. Link-LSAs associate addresses with a link at link-local flooding scope, while Intra-Area-Prefix-LSAs associate prefixes with routers or transit networks.

That architecture lets prefix suppression leave the topology LSAs alone and omit the transit-only prefixes from the relevant Intra-Area-Prefix-LSA construction. RFC 5838's address-family support does not require a new hiding message; the same division between topology and prefix advertisement applies inside each OSPFv3 instance.

The cleaner design does not make every trace disappear. A Link-LSA is still a protocol object. Router IDs remain. Local interface state, configuration, telemetry and packets can still disclose address or topology information. The defensible claim is not “OSPF forgot the link.” It is “this receiver did not install the suppressed prefix as routed reachability.”

Hidden is not secret

RFC 6860 uses “hiding” in a defined technical sense. Its security objective is to leave fewer core transit networks remotely reachable. Even when an address is known, routers without a route cannot forward ordinary traffic toward it through that OSPF domain.

That can reduce an attack surface. It is not encryption, authentication, access control or erasure. In OSPFv2, an interface address can remain visible as Router-LSA Link Data, and the DR's address remains the Network-LSA Link State ID. A router directly attached to the link has connected reachability. Another protocol, a static route, a tunnel or a management network may provide a path that OSPF does not.

The word hidden therefore needs a subject and an observation point. Hidden from which RIB? Derived from which OSPF instance? At which software version and time? Was the prefix also absent from the FIB? Was an alternate route present? Were packets tested from the place whose exposure matters?

Without those qualifiers, a protocol result becomes a security slogan. The strongest evidence is modest: the identified prefix was omitted from the identified receiver's OSPF-derived routing and forwarding state, while the identified adjacency and topology path remained.

The address may have had another job

The standard spends unusual care on what prefix suppression can break. Interface reachability is often used for troubleshooting and management even when ordinary customer traffic never targets the transit subnet. Once the prefix disappears from remote routing tables, pings, traceroute return paths and direct interface management can change.

Two dependencies are protocol-critical. First, a non-zero Forwarding Address in an AS-external or NSSA LSA requires a matching routing-table entry. An address on a suppressed interface must not be advertised as that Forwarding Address; otherwise the calculation lacks the route it needs. The fallback can produce less direct external routing.

Second, an OSPF virtual link depends on routable endpoint addresses through an intra-area path. A suppressed interface address must not be used as the virtual-link endpoint. The topology edge surviving suppression does not rescue a control function that explicitly depends on address reachability.

The same inventory must include inter-domain peering, automation targets, access lists, flow records, interface identifiers and out-of-band management assumptions. “Transit-only” is not a property that the subnet mask can prove. It is an operator claim about every material use of the address.

Running code needs a two-sided receipt

Current FRRouting and Cisco documentation exposes prefix-suppression controls. That proves the mechanism exists in named software families; it does not prove that a production router has enabled it, that the scope is correct or that the result is safe.

A defensible change receipt starts before configuration. Capture the software and capability set, intended interfaces, excluded loopbacks or passive links, pre-change LSDB, OSPF RIB and FIB, current management path, Forwarding Address use, virtual links and any peering bound to the numbered interfaces.

After the change, preserve both sides of the intended split:

  1. the neighbor adjacency and topology edge remain present;
  2. the Type 3 stub description or relevant prefix association is absent, or the special Network-LSA mask is present;
  3. each upgraded receiver omits the prefix from its OSPF RIB and FIB;
  4. any legacy receiver shows only the explicitly accepted compatibility result;
  5. the intended management path still works without borrowing the suppressed prefix;
  6. external routes, virtual links and packet paths retain the expected behavior; and
  7. rollback restores the prefix advertisement and reachability when its trigger is met.

The route-count reduction is not the whole outcome. A lower RIB count can coexist with lost observability or indirect external routing. Convergence improvement must be measured against a baseline; it cannot be inherited from the RFC abstract.

Álvaro Retana's bounded place in the record

RFC 6860 was published in 2013 by Yi Yang, Álvaro Retana and Abhay Roy. It updates the OSPFv2 and OSPFv3 base specifications and acknowledges a wider inventor and reviewer group. Retana's current IETF profile records a much broader routing-standards career, but this article does not turn that career into ownership of OSPF, Cisco code or any operator's deployment.

His documented co-authorship is enough. It connects him to a mechanism that refuses to treat topology and address reachability as the same fact. That distinction fits a durable Internet design discipline: agree on the smallest shared encoding, leave activation and dependency decisions local, and accept nothing as complete until running systems produce the promised state.

The mechanism's restraint is its significance. RFC 6860 does not order every network to hide every transit prefix. It gives compatible implementations a way to do so, names the cases in which the choice is unsafe and leaves the operator responsible for proving the result.

A prefix-suppression ledger

The final record should be readable after the engineers and software have changed. For every suppressed prefix, retain the router and release, feature scope, observation time, relevant LSA identity, receiver capability, pre/post RIB and FIB fingerprints, adjacency state, management alternative, dependency checks, packet canaries, owner and rollback condition.

That ledger keeps five statements from collapsing into one:

  • the link exists;
  • OSPF uses it as topology;
  • the interface has an address;
  • remote routers do not install the prefix; and
  • intended services still work.

RFC 6860 permits all five to have different answers. The prefix can leave the RIB while the link keeps carrying the network. Good operations begin by recording exactly which thing disappeared—and which did not.

Sources