IP Address Schemes for Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces

proposes a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent BFD asynchronous session on each LAG member link. Transmitted BFD packets will need to have neighbor IP address as the destination address in the IP header. However, the exact mechanism by which a router obtains the remote neighbor IP address is outside the scope of . This document describes a few mechanisms which can be used by a router to discover the remote neighbor IP address in order to run micro BFD sessions .

The source IP address in the IP header is the IP address configured on the LAG for all BFD packets sent on a micro BFD session. This is the case for all options described.

Routers can use two different techniques to learn the remote neighbor IP address to be used as the destination IP address for micro BFD sessions. In the first approach, the destination IP address is explicitly configured. In the second, the remote neighbor IP address is learnt by automatic discovery. We define two distinct mechanisms that can be used for automatic discovery. This following sections describe the different mechanisms that can be employed for obtaining the remote neighbor address for micro BFD sessions.

This neighbor IP address is a mandatory configuration, and destination address in the IP header of transmitted BFD packets is solely controlled by this configuration. Micro BFD sessions MUST NOT transmit any packets if this configuration has not been specified.

Neighbor IP address is not configured. Instead, micro BFD sessions MUST use a well-known link-local multicast IP address (224.0.0.X for IPv4, FF02::X for IPv6, to be assigned by IANA) as destination address in the IP header. Initial BFD packet exchanges will take place this way. BFD packets received will have IP address assigned on the LAG as source address in the IP header. Each router will discover the remote IP address by examining the source IP in micro BFD session packets. When transitioning into INIT or UP states, discovered neighbor IP address MUST be used as destination address in the IP header. Micro BFD sessions are to proceed as described in and . When a micro BFD session needs to start over the session bring-up logic, destination address in the IP header MUST be reset to a well-known link-local multicast IP address. If a node detects that source address in the IP header of latest received BFD packets differs from known neighbor IP address, then a node MUST respect the latest address as neighbor IP address. Destination address in the IP header of transmitted BFD packets are to get reflected of the address change.

Most of the logic and the rules used in this mechanism are same as the preceding option (option 2a). The only difference we use a loopback address (127/8 for IPv4, 0:0:0:0:0:FFFF:7F00/104 for IPv6) instead of a well-known link-local multicast IP address for the initial BFD packets over the micro BFD sessions.

Ideally, two nodes connecting enabled LAG are to use same neighbor address discovery option described. However, all described options can interoperate with each other, as long as following rules, described in this section, are honored. Vendors implementing the mechanisms described in this document SHOULD implement with following rules considered.

De-multiplexing received BFD packets MUST not rely on destination address in the IP header.

A node MUST be implemented to allow and accept BFD packets with unicast , well-known link-local multicast and loopback IP address.

The IANA is requested to assign a well-known link-local multicast IP address: 224.0.0.X for IPv4 and FF02::X for IPv6.

The proposal introduced in this document does not introduce any new security considerations beyond that already apply to the base BFD specification and .