Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)
Extracted elements (25)
BFD is explicitly not applicable for application-to-application failure detection across the Internet because it lacks sufficient congestion detection and avoidance capability, which could cause congestion collapse. Host-to-host or application-to-application deployment would require BFD to be encapsulated within a transport providing TCP-friendly (TFRC) behavior.
On point-to-point links, the source address is explicitly excluded from session identification to allow it to change (e.g., interface renumbering). The TTL=255 check or use of authentication provides assurance that packets genuinely come from the immediate neighbor, making source-address-based identity redundant.
The BFD Echo source address is deliberately chosen to not belong to the subnet of the transmitting interface and to not be a link-local address, in order to prevent the remote system from generating ICMP Redirect or Neighbor Discovery Redirect messages that would interfere with the echo path.
Section 8 states 'Ports 3784 and 3875 were assigned by IANA,' but the correct port number for BFD Echo is 3785 (as correctly stated in Section 4). The value '3875' in Section 8 appears to be a typographic error.
An implementation MAY use the UDP source port number to aid in demultiplexing incoming BFD Control packets, but ultimately the mechanisms in the BFD base specification (RFC 5880) MUST be used to demultiplex packets to the proper session.
BFD Echo packets on multiaccess media MUST be transmitted with a destination datalink address corresponding to the remote system to ensure the packet is received by the correct peer, not merely broadcast or misdirected.
If more than 16384 BFD sessions are simultaneously active, UDP source port numbers MAY be reused across multiple sessions, but the number of distinct uses of the same UDP source port SHOULD be minimized.
A system implementing the Echo function MUST be capable of sending packets to its own address, which typically requires bypassing the normal forwarding lookup and accessing APIs that bypass IP-layer functionality.
BFD Control packets MUST be transmitted in UDP packets with destination port 3784. The source port MUST be in the range 49152 through 65535, the same source port number MUST be used for all packets in a session, and the source port SHOULD be unique among all BFD sessions on the system.
BFD Echo packets MUST be transmitted in UDP packets with destination port 3785. The destination address MUST be chosen to cause the remote system to forward the packet back to the local system, and the source address MUST be chosen to preclude the remote system from generating ICMP or Neighbor Discovery Redirect messages.
Both sides of a single-hop BFD session MUST take the 'Active' role, sending initial BFD Control packets with a zero value of Your Discriminator. Any BFD packet from the remote machine with a zero Your Discriminator MUST be associated with the session bound to the remote system, interface, and protocol.
Each BFD session between a pair of systems MUST traverse a separate network-layer path in both directions. This is required for correct demultiplexing and to avoid multiple sessions protecting the same path.
If BFD is used with both IPv4 and IPv6 on a particular link, a separate BFD session MUST be established for each protocol, encapsulated by that protocol.
If the received source address changes on a point-to-point link, the local system MUST NOT use the new address as the destination in outgoing BFD Control packets; it MUST continue to use the address configured at session creation.
Implementations MUST ensure that all BFD Control packets are transmitted over the one-hop path being protected by BFD. On a multiaccess network, BFD Control packets MUST be transmitted with source and destination addresses that are part of the subnet.
Implementations that support the Echo function MUST ensure that ingress filtering (BCP 38) is not in use on an interface employing the Echo function, or make an exception for BFD Echo packets, because ingress filtering is incompatible with the way Echo packets are sent.
On a point-to-point link, the source address of a BFD Control packet MUST NOT be used to identify the session. The initial BFD packet MUST be accepted with any source address, and subsequent packets MUST be demultiplexed solely by the Your Discriminator field.
The source address of BFD Echo packets SHOULD NOT be part of the subnet bound to the transmitting interface and SHOULD NOT be an IPv6 link-local address, unless it is known that the remote system will not send Redirects.
When BFD authentication is in use, all BFD Control packets MUST still be sent with TTL or Hop Limit of 255. Received packets with TTL/Hop Limit not equal to 255 MAY be discarded, and the TTL check MAY be performed before cryptographic authentication to avoid unnecessary computation.
When BFD authentication is not in use, all BFD Control packets MUST be sent with TTL or Hop Limit value of 255, and received Control packets demultiplexed to the session MUST be discarded if the received TTL or Hop Limit is not equal to 255.
When BFD is used with tunnels that do not decrement the TTL/Hop Limit of the carried protocol, the BFD authentication mechanism SHOULD be used and is strongly encouraged.
BFD Control packets are encapsulated in UDP with destination port 3784, within an IPv4 or IPv6 packet. The UDP source port MUST be in the range 49152–65535 and the same source port MUST be used for all Control packets of a given session.
IANA assigned UDP port 3784 for the BFD Control protocol and UDP port 3785 for the BFD Echo protocol for use with single-hop IPv4 and IPv6 BFD sessions.
The simultaneous use of TTL=255 checking and BFD authentication provides a low-overhead mechanism for discarding unauthorized packets, which may be useful in implementations where cryptographic checksum processing is susceptible to denial-of-service attacks. The use or non-use of this combined mechanism does not impact interoperability.
The use of TTL=255 on transmit and receive, coupled with an association to an incoming interface, is considered to supply equivalent security characteristics to other infrastructure protocols, as it is not trivially spoofable. The security implications are further discussed in RFC 5082 (GTSM).