1. Introduction (Einführung)
Multiprotocol BGP (MP-BGP) [RFC4760] specifies that the set of network-layer protocols to which the address carried in the Next Hop Address field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). A number of existing AFIs/SAFIs allow the next-hop address to belong to a different address family than the Network Layer Reachability Information (NLRI). For example, the AFI/SAFI <25/65> used (as per [RFC6074]) to perform Layer 2 Virtual Private Network (L2VPN) auto-discovery allows advertising NLRI that contains the identifier of a Virtual Private LAN Service (VPLS) instance or that identifies a particular pool of attachment circuits at a given Provider Edge (PE), while the Next Hop Address field contains the loopback address of a PE. Similarly, the AFI/SAFI <1/132> (defined in [RFC4684]) to advertise Route Target (RT) membership information allows advertising NLRI that contains such RT membership information, while the Next Hop Address field contains the address of the advertising router. (Multiprotokoll-BGP (MP-BGP) [RFC4760] gibt an, dass der Satz von Netzwerkschichtprotokollen, zu denen die im Feld Next Hop Address übertragene Adresse gehören kann, durch den Address Family Identifier (AFI) und den Subsequent Address Family Identifier (SAFI) bestimmt wird. Eine Reihe bestehender AFIs/SAFIs ermöglichen es, dass die Next-Hop-Adresse zu einer anderen Adressfamilie gehört als die Network Layer Reachability Information (NLRI). Zum Beispiel ermöglicht der AFI/SAFI <25/65>, der (gemäß [RFC6074]) zur Durchführung der Layer 2 Virtual Private Network (L2VPN)-Auto-Erkennung verwendet wird, die Werbung für NLRI, die die Kennung einer Virtual Private LAN Service (VPLS)-Instanz enthält oder die einen bestimmten Pool von Anhangsschaltungen an einem bestimmten Provider Edge (PE) identifiziert, während das Feld Next Hop Address die Loopback-Adresse eines PE enthält. Ebenso ermöglicht der AFI/SAFI <1/132> (definiert in [RFC4684]) zur Werbung für Route Target (RT)-Mitgliedschaftsinformationen die Werbung für NLRI, die solche RT-Mitgliedschaftsinformationen enthalten, während das Feld Next Hop Address die Adresse des werbenden Routers enthält.)
Furthermore, a number of these existing AFIs/SAFIs allow the next hop to belong to either the IPv4 protocol or the IPv6 protocol and specify the encoding of the next-hop information to determine which of the protocols the address actually belongs to. For example, [RFC4684] allows the next-hop address to be either an IPv4 or IPv6 address and states that the Next Hop Address field shall be interpreted as an IPv4 address whenever the length of the next-hop address is 4 octets and as an IPv6 address whenever the length of the next-hop address is 16 octets. (Darüber hinaus erlauben eine Reihe dieser vorhandenen AFIs/SAFIs, dass der nächste Hop entweder zum IPv4-Protokoll oder zum IPv6-Protokoll gehört, und geben die Codierung der Next-Hop-Informationen an, um zu bestimmen, zu welchem der Protokolle die Adresse tatsächlich gehört. Zum Beispiel ermöglicht [RFC4684], dass die Next-Hop-Adresse entweder eine IPv4- oder eine IPv6-Adresse ist, und gibt an, dass das Feld Next Hop Address als IPv4-Adresse interpretiert wird, wenn die Länge der Next-Hop-Adresse 4 Oktette beträgt, und als IPv6-Adresse, wenn die Länge der Next-Hop-Adresse 16 Oktette beträgt.)
There are situations such as those described in [RFC4925] and [RFC5565] where carriers (or large enterprise networks acting as a carrier for their internal resources) may be required to establish connectivity between 'islands' of networks of one address family type across a transit core of a differing address family type. This includes both the case of IPv6 islands across an IPv4 core and the case of IPv4 islands across an IPv6 core. Where Multiprotocol BGP (MP-BGP) is used to advertise the corresponding reachability information, this translates into the requirement for a BGP speaker to advertise the NLRI of a given address family via a next hop of a different address family (i.e., IPv6 NLRI with an IPv4 next hop and IPv4 NLRI with an IPv6 next hop). (Es gibt Situationen, wie sie in [RFC4925] und [RFC5565] beschrieben sind, in denen Carrier (oder große Unternehmensnetzwerke, die als Carrier für ihre internen Ressourcen fungieren) möglicherweise Konnektivität zwischen "Inseln" von Netzwerken eines Adressfamilie-Typs über einen Transit-Core eines anderen Adressfamilie-Typs herstellen müssen. Dies umfasst sowohl den Fall von IPv6-Inseln über einen IPv4-Core als auch den Fall von IPv4-Inseln über einen IPv6-Core. Wenn Multiprotokoll-BGP (MP-BGP) verwendet wird, um die entsprechenden Erreichbarkeitsinformationen zu bewerben, führt dies zu der Anforderung an einen BGP-Sprecher, die NLRI einer bestimmten Adressfamilie über einen nächsten Hop einer anderen Adressfamilie zu bewerben (d. h. IPv6 NLRI mit einem IPv4 Next Hop und IPv4 NLRI mit einem IPv6 Next Hop).)
The AFI/SAFI definitions for the IPv6 address family assume that the next-hop address belongs to the IPv6 address family type. Specifically, as per [RFC2545] and [RFC8277], when the <AFI/SAFI> is <2/1>, <2/2>, or <2/4>, the next-hop address is assumed to be of an IPv6 type. As per [RFC4659], when the <AFI/SAFI> is <2/128>, the next-hop address is assumed to be of a VPN-IPv6 type. (Die AFI/SAFI-Definitionen für die IPv6-Adressfamilie gehen davon aus, dass die Next-Hop-Adresse zum IPv6-Adressfamilie-Typ gehört. Insbesondere gemäß [RFC2545] und [RFC8277] wird angenommen, dass die Next-Hop-Adresse vom IPv6-Typ ist, wenn <AFI/SAFI> <2/1>, <2/2> oder <2/4> ist. Gemäß [RFC4659] wird angenommen, dass die Next-Hop-Adresse vom VPN-IPv6-Typ ist, wenn <AFI/SAFI> <2/128> ist.)
However, [RFC4798] and [RFC4659] specify how an IPv4 address can be encoded inside the next-hop IPv6 address field when IPv6 NLRI needs to be advertised with an IPv4 next hop. [RFC4798] defines how the IPv4-mapped IPv6 address format specified in the IPv6 addressing architecture ([RFC4291]) can be used for that purpose when the <AFI/SAFI> is <2/1>, <2/2>, or <2/4>. [RFC4659] defines how the IPv4-mapped IPv6 address format as well as a null Route Distinguisher (RD) can be used for that purpose when the <AFI/SAFI> is <2/128>. Thus, there are existing solutions for the advertisement of IPv6 NLRI with an IPv4 next hop. (Allerdings spezifizieren [RFC4798] und [RFC4659], wie eine IPv4-Adresse im Next-Hop-IPv6-Adressfeld codiert werden kann, wenn IPv6 NLRI mit einem IPv4 Next Hop beworben werden muss. [RFC4798] definiert, wie das in der IPv6-Adressierungsarchitektur ([RFC4291]) spezifizierte IPv4-gemappte IPv6-Adressformat für diesen Zweck verwendet werden kann, wenn <AFI/SAFI> <2/1>, <2/2> oder <2/4> ist. [RFC4659] definiert, wie das IPv4-gemappte IPv6-Adressformat sowie ein Null Route Distinguisher (RD) für diesen Zweck verwendet werden können, wenn <AFI/SAFI> <2/128> ist. Somit gibt es bestehende Lösungen für die Werbung von IPv6 NLRI mit einem IPv4 Next Hop.)
Similarly, the AFI/SAFI definitions for the advertisement of IPv4 NLRI or VPN-IPv4 NLRI assume that the next-hop address belongs to the IPv4 address family type. Specifically, as per [RFC4760] and [RFC8277], when the <AFI/SAFI> is <1/1>, <1/2>, or <1/4>, the next-hop address is assumed to be of an IPv4 type. As per [RFC4364], when the <AFI/SAFI> is <1/128>, the next-hop address is assumed to be of a VPN-IPv4 type. As per [RFC6513] and [RFC6514], when the <AFI/SAFI> is <1/129>, the next-hop address is assumed to be of a VPN-IPv4 type. There is clearly no generally applicable method for encoding an IPv6 address inside the IPv4 address field of the next hop. Hence, there is currently no specified solution for advertising IPv4 or VPN-IPv4 NLRI with an IPv6 next hop. (Ebenso gehen die AFI/SAFI-Definitionen für die Werbung von IPv4 NLRI oder VPN-IPv4 NLRI davon aus, dass die Next-Hop-Adresse zum IPv4-Adressfamilie-Typ gehört. Insbesondere gemäß [RFC4760] und [RFC8277] wird angenommen, dass die Next-Hop-Adresse vom IPv4-Typ ist, wenn <AFI/SAFI> <1/1>, <1/2> oder <1/4> ist. Gemäß [RFC4364] wird angenommen, dass die Next-Hop-Adresse vom VPN-IPv4-Typ ist, wenn <AFI/SAFI> <1/128> ist. Gemäß [RFC6513] und [RFC6514] wird angenommen, dass die Next-Hop-Adresse vom VPN-IPv4-Typ ist, wenn <AFI/SAFI> <1/129> ist. Es gibt eindeutig keine allgemein anwendbare Methode zum Codieren einer IPv6-Adresse im IPv4-Adressfeld des nächsten Hops. Daher gibt es derzeit keine spezifizierte Lösung für die Werbung von IPv4 oder VPN-IPv4 NLRI mit einem IPv6 Next Hop.)
This document specifies the extensions necessary to allow advertisement of IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the next hop for IPv4 NLRI or VPN-IPv4 NLRI to belong to either the IPv4 or the IPv6 protocol, the encoding of the next-hop information to determine which of the protocols the address actually belongs to, and a BGP Capability allowing MP-BGP peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 next hop. The BGP Capability allows gradual deployment of the functionality of advertising IPv4 reachability via an IPv6 next hop without any flag day nor any risk of traffic black-holing. (Dieses Dokument spezifiziert die Erweiterungen, die erforderlich sind, um die Werbung von IPv4 NLRI oder VPN-IPv4 NLRI mit einer Next-Hop-Adresse zu ermöglichen, die zum IPv6-Protokoll gehört. Dies umfasst eine Erweiterung der AFI/SAFI-Definitionen, damit die Adresse des nächsten Hops für IPv4 NLRI oder VPN-IPv4 NLRI entweder zum IPv4- oder zum IPv6-Protokoll gehören kann, die Codierung der Next-Hop-Informationen, um zu bestimmen, zu welchem der Protokolle die Adresse tatsächlich gehört, und eine BGP-Fähigkeit, die es MP-BGP-Peers ermöglicht, dynamisch zu entdecken, ob sie IPv4 NLRI und VPN-IPv4 NLRI mit einem IPv6 Next Hop austauschen können. Die BGP-Fähigkeit ermöglicht die schrittweise Bereitstellung der Funktionalität der Werbung für IPv4-Erreichbarkeit über einen IPv6 Next Hop ohne Flag Day und ohne Risiko von Traffic-Black-Holing.)
This document obsoletes [RFC5549]. (Dieses Dokument ersetzt [RFC5549].)
1.1. Requirements Language (Anforderungssprache)
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. (Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in BCP 14 [RFC2119] [RFC8174] beschrieben, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.)