| Internet-Draft | Interface Index Capability for BGP | October 2026 |
| Lin & Wang | Expires 3 May 2027 | [Page] |
In some scenarios using unnumbered links, it is necessary for the BGP protocol to advertise the link's Interface Index and obtain the peer's Remote Interface Index.¶
This document defines a new BGP capability, as specified in RFC 5492, for advertising local interface indexes and obtaining neighbor interface indexes.¶
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 https://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 3 May 2027.¶
Copyright (c) 2026 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Here are several issues that arise when using unnumbered links due to BGP's lack of support for interface index.¶
Scenario 1: BGP-LS-SPF¶
BGP-LS-SPF [RFC9815] is a solution that leverages both the BGP protocol [RFC4271] and the BGP-LS extension [RFC9552]. In the BGP SPF routing domain, BGP routers collect network-wide topology information through the BGP-LS-SPF protocol and perform cross-domain path calculation to compute routes using the SPF algorithm. This approach aims to achieve intelligent traffic engineering and automated routing optimization in large-scale data center or carrier networks.¶
When an IGP protocol advertises an unnumbered link, it uses the local interface index and the remote interface index to distinguish between different unnumbered links.¶
BGP-LS-SPF reuses the BGP-LS information from the IGP. However, during the deployment of BGP-LS-SPF, if the remote interface index is unknown, it may lead to path calculation errors.¶
Scenario 2: BGP Egress Peer Engineering (EPE)¶
When deploying EPE, the BGP-LS peer link information in EPE is defined as follows (see Section 5.2 of [RFC9086]):¶
Link Descriptors MUST include the following TLV, as defined in [RFC9552]:¶
Currently, BGP has no mechanism to obtain the peer's Link Remote Identifier.¶
Scenario 3: BGP neighbor monitoring¶
During neighbor monitoring, if displaying bidirectional neighbor connectivity, without the Link Remote Identifier, the corresponding neighbor relationships on both sides cannot be matched.¶
Therefore, fundamentally, in unnumbered BGP scenarios, BGP peer information should include: local router-id, peer address, peer AS number, local interface index, and remote interface index.¶
This document defines a new BGP capability, as specified in [RFC5492], for advertising support of the interface index capability, thereby advertising local interface indexes and obtaining neighbor interface indexes.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following terminology is used in this document.¶
In the BGP protocol, the OPEN message carries the newly added Interface Index Capability TLV to exchange interface index information with neighbors.¶
When sending an OPEN message, the Interface Index Capability is included to advertise the Interface Index of the interface used to establish the neighbor relationship.¶
When receiving an OPEN message, if it contains the Interface Index Capability, the peer's Remote Interface Index is saved. If the Interface Index Capability is not carried, save the Remote Interface Index as 0.¶
The format of the Interface Index Capability is shown in Figure 1.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cap Code = TBD |Cap Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A BGP speaker that receives an OPEN message containing the Interface Index Capability with a Capability Length (as defined in [RFC5492]) other than 4 MUST treat the capability as malformed and ignore it. In this case, the Remote Interface Index of the peer MUST be set to 0, and the BGP session SHOULD still be established. An implementation MAY log this condition for further analysis.¶
If the Interface Index Value is 0, it indicates that the local interface index of the sender is unknown. The receiver MUST treat the Remote Interface Index as 0, and the BGP session SHOULD still be established.¶
Per [RFC5492], a BGP speaker that does not recognize or does not support the Interface Index Capability MUST silently ignore it, and the procedures described in this document do not apply to that BGP session.¶
A new BGP Capability named "Interface Index Capability" will be requested from the "Capability Codes" registry within the "IETF Review" range [RFC5492].¶
| Code Point | Description | Reference |
|---|---|---|
| TBD | Interface Index Capability | This document |
This document defines a new BGP capability that is carried in the OPEN message as specified in [RFC5492]; it does not introduce any new BGP messages or modify the BGP finite state machine.¶
The Interface Index carried in this capability is not considered sensitive information, as it is already advertised by the routing protocols of the local node (e.g., via the Link Local/Remote Identifiers TLV in BGP-LS [RFC9552]). However, a malicious BGP peer could advertise an incorrect Interface Index, which could mislead the receiver in scenarios such as those described in Section 1 (e.g., causing mismatches when correlating bidirectional neighbor relationships or computing paths over unnumbered links).¶
This document does not introduce any new mechanisms to protect the BGP session beyond those that already exist. Existing mechanisms to protect BGP sessions, such as the Generalized TTL Security Mechanism (GTSM) [RFC5082] and the TCP Authentication Option (TCP-AO) [RFC5925], SHOULD be used to protect the integrity of the BGP session.¶