draft-ietf-mpls-ipv6-only-gap-02.txt   draft-ietf-mpls-ipv6-only-gap-03.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: February 26, 2015 Cisco Expires: May 1, 2015 Cisco
August 25, 2014 October 28, 2014
Gap Analysis for Operating IPv6-only MPLS Networks Gap Analysis for Operating IPv6-only MPLS Networks
draft-ietf-mpls-ipv6-only-gap-02 draft-ietf-mpls-ipv6-only-gap-03
Abstract Abstract
This document reviews the Multiprotocol Label Switching (MPLS) This document reviews the Multiprotocol Label Switching (MPLS)
protocol suite in the context of IPv6 and identifies gaps that must protocol suite in the context of IPv6 and identifies gaps that must
be addressed in order to allow MPLS-related protocols and be addressed in order to allow MPLS-related protocols and
applications to be used with IPv6-only networks. This document is applications to be used with IPv6-only networks. This document is
not intended to highlight a particular vendor's implementation (or 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.
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 February 26, 2015. This Internet-Draft will expire on May 1, 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 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . . . 5
3.2. MPLS Control Plane . . . . . . . . . . . . . . . . . . . 5 3.2. MPLS Control Plane . . . . . . . . . . . . . . . . . . . 5
3.2.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Label Distribution Protocol (LDP) . . . . . . . . . . 5
3.2.2. Multipoint LDP . . . . . . . . . . . . . . . . . . . 5 3.2.2. Multipoint LDP (mLDP) . . . . . . . . . . . . . . . . 5
3.2.3. RSVP- TE . . . . . . . . . . . . . . . . . . . . . . 6 3.2.3. RSVP - Traffic Engineering (RSVP-TE) . . . . . . . . 6
3.2.3.1. IGP . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.3.1. Interior Gateway Protocol (IGP) . . . . . . . . . 7
3.2.3.2. RSVP-TE-P2MP . . . . . . . . . . . . . . . . . . 7 3.2.3.2. RSVP-TE - Point-to-Multipoint (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. Path Computation Element (PCE) . . . . . . . . . . . 7
3.2.5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.5. Border Gateway Protocol (BGP) . . . . . . . . . . . . 8
3.2.6. GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.6. Generalized Multi-Protocol Label Switching (GMPLS) . 8
3.3. MPLS Applications . . . . . . . . . . . . . . . . . . . . 8 3.3. MPLS Applications . . . . . . . . . . . . . . . . . . . . 8
3.3.1. L2VPN . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. Layer 2 Virtual Private Network (L2VPN) . . . . . . . 8
3.3.1.1. EVPN . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1.1. Ethernet VPN (EVPN) . . . . . . . . . . . . . . . 9
3.3.2. L3VPN . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.2. Layer 3 Virtual Private Network (L3VPN) . . . . . . . 10
3.3.2.1. 6PE/4PE . . . . . . . . . . . . . . . . . . . . . 10 3.3.2.1. IPv6 Provider Edge/IPv4 Provider Edge (6PE/4PE) . 10
3.3.2.2. 6VPE/4VPE . . . . . . . . . . . . . . . . . . . . 10 3.3.2.2. IPv6 Virtual Private Extension/IPv4 Virtual
3.3.2.3. BGP Encapsulation SAFI . . . . . . . . . . . . . 11 Private Extension (6VPE/4VPE) . . . . . . . . . . 11
3.3.2.4. MVPN . . . . . . . . . . . . . . . . . . . . . . 11 3.3.2.3. BGP Encapsulation Subsequent Address Family
3.3.3. MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . 12 Identifier (SAFI) . . . . . . . . . . . . . . . . 11
3.4. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.2.4. Multicast in MPLS/BGP IP VPN (MVPN) . . . . . . . 11
3.3.3. MPLS Transport Profile (MPLS-TP) . . . . . . . . . . 12
3.4. MPLS Operations, Administration, and Maintenance (MPLS
OAM) . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 13 3.4.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 13
3.4.2. LSP Ping . . . . . . . . . . . . . . . . . . . . . . 14 3.4.2. Label Switched Path Ping (LSP Ping) . . . . . . . . . 14
3.4.3. BFD OAM . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.3. Bidirectional Forwarding Detection (BFD) . . . . . . 15
3.4.4. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 15 3.4.4. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 15
3.4.5. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 15 3.4.5. MPLS Transport Profile (MPLS-TP) OAM . . . . . . . . 16
3.5. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5. MIB Modules . . . . . . . . . . . . . . . . . . . . . . . 16
4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18 6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Informative References . . . . . . . . . . . . . . . . . . . 19 9. Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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
can continue using IPv4 as necessary. However, as IPv6 deployment can continue using IPv4 as necessary. However, as IPv6 deployment
and usage becomes more pervasive, and IPv4 exhaustion begins driving and usage becomes more pervasive, and IPv4 exhaustion begins driving
changes in address consumption behaviors, there is an increasing changes in address consumption behaviors, there is an increasing
likelihood that many networks will need to start operating some or likelihood that many networks will need to start operating some or
all of their network nodes either as primarily IPv6 (most functions all of their network nodes either as primarily IPv6 (most functions
use IPv6, a few legacy features use IPv4), or as IPv6-only (no IPv4 use IPv6, a few legacy features use IPv4), or as IPv6-only (no IPv4
provisioned on the device). This transition toward IPv6-only provisioned on the device). This transition toward IPv6-only
operation exposes any gaps where features, protocols, or operation exposes any gaps where features, protocols, or
implementations are still reliant on IPv4 for proper function. To implementations are still reliant on IPv4 for proper function. To
that end, and in the spirit of RFC 6540's [RFC6540] recommendation that end, and in the spirit of the recommendation in RFC 6540
that implementations need to stop requiring IPv4 for proper and [RFC6540] that implementations need to stop requiring IPv4 for proper
complete function, this document reviews the Multi-Protocol Label and 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 and networks that and applications to be used with IPv6-only networks and networks that
are primarily IPv6 (hereafter referred to as IPv6-primary). This are primarily IPv6 (hereafter referred to as IPv6-primary). This
document is not intended to highlight a particular vendor's document is not intended to highlight a particular vendor's
implementation (or lack thereof) in the context of IPv6-only MPLS implementation (or lack thereof) in the context of IPv6-only MPLS
functionality, but rather to focus on gaps in the standards defining functionality, but rather to focus on gaps in the standards defining
the MPLS suite. the MPLS suite.
2. Use Case 2. Use Case
skipping to change at page 5, line 22 skipping to change at page 5, line 22
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.
Gap: None. Gap: None.
3.2. MPLS Control Plane 3.2. MPLS Control Plane
3.2.1. LDP 3.2.1. Label Distribution Protocol (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 Time To Live (TTL) security establishment, next hop address and LDP Time To Live (TTL) security
RFC 5082 [RFC5082] and RFC 6720 [RFC6720]. RFC 5082 [RFC5082] and RFC 6720 [RFC6720].
Gap: Major, update to RFC 5036 in progress via LDP-IPv6 Gap: Major, update to RFC 5036 in progress via LDP-IPv6
[I-D.ietf-mpls-ldp-ipv6] that should close this gap. [I-D.ietf-mpls-ldp-ipv6] that should close this gap.
3.2.2. Multipoint LDP 3.2.2. Multipoint LDP (mLDP)
Multipoint LDP (mLDP) is a set of extensions to LDP for setting up Multipoint LDP (mLDP) is a set of extensions to LDP for setting up
Point to Multipoint (P2MP) and Multipoint to Multipoint (MP2MP) LSPs. Point to Multipoint (P2MP) and Multipoint to Multipoint (MP2MP) LSPs.
These extensions are specified in RFC 6388 [RFC6388]. In terms of These extensions are specified in RFC 6388 [RFC6388]. In terms of
IPv6-only gap analysis, mLDP has two identified areas of interest: IPv6-only gap analysis, mLDP has two identified areas of interest:
1. LDP Control plane: Since mLDP uses the LDP control plane to 1. LDP Control plane: Since mLDP uses the LDP control plane to
discover and establish sessions with the peer, it shares the same discover and establish sessions with the peer, it shares the same
gaps as LDP (Section 3.2.1) with regards to control plane gaps as LDP (Section 3.2.1) with regards to control plane
(discovery, transport, and session establishment) in an IPv6-only (discovery, transport, and session establishment) in an IPv6-only
skipping to change at page 6, line 39 skipping to change at page 6, line 39
the first IPv6-only transit/branch LSRs (R3) when trying to find IPv4 the first IPv6-only transit/branch LSRs (R3) when trying to find IPv4
root address reachability. RFC 6512 [RFC6512] defines a recursive- root address reachability. RFC 6512 [RFC6512] defines a recursive-
FEC solution and procedures for mLDP when the backbone (transit/ FEC solution and procedures for mLDP when the backbone (transit/
branch) LSRs have no route to the root. The proposed solution is branch) LSRs have no route to the root. The proposed solution is
defined for a BGP-free core in an VPN environment, but a similar defined for a BGP-free core in 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 root address to equivalent IPv6 address (and vice vera) through
procedures similar to RFC6512. procedures similar to RFC 6512.
Gap: Major, update in progress for LDP via LDP-IPv6 Gap: Major, update in progress for LDP via LDP-IPv6
[I-D.ietf-mpls-ldp-ipv6], may need additional updates to RFC6512. [I-D.ietf-mpls-ldp-ipv6], may need additional updates to RFC 6512.
3.2.3. RSVP- TE 3.2.3. RSVP - Traffic Engineering (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 and (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. Interior Gateway Protocol (IGP)
RFC3630 [RFC3630] specifies a method of adding traffic engineering RFC 3630 [RFC3630] specifies a method of adding traffic engineering
capabilities to OSPF Version 2. New TLVs and sub-TLVs were added in capabilities to OSPF Version 2. New TLVs and sub-TLVs were added in
RFC5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF RFC 5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF
Version 3. Version 3.
RFC5305 [RFC5305] specifies a method of adding traffic engineering RFC 5305 [RFC5305] specifies a method of adding traffic engineering
capabilities to IS-IS. New TLVs and sub-TLVs were added in RFC6119 capabilities to IS-IS. New TLVs and sub-TLVs were added in RFC 6119
[RFC6119] to extend TE capabilities to IPv6 networks. [RFC6119] to extend TE capabilities to IPv6 networks.
Gap: None Gap: None
3.2.3.2. RSVP-TE-P2MP 3.2.3.2. RSVP-TE - Point-to-Multipoint (P2MP)
RFC4875 [RFC4875] describes extensions to RSVP-TE for the setup of RFC 4875 [RFC4875] describes extensions to RSVP-TE for the setup of
point-to-multipoint (P2MP) LSPs in MPLS and Generalized MPLS (GMPLS) point-to-multipoint (P2MP) LSPs in MPLS and Generalized MPLS (GMPLS)
with support for both IPv4 and IPv6. with support for both IPv4 and IPv6.
Gap: None Gap: None
3.2.3.3. RSVP-TE Fast Reroute (FRR) 3.2.3.3. RSVP-TE Fast Reroute (FRR)
RFC4090 [RFC4090] specifies FRR mechanisms to establish backup LSP RFC 4090 [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 RFC 5286 [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
shared risk link group (SRLG) for both IPv4 and IPv6. shared risk link group (SRLG) for both IPv4 and IPv6.
Gap: None Gap: None
3.2.4. Controller, PCE 3.2.4. Path Computation Element (PCE)
The Path Computation Element (PCE) defined in RFC4655 [RFC4655] is an The Path Computation Element (PCE) defined in RFC 4655 [RFC4655] is
entity that is capable of computing a network path or route based on an entity that is capable of computing a network path or route based
a network graph, and applying computational constraints. A Path on a network graph, and applying computational constraints. A Path
Computation Client (PCC) may make requests to a PCE for paths to be Computation Client (PCC) may make requests to a PCE for paths to be
computed. The PCE communication protocol (PCEP) is designed as a computed. The PCE Communication Protocol (PCEP) is designed as a
communication protocol between PCCs and PCEs for path computations communication protocol between PCCs and PCEs for path computations
and is defined in RFC5440 [RFC5440]. and is defined in RFC 5440 [RFC5440].
The PCEP specification RFC5440 [RFC5440] is defined for both IPv4 and The PCEP specification RFC 5440 [RFC5440] is defined for both IPv4
IPv6 with support for PCE discovery via an IGP (OSPF RFC5088 and IPv6 with support for PCE discovery via an IGP (OSPF RFC 5088
[RFC5088], or ISIS RFC5089 [RFC5089]) using both IPv4 and IPv6 [RFC5088], or ISIS RFC 5089 [RFC5089]) using both IPv4 and IPv6
addresses. Note that PCEP uses identical encoding of subobjects as addresses. Note that PCEP uses identical encoding of subobjects as
in the Resource Reservation Protocol Traffic Engineering Extensions in the Resource Reservation Protocol Traffic Engineering Extensions
(RSVP-TE) defined in RFC3209 [RFC3209] which supports both IPv4 and (RSVP-TE) defined in RFC 3209 [RFC3209] which supports both IPv4 and
IPv6. IPv6.
The extensions of PCEP to support confidentiality RFC5520 [RFC5520], The extensions of PCEP to support confidentiality RFC 5520 [RFC5520],
Route Exclusion RFC5521, [RFC5521] Monitoring RFC5886 [RFC5886], and Route Exclusion RFC 5521, [RFC5521] Monitoring RFC 5886 [RFC5886],
P2MP RFC6006 [RFC6006] have support for both IPv4 and IPv6. and P2MP RFC 6006 [RFC6006] have support for both IPv4 and IPv6.
Gap: None. Gap: None.
3.2.5. BGP 3.2.5. Border Gateway Protocol (BGP)
RFC3107 [RFC3107] specifies a set of BGP protocol procedures for RFC 3107 [RFC3107] specifies a set of BGP protocol procedures for
distributing the labels (for prefixes corresponding to any address- distributing the labels (for prefixes corresponding to any address-
family) between label switch routers so that they can use the labels family) between label switch routers so that they can use the labels
for forwarding the traffic. RFC3107 allows BGP to distribute the for forwarding the traffic. RFC 3107 allows BGP to distribute the
label for IPv4 or IPv6 prefix in an IPv6 only network. label for IPv4 or IPv6 prefix in an IPv6 only network.
Gap: None. Gap: None.
3.2.6. GMPLS 3.2.6. Generalized Multi-Protocol Label Switching (GMPLS)
RFC4558 [RFC4558] specifies Node-ID Based RSVP Hello Messages with The Generalized Multi-Protocol Label Switching (GMPLS) specification
capability for both IPv4 and IPv6. RFC4990 [RFC4990] clarifies the includes singaling functional extensions RFC 3471 [RFC3471] and RSVP-
TE extensions RFC 3473 [RFC3473]. The gap analysis on Section 3.2.3
applies to these.
RFC 4558 [RFC4558] specifies Node-ID Based RSVP Hello Messages with
capability for both IPv4 and IPv6. RFC 4990 [RFC4990] clarifies the
use of IPv6 addresses in GMPLS networks including handling in the MIB 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 RFC 6370 [RFC6370] describes the
mapping from an MPLS Transport Profile (MPLS-TP) LSP_ID to RSVP-TE mapping from an MPLS Transport Profile (MPLS-TP) LSP_ID to RSVP-TE
with an assumption that Node_IDs are derived from valid IPv4 with an assumption that Node_IDs are derived from valid IPv4
addresses. This assumption fails in an IPv6-only network, given that addresses. This assumption fails in an IPv6-only network, given that
there wouldn't be any IPv4 addresses. there would not be any IPv4 addresses.
Gap: Minor; Section 5.3. of RFC6370 needs to be updated. Gap: Minor; Section 5.3. of RFC 6370 needs to be updated.
3.3. MPLS Applications 3.3. MPLS Applications
3.3.1. L2VPN 3.3.1. Layer 2 Virtual Private Network (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
respectively in an MPLS network using LDP as the signaling protocol. respectively in an MPLS network using LDP as the signaling protocol.
This is complemented by RFC 6074 [RFC6074], which specifies a set of This is complemented by RFC 6074 [RFC6074], which specifies a set of
procedures for instantiating L2VPNs (e.g. VPWS, VPLS) using BGP as procedures for instantiating L2VPNs (e.g. VPWS, VPLS) using BGP as
discovery protocol and LDP as well as L2TPv3 as signaling protocol. discovery protocol and LDP as well as L2TPv3 as signaling protocol.
skipping to change at page 9, line 19 skipping to change at page 9, line 23
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 Network Layer Reachability Information ID, which is encoded in Network Layer Reachability Information
(NLRI), and should not exceed 12 bytes (to differentiate its AFI/SAFI (NLRI), and should not exceed 12 bytes (to differentiate its AFI/SAFI
(Subsequent Address Family Identifier) encoding from RFC4761). This (Subsequent Address Family Identifier) encoding from RFC 4761). This
means that PE IP address can NOT be an IPv6 address. Also, in its means that PE IP address can NOT be an IPv6 address. Also, in its
signaling procedures (section 3.2.3), it suggests encoding PE_addr in signaling procedures (section 3.2.3), it suggests encoding PE_addr in
Source Attachment Individual Identifier (SAII) and Target Attachment Source Attachment Individual Identifier (SAII) and Target Attachment
Individual Identifier (TAII), which are limited to 32-bit (AII Individual Identifier (TAII), which are limited to 32-bit (AII
Type=1) at the moment. Type=1) at the moment.
RFC 6073 [RFC6073] defines the new LDP Pseudowire (PW) Switching RFC 6073 [RFC6073] defines the new LDP Pseudowire (PW) Switching
Point PE TLV, which supports IPv4 and IPv6. Point PE TLV, which supports IPv4 and IPv6.
Gap: Minor. RFC6074 needs to be updated. Gap: Minor. RFC 6074 needs to be updated.
3.3.1.1. EVPN 3.3.1.1. Ethernet VPN (EVPN)
Ethernet VPN (EVPN) [I-D.ietf-l2vpn-evpn] defines a method for using Ethernet VPN (EVPN) [I-D.ietf-l2vpn-evpn] defines a method for using
BGP MPLS-based Ethernet VPNs. Because it can use functions in LDP BGP MPLS-based Ethernet VPNs. Because it can use functions in LDP
and mLDP, as well as RFC 7117 [RFC7117] Multicast VPLS, it inherits and mLDP, as well as RFC 7117 [RFC7117] Multicast VPLS, it inherits
gaps previously identified in LDP (Section 3.2.1) and RFC 6074 gaps previously identified in LDP (Section 3.2.1) and RFC 6074
[RFC6074]. Once those gaps are resolved, it should function properly [RFC6074]. Once those gaps are resolved, it should function properly
on IPv6-only networks as defined. on IPv6-only networks as defined.
3.3.2. L3VPN Gap: Major for LDP, update to RFC 5036 in progress via LDP-IPv6
[I-D.ietf-mpls-ldp-ipv6] that should close this gap (see xref
target="LDP"/>). Minor for RFC 6074 [RFC6074], which needs to be
updated.
3.3.2. Layer 3 Virtual Private Network (L3VPN)
RFC 4364 [RFC4364] defines a method by which a Service Provider may RFC 4364 [RFC4364] defines a method by which a Service Provider may
use an IP backbone to provide IP Virtual Private Networks (VPNs) for use an IP backbone to provide IP 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 Layer 3 Virtual Private Networks (L3VPNs) for IPv4 RFC 4364 defines Layer 3 Virtual Private Networks (L3VPNs) for IPv4
only and has references to 32-bit BGP next hop addresses. RFC 4659 only and has references to 32-bit BGP next hop addresses. RFC 4659
[RFC4659] adds support for IPv6 on L3VPNs including 128-bit BGP next [RFC4659] adds support for IPv6 on L3VPNs including 128-bit BGP next
hop addresses, and discusses operation whether IPv6 is the payload or hop addresses, and discusses operation whether IPv6 is the payload or
the underlying transport address family. However, RFC4659 does not the underlying transport address family. However, RFC 4659 does not
formally update RFC4364, and thus an implementer may miss this formally update RFC 4364, and thus an implementer may miss this
additional set of standards unless it is explicitly identified additional set of standards unless it is explicitly identified
independently of the base functionality defined in RFC4364. An independently of the base functionality defined in RFC 4364. An
erratum has been filed to correct this metadata problem. Further, erratum has been filed to correct this metadata problem. Further,
section 1 of RFC4659 explicitly identifies use case #2 as out of section 1 of RFC 4659 explicitly identifies use case number 2 as out
scope for the document. 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. RFC4659 needs to be updated to explicitly cover use case Gap: Major. RFC 4659 needs to be updated to explicitly cover use
#2. (Discussed in further detail below) case number 2. (Discussed in further detail below)
3.3.2.1. 6PE/4PE 3.3.2.1. IPv6 Provider Edge/IPv4 Provider Edge (6PE/4PE)
RFC 4798 [RFC4798] defines IPv6 Provider Edge (6PE), which defines RFC 4798 [RFC4798] defines IPv6 Provider Edge (6PE), which defines
how to interconnect IPv6 islands over a MPLS-enabled IPv4 cloud. how to interconnect IPv6 islands over a MPLS-enabled IPv4 cloud.
However, use case 2 is doing the opposite, and thus could also be However, use case 2 is doing the opposite, and thus could also be
referred to as IPv4 Provider Edge (4PE). The method to support this referred to as IPv4 Provider Edge (4PE). The method to support this
use case is not defined explicitly. To support it, IPv4 edge devices use case is not defined explicitly. To support it, IPv4 edge devices
need to be able to map IPv4 traffic to MPLS IPv6 core LSP's. Also, need to be able to map IPv4 traffic to MPLS IPv6 core LSP's. Also,
the core switches may not understand IPv4 at all, but in some cases the core switches may not understand IPv4 at all, but in some cases
they may need to be able to exchange Labeled IPv4 routes from one AS they may need to be able to exchange Labeled IPv4 routes from one AS
to a neighboring AS. to a neighboring AS.
Gap: Major. RFC4798 covers only the "6PE" case. Use case #2 is Gap: Major. RFC 4798 covers only the "6PE" case. Use case number 2
currently not specified in an RFC. is currently not specified in an RFC.
3.3.2.2. 6VPE/4VPE 3.3.2.2. IPv6 Virtual Private Extension/IPv4 Virtual Private Extension
(6VPE/4VPE)
RFC 4659 [RFC4659] defines IPv6 Virtual Private Network Extension RFC 4659 [RFC4659] defines IPv6 Virtual Private Network Extension
(6VPE), a method by which a Service Provider may use its packet- (6VPE), a method by which a Service Provider may use its packet-
switched backbone to provide Virtual Private Network (VPN) services switched backbone to provide Virtual Private Network (VPN) services
for its IPv6 customers. It allows the core network to be MPLS IPv4 for its IPv6 customers. It allows the core network to be MPLS IPv4
or MPLS IPv6, thus addressing use case 1 above. RFC4364 should work or MPLS IPv6, thus addressing use case 1 above. RFC 4364 should work
as defined for use case 2 above, which could also be referred to as as defined for use case 2 above, which could also be referred to as
IPv4 Virtual Private Extension (4VPE), but the RFC explicitly does IPv4 Virtual Private Extension (4VPE), but the RFC explicitly does
not discuss this use and defines it as out of scope. not discuss this use and defines it as out of scope.
Gap: Minor. RFC4659 needs to be updated to explicitly cover use case Gap: Minor. RFC 4659 needs to be updated to explicitly cover use
#2 case number 2
3.3.2.3. BGP Encapsulation SAFI 3.3.2.3. BGP Encapsulation Subsequent Address Family Identifier (SAFI)
RFC 5512 [RFC5512] defines the BGP Encapsulation SAFI and the BGP RFC 5512 [RFC5512] defines the BGP Encapsulation SAFI and the BGP
Tunnel Encapsulation Attribute, which can be used to signal tunneling Tunnel Encapsulation Attribute, which can be used to signal tunneling
over a single-Address Family IP core. This mechanism supports over 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. MVPN 3.3.2.4. Multicast in MPLS/BGP IP VPN (MVPN)
RFC 6513 [RFC6513] defines the procedure to provide multicast service RFC 6513 [RFC6513] defines the procedure to provide multicast service
over an MPLS VPN backbone for downstream customers. It is sometimes over an MPLS VPN backbone for downstream customers. It is sometimes
referred to as Next Generation Multicast VPN (NG-MVPN) The procedure referred to as Next Generation Multicast VPN (NG-MVPN) The procedure
involves the below set of protocols: involves the below set of protocols:
3.3.2.4.1. PE-CE Multicast Routing Protocol 3.3.2.4.1. PE-CE Multicast Routing Protocol
RFC 6513 [RFC6513] explains the use of Protocol Independent Multicast RFC 6513 [RFC6513] explains the use of Protocol Independent Multicast
(PIM) as Provider Edge-Customer Edge (PE-CE) protocol while (PIM) as Provider Edge-Customer Edge (PE-CE) protocol while
skipping to change at page 12, line 32 skipping to change at page 12, line 47
considerations, and any gaps are applicable for non-MPLS networks as considerations, and any gaps are applicable for non-MPLS networks as
well. Similarly, BGP only includes the PMSI tunnel attribute as a well. Similarly, BGP only includes the PMSI tunnel attribute as a
part of the NLRI which is inherited from P-tunnel instantiation and 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 considered to be an opaque value. So any gaps in the Control plane
(PIM or BGP) will not be specific to MPLS. (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
not unique to MPLS, and therefore are outside the scope of this not unique to MPLS, and therefore are outside the scope of this
document. It is included for completeness. document. It is included for completeness.
3.3.3. MPLS-TP 3.3.3. MPLS Transport Profile (MPLS-TP)
MPLS-TP does not require IP (see section 2 of RFC 5921 [RFC5921]) and MPLS-TP does not require IP (see section 2 of RFC 5921 [RFC5921]) and
should not be affected by operation on an IPv6-only network. should not be affected by operation on an IPv6-only network.
Therefore this is considered out of scope for this document, but is Therefore this is considered out of scope for this document, but is
included for completeness. included for completeness.
Although not required, MPLS-TP can use IP. One such example is
included in Section 3.2.6, where MPLS-TP identifiers can be derived
from valid IPv4 addresses.
Gap: None. Gap: None.
3.4. MPLS OAM 3.4. MPLS Operations, Administration, and Maintenance (MPLS OAM)
For MPLS LSPs, there are primarily three Operations, Administration, For MPLS LSPs, there are primarily three Operations, Administration,
and Maintenance (OAM) mechanisms: Extended ICMP RFC 4884 [RFC4884] and Maintenance (OAM) mechanisms: Extended ICMP RFC 4884 [RFC4884]
RFC 4950 [RFC4950], LSP Ping RFC 4379 [RFC4379], and Bidirectional RFC 4950 [RFC4950], LSP Ping RFC 4379 [RFC4379], and Bidirectional
Forwarding Detection (BFD) for MPLS LSPs RFC 5884 [RFC5884]. For Forwarding Detection (BFD) for MPLS LSPs RFC 5884 [RFC5884]. For
MPLS Pseudowires, there is also Virtual Circuit Connectivity MPLS Pseudowires, there is also Virtual Circuit Connectivity
Verification (VCCV) RFC 5085 [RFC5085] RFC 5885 [RFC5885]. Most of Verification (VCCV) RFC 5085 [RFC5085] RFC 5885 [RFC5885]. Most of
these mechanisms work in pure IPv6 environments, but there are some these mechanisms work in pure IPv6 environments, but there are some
problems encountered in mixed environments due to address-family problems encountered in mixed environments due to address-family
mismatches. The next subsections cover these gaps in detail. mismatches. The next subsections cover these gaps in detail.
Gap: Major. RFC4379 needs to be updated to better support multipath Gap: Major. RFC 4379 needs to be updated to better support multipath
IPv6. Additionally, there is potential for dropped messages in IPv6. Additionally, there is potential for dropped messages in
Extended ICMP and LSP ping due to IP version mismatches. It is Extended ICMP and LSP ping due to IP version mismatches. It is
important to note that this is a more generic problem with tunneling important to note that this is a more generic problem with tunneling
when IP address family mismatches exist, and is not specific to MPLS, when IP address family mismatches exist, and is not specific to MPLS,
so while MPLS will be affected, it will be difficult to fix this so while MPLS will be affected, it will be difficult to fix this
problem specifically for MPLS, rather than fixing the more generic problem specifically for MPLS, rather than fixing the more generic
problem. problem.
3.4.1. Extended ICMP 3.4.1. Extended ICMP
skipping to change at page 14, line 5 skipping to change at page 14, line 24
family of address information included in an Interface Information family of address information included in an Interface Information
Object to the same one as the ICMP (see Section 4.5 of RFC 5837). Object to the same one as the ICMP (see Section 4.5 of RFC 5837).
While these extensions are not MPLS specific, they can be used with While these extensions are not MPLS specific, they can be used with
MPLS packets carrying IP datagrams. This has no implications for MPLS packets carrying IP datagrams. This has no implications for
IPv6-only environments. IPv6-only environments.
Gap: Major. IP version mismatches may cause dropped messages. Gap: Major. IP version mismatches may cause dropped messages.
However, as noted in the previous section, this problem is not However, as noted in the previous section, this problem is not
specific to MPLS. specific to MPLS.
3.4.2. LSP Ping 3.4.2. Label Switched Path Ping (LSP Ping)
The LSP Ping mechanism defined in RFC 4379 [RFC4379] is specified to The LSP Ping mechanism defined in RFC 4379 [RFC4379] is specified to
work with IPv6. Specifically, the Target FEC Stacks include both work with IPv6. Specifically, the Target FEC Stacks include both
IPv4 and IPv6 versions of all FECs (see Section 3.2 of RFC 4379). IPv4 and IPv6 versions of all FECs (see Section 3.2 of RFC 4379).
The only exceptions are the Pseudowire FECs, which are later The only exceptions are the Pseudowire FECs, which are later
specified for IPv6 in RFC 6829 [RFC6829]. The multipath information specified for IPv6 in RFC 6829 [RFC6829]. The multipath information
also includes IPv6 encodings (see Section 3.3.1 of RFC 4379). also includes IPv6 encodings (see Section 3.3.1 of RFC 4379).
LSP Ping packets are UDP packets over either IPv4 or IPv6 (see LSP Ping packets are UDP packets over either IPv4 or IPv6 (see
Section 4.3 of RFC 4379). However, for IPv6 the destination IP Section 4.3 of RFC 4379). However, for IPv6 the destination IP
skipping to change at page 15, line 16 skipping to change at page 15, line 36
explain the behaviour in certain IPv6-specific scenarios. For explain the behaviour in certain IPv6-specific scenarios. For
example, RFC 4379 defines the K value as 28 octets when Address example, RFC 4379 defines the K value as 28 octets when Address
Family is set to IPv6 Unnumbered, but it doesn't describe how to Family is set to IPv6 Unnumbered, but it doesn't describe how to
carry a 32 bit LSR Router ID in the 128 bit Downstream IP Address carry a 32 bit LSR Router ID in the 128 bit Downstream IP Address
Field. Field.
Gap: Major. LSP ping uses IPv4-mapped IPv6 addresses, IP version Gap: Major. LSP ping uses IPv4-mapped IPv6 addresses, IP version
mismatches may cause dropped messages, unclear mapping from LSR mismatches may cause dropped messages, unclear mapping from LSR
Router ID to Downstream IP Address. Router ID to Downstream IP Address.
3.4.3. BFD OAM 3.4.3. Bidirectional Forwarding Detection (BFD)
The BFD specification for MPLS LSPs RFC 5884 [RFC5884] is defined for The BFD specification for MPLS LSPs RFC 5884 [RFC5884] is defined for
IPv4 as well as IPv6 versions of MPLS FECs (see Section 3.1 of RFC IPv4 as well as IPv6 versions of MPLS FECs (see Section 3.1 of RFC
5884). Additionally the BFD packet is encapsulated over UDP and 5884). Additionally the BFD packet is encapsulated over UDP and
specified to run over both IPv4 and IPv6 (see Section 7 of RFC 5884). specified to run over both IPv4 and IPv6 (see Section 7 of RFC 5884).
Gap: None. Gap: None.
3.4.4. Pseudowire OAM 3.4.4. Pseudowire OAM
skipping to change at page 15, line 38 skipping to change at page 16, line 10
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 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 Transport Profile (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] does not require IP
IP or existing MPLS OAM functions, and should not be affected by 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, but is included for completeness. for this document, but is included for completeness. Although not
required, MPLS-TP can use IP.
Gap: None. Gap: None.
3.5. MIBs 3.5. MIB Modules
RFC3811 [RFC3811] defines the textual conventions for MPLS. These RFC 3811 [RFC3811] defines the textual conventions for MPLS. These
lack support for IPv6 in defining MplsExtendedTunnelId and lack support for IPv6 in defining MplsExtendedTunnelId and
MplsLsrIdentifier. These textual conventions are used in the MPLS TE MplsLsrIdentifier. These textual conventions are used in the MPLS TE
Management Information Base (MIB) specification RFC3812 [RFC3812], Management Information Base (MIB) specification RFC 3812 [RFC3812],
GMPLS TE MIB specification RFC4802 [RFC4802] and Fast ReRoute (FRR) GMPLS TE MIB specification RFC 4802 [RFC4802] and Fast ReRoute (FRR)
extension RFC6445 [RFC6445]. 3811bis [I-D.manral-mpls-rfc3811bis] extension RFC 6445 [RFC6445]. RFC 3811bis
tries to resolve this gap by marking this textual convention as [I-D.manral-mpls-rfc3811bis] tries to resolve this gap by marking
obsolete. this textual convention as obsolete.
The other MIB specifications for LSR RFC3813 [RFC3813], LDP RFC3815 For MPLS-TP, RFC 4990 [RFC4990] discusses how to handle IPv6 sources
[RFC3815] and TE RFC4220 [RFC4220] have support for both IPv4 and and destinations in the MPLS and GMPLS Traffic Engineering (TE)
Management Information Base (MIB) modules.
The other MIB specifications for LSR RFC 3813 [RFC3813], LDP RFC 3815
[RFC3815] and TE RFC 4220 [RFC4220] have support for both IPv4 and
IPv6. IPv6.
Gap: Major. Work underway to update RFC3811 via 3811bis Gap: Major. Work underway to update RFC 3811 via RFC 3811bis
[I-D.manral-mpls-rfc3811bis], may also need to update RFC3812, [I-D.manral-mpls-rfc3811bis], may also need to update RFC 3812, RFC
RFC4802, and RFC6445, which depend on it. 4802, and RFC 6445, 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 or IPv6-primary to determine their suitability for use on IPv6-only or IPv6-primary
networks. While some parts of the MPLS suite will function properly networks. While some parts of the MPLS suite will function properly
without additional changes, gaps have been identified in others, without additional changes, gaps have been identified in others,
which will need to be addressed with follow-on work. This section which will need to be addressed with follow-on work. This section
will summarize those gaps, along with pointers to any work in will summarize those gaps, along with pointers to any work in
progress to address them. Note that because the referenced drafts progress to address them. Note that because the referenced drafts
skipping to change at page 17, line 18 skipping to change at page 17, line 25
| 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 | | mLDP | inherits gaps from LDP, | inherits LDP-IPv6 |
| S.3.2.2 | RFC6512 [RFC6512] | [I-D.ietf-mpls-ldp-ipv6], | | S.3.2.2 | RFC 6512 [RFC6512] | [I-D.ietf-mpls-ldp-ipv6], |
| | | additional fixes TBD | | | | additional fixes TBD |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| GMPLS | RFC6370 [RFC6370] Node | TBD | | GMPLS | RFC 6370 [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 4659 [RFC4659] | TBD | | L3VPN | RFC 4659 [RFC4659] | TBD |
| S.3.3.2 | define method for | | | S.3.3.2 | define method 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 | | MIB | RFC 3811 [RFC3811] no | RFC 3811bis |
| S.3.5 | IPv6 textual convention | [I-D.manral-mpls-rfc3811bis] | | Modules | IPv6 textual convention | [I-D.manral-mpls-rfc3811bis] |
| S.3.5 | | |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
Table 1: IPv6-only MPLS Gaps Table 1: IPv6-only MPLS Gaps
5. Acknowledgements 5. Acknowledgements
The authors wish to thank Alvaro Retana, Andrew Yourtchenko, Loa The authors wish to thank Alvaro Retana, Andrew Yourtchenko, Loa
Andersson, David Allan, Mach Chen, Mustapha Aissaoui, and Mark Tinka Andersson, David Allan, Mach Chen, Mustapha Aissaoui, and Mark Tinka
for their detailed reviews, as well as Brian Haberman, Joel Jaeggli, for their detailed reviews, as well as Brian Haberman, Joel Jaeggli,
Adrian Farrell, and Nobo Akiya for their comments. Adrian Farrel, 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 19, line 37 skipping to change at page 19, line 44
any of the specifics of the protocol or its features, however, any of the specifics of the protocol or its features, however,
follow-on work recommended by this gap analysis will need to address follow-on work recommended by this gap analysis will need to address
any effects of the use of IPv6 in their modifications may have on any effects of the use of IPv6 in their modifications may have on
security. 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-11 (work in progress), October 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-07 (work in progress), October 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-02 (work in
progress), March 2014. progress), October 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-13 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-13
(work in progress), July 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-
manral-mpls-rfc3811bis-03 (work in progress), June 2013. manral-mpls-rfc3811bis-04 (work in progress), September
2014.
[I-D.raza-mpls-oam-ipv6-rao] [I-D.raza-mpls-oam-ipv6-rao]
Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert
Option for MPLS OAM", draft-raza-mpls-oam-ipv6-rao-00 Option for MPLS OAM", draft-raza-mpls-oam-ipv6-rao-02
(work in progress), July 2014. (work in progress), September 2014.
[I-D.smith-v6ops-larger-ipv6-loopback-prefix] [I-D.smith-v6ops-larger-ipv6-loopback-prefix]
Smith, M., "A Larger Loopback Prefix for IPv6", draft- Smith, M., "A Larger Loopback Prefix for IPv6", draft-
smith-v6ops-larger-ipv6-loopback-prefix-04 (work in smith-v6ops-larger-ipv6-loopback-prefix-04 (work in
progress), February 2013. progress), February 2013.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
skipping to change at page 20, line 46 skipping to change at page 21, line 9
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001. Encoding", RFC 3032, January 2001.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001. BGP-4", RFC 3107, May 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September (TE) Extensions to OSPF Version 2", RFC 3630, September
2003. 2003.
[RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual
Conventions (TCs) for Multiprotocol Label Switching (MPLS) Conventions (TCs) for Multiprotocol Label Switching (MPLS)
Management", RFC 3811, June 2004. Management", RFC 3811, June 2004.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic Engineering "Multiprotocol Label Switching (MPLS) Traffic Engineering
 End of changes. 80 change blocks. 
121 lines changed or deleted 154 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/