BGP Capability for IPv6 BGP Identifier
draft-li-idr-ipv6-bgp-identifier-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Zhenqiang Li , GuangchenSong | ||
| Last updated | 2026-08-27 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-idr-ipv6-bgp-identifier-01
Inter-Domain Routing Z. Li, Ed.
Internet-Draft G. Song, Ed.
Updates: 4271 (if approved) China Mobile
Intended status: Standards Track 27 August 2026
Expires: 28 February 2027
BGP Capability for IPv6 BGP Identifier
draft-li-idr-ipv6-bgp-identifier-01
Abstract
This document defines a new BGP Capability that enables an IPv6 BGP
Speaker to use its global unicast IPv6 address as its BGP Identifier.
This mechanism simplifies configuration in IPv6-only networks by
leveraging the inherent uniqueness of IPv6 addresses, while
maintaining full backward compatibility with existing BGP
implementations.
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 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 28 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li & Song Expires 28 February 2027 [Page 1]
Internet-Draft BGP Capability for IPv6 BGP Identifier August 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Potential Use Case . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. IPv6 BGP Identifier . . . . . . . . . . . . . . . . . . . . . 4
3. Open Message Processing . . . . . . . . . . . . . . . . . . . 5
3.1. Constructing the OPEN Message . . . . . . . . . . . . . . 6
3.2. Receiving the OPEN Message . . . . . . . . . . . . . . . 6
4. Route Decision Process . . . . . . . . . . . . . . . . . . . 7
4.1. Mixed iBGP Deployment Considerations . . . . . . . . . . 7
4.2. Updated Tie-Breaking Procedure for BGP . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Operational Considerations . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
A router that runs the Border Gateway Protocol (BGP) [RFC4271] is
referred to as a BGP Speaker, and each BGP Speaker is uniquely
identified by a BGP Identifier (BGP ID). The BGP ID is a critical
parameter in the BGP protocol, used for establishing peering
sessions, resolving connection collisions, and participating in best-
path selection.
[RFC4271] specifies that the BGP ID is a 4-byte unsigned integer and
should be configured as a valid IPv4 address assigned to one of the
BGP Speaker's interfaces. However, in IPv6-only network
environments, devices are typically not configured with any IPv4
addresses, making it impossible to fulfill this requirement and
thereby preventing BGP from operating correctly.
Li & Song Expires 28 February 2027 [Page 2]
Internet-Draft BGP Capability for IPv6 BGP Identifier August 2026
[RFC6286] addresses this limitation by allowing the BGP ID to be any
4-byte unsigned integer, independent of interface addresses.
Nevertheless, in IPv6-only deployments, operators must still manually
assign a unique 4-byte BGP ID to each BGP Speaker and ensure that all
BGP IDs within the same Autonomous System (AS) are distinct. This
imposes additional operational complexity, particularly in large-
scale or automated network scenarios.
[RFC5492] defines an Optional Parameter called Capabilities, which
facilitates the introduction of new capabilities into the BGP by
providing a graceful capability advertisement mechanism—eliminating
the need to terminate BGP peering sessions when new capabilities are
introduced.
This document proposes an operationally friendly solution for
IPv6-only networks: allowing a BGP Speaker to use one of its own
global unicast IPv6 addresses as its BGP Identifier, referred to as
the IPv6 BGP ID. To this end, a new BGP Capability is defined.
The solution proposed in this document fully preserves compatibility
with existing BGP implementations. The IPv6 BGP ID is used only
between BGP Speakers that establish a BGP session over IPv6 and
mutually support the new capability. Peers that do not support this
capability will ignore the new option and continue to operate using
the traditional 4-byte BGP Identifier as specified in [RFC4271] and
[RFC6286].
1.1. Potential Use Case
It is about the interactions between BGP-LS [RFC9552] and IGPs that
utilize IPv6-style TE Router-IDs [RFC5329] [RFC6119]. In some
IPv6-only networks, IGP router identifiers are expressed as global
unicast IPv6 addresses. Even in such environments, a BGP session
carrying BGP-LS NLRI still requires a 4-octet BGP Identifier per
[RFC4271], forcing operators to manually provision an additional
32-bit identifier separate from the IGP-defined IPv6 router-id.
If both peers of a BGP-LS session support this IPv6 BGP-Identifier
capability, the BGP-session-level BGP Identifier can directly use the
existing IPv6 global-unicast address, removing the operational burden
of manually assigning a distinct 32-bit value for that session.
Li & Song Expires 28 February 2027 [Page 3]
Internet-Draft BGP Capability for IPv6 BGP Identifier August 2026
1.2. Requirements Language
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.
2. IPv6 BGP Identifier
This document defines a new BGP capability, the IPv6 BGP Identifier
(IPv6 BGP ID). An IPv6 BGP Speaker advertises its support for the
IPv6 BGP ID to its peer by including this capability in the Optional
Parameters of the BGP OPEN message.
[RFC4271] specifies the format of the OPEN message as follows:
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
+-+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Autonomous System |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| opt Parm Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Optional Parameters(variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: OPEN message
The Optional Parameters field, as shown below, contains a list of
optional parameters.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| Parm. Type | Parm. Length | Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Li & Song Expires 28 February 2027 [Page 4]
Internet-Draft BGP Capability for IPv6 BGP Identifier August 2026
Figure 2: Optional Parameters
[RFC5492] defines the Capabilities Optional Parameter with Parameter
Type 2. This parameter contains one or more triples <Capability
Code, Capability Length, Capability Value>, where each triple is
encoded as shown below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Code (1 octet) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Length (1 octet) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Value (variable) |
～ ～
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Capabilities Optional Parameter
The IPv6 BGP Identifier defined in this document is encapsulated in
one triple of the Capabilities Optional Parameter, as shown below.
Capability Code：
1 octet. The specific value will be assigned by IANA and is used
to indicate that this capability option represents the IPv6 BGP
Identifier capability.
Capability Length:
1 octet. It has a value of 16, indicating that the Capability
Value is 16 bytes (the IPv6 BGP Identifier).
Capability Value:
16 octets. This field contains the global unicast IPv6 address of
the BGP Speaker that is used as its BGP Identifier.
In an OPEN message carrying the IPv6 BGP Identifier, the BGP
Identifier field MUST be set to all zeros to indicate that the actual
BGP Identifier is carried within the Capabilities Optional Parameter.
3. Open Message Processing
Li & Song Expires 28 February 2027 [Page 5]
Internet-Draft BGP Capability for IPv6 BGP Identifier August 2026
3.1. Constructing the OPEN Message
A BGP Speaker that supports the IPv6 BGP Identifier MUST set the BGP
Identifier field in the OPEN message to zero and include the IPv6 BGP
Identifier defined in this document as a capability option, where the
Capability Value is a global unicast IPv6 address of the BGP Speaker.
One and only one IPv6 BGP Identifier SHOULD be carried in the OPEN
message.
3.2. Receiving the OPEN Message
A BGP Speaker that supports the IPv6 BGP Identifier capability MUST
examine the BGP Identifier field in the received OPEN message.
If this field is not set to zero, the speaker MUST process the OPEN
message as if the peer does not support the IPv6 BGP Identifier
capability. In this case, any instance of the IPv6 BGP Identifier
capability carried in the Capabilities Optional Parameter MUST be
ignored.
If the BGP Identifier field is zero, the speaker MUST inspect the
Capabilities Optional Parameter for the presence of the IPv6 BGP
Identifier capability defined in this document. If the capability is
absent, the speaker MUST send a NOTIFICATION message with Error Code
2 (OPEN Message Error) and Error Subcode 3 (Bad BGP Identifier).
If the capability is present but the Capability Value does not
represent a valid global unicast IPv6 address, the speaker MUST also
send a NOTIFICATION message with Error Code 2 (OPEN Message Error)
and Error Subcode 3 (Bad BGP Identifier).
If the IPv6 BGP Identifier capability is present in the OPEN message
and its Capability Value is a valid global unicast IPv6 address, the
BGP speaker proceeds to evaluate potential connection collision in
accordance with Section 6.8 of [RFC4271], with the following
modification:
For the purpose of collision resolution, the IPv6 BGP Identifier
carried in the capability (not the 4-byte BGP Identifier field in the
OPEN message, which is zero) is used as the BGP Identifier of the
peer. The local system MUST compare its own IPv6 BGP Identifier with
that of the remote peer. Each IPv6 BGP Identifier SHALL be
interpreted as a 128-bit unsigned integer in host byte order. The
connection initiated by the BGP speaker with the numerically larger
IPv6 BGP Identifier MUST be retained.
Li & Song Expires 28 February 2027 [Page 6]
Internet-Draft BGP Capability for IPv6 BGP Identifier August 2026
If the OPEN message contains more than one IPv6 BGP Identifier, it
MUST be treated as malformed. The speaker MUST send a NOTIFICATION
message with Error Code 2 (OPEN Message Error) and Error Subcode 3
(Bad BGP Identifier) to its peer.
The format of the NOTIFICATION message follows the definition in
Section 4.5 of RFC [RFC4271].
4. Route Decision Process
4.1. Mixed iBGP Deployment Considerations
Within an iBGP autonomous system, if only a subset of BGP speakers
supports the IPv6 BGP Identifier capability, different speakers may
compute different best paths, since they interpret BGP-Identifier
values differently. This mismatch in best-path computation may
create forwarding loops.
It is RECOMMENDED that operators either enable this capability
uniformly across all iBGP speakers within an AS, or avoid using this
capability within that AS entirely. If mixed-mode deployment is
unavoidable, additional policy mechanisms MUST be applied by the
operator to mitigate inconsistent best-path selection and potential
forwarding loops. This extension itself does not resolve such
mixed-domain loop risks
4.2. Updated Tie-Breaking Procedure for BGP
For a BGP speaker that supports the IPv6 BGP Identifier, the same
route decision process defined in [RFC4271] applies, with the
following extension to step f of the Phase 2 tie-breaking procedure
specified in Section 9.1.2.2 of [RFC4271].
f) Remove from consideration all routes other than the route that was
advertised by the BGP speaker with the lowest BGP Identifier value.
Only routes advertised by peers using the same identifier type
(either traditional 4-octet BGP Identifier or IPv6 BGP Identifier)
are compared against each other using BGP Identifier tie-breaker.
Routes with different BGP Identifier types MUST NOT be compared
against each other on the basis of BGP Identifier tie-breaker.
When comparing multiple routes from peers advertising IPv6 BGP
Identifier, select the route with numerically smallest 128-bit IPv6
BGP Identifier.
Li & Song Expires 28 February 2027 [Page 7]
Internet-Draft BGP Capability for IPv6 BGP Identifier August 2026
5. IANA Considerations
IANA is requested to assign new code points from the "BGP Capability
Codes" registry for the following capability defined in this
document:
+============+=============+===============+
| Code Point | Description | Reference |
+============+=============+===============+
| TBD | IPv6 BGP ID | This document |
+------------+-------------+---------------+
Table 1: New BGP Capability for IPv6 BGP ID
6. Operational Considerations
The IPv6 BGP-Identifier capability does not modify the AGGREGATOR
path attribute. When a speaker using an IPv6 BGP Identifier
generates an AGGREGATOR attribute, it MUST follow existing rules from
[RFC4271]. An operator configured with IPv6-only deployment needs to
supply a 4-octet identifier value for use inside AGGREGATOR.
7. Security Considerations
The base BGP security considerations are discussed in [RFC4271].
Inconsistent deployment of the IPv6 BGP Identifier capability within
an iBGP autonomous system will cause different BGP speakers to
compute different best paths, based on differing interpretations of
the BGP Identifier used for tie-breaking. This mismatch may produce
forwarding loops. Operators need to account for this risk when
planning deployment. Uniform enablement or uniform disablement
across the iBGP domain is RECOMMENDED.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
Li & Song Expires 28 February 2027 [Page 8]
Internet-Draft BGP Capability for IPv6 BGP Identifier August 2026
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <https://www.rfc-editor.org/info/rfc5492>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
February 2011, <https://www.rfc-editor.org/info/rfc6119>.
[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP
Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286,
June 2011, <https://www.rfc-editor.org/info/rfc6286>.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, December 2023,
<https://www.rfc-editor.org/info/rfc9552>.
Acknowledgements
The authors would like to acknowledge the supports from Cheng Chang,
Bo Liu.
The authors would like to thank Jeffrey Haas for his extensive review
and suggestions to this document
The authors would like to thank Robert Raszuk for his comments on
this document in the IDR working group mail list
Authors' Addresses
Zhenqiang Li (editor)
China Mobile
China
Email: lizhenqiang@chinamobile.com
Li & Song Expires 28 February 2027 [Page 9]
Internet-Draft BGP Capability for IPv6 BGP Identifier August 2026
Guangchen Song (editor)
China Mobile
China
Email: songguangchenjc@chinamobile.com
Li & Song Expires 28 February 2027 [Page 10]