idnits 2.17.1 draft-mpls-ipv6-only-gap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 01, 2013) is 3950 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6513' is mentioned on line 417, but not defined == Missing Reference: 'RFC 5921' is mentioned on line 425, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-03 == Outdated reference: A later version (-17) exists of draft-ietf-mpls-ldp-ipv6-08 == Outdated reference: A later version (-04) exists of draft-manral-mpls-rfc3811bis-03 -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) -- Obsolete informational reference (is this intentional?): RFC 5268 (Obsoleted by RFC 5568) -- Obsolete informational reference (is this intentional?): RFC 6006 (Obsoleted by RFC 8306) -- Obsolete informational reference (is this intentional?): RFC 6829 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. George, Ed. 3 Internet-Draft Time Warner Cable 4 Intended status: Informational C. Pignataro 5 Expires: January 02, 2014 R. Asati 6 K. Raza 7 Cisco Systems 8 R. Bonica 9 Juniper Networks 10 R. Papneja 11 D. Dhody 12 Huawei Technologies 13 V. Manral 14 Hewlett-Packard, Inc. 15 July 01, 2013 17 Gap Analysis for Operating IPv6-only MPLS Networks 18 draft-mpls-ipv6-only-gap-00 20 Abstract 22 This document reviews the MPLS protocol suite in the context of IPv6 23 and identifies gaps that must be addressed in order to allow MPLS- 24 related protocols and applications to be used with IPv6-only 25 networks. This document is not intended to highlight a particular 26 vendor's implementation (or lack thereof) in the context of IPv6-only 27 MPLS functionality, but rather to focus on gaps in the standards 28 defining the MPLS suite. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 02, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. MPLS Control Plane . . . . . . . . . . . . . . . . . . . 5 68 3.1.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1.2. Multicast LDP . . . . . . . . . . . . . . . . . . . . 5 70 3.1.3. RSVP- TE . . . . . . . . . . . . . . . . . . . . . . 6 71 3.1.3.1. IGP . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1.3.2. RSVP-TE-P2MP . . . . . . . . . . . . . . . . . . 7 73 3.1.3.3. RSVP-TE Fast Reroute (FRR) . . . . . . . . . . . 7 74 3.1.4. Controller, PCE . . . . . . . . . . . . . . . . . . . 7 75 3.1.5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.1.6. GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 8 77 3.2. MPLS Applications . . . . . . . . . . . . . . . . . . . . 8 78 3.2.1. L2VPN . . . . . . . . . . . . . . . . . . . . . . . . 8 79 3.2.1.1. EVPN . . . . . . . . . . . . . . . . . . . . . . 8 80 3.2.2. L3VPN . . . . . . . . . . . . . . . . . . . . . . . . 8 81 3.2.2.1. 6PE/4PE . . . . . . . . . . . . . . . . . . . . . 9 82 3.2.2.2. 6VPE/4VPE . . . . . . . . . . . . . . . . . . . . 9 83 3.2.2.3. NG-MVPN . . . . . . . . . . . . . . . . . . . . . 9 84 3.2.3. MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . 10 85 3.3. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . . 10 86 3.3.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 10 87 3.3.2. LSP Ping . . . . . . . . . . . . . . . . . . . . . . 11 88 3.3.3. BFD . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 3.3.4. Pseudowires . . . . . . . . . . . . . . . . . . . . . 11 90 3.3.5. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 12 91 3.4. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 97 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 98 8.2. Informative References . . . . . . . . . . . . . . . . . 13 99 Appendix A. Assignments . . . . . . . . . . . . . . . . . . . . 18 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 102 1. Introduction 104 IPv6 is an integral part of modern network deployments. At the time 105 when this document was written, the majority of these IPv6 106 deployments were using dual-stack implementations, where IPv4 and 107 IPv6 are supported equally on many or all of the network nodes, and 108 single-stack primarily refers to IPv4-only devices. Dual-stack 109 deployments provide a useful margin for protocols and features that 110 are not currently capable of operating solely over IPv6, because they 111 can continue using IPv4 as necessary. However, as IPv6 deployment 112 and usage becomes more pervasive, and IPv4 exhaustion begins driving 113 changes in address consumption behaviors, there is an increasing 114 likelihood that many networks will need to start operating some or 115 all of their network nodes either as primarily IPv6 (most functions 116 use IPv6, a few legacy features use IPv4), or as IPv6-only (no IPv4 117 provisioned on the device). This transition toward IPv6-only 118 operation exposes any gaps where features, protocols, or 119 implementations are still reliant on IPv4 for proper function. To 120 that end, and in the spirit of RFC 6540's [RFC6540] recommendation 121 that implementations need to stop requiring IPv4 for proper and 122 complete function, this document reviews the MPLS protocol suite in 123 the context of IPv6 and identifies gaps that must be addressed in 124 order to allow MPLS-related protocols and applications to be used 125 with IPv6-only networks. This document is not intended to highlight 126 a particular vendor's implementation (or lack thereof) in the context 127 of IPv6-only MPLS functionality, but rather to focus on gaps in the 128 standards defining the MPLS suite. 130 1.1. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 2. Use Case 138 From a purely theoretical perspective, ensuring that MPLS is fully IP 139 version-agnostic is the right thing to do. However, it is sometimes 140 helpful to understand the underlying drivers that make this work 141 necessary to undertake, especially at a time when IPv6-only 142 networking is still fairly uncommon. This section will discuss some 143 drivers. It is not intended to be a comprehensive discussion of all 144 potential use cases, but rather a discussion of at least one use case 145 so that this is not seen as solving a purely theoretical problem. 147 IP convergence is continuing to drive new classes of devices to begin 148 communicating via IP. Examples of such devices could include set top 149 boxes for IP Video distribution, cell tower electronics (macro or 150 micro cells), infrastructure Wi-Fi Access Points, and devices for 151 machine to machine (M2M) or Internet of Things applications. In some 152 cases, these classes of devices represent a very large deployment 153 base, on the order of thousands or even millions of devices network- 154 wide. The scale of these networks, coupled with the increasingly 155 overlapping use of RFC 1918 [RFC1918] address space within the 156 average network, and the lack of globally-routable IPv4 space 157 available for long-term growth begins to drive the need for many of 158 the endpoints in this network to be managed solely via IPv6. Even if 159 these devices are carrying some IPv4 user data, it is often 160 encapsulated in another protocol such that the communication between 161 the endpoint and its upstream devices can be IPv6-only without 162 impacting support for IPv4 on user data. Depending on the MPLS 163 features required, it is plausible to assume that the (existing) MPLS 164 network may need to be extended to these devices. 166 Additionally, as the impact of IPv4 exhaustion becomes more acute, 167 more and more aggressive IPv4 address reclamation measures will be 168 justified. Measures that were previously seen as too complex or as 169 netting too few addresses for the work required may become more 170 realistic as the cost for obtaining new IPv4 addresses increases. 171 More and more networks are likely to adopt the general stance that 172 IPv4 addresses need to be preserved for revenue-generating customers 173 so that legacy support for IPv4 can be maintained as long as 174 possible. As a result, it may be appropriate for some or all of the 175 network infrastructure, including MPLS LSRs and LERs, to have its 176 IPv4 addresses reclaimed and transition toward IPv6-only operation. 178 3. Gap Analysis 179 This gap analysis aims to answer the question, "what breaks when one 180 attempts to use MPLS features on a network of IPv6-only devices?" 181 The assumption is that some endpoints as well as PE routers, P 182 routers ***(or LSR and LER)??*** only have IPv6 transport available, 183 and need to support the full suite of MPLS features defined as of the 184 time of this document's writing at parity with the support on an IPv4 185 network. This is necessary whether they are enabled via LDP RFC 5036 186 [RFC5036], RSVP-TE RFC 5420 [RFC5420], GRE RFC 4023 [RFC4023], or 187 L2TPv3 RFC 4817 [RFC4817]. It is important when evaluating these 188 gaps to distinguish between user data and control plane data, because 189 while this document is focused on IPv6-only operation, it is quite 190 likely that some amount of the user payload data being carried in the 191 IPv6-only MPLS network will still be IPv4. 193 3.1. MPLS Control Plane 195 3.1.1. LDP 197 Label Distribution Protocol (LDP) RFC 5036 [RFC5036] defines a set of 198 procedures for distribution of labels between label switch routers 199 that can use the labels for forwarding traffic. While LDP was 200 designed to use an IPv4 or dual-stack IP network, it has a number of 201 deficiencies that prohibit it from working in an IPv6-only network. 202 LDP-IPv6 [I-D.ietf-mpls-ldp-ipv6] highlights some of the deficiencies 203 when LDP is enabled in IPv6 only or dual-stack networks, and 204 specifies appropriate protocol changes. These deficiencies are 205 related to LSP mapping, LDP identifiers, LDP discovery, LDP session 206 establishment, next hop address and LDP TTL security RFC 5082 207 [RFC5082]. 209 3.1.2. Multicast LDP 211 Multipoint LDP (mLDP) is a set of extensions to LDP for setting up 212 Point to Multipoint (P2MP) and Multipoint to Multipoint (MP2MP) LSPs. 213 These extensions are specified in RFC 6388 [RFC6388]. In terms of 214 IPv6-only gap analysis, mLDP has two identified areas of interest: 216 1. LDP Control plane: Since mLDP uses the LDP control plane to 217 discover and establish sessions with the peer, it shares the same 218 gaps as LDP with regards to control plane (discovery, transport, 219 and session establishment) in an IPv6-only network. 221 2. Multipoint (MP) FEC Root address: mLDP defines its own MP FECs 222 and rules, different from LDP, to map MP LSPs. mLDP MP FEC 223 contains a Root Address field which is an IP address in IP 224 networks. The current specification allows specifying Root 225 address according to AFI and hence covers both IPv4 or IPv6 root 226 addresses, requiring no extension to support IPv6-only MP LSPs. 228 The root address is used by each LSR participating in an MP LSP 229 setup such that root address reachability is resolved by doing a 230 table lookup against root address to find corresponding upstream 231 neighbor(s). This will pose a problem when an MP LSP traverses 232 islands of IPv4 and IPv4 clouds on the way to the root node. 234 For example, consider following setup, where R1/R6 are IPv4-only, R3/ 235 R4 are IPv6-only, and R2/R5 are dual-stack LSRs: 237 ( IPv4-only ) ( IPv6-only ) ( IPv4-only ) 238 R1 -- R2 -- R3 -- R4 -- R5 -- R6 239 Leaf Root 241 Assume R1 to be a leaf node for an P2MP LSP rooted at R6 (root node). 242 R1 uses R6's IPv4 address as the Root address in MP FEC. As the MP 243 LSP signaling proceeds from R1 to R6, the MP LSP setup will fail on 244 the first IPv6-only transit/branch LSRs (R3) when trying to find IPv4 245 root address reachability. RFC 6512 [RFC6512] defines a recursive- 246 FEC solution and procedures for mLDP when the backbone (transit/ 247 branch) LSRs have no route to the root. The proposed solution is 248 defined for a BGP-free core in an VPN environment, but the similar 249 concept can be used/extended to solve the above issue of IPv6-only 250 backbone receiving an MP FEC element with an IPv4 address. The 251 solution will require a border LSR (the one which is sitting on 252 border of an IPv4/IPv6 island(s) (R2 and R5) to translate an IPv4 253 root address to equivalent IPv6 address (and vice vera) through the 254 procedures similar to RFC6512. The translation of root address on 255 borders of IPv4 or IPv6 islands will also be needed for recursive 256 FECs and procedures defined in RFC6512. 258 3.1.3. RSVP- TE 260 Resource Reservation Protocol Extensions for MPLS Traffic Engineering 261 (RSVP-TE) RFC 3209 [RFC3209] defines a set of procedures & 262 enhancements to establish label-switched tunnels that can be 263 automatically routed away from network failures, congestion, and 264 bottlenecks. RSVP-TE allows establishing an LSP for an IPv4 or IPv6 265 prefix, thanks to its LSP_TUNNEL_IPv6 object and subobjects. 267 3.1.3.1. IGP 269 RFC3630 [RFC3630] specifies a method of adding traffic engineering 270 capabilities to OSPF Version 2. New TLVs and sub-TLVs were added in 271 RFC5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF 272 Version 3. 274 RFC5305 [RFC5305] specifies a method of adding traffic engineering 275 capabilities to IS-IS. New TLVs and sub-TLVs were added in RFC6119 276 [RFC6119] to extend TE capabilities to IPv6 networks. 278 3.1.3.2. RSVP-TE-P2MP 280 RFC4875 [RFC4875] describes extensions to RSVP-TE for the setup of 281 point-to-multipoint (P2MP) LSPs in MPLS and GMPLS with support for 282 both IPv4 and IPv6. 284 3.1.3.3. RSVP-TE Fast Reroute (FRR) 286 RFC4090 [RFC4090] specifies FRR mechanisms to establish backup LSP 287 tunnels for local repair supporting both IPv4 and IPv6 networks. 288 Further RFC5268 [RFC5268] describes the use of loop-free alternates 289 to provide local protection for unicast traffic in pure IP and MPLS 290 networks in the event of a single failure, whether link, node, or 291 shared risk link group (SRLG) for both IPv4 and IPv6. 293 3.1.4. Controller, PCE 295 The Path Computation Element (PCE) defined in RFC4655 [RFC4655] is an 296 entity that is capable of computing a network path or route based on 297 a network graph, and applying computational constraints. A Path 298 Computation Client (PCC) may make requests to a PCE for paths to be 299 computed. The PCE communication protocol (PCEP) is designed as a 300 communication protocol between PCCs and PCEs for path computations 301 and is defined in RFC5440 [RFC5440]. 303 The PCEP specification RFC5440 [RFC5440] is defined for both IPv4 and 304 IPv6 with support for PCE discovery via an IGP (OSPF RFC5088 305 [RFC5088], or ISIS RFC5089 [RFC5089]) using both IPv4 and IPv6 306 addresses. Note that PCEP uses identical encoding of subobjects as 307 in the Resource Reservation Protocol Traffic Engineering Extensions 308 (RSVP-TE) defined in RFC3209 [RFC3209] which supports both IPv4 and 309 IPv6. 311 The extensions of PCEP to support confidentiality RFC5520 [RFC5520], 312 Route Exclusion RFC5521, [RFC5521] Monitoring RFC5886 [RFC5886], and 313 P2MP RFC6006 [RFC6006] have support for both IPv4 and IPv6. 315 3.1.5. BGP 317 RFC3107 [RFC3107] specifies a set of BGP protocol procedures for 318 distributing the labels (for prefixes corresponding to any address- 319 family) between label switch routers so that they can use the labels 320 for forwarding the traffic. RFC3107 allows BGP to distribute the 321 label for IPv4 or IPv6 prefix in an IPv6 only network. 323 3.1.6. GMPLS 325 RFC4558 [RFC4558] specifies Node-ID Based RSVP Hello Messages with 326 capability for both IPv4 and IPv6. RFC4990 [RFC4990] clarifies the 327 use of IPv6 addresses in GMPLS networks including handling in the MIB 328 modules. 330 3.2. MPLS Applications 332 3.2.1. L2VPN 334 L2VPN RFC 4664 [RFC4664] specifies two fundamentally different kinds 335 of Layer 2 VPN services that a service provider could offer to a 336 customer: Virtual Private Wire Service (VPWS) and Virtual Private LAN 337 Service (VPLS). RFC 4447 [RFC4447] and RFC 4762 [RFC4762] specify 338 the LDP protocol changes to instantiate VPWS and VPLS services 339 respectively in an MPLS network using LDP as the signaling protocol. 340 This is complemented by RFC 6074 [RFC6074], which specifies a set of 341 procedures for instantiating L2VPNs (e.g. VPWS, VPLS) using BGP as 342 discovery protocol and LDP (as well as L2TPv3) as signaling protocol. 343 RFC 4761 [RFC4761] and RFC 6624 [RFC6624] specify BGP protocol 344 changes to instantiate VPLS and VPWS services in an MPLS network, 345 using BGP for both discovery and signaling. 347 In an IPv6-only MPLS network, use of L2VPN represents connection of 348 Layer 2 islands over an IPv6 MPLS core, and very few changes are 349 necessary to support operation over an IPv6-only network. The L2VPN 350 signaling protocol is either BGP or LDP in an MPLS network, and both 351 can run directly over IPv6 core infrastructure, as well as IPv6 edge 352 devices. RFC 6074 [RFC6074] is the only RFC that appears to have a 353 gap wrt IPv6. In its discovery procedures (section 3.2.2 and section 354 6), it suggests encoding PE IP address in the VSI-ID, which is 355 encoded in NLRI, which should not exceed 12 bytes (to differentiate 356 its AFI/SAFI encoding from RFC4761). This means that PE IP address 357 can NOT be an IPv6 address. Also, in its signaling procedures 358 (section 3.2.3), it suggests encoding PE_addr in SAII and TAII, which 359 are limited to 32-bit (AII Type=1) at the moment. 361 3.2.1.1. EVPN 363 EVPN [I-D.ietf-l2vpn-evpn] is still a work in progress. As such, it 364 is out of scope for this gap analysis. Instead, the authors of that 365 draft need to ensure that it supports IPv6-only operation, or if it 366 cannot, identify dependencies on underlying gaps in MPLS protocol(s) 367 that must be resolved before it can support IPv6-only operation. 369 3.2.2. L3VPN 370 RFC 4364 [RFC4364] defines a method by which a Service Provider may 371 use an IP backbone to provide IP Virtual Private Networks (VPNs) for 372 its customers. The following use cases arise in the context of this 373 gap analysis: 375 1. Connecting IPv6 islands over IPv6-only MPLS network 377 2. Connecting IPv4 islands over IPv6-only MPLS network 379 Both use cases 1 and 2 require mapping an IP packet to an 380 IPv6-signaled LSP to the remote PE, which is not explicitly defined 381 in any RFC. RFC4364 has two MAJOR gaps. First, it is not possible 382 to use an IPv6-only MPLS network, since RFC4364 explicitly assumes 383 IPv4-only MPLS network i.e. BGP Next Hop is assumed to have /32 (for 384 example, see section 5 of RFC4364]. Second, it is limited to VPN- 385 IPv4 address-family i.e. connecting IPv4 islands over IPv4-only MPLS 386 networks. This second gap has been fixed by 6VPE RFC 4659 [RFC4659], 387 which defines connecting IPv6 VPN sites over an IPv4-only MPLS 388 networks, but more work is needed to address the first gap. 390 The authors do not believe that there are any additional issues 391 encountered when using L2TPv3, RSVP, or GRE (instead of LDP) as 392 transport on an IPv6-only network. 394 3.2.2.1. 6PE/4PE 396 RFC 4798 [RFC4798] defines 6PE, which defines how to interconnect 397 IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 398 cloud. However, use case 2 is doing the opposite, and thus could 399 also be referred to as 4PE. The method to support this use case is 400 not defined explicitly. To support it, IPv4 edge devices need to be 401 able to map IPv4 traffic to MPLS IPv6 core LSP's. Also, the core 402 switches may not understand IPv4 at all, but in some cases they may 403 need to be able to exchange Labeled IPv4 routes from one AS to a 404 neighboring AS. 406 3.2.2.2. 6VPE/4VPE 408 RFC 4659 [RFC4659] defines 6VPE, a method by which a Service Provider 409 may use its packet-switched backbone to provide Virtual Private 410 Network (VPN) services for its IPv6 customers. It allows the core 411 network to be MPLS IPv4 or MPLS IPv6, thus addressing use case 1 412 above. RFC4364 should work as defined for use case 2 above, which 413 could also be referred to as 4VPE, but the RFC does not explicitly 414 discuss this use. 416 3.2.2.3. NG-MVPN 417 ***TBD [RFC6513] both IPv4 and IPv6 multicast payload traffic*** 419 No IP version considerations? 421 3.2.3. MPLS-TP 423 ***TBD RFC 6371 *** MPLS-TP does not require IP ("and network 424 operation in the absence of a dynamic > control plane or IP 425 forwarding support." [RFC 5921]) and thus should not be affected by 426 operation on an IPv6-only network. 428 3.3. MPLS OAM 430 For MPLS LSPs, there are primarily three OAM mechanisms: Extended 431 ICMP RFC 4884 [RFC4884] RFC 4950 [RFC4950], LSP Ping RFC 4379 432 [RFC4379], and BFD for MPLS LSPs RFC 5884 [RFC5884]. For MPLS 433 Pseudowires, there is also Virtual Circuit Connectivity Verification 434 (VCCV) RFC 5085 [RFC5085] RFC 5885 [RFC5885]. All of these 435 mechanisms work in pure IPv6 environments. The next subsections 436 cover these in detail. 438 3.3.1. Extended ICMP 440 Extended ICMP to support Multi-part messages is defined in RFC 4884 441 [RFC4884]. This extensibility is defined generally for both ICMPv4 442 and ICMPv6. The specific ICMP extensions for MPLS are defined in RFC 443 4950 [RFC4950]. ICMP Multi-part with MPLS extensions works for IPv4 444 and IPv6. However, the mechanisms described in RFC 4884 and 4950 may 445 fail when tunneling IPv4 traffic over an LSP that is supported by 446 IPv6-only infrastructure. 448 Assume the following: 450 o the path between two IPv4 only hosts contains an MPLS LSP 452 o the two routers that terminate the LSP run dual stack 454 o the LSP interior routers run IPv6 only 456 o the LSP is signaled over IPv6 458 Now assume that one of the hosts sends an IPv6 packet to the other. 459 However, the packet's TTL expires on an LSP interior router. 460 According to RFC 3032 [RFC3032], the interior router should examine 461 the IPv6 payload, format an ICMPv6 message, and send it (over the 462 tunnel upon which the original packet arrived) to the egress LSP. In 463 this case, however, the LSP interior router is not IPv6-aware. It 464 cannot parse the original IPv6 datagram, nor can it send an IPv6 465 message. So, no ICMP message is delivered to the source. Some 466 specific ICMP extensions, in particular ICMP Extensions for Interface 467 and Next-Hop Identification RFC 5837 [RFC5837] restrict the address 468 family of address information included in an Interface Information 469 Object to the same one as the ICMP (see Section 4.5 of RFC 5837). 470 While these extensions are not MPLS specific, they can be used with 471 MPLS packets carrying IP datagrams. This has no implications for 472 IPv6-only environments. 474 3.3.2. LSP Ping 476 The LSP Ping mechanism defined in RFC 4379 [RFC4379] is specified to 477 work with IPv6. Specifically, the Target FEC Stacks include both 478 IPv4 and IPv6 versions of all FECs (see Section 3.2 of RFC 4379). 479 The only exceptions are the Pseudowire FECs later specified for IPv6 480 in RFC 6829 [RFC6829]. Additionally, LSP Ping packets are UDP 481 packets over both IPv4 and IPv6 (see Section 4.3 of RFC 4379). The 482 multipath information includes also IPv6 encodings (see Section 3.3.1 483 of RFC 4379). However, the mechanisms described in RFC 4379 may fail 484 when tunneling IPv4 traffic over an LSP that is supported by 485 IPv6-only infrastructure. 487 Assume the following: 489 o LSP Ping is operating in traceroute mode over an MPLS LSP 491 o the two routers that terminate the LSP run dual stack 493 o the LSP interior routers run IPv6 only 495 o the LSP is signaled over IPv6 497 Packets will expire at LSP interior routers. According to RFC 4379, 498 the interior router must parse the IPv4 Echo Request, and then, send 499 an IPv4 Echo Reply. However, the LSP interior router is not 500 IPv4-aware. It cannot parse the IPv4 Echo Request, nor can it send 501 an IPv4 Echo Reply. So, no reply is sent. 503 3.3.3. BFD 505 The BFD specification for MPLS LSPs RFC 5884 [RFC5884] is defined for 506 IPv4 as well as IPv6 versions of MPLS FECs (see Section 3.1 of RFC 507 5884). Additionally the BFD packet is encapsulated over UDP and 508 specified to run over both IPv4 and IPv6 (see Section 7 of RFC 5884). 510 3.3.4. Pseudowires 511 The OAM specifications for MPLS Pseudowires define usage for both 512 IPv4 and IPv6. Specifically, VCCV RFC 5085 [RFC5085] can carry IPv4 513 or IPv6 OAM packets (see Section 5.1.1 and 5.2.1 of RFC 5085), and 514 VCCV for BFD RFC 5885 [RFC5885] also defines an IPv6 encapsulation 515 (see Section 3.2 of RFC 5885). 517 3.3.5. MPLS-TP OAM 519 *** TBD*** 521 3.4. MIBs 523 RFC3811 [RFC3811] defines the textual conventions for MPLS. These 524 lack support for IPv6 in defining MplsExtendedTunnelId and 525 MplsLsrIdentifier. These textual conventions are used in the MPLS TE 526 MIB specification RFC3812 [RFC3812], GMPLS TE MIB specification 527 RFC4802 [RFC4802] and Fast ReRoute (FRR) extension RFC6445 [RFC6445]. 528 3811bis [I-D.manral-mpls-rfc3811bis] tries to resolve this gap by 529 marking this textual convention as obsolete. 531 The other MIB specifications for LSR RFC3813 [RFC3813], LDP RFC3815 532 [RFC3815] and TE RFC4220 [RFC4220] have support for both IPv4 and 533 IPv6. 535 4. Gap Summary 537 This draft has reviewed a wide variety of MPLS features and protocols 538 to determine their suitability for use on IPv6-only networks. While 539 some parts of the MPLS suite will function properly without 540 additional changes, gaps have been identified in others, which will 541 need to be addressed with follow-on work. This section will 542 summarize those gaps, along with pointers to any work-in-progress to 543 address them. 545 Identifed gaps in MPLS for IPv6-only networks 547 +---------+------------------------+--------------------------------+ 548 | Item | Gap | Addressed in | 549 +---------+------------------------+--------------------------------+ 550 | LDP | LSP mapping, LDP | LDP-IPv6 [I-D.ietf-mpls-ldp- | 551 | | identifiers, LDP | ipv6] | 552 | | discovery, LDP session | | 553 | | establishment, next | | 554 | | hop address and LDP | | 555 | | TTL security | | 556 | L2VPN | RFC 6074 [RFC6074] | TBD | 557 | | discovery, signaling | | 558 | L3VPN | RFC 4364 [RFC4364] BGP | TBD | 559 | | next-hop, define | | 560 | | method for 4PE/4VPE | | 561 | MIBs | RFC 3811 [RFC3811] no | 3811bis [I-D.manral-mpls- | 562 | | IPv6 textual | rfc3811bis] | 563 | | convention | | 564 +---------+------------------------+--------------------------------+ 566 Table 1: IPv6-only MPLS Gaps 568 5. Acknowledgements 570 This draft is brought to you by the letters I, P, V, and the number 571 6. 573 6. IANA Considerations 575 This memo includes no request to IANA. 577 7. Security Considerations 579 Changing the address family used for MPLS network operation does not 580 fundamentally alter the security considerations currently extant in 581 any of the specifics of the protocol or its features. However, the 582 change does expose the network and protocol to some of the 583 IPv6-specific security considerations inherent to IPv6 itself as 584 documented in [list of RFCs?] 586 8. References 588 8.1. Normative References 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, March 1997. 593 8.2. Informative References 595 [I-D.ietf-l2vpn-evpn] 596 Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F., 597 Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", 598 draft-ietf-l2vpn-evpn-03 (work in progress), February 599 2013. 601 [I-D.ietf-mpls-ldp-ipv6] 602 Asati, R., Manral, V., Papneja, R., and C. Pignataro, 603 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-08 604 (work in progress), February 2013. 606 [I-D.manral-mpls-rfc3811bis] 607 Manral, V., Tsou, T., Liu, W., and F. Fondelli, 608 "Definitions of Textual Conventions (TCs) for 609 Multiprotocol Label Switching (MPLS) Management", draft- 610 manral-mpls-rfc3811bis-03 (work in progress), June 2013. 612 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 613 E. Lear, "Address Allocation for Private Internets", BCP 614 5, RFC 1918, February 1996. 616 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 617 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 618 Encoding", RFC 3032, January 2001. 620 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 621 BGP-4", RFC 3107, May 2001. 623 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 624 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 625 Tunnels", RFC 3209, December 2001. 627 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 628 (TE) Extensions to OSPF Version 2", RFC 3630, September 629 2003. 631 [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual 632 Conventions (TCs) for Multiprotocol Label Switching (MPLS) 633 Management", RFC 3811, June 2004. 635 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 636 "Multiprotocol Label Switching (MPLS) Traffic Engineering 637 (TE) Management Information Base (MIB)", RFC 3812, June 638 2004. 640 [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, 641 "Multiprotocol Label Switching (MPLS) Label Switching 642 Router (LSR) Management Information Base (MIB)", RFC 3813, 643 June 2004. 645 [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions 646 of Managed Objects for the Multiprotocol Label Switching 647 (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 648 2004. 650 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 651 MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 652 4023, March 2005. 654 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 655 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 656 2005. 658 [RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering 659 Link Management Information Base", RFC 4220, November 660 2005. 662 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 663 Networks (VPNs)", RFC 4364, February 2006. 665 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 666 Label Switched (MPLS) Data Plane Failures", RFC 4379, 667 February 2006. 669 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 670 Heron, "Pseudowire Setup and Maintenance Using the Label 671 Distribution Protocol (LDP)", RFC 4447, April 2006. 673 [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, 674 "Node-ID Based Resource Reservation Protocol (RSVP) Hello: 675 A Clarification Statement", RFC 4558, June 2006. 677 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 678 Element (PCE)-Based Architecture", RFC 4655, August 2006. 680 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 681 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 682 IPv6 VPN", RFC 4659, September 2006. 684 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 685 Private Networks (L2VPNs)", RFC 4664, September 2006. 687 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 688 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 689 4761, January 2007. 691 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 692 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 693 RFC 4762, January 2007. 695 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 696 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 697 Provider Edge Routers (6PE)", RFC 4798, February 2007. 699 [RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label 700 Switching (GMPLS) Traffic Engineering Management 701 Information Base", RFC 4802, February 2007. 703 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and 704 J. Young, "Encapsulation of MPLS over Layer 2 Tunneling 705 Protocol Version 3", RFC 4817, March 2007. 707 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 708 "Extensions to Resource Reservation Protocol - Traffic 709 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 710 Switched Paths (LSPs)", RFC 4875, May 2007. 712 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 713 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 714 April 2007. 716 [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP 717 Extensions for Multiprotocol Label Switching", RFC 4950, 718 August 2007. 720 [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of 721 Addresses in Generalized Multiprotocol Label Switching 722 (GMPLS) Networks", RFC 4990, September 2007. 724 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 725 Specification", RFC 5036, October 2007. 727 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 728 Pignataro, "The Generalized TTL Security Mechanism 729 (GTSM)", RFC 5082, October 2007. 731 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 732 Connectivity Verification (VCCV): A Control Channel for 733 Pseudowires", RFC 5085, December 2007. 735 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 736 "OSPF Protocol Extensions for Path Computation Element 737 (PCE) Discovery", RFC 5088, January 2008. 739 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 740 "IS-IS Protocol Extensions for Path Computation Element 741 (PCE) Discovery", RFC 5089, January 2008. 743 [RFC5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June 744 2008. 746 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 747 Engineering", RFC 5305, October 2008. 749 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, 750 "Traffic Engineering Extensions to OSPF Version 3", RFC 751 5329, September 2008. 753 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 754 Ayyangarps, "Encoding of Attributes for MPLS LSP 755 Establishment Using Resource Reservation Protocol Traffic 756 Engineering (RSVP-TE)", RFC 5420, February 2009. 758 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 759 (PCE) Communication Protocol (PCEP)", RFC 5440, March 760 2009. 762 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 763 Topology Confidentiality in Inter-Domain Path Computation 764 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 766 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 767 Path Computation Element Communication Protocol (PCEP) for 768 Route Exclusions", RFC 5521, April 2009. 770 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 771 Rivers, "Extending ICMP for Interface and Next-Hop 772 Identification", RFC 5837, April 2010. 774 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 775 "Bidirectional Forwarding Detection (BFD) for MPLS Label 776 Switched Paths (LSPs)", RFC 5884, June 2010. 778 [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 779 Detection (BFD) for the Pseudowire Virtual Circuit 780 Connectivity Verification (VCCV)", RFC 5885, June 2010. 782 [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of 783 Monitoring Tools for Path Computation Element (PCE)-Based 784 Architecture", RFC 5886, June 2010. 786 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., 787 and J. Meuric, "Extensions to the Path Computation Element 788 Communication Protocol (PCEP) for Point-to-Multipoint 789 Traffic Engineering Label Switched Paths", RFC 6006, 790 September 2010. 792 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 793 "Provisioning, Auto-Discovery, and Signaling in Layer 2 794 Virtual Private Networks (L2VPNs)", RFC 6074, January 795 2011. 797 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 798 Engineering in IS-IS", RFC 6119, February 2011. 800 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 801 "Label Distribution Protocol Extensions for Point-to- 802 Multipoint and Multipoint-to-Multipoint Label Switched 803 Paths", RFC 6388, November 2011. 805 [RFC6445] Nadeau, T., Koushik, A., and R. Cetin, "Multiprotocol 806 Label Switching (MPLS) Traffic Engineering Management 807 Information Base for Fast Reroute", RFC 6445, November 808 2011. 810 [RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, 811 "Using Multipoint LDP When the Backbone Has No Route to 812 the Root", RFC 6512, February 2012. 814 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 815 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 816 RFC 6540, April 2012. 818 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 819 Virtual Private Networks Using BGP for Auto-Discovery and 820 Signaling", RFC 6624, May 2012. 822 [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label 823 Switched Path (LSP) Ping for Pseudowire Forwarding 824 Equivalence Classes (FECs) Advertised over IPv6", RFC 825 6829, January 2013. 827 Appendix A. Assignments 829 *RFC EDITOR PLEASE REMOVE BEFORE PUBLISHING* 830 This will track which author volunteered for which section(s): 832 OAM - Ron Bonica, Carlos Pignataro 834 LDP/mLDP (multicast) - Kamran Raza 836 L2VPN - Rajiv Asati, Vishwas Manral, Rajiv Papneja 838 L3VPN - Rajiv Asati, Vishwas Manral, Rajiv Papneja 840 PCE - Dhruv Dhody, Rajiv Papneja 842 Editors- Wes George(primary), Vishwas Manral, Rajiv Asati 844 Authors' Addresses 846 Wesley George (editor) 847 Time Warner Cable 848 13820 Sunrise Valley Drive 849 Herndon, VA 20111 850 US 852 Phone: +1-703-561-2540 853 Email: wesley.george@twcable.com 855 Carlos Pignataro 856 Cisco Systems 857 7200-12 Kit Creek Road 858 Research Triangle Park, NC 27709 859 US 861 Email: cpignata@cisco.com 863 Rajiv Asati 864 Cisco Systems 865 7025 Kit Creek Road 866 Research Triangle Park, NC 27709 867 US 869 Email: rajiva@cisco.com 870 Kamran Raza 871 Cisco Systems 872 2000 Innovation Drive 873 Ottawa, ON K2K-3E8 874 CA 876 Email: skraza@cisco.com 878 Ronald Bonica 879 Juniper Networks 880 2251 Corporate Park Drive 881 Herndon, VA 20171 882 US 884 Email: rbonica@juniper.net 886 Rajiv Papneja 887 Huawei Technologies 888 2330 Central Expressway 889 Santa Clara, CA 95050 890 US 892 Email: rajiv.papneja@huawei.com 894 Dhruv Dhody 895 Huawei Technologies 896 2330 Central Expressway 897 Santa Clara, CA 95050 898 US 900 Email: dhruv.dhody@huawei.com 902 Vishwas Manral 903 Hewlett-Packard, Inc. 904 19111 Pruneridge Ave. 905 Cupertino, CA 95014 906 US 908 Email: vishwas.manral@hp.com