Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next HopCiscoslitkows@cisco.comCiscoswaagraw@cisco.comCiscokriswamy@cisco.comArrcuskeyur@arrcus.comBESS Working Groupbgpmvpnvpnv4vpnv6
Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families
is determined by the Address Family Identifier (AFI) and the
Subsequent Address Family Identifier (SAFI). The AFI/SAFI
definitions for the IPv4 address family only have provisions for
advertising a next-hop address that belongs to the IPv4 protocol when
advertising IPv4 Network Layer Reachability Information (NLRI) or
VPN-IPv4 NLRI.
This document specifies the extensions necessary to
allow the advertising 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 also belong to the IPv6 protocol, the
encoding of the next hop 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. This document obsoletes RFC 5549.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction
. Requirements Language
. Changes Compared to RFC 5549
. Extension of AFI/SAFI Definitions for the IPv4 Address Family
. Use of BGP Capability Advertisement
. Operations
. Usage Examples
. IPv4 over IPv6 Core
. IPv4 VPN Unicast over IPv6 Core
. IPv4 VPN Multicast over IPv6 Core
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgments
Authors' Addresses
Introduction
Multiprotocol BGP (MP-BGP) 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
) 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 ) 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.
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, 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.
There are situations such as those described in and 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).
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 and , 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 , when the <AFI/SAFI> is <2/128>, the next-hop
address is assumed to be of a VPN-IPv6 type.
However, and
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. defines how the
IPv4-mapped IPv6 address format specified in the IPv6 addressing
architecture () can be
used for that purpose when the <AFI/SAFI> is <2/1>,
<2/2>, or <2/4>. 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.
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 and
, 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 , when
the <AFI/SAFI> is <1/128>, the next-hop address is assumed to
be of a VPN-IPv4 type. As per and , 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.
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.
This document obsoletes .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.
Changes Compared to RFC 5549This document introduces two significant changes compared to :
In , when AFI/SAFI <1/128>
is used, the next-hop address is encoded as an IPv6 address with a
length of 16 or 32 bytes. To accommodate all existing implementations
and bring consistency with VPNv4oIPv4 and VPNv6oIPv6, this document
modifies how the next-hop address is encoded. The next-hop address is
now encoded as a VPN-IPv6 address with a length of 24 or 48 bytes
(see Sections and ). This change
addresses Erratum ID 5253 ().
As all known and deployed implementations are interoperable today and use the new proposed encoding, the change does not break existing interoperability.
This document allows AFI/SAFI <1/129> (IPv4 multicast) to use an
IPv6 underlay using similar encoding and procedures to AFI/SAFI
<1/128> (see Sections and ).
Extension of AFI/SAFI Definitions for the IPv4 Address Family
As mentioned earlier, MP-BGP specifies that the set of usable next-hop address families
is determined by the AFI and the SAFI. The following
AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 NLRI (<1/1>,
<1/2>, <1/4>, <1/128>, and <1/129>) only have provisions for advertising a
next-hop address that belongs to the IPv4 protocol.
This document
extends the set of usable next-hop address families to include IPv6 in addition to
IPv4 when advertising an IPv4 or VPN-IPv4 NLRI.
Specifically, this document allows advertising the MP_REACH_NLRI attribute with this content:
AFI = 1
SAFI = 1, 2, or 4
Length of Next Hop Address = 16 or 32
Next Hop Address = IPv6 address of a next hop (potentially followed
by the link-local IPv6 address of the next hop). This field is to
be constructed as per .
NLRI = NLRI as per the AFI/SAFI definition
It also allows advertising the MP_REACH_NLRI attribute with this content:
AFI = 1
SAFI = 128 or 129
Length of Next Hop Address = 24 or 48
Next Hop Address = VPN-IPv6 address of a next hop with an 8-octet RD set to zero (potentially followed
by the link-local VPN-IPv6 address of the next hop with an 8-octet RD set to zero).
NLRI = NLRI as per the AFI/SAFI definition
This is in addition to the existing mode of operation allowing
advertisement of NLRI for <AFI/SAFI> of <1/1>, <1/2>, and <1/4> with a
next-hop address of an IPv4 type and advertisement of NLRI for an
<AFI/SAFI> of <1/128> and <1/129> with a next-hop address
of a VPN-IPv4 type.
The BGP speaker receiving the advertisement MUST use the Length of
Next Hop Address field to determine which network-layer protocol the
next-hop address belongs to.
When the AFI/SAFI is <1/1>, <1/2>, or <1/4>
and when the Length of Next Hop Address
field is equal to 16 or 32, the next-hop address is of type IPv6.
When the AFI/SAFI is <1/128> or <1/129>
and when the Length of Next Hop Address
field is equal to 24 or 48, the next-hop address is of type VPN-IPv6.
Note that this method of using the Length of Next Hop Address
field to determine which network-layer protocol the next-hop address
belongs to (out of the set of protocols allowed by the AFI/SAFI
definition) is the same as that used in and .
Use of BGP Capability Advertisement 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 , 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 .
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 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 and , 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 ).
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
and AFI/SAFI = <2/128> with
an IPv4 next hop as per
).
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 .
Operations
By default, if a particular BGP session is running over IPvx (where
IPvx is IPv4 or IPv6) and if the BGP speaker sending an update is
putting its own address in as the next hop, then the next-hop address
SHOULD be specified as an IPvx address, using the encoding rules
specified in the AFI/SAFI definition of the NLRI being updated. This
default behavior may be overridden by policy.
When a next-hop address needs to be passed along unchanged (e.g., as
a Route Reflector (RR) would do), its encoding MUST NOT be changed.
If a particular RR client cannot handle that encoding (as determined
by the BGP Capability Advertisement), then the NLRI in question
cannot be distributed to that client. For sound routing in certain
scenarios, this will require that all the RR clients be able to
handle whatever encodings any of them may generate.
Usage ExamplesIPv4 over IPv6 Core
The extensions defined in this document may be used as discussed in
for the interconnection of IPv4 islands over an IPv6
backbone. In this application, Address Family Border Routers (AFBRs;
as defined in ) advertise IPv4 NLRI in the MP_REACH_NLRI
along with an IPv6 next hop.
The MP_REACH_NLRI is encoded with:
AFI = 1
SAFI = 1
Length of Next Hop Address field = 16 (or 32)
Next Hop Address = IPv6 address of the next hop
NLRI = IPv4 routes
During BGP Capability Advertisement, the PE routers would include the following fields in the Capabilities Optional Parameter:
Capability Code set to "Extended Next Hop Encoding"
Capability Value containing <NLRI AFI=1, NLRI SAFI=1, Nexthop
AFI=2>
IPv4 VPN Unicast over IPv6 Core
The extensions defined in this document may be used for support of
IPv4 VPNs over an IPv6 backbone. In this application, PE routers
would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6
next hop.
The MP_REACH_NLRI is encoded with:
AFI = 1
SAFI = 128
Length of Next Hop Address field = 24 (or 48)
Next Hop Address = VPN-IPv6 address of a next hop whose RD is set to zero
NLRI = IPv4-VPN routes
During BGP Capability Advertisement, the PE routers would include the
following fields in the Capabilities Optional Parameter:
Capability Code set to "Extended Next Hop Encoding"
Capability Value containing <NLRI AFI=1, NLRI SAFI=128, Nexthop
AFI=2>
IPv4 VPN Multicast over IPv6 Core
The extensions defined in this document may be used for support of
IPv4 multicast VPNs over an IPv6 backbone. In this application, PE routers
would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6
next hop.
The MP_REACH_NLRI is encoded with:
AFI = 1
SAFI = 129
Length of Next Hop Address field = 24 (or 48)
Next Hop Address = VPN-IPv6 address of a next hop whose RD is set to zero
NLRI = IPv4-VPN routes
During BGP Capability Advertisement, the PE routers would include the
following fields in the Capabilities Optional Parameter:
Capability Code set to "Extended Next Hop Encoding"
Capability Value containing <NLRI AFI=1, NLRI SAFI=129, Nexthop
AFI=2>
IANA ConsiderationsThis document does not define any new code points from those
included in . added "Extended
Next Hop Encoding" to the "Capability Codes" registry (), which was created by .
IANA has updated the registration of that entry to refer to this document. The value allocated for this Capability
Code is 5.Security Considerations
This document does not raise any additional security issues beyond
those of BGP-4 and the Multiprotocol Extensions for BGP-4. The same
security mechanisms are applicable.
However, as discusses, BGP is vulnerable to traffic diversion attacks.
The ability to advertise an IPv6 next hop adds a new means by which an
attacker could cause traffic to be diverted from its normal path. Such an
attack differs from preexisting vulnerabilities in that traffic could be
forwarded to a distant target across an intervening network infrastructure
(e.g., an IPv6 core), allowing an attack to potentially succeed more
easily since less infrastructure would have to be subverted. Potential
consequences include "hijacking" of traffic or denial of service.
Although not expected to be the typical case, the IPv6 address used
as the BGP next-hop address could be an IPv4-mapped IPv6 address (as
defined in ). Configuration of the security mechanisms
potentially deployed by the network operator (such as security checks
on a next-hop address) also need to keep this case in mind.
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain RoutingBGP-4 Multiprotocol Extensions (BGP-MP) defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. [STANDARDS-TRACK]IP Version 6 Addressing ArchitectureThis specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]BGP/MPLS IP Virtual Private Networks (VPNs)This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]Multiprotocol Extensions for BGP-4This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]Capabilities Advertisement with BGP-4This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.This document obsoletes RFC 3392. [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Using BGP to Bind MPLS Labels to Address PrefixesThis document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107.Informative ReferencesErratum ID 5253RFC ErrataRFC 5549Address Family NumbersIANACapability CodesIANASubsequent Address Family Identifiers (SAFI) ParametersIANABGP Security Vulnerabilities AnalysisBorder Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior.This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets. This memo provides information for the Internet community.BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPNThis document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method for support of IPv6. In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4 VPN routes over the service provider backbone, and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in "Multiprotocol BGP".This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and for using various tunneling techniques over the core, including MPLS, IP-in-IP, Generic Routing Encapsulation (GRE) and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. [STANDARDS-TRACK]Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information. This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN) Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system. This document updates RFC 4364. [STANDARDS-TRACK]Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)This document explains how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud. This approach relies on IPv6 Provider Edge routers (6PE), which are Dual Stack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 reachability information transparently over the core using the Multiprotocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration. [STANDARDS-TRACK]Softwire Problem StatementThis document captures the problem statement for the Softwires Working Group, which is developing standards for the discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks as well as IPv6 networks across IPv4-only networks. The standards will encourage multiple, inter-operable vendor implementations by identifying, and extending where necessary, existing standard protocols to resolve a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved by the standards developed by the Softwires Working Group. Some requirements (and non-requirements) are also identified to better describe the specific problem scope. This memo provides information for the Internet community.Advertising IPv4 Network Layer Reachability Information with an IPv6 Next HopMultiprotocol BGP (MP-BGP) specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising 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 also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. [STANDARDS-TRACK]Softwire Mesh FrameworkThe Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single-protocol" networks. One kind of single-protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single-protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single-protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol. The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology. [STANDARDS-TRACK]Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of pseudowires (PWs) that form the (virtual) backbone of the L2VPN. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP), and the Layer 2 Tunneling Protocol version 3 (L2TPv3). [STANDARDS- TRACK]Multicast in MPLS/BGP IP VPNsIn order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK]BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNsThis document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK]AcknowledgmentsThe authors would like to thank and for their work on .
The authors would like to thank , , and for their contributions to the approach defined in .
Authors' AddressesCiscoslitkows@cisco.comCiscoswaagraw@cisco.comCiscokriswamy@cisco.comArrcuskeyur@arrcus.com