idnits 2.17.1 draft-ietf-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 date (April 17, 2014) is 3655 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-06 == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-mvpn-mldp-nlri-04 == Outdated reference: A later version (-02) exists of draft-ietf-l3vpn-mvpn-pe-ce-01 == Outdated reference: A later version (-17) exists of draft-ietf-mpls-ldp-ipv6-12 == 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 5512 (Obsoleted by RFC 9012) -- 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 (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS W. George, Ed. 3 Internet-Draft Time Warner Cable 4 Intended status: Informational C. Pignataro, Ed. 5 Expires: October 19, 2014 Cisco 6 April 17, 2014 8 Gap Analysis for Operating IPv6-only MPLS Networks 9 draft-ietf-mpls-ipv6-only-gap-00 11 Abstract 13 This document reviews the MPLS protocol suite in the context of IPv6 14 and identifies gaps that must be addressed in order to allow MPLS- 15 related protocols and applications to be used with IPv6-only 16 networks. This document is not intended to highlight a particular 17 vendor's implementation (or lack thereof) in the context of IPv6-only 18 MPLS functionality, but rather to focus on gaps in the standards 19 defining the MPLS suite. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 19, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. MPLS Control Plane . . . . . . . . . . . . . . . . . . . 5 60 3.2.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2.2. Multipoint LDP . . . . . . . . . . . . . . . . . . . 5 62 3.2.3. RSVP- TE . . . . . . . . . . . . . . . . . . . . . . 6 63 3.2.3.1. IGP . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2.3.2. RSVP-TE-P2MP . . . . . . . . . . . . . . . . . . 7 65 3.2.3.3. RSVP-TE Fast Reroute (FRR) . . . . . . . . . . . 7 66 3.2.4. Controller, PCE . . . . . . . . . . . . . . . . . . . 7 67 3.2.5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.2.6. GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.3. MPLS Applications . . . . . . . . . . . . . . . . . . . . 8 70 3.3.1. L2VPN . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.3.1.1. EVPN . . . . . . . . . . . . . . . . . . . . . . 9 72 3.3.2. L3VPN . . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.3.2.1. 6PE/4PE . . . . . . . . . . . . . . . . . . . . . 10 74 3.3.2.2. 6VPE/4VPE . . . . . . . . . . . . . . . . . . . . 10 75 3.3.2.3. BGP Encapsulation SAFI . . . . . . . . . . . . . 10 76 3.3.2.4. NG-MVPN . . . . . . . . . . . . . . . . . . . . . 10 77 3.3.3. MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . 12 78 3.4. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . . 12 79 3.4.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 12 80 3.4.2. LSP Ping . . . . . . . . . . . . . . . . . . . . . . 13 81 3.4.3. BFD OAM . . . . . . . . . . . . . . . . . . . . . . . 14 82 3.4.4. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 14 83 3.4.5. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 15 84 3.5. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 87 6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 16 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 9. Informative References . . . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 93 1. Introduction 95 IPv6 is an integral part of modern network deployments. At the time 96 when this document was written, the majority of these IPv6 97 deployments were using dual-stack implementations, where IPv4 and 98 IPv6 are supported equally on many or all of the network nodes, and 99 single-stack primarily referred to IPv4-only devices. Dual-stack 100 deployments provide a useful margin for protocols and features that 101 are not currently capable of operating solely over IPv6, because they 102 can continue using IPv4 as necessary. However, as IPv6 deployment 103 and usage becomes more pervasive, and IPv4 exhaustion begins driving 104 changes in address consumption behaviors, there is an increasing 105 likelihood that many networks will need to start operating some or 106 all of their network nodes either as primarily IPv6 (most functions 107 use IPv6, a few legacy features use IPv4), or as IPv6-only (no IPv4 108 provisioned on the device). This transition toward IPv6-only 109 operation exposes any gaps where features, protocols, or 110 implementations are still reliant on IPv4 for proper function. To 111 that end, and in the spirit of RFC 6540's [RFC6540] recommendation 112 that implementations need to stop requiring IPv4 for proper and 113 complete function, this document reviews the Multi-Protocol Label 114 Switching (MPLS) protocol suite in the context of IPv6 and identifies 115 gaps that must be addressed in order to allow MPLS-related protocols 116 and applications to be used with IPv6-only networks. This document 117 is not intended to highlight a particular vendor's implementation (or 118 lack thereof) in the context of IPv6-only MPLS functionality, but 119 rather to focus on gaps in the standards defining the MPLS suite. 121 2. Use Case 123 This section discusses some drivers for ensuring that MPLS completely 124 supports IPv6-only operation. It is not intended to be a 125 comprehensive discussion of all potential use cases, but rather a 126 discussion of at least one use case to provide context and 127 justification to undertake such a gap analysis. 129 IP convergence is continuing to drive new classes of devices to begin 130 communicating via IP. Examples of such devices could include set top 131 boxes for IP Video distribution, cell tower electronics (macro or 132 micro cells), infrastructure Wi-Fi Access Points, and devices for 133 machine to machine (M2M) or Internet of Things applications. In some 134 cases, these classes of devices represent a very large deployment 135 base, on the order of thousands or even millions of devices network- 136 wide. The scale of these networks, coupled with the increasingly 137 overlapping use of RFC 1918 [RFC1918] address space within the 138 average network, and the lack of globally-routable IPv4 space 139 available for long-term growth begins to drive the need for many of 140 the endpoints in this network to be managed solely via IPv6. Even if 141 these devices are carrying some IPv4 user data, it is often 142 encapsulated in another protocol such that the communication between 143 the endpoint and its upstream devices can be IPv6-only without 144 impacting support for IPv4 on user data. As the number of devices to 145 manage increases, the operator is compelled to move to IPv6. 146 Depending on the MPLS features required, it is plausible to assume 147 that the (existing) MPLS network will need to be extended to these 148 IPv6-only devices. 150 Additionally, as the impact of IPv4 exhaustion becomes more acute, 151 more and more aggressive IPv4 address reclamation measures will be 152 justified. Many networks are likely to focus on preserving their 153 remaining IPv4 addresses for revenue-generating customers so that 154 legacy support for IPv4 can be maintained as long as possible. As a 155 result, it may be appropriate for some or all of the network 156 infrastructure, including MPLS LSRs and LERs, to have its IPv4 157 addresses reclaimed and transition toward IPv6-only operation. 159 3. Gap Analysis 161 This gap analysis aims to answer the question, "what breaks when one 162 attempts to use MPLS features on a network of IPv6-only devices?" 163 The baseline assumption for this analysis is that some endpoints as 164 well as Label Switch Routers (PE and P routers) only have IPv6 165 transport available, and need to support the full suite of MPLS 166 features defined as of the time of this document's writing at parity 167 with the support on an IPv4 network. This is necessary whether they 168 are enabled via Label Distribution Protocol (LDP) RFC 5036 [RFC5036], 169 Resource Reservation Protocol Extensions for MPLS Traffic Engineering 170 (RSVP-TE) RFC 3209 [RFC3209], or Border Gateway Protocol (BGP) RFC 171 3107 [RFC3107], and whether they are encapsulated in MPLS RFC 3032 172 [RFC3032], IP RFC 4023 [RFC4023], Generic Routing Encapsulation (GRE) 173 RFC 4023 [RFC4023], or Layer 2 Tunneling Protocol Version 3 (L2TPv3) 174 RFC 4817 [RFC4817]. It is important when evaluating these gaps to 175 distinguish between user data and control plane data, because while 176 this document is focused on IPv6-only operation, it is quite likely 177 that some amount of the user payload data being carried in the 178 IPv6-only MPLS network will still be IPv4. 180 3.1. MPLS Data Plane 182 MPLS labeled packets can be transmitted over a variety of data links 183 RFC 3032 [RFC3032], and MPLS labeled packets can also be encapsulated 184 over IP. The encapsulations of MPLS in IP and GRE as well as MPLS 185 over L2TPv3 support IPv6. See Section 3 of RFC 4023 [RFC4023] and 186 Section 2 of RFC 4817 [RFC4817] respectively. 188 In the case where an IPv4 prefix is resolved over an IPv6 LSP, an 189 IPv6 Explicit Null label cannot immediately preceed an IPv4 packet. 191 Gap: None. 193 3.2. MPLS Control Plane 195 3.2.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] and RFC 6720 [RFC6720]. 209 Gap: Major, update to RFC 5036 in progress that should close this 210 gap. 212 3.2.2. Multipoint LDP 214 Multipoint LDP (mLDP) is a set of extensions to LDP for setting up 215 Point to Multipoint (P2MP) and Multipoint to Multipoint (MP2MP) LSPs. 216 These extensions are specified in RFC 6388 [RFC6388]. In terms of 217 IPv6-only gap analysis, mLDP has two identified areas of interest: 219 1. LDP Control plane: Since mLDP uses the LDP control plane to 220 discover and establish sessions with the peer, it shares the same 221 gaps as LDP with regards to control plane (discovery, transport, 222 and session establishment) in an IPv6-only network. 224 2. Multipoint (MP) FEC Root address: mLDP defines its own MP FECs 225 and rules, different from LDP, to map MP LSPs. mLDP MP FEC 226 contains a Root Address field which is an IP address in IP 227 networks. The current specification allows specifying Root 228 address according to AFI and hence covers both IPv4 or IPv6 root 229 addresses, requiring no extension to support IPv6-only MP LSPs. 230 The root address is used by each LSR participating in an MP LSP 231 setup such that root address reachability is resolved by doing a 232 table lookup against root address to find corresponding upstream 233 neighbor(s). This will pose a problem if an MP LSP traverses 234 IPv4-only and IPv6-only nodes in a dual-stack network on the way 235 to the root node. 237 For example, consider following setup, where R1/R6 are IPv4-only, R3/ 238 R4 are IPv6-only, and R2/R5 are dual-stack LSRs: 240 ( IPv4-only ) ( IPv6-only ) ( IPv4-only ) 241 R1 -- R2 -- R3 -- R4 -- R5 -- R6 242 Leaf Root 244 Assume R1 to be a leaf node for an P2MP LSP rooted at R6 (root node). 245 R1 uses R6's IPv4 address as the Root address in MP FEC. As the MP 246 LSP signaling proceeds from R1 to R6, the MP LSP setup will fail on 247 the first IPv6-only transit/branch LSRs (R3) when trying to find IPv4 248 root address reachability. RFC 6512 [RFC6512] defines a recursive- 249 FEC solution and procedures for mLDP when the backbone (transit/ 250 branch) LSRs have no route to the root. The proposed solution is 251 defined for a BGP-free core in an VPN environment, but the similar 252 concept can be used/extended to solve the above issue of IPv6-only 253 backbone receiving an MP FEC element with an IPv4 address. The 254 solution will require a border LSR (the one which is sitting on 255 border of an IPv4/IPv6 island(s) (R2 and R5) to translate an IPv4 256 root address to equivalent IPv6 address (and vice vera) through the 257 procedures similar to RFC6512. The translation of root address on 258 borders of IPv4 or IPv6 islands will also be needed for recursive 259 FECs and procedures defined in RFC6512. 261 Gap: Major, update in progress for LDP via LDP-IPv6 262 [I-D.ietf-mpls-ldp-ipv6], may need additional updates to RFC6512. 264 3.2.3. RSVP- TE 266 Resource Reservation Protocol Extensions for MPLS Traffic Engineering 267 (RSVP-TE) RFC 3209 [RFC3209] defines a set of procedures & 268 enhancements to establish label-switched tunnels that can be 269 automatically routed away from network failures, congestion, and 270 bottlenecks. RSVP-TE allows establishing an LSP for an IPv4 or IPv6 271 prefix, thanks to its LSP_TUNNEL_IPv6 object and subobjects. 273 Gap: None 275 3.2.3.1. IGP 277 RFC3630 [RFC3630] specifies a method of adding traffic engineering 278 capabilities to OSPF Version 2. New TLVs and sub-TLVs were added in 279 RFC5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF 280 Version 3. 282 RFC5305 [RFC5305] specifies a method of adding traffic engineering 283 capabilities to IS-IS. New TLVs and sub-TLVs were added in RFC6119 284 [RFC6119] to extend TE capabilities to IPv6 networks. 286 Gap: None 288 3.2.3.2. RSVP-TE-P2MP 290 RFC4875 [RFC4875] describes extensions to RSVP-TE for the setup of 291 point-to-multipoint (P2MP) LSPs in MPLS and GMPLS with support for 292 both IPv4 and IPv6. 294 Gap: None 296 3.2.3.3. RSVP-TE Fast Reroute (FRR) 298 RFC4090 [RFC4090] specifies FRR mechanisms to establish backup LSP 299 tunnels for local repair supporting both IPv4 and IPv6 networks. 300 Further RFC5286 [RFC5286] describes the use of loop-free alternates 301 to provide local protection for unicast traffic in pure IP and MPLS 302 networks in the event of a single failure, whether link, node, or 303 shared risk link group (SRLG) for both IPv4 and IPv6. 305 Gap: None 307 3.2.4. Controller, PCE 309 The Path Computation Element (PCE) defined in RFC4655 [RFC4655] is an 310 entity that is capable of computing a network path or route based on 311 a network graph, and applying computational constraints. A Path 312 Computation Client (PCC) may make requests to a PCE for paths to be 313 computed. The PCE communication protocol (PCEP) is designed as a 314 communication protocol between PCCs and PCEs for path computations 315 and is defined in RFC5440 [RFC5440]. 317 The PCEP specification RFC5440 [RFC5440] is defined for both IPv4 and 318 IPv6 with support for PCE discovery via an IGP (OSPF RFC5088 319 [RFC5088], or ISIS RFC5089 [RFC5089]) using both IPv4 and IPv6 320 addresses. Note that PCEP uses identical encoding of subobjects as 321 in the Resource Reservation Protocol Traffic Engineering Extensions 322 (RSVP-TE) defined in RFC3209 [RFC3209] which supports both IPv4 and 323 IPv6. 325 The extensions of PCEP to support confidentiality RFC5520 [RFC5520], 326 Route Exclusion RFC5521, [RFC5521] Monitoring RFC5886 [RFC5886], and 327 P2MP RFC6006 [RFC6006] have support for both IPv4 and IPv6. 329 Gap: None. 331 3.2.5. BGP 333 RFC3107 [RFC3107] specifies a set of BGP protocol procedures for 334 distributing the labels (for prefixes corresponding to any address- 335 family) between label switch routers so that they can use the labels 336 for forwarding the traffic. RFC3107 allows BGP to distribute the 337 label for IPv4 or IPv6 prefix in an IPv6 only network. 339 Gap: None. 341 3.2.6. GMPLS 343 RFC4558 [RFC4558] specifies Node-ID Based RSVP Hello Messages with 344 capability for both IPv4 and IPv6. RFC4990 [RFC4990] clarifies the 345 use of IPv6 addresses in GMPLS networks including handling in the MIB 346 modules. 348 Section 5.3, second paragraph of RFC6370 [RFC6370] describes the 349 mapping from an MPLS-TP LSP_ID to RSVP-TE with an assumption that 350 Node_IDs are derived from valid IPv4 addresses. This assumption 351 fails in an IPv6-only network, given that there wouldn't be any IPv4 352 addresses. 354 Gap: Minor; Section 5.3. of RFC6370 needs to be updated. 356 3.3. MPLS Applications 358 3.3.1. L2VPN 360 L2VPN RFC 4664 [RFC4664] specifies two fundamentally different kinds 361 of Layer 2 VPN services that a service provider could offer to a 362 customer: Virtual Private Wire Service (VPWS) and Virtual Private LAN 363 Service (VPLS). RFC 4447 [RFC4447] and RFC 4762 [RFC4762] specify 364 the LDP protocol changes to instantiate VPWS and VPLS services 365 respectively in an MPLS network using LDP as the signaling protocol. 366 This is complemented by RFC 6074 [RFC6074], which specifies a set of 367 procedures for instantiating L2VPNs (e.g. VPWS, VPLS) using BGP as 368 discovery protocol and LDP as well as L2TPv3 as signaling protocol. 369 RFC 4761 [RFC4761] and RFC 6624 [RFC6624] specify BGP protocol 370 changes to instantiate VPLS and VPWS services in an MPLS network, 371 using BGP for both discovery and signaling. 373 In an IPv6-only MPLS network, use of L2VPN represents connection of 374 Layer 2 islands over an IPv6 MPLS core, and very few changes are 375 necessary to support operation over an IPv6-only network. The L2VPN 376 signaling protocol is either BGP or LDP in an MPLS network, and both 377 can run directly over IPv6 core infrastructure, as well as IPv6 edge 378 devices. RFC 6074 [RFC6074] is the only RFC that appears to have a 379 gap for IPv6-only operation. In its discovery procedures (section 380 3.2.2 and section 6), it suggests encoding PE IP address in the VSI- 381 ID, which is encoded in NLRI, and should not exceed 12 bytes (to 382 differentiate its AFI/SAFI encoding from RFC4761). This means that 383 PE IP address can NOT be an IPv6 address. Also, in its signaling 384 procedures (section 3.2.3), it suggests encoding PE_addr in SAII and 385 TAII, which are limited to 32-bit (AII Type=1) at the moment. 387 RFC 6073 [RFC6073] defines the new LDP PW Switching Point PE TLV, 388 which supports IPv4 and IPv6. 390 Gap: Minor. RFC6074 needs to be updated. 392 3.3.1.1. EVPN 394 EVPN [I-D.ietf-l2vpn-evpn] is still a work in progress. As such, it 395 is out of scope for this gap analysis. Instead, the authors of that 396 draft need to ensure that it supports IPv6-only operation, or if it 397 cannot, identify dependencies on underlying gaps in MPLS protocol(s) 398 that must be resolved before it can support IPv6-only operation. 400 3.3.2. L3VPN 402 RFC 4364 [RFC4364] defines a method by which a Service Provider may 403 use an IP backbone to provide IP Virtual Private Networks (VPNs) for 404 its customers. The following use cases arise in the context of this 405 gap analysis: 407 1. Connecting IPv6 islands over IPv6-only MPLS network 409 2. Connecting IPv4 islands over IPv6-only MPLS network 411 Both use cases require mapping an IP packet to an IPv6-signaled LSP. 412 RFC4364 defines a VPN-IPv4 address family, but not a VPN-IPv6 address 413 family. RFC 4659 [RFC4659] corrects this oversight. Also, Section 5 414 of RFC 4364 [RFC4364] assumes that the BGP next-hop contains exactly 415 32 bits. This text should be generalized to include 128 bit next- 416 hops as well. Section 3.2.1.1 of RFC 4659 [RFC4659] does actually 417 specifies a 128-bit BGP next-hop. 419 The authors do not believe that there are any additional issues 420 encountered when using L2TPv3, RSVP, or GRE (instead of MPLS) as 421 transport on an IPv6-only network. 423 Gap: Major. RFC4364 must be updated, and RFC4659 may need to be 424 updated to explicitly cover use case #2. (Discussed in further 425 detail below) 427 3.3.2.1. 6PE/4PE 429 RFC 4798 [RFC4798] defines 6PE, which defines how to interconnect 430 IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 431 cloud. However, use case 2 is doing the opposite, and thus could 432 also be referred to as 4PE. The method to support this use case is 433 not defined explicitly. To support it, IPv4 edge devices need to be 434 able to map IPv4 traffic to MPLS IPv6 core LSP's. Also, the core 435 switches may not understand IPv4 at all, but in some cases they may 436 need to be able to exchange Labeled IPv4 routes from one AS to a 437 neighboring AS. 439 Gap: Major. RFC4798 covers only the "6PE" case. Use case #2 is 440 currently not specified in an RFC. 442 3.3.2.2. 6VPE/4VPE 444 RFC 4659 [RFC4659] defines 6VPE, a method by which a Service Provider 445 may use its packet-switched backbone to provide Virtual Private 446 Network (VPN) services for its IPv6 customers. It allows the core 447 network to be MPLS IPv4 or MPLS IPv6, thus addressing use case 1 448 above. RFC4364 should work as defined for use case 2 above, which 449 could also be referred to as 4VPE, but the RFC does not explicitly 450 discuss this use. 452 Gap: Minor. RFC4659 may need to be updated to explicitly cover use 453 case #2 455 3.3.2.3. BGP Encapsulation SAFI 457 RFC 5512 [RFC5512] defines the BGP Encapsulation SAFI and the BGP 458 Tunnel Encapsulation Attribute, which can be used to signal tunneling 459 over a single-Address Family IP core. This mechanism supports 460 transport of MPLS (and other protocols) over Tunnels in an IP core 461 (including an IPv6-only core). In this context, load-balancing can 462 be provided as specified in RFC 5640 [RFC5640]. 464 Gap: None. 466 3.3.2.4. NG-MVPN 468 RFC 6513 [RFC6513] defines the procedure to provide multicast service 469 over MPLS VPN backbone for the customers. The procedure involves the 470 below set of protocols: 472 3.3.2.4.1. PE-CE Multicast Routing Protocol 474 RFC 6513 [RFC6513] explains the use of PIM as PE-CE protocol while 475 Section 11.1.2 of RFC 6514 [RFC6514] explains the use of mLDP as PE- 476 CE protocol. 478 The MCAST-VPN NLRI route-type format defined in RFC 6514 [RFC6514] is 479 not sufficiently covering all scenarios when mLDP is used as PE-CE 480 protocol. The issue is explained in section 2 of 481 [I-D.ietf-l3vpn-mvpn-mldp-nlri] along with new route-type that 482 encodes the mLDP FEC in NLRI. 484 Further [I-D.ietf-l3vpn-mvpn-pe-ce] defines the use of BGP as PE-CE 485 protocol. 487 Gap: None. 489 3.3.2.4.2. P-Tunnel Instantiation 491 RFC 6513 [RFC6513] explains the use of the below tunnels: 493 o RSVP-TE P2MP LSP 495 o PIM Tree 497 o mLDP P2MP LSP 499 o mLDP MP2MP LSP 501 o Ingress Replication 503 Gap: Gaps in RSVP-TE P2MP LSP and mLDP P2MP and MP2MP LSP are covered 504 in previous sections. 506 PIM Tree and Ingress Replication are out of the scope of this 507 document. 509 3.3.2.4.3. PE-PE Multicast Routing Protocol 511 Section 3.1 of RFC 6513 [RFC6513] explains the use of PIM as PE-PE 512 protocol while RFC 6514 [RFC6514] explains the use of BGP as PE-PE 513 protocol. 515 Gap: Any gaps in PIM or BGP as PE-PE Multicast Routing protocol are 516 outside the scope of this document 518 3.3.3. MPLS-TP 520 MPLS-TP does not require IP (see section 2 of RFC 5921 [RFC5921]) and 521 should not be affected by operation on an IPv6-only network. 522 Therefore this is considered out of scope for this document. 524 Gap: None. 526 3.4. MPLS OAM 528 For MPLS LSPs, there are primarily three OAM mechanisms: Extended 529 ICMP RFC 4884 [RFC4884] RFC 4950 [RFC4950], LSP Ping RFC 4379 530 [RFC4379], and BFD for MPLS LSPs RFC 5884 [RFC5884]. For MPLS 531 Pseudowires, there is also Virtual Circuit Connectivity Verification 532 (VCCV) RFC 5085 [RFC5085] RFC 5885 [RFC5885]. All of these 533 mechanisms work in pure IPv6 environments. The next subsections 534 cover these in detail. 536 Gap: Major. RFC4379 needs to be updated for multipath IPv6. 537 Additionally, there is potential for dropped messages in Extended 538 ICMP and LSP ping due to IP version mismatches. It is important to 539 note that this is a more generic problem with tunneling when IP 540 address family mismatches exist, and is not specific to MPLS, so 541 while MPLS will be affected, it will be difficult to fix this problem 542 specifically for MPLS, rather than fixing the more generic problem. 544 3.4.1. Extended ICMP 546 Extended ICMP to support Multi-part messages is defined in RFC 4884 547 [RFC4884]. This extensibility is defined generally for both ICMPv4 548 and ICMPv6. The specific ICMP extensions for MPLS are defined in RFC 549 4950 [RFC4950]. ICMP Multi-part with MPLS extensions works for IPv4 550 and IPv6. However, the mechanisms described in RFC 4884 and 4950 may 551 fail when tunneling IPv4 traffic over an LSP that is supported by 552 IPv6-only infrastructure. 554 Assume the following: 556 o the path between two IPv4 only hosts contains an MPLS LSP 558 o the two routers that terminate the LSP run dual stack 560 o the LSP interior routers run IPv6 only 562 o the LSP is signaled over IPv6 564 Now assume that one of the hosts sends an IPv4 packet to the other. 565 However, the packet's TTL expires on an LSP interior router. 567 According to RFC 3032 [RFC3032], the interior router should examine 568 the IPv4 payload, format an ICMPv4 message, and send it (over the 569 tunnel upon which the original packet arrived) to the egress LSP. In 570 this case, however, the LSP interior router is not IPv4-aware. It 571 cannot parse the original IPv4 datagram, nor can it send an IPv4 572 message. So, no ICMP message is delivered to the source. Some 573 specific ICMP extensions, in particular ICMP Extensions for Interface 574 and Next-Hop Identification RFC 5837 [RFC5837] restrict the address 575 family of address information included in an Interface Information 576 Object to the same one as the ICMP (see Section 4.5 of RFC 5837). 577 While these extensions are not MPLS specific, they can be used with 578 MPLS packets carrying IP datagrams. This has no implications for 579 IPv6-only environments. 581 Gap: Major. IP version mismatches may cause dropped messages. 582 However, as noted in the previous section, this problem is not 583 specific to MPLS. 585 3.4.2. LSP Ping 587 The LSP Ping mechanism defined in RFC 4379 [RFC4379] is specified to 588 work with IPv6. Specifically, the Target FEC Stacks include both 589 IPv4 and IPv6 versions of all FECs (see Section 3.2 of RFC 4379). 590 The only exceptions are the Pseudowire FECs later specified for IPv6 591 in RFC 6829 [RFC6829]. 593 The multipath information includes also IPv6 encodings (see 594 Section 3.3.1 of RFC 4379). 596 RFC 4379 does not define the value to be used in the IPv6 Router 597 Alert option (RAO). For IPv4 RAO, a value of zero is used. However, 598 there is no equivalent value for IPv6 RAO. This gap needs to be 599 fixed to be able to use LSP Ping in IPv6 networks. 601 Additionally, LSP Ping packets are UDP packets over both IPv4 and 602 IPv6 (see Section 4.3 of RFC 4379). However, for IPv6, the 603 destination IP address is a (randomly chosen) IPv6 address from the 604 range 0:0:0:0:0:FFFF:127/104. That is, using an IPv4-mapped IPv6 605 address. This is a transitional mechanism that should not bleed into 606 IPv6-only networks, as [I-D.itojun-v6ops-v4mapped-harmful] explains. 607 The issue is that the MPLS LSP Ping mechanism needs a range of 608 loopback IP addresses to be used as destination addresses to exercise 609 ECMPs, but the IPv6 address architecture specifies a single address 610 (::1/128) for loopback. A mechanism to achieve this was proposed in 611 [I-D.smith-v6ops-larger-ipv6-loopback-prefix]. 613 Another gap is that the mechanisms described in RFC 4379 may fail 614 when tunneling IPv4 traffic over an LSP that is supported by 615 IPv6-only infrastructure. 617 Assume the following: 619 o LSP Ping is operating in traceroute mode over an MPLS LSP 621 o the two routers that terminate the LSP run dual stack 623 o the LSP interior routers run IPv6 only 625 o the LSP is signaled over IPv6 627 Packets will expire at LSP interior routers. According to RFC 4379, 628 the interior router must parse the IPv4 Echo Request, and then, send 629 an IPv4 Echo Reply. However, the LSP interior router is not 630 IPv4-aware. It cannot parse the IPv4 Echo Request, nor can it send 631 an IPv4 Echo Reply. So, no reply is sent. 633 The mechanism described in RFC 4379 also does not sufficiently 634 explain the behaviour in certain IPv6-specific scenarios. For 635 example, RFC 4379 defines the K value as 28 octets when Address 636 Family is set to IPv6 Unnumbered, but it doesn't describe how to 637 carry a 32 bit LSR Router ID in the 128 bit Downstream IP Address 638 Field. 640 Gap: Major. LSP ping uses IPv4-mapped IPv6 addresses, IP version 641 mismatches may cause dropped messages, unclear mapping from LSR 642 Router ID to Downstream IP Address. 644 3.4.3. BFD OAM 646 The BFD specification for MPLS LSPs RFC 5884 [RFC5884] is defined for 647 IPv4 as well as IPv6 versions of MPLS FECs (see Section 3.1 of RFC 648 5884). Additionally the BFD packet is encapsulated over UDP and 649 specified to run over both IPv4 and IPv6 (see Section 7 of RFC 5884). 651 Gap: None. 653 3.4.4. Pseudowire OAM 655 The OAM specifications for MPLS Pseudowires define usage for both 656 IPv4 and IPv6. Specifically, VCCV RFC 5085 [RFC5085] can carry IPv4 657 or IPv6 OAM packets (see Section 5.1.1 and 5.2.1 of RFC 5085), and 658 VCCV for BFD RFC 5885 [RFC5885] also defines an IPv6 encapsulation 659 (see Section 3.2 of RFC 5885). 661 Additionally, for LSP Ping for Pseudowires, the Pseudowire FECs are 662 specified for IPv6 in RFC 6829 [RFC6829]. 664 Gap: None. 666 3.4.5. MPLS-TP OAM 668 As with MPLS-TP, MPLS-TP OAM RFC 6371 [RFC6371] is not dependent on 669 IP or existing MPLS OAM functions, and should not be affected by 670 operation on an IPv6-only network. Therefore, this is out of scope 671 for this document. 673 Gap: None. 675 3.5. MIBs 677 RFC3811 [RFC3811] defines the textual conventions for MPLS. These 678 lack support for IPv6 in defining MplsExtendedTunnelId and 679 MplsLsrIdentifier. These textual conventions are used in the MPLS TE 680 MIB specification RFC3812 [RFC3812], GMPLS TE MIB specification 681 RFC4802 [RFC4802] and Fast ReRoute (FRR) extension RFC6445 [RFC6445]. 682 3811bis [I-D.manral-mpls-rfc3811bis] tries to resolve this gap by 683 marking this textual convention as obsolete. 685 The other MIB specifications for LSR RFC3813 [RFC3813], LDP RFC3815 686 [RFC3815] and TE RFC4220 [RFC4220] have support for both IPv4 and 687 IPv6. 689 Gap: Major. Work underway to update RFC3811, may also need to update 690 RFC3812, RFC4802, and RFC6445, which depend on it. 692 4. Gap Summary 694 This draft has reviewed a wide variety of MPLS features and protocols 695 to determine their suitability for use on IPv6-only networks. While 696 some parts of the MPLS suite will function properly without 697 additional changes, gaps have been identified in others, which will 698 need to be addressed with follow-on work. This section will 699 summarize those gaps, along with pointers to any work-in-progress to 700 address them. 702 Identifed gaps in MPLS for IPv6-only networks 704 +---------+--------------------------+------------------------------+ 705 | Item | Gap | Addressed in | 706 +---------+--------------------------+------------------------------+ 707 | LDP | LSP mapping, LDP | LDP-IPv6 | 708 | S.3.2.1 | identifiers, LDP | [I-D.ietf-mpls-ldp-ipv6] | 709 | | discovery, LDP session | | 710 | | establishment, next hop | | 711 | | address and LDP TTL | | 712 | | security | | 713 +---------+--------------------------+------------------------------+ 714 | GMPLS | RFC6370 [RFC6370] Node | TBD | 715 | S.3.2.6 | ID derivation | | 716 +---------+--------------------------+------------------------------+ 717 | L2VPN | RFC 6074 [RFC6074] | TBD | 718 | S.3.3.1 | discovery, signaling | | 719 +---------+--------------------------+------------------------------+ 720 | L3VPN | RFC 4364 [RFC4364] BGP | TBD | 721 | S.3.3.2 | next-hop, define method | | 722 | | for 4PE/4VPE | | 723 +---------+--------------------------+------------------------------+ 724 | OAM | RFC 4379 [RFC4379] no | TBD | 725 | S.3.4 | IPv6 multipath support, | | 726 | | possible dropped | | 727 | | messages in IP version | | 728 | | mismatch | | 729 +---------+--------------------------+------------------------------+ 730 | MIBs | RFC 3811 [RFC3811] no | 3811bis | 731 | S.3.5 | IPv6 textual convention | [I-D.manral-mpls-rfc3811bis] | 732 +---------+--------------------------+------------------------------+ 734 Table 1: IPv6-only MPLS Gaps 736 5. Acknowledgements 738 The authors wish to thank Andrew Yourtchenko, Loa Andersson, David 739 Allan, Mach Chen, Mustapha Aissaoui, and Mark Tinka for their 740 detailed reviews, as well as Brian Haberman, Joel Jaeggli, Adrian 741 Farrell, and Nobo Akiya for their comments. 743 6. Contributing Authors 745 The following people have contributed text to this draft: 747 Rajiv Asati 748 Cisco Systems 749 7025 Kit Creek Road 750 Research Triangle Park, NC 27709 751 US 753 Email: rajiva@cisco.com 755 Kamran Raza 756 Cisco Systems 757 2000 Innovation Drive 758 Ottawa, ON K2K-3E8 759 CA 761 Email: skraza@cisco.com 763 Ronald Bonica 764 Juniper Networks 765 2251 Corporate Park Drive 766 Herndon, VA 20171 767 US 769 Email: rbonica@juniper.net 771 Rajiv Papneja 772 Huawei Technologies 773 2330 Central Expressway 774 Santa Clara, CA 95050 775 US 777 Email: rajiv.papneja@huawei.com 779 Dhruv Dhody 780 Huawei Technologies 781 Leela Palace 782 Bangalore, Karnataka 560008 783 IN 785 Email: dhruv.ietf@gmail.com 787 Vishwas Manral 788 Ionos Networks 789 Sunnyvale, CA 94089 790 US 792 Email: vishwas@ionosnetworks.com 793 Nagendra Kumar 794 Cisco Systems, Inc. 795 7200 Kit Creek Road 796 Research Triangle Park, NC 27709 797 US 799 Email: naikumar@cisco.com 801 7. IANA Considerations 803 This memo includes no request to IANA. 805 8. Security Considerations 807 Changing the address family used for MPLS network operation does not 808 fundamentally alter the security considerations currently extant in 809 any of the specifics of the protocol or its features. 811 9. Informative References 813 [I-D.ietf-l2vpn-evpn] 814 Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. 815 Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn- 816 evpn-06 (work in progress), March 2014. 818 [I-D.ietf-l3vpn-mvpn-mldp-nlri] 819 Wijnands, I., Rosen, E., and U. Joorde, "Encoding mLDP 820 FECs in the NLRI of BGP MCAST-VPN Routes", draft-ietf- 821 l3vpn-mvpn-mldp-nlri-04 (work in progress), December 2013. 823 [I-D.ietf-l3vpn-mvpn-pe-ce] 824 Patel, K., Rekhter, Y., and E. Rosen, "BGP as an MVPN PE- 825 CE Protocol", draft-ietf-l3vpn-mvpn-pe-ce-01 (work in 826 progress), March 2014. 828 [I-D.ietf-mpls-ldp-ipv6] 829 Asati, R., Manral, V., Papneja, R., and C. Pignataro, 830 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-12 831 (work in progress), February 2014. 833 [I-D.itojun-v6ops-v4mapped-harmful] 834 Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire 835 Considered Harmful", draft-itojun-v6ops-v4mapped- 836 harmful-02 (work in progress), October 2003. 838 [I-D.manral-mpls-rfc3811bis] 839 Manral, V., Tsou, T., Will, W., and F. Fondelli, 840 "Definitions of Textual Conventions (TCs) for 841 Multiprotocol Label Switching (MPLS) Management", draft- 842 manral-mpls-rfc3811bis-03 (work in progress), June 2013. 844 [I-D.smith-v6ops-larger-ipv6-loopback-prefix] 845 Smith, M., "A Larger Loopback Prefix for IPv6", draft- 846 smith-v6ops-larger-ipv6-loopback-prefix-04 (work in 847 progress), February 2013. 849 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 850 E. Lear, "Address Allocation for Private Internets", BCP 851 5, RFC 1918, February 1996. 853 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 854 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 855 Encoding", RFC 3032, January 2001. 857 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 858 BGP-4", RFC 3107, May 2001. 860 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 861 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 862 Tunnels", RFC 3209, December 2001. 864 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 865 (TE) Extensions to OSPF Version 2", RFC 3630, September 866 2003. 868 [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual 869 Conventions (TCs) for Multiprotocol Label Switching (MPLS) 870 Management", RFC 3811, June 2004. 872 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 873 "Multiprotocol Label Switching (MPLS) Traffic Engineering 874 (TE) Management Information Base (MIB)", RFC 3812, June 875 2004. 877 [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, 878 "Multiprotocol Label Switching (MPLS) Label Switching 879 Router (LSR) Management Information Base (MIB)", RFC 3813, 880 June 2004. 882 [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions 883 of Managed Objects for the Multiprotocol Label Switching 884 (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 885 2004. 887 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 888 MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 889 4023, March 2005. 891 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 892 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 893 2005. 895 [RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering 896 Link Management Information Base", RFC 4220, November 897 2005. 899 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 900 Networks (VPNs)", RFC 4364, February 2006. 902 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 903 Label Switched (MPLS) Data Plane Failures", RFC 4379, 904 February 2006. 906 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 907 Heron, "Pseudowire Setup and Maintenance Using the Label 908 Distribution Protocol (LDP)", RFC 4447, April 2006. 910 [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, 911 "Node-ID Based Resource Reservation Protocol (RSVP) Hello: 912 A Clarification Statement", RFC 4558, June 2006. 914 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 915 Element (PCE)-Based Architecture", RFC 4655, August 2006. 917 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 918 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 919 IPv6 VPN", RFC 4659, September 2006. 921 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 922 Private Networks (L2VPNs)", RFC 4664, September 2006. 924 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 925 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 926 4761, January 2007. 928 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 929 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 930 RFC 4762, January 2007. 932 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 933 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 934 Provider Edge Routers (6PE)", RFC 4798, February 2007. 936 [RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label 937 Switching (GMPLS) Traffic Engineering Management 938 Information Base", RFC 4802, February 2007. 940 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and 941 J. Young, "Encapsulation of MPLS over Layer 2 Tunneling 942 Protocol Version 3", RFC 4817, March 2007. 944 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 945 "Extensions to Resource Reservation Protocol - Traffic 946 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 947 Switched Paths (LSPs)", RFC 4875, May 2007. 949 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 950 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 951 April 2007. 953 [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP 954 Extensions for Multiprotocol Label Switching", RFC 4950, 955 August 2007. 957 [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of 958 Addresses in Generalized Multiprotocol Label Switching 959 (GMPLS) Networks", RFC 4990, September 2007. 961 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 962 Specification", RFC 5036, October 2007. 964 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 965 Pignataro, "The Generalized TTL Security Mechanism 966 (GTSM)", RFC 5082, October 2007. 968 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 969 Connectivity Verification (VCCV): A Control Channel for 970 Pseudowires", RFC 5085, December 2007. 972 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 973 "OSPF Protocol Extensions for Path Computation Element 974 (PCE) Discovery", RFC 5088, January 2008. 976 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 977 "IS-IS Protocol Extensions for Path Computation Element 978 (PCE) Discovery", RFC 5089, January 2008. 980 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 981 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 983 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 984 Engineering", RFC 5305, October 2008. 986 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, 987 "Traffic Engineering Extensions to OSPF Version 3", RFC 988 5329, September 2008. 990 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 991 (PCE) Communication Protocol (PCEP)", RFC 5440, March 992 2009. 994 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 995 Subsequent Address Family Identifier (SAFI) and the BGP 996 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 998 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 999 Topology Confidentiality in Inter-Domain Path Computation 1000 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 1002 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1003 Path Computation Element Communication Protocol (PCEP) for 1004 Route Exclusions", RFC 5521, April 2009. 1006 [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- 1007 Balancing for Mesh Softwires", RFC 5640, August 2009. 1009 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 1010 Rivers, "Extending ICMP for Interface and Next-Hop 1011 Identification", RFC 5837, April 2010. 1013 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 1014 "Bidirectional Forwarding Detection (BFD) for MPLS Label 1015 Switched Paths (LSPs)", RFC 5884, June 2010. 1017 [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 1018 Detection (BFD) for the Pseudowire Virtual Circuit 1019 Connectivity Verification (VCCV)", RFC 5885, June 2010. 1021 [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of 1022 Monitoring Tools for Path Computation Element (PCE)-Based 1023 Architecture", RFC 5886, June 2010. 1025 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 1026 Berger, "A Framework for MPLS in Transport Networks", RFC 1027 5921, July 2010. 1029 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., 1030 and J. Meuric, "Extensions to the Path Computation Element 1031 Communication Protocol (PCEP) for Point-to-Multipoint 1032 Traffic Engineering Label Switched Paths", RFC 6006, 1033 September 2010. 1035 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 1036 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 1038 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 1039 "Provisioning, Auto-Discovery, and Signaling in Layer 2 1040 Virtual Private Networks (L2VPNs)", RFC 6074, January 1041 2011. 1043 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1044 Engineering in IS-IS", RFC 6119, February 2011. 1046 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 1047 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 1049 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 1050 Maintenance Framework for MPLS-Based Transport Networks", 1051 RFC 6371, September 2011. 1053 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 1054 "Label Distribution Protocol Extensions for Point-to- 1055 Multipoint and Multipoint-to-Multipoint Label Switched 1056 Paths", RFC 6388, November 2011. 1058 [RFC6445] Nadeau, T., Koushik, A., and R. Cetin, "Multiprotocol 1059 Label Switching (MPLS) Traffic Engineering Management 1060 Information Base for Fast Reroute", RFC 6445, November 1061 2011. 1063 [RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, 1064 "Using Multipoint LDP When the Backbone Has No Route to 1065 the Root", RFC 6512, February 2012. 1067 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 1068 VPNs", RFC 6513, February 2012. 1070 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1071 Encodings and Procedures for Multicast in MPLS/BGP IP 1072 VPNs", RFC 6514, February 2012. 1074 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 1075 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 1076 RFC 6540, April 2012. 1078 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 1079 Virtual Private Networks Using BGP for Auto-Discovery and 1080 Signaling", RFC 6624, May 2012. 1082 [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security 1083 Mechanism (GTSM) for the Label Distribution Protocol 1084 (LDP)", RFC 6720, August 2012. 1086 [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label 1087 Switched Path (LSP) Ping for Pseudowire Forwarding 1088 Equivalence Classes (FECs) Advertised over IPv6", RFC 1089 6829, January 2013. 1091 Authors' Addresses 1093 Wesley George (editor) 1094 Time Warner Cable 1095 13820 Sunrise Valley Drive 1096 Herndon, VA 20111 1097 US 1099 Phone: +1-703-561-2540 1100 Email: wesley.george@twcable.com 1102 Carlos Pignataro (editor) 1103 Cisco Systems, Inc. 1104 7200-12 Kit Creek Road 1105 Research Triangle Park, NC 27709 1106 US 1108 Phone: +1-919-392-7428 1109 Email: cpignata@cisco.com