doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc7439.txt b/doc/rfc/rfc7439.txt
new file mode 100644
index 0000000..93a7a0c
--- /dev/null
+++ b/doc/rfc/rfc7439.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    W. George, Ed.
+Request for Comments: 7439                             Time Warner Cable
+Category: Informational                                C. Pignataro, Ed.
+ISSN: 2070-1721                                                    Cisco
+                                                            January 2015
+
+
+           Gap Analysis for Operating IPv6-Only MPLS Networks
+
+Abstract
+
+   This document reviews the Multiprotocol Label Switching (MPLS)
+   protocol suite in the context of IPv6 and identifies gaps that must
+   be addressed in order to allow MPLS-related protocols and
+   applications to be used with IPv6-only networks.  This document is
+   intended to focus on gaps in the standards defining the MPLS suite,
+   and is not intended to highlight particular vendor implementations
+   (or lack thereof) in the context of IPv6-only MPLS functionality.
+
+   In the data plane, MPLS fully supports IPv6, and MPLS labeled packets
+   can be carried over IPv6 packets in a variety of encapsulations.
+   However, support for IPv6 among MPLS control-plane protocols, MPLS
+   applications, MPLS Operations, Administration, and Maintenance (OAM),
+   and MIB modules is mixed, with some protocols having major gaps.  For
+   most major gaps, work is in progress to upgrade the relevant
+   protocols.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7439.
+
+
+
+
+
+
+
+
+
+George & Pignataro            Informational                     [Page 1]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 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
+   (http://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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+George & Pignataro            Informational                     [Page 2]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  Use Case  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .   5
+     3.1.  MPLS Data Plane . . . . . . . . . . . . . . . . . . . . .   6
+     3.2.  MPLS Control Plane  . . . . . . . . . . . . . . . . . . .   6
+       3.2.1.  Label Distribution Protocol (LDP) . . . . . . . . . .   6
+       3.2.2.  Multipoint LDP (mLDP) . . . . . . . . . . . . . . . .   6
+       3.2.3.  RSVP - Traffic Engineering (RSVP-TE)  . . . . . . . .   7
+         3.2.3.1.  Interior Gateway Protocol (IGP) . . . . . . . . .   8
+         3.2.3.2.  RSVP-TE Point-to-Multipoint (P2MP)  . . . . . . .   8
+         3.2.3.3.  RSVP-TE Fast Reroute (FRR)  . . . . . . . . . . .   8
+       3.2.4.  Path Computation Element (PCE)  . . . . . . . . . . .   8
+       3.2.5.  Border Gateway Protocol (BGP) . . . . . . . . . . . .   9
+       3.2.6.  Generalized Multi-Protocol Label Switching (GMPLS)  .   9
+     3.3.  MPLS Applications . . . . . . . . . . . . . . . . . . . .   9
+       3.3.1.  Layer 2 Virtual Private Network (L2VPN) . . . . . . .   9
+         3.3.1.1.  Ethernet VPN (EVPN) . . . . . . . . . . . . . . .  10
+       3.3.2.  Layer 3 Virtual Private Network (L3VPN) . . . . . . .  10
+         3.3.2.1.  IPv6 Provider Edge/IPv4 Provider Edge (6PE/4PE) .  11
+         3.3.2.2.  IPv6 Virtual Private Extension/IPv4 Virtual
+                   Private Extension (6VPE/4VPE) . . . . . . . . . .  11
+         3.3.2.3.  BGP Encapsulation Subsequent Address Family
+                   Identifier (SAFI) . . . . . . . . . . . . . . . .  12
+         3.3.2.4.  Multicast in MPLS/BGP IP VPN (MVPN) . . . . . . .  12
+       3.3.3.  MPLS Transport Profile (MPLS-TP)  . . . . . . . . . .  13
+     3.4.  MPLS Operations, Administration, and Maintenance (MPLS
+           OAM)  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
+       3.4.1.  Extended ICMP . . . . . . . . . . . . . . . . . . . .  14
+       3.4.2.  Label Switched Path Ping (LSP Ping) . . . . . . . . .  15
+       3.4.3.  Bidirectional Forwarding Detection (BFD)  . . . . . .  16
+       3.4.4.  Pseudowire OAM  . . . . . . . . . . . . . . . . . . .  16
+       3.4.5.  MPLS Transport Profile (MPLS-TP) OAM  . . . . . . . .  16
+     3.5.  MIB Modules . . . . . . . . . . . . . . . . . . . . . . .  17
+   4.  Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . .  17
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
+     6.2.  Informative References  . . . . . . . . . . . . . . . . .  20
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  26
+   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  26
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28
+
+
+
+
+
+
+
+
+George & Pignataro            Informational                     [Page 3]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+1.  Introduction
+
+   IPv6 [RFC2460] is an integral part of modern network deployments.  At
+   the time when this document was written, the majority of these IPv6
+   deployments were using dual-stack implementations, where IPv4 and
+   IPv6 are supported equally on many or all of the network nodes, and
+   single-stack primarily referred to IPv4-only devices.  Dual-stack
+   deployments provide a useful margin for protocols and features that
+   are not currently capable of operating solely over IPv6, because they
+   can continue using IPv4 as necessary.  However, as IPv6 deployment
+   and usage becomes more pervasive, and IPv4 exhaustion begins driving
+   changes in address consumption behaviors, there is an increasing
+   likelihood that many networks will need to start operating some or
+   all of their network nodes either as primarily IPv6 (most functions
+   use IPv6, a few legacy features use IPv4), or as IPv6-only (no IPv4
+   provisioned on the device).  This transition toward IPv6-only
+   operation exposes any gaps where features, protocols, or
+   implementations are still reliant on IPv4 for proper function.  To
+   that end, and in the spirit of the recommendation in RFC 6540
+   [RFC6540] that implementations need to stop requiring IPv4 for proper
+   and complete function, this document reviews the MPLS protocol suite
+   in the context of IPv6 and identifies gaps that must be addressed in
+   order to allow MPLS-related protocols and applications to be used
+   with IPv6-only networks and networks that are primarily IPv6
+   (hereafter referred to as IPv6-primary).  This document is intended
+   to focus on gaps in the standards defining the MPLS suite, and not to
+   highlight particular vendor implementations (or lack thereof) in the
+   context of IPv6-only MPLS functionality.
+
+2.  Use Case
+
+   This section discusses some drivers for ensuring that MPLS completely
+   supports IPv6-only operation.  It is not intended to be a
+   comprehensive discussion of all potential use cases, but rather a
+   discussion of one use case to provide context and justification to
+   undertake such a gap analysis.
+
+   IP convergence is continuing to drive new classes of devices to begin
+   communicating via IP.  Examples of such devices could include set-top
+   boxes for IP video distribution, cell tower electronics (macro or
+   micro cells), infrastructure Wi-Fi access points, and devices for
+   machine-to-machine (M2M) or Internet of Things (IoT) applications.
+   In some cases, these classes of devices represent a very large
+   deployment base, on the order of thousands or even millions of
+   devices network-wide.  The scale of these networks, coupled with the
+   increasingly overlapping use of RFC 1918 [RFC1918] address space
+   within the average network and the lack of globally routable IPv4
+   space available for long-term growth, begins to drive the need for
+
+
+
+George & Pignataro            Informational                     [Page 4]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   many of the endpoints in this network to be managed solely via IPv6.
+   Even if these devices are carrying some IPv4 user data, it is often
+   encapsulated in another protocol such that the communication between
+   the endpoint and its upstream devices can be IPv6-only without
+   impacting support for IPv4 on user data.  As the number of devices to
+   manage increases, the operator is compelled to move to IPv6.
+   Depending on the MPLS features required, it is plausible to assume
+   that the (existing) MPLS network will need to be extended to these
+   IPv6-only devices.
+
+   Additionally, as the impact of IPv4 exhaustion becomes more acute,
+   more and more aggressive IPv4 address reclamation measures will be
+   justified.  Many networks are likely to focus on preserving their
+   remaining IPv4 addresses for revenue-generating customers so that
+   legacy support for IPv4 can be maintained as long as necessary.  As a
+   result, it may be appropriate for some or all of the network
+   infrastructure, including MPLS Label Switching Routers (LSRs) and
+   Label Edge Routers (LERs), to have its IPv4 addresses reclaimed and
+   transition toward IPv6-only operation.
+
+3.  Gap Analysis
+
+   This gap analysis aims to answer the question of what fails when one
+   attempts to use MPLS features on a network of IPv6-only devices.  The
+   baseline assumption for this analysis is that some endpoints, as well
+   as Label Switching Routers (Provider Edge (PE) and Provider (P)
+   routers), only have IPv6 transport available and need to support the
+   full suite of MPLS features defined as of the time of this document's
+   writing at parity with the support on an IPv4 network.  This is
+   necessary whether they are enabled via the Label Distribution
+   Protocol (LDP) [RFC5036], RSVP - Traffic Engineering (RSVP-TE)
+   [RFC3209], or Border Gateway Protocol (BGP) [RFC3107], and whether
+   they are encapsulated in MPLS [RFC3032], IP [RFC4023], Generic
+   Routing Encapsulation (GRE) [RFC4023], or Layer 2 Tunneling Protocol
+   Version 3 (L2TPv3) [RFC4817].  It is important when evaluating these
+   gaps to distinguish between user data and control-plane data, because
+   while this document is focused on IPv6-only operation, it is quite
+   likely that some amount of the user payload data being carried in the
+   IPv6-only MPLS network will still be IPv4.
+
+   A note about terminology: Gaps identified by this document are
+   characterized as "Major" or "Minor".  Major gaps refer to significant
+   changes necessary in one or more standards to address the gap due to
+   existing standards language having either missing functionality for
+   IPv6-only operation or explicit language requiring the use of IPv4
+   with no IPv6 alternatives defined.  Minor gaps refer to changes
+   necessary primarily to clarify existing standards language.  Usually
+
+
+
+
+George & Pignataro            Informational                     [Page 5]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   these changes are needed in order to explicitly codify IPv6 support
+   in places where it is either implicit or omitted today, but the
+   omission is unlikely to prevent IPv6-only operation.
+
+3.1.  MPLS Data Plane
+
+   MPLS labeled packets can be transmitted over a variety of data links
+   [RFC3032], and MPLS labeled packets can also be encapsulated over IP.
+   The encapsulations of MPLS in IP and GRE, as well as MPLS over
+   L2TPv3, support IPv6.  See Section 3 of RFC 4023 [RFC4023] and
+   Section 2 of RFC 4817 [RFC4817], respectively.
+
+   Gap: None.
+
+3.2.  MPLS Control Plane
+
+3.2.1.  Label Distribution Protocol (LDP)
+
+   The Label Distribution Protocol (LDP) [RFC5036] defines a set of
+   procedures for distribution of labels between Label Switching Routers
+   that can use the labels for forwarding traffic.  While LDP was
+   designed to use an IPv4 or dual-stack IP network, it has a number of
+   deficiencies that prevent it from working in an IPv6-only network.
+   LDP-IPv6 [LDP-IPv6] highlights some of the deficiencies when LDP is
+   enabled in IPv6-only or dual-stack networks and specifies appropriate
+   protocol changes.  These deficiencies are related to Label Switched
+   Path (LSP) mapping, LDP identifiers, LDP discovery, LDP session
+   establishment, next-hop address, and LDP Time To Live (TTL) security
+   [RFC5082] [RFC6720].
+
+   Gap: Major; update to RFC 5036 in progress via [LDP-IPv6], which
+   should close this gap.
+
+3.2.2.  Multipoint LDP (mLDP)
+
+   Multipoint LDP (mLDP) is a set of extensions to LDP for setting up
+   Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) LSPs.
+   These extensions are specified in RFC 6388 [RFC6388].  In terms of
+   IPv6-only gap analysis, mLDP has two identified areas of interest:
+
+   1.  LDP Control Plane: Since mLDP uses the LDP control plane to
+       discover and establish sessions with the peer, it shares the same
+       gaps as LDP (Section 3.2.1) with regards to control plane
+       (discovery, transport, and session establishment) in an IPv6-only
+       network.
+
+
+
+
+
+
+George & Pignataro            Informational                     [Page 6]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   2.  Multipoint (MP) Forwarding Equivalence Class (FEC) Root Address:
+       mLDP defines its own MP FECs and rules, different from LDP, to
+       map MP LSPs.  An mLDP MP FEC contains a Root Address field that
+       is an IP address in IP networks.  The current specification
+       allows specifying the root address according to the Address
+       Family Identifier (AFI), and hence covers both IPv4 or IPv6 root
+       addresses, requiring no extension to support IPv6-only MP LSPs.
+       The root address is used by each LSR participating in an MP LSP
+       setup such that root address reachability is resolved by doing a
+       table lookup against the root address to find corresponding
+       upstream neighbor(s).  This will pose a problem if an MP LSP
+       traverses IPv4-only and IPv6-only nodes in a dual-stack network
+       on the way to the root node.
+
+   For example, consider following setup, where R1/R6 are IPv4-only, R3/
+   R4 are IPv6-only, and R2/R5 are dual-stack LSRs:
+
+   ( IPv4-only )  (  IPv6-only   )  ( IPv4-only )
+          R1 -- R2 -- R3 -- R4 -- R5 -- R6
+          Leaf                          Root
+
+   Assume R1 to be a leaf node for a P2MP LSP rooted at R6 (root node).
+   R1 uses R6's IPv4 address as the root address in MP FEC.  As the MP
+   LSP signaling proceeds from R1 to R6, the MP LSP setup will fail on
+   the first IPv6-only transit/branch LSRs (R3) when trying to find IPv4
+   root address reachability.  RFC 6512 [RFC6512] defines a recursive-
+   FEC solution and procedures for mLDP when the backbone (transit/
+   branch) LSRs have no route to the root.  The proposed solution is
+   defined for a BGP-free core in a VPN environment, but a similar
+   concept can be used/extended to solve the above issue of the
+   IPv6-only backbone receiving an MP FEC element with an IPv4 address.
+   The solution will require a border LSR (the one that is sitting on
+   the border of an IPv4/IPv6 island (namely, R2 and R5 in this
+   example)) to translate an IPv4 root address to an equivalent IPv6
+   address (and vice versa) through procedures similar to RFC 6512.
+
+   Gap: Major; update in progress for LDP via [LDP-IPv6], may need
+   additional updates to RFC 6512.
+
+3.2.3.  RSVP - Traffic Engineering (RSVP-TE)
+
+   RSVP-TE [RFC3209] defines a set of procedures and enhancements to
+   establish LSP tunnels that can be automatically routed away from
+   network failures, congestion, and bottlenecks.  RSVP-TE allows
+   establishing an LSP for an IPv4 or IPv6 prefix, thanks to its
+   LSP_TUNNEL_IPv6 object and subobjects.
+
+   Gap: None.
+
+
+
+George & Pignataro            Informational                     [Page 7]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+3.2.3.1.  Interior Gateway Protocol (IGP)
+
+   RFC 3630 [RFC3630] specifies a method of adding traffic engineering
+   capabilities to OSPF Version 2.  New TLVs and sub-TLVs were added in
+   RFC 5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF
+   Version 3.
+
+   RFC 5305 [RFC5305] specifies a method of adding traffic engineering
+   capabilities to IS-IS.  New TLVs and sub-TLVs were added in RFC 6119
+   [RFC6119] to extend TE capabilities to IPv6 networks.
+
+   Gap: None.
+
+3.2.3.2.  RSVP-TE Point-to-Multipoint (P2MP)
+
+   RFC 4875 [RFC4875] describes extensions to RSVP-TE for the setup of
+   Point-to-Multipoint (P2MP) LSPs in MPLS and Generalized MPLS (GMPLS)
+   with support for both IPv4 and IPv6.
+
+   Gap: None.
+
+3.2.3.3.  RSVP-TE Fast Reroute (FRR)
+
+   RFC 4090 [RFC4090] specifies Fast Reroute (FRR) mechanisms to
+   establish backup LSP tunnels for local repair supporting both IPv4
+   and IPv6 networks.  Further, [RFC5286] describes the use of loop-free
+   alternates to provide local protection for unicast traffic in pure IP
+   and MPLS networks in the event of a single failure, whether link,
+   node, or shared risk link group (SRLG) for both IPv4 and IPv6.
+
+   Gap: None.
+
+3.2.4.  Path Computation Element (PCE)
+
+   The Path Computation Element (PCE) defined in RFC 4655 [RFC4655] is
+   an entity that is capable of computing a network path or route based
+   on a network graph and applying computational constraints.  A Path
+   Computation Client (PCC) may make requests to a PCE for paths to be
+   computed.  The PCE Communication Protocol (PCEP) is designed as a
+   communication protocol between PCCs and PCEs for path computations
+   and is defined in RFC 5440 [RFC5440].
+
+   The PCEP specification [RFC5440] is defined for both IPv4 and IPv6
+   with support for PCE discovery via an IGP (OSPF [RFC5088] or IS-IS
+   [RFC5089]) using both IPv4 and IPv6 addresses.  Note that PCEP uses
+   identical encoding of subobjects, as in RSVP-TE defined in RFC 3209
+   [RFC3209] that supports both IPv4 and IPv6.
+
+
+
+
+George & Pignataro            Informational                     [Page 8]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   The extensions to PCEP to support confidentiality [RFC5520], route
+   exclusions [RFC5521], monitoring [RFC5886], and P2MP TE LSPs
+   [RFC6006] have support for both IPv4 and IPv6.
+
+   Gap: None.
+
+3.2.5.  Border Gateway Protocol (BGP)
+
+   RFC 3107 [RFC3107] specifies a set of BGP protocol procedures for
+   distributing the labels (for prefixes corresponding to any address
+   family) between label switch routers so that they can use the labels
+   for forwarding the traffic.  RFC 3107 allows BGP to distribute the
+   label for IPv4 or IPv6 prefix in an IPv6-only network.
+
+   Gap: None.
+
+3.2.6.  Generalized Multi-Protocol Label Switching (GMPLS)
+
+   The Generalized Multi-Protocol Label Switching (GMPLS) specification
+   includes signaling functional extensions [RFC3471] and RSVP-TE
+   extensions [RFC3473].  The gap analysis in Section 3.2.3 applies to
+   these.
+
+   RFC 4558 [RFC4558] specifies Node-ID Based RSVP Hello Messages with
+   capability for both IPv4 and IPv6.  RFC 4990 [RFC4990] clarifies the
+   use of IPv6 addresses in GMPLS networks including handling in the MIB
+   modules.
+
+   The second paragraph of Section 5.3 of RFC 6370 [RFC6370] describes
+   the mapping from an MPLS Transport Profile (MPLS-TP) LSP_ID to RSVP-
+   TE with an assumption that Node_IDs are derived from valid IPv4
+   addresses.  This assumption fails in an IPv6-only network, given that
+   there would not be any IPv4 addresses.
+
+   Gap: Minor; Section 5.3 of RFC 6370 [RFC6370] needs to be updated.
+
+3.3.  MPLS Applications
+
+3.3.1.  Layer 2 Virtual Private Network (L2VPN)
+
+   L2VPN [RFC4664] specifies two fundamentally different kinds of Layer
+   2 VPN services that a service provider could offer to a customer:
+   Virtual Private Wire Service (VPWS) and Virtual Private LAN Service
+   (VPLS).  RFC 4447 [RFC4447] and RFC 4762 [RFC4762] specify the LDP
+   protocol changes to instantiate VPWS and VPLS services, respectively,
+   in an MPLS network using LDP as the signaling protocol.  This is
+   complemented by RFC 6074 [RFC6074], which specifies a set of
+   procedures for instantiating L2VPNs (e.g., VPWS, VPLS) using BGP as a
+
+
+
+George & Pignataro            Informational                     [Page 9]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   discovery protocol and LDP, as well as L2TPv3, as a signaling
+   protocol.  RFC 4761 [RFC4761] and RFC 6624 [RFC6624] specify BGP
+   protocol changes to instantiate VPLS and VPWS services in an MPLS
+   network, using BGP for both discovery and signaling.
+
+   In an IPv6-only MPLS network, use of L2VPN represents a connection of
+   Layer 2 islands over an IPv6 MPLS core, and very few changes are
+   necessary to support operation over an IPv6-only network.  The L2VPN
+   signaling protocol is either BGP or LDP in an MPLS network, and both
+   can run directly over IPv6 core infrastructure as well as IPv6 edge
+   devices.  RFC 6074 [RFC6074] is the only RFC that appears to have a
+   gap for IPv6-only operation.  In its discovery procedures (Sections
+   3.2.2 and 6 of RFC 6074 [RFC6074]), it suggests encoding PE IP
+   addresses in the Virtual Switching Instance ID (VSI-ID), which is
+   encoded in Network Layer Reachability Information (NLRI) and should
+   not exceed 12 bytes (to differentiate its AFI/SAFI (Subsequent
+   Address Family Identifier) encoding from RFC 4761).  This means that
+   a PE IP address cannot be an IPv6 address.  Also, in its signaling
+   procedures (Section 3.2.3 of RFC 6074 [RFC6074]), it suggests
+   encoding PE_addr in the Source Attachment Individual Identifier
+   (SAII) and the Target Attachment Individual Identifier (TAII), which
+   are limited to 32 bits (AII Type=1) at the moment.
+
+   RFC 6073 [RFC6073] defines the new LDP Pseudowire (PW) Switching
+   Point PE TLV, which supports IPv4 and IPv6.
+
+   Gap: Minor; RFC 6074 needs to be updated.
+
+3.3.1.1.  Ethernet VPN (EVPN)
+
+   Ethernet VPN [EVPN] defines a method for using BGP MPLS-based
+   Ethernet VPNs.  Because it can use functions in LDP and mLDP, as well
+   as Multicast VPLS [RFC7117], it inherits LDP gaps previously
+   identified in Section 3.2.1.  Once those gaps are resolved, it should
+   function properly on IPv6-only networks as defined.
+
+   Gap: Major for LDP; update to RFC 5036 in progress via [LDP-IPv6]
+   that should close this gap (see Section 3.2.1).
+
+3.3.2.  Layer 3 Virtual Private Network (L3VPN)
+
+   RFC 4364 [RFC4364] defines a method by which a Service Provider may
+   use an IP backbone to provide IP VPNs for its customers.  The
+   following use cases arise in the context of this gap analysis:
+
+   1.  Connecting IPv6 islands over IPv6-only MPLS network
+
+   2.  Connecting IPv4 islands over IPv6-only MPLS network
+
+
+
+George & Pignataro            Informational                    [Page 10]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   Both use cases require mapping an IP packet to an IPv6-signaled LSP.
+   RFC 4364 defines Layer 3 Virtual Private Networks (L3VPNs) for
+   IPv4-only and has references to 32-bit BGP next-hop addresses.  RFC
+   4659 [RFC4659] adds support for IPv6 on L3VPNs, including 128-bit BGP
+   next-hop addresses, and discusses operation whether IPv6 is the
+   payload or the underlying transport address family.  However, RFC
+   4659 does not formally update RFC 4364, and thus an implementer may
+   miss this additional set of standards unless it is explicitly
+   identified independently of the base functionality defined in RFC
+   4364.  Further, Section 1 of RFC 4659 explicitly identifies use case
+   2 as out of scope for the document.
+
+   The authors do not believe that there are any additional issues
+   encountered when using L2TPv3, RSVP, or GRE (instead of MPLS) as
+   transport on an IPv6-only network.
+
+   Gap: Major; RFC 4659 needs to be updated to explicitly cover use case
+   2 (discussed in further detail below)
+
+3.3.2.1.  IPv6 Provider Edge/IPv4 Provider Edge (6PE/4PE)
+
+   RFC 4798 [RFC4798] defines IPv6 Provider Edge (6PE), which defines
+   how to interconnect IPv6 islands over a MPLS-enabled IPv4 cloud.
+   However, use case 2 is doing the opposite, and thus could also be
+   referred to as IPv4 Provider Edge (4PE).  The method to support this
+   use case is not defined explicitly.  To support it, IPv4 edge devices
+   need to be able to map IPv4 traffic to MPLS IPv6 core LSPs.  Also,
+   the core switches may not understand IPv4 at all, but in some cases
+   they may need to be able to exchange Labeled IPv4 routes from one
+   Autonomous System (AS) to a neighboring AS.
+
+   Gap: Major; RFC 4798 covers only the "6PE" case.  Use case 2 is
+   currently not specified in an RFC.
+
+3.3.2.2.  IPv6 Virtual Private Extension/IPv4 Virtual Private Extension
+          (6VPE/4VPE)
+
+   RFC 4659 [RFC4659] defines IPv6 Virtual Private Network Extension
+   (6VPE), a method by which a Service Provider may use its packet-
+   switched backbone to provide Virtual Private Network (VPN) services
+   for its IPv6 customers.  It allows the core network to be MPLS IPv4
+   or MPLS IPv6, thus addressing use case 1 above.  RFC 4364 should work
+   as defined for use case 2 above, which could also be referred to as
+   IPv4 Virtual Private Extension (4VPE), but the RFC explicitly does
+   not discuss this use and defines it as out of scope.
+
+   Gap: Minor; RFC 4659 needs to be updated to explicitly cover use case
+   2.
+
+
+
+George & Pignataro            Informational                    [Page 11]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+3.3.2.3.  BGP Encapsulation Subsequent Address Family Identifier (SAFI)
+
+   RFC 5512 [RFC5512] defines the BGP Encapsulation SAFI and the BGP
+   Tunnel Encapsulation Attribute, which can be used to signal tunneling
+   over an IP Core that is using a single address family.  This
+   mechanism supports transport of MPLS (and other protocols) over
+   Tunnels in an IP core (including an IPv6-only core).  In this
+   context, load balancing can be provided as specified in RFC 5640
+   [RFC5640].
+
+   Gap: None.
+
+3.3.2.4.  Multicast in MPLS/BGP IP VPN (MVPN)
+
+   RFC 6513 [RFC6513] defines the procedure to provide multicast service
+   over an MPLS VPN backbone for downstream customers.  It is sometimes
+   referred to as Next Generation Multicast VPN (NG-MVPN) The procedure
+   involves the below set of protocols.
+
+3.3.2.4.1.  PE-CE Multicast Routing Protocol
+
+   RFC 6513 [RFC6513] explains the use of Protocol Independent Multicast
+   (PIM) as a Provider Edge - Customer Edge (PE-CE) protocol, while
+   Section 11.1.2 of RFC 6514 [RFC6514] explains the use of mLDP as a
+   PE-CE protocol.
+
+   The MCAST-VPN NLRI route-type format defined in RFC 6514 [RFC6514] is
+   not sufficiently covering all scenarios when mLDP is used as a PE-CE
+   protocol.  The issue is explained in Section 2 of [mLDP-NLRI] along
+   with a new route type that encodes the mLDP FEC in NLRI.
+
+   Further, [PE-CE] defines the use of BGP as a PE-CE protocol.
+
+   Gap: None.
+
+3.3.2.4.2.  P-Tunnel Instantiation
+
+   [RFC6513] explains the use of the below tunnels:
+
+   o  RSVP-TE P2MP LSP
+
+   o  PIM Tree
+
+   o  mLDP P2MP LSP
+
+   o  mLDP MP2MP LSP
+
+   o  Ingress Replication
+
+
+
+George & Pignataro            Informational                    [Page 12]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   Gap: Gaps in RSVP-TE P2MP LSP (Section 3.2.3.2) and mLDP
+   (Section 3.2.2) P2MP and MP2MP LSP are covered in previous sections.
+   There are no MPLS-specific gaps for PIM Tree or Ingress Replication,
+   and any protocol-specific gaps not related to MPLS are outside the
+   scope of this document.
+
+3.3.2.4.3.  PE-PE Multicast Routing Protocol
+
+   Section 3.1 of RFC 6513 [RFC6513] explains the use of PIM as a PE-PE
+   protocol, while RFC 6514 [RFC6514] explains the use of BGP as a PE-PE
+   protocol.
+
+   PE-PE multicast routing is not specific to P-tunnels or to MPLS.  It
+   can be PIM or BGP with P-tunnels that are label based or PIM tree
+   based.  Enabling PIM as a PE-PE multicast protocol is equivalent to
+   running it on a non-MPLS IPv6 network, so there are not any MPLS-
+   specific considerations and any gaps are applicable for non-MPLS
+   networks as well.  Similarly, BGP only includes the P-Multicast
+   Service Interface (PMSI) tunnel attribute as a part of the NLRI,
+   which is inherited from P-tunnel instantiation and considered to be
+   an opaque value.  Any gaps in the control plane (PIM or BGP) will not
+   be specific to MPLS.
+
+   Gap: Any gaps in PIM or BGP as a PE-PE multicast routing protocol are
+   not unique to MPLS, and therefore are outside the scope of this
+   document.  It is included for completeness.
+
+3.3.3.  MPLS Transport Profile (MPLS-TP)
+
+   MPLS-TP does not require IP (see Section 2 of RFC 5921 [RFC5921]) and
+   should not be affected by operation on an IPv6-only network.
+   Therefore, this is considered out of scope for this document but is
+   included for completeness.
+
+   Although not required, MPLS-TP can use IP.  One such example is
+   included in Section 3.2.6, where MPLS-TP identifiers can be derived
+   from valid IPv4 addresses.
+
+   Gap: None.  MPLS-TP does not require IP.
+
+3.4.  MPLS Operations, Administration, and Maintenance (MPLS OAM)
+
+   For MPLS LSPs, there are primarily three OAM mechanisms: Extended
+   ICMP [RFC4884] [RFC4950], LSP Ping [RFC4379], and Bidirectional
+   Forwarding Detection (BFD) for MPLS LSPs [RFC5884].  For MPLS
+   Pseudowires, there is also Virtual Circuit Connectivity Verification
+   (VCCV) [RFC5085] [RFC5885].  Most of these mechanisms work in pure
+
+
+
+
+George & Pignataro            Informational                    [Page 13]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   IPv6 environments, but there are some problems encountered in mixed
+   environments due to address-family mismatches.  The next subsections
+   cover these gaps in detail.
+
+   Gap: Major; RFC 4379 needs to be updated to better support multipath
+   IPv6.  Additionally, there is potential for dropped messages in
+   Extended ICMP and LSP Ping due to IP version mismatches.  It is
+   important to note that this is a more generic problem with tunneling
+   when address-family mismatches exist and is not specific to MPLS.
+   While MPLS will be affected, it will be difficult to fix this problem
+   specifically for MPLS, rather than fixing the more generic problem.
+
+3.4.1.  Extended ICMP
+
+   Extended ICMP to support Multi-part messages is defined in RFC 4884
+   [RFC4884].  This extensibility is defined generally for both ICMPv4
+   and ICMPv6.  The specific ICMP extensions for MPLS are defined in RFC
+   4950 [RFC4950].  ICMP Multi-part with MPLS extensions works for IPv4
+   and IPv6.  However, the mechanisms described in RFC 4884 and 4950 may
+   fail when tunneling IPv4 traffic over an LSP that is supported by an
+   IPv6-only infrastructure.
+
+   Assume the following:
+
+   o  The path between two IPv4-only hosts contains an MPLS LSP.
+
+   o  The two routers that terminate the LSP run dual stack.
+
+   o  The LSP interior routers run IPv6 only.
+
+   o  The LSP is signaled over IPv6.
+
+   Now assume that one of the hosts sends an IPv4 packet to the other.
+   However, the packet's TTL expires on an LSP interior router.
+   According to RFC 3032 [RFC3032], the interior router should examine
+   the IPv4 payload, format an ICMPv4 message, and send it (over the
+   tunnel upon which the original packet arrived) to the egress LSP.  In
+   this case, however, the LSP interior router is not IPv4-aware.  It
+   cannot parse the original IPv4 datagram, nor can it send an IPv4
+   message.  So, no ICMP message is delivered to the source.  Some
+   specific ICMP extensions, in particular, ICMP extensions for
+   interface and next-hop identification [RFC5837], restrict the address
+   family of address information included in an Interface Information
+   Object to the same one as the ICMP (see Section 4.5 of RFC 5837).
+   While these extensions are not MPLS specific, they can be used with
+   MPLS packets carrying IP datagrams.  This has no implications for
+   IPv6-only environments.
+
+
+
+
+George & Pignataro            Informational                    [Page 14]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   Gap: Major; IP version mismatches may cause dropped messages.
+   However, as noted in the previous section, this problem is not
+   specific to MPLS.
+
+3.4.2.  Label Switched Path Ping (LSP Ping)
+
+   The LSP Ping mechanism defined in RFC 4379 [RFC4379] is specified to
+   work with IPv6.  Specifically, the Target FEC Stacks include both
+   IPv4 and IPv6 versions of all FECs (see Section 3.2 of RFC 4379).
+   The only exceptions are the Pseudowire FECs, which are later
+   specified for IPv6 in RFC 6829 [RFC6829].  The multipath information
+   also includes IPv6 encodings (see Section 3.3.1 of RFC 4379).
+
+   LSP Ping packets are UDP packets over either IPv4 or IPv6 (see
+   Section 4.3 of RFC 4379).  However, for IPv6 the destination IP
+   address is a (randomly chosen) IPv6 address from the range
+   0:0:0:0:0:FFFF:127/104; that is, using an IPv4-mapped IPv6 address.
+   This is a transitional mechanism that should not bleed into IPv6-only
+   networks, as [IPv4-MAPPED] explains.  The issue is that the MPLS LSP
+   Ping mechanism needs a range of loopback IP addresses to be used as
+   destination addresses to exercise Equal Cost Multiple Path (ECMP),
+   but the IPv6 address architecture specifies a single address
+   (::1/128) for loopback.  A mechanism to achieve this was proposed in
+   [LOOPBACK-PREFIX].
+
+   Additionally, RFC 4379 does not define the value to be used in the
+   IPv6 Router Alert option (RAO).  For IPv4 RAO, a value of zero is
+   used.  However, there is no equivalent value for IPv6 RAO.  This gap
+   needs to be fixed to be able to use LSP Ping in IPv6 networks.
+   Further details on this gap are captured, along with a proposed
+   solution, in [IPv6-RAO].
+
+   Another gap is that the mechanisms described in RFC 4379 may fail
+   when tunneling IPv4 traffic over an LSP that is supported by
+   IPv6-only infrastructure.
+
+   Assume the following:
+
+   o  LSP Ping is operating in traceroute mode over an MPLS LSP.
+
+   o  The two routers that terminate the LSP run dual stack.
+
+   o  The LSP interior routers run IPv6 only.
+
+   o  The LSP is signaled over IPv6.
+
+
+
+
+
+
+George & Pignataro            Informational                    [Page 15]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   Packets will expire at LSP interior routers.  According to RFC 4379,
+   the interior router must parse the IPv4 Echo Request and then send an
+   IPv4 Echo Reply.  However, the LSP interior router is not IPv4-aware.
+   It cannot parse the IPv4 Echo Request, nor can it send an IPv4 Echo
+   Reply.  So, no reply is sent.
+
+   The mechanism described in RFC 4379 also does not sufficiently
+   explain the behavior in certain IPv6-specific scenarios.  For
+   example, RFC 4379 defines the K value as 28 octets when the Address
+   Family is set to IPv6 Unnumbered, but it doesn't describe how to
+   carry a 32-bit LSR Router ID in the 128-bit Downstream IP Address
+   field.
+
+   Gap: Major; LSP Ping uses IPv4-mapped IPv6 addresses.  IP version
+   mismatches may cause dropped messages and unclear mapping from the
+   LSR Router ID to Downstream IP Address.
+
+3.4.3.  Bidirectional Forwarding Detection (BFD)
+
+   The BFD specification for MPLS LSPs [RFC5884] is defined for IPv4, as
+   well as IPv6, versions of MPLS FECs (see Section 3.1 of RFC 5884).
+   Additionally, the BFD packet is encapsulated over UDP and specified
+   to run over both IPv4 and IPv6 (see Section 7 of RFC 5884).
+
+   Gap: None.
+
+3.4.4.  Pseudowire OAM
+
+   The OAM specifications for MPLS Pseudowires define usage for both
+   IPv4 and IPv6.  Specifically, VCCV [RFC5085] can carry IPv4 or IPv6
+   OAM packets (see Sections 5.1.1 and 5.2.1 of RFC 5085), and VCCV for
+   BFD [RFC5885] also defines an IPv6 encapsulation (see Section 3.2 of
+   RFC 5885).
+
+   Additionally, for LSP Ping for pseudowires, the Pseudowire FECs are
+   specified for IPv6 in RFC 6829 [RFC6829].
+
+   Gap: None.
+
+3.4.5.  MPLS Transport Profile (MPLS-TP) OAM
+
+   As with MPLS-TP, MPLS-TP OAM [RFC6371] does not require IP or
+   existing MPLS OAM functions and should not be affected by operation
+   on an IPv6-only network.  Therefore, this is out of scope for this
+   document but is included for completeness.  Although not required,
+   MPLS-TP can use IP.
+
+   Gap: None.  MPLS-TP OAM does not require IP.
+
+
+
+George & Pignataro            Informational                    [Page 16]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+3.5.  MIB Modules
+
+   RFC 3811 [RFC3811] defines the textual conventions for MPLS.  These
+   lack support for IPv6 in defining MplsExtendedTunnelId and
+   MplsLsrIdentifier.  These textual conventions are used in the MPLS-TE
+   MIB specification [RFC3812], the GMPLS-TE MIB specification [RFC4802]
+   and the FRR extension [RFC6445].  "Definitions of Textual Conventions
+   (TCs) for Multiprotocol Label Switching (MPLS) Management" [MPLS-TC]
+   tries to resolve this gap by marking this textual convention as
+   obsolete.
+
+   The other MIB specifications for LSR [RFC3813], LDP [RFC3815], and TE
+   [RFC4220] have support for both IPv4 and IPv6.
+
+   Lastly, RFC 4990 [RFC4990] discusses how to handle IPv6 sources and
+   destinations in the MPLS and GMPLS-TE MIB modules.  In particular,
+   Section 8 of RFC 4990 [RFC4990] describes a method of defining or
+   monitoring an LSP tunnel using the MPLS-TE and GMPLS-TE MIB modules,
+   working around some of the limitations in RFC 3811 [RFC3811].
+
+   Gap: Minor; Section 8 of RFC 4990 [RFC4990] describes a method to
+   handle IPv6 addresses in the MPLS-TE [RFC3812] and GMPLS-TE [RFC4802]
+   MIB modules.  Work underway to update RFC 3811 via [MPLS-TC], may
+   also need to update RFC 3812, RFC 4802, and RFC 6445, which depend on
+   it.
+
+4.  Gap Summary
+
+   This document has reviewed a wide variety of MPLS features and
+   protocols to determine their suitability for use on IPv6-only or
+   IPv6-primary networks.  While some parts of the MPLS suite will
+   function properly without additional changes, gaps have been
+   identified in others that will need to be addressed with follow-on
+   work.  This section will summarize those gaps, along with pointers to
+   any work in progress to address them.  Note that because the
+   referenced documents are works in progress and do not have consensus
+   at the time of this document's publication, there could be other
+   solutions proposed at a future time, and the pointers in this
+   document should not be considered normative in any way.
+   Additionally, work in progress on new features that use MPLS
+   protocols will need to ensure that those protocols support operation
+   on IPv6-only or IPv6-primary networks, or explicitly identify any
+   dependencies on existing gaps that, once resolved, will allow proper
+   IPv6-only operation.
+
+
+
+
+
+
+
+George & Pignataro            Informational                    [Page 17]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+              Identified Gaps in MPLS for IPv6-Only Networks
+
+   +---------+---------------------------------------+-----------------+
+   |   Item  |                  Gap                  |   Addressed in  |
+   +---------+---------------------------------------+-----------------+
+   |   LDP   |   LSP mapping, LDP identifiers, LDP   |    [LDP-IPv6]   |
+   | S.3.2.1 | discovery, LDP session establishment, |                 |
+   |         |     next-hop address, and LDP TTL     |                 |
+   |         |                security               |                 |
+   +---------+---------------------------------------+-----------------+
+   |   mLDP  |    Inherits gaps from LDP, RFC 6512   |     Inherits    |
+   | S.3.2.2 |               [RFC6512]               |   [LDP-IPv6],   |
+   |         |                                       |    additional   |
+   |         |                                       |    fixes TBD    |
+   +---------+---------------------------------------+-----------------+
+   |  GMPLS  | RFC 6370 [RFC6370] Node ID derivation |       TBD       |
+   | S.3.2.6 |                                       |                 |
+   +---------+---------------------------------------+-----------------+
+   |  L2VPN  |     RFC 6074 [RFC6074] discovery,     |       TBD       |
+   | S.3.3.1 |               signaling               |                 |
+   +---------+---------------------------------------+-----------------+
+   |  L3VPN  |  RFC 4659 [RFC4659] does not define a |       TBD       |
+   | S.3.3.2 |          method for 4PE/4VPE          |                 |
+   +---------+---------------------------------------+-----------------+
+   |   OAM   |  RFC 4379 [RFC4379] No IPv6 multipath |    [IPv6-RAO]   |
+   |  S.3.4  |     support, no IPv6 RAO, possible    |                 |
+   |         |     dropped messages in IP version    |                 |
+   |         |                mismatch               |                 |
+   +---------+---------------------------------------+-----------------+
+   |   MIB   |   RFC 3811 [RFC3811] no IPv6 textual  |    [MPLS-TC]    |
+   | Modules |               convention              |                 |
+   |  S.3.5  |                                       |                 |
+   +---------+---------------------------------------+-----------------+
+
+                       Table 1: IPv6-Only MPLS Gaps
+
+5.  Security Considerations
+
+   Changing the address family used for MPLS network operation does not
+   fundamentally alter the security considerations currently extant in
+   any of the specifics of the protocol or its features.  However,
+   follow-on work recommended by this gap analysis will need to address
+   any effects that the use of IPv6 in their modifications may have on
+   security.
+
+
+
+
+
+
+
+George & Pignataro            Informational                    [Page 18]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, December 1998,
+              <http://www.rfc-editor.org/info/rfc2460>.
+
+   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+              Encoding", RFC 3032, January 2001,
+              <http://www.rfc-editor.org/info/rfc3032>.
+
+   [RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in
+              BGP-4", RFC 3107, May 2001,
+              <http://www.rfc-editor.org/info/rfc3107>.
+
+   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+              Tunnels", RFC 3209, December 2001,
+              <http://www.rfc-editor.org/info/rfc3209>.
+
+   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
+              (GMPLS) Signaling Functional Description", RFC 3471,
+              January 2003, <http://www.rfc-editor.org/info/rfc3471>.
+
+   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
+              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
+              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003,
+              <http://www.rfc-editor.org/info/rfc3473>.
+
+   [RFC3811]  Nadeau, T. and J. Cucchiara, "Definitions of Textual
+              Conventions (TCs) for Multiprotocol Label Switching (MPLS)
+              Management", RFC 3811, June 2004,
+              <http://www.rfc-editor.org/info/rfc3811>.
+
+   [RFC4023]  Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
+              MPLS in IP or Generic Routing Encapsulation (GRE)", RFC
+              4023, March 2005,
+              <http://www.rfc-editor.org/info/rfc4023>.
+
+   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
+              Label Switched (MPLS) Data Plane Failures", RFC 4379,
+              February 2006, <http://www.rfc-editor.org/info/rfc4379>.
+
+
+
+
+
+
+
+George & Pignataro            Informational                    [Page 19]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   [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, September 2006,
+              <http://www.rfc-editor.org/info/4659>.
+
+   [RFC4817]  Townsley, M., Pignataro, C., Wainner, S., Seely, T., and
+              J. Young, "Encapsulation of MPLS over Layer 2 Tunneling
+              Protocol Version 3", RFC 4817, March 2007,
+              <http://www.rfc-editor.org/info/rfc4817>.
+
+   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
+              Specification", RFC 5036, October 2007,
+              <http://www.rfc-editor.org/info/rfc5036>.
+
+   [RFC6074]  Rosen, E., Davie, B., Radoaca, V., and W. Luo,
+              "Provisioning, Auto-Discovery, and Signaling in Layer 2
+              Virtual Private Networks (L2VPNs)", RFC 6074, January
+              2011, <http://www.rfc-editor.org/info/rfc6074>.
+
+   [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
+              Profile (MPLS-TP) Identifiers", RFC 6370, September 2011,
+              <http://www.rfc-editor.org/info/rfc6370>.
+
+   [RFC6512]  Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann,
+              "Using Multipoint LDP When the Backbone Has No Route to
+              the Root", RFC 6512, February 2012,
+              <http://www.rfc-editor.org/info/rfc6512>.
+
+6.2.  Informative References
+
+   [EVPN]     Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J.
+              Uttaro, "BGP MPLS Based Ethernet VPN", Work in Progress,
+              draft-ietf-l2vpn-evpn-11, October 2014.
+
+   [IPv4-MAPPED]
+              Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire
+              Considered Harmful", Work in Progress, draft-itojun-v6ops-
+              v4mapped-harmful-02, October 2003.
+
+   [IPv6-RAO]
+              Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert
+              Option for MPLS OAM", Work in Progress, draft-raza-mpls-
+              oam-ipv6-rao-02, September 2014.
+
+   [LDP-IPv6]
+              Asati, R., Manral, V., Papneja, R., and C. Pignataro,
+              "Updates to LDP for IPv6", Work in Progress, draft-ietf-
+              mpls-ldp-ipv6-14, October 2014.
+
+
+
+George & Pignataro            Informational                    [Page 20]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   [LOOPBACK-PREFIX]
+              Smith, M., "A Larger Loopback Prefix for IPv6", Work in
+              Progress, draft-smith-v6ops-larger-ipv6-loopback-prefix-
+              04, February 2013.
+
+   [mLDP-NLRI]
+              Wijnands, I., Rosen, E., and U. Joorde, "Encoding mLDP
+              FECs in the NLRI of BGP MCAST-VPN Routes", Work in
+              Progress, draft-ietf-l3vpn-mvpn-mldp-nlri-10, November
+              2014.
+
+   [MPLS-TC]  Manral, V., Tsou, T., Will, W., and F. Fondelli,
+              "Definitions of Textual Conventions (TCs) for
+              Multiprotocol Label Switching (MPLS) Management", Work in
+              Progress, draft-manral-mpls-rfc3811bis-04, September 2014.
+
+   [PE-CE]    Patel, K., Rekhter, Y., and E. Rosen, "BGP as an MVPN
+              PE-CE Protocol", Work in Progress,
+              draft-ietf-l3vpn-mvpn-pe- ce-02, October 2014.
+
+   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
+              E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, February 1996,
+              <http://www.rfc-editor.org/info/rfc1918>.
+
+   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
+              (TE) Extensions to OSPF Version 2", RFC 3630, September
+              2003, <http://www.rfc-editor.org/info/rfc3630>.
+
+   [RFC3812]  Srinivasan, C., Viswanathan, A., and T. Nadeau,
+              "Multiprotocol Label Switching (MPLS) Traffic Engineering
+              (TE) Management Information Base (MIB)", RFC 3812, June
+              2004, <http://www.rfc-editor.org/info/rfc3812>.
+
+   [RFC3813]  Srinivasan, C., Viswanathan, A., and T. Nadeau,
+              "Multiprotocol Label Switching (MPLS) Label Switching
+              Router (LSR) Management Information Base (MIB)", RFC 3813,
+              June 2004, <http://www.rfc-editor.org/info/rfc3813>.
+
+   [RFC3815]  Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions
+              of Managed Objects for the Multiprotocol Label Switching
+              (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June
+              2004, <http://www.rfc-editor.org/info/rfc3815>.
+
+   [RFC4090]  Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
+              Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
+              2005, <http://www.rfc-editor.org/info/rfc4090>.
+
+
+
+
+George & Pignataro            Informational                    [Page 21]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   [RFC4220]  Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering
+              Link Management Information Base", RFC 4220, November
+              2005, <http://www.rfc-editor.org/info/rfc4220>.
+
+   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+              Networks (VPNs)", RFC 4364, February 2006,
+              <http://www.rfc-editor.org/info/rfc4364>.
+
+   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
+              Heron, "Pseudowire Setup and Maintenance Using the Label
+              Distribution Protocol (LDP)", RFC 4447, April 2006,
+              <http://www.rfc-editor.org/info/rfc4447>.
+
+   [RFC4558]  Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou,
+              "Node-ID Based Resource Reservation Protocol (RSVP) Hello:
+              A Clarification Statement", RFC 4558, June 2006,
+              <http://www.rfc-editor.org/info/rfc4558>.
+
+   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
+              Element (PCE)-Based Architecture", RFC 4655, August 2006,
+              <http://www.rfc-editor.org/info/rfc4655>.
+
+   [RFC4664]  Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
+              Private Networks (L2VPNs)", RFC 4664, September 2006,
+              <http://www.rfc-editor.org/info/rfc4664>.
+
+   [RFC4761]  Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
+              (VPLS) Using BGP for Auto-Discovery and Signaling", RFC
+              4761, January 2007,
+              <http://www.rfc-editor.org/info/rfc4761>.
+
+   [RFC4762]  Lasserre, M. and V. Kompella, "Virtual Private LAN Service
+              (VPLS) Using Label Distribution Protocol (LDP) Signaling",
+              RFC 4762, January 2007,
+              <http://www.rfc-editor.org/info/rfc4762>.
+
+   [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, February 2007,
+              <http://www.rfc-editor.org/info/rfc4798>.
+
+   [RFC4802]  Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label
+              Switching (GMPLS) Traffic Engineering Management
+              Information Base", RFC 4802, February 2007,
+              <http://www.rfc-editor.org/info/rfc4802>.
+
+
+
+
+
+
+George & Pignataro            Informational                    [Page 22]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   [RFC4875]  Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
+              "Extensions to Resource Reservation Protocol - Traffic
+              Engineering (RSVP-TE) for Point-to-Multipoint TE Label
+              Switched Paths (LSPs)", RFC 4875, May 2007,
+              <http://www.rfc-editor.org/info/rfc4875>.
+
+   [RFC4884]  Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
+              "Extended ICMP to Support Multi-Part Messages", RFC 4884,
+              April 2007, <http://www.rfc-editor.org/info/rfc4884>.
+
+   [RFC4950]  Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP
+              Extensions for Multiprotocol Label Switching", RFC 4950,
+              August 2007, <http://www.rfc-editor.org/info/rfc4950>.
+
+   [RFC4990]  Shiomoto, K., Papneja, R., and R. Rabbat, "Use of
+              Addresses in Generalized Multiprotocol Label Switching
+              (GMPLS) Networks", RFC 4990, September 2007,
+              <http://www.rfc-editor.org/info/rfc4990>.
+
+   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
+              Pignataro, "The Generalized TTL Security Mechanism
+              (GTSM)", RFC 5082, October 2007,
+              <http://www.rfc-editor.org/info/rfc5082>.
+
+   [RFC5085]  Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
+              Connectivity Verification (VCCV): A Control Channel for
+              Pseudowires", RFC 5085, December 2007,
+              <http://www.rfc-editor.org/info/rfc5085>.
+
+   [RFC5088]  Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
+              "OSPF Protocol Extensions for Path Computation Element
+              (PCE) Discovery", RFC 5088, January 2008,
+              <http://www.rfc-editor.org/info/rfc5088>.
+
+   [RFC5089]  Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
+              "IS-IS Protocol Extensions for Path Computation Element
+              (PCE) Discovery", RFC 5089, January 2008,
+              <http://www.rfc-editor.org/info/rfc5089>.
+
+   [RFC5286]  Atlas, A. and A. Zinin, "Basic Specification for IP Fast
+              Reroute: Loop-Free Alternates", RFC 5286, September 2008,
+              <http://www.rfc-editor.org/info/rfc5286>.
+
+   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
+              Engineering", RFC 5305, October 2008,
+              <http://www.rfc-editor.org/info/rfc5305>.
+
+
+
+
+
+George & Pignataro            Informational                    [Page 23]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   [RFC5329]  Ishiguro, K., Manral, V., Davey, A., and A. Lindem,
+              "Traffic Engineering Extensions to OSPF Version 3", RFC
+              5329, September 2008,
+              <http://www.rfc-editor.org/info/rfc5329>.
+
+   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
+              (PCE) Communication Protocol (PCEP)", RFC 5440, March
+              2009, <http://www.rfc-editor.org/info/rfc5440>.
+
+   [RFC5512]  Mohapatra, P. and E. Rosen, "The BGP Encapsulation
+              Subsequent Address Family Identifier (SAFI) and the BGP
+              Tunnel Encapsulation Attribute", RFC 5512, April 2009,
+              <http://www.rfc-editor.org/info/rfc5512>.
+
+   [RFC5520]  Bradford, R., Vasseur, JP., and A. Farrel, "Preserving
+              Topology Confidentiality in Inter-Domain Path Computation
+              Using a Path-Key-Based Mechanism", RFC 5520, April 2009,
+              <http://www.rfc-editor.org/info/rfc5520>.
+
+   [RFC5521]  Oki, E., Takeda, T., and A. Farrel, "Extensions to the
+              Path Computation Element Communication Protocol (PCEP) for
+              Route Exclusions", RFC 5521, April 2009,
+              <http://www.rfc-editor.org/info/rfc5521>.
+
+   [RFC5640]  Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-
+              Balancing for Mesh Softwires", RFC 5640, August 2009,
+              <http://www.rfc-editor.org/info/rfc5640>.
+
+   [RFC5837]  Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR.
+              Rivers, "Extending ICMP for Interface and Next-Hop
+              Identification", RFC 5837, April 2010,
+              <http://www.rfc-editor.org/info/rfc5837>.
+
+   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
+              "Bidirectional Forwarding Detection (BFD) for MPLS Label
+              Switched Paths (LSPs)", RFC 5884, June 2010,
+              <http://www.rfc-editor.org/info/rfc5884>.
+
+   [RFC5885]  Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
+              Detection (BFD) for the Pseudowire Virtual Circuit
+              Connectivity Verification (VCCV)", RFC 5885, June 2010,
+              <http://www.rfc-editor.org/info/rfc5885>.
+
+   [RFC5886]  Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of
+              Monitoring Tools for Path Computation Element (PCE)-Based
+              Architecture", RFC 5886, June 2010,
+              <http://www.rfc-editor.org/info/rfc5886>.
+
+
+
+
+George & Pignataro            Informational                    [Page 24]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   [RFC5921]  Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
+              Berger, "A Framework for MPLS in Transport Networks",
+              RFC 5921, July 2010,
+              <http://www.rfc-editor.org/info/rfc5921>.
+
+   [RFC6006]  Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z.,
+              and J. Meuric, "Extensions to the Path Computation Element
+              Communication Protocol (PCEP) for Point-to-Multipoint
+              Traffic Engineering Label Switched Paths", RFC 6006,
+              September 2010, <http://www.rfc-editor.org/info/rfc6006>.
+
+   [RFC6073]  Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
+              Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011,
+              <http://www.rfc-editor.org/info/rfc6073>.
+
+   [RFC6119]  Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
+              Engineering in IS-IS", RFC 6119, February 2011,
+              <http://www.rfc-editor.org/info/rfc6119>.
+
+   [RFC6371]  Busi, I. and D. Allan, "Operations, Administration, and
+              Maintenance Framework for MPLS-Based Transport Networks",
+              RFC 6371, September 2011,
+              <http://www.rfc-editor.org/info/rfc6371>.
+
+   [RFC6388]  Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
+              "Label Distribution Protocol Extensions for Point-to-
+              Multipoint and Multipoint-to-Multipoint Label Switched
+              Paths", RFC 6388, November 2011,
+              <http://www.rfc-editor.org/info/rfc6388>.
+
+   [RFC6445]  Nadeau, T., Koushik, A., and R. Cetin, "Multiprotocol
+              Label Switching (MPLS) Traffic Engineering Management
+              Information Base for Fast Reroute", RFC 6445, November
+              2011, <http://www.rfc-editor.org/info/rfc6445>.
+
+   [RFC6513]  Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
+              VPNs", RFC 6513, February 2012,
+              <http://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, February 2012,
+              <http://rfc-editor.org/info/rfc6514>.
+
+   [RFC6540]  George, W., Donley, C., Liljenstolpe, C., and L. Howard,
+              "IPv6 Support Required for All IP-Capable Nodes", BCP 177,
+              RFC 6540, April 2012,
+              <http://www.rfc-editor.org/info/rfc6540>.
+
+
+
+George & Pignataro            Informational                    [Page 25]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+   [RFC6624]  Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
+              Virtual Private Networks Using BGP for Auto-Discovery and
+              Signaling", RFC 6624, May 2012,
+              <http://www.rfc-editor.org/info/rfc6624>.
+
+   [RFC6720]  Pignataro, C. and R. Asati, "The Generalized TTL Security
+              Mechanism (GTSM) for the Label Distribution Protocol
+              (LDP)", RFC 6720, August 2012,
+              <http://www.rfc-editor.org/info/rfc6720>.
+
+   [RFC6829]  Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label
+              Switched Path (LSP) Ping for Pseudowire Forwarding
+              Equivalence Classes (FECs) Advertised over IPv6", RFC
+              6829, January 2013,
+              <http://www.rfc-editor.org/info/rfc6829>.
+
+   [RFC7117]  Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C.
+              Kodeboniya, "Multicast in Virtual Private LAN Service
+              (VPLS)", RFC 7117, February 2014,
+              <http://www.rfc-editor.org/info/rfc7117>.
+
+Acknowledgements
+
+   The authors wish to thank Alvaro Retana, Andrew Yourtchenko, Loa
+   Andersson, David Allan, Mach Chen, Mustapha Aissaoui, and Mark Tinka
+   for their detailed reviews, as well as Brian Haberman, Joel Jaeggli,
+   Adrian Farrel, Nobo Akiya, Francis Dupont, and Tobias Gondrom for
+   their comments.
+
+Contributors
+
+   The following people have contributed text to this document:
+
+      Rajiv Asati
+      Cisco Systems
+      7025 Kit Creek Road
+      Research Triangle Park, NC 27709
+      United States
+
+      EMail: rajiva@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+George & Pignataro            Informational                    [Page 26]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+      Kamran Raza
+      Cisco Systems
+      2000 Innovation Drive
+      Ottawa, ON K2K-3E8
+      Canada
+
+      EMail: skraza@cisco.com
+
+
+      Ronald Bonica
+      Juniper Networks
+      2251 Corporate Park Drive
+      Herndon, VA 20171
+      United States
+
+      EMail: rbonica@juniper.net
+
+
+      Rajiv Papneja
+      Huawei Technologies
+      2330 Central Expressway
+      Santa Clara, CA 95050
+      United States
+
+      EMail: rajiv.papneja@huawei.com
+
+
+      Dhruv Dhody
+      Huawei Technologies
+      Leela Palace
+      Bangalore, Karnataka 560008
+      India
+
+      EMail: dhruv.ietf@gmail.com
+
+
+      Vishwas Manral
+      Ionos Networks
+      Sunnyvale, CA 94089
+      United States
+
+      EMail: vishwas@ionosnetworks.com
+
+
+
+
+
+
+
+
+
+George & Pignataro            Informational                    [Page 27]
+
+RFC 7439                     IPv6-Only MPLS                 January 2015
+
+
+      Nagendra Kumar
+      Cisco Systems, Inc.
+      7200 Kit Creek Road
+      Research Triangle Park, NC 27709
+      United States
+
+      EMail: naikumar@cisco.com
+
+Authors' Addresses
+
+   Wesley George (editor)
+   Time Warner Cable
+   13820 Sunrise Valley Drive
+   Herndon, VA  20111
+   United States
+
+   Phone: +1-703-561-2540
+   EMail: wesley.george@twcable.com
+
+
+   Carlos Pignataro (editor)
+   Cisco Systems, Inc.
+   7200-12 Kit Creek Road
+   Research Triangle Park, NC  27709
+   United States
+
+   Phone: +1-919-392-7428
+   EMail: cpignata@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+George & Pignataro            Informational                    [Page 28]
+