draft-george-mpls-ipv6-only-gap-04.txt   draft-george-mpls-ipv6-only-gap-05.txt 
Internet Engineering Task Force W. George, Ed. Internet Engineering Task Force W. George, Ed.
Internet-Draft Time Warner Cable Internet-Draft Time Warner Cable
Intended status: Informational C. Pignataro, Ed. Intended status: Informational C. Pignataro, Ed.
Expires: August 14, 2014 Cisco Systems Expires: September 25, 2014 Cisco
February 10, 2014 March 24, 2014
Gap Analysis for Operating IPv6-only MPLS Networks Gap Analysis for Operating IPv6-only MPLS Networks
draft-george-mpls-ipv6-only-gap-04 draft-george-mpls-ipv6-only-gap-05
Abstract Abstract
This document reviews the MPLS protocol suite in the context of IPv6 This document reviews the MPLS protocol suite in the context of IPv6
and identifies gaps that must be addressed in order to allow MPLS- and identifies gaps that must be addressed in order to allow MPLS-
related protocols and applications to be used with IPv6-only related protocols and applications to be used with IPv6-only
networks. This document is not intended to highlight a particular networks. This document is not intended to highlight a particular
vendor's implementation (or lack thereof) in the context of IPv6-only vendor's implementation (or lack thereof) in the context of IPv6-only
MPLS functionality, but rather to focus on gaps in the standards MPLS functionality, but rather to focus on gaps in the standards
defining the MPLS suite. defining the MPLS suite.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 14, 2014. This Internet-Draft will expire on September 25, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 5 3.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 4
3.2. MPLS Control Plane . . . . . . . . . . . . . . . . . . . 5 3.2. MPLS Control Plane . . . . . . . . . . . . . . . . . . . 5
3.2.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. Multipoint LDP . . . . . . . . . . . . . . . . . . . 5 3.2.2. Multipoint LDP . . . . . . . . . . . . . . . . . . . 5
3.2.3. RSVP- TE . . . . . . . . . . . . . . . . . . . . . . 6 3.2.3. RSVP- TE . . . . . . . . . . . . . . . . . . . . . . 6
3.2.3.1. IGP . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.3.1. IGP . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.3.2. RSVP-TE-P2MP . . . . . . . . . . . . . . . . . . 7 3.2.3.2. RSVP-TE-P2MP . . . . . . . . . . . . . . . . . . 7
3.2.3.3. RSVP-TE Fast Reroute (FRR) . . . . . . . . . . . 7 3.2.3.3. RSVP-TE Fast Reroute (FRR) . . . . . . . . . . . 7
3.2.4. Controller, PCE . . . . . . . . . . . . . . . . . . . 7 3.2.4. Controller, PCE . . . . . . . . . . . . . . . . . . . 7
3.2.5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.6. GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.6. GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 2, line 38 skipping to change at page 2, line 38
3.3.2.1. 6PE/4PE . . . . . . . . . . . . . . . . . . . . . 10 3.3.2.1. 6PE/4PE . . . . . . . . . . . . . . . . . . . . . 10
3.3.2.2. 6VPE/4VPE . . . . . . . . . . . . . . . . . . . . 10 3.3.2.2. 6VPE/4VPE . . . . . . . . . . . . . . . . . . . . 10
3.3.2.3. BGP Encapsulation SAFI . . . . . . . . . . . . . 10 3.3.2.3. BGP Encapsulation SAFI . . . . . . . . . . . . . 10
3.3.2.4. NG-MVPN . . . . . . . . . . . . . . . . . . . . . 10 3.3.2.4. NG-MVPN . . . . . . . . . . . . . . . . . . . . . 10
3.3.3. MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.3. MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 12 3.4.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 12
3.4.2. LSP Ping . . . . . . . . . . . . . . . . . . . . . . 13 3.4.2. LSP Ping . . . . . . . . . . . . . . . . . . . . . . 13
3.4.3. BFD OAM . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.3. BFD OAM . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.4. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 14 3.4.4. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 14
3.4.5. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 14 3.4.5. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 15
3.5. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 16 6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Informative References . . . . . . . . . . . . . . . . . . . 19 9. Informative References . . . . . . . . . . . . . . . . . . . 18
Appendix A. Assignments . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
IPv6 is an integral part of modern network deployments. At the time IPv6 is an integral part of modern network deployments. At the time
when this document was written, the majority of these IPv6 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 35 skipping to change at page 3, line 35
complete function, this document reviews the Multi-Protocol Label complete function, this document reviews the Multi-Protocol Label
Switching (MPLS) protocol suite in the context of IPv6 and identifies Switching (MPLS) protocol suite in the context of IPv6 and identifies
gaps that must be addressed in order to allow MPLS-related protocols gaps that must be addressed in order to allow MPLS-related protocols
and applications to be used with IPv6-only networks. This document and applications to be used with IPv6-only networks. This document
is not intended to highlight a particular vendor's implementation (or is not intended to highlight a particular vendor's implementation (or
lack thereof) in the context of IPv6-only MPLS functionality, but lack thereof) in the context of IPv6-only MPLS functionality, but
rather to focus on gaps in the standards defining the MPLS suite. rather to focus on gaps in the standards defining the MPLS suite.
2. Use Case 2. Use Case
From a purely theoretical perspective, ensuring that MPLS is fully IP This section discusses some drivers for ensuring that MPLS completely
version-agnostic is the right thing to do. However, it is sometimes supports IPv6-only operation. It is not intended to be a
helpful to understand the underlying drivers that make this work comprehensive discussion of all potential use cases, but rather a
necessary to undertake, especially at a time when IPv6-only discussion of at least one use case to provide context and
networking is still fairly uncommon. This section will discuss some justification to undertake such a gap analysis.
drivers. It is not intended to be a comprehensive discussion of all
potential use cases, but rather a discussion of at least one use case
to demonstrate that this document is not discussing a purely
theoretical problem.
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 applications. In some
cases, these classes of devices represent a very large deployment cases, these classes of devices represent a very large deployment
base, on the order of thousands or even millions of devices network- base, on the order of thousands or even millions of devices network-
wide. The scale of these networks, coupled with the increasingly wide. The scale of these networks, coupled with the increasingly
overlapping use of RFC 1918 [RFC1918] address space within the overlapping use of RFC 1918 [RFC1918] address space within the
average network, and the lack of globally-routable IPv4 space average network, and the lack of globally-routable IPv4 space
available for long-term growth begins to drive the need for many of available for long-term growth begins to drive the need for many of
the endpoints in this network to be managed solely via IPv6. Even if the endpoints in this network to be managed solely via IPv6. Even if
these devices are carrying some IPv4 user data, it is often 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. Depending on the MPLS impacting support for IPv4 on user data. As the number of devices to
features required, it is plausible to assume that the (existing) MPLS manage increases, the operator is compelled to move to IPv6.
network may need to be extended to these devices. Depending on the MPLS features required, it is plausible to assume
that the (existing) MPLS network will need to be extended to these
IPv6-only devices.
Additionally, as the impact of IPv4 exhaustion becomes more acute, 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. Measures that were previously seen as too complex or as justified. Many networks are likely to focus on preserving their
netting too few addresses for the work required may become more remaining IPv4 addresses for revenue-generating customers so that
realistic as the cost for obtaining new IPv4 addresses increases. legacy support for IPv4 can be maintained as long as possible. As a
More and more networks are likely to adopt the general stance that result, it may be appropriate for some or all of the network
IPv4 addresses need to be preserved for revenue-generating customers infrastructure, including MPLS LSRs and LERs, to have its IPv4
so that legacy support for IPv4 can be maintained as long as addresses reclaimed and transition toward IPv6-only operation.
possible. As a result, it may be appropriate for some or all of the
network infrastructure, including MPLS LSRs and LERs, to have its
IPv4 addresses reclaimed and transition toward IPv6-only operation.
3. Gap Analysis 3. Gap Analysis
This gap analysis aims to answer the question, "what breaks when one This gap analysis aims to answer the question, "what breaks 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 baseline assumption for this analysis is that some endpoints as The baseline assumption for this analysis is that some endpoints as
well as Label Switch Routers (PE and P routers) only have IPv6 well as Label Switch Routers (PE and P routers) only have IPv6
transport available, and need to support the full suite of MPLS transport available, and need to support the full suite of MPLS
features defined as of the time of this document's writing at parity features defined as of the time of this document's writing at parity
with the support on an IPv4 network. This is necessary whether they with the support on an IPv4 network. This is necessary whether they
are enabled via Label Distribution Protocol (LDP) RFC 5036 [RFC5036], are enabled via Label Distribution Protocol (LDP) RFC 5036 [RFC5036],
Resource Reservation Protocol Extensions for MPLS Traffic Engineering Resource Reservation Protocol Extensions for MPLS Traffic Engineering
(RSVP-TE) RFC 5420 [RFC5420], or Border Gateway Protocol (BGP) RFC (RSVP-TE) RFC 3209 [RFC3209], or Border Gateway Protocol (BGP) RFC
3107 [RFC3107], and whether they are encapsulated in MPLS RFC 3032 3107 [RFC3107], and whether they are encapsulated in MPLS RFC 3032
[RFC3032], IP RFC 4023 [RFC4023], Generic Routing Encapsulation (GRE) [RFC3032], IP RFC 4023 [RFC4023], Generic Routing Encapsulation (GRE)
RFC 4023 [RFC4023], or Layer 2 Tunneling Protocol Version 3 (L2TPv3) RFC 4023 [RFC4023], or Layer 2 Tunneling Protocol Version 3 (L2TPv3)
RFC 4817 [RFC4817]. It is important when evaluating these gaps to RFC 4817 [RFC4817]. It is important when evaluating these gaps to
distinguish between user data and control plane data, because while distinguish between user data and control plane data, because while
this document is focused on IPv6-only operation, it is quite likely this document is focused on IPv6-only operation, it is quite likely
that some amount of the user payload data being carried in the that some amount of the user payload data being carried in the
IPv6-only MPLS network will still be IPv4. IPv6-only MPLS network will still be IPv4.
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 RFC 3032 [RFC3032], and MPLS labeled packets can also be encapsulated
over IP. The encapsulations of MPLS in IP and GRE as well as MPLS over IP. The encapsulations of MPLS in IP and GRE as well as MPLS
over L2TPv3 support IPv6. See Section 3 of RFC 4023 [RFC4023] and over 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.
In the case where an IPv4 prefix is resolved over an IPv6 LSP, an
IPv6 Explicit Null label cannot immediately preceed an IPv4 packet.
Gap: None. Gap: None.
3.2. MPLS Control Plane 3.2. MPLS Control Plane
3.2.1. LDP 3.2.1. LDP
Label Distribution Protocol (LDP) RFC 5036 [RFC5036] defines a set of Label Distribution Protocol (LDP) RFC 5036 [RFC5036] defines a set of
procedures for distribution of labels between label switch routers procedures for distribution of labels between label switch 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
skipping to change at page 6, line 6 skipping to change at page 5, line 50
2. Multipoint (MP) FEC Root address: mLDP defines its own MP FECs 2. Multipoint (MP) FEC Root address: mLDP defines its own MP FECs
and rules, different from LDP, to map MP LSPs. mLDP MP FEC and rules, different from LDP, to map MP LSPs. mLDP MP FEC
contains a Root Address field which is an IP address in IP contains a Root Address field which is an IP address in IP
networks. The current specification allows specifying Root networks. The current specification allows specifying Root
address according to AFI and hence covers both IPv4 or IPv6 root address according to 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 root address to find corresponding upstream table lookup against root address to find corresponding upstream
neighbor(s). This will pose a problem when an MP LSP traverses neighbor(s). This will pose a problem if an MP LSP traverses
islands of IPv4 and IPv4 clouds on the way to the root node. IPv4-only and IPv6-only nodes in a dual-stack network on the way
to the root node.
For example, consider following setup, where R1/R6 are IPv4-only, R3/ 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 an 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
skipping to change at page 8, line 28 skipping to change at page 8, line 22
Gap: None. Gap: None.
3.2.6. GMPLS 3.2.6. GMPLS
RFC4558 [RFC4558] specifies Node-ID Based RSVP Hello Messages with RFC4558 [RFC4558] specifies Node-ID Based RSVP Hello Messages with
capability for both IPv4 and IPv6. RFC4990 [RFC4990] clarifies the capability for both IPv4 and IPv6. RFC4990 [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.
Gap: None. Section 5.3, second paragraph of RFC6370 [RFC6370] describes the
mapping from an MPLS-TP LSP_ID to RSVP-TE with an assumption that
Node_IDs are derived from valid IPv4 addresses. This assumption
fails in an IPv6-only network, given that there wouldn't be any IPv4
addresses.
Gap: Minor; Section 5.3. of RFC6370 needs to be updated.
3.3. MPLS Applications 3.3. MPLS Applications
3.3.1. L2VPN 3.3.1. L2VPN
L2VPN RFC 4664 [RFC4664] specifies two fundamentally different kinds L2VPN RFC 4664 [RFC4664] specifies two fundamentally different kinds
of Layer 2 VPN services that a service provider could offer to a of Layer 2 VPN services that a service provider could offer to a
customer: Virtual Private Wire Service (VPWS) and Virtual Private LAN customer: Virtual Private Wire Service (VPWS) and Virtual Private LAN
Service (VPLS). RFC 4447 [RFC4447] and RFC 4762 [RFC4762] specify Service (VPLS). RFC 4447 [RFC4447] and RFC 4762 [RFC4762] specify
the LDP protocol changes to instantiate VPWS and VPLS services the LDP protocol changes to instantiate VPWS and VPLS services
skipping to change at page 9, line 12 skipping to change at page 9, line 12
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 (section
3.2.2 and section 6), it suggests encoding PE IP address in the VSI- 3.2.2 and section 6), it suggests encoding PE IP address in the VSI-
ID, which is encoded in NLRI, and should not exceed 12 bytes (to ID, which is encoded in NLRI, and should not exceed 12 bytes (to
differentiate its AFI/SAFI encoding from RFC4761). This means that differentiate its AFI/SAFI encoding from RFC4761). This means that
PE IP address can NOT be an IPv6 address. Also, in its signaling PE IP address can NOT be an IPv6 address. Also, in its signaling
procedures (section 3.2.3), it suggests encoding PE_addr in SAII and procedures (section 3.2.3), it suggests encoding PE_addr in SAII and
TAII, which are limited to 32-bit (AII Type=1) at the moment. TAII, which are limited to 32-bit (AII Type=1) at the moment.
RFC 6073 [RFC6073] defines the new LDP PW Switching Point PE TLV,
which supports IPv4 and IPv6.
Gap: Minor. RFC6074 needs to be updated. Gap: Minor. RFC6074 needs to be updated.
3.3.1.1. EVPN 3.3.1.1. EVPN
EVPN [I-D.ietf-l2vpn-evpn] is still a work in progress. As such, it EVPN [I-D.ietf-l2vpn-evpn] is still a work in progress. As such, it
is out of scope for this gap analysis. Instead, the authors of that is out of scope for this gap analysis. Instead, the authors of that
draft need to ensure that it supports IPv6-only operation, or if it draft need to ensure that it supports IPv6-only operation, or if it
cannot, identify dependencies on underlying gaps in MPLS protocol(s) cannot, identify dependencies on underlying gaps in MPLS protocol(s)
that must be resolved before it can support IPv6-only operation. that must be resolved before it can support IPv6-only operation.
skipping to change at page 9, line 34 skipping to change at page 9, line 37
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 Virtual Private Networks (VPNs) for
its customers. The following use cases arise in the context of this its customers. The 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.
RFC4364 defines as VPN-IPv4 address type, but not a VPN-IPv6 address RFC4364 defines a VPN-IPv4 address family, but not a VPN-IPv6 address
type. RFC 4659 [RFC4659] corrects this oversight. Also, Section 5 family. RFC 4659 [RFC4659] corrects this oversight. Also, Section 5
of RFC 4364 [RFC4364] assumes that the BGP next-hop contains exactly of RFC 4364 [RFC4364] assumes that the BGP next-hop contains exactly
32 bits. This text should be generalized to include 128 bit next- 32 bits. This text should be generalized to include 128 bit next-
hops as well. hops as well. Section 3.2.1.1 of RFC 4659 [RFC4659] does actually
specifies a 128-bit BGP next-hop.
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. RFC4364 must be updated, and RFC4659 may need to be Gap: Major. RFC4364 must be updated, and RFC4659 may need to be
updated to explicitly cover use case #2. (Discussed in further updated to explicitly cover use case #2. (Discussed in further
detail below) detail below)
3.3.2.1. 6PE/4PE 3.3.2.1. 6PE/4PE
skipping to change at page 10, line 17 skipping to change at page 10, line 17
RFC 4798 [RFC4798] defines 6PE, which defines how to interconnect RFC 4798 [RFC4798] defines 6PE, which defines how to interconnect
IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4
cloud. However, use case 2 is doing the opposite, and thus could cloud. However, use case 2 is doing the opposite, and thus could
also be referred to as 4PE. The method to support this use case is also be referred to as 4PE. The method to support this use case is
not defined explicitly. To support it, IPv4 edge devices need to be not defined explicitly. To support it, IPv4 edge devices need to be
able to map IPv4 traffic to MPLS IPv6 core LSP's. Also, the core able to map IPv4 traffic to MPLS IPv6 core LSP's. Also, the core
switches may not understand IPv4 at all, but in some cases they may 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 to a need to be able to exchange Labeled IPv4 routes from one AS to a
neighboring AS. neighboring AS.
Gap: Major. RFC4659 needs to be updated to explicitly cover use case Gap: Major. RFC4798 covers only the "6PE" case. Use case #2 is
#2. currently not specified in an RFC.
3.3.2.2. 6VPE/4VPE 3.3.2.2. 6VPE/4VPE
RFC 4659 [RFC4659] defines 6VPE, a method by which a Service Provider RFC 4659 [RFC4659] defines 6VPE, a method by which a Service Provider
may use its packet-switched backbone to provide Virtual Private may use its packet-switched backbone to provide Virtual Private
Network (VPN) services for its IPv6 customers. It allows the core Network (VPN) services for its IPv6 customers. It allows the core
network to be MPLS IPv4 or MPLS IPv6, thus addressing use case 1 network to be MPLS IPv4 or MPLS IPv6, thus addressing use case 1
above. RFC4364 should work as defined for use case 2 above, which above. RFC4364 should work as defined for use case 2 above, which
could also be referred to as 4VPE, but the RFC does not explicitly could also be referred to as 4VPE, but the RFC does not explicitly
discuss this use. discuss this use.
Gap: Minor. RFC4659 may need to be updated to explicitly cover use Gap: Minor. RFC4659 may need to be updated to explicitly cover use
case #2 case #2
3.3.2.3. BGP Encapsulation SAFI 3.3.2.3. BGP Encapsulation 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 Tunnel Encapsulation Attribute, which can be used to signal tunneling
tunnelling over an single-Address Family IP core. This mechanism over a single-Address Family IP core. This mechanism supports
supports transport of MPLS (and other protocols) over Tunnels in an transport of MPLS (and other protocols) over Tunnels in an IP core
IP core (including an IPv6-only core). In this context, load- (including an IPv6-only core). In this context, load-balancing can
balancing can be provided as specified in RFC 5640 [RFC5640]. be provided as specified in RFC 5640 [RFC5640].
Gap: None. Gap: None.
3.3.2.4. NG-MVPN 3.3.2.4. NG-MVPN
RFC 6513 [RFC6513] defines the procedure to provide multicast service RFC 6513 [RFC6513] defines the procedure to provide multicast service
over MPLS VPN backbone for the customers. The procedure involves the over MPLS VPN backbone for the customers. The procedure involves the
below set of protocols: below set of protocols:
3.3.2.4.1. PE-CE Multicast Routing Protocol 3.3.2.4.1. PE-CE Multicast Routing Protocol
skipping to change at page 14, line 44 skipping to change at page 14, line 44
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 RFC 5085 [RFC5085] can carry IPv4
or IPv6 OAM packets (see Section 5.1.1 and 5.2.1 of RFC 5085), and or IPv6 OAM packets (see Section 5.1.1 and 5.2.1 of RFC 5085), and
VCCV for BFD RFC 5885 [RFC5885] also defines an IPv6 encapsulation VCCV for BFD RFC 5885 [RFC5885] also defines an IPv6 encapsulation
(see Section 3.2 of RFC 5885). (see Section 3.2 of RFC 5885).
Additionally, for LSP Ping for Pseudowires, the Pseudowire FECs are
specified for IPv6 in RFC 6829 [RFC6829].
Gap: None. Gap: None.
3.4.5. MPLS-TP OAM 3.4.5. MPLS-TP OAM
As with MPLS-TP, MPLS-TP OAM RFC 6371 [RFC6371] is not dependent on As with MPLS-TP, MPLS-TP OAM RFC 6371 [RFC6371] is not dependent on
IP or existing MPLS OAM functions, and should not be affected by IP or existing MPLS OAM functions, and should not be affected by
operation on an IPv6-only network. Therefore, this is out of scope operation on an IPv6-only network. Therefore, this is out of scope
for this document. for this document.
Gap: None. Gap: None.
skipping to change at page 16, line 17 skipping to change at page 16, line 17
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| Item | Gap | Addressed in | | Item | Gap | Addressed in |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| LDP | LSP mapping, LDP | LDP-IPv6 | | LDP | LSP mapping, LDP | LDP-IPv6 |
| S.3.2.1 | identifiers, LDP | [I-D.ietf-mpls-ldp-ipv6] | | S.3.2.1 | identifiers, LDP | [I-D.ietf-mpls-ldp-ipv6] |
| | discovery, LDP session | | | | discovery, LDP session | |
| | establishment, next hop | | | | establishment, next hop | |
| | address and LDP TTL | | | | address and LDP TTL | |
| | security | | | | security | |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| GMPLS | RFC6370 [RFC6370] Node | TBD |
| S.3.2.6 | ID derivation | |
+---------+--------------------------+------------------------------+
| L2VPN | RFC 6074 [RFC6074] | TBD | | L2VPN | RFC 6074 [RFC6074] | TBD |
| S.3.3.1 | discovery, signaling | | | S.3.3.1 | discovery, signaling | |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| L3VPN | RFC 4364 [RFC4364] BGP | TBD | | L3VPN | RFC 4364 [RFC4364] BGP | TBD |
| S.3.3.2 | next-hop, define method | | | S.3.3.2 | next-hop, define method | |
| | for 4PE/4VPE | | | | for 4PE/4VPE | |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| OAM | RFC 4379 [RFC4379] no | TBD | | OAM | RFC 4379 [RFC4379] no | TBD |
| S.3.4 | IPv6 multipath support, | | | S.3.4 | IPv6 multipath support, | |
| | possible dropped | | | | possible dropped | |
skipping to change at page 16, line 38 skipping to change at page 16, line 41
| | mismatch | | | | mismatch | |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| MIBs | RFC 3811 [RFC3811] no | 3811bis | | MIBs | RFC 3811 [RFC3811] no | 3811bis |
| S.3.5 | IPv6 textual convention | [I-D.manral-mpls-rfc3811bis] | | S.3.5 | IPv6 textual convention | [I-D.manral-mpls-rfc3811bis] |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
Table 1: IPv6-only MPLS Gaps Table 1: IPv6-only MPLS Gaps
5. Acknowledgements 5. Acknowledgements
The authors wish to thank Andrew Yourtchenko and Loa Andersson for a The authors wish to thank Andrew Yourtchenko, Loa Andersson, David
detailed review, as well as Brian Haberman, Joel Jaeggli, and Adrian Allan, Mach Chen, Mustapha Aissaoui, and Mark Tinka for their
detailed reviews, as well as Brian Haberman, Joel Jaeggli, and Adrian
Farrell for their comments. Farrell for their comments.
6. Contributing Authors 6. Contributing Authors
The following people have contributed text to this draft: The following people have contributed text to this draft:
Rajiv Asati Rajiv Asati
Cisco Systems Cisco Systems
7025 Kit Creek Road 7025 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
US US
Email: rajiva@cisco.com Email: rajiva@cisco.com
Kamran Raza Kamran Raza
Cisco Systems Cisco Systems
2000 Innovation Drive 2000 Innovation Drive
Ottawa, ON K2K-3E8 Ottawa, ON K2K-3E8
CA CA
Email: skraza@cisco.com Email: skraza@cisco.com
Ronald Bonica Ronald Bonica
Juniper Networks Juniper Networks
2251 Corporate Park Drive 2251 Corporate Park Drive
Herndon, VA 20171 Herndon, VA 20171
US US
Email: rbonica@juniper.net Email: rbonica@juniper.net
Rajiv Papneja Rajiv Papneja
Huawei Technologies Huawei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
US US
Email: rajiv.papneja@huawei.com Email: rajiv.papneja@huawei.com
Dhruv Dhody
Dhruv Dhody
Huawei Technologies Huawei Technologies
Leela Palace Leela Palace
Bangalore, Karnataka 560008 Bangalore, Karnataka 560008
IN IN
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Vishwas Manral Vishwas Manral
Hewlett-Packard, Inc. Hewlett-Packard, Inc.
19111 Pruneridge Ave. 19111 Pruneridge Ave.
Cupertino, CA 95014 Cupertino, CA 95014
US US
Email: vishwas.manral@hp.com Email: vishwas.manral@hp.com
Nagendra Kumar Nagendra Kumar
Cisco Systems, Inc. Cisco Systems, Inc.
7200 Kit Creek Road 7200 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
US US
Email: naikumar@cisco.com Email: naikumar@cisco.com
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 8. Security Considerations
skipping to change at page 19, line 14 skipping to change at page 18, line 27
8. Security Considerations 8. 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. any of the specifics of the protocol or its features.
9. Informative References 9. Informative References
[I-D.ietf-l2vpn-evpn] [I-D.ietf-l2vpn-evpn]
Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F., Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J.
Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-
draft-ietf-l2vpn-evpn-04 (work in progress), July 2013. evpn-06 (work in progress), March 2014.
[I-D.ietf-l3vpn-mvpn-mldp-nlri] [I-D.ietf-l3vpn-mvpn-mldp-nlri]
Wijnands, I., Rosen, E., and U. Joorde, "Encoding mLDP Wijnands, I., Rosen, E., and U. Joorde, "Encoding mLDP
FECs in the NLRI of BGP MCAST-VPN Routes", draft-ietf- FECs in the NLRI of BGP MCAST-VPN Routes", draft-ietf-
l3vpn-mvpn-mldp-nlri-04 (work in progress), December 2013. l3vpn-mvpn-mldp-nlri-04 (work in progress), December 2013.
[I-D.ietf-l3vpn-mvpn-pe-ce] [I-D.ietf-l3vpn-mvpn-pe-ce]
Patel, K., Rekhter, Y., and E. Rosen, "BGP as an MVPN PE- Patel, K., Rekhter, Y., and E. Rosen, "BGP as an MVPN PE-
CE Protocol", draft-ietf-l3vpn-mvpn-pe-ce-00 (work in CE Protocol", draft-ietf-l3vpn-mvpn-pe-ce-00 (work in
progress), October 2013. progress), October 2013.
skipping to change at page 22, line 46 skipping to change at page 22, line 12
[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.
[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.
[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.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009.
[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.
[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.
[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
skipping to change at page 24, line 5 skipping to change at page 23, line 11
[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", RFC
5921, July 2010. 5921, July 2010.
[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.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
[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.
[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.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[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.
[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.
[RFC6445] Nadeau, T., Koushik, A., and R. Cetin, "Multiprotocol [RFC6445] Nadeau, T., Koushik, A., and R. Cetin, "Multiprotocol
skipping to change at page 25, line 10 skipping to change at page 24, line 18
[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.
[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.
Appendix A. Assignments
*RFC EDITOR PLEASE REMOVE BEFORE PUBLISHING*
This will track which author volunteered for which section(s):
OAM - Ron Bonica, Carlos Pignataro
LDP/mLDP (multicast) - Kamran Raza
L2VPN - Rajiv Asati, Vishwas Manral, Rajiv Papneja
L3VPN - Rajiv Asati, Vishwas Manral, Rajiv Papneja
PCE - Dhruv Dhody, Rajiv Papneja
Editors- Wes George(primary), Vishwas Manral, Rajiv Asati
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 US
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 Cisco Systems, Inc.
7200-12 Kit Creek Road 7200-12 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
US US
Phone: +1-919-392-7428
Email: cpignata@cisco.com Email: cpignata@cisco.com
 End of changes. 57 change blocks. 
102 lines changed or deleted 74 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/