draft-george-mpls-ipv6-only-gap-03.txt   draft-george-mpls-ipv6-only-gap-04.txt 
Internet Engineering Task Force W. George, Ed. Internet Engineering Task Force W. George, Ed.
Internet-Draft Time Warner Cable Internet-Draft Time Warner Cable
Intended status: Informational C. Pignataro, Ed. Intended status: Informational C. Pignataro, Ed.
Expires: July 25, 2014 Cisco Systems Expires: August 14, 2014 Cisco Systems
January 21, 2014 February 10, 2014
Gap Analysis for Operating IPv6-only MPLS Networks Gap Analysis for Operating IPv6-only MPLS Networks
draft-george-mpls-ipv6-only-gap-03 draft-george-mpls-ipv6-only-gap-04
Abstract Abstract
This document reviews the MPLS protocol suite in the context of IPv6 This document reviews the MPLS protocol suite in the context of IPv6
and identifies gaps that must be addressed in order to allow MPLS- and identifies gaps that must be addressed in order to allow MPLS-
related protocols and applications to be used with IPv6-only related protocols and applications to be used with IPv6-only
networks. This document is not intended to highlight a particular networks. This document is not intended to highlight a particular
vendor's implementation (or lack thereof) in the context of IPv6-only vendor's implementation (or lack thereof) in the context of IPv6-only
MPLS functionality, but rather to focus on gaps in the standards MPLS functionality, but rather to focus on gaps in the standards
defining the MPLS suite. defining the MPLS suite.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 25, 2014. This Internet-Draft will expire on August 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 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. Multicast LDP . . . . . . . . . . . . . . . . . . . . 5 3.2.2. Multipoint LDP . . . . . . . . . . . . . . . . . . . 5
3.2.3. RSVP- TE . . . . . . . . . . . . . . . . . . . . . . 6 3.2.3. RSVP- TE . . . . . . . . . . . . . . . . . . . . . . 6
3.2.3.1. IGP . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.3.1. IGP . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.3.2. RSVP-TE-P2MP . . . . . . . . . . . . . . . . . . 7 3.2.3.2. RSVP-TE-P2MP . . . . . . . . . . . . . . . . . . 7
3.2.3.3. RSVP-TE Fast Reroute (FRR) . . . . . . . . . . . 7 3.2.3.3. RSVP-TE Fast Reroute (FRR) . . . . . . . . . . . 7
3.2.4. Controller, PCE . . . . . . . . . . . . . . . . . . . 7 3.2.4. Controller, PCE . . . . . . . . . . . . . . . . . . . 7
3.2.5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1.1. EVPN . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. L3VPN . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.2. L3VPN . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2.1. 6PE/4PE . . . . . . . . . . . . . . . . . . . . . 9 3.3.2.1. 6PE/4PE . . . . . . . . . . . . . . . . . . . . . 10
3.3.2.2. 6VPE/4VPE . . . . . . . . . . . . . . . . . . . . 9 3.3.2.2. 6VPE/4VPE . . . . . . . . . . . . . . . . . . . . 10
3.3.2.3. BGP Encapsulation SAFI . . . . . . . . . . . . . 10 3.3.2.3. BGP Encapsulation SAFI . . . . . . . . . . . . . 10
3.3.2.4. NG-MVPN . . . . . . . . . . . . . . . . . . . . . 10 3.3.2.4. NG-MVPN . . . . . . . . . . . . . . . . . . . . . 10
3.3.3. MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.3. MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 11 3.4.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 12
3.4.2. LSP Ping . . . . . . . . . . . . . . . . . . . . . . 12 3.4.2. LSP Ping . . . . . . . . . . . . . . . . . . . . . . 13
3.4.3. BFD . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.3. BFD OAM . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.4. Pseudowires . . . . . . . . . . . . . . . . . . . . . 13 3.4.4. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 14
3.4.5. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 14 3.4.5. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 14
3.5. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.5. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15 6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Informative References . . . . . . . . . . . . . . . . . . . 18 9. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Assignments . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Assignments . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
IPv6 is an integral part of modern network deployments. At the time IPv6 is an integral part of modern network deployments. At the time
when this document was written, the majority of these IPv6 when this document was written, the majority of these IPv6
deployments were using dual-stack implementations, where IPv4 and deployments were using dual-stack implementations, where IPv4 and
IPv6 are supported equally on many or all of the network nodes, and IPv6 are supported equally on many or all of the network nodes, and
single-stack primarily referred to IPv4-only devices. Dual-stack single-stack primarily referred to IPv4-only devices. Dual-stack
deployments provide a useful margin for protocols and features that deployments provide a useful margin for protocols and features that
are not currently capable of operating solely over IPv6, because they are not currently capable of operating solely over IPv6, because they
skipping to change at page 3, line 42 skipping to change at page 3, line 42
2. Use Case 2. Use Case
From a purely theoretical perspective, ensuring that MPLS is fully IP From a purely theoretical perspective, ensuring that MPLS is fully IP
version-agnostic is the right thing to do. However, it is sometimes version-agnostic is the right thing to do. However, it is sometimes
helpful to understand the underlying drivers that make this work helpful to understand the underlying drivers that make this work
necessary to undertake, especially at a time when IPv6-only necessary to undertake, especially at a time when IPv6-only
networking is still fairly uncommon. This section will discuss some networking is still fairly uncommon. This section will discuss some
drivers. It is not intended to be a comprehensive discussion of all drivers. It is not intended to be a comprehensive discussion of all
potential use cases, but rather a discussion of at least one use case potential use cases, but rather a discussion of at least one use case
so that this is not seen as solving a purely theoretical problem. to demonstrate that this document is not discussing a purely
theoretical problem.
IP convergence is continuing to drive new classes of devices to begin IP convergence is continuing to drive new classes of devices to begin
communicating via IP. Examples of such devices could include set top communicating via IP. Examples of such devices could include set top
boxes for IP Video distribution, cell tower electronics (macro or boxes for IP Video distribution, cell tower electronics (macro or
micro cells), infrastructure Wi-Fi Access Points, and devices for micro cells), infrastructure Wi-Fi Access Points, and devices for
machine to machine (M2M) or Internet of Things applications. In some machine to machine (M2M) or Internet of Things applications. In some
cases, these classes of devices represent a very large deployment cases, these classes of devices represent a very large deployment
base, on the order of thousands or even millions of devices network- base, on the order of thousands or even millions of devices network-
wide. The scale of these networks, coupled with the increasingly wide. The scale of these networks, coupled with the increasingly
overlapping use of RFC 1918 [RFC1918] address space within the overlapping use of RFC 1918 [RFC1918] address space within the
skipping to change at page 5, line 23 skipping to change at page 5, line 29
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 TTL security RFC 5082
[RFC5082]. [RFC5082] and RFC 6720 [RFC6720].
Gap: Major, update to RFC 5036 in progress. Gap: Major, update to RFC 5036 in progress that should close this
gap.
3.2.2. Multicast 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 with regards to control plane (discovery, transport,
and session establishment) in an IPv6-only network. and session establishment) in an IPv6-only network.
skipping to change at page 6, line 29 skipping to change at page 6, line 33
defined for a BGP-free core in an VPN environment, but the similar defined for a BGP-free core in an VPN environment, but the 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 the
procedures similar to RFC6512. The translation of root address on procedures similar to RFC6512. The translation of root address on
borders of IPv4 or IPv6 islands will also be needed for recursive borders of IPv4 or IPv6 islands will also be needed for recursive
FECs and procedures defined in RFC6512. FECs and procedures defined in RFC6512.
Gap: Major, update in progress for LDP, may need additional updates Gap: Major, update in progress for LDP via LDP-IPv6
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 &
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
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
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 RFC5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF
Version 3. Version 3.
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
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 GMPLS with support for
both IPv4 and IPv6. both IPv4 and IPv6.
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
shared risk link group (SRLG) for both IPv4 and IPv6. shared risk link group (SRLG) for both IPv4 and IPv6.
Gap: None
3.2.4. Controller, PCE 3.2.4. Controller, PCE
The Path Computation Element (PCE) defined in RFC4655 [RFC4655] is an The Path Computation Element (PCE) defined in RFC4655 [RFC4655] is an
entity that is capable of computing a network path or route based on entity that is capable of computing a network path or route based on
a network graph, and applying computational constraints. A Path 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 RFC5440 [RFC5440].
skipping to change at page 9, line 30 skipping to change at page 9, line 45
type. RFC 4659 [RFC4659] corrects this oversight. Also, Section 5 type. RFC 4659 [RFC4659] corrects this oversight. Also, Section 5
of RFC 4364 [RFC4364] assumes that the BGP next-hop contains exactly of RFC 4364 [RFC4364] assumes that the BGP next-hop contains exactly
32 bits. This text should be generalized to include 128 bit next- 32 bits. This text should be generalized to include 128 bit next-
hops as well. hops as well.
The authors do not believe that there are any additional issues The authors do not believe that there are any additional issues
encountered when using L2TPv3, RSVP, or GRE (instead of MPLS) as encountered when using L2TPv3, RSVP, or GRE (instead of MPLS) as
transport on an IPv6-only network. transport on an IPv6-only network.
Gap: Major. RFC4364 must be updated, and RFC4659 may need to be Gap: Major. RFC4364 must be updated, and RFC4659 may need to be
updated to explicitly cover use case #2 as discussed below. updated to explicitly cover use case #2. (Discussed in further
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 6PE, which defines how to interconnect
IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4
cloud. However, use case 2 is doing the opposite, and thus could cloud. However, use case 2 is doing the opposite, and thus could
also be referred to as 4PE. The method to support this use case is also be referred to as 4PE. The method to support this use case is
not defined explicitly. To support it, IPv4 edge devices need to be not defined explicitly. To support it, IPv4 edge devices need to be
able to map IPv4 traffic to MPLS IPv6 core LSP's. Also, the core able to map IPv4 traffic to MPLS IPv6 core LSP's. Also, the core
switches may not understand IPv4 at all, but in some cases they may switches may not understand IPv4 at all, but in some cases they may
need to be able to exchange Labeled IPv4 routes from one AS to a need to be able to exchange Labeled IPv4 routes from one AS to a
neighboring AS. neighboring AS.
Gap: Major. RFC4659 needs to be updated to explicitly cover use case
#2.
3.3.2.2. 6VPE/4VPE 3.3.2.2. 6VPE/4VPE
RFC 4659 [RFC4659] defines 6VPE, a method by which a Service Provider RFC 4659 [RFC4659] defines 6VPE, a method by which a Service Provider
may use its packet-switched backbone to provide Virtual Private may use its packet-switched backbone to provide Virtual Private
Network (VPN) services for its IPv6 customers. It allows the core Network (VPN) services for its IPv6 customers. It allows the core
network to be MPLS IPv4 or MPLS IPv6, thus addressing use case 1 network to be MPLS IPv4 or MPLS IPv6, thus addressing use case 1
above. RFC4364 should work as defined for use case 2 above, which above. RFC4364 should work as defined for use case 2 above, which
could also be referred to as 4VPE, but the RFC does not explicitly could also be referred to as 4VPE, but the RFC does not explicitly
discuss this use. discuss this use.
Gap: Minor. RFC4659 may need to be updated to explicitly cover use
case #2
3.3.2.3. BGP Encapsulation SAFI 3.3.2.3. BGP Encapsulation SAFI
RFC 5512 [RFC5512] defines the BGP Encapsulation SAFI and the BGP RFC 5512 [RFC5512] defines the BGP Encapsulation SAFI and the BGP
Tunnel Encapsulation Attribute, which can be used to signal Tunnel Encapsulation Attribute, which can be used to signal
tunnelling over an single-Address Family IP core. This mechanism tunnelling over an single-Address Family IP core. This mechanism
supports transport of MPLS (and other protocols) over Tunnels in an supports transport of MPLS (and other protocols) over Tunnels in an
IP core (including an IPv6-only core). In this context, load- IP core (including an IPv6-only core). In this context, load-
balancing can be provided as specified in RFC 5640 [RFC5640]. balancing can be provided as specified in RFC 5640 [RFC5640].
Gap: None.
3.3.2.4. NG-MVPN 3.3.2.4. NG-MVPN
RFC 6513 [RFC6513] defines the procedure to provide multicast service RFC 6513 [RFC6513] defines the procedure to provide multicast service
over MPLS VPN backbone for the customers. The procedure involves the over MPLS VPN backbone for the customers. The procedure involves the
below set of protocols: below set of protocols:
3.3.2.4.1. PE-CE Multicast Routing Protocol 3.3.2.4.1. PE-CE Multicast Routing Protocol
RFC 6513 [RFC6513] explains the use of PIM as PE-CE protocol while RFC 6513 [RFC6513] explains the use of PIM as 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-
skipping to change at page 11, line 22 skipping to change at page 12, line 8
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.
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 outside the scope of this document
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
thus 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.
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 OAM mechanisms: Extended
ICMP RFC 4884 [RFC4884] RFC 4950 [RFC4950], LSP Ping RFC 4379 ICMP RFC 4884 [RFC4884] RFC 4950 [RFC4950], LSP Ping RFC 4379
[RFC4379], and BFD for MPLS LSPs RFC 5884 [RFC5884]. For MPLS [RFC4379], and BFD for MPLS LSPs RFC 5884 [RFC5884]. For MPLS
Pseudowires, there is also Virtual Circuit Connectivity Verification Pseudowires, there is also Virtual Circuit Connectivity Verification
(VCCV) RFC 5085 [RFC5085] RFC 5885 [RFC5885]. All of these (VCCV) RFC 5085 [RFC5085] RFC 5885 [RFC5885]. All of these
skipping to change at page 12, line 33 skipping to change at page 13, line 19
cannot parse the original IPv4 datagram, nor can it send an IPv4 cannot parse the original IPv4 datagram, nor can it send an IPv4
message. So, no ICMP message is delivered to the source. Some message. So, no ICMP message is delivered to the source. Some
specific ICMP extensions, in particular ICMP Extensions for Interface specific ICMP extensions, in particular ICMP Extensions for Interface
and Next-Hop Identification RFC 5837 [RFC5837] restrict the address and Next-Hop Identification RFC 5837 [RFC5837] restrict the address
family of address information included in an Interface Information family of address information included in an Interface Information
Object to the same one as the ICMP (see Section 4.5 of RFC 5837). Object to the same one as the ICMP (see Section 4.5 of RFC 5837).
While these extensions are not MPLS specific, they can be used with While these extensions are not MPLS specific, they can be used with
MPLS packets carrying IP datagrams. This has no implications for MPLS packets carrying IP datagrams. This has no implications for
IPv6-only environments. IPv6-only environments.
Gap: Major. IP version mismatches may cause dropped messages.
However, as noted in the previous section, this problem is not
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 later specified for IPv6
in RFC 6829 [RFC6829]. in RFC 6829 [RFC6829].
The multipath information includes also IPv6 encodings (see The multipath information includes also IPv6 encodings (see
Section 3.3.1 of RFC 4379). Section 3.3.1 of RFC 4379).
skipping to change at page 13, line 35 skipping to change at page 14, line 23
IPv4-aware. It cannot parse the IPv4 Echo Request, nor can it send IPv4-aware. It cannot parse the IPv4 Echo Request, nor can it send
an IPv4 Echo Reply. So, no reply is sent. an IPv4 Echo Reply. So, no reply is sent.
The mechanism described in RFC 4379 also does not sufficiently The mechanism described in RFC 4379 also does not sufficiently
explain the 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.
3.4.3. BFD Gap: Major. LSP ping uses IPv4-mapped IPv6 addresses, IP version
mismatches may cause dropped messages, unclear mapping from LSR
Router ID to Downstream IP Address.
3.4.3. BFD OAM
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).
3.4.4. Pseudowires Gap: None.
3.4.4. Pseudowire OAM
The OAM specifications for MPLS Pseudowires define usage for both The OAM specifications for MPLS Pseudowires define usage for both
IPv4 and IPv6. Specifically, VCCV RFC 5085 [RFC5085] can carry IPv4 IPv4 and IPv6. Specifically, VCCV RFC 5085 [RFC5085] can carry IPv4
or IPv6 OAM packets (see Section 5.1.1 and 5.2.1 of RFC 5085), and or IPv6 OAM packets (see Section 5.1.1 and 5.2.1 of RFC 5085), and
VCCV for BFD RFC 5885 [RFC5885] also defines an IPv6 encapsulation VCCV for BFD RFC 5885 [RFC5885] also defines an IPv6 encapsulation
(see Section 3.2 of RFC 5885). (see Section 3.2 of RFC 5885).
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. operation on an IPv6-only network. Therefore, this is out of scope
for this document.
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 MIB specification RFC3812 [RFC3812], GMPLS TE MIB specification
RFC4802 [RFC4802] and Fast ReRoute (FRR) extension RFC6445 [RFC6445]. RFC4802 [RFC4802] and Fast ReRoute (FRR) extension RFC6445 [RFC6445].
3811bis [I-D.manral-mpls-rfc3811bis] tries to resolve this gap by 3811bis [I-D.manral-mpls-rfc3811bis] tries to resolve this gap by
marking this textual convention as obsolete. marking this textual convention as obsolete.
skipping to change at page 15, line 24 skipping to change at page 16, line 24
| | address and LDP TTL | | | | address and LDP TTL | |
| | security | | | | security | |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| L2VPN | RFC 6074 [RFC6074] | TBD | | L2VPN | RFC 6074 [RFC6074] | TBD |
| S.3.3.1 | discovery, signaling | | | S.3.3.1 | discovery, signaling | |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| L3VPN | RFC 4364 [RFC4364] BGP | TBD | | L3VPN | RFC 4364 [RFC4364] BGP | TBD |
| S.3.3.2 | next-hop, define method | | | S.3.3.2 | next-hop, define method | |
| | for 4PE/4VPE | | | | for 4PE/4VPE | |
+---------+--------------------------+------------------------------+ +---------+--------------------------+------------------------------+
| OAM | RFC 4379 [RFC4379] no | TBD |
| S.3.4 | IPv6 multipath support, | |
| | possible dropped | |
| | messages in IP 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 for a detailed review, The authors wish to thank Andrew Yourtchenko and Loa Andersson for a
as well as Brian Haberman, Joel Jaeggli, and Adrian Farrell for their detailed review, as well as Brian Haberman, Joel Jaeggli, and Adrian
comments. Farrell for their comments.
6. Contributing Authors 6. Contributing Authors
The following people have contributed text to this draft: The following people have contributed text to this draft:
Rajiv Asati Rajiv Asati
Cisco Systems Cisco Systems
7025 Kit Creek Road 7025 Kit Creek Road
skipping to change at page 18, line 24 skipping to change at page 19, line 30
FECs in the NLRI of BGP MCAST-VPN Routes", draft-ietf- FECs in the NLRI of BGP MCAST-VPN Routes", draft-ietf-
l3vpn-mvpn-mldp-nlri-04 (work in progress), December 2013. l3vpn-mvpn-mldp-nlri-04 (work in progress), December 2013.
[I-D.ietf-l3vpn-mvpn-pe-ce] [I-D.ietf-l3vpn-mvpn-pe-ce]
Patel, K., Rekhter, Y., and E. Rosen, "BGP as an MVPN PE- Patel, K., Rekhter, Y., and E. Rosen, "BGP as an MVPN PE-
CE Protocol", draft-ietf-l3vpn-mvpn-pe-ce-00 (work in CE Protocol", draft-ietf-l3vpn-mvpn-pe-ce-00 (work in
progress), October 2013. progress), October 2013.
[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-11 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-12
(work in progress), December 2013. (work in progress), February 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 23, line 38 skipping to change at page 24, line 46
VPNs", RFC 6514, February 2012. VPNs", RFC 6514, February 2012.
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard,
"IPv6 Support Required for All IP-Capable Nodes", BCP 177, "IPv6 Support Required for All IP-Capable Nodes", BCP 177,
RFC 6540, April 2012. RFC 6540, April 2012.
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
Virtual Private Networks Using BGP for Auto-Discovery and Virtual Private Networks Using BGP for Auto-Discovery and
Signaling", RFC 6624, May 2012. Signaling", RFC 6624, May 2012.
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security
Mechanism (GTSM) for the Label Distribution Protocol
(LDP)", RFC 6720, August 2012.
[RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label
Switched Path (LSP) Ping for Pseudowire Forwarding Switched Path (LSP) Ping for Pseudowire Forwarding
Equivalence Classes (FECs) Advertised over IPv6", RFC Equivalence Classes (FECs) Advertised over IPv6", RFC
6829, January 2013. 6829, January 2013.
Appendix A. Assignments Appendix A. Assignments
*RFC EDITOR PLEASE REMOVE BEFORE PUBLISHING* *RFC EDITOR PLEASE REMOVE BEFORE PUBLISHING*
This will track which author volunteered for which section(s): This will track which author volunteered for which section(s):
 End of changes. 33 change blocks. 
41 lines changed or deleted 86 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/