doc: Add RFC documents

1 files changed, 639 insertions, 0 deletions

diff --git a/doc/rfc/rfc8950.txt b/doc/rfc/rfc8950.txt
new file mode 100644
index 0000000..28e9cf9
--- /dev/null
+++ b/doc/rfc/rfc8950.txt
@@ -0,0 +1,639 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                      S. Litkowski
+Request for Comments: 8950                                    S. Agrawal
+Obsoletes: 5549                                         K. Ananthamurthy
+Category: Standards Track                                          Cisco
+ISSN: 2070-1721                                                 K. Patel
+                                                                  Arrcus
+                                                           November 2020
+
+
+ Advertising IPv4 Network Layer Reachability Information (NLRI) with an
+                             IPv6 Next Hop
+
+Abstract
+
+   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
+   https://www.rfc-editor.org/info/rfc8950.
+
+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
+   (https://trustee.ietf.org/license-info) 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
+
+   1.  Introduction
+     1.1.  Requirements Language
+   2.  Changes Compared to RFC 5549
+   3.  Extension of AFI/SAFI Definitions for the IPv4 Address Family
+   4.  Use of BGP Capability Advertisement
+   5.  Operations
+   6.  Usage Examples
+     6.1.  IPv4 over IPv6 Core
+     6.2.  IPv4 VPN Unicast over IPv6 Core
+     6.3.  IPv4 VPN Multicast over IPv6 Core
+   7.  IANA Considerations
+   8.  Security Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   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.
+
+   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.
+
+   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).
+
+   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.
+
+   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.
+
+   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.
+
+   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 [RFC5549].
+
+1.1.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  Changes Compared to RFC 5549
+
+   This document introduces two significant changes compared to
+   [RFC5549]:
+
+   *  In [RFC5549], 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 3 and 6.2).  This change addresses Erratum ID 5253
+      ([Err5253]).  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 3 and 6.3).
+
+3.  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 [RFC4760] 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 Section 3 of [RFC2545].
+
+   *  NLRI = NLRI as per the AFI/SAFI definition
+
+   It also allows advertising the MP_REACH_NLRI attribute [RFC4760] 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 [RFC4684] and [RFC6074].
+
+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].
+
+5.  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.
+
+6.  Usage Examples
+
+6.1.  IPv4 over IPv6 Core
+
+   The extensions defined in this document may be used as discussed in
+   [RFC5565] for the interconnection of IPv4 islands over an IPv6
+   backbone.  In this application, Address Family Border Routers (AFBRs;
+   as defined in [RFC4925]) 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>
+
+6.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>
+
+6.3.  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>
+
+7.  IANA Considerations
+
+   This document does not define any new code points from those included
+   in [RFC5549].
+
+   [RFC5549] added "Extended Next Hop Encoding" to the "Capability
+   Codes" registry ([IANA-CAP-CODE]), which was created by [RFC5492].
+   IANA has updated the registration of that entry to refer to this
+   document.  The value allocated for this Capability Code is 5.
+
+8.  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 [RFC4272] 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 [RFC4291]).  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.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2545]  Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
+              Extensions for IPv6 Inter-Domain Routing", RFC 2545,
+              DOI 10.17487/RFC2545, March 1999,
+              <https://www.rfc-editor.org/info/rfc2545>.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
+              2006, <https://www.rfc-editor.org/info/rfc4291>.
+
+   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
+              2006, <https://www.rfc-editor.org/info/rfc4364>.
+
+   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
+              "Multiprotocol Extensions for BGP-4", RFC 4760,
+              DOI 10.17487/RFC4760, January 2007,
+              <https://www.rfc-editor.org/info/rfc4760>.
+
+   [RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement
+              with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
+              2009, <https://www.rfc-editor.org/info/rfc5492>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8277]  Rosen, E., "Using BGP to Bind MPLS Labels to Address
+              Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
+              <https://www.rfc-editor.org/info/rfc8277>.
+
+9.2.  Informative References
+
+   [Err5253]  RFC Errata, Erratum ID 5253, RFC 5549,
+              <https://www.rfc-editor.org/errata/eid5253>.
+
+   [IANA-AFI] IANA, "Address Family Numbers",
+              <https://www.iana.org/assignments/address-family-
+              numbers/>.
+
+   [IANA-CAP-CODE]
+              IANA, "Capability Codes",
+              <https://www.iana.org/assignments/capability-codes/>.
+
+   [IANA-SAFI]
+              IANA, "Subsequent Address Family Identifiers (SAFI)
+              Parameters",
+              <https://www.iana.org/assignments/safi-namespace/>.
+
+   [RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis",
+              RFC 4272, DOI 10.17487/RFC4272, January 2006,
+              <https://www.rfc-editor.org/info/rfc4272>.
+
+   [RFC4659]  De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
+              "BGP-MPLS IP Virtual Private Network (VPN) Extension for
+              IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
+              <https://www.rfc-editor.org/info/rfc4659>.
+
+   [RFC4684]  Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
+              R., Patel, K., and J. Guichard, "Constrained Route
+              Distribution for Border Gateway Protocol/MultiProtocol
+              Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
+              Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
+              November 2006, <https://www.rfc-editor.org/info/rfc4684>.
+
+   [RFC4798]  De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
+              "Connecting IPv6 Islands over IPv4 MPLS Using IPv6
+              Provider Edge Routers (6PE)", RFC 4798,
+              DOI 10.17487/RFC4798, February 2007,
+              <https://www.rfc-editor.org/info/rfc4798>.
+
+   [RFC4925]  Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A.
+              Durand, Ed., "Softwire Problem Statement", RFC 4925,
+              DOI 10.17487/RFC4925, July 2007,
+              <https://www.rfc-editor.org/info/rfc4925>.
+
+   [RFC5549]  Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
+              Layer Reachability Information with an IPv6 Next Hop",
+              RFC 5549, DOI 10.17487/RFC5549, May 2009,
+              <https://www.rfc-editor.org/info/rfc5549>.
+
+   [RFC5565]  Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
+              Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009,
+              <https://www.rfc-editor.org/info/rfc5565>.
+
+   [RFC6074]  Rosen, E., Davie, B., Radoaca, V., and W. Luo,
+              "Provisioning, Auto-Discovery, and Signaling in Layer 2
+              Virtual Private Networks (L2VPNs)", RFC 6074,
+              DOI 10.17487/RFC6074, January 2011,
+              <https://www.rfc-editor.org/info/rfc6074>.
+
+   [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
+              BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
+              2012, <https://www.rfc-editor.org/info/rfc6513>.
+
+   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
+              Encodings and Procedures for Multicast in MPLS/BGP IP
+              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
+              <https://www.rfc-editor.org/info/rfc6514>.
+
+Acknowledgments
+
+   The authors would like to thank Francois Le Faucheur and Eric Rosen
+   for their work on [RFC5549].
+
+   The authors would like to thank Yakov Rekhter, Pranav Mehta, and John
+   Scudder for their contributions to the approach defined in [RFC5549].
+
+Authors' Addresses
+
+   Stephane Litkowski
+   Cisco
+
+   Email: slitkows@cisco.com
+
+
+   Swadesh Agrawal
+   Cisco
+
+   Email: swaagraw@cisco.com
+
+
+   Krishna Muddenahally Ananthamurthy
+   Cisco
+
+   Email: kriswamy@cisco.com
+
+
+   Keyur Patel
+   Arrcus
+
+   Email: keyur@arrcus.com