Unsolicited Bidirectional Forwarding Detection (BFD) for Sessionless Applications
Extracted elements (25)
Compared to Seamless BFD (RFC 7880), unsolicited BFD involves only minor procedural enhancements to widely deployed BFD and does not require exchange of BFD discriminators over an out-of-band channel before session bring-up, making it simpler to deploy.
The passive side selects its own bfd.LocalDiscr rather than accepting or mirroring the active side's discriminator because multiple concurrent unsolicited BFD sessions from different active peers may exist on the same passive node.
Unsolicited BFD addresses the operational burden where sessionless applications (e.g., static route next-hop tracking, IXP Route Server third-party next-hop tracking) currently require coordinated configuration on both endpoints even when only one side needs the BFD functionality.
Unsolicited BFD is intentionally restricted to single IP hops (RFC 5881) and not applied to multihop paths (RFC 5883) due to security risks associated with accepting BFD sessions from arbitrary remote systems across multiple hops.
Unsolicited BFD applies only to BFD for single IP hops (RFC 5881). The document explicitly states that although the procedure could be applied to multihop BFD (RFC 5883), it is not specified for multihop due to security risks.
Unsolicited BFD impacts only the initiation of BFD sessions; all other RFC 5880 procedures—including the Echo function and Demand mode—remain unchanged.
If the BFD session fails to get established within a time at least equal to the local failure detection time, or if an established session goes down, the passive side MUST stop sending BFD Control packets and SHOULD delete the BFD session until the active side initiates again.
Implementations of unsolicited BFD are RECOMMENDED to use BFD authentication, and if authentication is used, the strongest supported BFD authentication mechanism MUST be used.
Implementations of unsolicited BFD MUST apply policy to process BFD packets only from certain subnets or hosts to mitigate excessive resource usage from unexpected remote systems.
Implementations of unsolicited BFD MUST limit the feature to specific interfaces and to single-hop BFD sessions using the Generalized TTL Security Mechanism (GTSM) procedures from RFC 5082/5881.
Passive unsolicited BFD support MUST be disabled by default and MUST require explicit configuration to be enabled.
The bfd.LocalDiscr value MUST be selected by the passive side to allow multiple unsolicited BFD sessions, even if the passive side chooses to adopt the active side's timing parameters.
When the passive side receives a BFD Control packet with 'Your Discriminator' set to 0 and finds no existing session, it SHOULD create a matching BFD session toward the active side, unless prohibited by local configuration or policy.
When the passive side receives an incoming BFD Control packet on a numbered interface, the source address MUST belong to the subnet of the receiving interface; otherwise the packet MUST NOT be processed.
A new state variable bfd.Role is defined, indicating the role (Active or Passive) of the local system during BFD session initialization per RFC 5880 Section 6.1.
On the passive side, the BFD parameters bfd.DesiredMinTxInterval, bfd.RequiredMinRxInterval, and bfd.DetectMult SHOULD be configurable; the passive side MAY also adopt the active side's values for these parameters.
The 'unsolicited-params-per-interface' YANG feature gates per-interface parameter overrides (local-multiplier, desired-min-tx-interval, required-min-rx-interval, min-interval); if both global and per-interface configurations exist, per-interface takes precedence.
The YANG module ietf-bfd-unsolicited (namespace urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited) augments RFC 9314's BFD YANG model to add global and per-interface unsolicited configuration and a read-only 'role' leaf on session state.
Unsolicited BFD uses an Active/Passive role model as defined in RFC 5880 Section 6.1. The active side initiates by sending BFD Control packets; the passive side only begins sending after receiving packets from the active side.
IANA registered the namespace URI urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited in the 'ns' subregistry of the IETF XML Registry (RFC 3688).
IANA registered the YANG module 'ietf-bfd-unsolicited' (prefix: bfd-unsol, namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited) in the 'YANG Module Names' registry (RFC 6020).
In some environments such as IXPs, BFD authentication cannot be used due to lack of coordination between session endpoints; in others such as static route next-hop tracking, BFD authentication is feasible but requires configuring matching key chains on both endpoints.
The YANG module's writable data nodes (enabled, local-multiplier, interval parameters) are sensitive: unauthorized write access can enable unsolicited session creation globally or alter BFD packet rates and failure detection times. The read-only 'role' leaf discloses local system role and should have controlled read access.
With unsolicited BFD there is a potential risk of excessive resource usage from unexpected remote systems. Mitigations include restricting to specific interfaces, applying subnet/host policies, and deploying only in environments without anonymous participation (e.g., IXPs with business relationships).
Session lifecycle: Active sends BFD Control packets with 'Your Discriminator'=0. Passive receives and creates session (state: Init). Both exchange packets to reach Up state. On session failure or establishment timeout, passive transitions to Down, stops sending, and deletes session awaiting re-initiation by active.