IP Address Schemes for Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces
draft-mmsn-bfd-on-lags-address-00

Abstract

This document describes techniques which can be used by a router to obtain or discover remote neighbor IP address in order to establish micro Bidirectional Forwarding Detection (BFD) sessions [BFD-ON-LAGS].

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 10, 2012.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

[BFD-ON-LAGS] 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 [BFD-ON-LAGS]. 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 [BFD-ON-LAGS].

2. Source IP Address

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.

3. Remote Neighbor IP Address Discovery Mechanisms

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.

3.1. Explicit Configuration (Option 1)

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.

3.2. Auto-Discovery Using Multicast Address (Option 2a)

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 [RFC5880] and [BFD-ON-LAGS]. 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.

3.3. Auto-Discovery Using Loopback Address (Option 2b)

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.

4. Interoperability

Ideally, two nodes connecting [BFD-ON-LAGS] 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.

4.1. Packet De-multiplexing (Rule 1)

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

4.2. Packet Accepted (Rule 2)

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

5. IANA Considerations

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.

6. Security Considerations

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

7. References

Authors' Addresses

Table of Contents

• 1. Introduction
• 2. Source IP Address
• 3. Remote Neighbor IP Address Discovery Mechanisms
• 3.1. Explicit Configuration (Option 1)
• 3.2. Auto-Discovery Using Multicast Address (Option 2a)
• 3.3. Auto-Discovery Using Loopback Address (Option 2b)
• 4. Interoperability
• 4.1. Packet De-multiplexing (Rule 1)
• 4.2. Packet Accepted (Rule 2)
• 5. IANA Considerations
• 6. Security Considerations
• 7. References
• Authors' Addresses