draft-ietf-mpls-ipv6-only-gap-01.txt   draft-ietf-mpls-ipv6-only-gap-02.txt 
MPLS W. George, Ed. MPLS 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: January 24, 2015 Cisco Expires: February 26, 2015 Cisco
July 23, 2014 August 25, 2014
Gap Analysis for Operating IPv6-only MPLS Networks Gap Analysis for Operating IPv6-only MPLS Networks
draft-ietf-mpls-ipv6-only-gap-01 draft-ietf-mpls-ipv6-only-gap-02
Abstract Abstract
This document reviews the MPLS protocol suite in the context of IPv6 This document reviews the Multiprotocol Label Switching (MPLS)
and identifies gaps that must be addressed in order to allow MPLS- protocol suite in the context of IPv6 and identifies gaps that must
related protocols and applications to be used with IPv6-only be addressed in order to allow MPLS-related protocols and
networks. This document is not intended to highlight a particular applications to be used with IPv6-only networks. This document is
vendor's implementation (or lack thereof) in the context of IPv6-only not intended to highlight a particular vendor's implementation (or
MPLS functionality, but rather to focus on gaps in the standards lack thereof) in the context of IPv6-only MPLS functionality, but
defining the MPLS suite. rather to focus on gaps in the standards defining the MPLS suite.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 24, 2015. This Internet-Draft will expire on February 26, 2015.
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 . . . . . . . . . . . . . . . . . . . . . 4 3.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . . 7
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
3.3. MPLS Applications . . . . . . . . . . . . . . . . . . . . 8 3.3. MPLS Applications . . . . . . . . . . . . . . . . . . . . 8
3.3.1. L2VPN . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. L2VPN . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1.1. EVPN . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1.1. EVPN . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. L3VPN . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.2. L3VPN . . . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . 11
3.3.2.4. NG-MVPN . . . . . . . . . . . . . . . . . . . . . 10 3.3.2.4. MVPN . . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . 13
3.4.2. LSP Ping . . . . . . . . . . . . . . . . . . . . . . 13 3.4.2. LSP Ping . . . . . . . . . . . . . . . . . . . . . . 14
3.4.3. BFD OAM . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.3. BFD OAM . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.4. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 14 3.4.4. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 15
3.4.5. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 15 3.4.5. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 15
3.5. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 16 6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Informative References . . . . . . . . . . . . . . . . . . . 18 9. Informative References . . . . . . . . . . . . . . . . . . . 19
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 28 skipping to change at page 3, line 28
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 RFC 6540's [RFC6540] recommendation that end, and in the spirit of RFC 6540's [RFC6540] recommendation
that implementations need to stop requiring IPv4 for proper and that implementations need to stop requiring IPv4 for proper and
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 and networks that
is not intended to highlight a particular vendor's implementation (or are primarily IPv6 (hereafter referred to as IPv6-primary). This
lack thereof) in the context of IPv6-only MPLS functionality, but document is not intended to highlight a particular vendor's
rather to focus on gaps in the standards defining the MPLS suite. implementation (or lack thereof) in the context of IPv6-only MPLS
functionality, but rather to focus on gaps in the standards defining
the MPLS suite.
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 at least one use case to provide context and discussion of one use case to provide context and justification to
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 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
skipping to change at page 4, line 17 skipping to change at page 4, line 19
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 possible. 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 LSRs and LERs, to have its IPv4 infrastructure, including MPLS Label Switch Routers (LSRs) and Label
addresses reclaimed and transition toward IPv6-only operation. Edge Routers (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 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 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 (Provider Edge (PE) and Provider (P)
transport available, and need to support the full suite of MPLS routers) only have IPv6 transport available, and need to support the
features defined as of the time of this document's writing at parity full suite of MPLS features defined as of the time of this document's
with the support on an IPv4 network. This is necessary whether they writing at parity with the support on an IPv4 network. This is
are enabled via Label Distribution Protocol (LDP) RFC 5036 [RFC5036], necessary whether they are enabled via Label Distribution Protocol
Resource Reservation Protocol Extensions for MPLS Traffic Engineering (LDP) RFC 5036 [RFC5036], Resource Reservation Protocol Extensions
(RSVP-TE) RFC 3209 [RFC3209], or Border Gateway Protocol (BGP) RFC for MPLS Traffic Engineering (RSVP-TE) RFC 3209 [RFC3209], or Border
3107 [RFC3107], and whether they are encapsulated in MPLS RFC 3032 Gateway Protocol (BGP) RFC 3107 [RFC3107], and whether they are
[RFC3032], IP RFC 4023 [RFC4023], Generic Routing Encapsulation (GRE) encapsulated in MPLS RFC 3032 [RFC3032], IP RFC 4023 [RFC4023],
RFC 4023 [RFC4023], or Layer 2 Tunneling Protocol Version 3 (L2TPv3) Generic Routing Encapsulation (GRE) RFC 4023 [RFC4023], or Layer 2
RFC 4817 [RFC4817]. It is important when evaluating these gaps to Tunneling Protocol Version 3 (L2TPv3) RFC 4817 [RFC4817]. It is
distinguish between user data and control plane data, because while important when evaluating these gaps to distinguish between user data
this document is focused on IPv6-only operation, it is quite likely and control plane data, because while this document is focused on
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
characterized as "Major" or "Minor". Major gaps refer to significant
changes necessary in one or more standards to address the gap due to
existing standards language having either missing functionality for
IPv6-only operation or explicit language requiring the use of IPv4
with no IPv6 alternatives defined. Minor gaps refer to changes
necessary primarily to clarify existing standards language. Usually
these changes are needed in order to explicitly codify IPv6 support
in places where it is either implicit or omitted today, but the
omission is unlikely to prevent IPv6-only operation.
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
deficiencies that prohibit it from working in an IPv6-only network. deficiencies that prohibit it from working in an IPv6-only network.
LDP-IPv6 [I-D.ietf-mpls-ldp-ipv6] highlights some of the deficiencies LDP-IPv6 [I-D.ietf-mpls-ldp-ipv6] highlights some of the deficiencies
when LDP is enabled in IPv6 only or dual-stack networks, and when LDP is enabled in IPv6 only or dual-stack networks, and
specifies appropriate protocol changes. These deficiencies are specifies appropriate protocol changes. These deficiencies are
related to LSP mapping, LDP identifiers, LDP discovery, LDP session related to LSP mapping, LDP identifiers, LDP discovery, LDP session
establishment, next hop address and LDP TTL security RFC 5082 establishment, next hop address and LDP Time To Live (TTL) security
[RFC5082] and RFC 6720 [RFC6720]. RFC 5082 [RFC5082] and RFC 6720 [RFC6720].
Gap: Major, update to RFC 5036 in progress that should close this Gap: Major, update to RFC 5036 in progress via LDP-IPv6
gap. [I-D.ietf-mpls-ldp-ipv6] that should close this gap.
3.2.2. Multipoint LDP 3.2.2. Multipoint LDP
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 with regards to control plane (discovery, transport, gaps as LDP (Section 3.2.1) with regards to control plane
and session establishment) in an IPv6-only network. (discovery, transport, and session establishment) in an IPv6-only
network.
2. Multipoint (MP) FEC Root address: mLDP defines its own MP FECs 2. Multipoint (MP) FEC Root address: mLDP defines its own MP
and rules, different from LDP, to map MP LSPs. mLDP MP FEC Forwarding Equivalence Classes (FECs) and rules, different from
contains a Root Address field which is an IP address in IP LDP, to map MP LSPs. mLDP MP FEC contains a Root Address field
networks. The current specification allows specifying Root which is an IP address in IP networks. The current specification
address according to AFI and hence covers both IPv4 or IPv6 root allows specifying Root address according to Address 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 root address to find corresponding upstream table lookup against the root address to find corresponding
neighbor(s). This will pose a problem if an MP LSP traverses upstream neighbor(s). This will pose a problem if an MP LSP
IPv4-only and IPv6-only nodes in a dual-stack network on the way traverses IPv4-only and IPv6-only nodes in a dual-stack network
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 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
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 the similar defined for a BGP-free core in an 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 IPv6-only
backbone receiving an MP FEC element with an IPv4 address. The backbone receiving an MP FEC element with an IPv4 address. The
solution will require a border LSR (the one which is sitting on solution will require a border LSR (the one which is sitting on
border of an IPv4/IPv6 island(s) (R2 and R5) to translate an IPv4 border of an IPv4/IPv6 island(s) (R2 and R5) to translate an IPv4
root address to equivalent IPv6 address (and vice vera) through the root address to equivalent IPv6 address (and vice vera) through
procedures similar to RFC6512. The translation of root address on procedures similar to RFC6512.
borders of IPv4 or IPv6 islands will also be needed for recursive
FECs and procedures defined in RFC6512.
Gap: Major, update in progress for LDP via LDP-IPv6 Gap: Major, update in progress for LDP via LDP-IPv6
[I-D.ietf-mpls-ldp-ipv6], may need additional updates to RFC6512. [I-D.ietf-mpls-ldp-ipv6], may need additional updates to RFC6512.
3.2.3. RSVP- TE 3.2.3. RSVP- TE
Resource Reservation Protocol Extensions for MPLS Traffic Engineering Resource Reservation Protocol Extensions for MPLS Traffic Engineering
(RSVP-TE) RFC 3209 [RFC3209] defines a set of procedures & (RSVP-TE) RFC 3209 [RFC3209] defines a set of procedures and
enhancements to establish label-switched tunnels that can be enhancements to establish label-switched tunnels that can be
automatically routed away from network failures, congestion, and automatically routed away from network failures, congestion, and
bottlenecks. RSVP-TE allows establishing an LSP for an IPv4 or IPv6 bottlenecks. RSVP-TE allows establishing an LSP for an IPv4 or IPv6
prefix, thanks to its LSP_TUNNEL_IPv6 object and subobjects. prefix, thanks to its LSP_TUNNEL_IPv6 object and subobjects.
Gap: None Gap: None
3.2.3.1. IGP 3.2.3.1. IGP
RFC3630 [RFC3630] specifies a method of adding traffic engineering RFC3630 [RFC3630] specifies a method of adding traffic engineering
skipping to change at page 7, line 10 skipping to change at page 7, line 23
RFC5305 [RFC5305] specifies a method of adding traffic engineering RFC5305 [RFC5305] specifies a method of adding traffic engineering
capabilities to IS-IS. New TLVs and sub-TLVs were added in RFC6119 capabilities to IS-IS. New TLVs and sub-TLVs were added in RFC6119
[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-P2MP 3.2.3.2. RSVP-TE-P2MP
RFC4875 [RFC4875] describes extensions to RSVP-TE for the setup of RFC4875 [RFC4875] describes extensions to RSVP-TE for the setup of
point-to-multipoint (P2MP) LSPs in MPLS and GMPLS with support for point-to-multipoint (P2MP) LSPs in MPLS and Generalized MPLS (GMPLS)
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)
RFC4090 [RFC4090] specifies FRR mechanisms to establish backup LSP RFC4090 [RFC4090] specifies FRR mechanisms to establish backup LSP
tunnels for local repair supporting both IPv4 and IPv6 networks. tunnels for local repair supporting both IPv4 and IPv6 networks.
Further RFC5286 [RFC5286] describes the use of loop-free alternates Further RFC5286 [RFC5286] describes the use of loop-free alternates
to provide local protection for unicast traffic in pure IP and MPLS to provide local protection for unicast traffic in pure IP and MPLS
networks in the event of a single failure, whether link, node, or networks in the event of a single failure, whether link, node, or
skipping to change at page 8, line 23 skipping to change at page 8, line 32
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.
Section 5.3, second paragraph of RFC6370 [RFC6370] describes the Section 5.3, second paragraph of RFC6370 [RFC6370] describes the
mapping from an MPLS-TP LSP_ID to RSVP-TE with an assumption that mapping from an MPLS Transport Profile (MPLS-TP) LSP_ID to RSVP-TE
Node_IDs are derived from valid IPv4 addresses. This assumption with an assumption that Node_IDs are derived from valid IPv4
fails in an IPv6-only network, given that there wouldn't be any IPv4 addresses. This assumption fails in an IPv6-only network, given that
addresses. there wouldn't be any IPv4 addresses.
Gap: Minor; Section 5.3. of RFC6370 needs to be updated. 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
skipping to change at page 9, line 6 skipping to change at page 9, line 17
using BGP for both discovery and signaling. 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 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 (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 Network Layer Reachability Information
differentiate its AFI/SAFI encoding from RFC4761). This means that (NLRI), and should not exceed 12 bytes (to differentiate its AFI/SAFI
PE IP address can NOT be an IPv6 address. Also, in its signaling (Subsequent Address Family Identifier) encoding from RFC4761). This
procedures (section 3.2.3), it suggests encoding PE_addr in SAII and means that PE IP address can NOT be an IPv6 address. Also, in its
TAII, which are limited to 32-bit (AII Type=1) at the moment. signaling procedures (section 3.2.3), it suggests encoding PE_addr in
Source Attachment Individual Identifier (SAII) and Target Attachment
Individual Identifier (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, RFC 6073 [RFC6073] defines the new LDP Pseudowire (PW) Switching
which supports IPv4 and IPv6. 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 Ethernet VPN (EVPN) [I-D.ietf-l2vpn-evpn] defines a method for using
is out of scope for this gap analysis. Instead, the authors of that BGP MPLS-based Ethernet VPNs. Because it can use functions in LDP
draft need to ensure that it supports IPv6-only operation, or if it and mLDP, as well as RFC 7117 [RFC7117] Multicast VPLS, it inherits
cannot, identify dependencies on underlying gaps in MPLS protocol(s) gaps previously identified in LDP (Section 3.2.1) and RFC 6074
that must be resolved before it can support IPv6-only operation. [RFC6074]. Once those gaps are resolved, it should function properly
on IPv6-only networks as defined.
3.3.2. L3VPN 3.3.2. 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 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 a VPN-IPv4 address family, but not a VPN-IPv6 address RFC4364 defines Layer 3 Virtual Private Networks (L3VPNs) for IPv4
family. RFC 4659 [RFC4659] corrects this oversight. Also, Section 5 only and has references to 32-bit BGP next hop addresses. RFC 4659
of RFC 4364 [RFC4364] assumes that the BGP next-hop contains exactly [RFC4659] adds support for IPv6 on L3VPNs including 128-bit BGP next
32 bits. This text should be generalized to include 128 bit next- hop addresses, and discusses operation whether IPv6 is the payload or
hops as well. Section 3.2.1.1 of RFC 4659 [RFC4659] does actually the underlying transport address family. However, RFC4659 does not
specifies a 128-bit BGP next-hop. formally update RFC4364, and thus an implementer may miss this
additional set of standards unless it is explicitly identified
independently of the base functionality defined in RFC4364. An
erratum has been filed to correct this metadata problem. Further,
section 1 of RFC4659 explicitly identifies use case #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. RFC4364 must be updated, and RFC4659 may need to be Gap: Major. RFC4659 needs to be updated to explicitly cover use case
updated to explicitly cover use case #2. (Discussed in further #2. (Discussed in further detail below)
detail below)
3.3.2.1. 6PE/4PE 3.3.2.1. 6PE/4PE
RFC 4798 [RFC4798] defines 6PE, which defines how to interconnect RFC 4798 [RFC4798] defines IPv6 Provider Edge (6PE), which defines
IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 how to interconnect IPv6 islands over a MPLS-enabled IPv4 cloud.
cloud. However, use case 2 is doing the opposite, and thus could However, use case 2 is doing the opposite, and thus could also be
also be referred to as 4PE. The method to support this use case is referred to as IPv4 Provider Edge (4PE). The method to support this
not defined explicitly. To support it, IPv4 edge devices need to be use case is not defined explicitly. To support it, IPv4 edge devices
able to map IPv4 traffic to MPLS IPv6 core LSP's. Also, the core need to be able to map IPv4 traffic to MPLS IPv6 core LSP's. Also,
switches may not understand IPv4 at all, but in some cases they may the core switches may not understand IPv4 at all, but in some cases
need to be able to exchange Labeled IPv4 routes from one AS to a they may need to be able to exchange Labeled IPv4 routes from one AS
neighboring AS. to a neighboring AS.
Gap: Major. RFC4798 covers only the "6PE" case. Use case #2 is Gap: Major. RFC4798 covers only the "6PE" case. Use case #2 is
currently not specified in an RFC. 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 IPv6 Virtual Private Network Extension
may use its packet-switched backbone to provide Virtual Private (6VPE), a method by which a Service Provider may use its packet-
Network (VPN) services for its IPv6 customers. It allows the core switched backbone to provide Virtual Private Network (VPN) services
network to be MPLS IPv4 or MPLS IPv6, thus addressing use case 1 for its IPv6 customers. It allows the core network to be MPLS IPv4
above. RFC4364 should work as defined for use case 2 above, which or MPLS IPv6, thus addressing use case 1 above. RFC4364 should work
could also be referred to as 4VPE, but the RFC does not explicitly as defined for use case 2 above, which could also be referred to as
discuss this use. IPv4 Virtual Private Extension (4VPE), but the RFC explicitly does
not discuss this use and defines it as out of scope.
Gap: Minor. RFC4659 may need to be updated to explicitly cover use Gap: Minor. RFC4659 needs to be updated to explicitly cover use case
case #2 #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 tunneling Tunnel Encapsulation Attribute, which can be used to signal tunneling
over a single-Address Family IP core. This mechanism supports over a single-Address Family IP core. This mechanism supports
transport of MPLS (and other protocols) over Tunnels in an IP core transport of MPLS (and other protocols) over Tunnels in an IP core
(including an IPv6-only core). In this context, load-balancing can (including an IPv6-only core). In this context, load-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. 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 an MPLS VPN backbone for downstream customers. It is sometimes
below set of protocols: referred to as Next Generation Multicast VPN (NG-MVPN) The procedure
involves the below set of protocols:
3.3.2.4.1. PE-CE Multicast Routing Protocol 3.3.2.4.1. PE-CE Multicast Routing Protocol
RFC 6513 [RFC6513] explains the use of PIM as PE-CE protocol while RFC 6513 [RFC6513] explains the use of Protocol Independent Multicast
(PIM) as 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 PE-
CE protocol. 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 PE-CE
protocol. The issue is explained in section 2 of protocol. The issue is explained in section 2 of
[I-D.ietf-l3vpn-mvpn-mldp-nlri] along with new route-type that [I-D.ietf-l3vpn-mvpn-mldp-nlri] along with 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 [I-D.ietf-l3vpn-mvpn-pe-ce] defines the use of BGP as PE-CE
skipping to change at page 11, line 33 skipping to change at page 12, line 4
RFC 6513 [RFC6513] explains the use of the below tunnels: RFC 6513 [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
Gap: Gaps in RSVP-TE P2MP LSP and mLDP P2MP and MP2MP LSP are covered Gap: Gaps in RSVP-TE P2MP LSP (Section 3.2.3.2) and mLDP
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
PIM Tree and Ingress Replication are out of the scope of this and any protocol-specific gaps not related to MPLS are outside the
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 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 PE-PE
protocol. protocol.
PE-PE multicast routing is not specific to P-tunnel or to MPLS. It
can be PIM or BGP with label based or PIM tree based P-Tunnels.
Enabling PIM as a PE-PE multicast protocol is equivalent to running
it on a non-MPLS IPv6 network, so there are not any MPLS-specific
considerations, and any gaps are applicable for non-MPLS networks as
well. Similarly, BGP only includes the PMSI tunnel attribute as a
part of the NLRI which is inherited from P-tunnel instantiation and
considered to be an opaque value. So 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 PE-PE Multicast Routing protocol are
outside the scope of this document not unique to MPLS, and therefore are outside the scope of this
document. It is included for completeness.
3.3.3. MPLS-TP 3.3.3. 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. Therefore this is considered out of scope for this document, but is
included for completeness.
Gap: None. Gap: None.
3.4. MPLS OAM 3.4. MPLS OAM
For MPLS LSPs, there are primarily three OAM mechanisms: Extended For MPLS LSPs, there are primarily three Operations, Administration,
ICMP RFC 4884 [RFC4884] RFC 4950 [RFC4950], LSP Ping RFC 4379 and Maintenance (OAM) mechanisms: Extended ICMP RFC 4884 [RFC4884]
[RFC4379], and BFD for MPLS LSPs RFC 5884 [RFC5884]. For MPLS RFC 4950 [RFC4950], LSP Ping RFC 4379 [RFC4379], and Bidirectional
Pseudowires, there is also Virtual Circuit Connectivity Verification Forwarding Detection (BFD) for MPLS LSPs RFC 5884 [RFC5884]. For
(VCCV) RFC 5085 [RFC5085] RFC 5885 [RFC5885]. All of these MPLS Pseudowires, there is also Virtual Circuit Connectivity
mechanisms work in pure IPv6 environments. The next subsections Verification (VCCV) RFC 5085 [RFC5085] RFC 5885 [RFC5885]. Most of
cover these in detail. these mechanisms work in pure IPv6 environments, but there are some
problems encountered in mixed environments due to address-family
mismatches. The next subsections cover these gaps in detail.
Gap: Major. RFC4379 needs to be updated for multipath IPv6. Gap: Major. RFC4379 needs to be updated to better support multipath
Additionally, there is potential for dropped messages in Extended IPv6. Additionally, there is potential for dropped messages in
ICMP and LSP ping due to IP version mismatches. It is important to Extended ICMP and LSP ping due to IP version mismatches. It is
note that this is a more generic problem with tunneling when IP important to note that this is a more generic problem with tunneling
address family mismatches exist, and is not specific to MPLS, so when IP address family mismatches exist, and is not specific to MPLS,
while MPLS will be affected, it will be difficult to fix this problem so while MPLS will be affected, it will be difficult to fix this
specifically for MPLS, rather than fixing the more generic problem. problem specifically for MPLS, rather than fixing the more generic
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 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
skipping to change at page 13, line 28 skipping to change at page 14, line 10
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. LSP Ping 3.4.2. 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 later specified for IPv6 The only exceptions are the Pseudowire FECs, which are later
in RFC 6829 [RFC6829]. specified for IPv6 in RFC 6829 [RFC6829]. The multipath information
also includes IPv6 encodings (see Section 3.3.1 of RFC 4379).
The multipath information includes also IPv6 encodings (see
Section 3.3.1 of RFC 4379).
RFC 4379 does not define the value to be used in the IPv6 Router LSP Ping packets are UDP packets over either IPv4 or IPv6 (see
Alert option (RAO). For IPv4 RAO, a value of zero is used. However, Section 4.3 of RFC 4379). However, for IPv6 the destination IP
there is no equivalent value for IPv6 RAO. This gap needs to be address is a (randomly chosen) IPv6 address from the range
fixed to be able to use LSP Ping in IPv6 networks. Further details 0:0:0:0:0:FFFF:127/104. That is, using an IPv4-mapped IPv6 address.
on this gap are captured, along with a proposed solution, in This is a transitional mechanism that should not bleed into IPv6-only
[I-D.raza-mpls-oam-ipv6-rao]. networks, as [I-D.itojun-v6ops-v4mapped-harmful] explains. The issue
is that the MPLS LSP Ping mechanism needs a range of loopback IP
addresses to be used as destination addresses to exercise Equal Cost
Multiple Path (ECMP), but the IPv6 address architecture specifies a
single address (::1/128) for loopback. A mechanism to achieve this
was proposed in [I-D.smith-v6ops-larger-ipv6-loopback-prefix].
Additionally, LSP Ping packets are UDP packets over both IPv4 and Additionally, RFC 4379 does not define the value to be used in the
IPv6 (see Section 4.3 of RFC 4379). However, for IPv6, the IPv6 Router Alert option (RAO). For IPv4 RAO, a value of zero is
destination IP address is a (randomly chosen) IPv6 address from the used. However, there is no equivalent value for IPv6 RAO. This gap
range 0:0:0:0:0:FFFF:127/104. That is, using an IPv4-mapped IPv6 needs to be fixed to be able to use LSP Ping in IPv6 networks.
address. This is a transitional mechanism that should not bleed into Further details on this gap are captured, along with a proposed
IPv6-only networks, as [I-D.itojun-v6ops-v4mapped-harmful] explains. solution, in [I-D.raza-mpls-oam-ipv6-rao].
The issue is that the MPLS LSP Ping mechanism needs a range of
loopback IP addresses to be used as destination addresses to exercise
ECMPs, but the IPv6 address architecture specifies a single address
(::1/128) for loopback. A mechanism to achieve this was proposed in
[I-D.smith-v6ops-larger-ipv6-loopback-prefix].
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
skipping to change at page 15, line 15 skipping to change at page 15, line 43
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-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, but is included for completeness.
Gap: None. Gap: None.
3.5. MIBs 3.5. MIBs
RFC3811 [RFC3811] defines the textual conventions for MPLS. These RFC3811 [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
MIB specification RFC3812 [RFC3812], GMPLS TE MIB specification Management Information Base (MIB) specification RFC3812 [RFC3812],
RFC4802 [RFC4802] and Fast ReRoute (FRR) extension RFC6445 [RFC6445]. GMPLS TE MIB specification RFC4802 [RFC4802] and Fast ReRoute (FRR)
3811bis [I-D.manral-mpls-rfc3811bis] tries to resolve this gap by extension RFC6445 [RFC6445]. 3811bis [I-D.manral-mpls-rfc3811bis]
marking this textual convention as obsolete. tries to resolve this gap by marking this textual convention as
obsolete.
The other MIB specifications for LSR RFC3813 [RFC3813], LDP RFC3815 The other MIB specifications for LSR RFC3813 [RFC3813], LDP RFC3815
[RFC3815] and TE RFC4220 [RFC4220] have support for both IPv4 and [RFC3815] and TE RFC4220 [RFC4220] have support for both IPv4 and
IPv6. IPv6.
Gap: Major. Work underway to update RFC3811, may also need to update Gap: Major. Work underway to update RFC3811 via 3811bis
RFC3812, RFC4802, and RFC6445, which depend on it. [I-D.manral-mpls-rfc3811bis], may also need to update RFC3812,
RFC4802, and RFC6445, which depend on it.
4. Gap Summary 4. Gap Summary
This draft has reviewed a wide variety of MPLS features and protocols This draft has reviewed a wide variety of MPLS features and protocols
to determine their suitability for use on IPv6-only networks. While to determine their suitability for use on IPv6-only or IPv6-primary
some parts of the MPLS suite will function properly without networks. While some parts of the MPLS suite will function properly
additional changes, gaps have been identified in others, which will without additional changes, gaps have been identified in others,
need to be addressed with follow-on work. This section will which will need to be addressed with follow-on work. This section
summarize those gaps, along with pointers to any work-in-progress to will summarize those gaps, along with pointers to any work in
address them. progress to address them. Note that because the referenced drafts
are works in progress and do not have consensus at the time of this
document's publication, there could be other solutions proposed at a
future time, and the pointers in this document should not be
considered normative in any way. Additionally, work in progress on
new features that use MPLS protocols will need to ensure that those
protocols support operation on IPv6-only or IPv6-primary networks, or
explicitly identify any dependencies on existing gaps that, once
resolved, will allow proper IPv6-only operation.
Identifed gaps in MPLS for IPv6-only networks Identifed gaps in MPLS for IPv6-only networks
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| 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 | |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| mLDP | inherits gaps from LDP, | inherits LDP-IPv6 |
| S.3.2.2 | RFC6512 [RFC6512] | [I-D.ietf-mpls-ldp-ipv6], |
| | | additional fixes TBD |
+---------+--------------------------+------------------------------+
| GMPLS | RFC6370 [RFC6370] Node | TBD | | GMPLS | RFC6370 [RFC6370] Node | TBD |
| S.3.2.6 | ID derivation | | | 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 4659 [RFC4659] | TBD |
| S.3.3.2 | next-hop, define method | | | S.3.3.2 | define method for | |
| | for 4PE/4VPE | | | | 4PE/4VPE | |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| OAM | RFC 4379 [RFC4379] no | IPv6 RAO for MPLS OAM | | OAM | RFC 4379 [RFC4379] no | IPv6 RAO for MPLS OAM |
| S.3.4 | IPv6 multipath support, | [I-D.raza-mpls-oam-ipv6-rao] | | S.3.4 | IPv6 multipath support, | [I-D.raza-mpls-oam-ipv6-rao] |
| | no IPv6 RAO, possible | | | | no IPv6 RAO, possible | |
| | dropped messages in IP | | | | dropped messages in IP | |
| | version mismatch | | | | version 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, Loa Andersson, David The authors wish to thank Alvaro Retana, Andrew Yourtchenko, Loa
Allan, Mach Chen, Mustapha Aissaoui, and Mark Tinka for their Andersson, David Allan, Mach Chen, Mustapha Aissaoui, and Mark Tinka
detailed reviews, as well as Brian Haberman, Joel Jaeggli, Adrian for their detailed reviews, as well as Brian Haberman, Joel Jaeggli,
Farrell, and Nobo Akiya for their comments. Adrian Farrell, and Nobo Akiya 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
skipping to change at page 18, line 20 skipping to change at page 19, line 27
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
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, however,
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
security.
9. Informative References 9. Informative References
[I-D.ietf-l2vpn-evpn] [I-D.ietf-l2vpn-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", draft-ietf-l2vpn- Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-
evpn-07 (work in progress), May 2014. evpn-07 (work in progress), May 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-05 (work in progress), May 2014. l3vpn-mvpn-mldp-nlri-05 (work in progress), May 2014.
[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-01 (work in CE Protocol", draft-ietf-l3vpn-mvpn-pe-ce-01 (work in
progress), March 2014. progress), March 2014.
[I-D.ietf-mpls-ldp-ipv6] [I-D.ietf-mpls-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-12 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-13
(work in progress), February 2014. (work in progress), July 2014.
[I-D.itojun-v6ops-v4mapped-harmful] [I-D.itojun-v6ops-v4mapped-harmful]
Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire
Considered Harmful", draft-itojun-v6ops-v4mapped- Considered Harmful", draft-itojun-v6ops-v4mapped-
harmful-02 (work in progress), October 2003. harmful-02 (work in progress), October 2003.
[I-D.manral-mpls-rfc3811bis] [I-D.manral-mpls-rfc3811bis]
Manral, V., Tsou, T., Will, W., and F. Fondelli, Manral, V., Tsou, T., Will, W., and F. Fondelli,
"Definitions of Textual Conventions (TCs) for "Definitions of Textual Conventions (TCs) for
Multiprotocol Label Switching (MPLS) Management", draft- Multiprotocol Label Switching (MPLS) Management", draft-
skipping to change at page 24, line 22 skipping to change at page 25, line 33
[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.
[RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C.
Kodeboniya, "Multicast in Virtual Private LAN Service
(VPLS)", RFC 7117, February 2014.
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
 End of changes. 58 change blocks. 
192 lines changed or deleted 248 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/