Gap Analysis for Operating IPv6-Only MPLS Networks

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) , RSVP - Traffic Engineering (RSVP-TE) , or Border Gateway Protocol (BGP) , and whether they are encapsulated in MPLS , IP , Generic Routing Encapsulation (GRE) , or Layer 2 Tunneling Protocol Version 3 (L2TPv3) . 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 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.

MPLS labeled packets can be transmitted over a variety of data links , 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 and Section 2 of RFC 4817, respectively. Gap: None.

The Label Distribution Protocol (LDP) 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 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 . Gap: Major; update to RFC 5036 in progress via , which should close this gap.

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. In terms of IPv6-only gap analysis, mLDP has two identified areas of interest: 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 with regards to control plane (discovery, transport, and session establishment) in an IPv6-only network. 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:

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 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 , may need additional updates to RFC 6512.

RSVP-TE 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.

RFC 3630 specifies a method of adding traffic engineering capabilities to OSPF Version 2. New TLVs and sub-TLVs were added in RFC 5329 to extend TE capabilities to IPv6 networks in OSPF Version 3. RFC 5305 specifies a method of adding traffic engineering capabilities to IS-IS. New TLVs and sub-TLVs were added in RFC 6119 to extend TE capabilities to IPv6 networks. Gap: None.

RFC 4875 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.

RFC 4090 specifies Fast Reroute (FRR) mechanisms to establish backup LSP tunnels for local repair supporting both IPv4 and IPv6 networks. Further, 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.

The Path Computation Element (PCE) defined in RFC 4655 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. The PCEP specification is defined for both IPv4 and IPv6 with support for PCE discovery via an IGP (OSPF or IS-IS ) using both IPv4 and IPv6 addresses. Note that PCEP uses identical encoding of subobjects, as in RSVP-TE defined in RFC 3209 that supports both IPv4 and IPv6. The extensions to PCEP to support confidentiality , route exclusions , monitoring , and P2MP TE LSPs have support for both IPv4 and IPv6. Gap: None.

RFC 3107 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.

The Generalized Multi-Protocol Label Switching (GMPLS) specification includes signaling functional extensions and RSVP-TE extensions . The gap analysis in applies to these. RFC 4558 specifies Node-ID Based RSVP Hello Messages with capability for both IPv4 and IPv6. RFC 4990 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 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 needs to be updated.

L2VPN 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 and RFC 4762 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, which specifies a set of procedures for instantiating L2VPNs (e.g., VPWS, VPLS) using BGP as a discovery protocol and LDP, as well as L2TPv3, as a signaling protocol. RFC 4761 and RFC 6624 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 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), 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), 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 defines the new LDP Pseudowire (PW) Switching Point PE TLV, which supports IPv4 and IPv6. Gap: Minor; RFC 6074 needs to be updated.

Ethernet VPN defines a method for using BGP MPLS-based Ethernet VPNs. Because it can use functions in LDP and mLDP, as well as Multicast VPLS , it inherits LDP gaps previously identified in . 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 that should close this gap (see ).

RFC 4364 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: Connecting IPv6 islands over IPv6-only MPLS network Connecting IPv4 islands over IPv6-only MPLS network 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 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)

RFC 4798 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.

RFC 4659 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

RFC 5512 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. Gap: None.

RFC 6513 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.

RFC 6513 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 explains the use of mLDP as a PE-CE protocol. The MCAST-VPN NLRI route-type format defined in RFC 6514 is not sufficiently covering all scenarios when mLDP is used as a PE-CE protocol. The issue is explained in Section 2 of along with a new route type that encodes the mLDP FEC in NLRI. Further, defines the use of BGP as a PE-CE protocol. Gap: None.

explains the use of the below tunnels: RSVP-TE P2MP LSP PIM Tree mLDP P2MP LSP mLDP MP2MP LSP Ingress Replication Gap: Gaps in RSVP-TE P2MP LSP and mLDP 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.

Section 3.1 of RFC 6513 explains the use of PIM as a PE-PE protocol, while RFC 6514 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.

MPLS-TP does not require IP (see Section 2 of RFC 5921) 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 , where MPLS-TP identifiers can be derived from valid IPv4 addresses. Gap: None. MPLS-TP does not require IP.

For MPLS LSPs, there are primarily three OAM mechanisms: Extended ICMP , LSP Ping , and Bidirectional Forwarding Detection (BFD) for MPLS LSPs . For MPLS Pseudowires, there is also Virtual Circuit Connectivity Verification (VCCV) . Most of these mechanisms work in pure 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.

Extended ICMP to support Multi-part messages is defined in RFC 4884. This extensibility is defined generally for both ICMPv4 and ICMPv6. The specific ICMP extensions for MPLS are defined in RFC 4950. 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: The path between two IPv4-only hosts contains an MPLS LSP. The two routers that terminate the LSP run dual stack. The LSP interior routers run IPv6 only. 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, 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 , 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. Gap: Major; IP version mismatches may cause dropped messages. However, as noted in the previous section, this problem is not specific to MPLS.

The LSP Ping mechanism defined in RFC 4379 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. 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 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 . 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 . 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: LSP Ping is operating in traceroute mode over an MPLS LSP. The two routers that terminate the LSP run dual stack. The LSP interior routers run IPv6 only. The LSP is signaled over IPv6. 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.

The BFD specification for MPLS LSPs 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.

The OAM specifications for MPLS Pseudowires define usage for both IPv4 and IPv6. Specifically, VCCV can carry IPv4 or IPv6 OAM packets (see Sections 5.1.1 and 5.2.1 of RFC 5085), and VCCV for BFD 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. Gap: None.

As with MPLS-TP, MPLS-TP OAM 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.

RFC 3811 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 , the GMPLS-TE MIB specification and the FRR extension . "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management" tries to resolve this gap by marking this textual convention as obsolete. The other MIB specifications for LSR , LDP , and TE have support for both IPv4 and IPv6. Lastly, RFC 4990 discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS-TE MIB modules. In particular, Section 8 of RFC 4990 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. Gap: Minor; Section 8 of RFC 4990 describes a method to handle IPv6 addresses in the MPLS-TE and GMPLS-TE MIB modules. Work underway to update RFC 3811 via , may also need to update RFC 3812, RFC 4802, and RFC 6445, which depend on it.