tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7439

 Errata 
Informational
Pages: 28
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MPLS

Gap Analysis for Operating IPv6-Only MPLS Networks

Part 1 of 2, p. 1 to 13
None       Next RFC Part

 


Top       ToC       Page 1 
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.

Page 2 
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.

Top       Page 3 
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

Top      ToC       Page 4 
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

Top      ToC       Page 5 
   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

Top      ToC       Page 6 
   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.

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
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.

Top      ToC       Page 9 
   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

Top      ToC       Page 10 
   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

Top      ToC       Page 11 
   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.

Top      ToC       Page 12 
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

Top      ToC       Page 13 
   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.



(page 13 continued on part 2)

Next RFC Part