Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop
obsoletes
- rfc-5549 — Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop
Extracted elements (22)
New AFI/SAFIs defined in the future are expected to include provisions for both IPv4 and IPv6 next hops from the outset (using Length of Next Hop Address field determination), making the Extended Next Hop Encoding capability unnecessary for them.
The BGP Capability Advertisement mechanism allows gradual deployment of IPv4-over-IPv6-next-hop functionality without a flag day and without risk of traffic black-holing, since speakers only use the feature with peers that have confirmed support.
The method of using the Length of Next Hop Address field to determine the network-layer protocol of the next hop (rather than a flag or type field) follows the same approach used in RFC 4684 and RFC 6074, providing consistency across AFI/SAFI definitions.
RFC 8950 changes the VPN-IPv4 (AFI/SAFI <1/128>) next-hop encoding from a plain IPv6 address of 16 or 32 bytes (as in RFC 5549) to a VPN-IPv6 address of 24 or 48 bytes with an 8-octet zero RD prefix, addressing Erratum ID 5253 on RFC 5549 and aligning with existing deployed implementations.
For Route Reflector scenarios, all RR clients must be capable of handling whatever next-hop encodings any of them may generate; if a client cannot handle a given encoding (as determined by Capability Advertisement), the corresponding NLRI cannot be distributed to that client.
RFC 8950 extends VPN-IPv4 multicast (AFI/SAFI <1/129>) to support IPv6 underlay using the same encoding and procedures as VPN-IPv4 unicast (<1/128>); this capability was not present in RFC 5549.
The Extended Next Hop Encoding capability is not intended for AFI/SAFIs whose definitions already allow both IPv4 and IPv6 next hops (e.g., <1/132> per RFC 4684) or for which a different-family next-hop solution already exists (e.g., <2/1>, <2/2>, <2/4> with IPv4 next hop per RFC 4798).
A BGP speaker MUST only advertise IPv4 or VPN-IPv4 NLRI with an IPv6 next hop to a BGP peer if the BGP speaker has first ascertained via BGP Capability Advertisement that the peer supports the Extended Next Hop Encoding capability for the relevant AFI/SAFI pair.
A BGP speaker receiving an advertisement MUST use the Length of Next Hop Address field to determine which network-layer protocol the next-hop address belongs to. For AFI/SAFI <1/1>, <1/2>, or <1/4>, length 16 or 32 indicates IPv6; for AFI/SAFI <1/128> or <1/129>, length 24 or 48 indicates VPN-IPv6.
A BGP speaker that wishes to advertise an IPv6 next hop for IPv4 NLRI or VPN-IPv4 NLRI MUST use the Capability Advertisement procedures defined in RFC 5492 with the Extended Next Hop Encoding capability to determine whether its peer supports this for the relevant AFI/SAFI pair(s).
By default, if a BGP session is running over IPvx and the BGP speaker is putting its own address in as the next hop, the next-hop address SHOULD be specified as an IPvx address using the encoding rules of the AFI/SAFI definition. This default may be overridden by policy.
The Capability Code field in the Extended Next Hop Encoding capability advertisement MUST be set to 5.
When a next-hop address needs to be passed along unchanged (e.g., by a Route Reflector), its encoding MUST NOT be changed. If a particular RR client cannot handle that encoding, the NLRI in question cannot be distributed to that client.
The Extended Next Hop Encoding capability (Capability Code 5, defined in RFC 5492) allows BGP speakers to dynamically discover whether, for a given NLRI AFI/SAFI, a peer supports advertisement with a next hop whose network protocol is determined by the Length of Next Hop Address field.
The Extended Next Hop Encoding capability conveys next-hop encoding information for a given AFI/SAFI but does not influence whether that AFI/SAFI is allowed between peers; that is determined solely by the Multiprotocol Extensions capability (RFC 4760).
This document restricts valid Extended Next Hop Encoding capability values to: NLRI AFI=1 (IPv4), NLRI SAFI in {1, 2, 4, 128, 129}, Nexthop AFI=2 (IPv6). Other combinations are not specified by this document.
RFC 5549 added 'Extended Next Hop Encoding' with value 5 to the IANA 'Capability Codes' registry. RFC 8950 updates that registry entry to reference this document instead of RFC 5549.
The ability to advertise an IPv6 next hop adds a new means by which an attacker could cause traffic to be diverted. Traffic could be forwarded across an intervening IPv6 core to a distant target, potentially making a traffic-hijacking or denial-of-service attack easier to mount than with preexisting BGP vulnerabilities.
The IPv6 address used as the BGP next-hop could be an IPv4-mapped IPv6 address (RFC 4291). Security mechanisms such as next-hop address checks deployed by network operators must account for this case.
For AFI=1, SAFI=1/2/4 with an IPv6 next hop: the MP_REACH_NLRI Length of Next Hop Address field is 16 (single global IPv6 address) or 32 (global plus link-local IPv6 address), encoded as per RFC 2545 Section 3.
For AFI=1, SAFI=128/129 (VPN-IPv4) with an IPv6 next hop: the MP_REACH_NLRI Length of Next Hop Address field is 24 or 48, encoding a VPN-IPv6 address with an 8-octet Route Distinguisher set to zero, optionally followed by a second VPN-IPv6 link-local address also with zero RD.
The Extended Next Hop Encoding capability value consists of one or more triples: NLRI AFI (2 octets), NLRI SAFI (2 octets), Nexthop AFI (2 octets). Each triple indicates that NLRI of <NLRI AFI/SAFI> may be advertised with a next-hop address of the Nexthop AFI protocol.