4. Use of BGP Capability Advertisement
[RFC5492] defines a mechanism to allow two BGP speakers to discover if a particular capability is supported by their BGP peer and, thus, whether it can be used with that peer. This document defines a capability that can be advertised using [RFC5492], referred to as the "Extended Next Hop Encoding capability". This capability allows BGP speakers to discover whether, for a given NLRI <AFI/SAFI>, a peer supports advertisement with a next hop whose network protocol is determined by the value of the Length of Next Hop Address field, as specified in Section 3.
A BGP speaker that wishes to advertise an IPv6 next hop for IPv4 NLRI or for VPN-IPv4 NLRI to a BGP peer as per this specification MUST use the Capability Advertisement procedures defined in [RFC5492] with the Extended Next Hop Encoding capability to determine whether its peer supports this for the NLRI AFI/SAFI pair(s) of interest. The fields in the Capabilities Optional Parameter MUST be set as follows:
-
The Capability Code field MUST be set to 5 (which indicates the Extended Next Hop Encoding capability).
-
The Capability Length field is set to a variable value that is the length of the Capability Value field (which follows).
-
The Capability Value field has the following format:
+-----------------------------------------------------+
| NLRI AFI - 1 (2 octets) |
+-----------------------------------------------------+
| NLRI SAFI - 1 (2 octets) |
+-----------------------------------------------------+
| Nexthop AFI - 1 (2 octets) |
+-----------------------------------------------------+
| ..... |
+-----------------------------------------------------+
| NLRI AFI - N (2 octets) |
+-----------------------------------------------------+
| NLRI SAFI - N (2 octets) |
+-----------------------------------------------------+
| Nexthop AFI - N (2 octets) |
+-----------------------------------------------------+
where:
-
each triple <NLRI AFI, NLRI SAFI, Nexthop AFI> indicates that the NLRI of <NLRI AFI / NLRI SAFI> may be advertised with a next-hop address belonging to the network-layer protocol of Nexthop AFI.
-
the AFI and SAFI values are defined in the "Address Family Numbers" and "Subsequent Address Family Identifier (SAFI) Parameters" registries (see [IANA-AFI] and [IANA-SAFI], respectively).
Since this document only concerns itself with the advertisement of IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 next hop, this specification only allows the following values in the Capability Value field of the Extended Next Hop Encoding capability:
-
NLRI AFI = 1 (IPv4)
-
NLRI SAFI = 1, 2, 4, 128, or 129
-
Nexthop AFI = 2 (IPv6)
This document does not specify the use of the Extended Next Hop Encoding capability with any other combinations of <NLRI AFI, NLRI SAFI, Nexthop AFI>. For example, the Next Hop Encoding capability specified in this document is not intended to be used for NLRI AFIs/SAFIs whose definition already allows use of both IPv4 and IPv6 next hops (e.g., AFI/SAFI = <1/132> as defined in [RFC4684]). Similarly, it is not intended that the Extended Next Hop Encoding capability be used for NLRI AFIs/SAFIs for which there is already a solution for advertising a next hop of a different address family (e.g., AFI/SAFI = <2/1>, <2/2>, or <2/4> with an IPv4 next hop as per [RFC4798] and AFI/SAFI = <2/128> with an IPv4 next hop as per [RFC4659]).
It is expected that if new AFIs/SAFIs are defined in the future, their definitions will have provisions (where appropriate) for both IPv4 and IPv6 next hops from the beginning, with the determination based on the Length of Next Hop Address field. Thus, new AFIs/SAFIs are not expected to make use of the Extended Next Hop Encoding capability.
A BGP speaker MUST only advertise the IPv4 or VPN-IPv4 NLRI with an IPv6 next hop to a BGP peer if the BGP speaker has first ascertained via the BGP Capability Advertisement that the BGP peer supports the Extended Next Hop Encoding capability for the relevant AFI/SAFI pair.
The Extended Next Hop Encoding capability provides information about next-hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is allowed. It does not influence whether that AFI/SAFI is indeed allowed. Whether an AFI/SAFI can be used between the BGP peers is purely determined through the Multiprotocol Extensions capability defined in [RFC4760].