Bidirectional Forwarding Detection (BFD) for Multihop Paths
Extracted elements (18)
BFD is not applicable for application-to-application failure detection across the Internet because it lacks sufficient congestion detection and avoidance capability; host-to-host deployment would require encapsulation within a TCP-friendly transport.
Out-of-band discriminator signaling (Section 4.2) is advantageous because it allows BFD to be directed by system components with knowledge of paths in use and is simple to implement, but requires BFD-specific knowledge outside the BFD subsystem.
The TTL/Hop Limit of 255 approach used in BFD-1HOP to prevent spoofing cannot work for multihop paths, so BFD authentication is required instead to address the security issue.
Unidirectional links are classified as multihop paths because their return path may be arbitrary and return paths for parallel unidirectional links may overlap or be identical, making the single-hop TTL-based demultiplexing approach inapplicable.
BFD multihop encapsulation in IPv4 and IPv6 is identical to that defined in RFC 5881 (BFD-1HOP) except for the UDP destination port, which MUST be 4784 instead of the single-hop value.
The out-of-band discriminator signaling method is used by the BFD MPLS specification (RFC 5884), establishing a precedent for external signaling of BFD discriminators before session establishment.
The totally arbitrary paths approach (Section 4.1) limiting BFD to one session per address pair is appropriate for OSPF Virtual Links (OSPFv2/OSPFv3), providing a concrete interoperability use case.
BFD Control packets for multihop application MUST use UDP destination port 4784, distinct from the single-hop port, to aid in demultiplexing and internal routing of incoming BFD packets.
For unidirectional links, the Unidirectional Receiver MUST operate in the Passive role, meaning it does not transmit BFD Control packets until it learns the discriminator value from the first received packet.
For unidirectional links, the Unidirectional Sender MUST operate in the Active role as defined in the base BFD specification.
Implementations of BFD SHOULD utilize cryptographic authentication over multihop paths to help mitigate denial-of-service attacks, given the increased spoofing exposure as hop count increases.
The Echo function MUST NOT be used over multiple hops. Intermediate hops would route the packets back to the sender, preventing verification of connectivity through the entire path.
BFD multihop uses UDP destination port 4784 for encapsulation of BFD Control packets in both IPv4 and IPv6, replacing the single-hop port used by RFC 5881.
For totally arbitrary paths, BFD deployment is limited to a single session between a source/destination address pair; multiple sessions between the same pair must have at least one distinct endpoint address.
For unidirectional links, the Unidirectional Receiver demultiplexes the first BFD Control packet to the proper session based on the physical or logical link over which it was received, then learns the remote discriminator to echo back.
In the out-of-band discriminator signaling approach, discriminator values are exchanged in each direction through an out-of-band mechanism before the BFD session is established, so no packets with Your Discriminator set to zero are ever sent.
IANA has assigned UDP port 4784 for use with BFD Multihop Control.
As the number of hops increases, BFD becomes further exposed to attack; the use of strong forms of cryptographic authentication is strongly encouraged for multihop BFD deployments.