--- 1/draft-george-mpls-ipv6-only-gap-03.txt 2014-02-13 15:14:51.690420975 -0800 +++ 2/draft-george-mpls-ipv6-only-gap-04.txt 2014-02-13 15:14:51.738422130 -0800 @@ -1,19 +1,19 @@ Internet Engineering Task Force W. George, Ed. Internet-Draft Time Warner Cable Intended status: Informational C. Pignataro, Ed. -Expires: July 25, 2014 Cisco Systems - January 21, 2014 +Expires: August 14, 2014 Cisco Systems + February 10, 2014 Gap Analysis for Operating IPv6-only MPLS Networks - draft-george-mpls-ipv6-only-gap-03 + draft-george-mpls-ipv6-only-gap-04 Abstract This document reviews the MPLS protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS- related protocols and applications to be used with IPv6-only networks. This document is not intended to highlight a particular vendor's implementation (or lack thereof) in the context of IPv6-only MPLS functionality, but rather to focus on gaps in the standards defining the MPLS suite. @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -48,55 +48,55 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 5 3.2. MPLS Control Plane . . . . . . . . . . . . . . . . . . . 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.1. IGP . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.3.2. RSVP-TE-P2MP . . . . . . . . . . . . . . . . . . 7 3.2.3.3. RSVP-TE Fast Reroute (FRR) . . . . . . . . . . . 7 3.2.4. Controller, PCE . . . . . . . . . . . . . . . . . . . 7 - 3.2.5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2.5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.6. GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. MPLS Applications . . . . . . . . . . . . . . . . . . . . 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.1. 6PE/4PE . . . . . . . . . . . . . . . . . . . . . 9 - 3.3.2.2. 6VPE/4VPE . . . . . . . . . . . . . . . . . . . . 9 + 3.3.2.1. 6PE/4PE . . . . . . . . . . . . . . . . . . . . . 10 + 3.3.2.2. 6VPE/4VPE . . . . . . . . . . . . . . . . . . . . 10 3.3.2.3. BGP Encapsulation SAFI . . . . . . . . . . . . . 10 3.3.2.4. NG-MVPN . . . . . . . . . . . . . . . . . . . . . 10 - 3.3.3. MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.4. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.4.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 11 - 3.4.2. LSP Ping . . . . . . . . . . . . . . . . . . . . . . 12 - 3.4.3. BFD . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 3.4.4. Pseudowires . . . . . . . . . . . . . . . . . . . . . 13 + 3.3.3. MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.4. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.4.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 12 + 3.4.2. LSP Ping . . . . . . . . . . . . . . . . . . . . . . 13 + 3.4.3. BFD OAM . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.4.4. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 14 3.4.5. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 14 - 3.5. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 - 6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 9. Informative References . . . . . . . . . . . . . . . . . . . 18 - Appendix A. Assignments . . . . . . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 + 3.5. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 + 6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 16 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 9. Informative References . . . . . . . . . . . . . . . . . . . 19 + Appendix A. Assignments . . . . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction IPv6 is an integral part of modern network deployments. At the time when this document was written, the majority of these IPv6 deployments were using dual-stack implementations, where IPv4 and IPv6 are supported equally on many or all of the network nodes, and single-stack primarily referred to IPv4-only devices. Dual-stack deployments provide a useful margin for protocols and features that are not currently capable of operating solely over IPv6, because they @@ -121,21 +121,22 @@ 2. Use Case From a purely theoretical perspective, ensuring that MPLS is fully IP version-agnostic is the right thing to do. However, it is sometimes helpful to understand the underlying drivers that make this work necessary to undertake, especially at a time when IPv6-only networking is still fairly uncommon. This section will discuss some 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 - 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 communicating via IP. Examples of such devices could include set top boxes for IP Video distribution, cell tower electronics (macro or micro cells), infrastructure Wi-Fi Access Points, and devices for machine to machine (M2M) or Internet of Things applications. In some cases, these classes of devices represent a very large deployment base, on the order of thousands or even millions of devices network- wide. The scale of these networks, coupled with the increasingly overlapping use of RFC 1918 [RFC1918] address space within the @@ -199,25 +200,26 @@ Label Distribution Protocol (LDP) RFC 5036 [RFC5036] defines a set of procedures for distribution of labels between label switch routers 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 deficiencies that prohibit it from working in an IPv6-only network. 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 specifies appropriate protocol changes. These deficiencies are related to LSP mapping, LDP identifiers, LDP discovery, LDP session 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 Point to Multipoint (P2MP) and Multipoint to Multipoint (MP2MP) LSPs. These extensions are specified in RFC 6388 [RFC6388]. In terms of IPv6-only gap analysis, mLDP has two identified areas of interest: 1. LDP Control plane: Since mLDP uses the LDP control plane to discover and establish sessions with the peer, it shares the same gaps as LDP with regards to control plane (discovery, transport, and session establishment) in an IPv6-only network. @@ -251,58 +253,66 @@ 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 backbone receiving an MP FEC element with an IPv4 address. The 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 root address to equivalent IPv6 address (and vice vera) through the procedures similar to RFC6512. The translation of root address on borders of IPv4 or IPv6 islands will also be needed for recursive FECs and procedures defined in RFC6512. - Gap: Major, update in progress for LDP, may need additional updates - to RFC6512. + Gap: Major, update in progress for LDP via LDP-IPv6 + [I-D.ietf-mpls-ldp-ipv6], may need additional updates to RFC6512. 3.2.3. RSVP- TE Resource Reservation Protocol Extensions for MPLS Traffic Engineering (RSVP-TE) RFC 3209 [RFC3209] defines a set of procedures & enhancements to establish label-switched tunnels that can be automatically routed away from network failures, congestion, and bottlenecks. RSVP-TE allows establishing an LSP for an IPv4 or IPv6 prefix, thanks to its LSP_TUNNEL_IPv6 object and subobjects. + Gap: None + 3.2.3.1. IGP RFC3630 [RFC3630] specifies a method of adding traffic engineering capabilities to OSPF Version 2. New TLVs and sub-TLVs were added in RFC5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF Version 3. RFC5305 [RFC5305] specifies a method of adding traffic engineering capabilities to IS-IS. New TLVs and sub-TLVs were added in RFC6119 [RFC6119] to extend TE capabilities to IPv6 networks. + Gap: None + 3.2.3.2. RSVP-TE-P2MP RFC4875 [RFC4875] describes extensions to RSVP-TE for the setup of point-to-multipoint (P2MP) LSPs in MPLS and GMPLS with support for both IPv4 and IPv6. + Gap: None + 3.2.3.3. RSVP-TE Fast Reroute (FRR) RFC4090 [RFC4090] specifies FRR mechanisms to establish backup LSP tunnels for local repair supporting both IPv4 and IPv6 networks. Further RFC5286 [RFC5286] describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS networks in the event of a single failure, whether link, node, or shared risk link group (SRLG) for both IPv4 and IPv6. + Gap: None + 3.2.4. Controller, PCE The Path Computation Element (PCE) defined in RFC4655 [RFC4655] is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed. The PCE communication protocol (PCEP) is designed as a communication protocol between PCCs and PCEs for path computations and is defined in RFC5440 [RFC5440]. @@ -396,53 +406,62 @@ type. RFC 4659 [RFC4659] corrects this oversight. Also, Section 5 of RFC 4364 [RFC4364] assumes that the BGP next-hop contains exactly 32 bits. This text should be generalized to include 128 bit next- hops as well. The authors do not believe that there are any additional issues encountered when using L2TPv3, RSVP, or GRE (instead of MPLS) as transport on an IPv6-only network. 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 RFC 4798 [RFC4798] defines 6PE, which defines how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 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 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 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 neighboring AS. + Gap: Major. RFC4659 needs to be updated to explicitly cover use case + #2. + 3.3.2.2. 6VPE/4VPE RFC 4659 [RFC4659] defines 6VPE, a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services 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 as defined for use case 2 above, which could also be referred to as 4VPE, but the RFC does not explicitly discuss this use. + Gap: Minor. RFC4659 may need to be updated to explicitly cover use + case #2 + 3.3.2.3. BGP Encapsulation SAFI RFC 5512 [RFC5512] defines the BGP Encapsulation SAFI and the BGP Tunnel Encapsulation Attribute, which can be used to signal tunnelling over an single-Address Family IP core. This mechanism supports transport of MPLS (and other protocols) over Tunnels in an IP core (including an IPv6-only core). In this context, load- balancing can be provided as specified in RFC 5640 [RFC5640]. + Gap: None. + 3.3.2.4. NG-MVPN RFC 6513 [RFC6513] defines the procedure to provide multicast service over MPLS VPN backbone for the customers. The procedure involves the below set of protocols: 3.3.2.4.1. PE-CE Multicast Routing Protocol 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- @@ -483,21 +503,22 @@ 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. Gap: Any gaps in PIM or BGP as PE-PE Multicast Routing protocol are outside the scope of this document 3.3.3. MPLS-TP 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. 3.4. MPLS OAM For MPLS LSPs, there are primarily three OAM mechanisms: Extended ICMP RFC 4884 [RFC4884] RFC 4950 [RFC4950], LSP Ping RFC 4379 [RFC4379], and BFD for MPLS LSPs RFC 5884 [RFC5884]. For MPLS Pseudowires, there is also Virtual Circuit Connectivity Verification (VCCV) RFC 5085 [RFC5085] RFC 5885 [RFC5885]. All of these @@ -541,20 +563,24 @@ cannot parse the original IPv4 datagram, nor can it send an IPv4 message. So, no ICMP message is delivered to the source. Some specific ICMP extensions, in particular ICMP Extensions for Interface and Next-Hop Identification RFC 5837 [RFC5837] restrict the address family of address information included in an Interface Information 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 MPLS packets carrying IP datagrams. This has no implications for 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 The LSP Ping mechanism defined in RFC 4379 [RFC4379] is specified to work with IPv6. Specifically, the Target FEC Stacks include both 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 in RFC 6829 [RFC6829]. The multipath information includes also IPv6 encodings (see Section 3.3.1 of RFC 4379). @@ -591,40 +616,51 @@ IPv4-aware. It cannot parse the IPv4 Echo Request, nor can it send an IPv4 Echo Reply. So, no reply is sent. The mechanism described in RFC 4379 also does not sufficiently explain the behaviour in certain IPv6-specific scenarios. For 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 carry a 32 bit LSR Router ID in the 128 bit Downstream IP Address 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 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 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 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 VCCV for BFD RFC 5885 [RFC5885] also defines an IPv6 encapsulation (see Section 3.2 of RFC 5885). + Gap: None. + 3.4.5. MPLS-TP OAM 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 - 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 RFC3811 [RFC3811] defines the textual conventions for MPLS. These lack support for IPv6 in defining MplsExtendedTunnelId and MplsLsrIdentifier. These textual conventions are used in the MPLS TE MIB specification RFC3812 [RFC3812], GMPLS TE MIB specification RFC4802 [RFC4802] and Fast ReRoute (FRR) extension RFC6445 [RFC6445]. 3811bis [I-D.manral-mpls-rfc3811bis] tries to resolve this gap by marking this textual convention as obsolete. @@ -658,31 +694,37 @@ | | address and LDP TTL | | | | security | | +---------+--------------------------+------------------------------+ | L2VPN | RFC 6074 [RFC6074] | TBD | | S.3.3.1 | discovery, signaling | | +---------+--------------------------+------------------------------+ | L3VPN | RFC 4364 [RFC4364] BGP | TBD | | S.3.3.2 | next-hop, define method | | | | 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 | | S.3.5 | IPv6 textual convention | [I-D.manral-mpls-rfc3811bis] | +---------+--------------------------+------------------------------+ Table 1: IPv6-only MPLS Gaps 5. Acknowledgements - The authors wish to thank Andrew Yourtchenko for a detailed review, - as well as Brian Haberman, Joel Jaeggli, and Adrian Farrell for their - comments. + The authors wish to thank Andrew Yourtchenko and Loa Andersson for a + detailed review, as well as Brian Haberman, Joel Jaeggli, and Adrian + Farrell for their comments. 6. Contributing Authors The following people have contributed text to this draft: Rajiv Asati Cisco Systems 7025 Kit Creek Road @@ -785,22 +827,22 @@ FECs in the NLRI of BGP MCAST-VPN Routes", draft-ietf- l3vpn-mvpn-mldp-nlri-04 (work in progress), December 2013. [I-D.ietf-l3vpn-mvpn-pe-ce] Patel, K., Rekhter, Y., and E. Rosen, "BGP as an MVPN PE- CE Protocol", draft-ietf-l3vpn-mvpn-pe-ce-00 (work in progress), October 2013. [I-D.ietf-mpls-ldp-ipv6] Asati, R., Manral, V., Papneja, R., and C. Pignataro, - "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-11 - (work in progress), December 2013. + "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-12 + (work in progress), February 2014. [I-D.itojun-v6ops-v4mapped-harmful] Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire Considered Harmful", draft-itojun-v6ops-v4mapped- harmful-02 (work in progress), October 2003. [I-D.manral-mpls-rfc3811bis] Manral, V., Tsou, T., Will, W., and F. Fondelli, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", draft- @@ -1036,20 +1078,24 @@ VPNs", RFC 6514, February 2012. [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, April 2012. [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and 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 Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6", RFC 6829, January 2013. Appendix A. Assignments *RFC EDITOR PLEASE REMOVE BEFORE PUBLISHING* This will track which author volunteered for which section(s):