China Mobile

CN lizhenqiang@chinamobile.com

China Mobile

CN songguangchenjc@chinamobile.com

Routing Inter-Domain Routing BGP BGP Identifier Capability 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.

Introduction A router that runs the Border Gateway Protocol (BGP) 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. 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. 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. 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 and .

Potential Use Case It is about the interactions between BGP‑LS and IGPs that utilize IPv6‑style TE Router‑IDs . 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 , 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.

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 when, and only when, they appear in all capitals, as shown here.

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. specifies the format of the OPEN message as follows:

OPEN message

The Optional Parameters field, as shown below, contains a list of optional parameters.

Optional Parameters

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:

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.

Open Message Processing

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.

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 , 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. 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 .

Route Decision Process

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

Updated Tie-Breaking Procedure for BGP For a BGP speaker that supports the IPv6 BGP Identifier, the same route decision process defined in applies, with the following extension to step f of the Phase 2 tie‑breaking procedure specified in Section 9.1.2.2 of . 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.

IANA Considerations IANA is requested to assign new code points from the "BGP Capability Codes" registry for the following capability defined in this document: New BGP Capability for IPv6 BGP ID

Code Point	Description	Reference
TBD	IPv6 BGP ID	This document

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 . An operator configured with IPv6‑only deployment needs to supply a 4‑octet identifier value for use inside AGGREGATOR.

Security Considerations The base BGP security considerations are discussed in . 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.

References Normative References Informative References

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