Summary

  • RFC 9747 tests a bounded forwarding loop through an adjacent IP forwarder. The destination address, BFD state and discriminator originate locally; the neighbour does not issue a BFD health declaration.
  • Exact TTL or Hop Limit validation, compatible forwarding configuration and a locally provisioned detection budget are prerequisites, not proof of remote IP, application or downstream availability.
  • Faster detection can support an already authorised interface action. It cannot supply the missing business authority, evidence of user recovery or conditions for safe failback.

The address gives the game away

The most revealing part of this failure detector is its destination. Device A sends a packet towards B, but the destination IP address belongs to A itself. B sends it back by ordinary IP forwarding. A has learned something valuable about an adjacent forwarding interface without asking B to implement the full BFD protocol. It has not asked B's management address, let alone an application behind B, to answer.

That distinction is explicit in RFC 9747, section 1. Published in March 2025 as an IETF Standards Track document updating RFC 5880, it defines Unaffiliated BFD Echo for one IPv4 or IPv6 hop. Its publication date establishes a specification, not a deployment count or a measured reliability improvement. The mechanism matters precisely because a neighbour need only forward IP. Lowering that dependency is useful; extending the resulting evidence beyond the small loop would erase the reason the simplification works.

A conversation with one's own state

The packet uses the BFD Control format, but travels to Echo UDP destination port 3785. B neither intercepts it to run a BFD session nor parses its BFD fields. A applies the relevant asynchronous processing, validation and authentication procedures to the returned packet. From A's perspective there is a session; between the two ends there is no coordinated BFD protocol state.

The state machine therefore consumes state generated by A and returned through B. Down, Init and Up can describe the local test's progress, but none is a separate statement by B about its administrative intentions. AdminDown is not used in this mechanism. The same ownership appears in the discriminators: A provisions My Discriminator, starts Your Discriminator at zero, and then uses the returned My Discriminator value as Your Discriminator. Startup demultiplexing uses the source IP address or UDP source port; later reception uses Your Discriminator alone. These are session-selection rules, not an identity certificate for the far end. RFC 9747, section 2 supplies the rules.

The single-hop boundary is deliberately strict. Every transmitted packet must have TTL, or IPv6 Hop Limit, 255. A received packet must have exactly 254; otherwise it must be discarded. Authentication does not waive that requirement. Nor does a correct value independently identify B: it checks the configured hop condition under the network's forwarding assumptions. A tunnel or altered forwarding behaviour needs its own validation, rather than a convenient relaxation of the acceptance test. This is not a multihop probe: the first hop would return the packet before a longer intended path had been exercised.

The neighbour can be silent, but cannot be unprepared

Ordinary forwarding still has to be arranged. Routers generally provide it; hosts may not enable it by default. RFC 9747 leaves the provisioning method for B outside its scope. On A, a packet addressed to A must nevertheless leave towards B, not disappear into local delivery. On a multi-access link the data-link destination must direct it to the intended neighbour. A packet capture at the selected interface is stronger evidence of that arrangement than a configuration label bearing B's name.

Address selection also has consequences. The inherited RFC 5881 Echo encapsulation rules avoid IP Redirect behaviour; an address on the outgoing interface's subnet, or an IPv6 link-local source, is unsuitable unless it is known that a redirect will not occur. RFC 9747 also warns that Unicast Strict Reverse Path Forwarding can prevent the required return. The operational task is to reconcile a narrowly scoped Echo path with ingress protection, not to disable anti-spoofing across a network. RFC 3704 explains the strict reverse-path check that creates the conflict.

These prerequisites move work rather than abolish it. B's operator may change forwarding, filtering or interface configuration without issuing any BFD administrative message. A's owner must distinguish a service outage from a test that no longer has its agreed conditions.

The clock is local too

Control-format interval fields can look like a bilateral timing agreement. Here they are not. Desired Min TX Interval and Required Min RX Interval must contain specific values to avoid leaking uninitialised memory; the recommended value is one second, or 1,000,000 microseconds. Required Min Echo RX Interval is similarly initialised, with zero recommended. Reception ignores all three; the first two must not calculate Detection Time.

A instead provisions the Up-state transmission interval and Detect Mult locally. Startup and recovery after Down use a slow rate, no greater than one packet per second as described by the RFC; the configured faster interval applies once Up. When an Up test misses the provisioned number of expected Echo packets, A must become Down and set LocalDiag to 2, Echo Function Failed. A useful sizing illustration is a nominal budget of interval multiplied by missed-packet count. It is not a measured convergence guarantee. Transmission jitter, receive scheduling, client reaction, forwarding-table change and successful user traffic are different clocks.

A healthy loop can coexist with a failed service

Suppose the adjacent device still forwards a packet back to A while its management address is unavailable or an application beyond it fails. Echo Up need not be wrong; the broader assertion that the service is healthy would be wrong. Conversely, an Echo filtering change or local receive pressure may produce Down even while the service's own transactions continue. That is a false failure relative to a service claim, not necessarily a defect in the specified detector. The comparison must name the service and observation window before calling either result a false positive or negative.

Security does not close that semantic gap. RFC 9747 recommends the BFD Authentication Section because Echo packets can be spoofed. The authentication content still originates at A. Validating its return protects the test under the selected authentication scheme; it does not turn B into an independently authenticated speaker, prove its intent or vouch for the business behind it. Authentication, hop validation and application checks address different questions.

The resulting evidence is narrow but usable: the local loop satisfied its acceptance conditions within the local budget. A leadership report should keep that sentence intact. It should not translate it into “the neighbour and its services are available” merely because a dashboard has room for only one green light.

Sources

Specification, inherited rules and status: RFC Editor, RFC 9747, IETF Datatracker, RFC 5880, RFC 5881, RFC 5882, RFC 5082, RFC 3704, RFC 9747 — errata.

Attributed analytical framework: Lu Heng — Note 65, Lu Heng — Note 64, Lu Heng — Note 36.