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/ |