1. Introduction (Introduzione)
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. (Multiprotocol BGP (MP-BGP) [RFC4760] specifica che l'insieme di protocolli del livello di rete a cui può appartenere l'indirizzo trasportato nel campo Next Hop Address è determinato dall'Address Family Identifier (AFI) e dal Subsequent Address Family Identifier (SAFI). Un certo numero di AFI/SAFI esistenti consente all'indirizzo next-hop di appartenere a una famiglia di indirizzi diversa rispetto alle Network Layer Reachability Information (NLRI). Ad esempio, l'AFI/SAFI <25/65> utilizzato (come da [RFC6074]) per eseguire l'auto-scoperta della Layer 2 Virtual Private Network (L2VPN) consente di pubblicizzare NLRI che contiene l'identificatore di un'istanza Virtual Private LAN Service (VPLS) o che identifica un particolare pool di circuiti di collegamento su un dato Provider Edge (PE), mentre il campo Next Hop Address contiene l'indirizzo di loopback di un PE. Allo stesso modo, l'AFI/SAFI <1/132> (definito in [RFC4684]) per pubblicizzare le informazioni sull'appartenenza al Route Target (RT) consente di pubblicizzare NLRI che contiene tali informazioni sull'appartenenza RT, mentre il campo Next Hop Address contiene l'indirizzo del router pubblicitario.)
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. (Inoltre, un certo numero di questi AFI/SAFI esistenti consente al next hop di appartenere al protocollo IPv4 o al protocollo IPv6 e specifica la codifica delle informazioni sul next hop per determinare a quale dei protocolli appartiene effettivamente l'indirizzo. Ad esempio, [RFC4684] consente all'indirizzo next-hop di essere un indirizzo IPv4 o IPv6 e afferma che il campo Next Hop Address deve essere interpretato come un indirizzo IPv4 ogni volta che la lunghezza dell'indirizzo next-hop è di 4 ottetti e come un indirizzo IPv6 ogni volta che la lunghezza dell'indirizzo next-hop è di 16 ottetti.)
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). (Ci sono situazioni come quelle descritte in [RFC4925] e [RFC5565] in cui i carrier (o le grandi reti aziendali che agiscono come carrier per le loro risorse interne) potrebbero dover stabilire la connettività tra 'isole' di reti di un tipo di famiglia di indirizzi attraverso un core di transito di un tipo di famiglia di indirizzi diverso. Ciò include sia il caso di isole IPv6 attraverso un core IPv4 sia il caso di isole IPv4 attraverso un core IPv6. Dove Multiprotocol BGP (MP-BGP) viene utilizzato per pubblicizzare le corrispondenti informazioni di raggiungibilità, ciò si traduce nel requisito per un BGP speaker di pubblicizzare le NLRI di una data famiglia di indirizzi tramite un next hop di una famiglia di indirizzi diversa (ovvero, IPv6 NLRI con un next hop IPv4 e IPv4 NLRI con un next hop IPv6).)
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. (Le definizioni AFI/SAFI per la famiglia di indirizzi IPv6 presuppongono che l'indirizzo next-hop appartenga al tipo di famiglia di indirizzi IPv6. In particolare, come da [RFC2545] e [RFC8277], quando l'<AFI/SAFI> è <2/1>, <2/2> o <2/4>, si presume che l'indirizzo next-hop sia di tipo IPv6. Come da [RFC4659], quando l'<AFI/SAFI> è <2/128>, si presume che l'indirizzo next-hop sia di tipo VPN-IPv6.)
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. (Tuttavia, [RFC4798] e [RFC4659] specificano come un indirizzo IPv4 può essere codificato all'interno del campo dell'indirizzo IPv6 next-hop quando IPv6 NLRI deve essere pubblicizzato con un next hop IPv4. [RFC4798] definisce come il formato dell'indirizzo IPv6 mappato IPv4 specificato nell'architettura di indirizzamento IPv6 ([RFC4291]) può essere utilizzato a tale scopo quando l'<AFI/SAFI> è <2/1>, <2/2> o <2/4>. [RFC4659] definisce come il formato dell'indirizzo IPv6 mappato IPv4 e un Route Distinguisher (RD) nullo possono essere utilizzati a tale scopo quando l'<AFI/SAFI> è <2/128>. Pertanto, esistono soluzioni esistenti per la pubblicità di IPv6 NLRI con un next hop IPv4.)
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. (Allo stesso modo, le definizioni AFI/SAFI per la pubblicità di IPv4 NLRI o VPN-IPv4 NLRI presuppongono che l'indirizzo next-hop appartenga al tipo di famiglia di indirizzi IPv4. In particolare, come da [RFC4760] e [RFC8277], quando l'<AFI/SAFI> è <1/1>, <1/2> o <1/4>, si presume che l'indirizzo next-hop sia di tipo IPv4. Come da [RFC4364], quando l'<AFI/SAFI> è <1/128>, si presume che l'indirizzo next-hop sia di tipo VPN-IPv4. Come da [RFC6513] e [RFC6514], quando l'<AFI/SAFI> è <1/129>, si presume che l'indirizzo next-hop sia di tipo VPN-IPv4. Non esiste chiaramente alcun metodo generalmente applicabile per codificare un indirizzo IPv6 all'interno del campo dell'indirizzo IPv4 del next hop. Pertanto, al momento non esiste alcuna soluzione specificata per pubblicizzare IPv4 o VPN-IPv4 NLRI con un next hop IPv6.)
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. (Questo documento specifica le estensioni necessarie per consentire la pubblicità di IPv4 NLRI o VPN-IPv4 NLRI con un indirizzo next-hop che appartiene al protocollo IPv6. Ciò comprende un'estensione delle definizioni AFI/SAFI per consentire all'indirizzo del next hop per IPv4 NLRI o VPN-IPv4 NLRI di appartenere al protocollo IPv4 o al protocollo IPv6, la codifica delle informazioni sul next hop per determinare a quale dei protocolli appartiene effettivamente l'indirizzo e una capacità BGP che consente ai peer MP-BGP di scoprire dinamicamente se possono scambiare IPv4 NLRI e VPN-IPv4 NLRI con un next hop IPv6. La capacità BGP consente l'implementazione graduale della funzionalità di pubblicità della raggiungibilità IPv4 tramite un next hop IPv6 senza alcun flag day né alcun rischio di black-holing del traffico.)
This document obsoletes [RFC5549]. (Questo documento rende obsoleto [RFC5549].)
1.1. Requirements Language (Linguaggio dei requisiti)
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. (Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.)