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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/