idnits 2.17.1 draft-ietf-mpls-ipv6-only-gap-02.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 (August 25, 2014) is 3524 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-07 == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-mvpn-mldp-nlri-05 == 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-13 == Outdated reference: A later version (-04) exists of draft-manral-mpls-rfc3811bis-03 == Outdated reference: A later version (-02) exists of draft-raza-mpls-oam-ipv6-rao-00 -- 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 (~~), 7 warnings (==), 8 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: February 26, 2015 Cisco 6 August 25, 2014 8 Gap Analysis for Operating IPv6-only MPLS Networks 9 draft-ietf-mpls-ipv6-only-gap-02 11 Abstract 13 This document reviews the Multiprotocol Label Switching (MPLS) 14 protocol suite in the context of IPv6 and identifies gaps that must 15 be addressed in order to allow MPLS-related protocols and 16 applications to be used with IPv6-only networks. This document is 17 not intended to highlight a particular vendor's implementation (or 18 lack thereof) in the context of IPv6-only MPLS functionality, but 19 rather to focus on gaps in the standards 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 February 26, 2015. 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 . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . 11 76 3.3.2.4. MVPN . . . . . . . . . . . . . . . . . . . . . . 11 77 3.3.3. MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . 12 78 3.4. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . . 12 79 3.4.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 13 80 3.4.2. LSP Ping . . . . . . . . . . . . . . . . . . . . . . 14 81 3.4.3. BFD OAM . . . . . . . . . . . . . . . . . . . . . . . 15 82 3.4.4. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 15 83 3.4.5. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 15 84 3.5. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 87 6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 90 9. Informative References . . . . . . . . . . . . . . . . . . . 19 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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 and networks that 117 are primarily IPv6 (hereafter referred to as IPv6-primary). This 118 document is not intended to highlight a particular vendor's 119 implementation (or lack thereof) in the context of IPv6-only MPLS 120 functionality, but rather to focus on gaps in the standards defining 121 the MPLS suite. 123 2. Use Case 125 This section discusses some drivers for ensuring that MPLS completely 126 supports IPv6-only operation. It is not intended to be a 127 comprehensive discussion of all potential use cases, but rather a 128 discussion of one use case to provide context and justification to 129 undertake such a gap analysis. 131 IP convergence is continuing to drive new classes of devices to begin 132 communicating via IP. Examples of such devices could include set top 133 boxes for IP Video distribution, cell tower electronics (macro or 134 micro cells), infrastructure Wi-Fi Access Points, and devices for 135 machine to machine (M2M) or Internet of Things applications. In some 136 cases, these classes of devices represent a very large deployment 137 base, on the order of thousands or even millions of devices network- 138 wide. The scale of these networks, coupled with the increasingly 139 overlapping use of RFC 1918 [RFC1918] address space within the 140 average network, and the lack of globally-routable IPv4 space 141 available for long-term growth begins to drive the need for many of 142 the endpoints in this network to be managed solely via IPv6. Even if 143 these devices are carrying some IPv4 user data, it is often 144 encapsulated in another protocol such that the communication between 145 the endpoint and its upstream devices can be IPv6-only without 146 impacting support for IPv4 on user data. As the number of devices to 147 manage increases, the operator is compelled to move to IPv6. 148 Depending on the MPLS features required, it is plausible to assume 149 that the (existing) MPLS network will need to be extended to these 150 IPv6-only devices. 152 Additionally, as the impact of IPv4 exhaustion becomes more acute, 153 more and more aggressive IPv4 address reclamation measures will be 154 justified. Many networks are likely to focus on preserving their 155 remaining IPv4 addresses for revenue-generating customers so that 156 legacy support for IPv4 can be maintained as long as necessary. As a 157 result, it may be appropriate for some or all of the network 158 infrastructure, including MPLS Label Switch Routers (LSRs) and Label 159 Edge Routers (LERs), to have its IPv4 addresses reclaimed and 160 transition toward IPv6-only operation. 162 3. Gap Analysis 164 This gap analysis aims to answer the question, "what fails when one 165 attempts to use MPLS features on a network of IPv6-only devices?" 166 The baseline assumption for this analysis is that some endpoints as 167 well as Label Switch Routers (Provider Edge (PE) and Provider (P) 168 routers) only have IPv6 transport available, and need to support the 169 full suite of MPLS features defined as of the time of this document's 170 writing at parity with the support on an IPv4 network. This is 171 necessary whether they are enabled via Label Distribution Protocol 172 (LDP) RFC 5036 [RFC5036], Resource Reservation Protocol Extensions 173 for MPLS Traffic Engineering (RSVP-TE) RFC 3209 [RFC3209], or Border 174 Gateway Protocol (BGP) RFC 3107 [RFC3107], and whether they are 175 encapsulated in MPLS RFC 3032 [RFC3032], IP RFC 4023 [RFC4023], 176 Generic Routing Encapsulation (GRE) RFC 4023 [RFC4023], or Layer 2 177 Tunneling Protocol Version 3 (L2TPv3) RFC 4817 [RFC4817]. It is 178 important when evaluating these gaps to distinguish between user data 179 and control plane data, because while this document is focused on 180 IPv6-only operation, it is quite likely that some amount of the user 181 payload data being carried in the IPv6-only MPLS network will still 182 be IPv4. 184 A note about terminology: Gaps identified by this document are 185 characterized as "Major" or "Minor". Major gaps refer to significant 186 changes necessary in one or more standards to address the gap due to 187 existing standards language having either missing functionality for 188 IPv6-only operation or explicit language requiring the use of IPv4 189 with no IPv6 alternatives defined. Minor gaps refer to changes 190 necessary primarily to clarify existing standards language. Usually 191 these changes are needed in order to explicitly codify IPv6 support 192 in places where it is either implicit or omitted today, but the 193 omission is unlikely to prevent IPv6-only operation. 195 3.1. MPLS Data Plane 197 MPLS labeled packets can be transmitted over a variety of data links 198 RFC 3032 [RFC3032], and MPLS labeled packets can also be encapsulated 199 over IP. The encapsulations of MPLS in IP and GRE as well as MPLS 200 over L2TPv3 support IPv6. See Section 3 of RFC 4023 [RFC4023] and 201 Section 2 of RFC 4817 [RFC4817] respectively. 203 Gap: None. 205 3.2. MPLS Control Plane 207 3.2.1. LDP 209 Label Distribution Protocol (LDP) RFC 5036 [RFC5036] defines a set of 210 procedures for distribution of labels between label switch routers 211 that can use the labels for forwarding traffic. While LDP was 212 designed to use an IPv4 or dual-stack IP network, it has a number of 213 deficiencies that prohibit it from working in an IPv6-only network. 214 LDP-IPv6 [I-D.ietf-mpls-ldp-ipv6] highlights some of the deficiencies 215 when LDP is enabled in IPv6 only or dual-stack networks, and 216 specifies appropriate protocol changes. These deficiencies are 217 related to LSP mapping, LDP identifiers, LDP discovery, LDP session 218 establishment, next hop address and LDP Time To Live (TTL) security 219 RFC 5082 [RFC5082] and RFC 6720 [RFC6720]. 221 Gap: Major, update to RFC 5036 in progress via LDP-IPv6 222 [I-D.ietf-mpls-ldp-ipv6] that should close this gap. 224 3.2.2. Multipoint LDP 226 Multipoint LDP (mLDP) is a set of extensions to LDP for setting up 227 Point to Multipoint (P2MP) and Multipoint to Multipoint (MP2MP) LSPs. 228 These extensions are specified in RFC 6388 [RFC6388]. In terms of 229 IPv6-only gap analysis, mLDP has two identified areas of interest: 231 1. LDP Control plane: Since mLDP uses the LDP control plane to 232 discover and establish sessions with the peer, it shares the same 233 gaps as LDP (Section 3.2.1) with regards to control plane 234 (discovery, transport, and session establishment) in an IPv6-only 235 network. 237 2. Multipoint (MP) FEC Root address: mLDP defines its own MP 238 Forwarding Equivalence Classes (FECs) and rules, different from 239 LDP, to map MP LSPs. mLDP MP FEC contains a Root Address field 240 which is an IP address in IP networks. The current specification 241 allows specifying Root address according to Address Family 242 Identifier (AFI) and hence covers both IPv4 or IPv6 root 243 addresses, requiring no extension to support IPv6-only MP LSPs. 244 The root address is used by each LSR participating in an MP LSP 245 setup such that root address reachability is resolved by doing a 246 table lookup against the root address to find corresponding 247 upstream neighbor(s). This will pose a problem if an MP LSP 248 traverses IPv4-only and IPv6-only nodes in a dual-stack network 249 on the way to the root node. 251 For example, consider following setup, where R1/R6 are IPv4-only, R3/ 252 R4 are IPv6-only, and R2/R5 are dual-stack LSRs: 254 ( IPv4-only ) ( IPv6-only ) ( IPv4-only ) 255 R1 -- R2 -- R3 -- R4 -- R5 -- R6 256 Leaf Root 258 Assume R1 to be a leaf node for an P2MP LSP rooted at R6 (root node). 259 R1 uses R6's IPv4 address as the Root address in MP FEC. As the MP 260 LSP signaling proceeds from R1 to R6, the MP LSP setup will fail on 261 the first IPv6-only transit/branch LSRs (R3) when trying to find IPv4 262 root address reachability. RFC 6512 [RFC6512] defines a recursive- 263 FEC solution and procedures for mLDP when the backbone (transit/ 264 branch) LSRs have no route to the root. The proposed solution is 265 defined for a BGP-free core in an VPN environment, but a similar 266 concept can be used/extended to solve the above issue of IPv6-only 267 backbone receiving an MP FEC element with an IPv4 address. The 268 solution will require a border LSR (the one which is sitting on 269 border of an IPv4/IPv6 island(s) (R2 and R5) to translate an IPv4 270 root address to equivalent IPv6 address (and vice vera) through 271 procedures similar to RFC6512. 273 Gap: Major, update in progress for LDP via LDP-IPv6 274 [I-D.ietf-mpls-ldp-ipv6], may need additional updates to RFC6512. 276 3.2.3. RSVP- TE 278 Resource Reservation Protocol Extensions for MPLS Traffic Engineering 279 (RSVP-TE) RFC 3209 [RFC3209] defines a set of procedures and 280 enhancements to establish label-switched tunnels that can be 281 automatically routed away from network failures, congestion, and 282 bottlenecks. RSVP-TE allows establishing an LSP for an IPv4 or IPv6 283 prefix, thanks to its LSP_TUNNEL_IPv6 object and subobjects. 285 Gap: None 287 3.2.3.1. IGP 289 RFC3630 [RFC3630] specifies a method of adding traffic engineering 290 capabilities to OSPF Version 2. New TLVs and sub-TLVs were added in 291 RFC5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF 292 Version 3. 294 RFC5305 [RFC5305] specifies a method of adding traffic engineering 295 capabilities to IS-IS. New TLVs and sub-TLVs were added in RFC6119 296 [RFC6119] to extend TE capabilities to IPv6 networks. 298 Gap: None 300 3.2.3.2. RSVP-TE-P2MP 302 RFC4875 [RFC4875] describes extensions to RSVP-TE for the setup of 303 point-to-multipoint (P2MP) LSPs in MPLS and Generalized MPLS (GMPLS) 304 with support for both IPv4 and IPv6. 306 Gap: None 308 3.2.3.3. RSVP-TE Fast Reroute (FRR) 310 RFC4090 [RFC4090] specifies FRR mechanisms to establish backup LSP 311 tunnels for local repair supporting both IPv4 and IPv6 networks. 312 Further RFC5286 [RFC5286] describes the use of loop-free alternates 313 to provide local protection for unicast traffic in pure IP and MPLS 314 networks in the event of a single failure, whether link, node, or 315 shared risk link group (SRLG) for both IPv4 and IPv6. 317 Gap: None 319 3.2.4. Controller, PCE 321 The Path Computation Element (PCE) defined in RFC4655 [RFC4655] is an 322 entity that is capable of computing a network path or route based on 323 a network graph, and applying computational constraints. A Path 324 Computation Client (PCC) may make requests to a PCE for paths to be 325 computed. The PCE communication protocol (PCEP) is designed as a 326 communication protocol between PCCs and PCEs for path computations 327 and is defined in RFC5440 [RFC5440]. 329 The PCEP specification RFC5440 [RFC5440] is defined for both IPv4 and 330 IPv6 with support for PCE discovery via an IGP (OSPF RFC5088 331 [RFC5088], or ISIS RFC5089 [RFC5089]) using both IPv4 and IPv6 332 addresses. Note that PCEP uses identical encoding of subobjects as 333 in the Resource Reservation Protocol Traffic Engineering Extensions 334 (RSVP-TE) defined in RFC3209 [RFC3209] which supports both IPv4 and 335 IPv6. 337 The extensions of PCEP to support confidentiality RFC5520 [RFC5520], 338 Route Exclusion RFC5521, [RFC5521] Monitoring RFC5886 [RFC5886], and 339 P2MP RFC6006 [RFC6006] have support for both IPv4 and IPv6. 341 Gap: None. 343 3.2.5. BGP 345 RFC3107 [RFC3107] specifies a set of BGP protocol procedures for 346 distributing the labels (for prefixes corresponding to any address- 347 family) between label switch routers so that they can use the labels 348 for forwarding the traffic. RFC3107 allows BGP to distribute the 349 label for IPv4 or IPv6 prefix in an IPv6 only network. 351 Gap: None. 353 3.2.6. GMPLS 355 RFC4558 [RFC4558] specifies Node-ID Based RSVP Hello Messages with 356 capability for both IPv4 and IPv6. RFC4990 [RFC4990] clarifies the 357 use of IPv6 addresses in GMPLS networks including handling in the MIB 358 modules. 360 Section 5.3, second paragraph of RFC6370 [RFC6370] describes the 361 mapping from an MPLS Transport Profile (MPLS-TP) LSP_ID to RSVP-TE 362 with an assumption that Node_IDs are derived from valid IPv4 363 addresses. This assumption fails in an IPv6-only network, given that 364 there wouldn't be any IPv4 addresses. 366 Gap: Minor; Section 5.3. of RFC6370 needs to be updated. 368 3.3. MPLS Applications 370 3.3.1. L2VPN 372 L2VPN RFC 4664 [RFC4664] specifies two fundamentally different kinds 373 of Layer 2 VPN services that a service provider could offer to a 374 customer: Virtual Private Wire Service (VPWS) and Virtual Private LAN 375 Service (VPLS). RFC 4447 [RFC4447] and RFC 4762 [RFC4762] specify 376 the LDP protocol changes to instantiate VPWS and VPLS services 377 respectively in an MPLS network using LDP as the signaling protocol. 378 This is complemented by RFC 6074 [RFC6074], which specifies a set of 379 procedures for instantiating L2VPNs (e.g. VPWS, VPLS) using BGP as 380 discovery protocol and LDP as well as L2TPv3 as signaling protocol. 382 RFC 4761 [RFC4761] and RFC 6624 [RFC6624] specify BGP protocol 383 changes to instantiate VPLS and VPWS services in an MPLS network, 384 using BGP for both discovery and signaling. 386 In an IPv6-only MPLS network, use of L2VPN represents connection of 387 Layer 2 islands over an IPv6 MPLS core, and very few changes are 388 necessary to support operation over an IPv6-only network. The L2VPN 389 signaling protocol is either BGP or LDP in an MPLS network, and both 390 can run directly over IPv6 core infrastructure, as well as IPv6 edge 391 devices. RFC 6074 [RFC6074] is the only RFC that appears to have a 392 gap for IPv6-only operation. In its discovery procedures (section 393 3.2.2 and section 6), it suggests encoding PE IP address in the VSI- 394 ID, which is encoded in Network Layer Reachability Information 395 (NLRI), and should not exceed 12 bytes (to differentiate its AFI/SAFI 396 (Subsequent Address Family Identifier) encoding from RFC4761). This 397 means that PE IP address can NOT be an IPv6 address. Also, in its 398 signaling procedures (section 3.2.3), it suggests encoding PE_addr in 399 Source Attachment Individual Identifier (SAII) and Target Attachment 400 Individual Identifier (TAII), which are limited to 32-bit (AII 401 Type=1) at the moment. 403 RFC 6073 [RFC6073] defines the new LDP Pseudowire (PW) Switching 404 Point PE TLV, which supports IPv4 and IPv6. 406 Gap: Minor. RFC6074 needs to be updated. 408 3.3.1.1. EVPN 410 Ethernet VPN (EVPN) [I-D.ietf-l2vpn-evpn] defines a method for using 411 BGP MPLS-based Ethernet VPNs. Because it can use functions in LDP 412 and mLDP, as well as RFC 7117 [RFC7117] Multicast VPLS, it inherits 413 gaps previously identified in LDP (Section 3.2.1) and RFC 6074 414 [RFC6074]. Once those gaps are resolved, it should function properly 415 on IPv6-only networks as defined. 417 3.3.2. L3VPN 419 RFC 4364 [RFC4364] defines a method by which a Service Provider may 420 use an IP backbone to provide IP Virtual Private Networks (VPNs) for 421 its customers. The following use cases arise in the context of this 422 gap analysis: 424 1. Connecting IPv6 islands over IPv6-only MPLS network 426 2. Connecting IPv4 islands over IPv6-only MPLS network 428 Both use cases require mapping an IP packet to an IPv6-signaled LSP. 429 RFC4364 defines Layer 3 Virtual Private Networks (L3VPNs) for IPv4 430 only and has references to 32-bit BGP next hop addresses. RFC 4659 431 [RFC4659] adds support for IPv6 on L3VPNs including 128-bit BGP next 432 hop addresses, and discusses operation whether IPv6 is the payload or 433 the underlying transport address family. However, RFC4659 does not 434 formally update RFC4364, and thus an implementer may miss this 435 additional set of standards unless it is explicitly identified 436 independently of the base functionality defined in RFC4364. An 437 erratum has been filed to correct this metadata problem. Further, 438 section 1 of RFC4659 explicitly identifies use case #2 as out of 439 scope for the document. 441 The authors do not believe that there are any additional issues 442 encountered when using L2TPv3, RSVP, or GRE (instead of MPLS) as 443 transport on an IPv6-only network. 445 Gap: Major. RFC4659 needs to be updated to explicitly cover use case 446 #2. (Discussed in further detail below) 448 3.3.2.1. 6PE/4PE 450 RFC 4798 [RFC4798] defines IPv6 Provider Edge (6PE), which defines 451 how to interconnect IPv6 islands over a MPLS-enabled IPv4 cloud. 452 However, use case 2 is doing the opposite, and thus could also be 453 referred to as IPv4 Provider Edge (4PE). The method to support this 454 use case is not defined explicitly. To support it, IPv4 edge devices 455 need to be able to map IPv4 traffic to MPLS IPv6 core LSP's. Also, 456 the core switches may not understand IPv4 at all, but in some cases 457 they may need to be able to exchange Labeled IPv4 routes from one AS 458 to a neighboring AS. 460 Gap: Major. RFC4798 covers only the "6PE" case. Use case #2 is 461 currently not specified in an RFC. 463 3.3.2.2. 6VPE/4VPE 465 RFC 4659 [RFC4659] defines IPv6 Virtual Private Network Extension 466 (6VPE), a method by which a Service Provider may use its packet- 467 switched backbone to provide Virtual Private Network (VPN) services 468 for its IPv6 customers. It allows the core network to be MPLS IPv4 469 or MPLS IPv6, thus addressing use case 1 above. RFC4364 should work 470 as defined for use case 2 above, which could also be referred to as 471 IPv4 Virtual Private Extension (4VPE), but the RFC explicitly does 472 not discuss this use and defines it as out of scope. 474 Gap: Minor. RFC4659 needs to be updated to explicitly cover use case 475 #2 477 3.3.2.3. BGP Encapsulation SAFI 479 RFC 5512 [RFC5512] defines the BGP Encapsulation SAFI and the BGP 480 Tunnel Encapsulation Attribute, which can be used to signal tunneling 481 over a single-Address Family IP core. This mechanism supports 482 transport of MPLS (and other protocols) over Tunnels in an IP core 483 (including an IPv6-only core). In this context, load-balancing can 484 be provided as specified in RFC 5640 [RFC5640]. 486 Gap: None. 488 3.3.2.4. MVPN 490 RFC 6513 [RFC6513] defines the procedure to provide multicast service 491 over an MPLS VPN backbone for downstream customers. It is sometimes 492 referred to as Next Generation Multicast VPN (NG-MVPN) The procedure 493 involves the below set of protocols: 495 3.3.2.4.1. PE-CE Multicast Routing Protocol 497 RFC 6513 [RFC6513] explains the use of Protocol Independent Multicast 498 (PIM) as Provider Edge-Customer Edge (PE-CE) protocol while 499 Section 11.1.2 of RFC 6514 [RFC6514] explains the use of mLDP as PE- 500 CE protocol. 502 The MCAST-VPN NLRI route-type format defined in RFC 6514 [RFC6514] is 503 not sufficiently covering all scenarios when mLDP is used as PE-CE 504 protocol. The issue is explained in section 2 of 505 [I-D.ietf-l3vpn-mvpn-mldp-nlri] along with new route-type that 506 encodes the mLDP FEC in NLRI. 508 Further [I-D.ietf-l3vpn-mvpn-pe-ce] defines the use of BGP as PE-CE 509 protocol. 511 Gap: None. 513 3.3.2.4.2. P-Tunnel Instantiation 515 RFC 6513 [RFC6513] explains the use of the below tunnels: 517 o RSVP-TE P2MP LSP 519 o PIM Tree 521 o mLDP P2MP LSP 523 o mLDP MP2MP LSP 524 o Ingress Replication 526 Gap: Gaps in RSVP-TE P2MP LSP (Section 3.2.3.2) and mLDP 527 (Section 3.2.2) P2MP and MP2MP LSP are covered in previous sections. 528 There are no MPLS-specific gaps for PIM Tree or Ingress Replication 529 and any protocol-specific gaps not related to MPLS are outside the 530 scope of this document. 532 3.3.2.4.3. PE-PE Multicast Routing Protocol 534 Section 3.1 of RFC 6513 [RFC6513] explains the use of PIM as PE-PE 535 protocol while RFC 6514 [RFC6514] explains the use of BGP as PE-PE 536 protocol. 538 PE-PE multicast routing is not specific to P-tunnel or to MPLS. It 539 can be PIM or BGP with label based or PIM tree based P-Tunnels. 540 Enabling PIM as a PE-PE multicast protocol is equivalent to running 541 it on a non-MPLS IPv6 network, so there are not any MPLS-specific 542 considerations, and any gaps are applicable for non-MPLS networks as 543 well. Similarly, BGP only includes the PMSI tunnel attribute as a 544 part of the NLRI which is inherited from P-tunnel instantiation and 545 considered to be an opaque value. So any gaps in the Control plane 546 (PIM or BGP) will not be specific to MPLS. 548 Gap: Any gaps in PIM or BGP as PE-PE Multicast Routing protocol are 549 not unique to MPLS, and therefore are outside the scope of this 550 document. It is included for completeness. 552 3.3.3. MPLS-TP 554 MPLS-TP does not require IP (see section 2 of RFC 5921 [RFC5921]) and 555 should not be affected by operation on an IPv6-only network. 556 Therefore this is considered out of scope for this document, but is 557 included for completeness. 559 Gap: None. 561 3.4. MPLS OAM 563 For MPLS LSPs, there are primarily three Operations, Administration, 564 and Maintenance (OAM) mechanisms: Extended ICMP RFC 4884 [RFC4884] 565 RFC 4950 [RFC4950], LSP Ping RFC 4379 [RFC4379], and Bidirectional 566 Forwarding Detection (BFD) for MPLS LSPs RFC 5884 [RFC5884]. For 567 MPLS Pseudowires, there is also Virtual Circuit Connectivity 568 Verification (VCCV) RFC 5085 [RFC5085] RFC 5885 [RFC5885]. Most of 569 these mechanisms work in pure IPv6 environments, but there are some 570 problems encountered in mixed environments due to address-family 571 mismatches. The next subsections cover these gaps in detail. 573 Gap: Major. RFC4379 needs to be updated to better support multipath 574 IPv6. Additionally, there is potential for dropped messages in 575 Extended ICMP and LSP ping due to IP version mismatches. It is 576 important to note that this is a more generic problem with tunneling 577 when IP address family mismatches exist, and is not specific to MPLS, 578 so while MPLS will be affected, it will be difficult to fix this 579 problem specifically for MPLS, rather than fixing the more generic 580 problem. 582 3.4.1. Extended ICMP 584 Extended ICMP to support Multi-part messages is defined in RFC 4884 585 [RFC4884]. This extensibility is defined generally for both ICMPv4 586 and ICMPv6. The specific ICMP extensions for MPLS are defined in RFC 587 4950 [RFC4950]. ICMP Multi-part with MPLS extensions works for IPv4 588 and IPv6. However, the mechanisms described in RFC 4884 and 4950 may 589 fail when tunneling IPv4 traffic over an LSP that is supported by an 590 IPv6-only infrastructure. 592 Assume the following: 594 o the path between two IPv4 only hosts contains an MPLS LSP 596 o the two routers that terminate the LSP run dual stack 598 o the LSP interior routers run IPv6 only 600 o the LSP is signaled over IPv6 602 Now assume that one of the hosts sends an IPv4 packet to the other. 603 However, the packet's TTL expires on an LSP interior router. 604 According to RFC 3032 [RFC3032], the interior router should examine 605 the IPv4 payload, format an ICMPv4 message, and send it (over the 606 tunnel upon which the original packet arrived) to the egress LSP. In 607 this case, however, the LSP interior router is not IPv4-aware. It 608 cannot parse the original IPv4 datagram, nor can it send an IPv4 609 message. So, no ICMP message is delivered to the source. Some 610 specific ICMP extensions, in particular ICMP Extensions for Interface 611 and Next-Hop Identification RFC 5837 [RFC5837] restrict the address 612 family of address information included in an Interface Information 613 Object to the same one as the ICMP (see Section 4.5 of RFC 5837). 614 While these extensions are not MPLS specific, they can be used with 615 MPLS packets carrying IP datagrams. This has no implications for 616 IPv6-only environments. 618 Gap: Major. IP version mismatches may cause dropped messages. 619 However, as noted in the previous section, this problem is not 620 specific to MPLS. 622 3.4.2. LSP Ping 624 The LSP Ping mechanism defined in RFC 4379 [RFC4379] is specified to 625 work with IPv6. Specifically, the Target FEC Stacks include both 626 IPv4 and IPv6 versions of all FECs (see Section 3.2 of RFC 4379). 627 The only exceptions are the Pseudowire FECs, which are later 628 specified for IPv6 in RFC 6829 [RFC6829]. The multipath information 629 also includes IPv6 encodings (see Section 3.3.1 of RFC 4379). 631 LSP Ping packets are UDP packets over either IPv4 or IPv6 (see 632 Section 4.3 of RFC 4379). However, for IPv6 the destination IP 633 address is a (randomly chosen) IPv6 address from the range 634 0:0:0:0:0:FFFF:127/104. That is, using an IPv4-mapped IPv6 address. 635 This is a transitional mechanism that should not bleed into IPv6-only 636 networks, as [I-D.itojun-v6ops-v4mapped-harmful] explains. The issue 637 is that the MPLS LSP Ping mechanism needs a range of loopback IP 638 addresses to be used as destination addresses to exercise Equal Cost 639 Multiple Path (ECMP), but the IPv6 address architecture specifies a 640 single address (::1/128) for loopback. A mechanism to achieve this 641 was proposed in [I-D.smith-v6ops-larger-ipv6-loopback-prefix]. 643 Additionally, RFC 4379 does not define the value to be used in the 644 IPv6 Router Alert option (RAO). For IPv4 RAO, a value of zero is 645 used. However, there is no equivalent value for IPv6 RAO. This gap 646 needs to be fixed to be able to use LSP Ping in IPv6 networks. 647 Further details on this gap are captured, along with a proposed 648 solution, in [I-D.raza-mpls-oam-ipv6-rao]. 650 Another gap is that the mechanisms described in RFC 4379 may fail 651 when tunneling IPv4 traffic over an LSP that is supported by 652 IPv6-only infrastructure. 654 Assume the following: 656 o LSP Ping is operating in traceroute mode over an MPLS LSP 658 o the two routers that terminate the LSP run dual stack 660 o the LSP interior routers run IPv6 only 662 o the LSP is signaled over IPv6 664 Packets will expire at LSP interior routers. According to RFC 4379, 665 the interior router must parse the IPv4 Echo Request, and then, send 666 an IPv4 Echo Reply. However, the LSP interior router is not 667 IPv4-aware. It cannot parse the IPv4 Echo Request, nor can it send 668 an IPv4 Echo Reply. So, no reply is sent. 670 The mechanism described in RFC 4379 also does not sufficiently 671 explain the behaviour in certain IPv6-specific scenarios. For 672 example, RFC 4379 defines the K value as 28 octets when Address 673 Family is set to IPv6 Unnumbered, but it doesn't describe how to 674 carry a 32 bit LSR Router ID in the 128 bit Downstream IP Address 675 Field. 677 Gap: Major. LSP ping uses IPv4-mapped IPv6 addresses, IP version 678 mismatches may cause dropped messages, unclear mapping from LSR 679 Router ID to Downstream IP Address. 681 3.4.3. BFD OAM 683 The BFD specification for MPLS LSPs RFC 5884 [RFC5884] is defined for 684 IPv4 as well as IPv6 versions of MPLS FECs (see Section 3.1 of RFC 685 5884). Additionally the BFD packet is encapsulated over UDP and 686 specified to run over both IPv4 and IPv6 (see Section 7 of RFC 5884). 688 Gap: None. 690 3.4.4. Pseudowire OAM 692 The OAM specifications for MPLS Pseudowires define usage for both 693 IPv4 and IPv6. Specifically, VCCV RFC 5085 [RFC5085] can carry IPv4 694 or IPv6 OAM packets (see Section 5.1.1 and 5.2.1 of RFC 5085), and 695 VCCV for BFD RFC 5885 [RFC5885] also defines an IPv6 encapsulation 696 (see Section 3.2 of RFC 5885). 698 Additionally, for LSP Ping for Pseudowires, the Pseudowire FECs are 699 specified for IPv6 in RFC 6829 [RFC6829]. 701 Gap: None. 703 3.4.5. MPLS-TP OAM 705 As with MPLS-TP, MPLS-TP OAM RFC 6371 [RFC6371] is not dependent on 706 IP or existing MPLS OAM functions, and should not be affected by 707 operation on an IPv6-only network. Therefore, this is out of scope 708 for this document, but is included for completeness. 710 Gap: None. 712 3.5. MIBs 714 RFC3811 [RFC3811] defines the textual conventions for MPLS. These 715 lack support for IPv6 in defining MplsExtendedTunnelId and 716 MplsLsrIdentifier. These textual conventions are used in the MPLS TE 717 Management Information Base (MIB) specification RFC3812 [RFC3812], 718 GMPLS TE MIB specification RFC4802 [RFC4802] and Fast ReRoute (FRR) 719 extension RFC6445 [RFC6445]. 3811bis [I-D.manral-mpls-rfc3811bis] 720 tries to resolve this gap by marking this textual convention as 721 obsolete. 723 The other MIB specifications for LSR RFC3813 [RFC3813], LDP RFC3815 724 [RFC3815] and TE RFC4220 [RFC4220] have support for both IPv4 and 725 IPv6. 727 Gap: Major. Work underway to update RFC3811 via 3811bis 728 [I-D.manral-mpls-rfc3811bis], may also need to update RFC3812, 729 RFC4802, and RFC6445, which depend on it. 731 4. Gap Summary 733 This draft has reviewed a wide variety of MPLS features and protocols 734 to determine their suitability for use on IPv6-only or IPv6-primary 735 networks. While some parts of the MPLS suite will function properly 736 without additional changes, gaps have been identified in others, 737 which will need to be addressed with follow-on work. This section 738 will summarize those gaps, along with pointers to any work in 739 progress to address them. Note that because the referenced drafts 740 are works in progress and do not have consensus at the time of this 741 document's publication, there could be other solutions proposed at a 742 future time, and the pointers in this document should not be 743 considered normative in any way. Additionally, work in progress on 744 new features that use MPLS protocols will need to ensure that those 745 protocols support operation on IPv6-only or IPv6-primary networks, or 746 explicitly identify any dependencies on existing gaps that, once 747 resolved, will allow proper IPv6-only operation. 749 Identifed gaps in MPLS for IPv6-only networks 751 +---------+--------------------------+------------------------------+ 752 | Item | Gap | Addressed in | 753 +---------+--------------------------+------------------------------+ 754 | LDP | LSP mapping, LDP | LDP-IPv6 | 755 | S.3.2.1 | identifiers, LDP | [I-D.ietf-mpls-ldp-ipv6] | 756 | | discovery, LDP session | | 757 | | establishment, next hop | | 758 | | address and LDP TTL | | 759 | | security | | 760 +---------+--------------------------+------------------------------+ 761 | mLDP | inherits gaps from LDP, | inherits LDP-IPv6 | 762 | S.3.2.2 | RFC6512 [RFC6512] | [I-D.ietf-mpls-ldp-ipv6], | 763 | | | additional fixes TBD | 764 +---------+--------------------------+------------------------------+ 765 | GMPLS | RFC6370 [RFC6370] Node | TBD | 766 | S.3.2.6 | ID derivation | | 767 +---------+--------------------------+------------------------------+ 768 | L2VPN | RFC 6074 [RFC6074] | TBD | 769 | S.3.3.1 | discovery, signaling | | 770 +---------+--------------------------+------------------------------+ 771 | L3VPN | RFC 4659 [RFC4659] | TBD | 772 | S.3.3.2 | define method for | | 773 | | 4PE/4VPE | | 774 +---------+--------------------------+------------------------------+ 775 | OAM | RFC 4379 [RFC4379] no | IPv6 RAO for MPLS OAM | 776 | S.3.4 | IPv6 multipath support, | [I-D.raza-mpls-oam-ipv6-rao] | 777 | | no IPv6 RAO, possible | | 778 | | dropped messages in IP | | 779 | | version mismatch | | 780 +---------+--------------------------+------------------------------+ 781 | MIBs | RFC 3811 [RFC3811] no | 3811bis | 782 | S.3.5 | IPv6 textual convention | [I-D.manral-mpls-rfc3811bis] | 783 +---------+--------------------------+------------------------------+ 785 Table 1: IPv6-only MPLS Gaps 787 5. Acknowledgements 789 The authors wish to thank Alvaro Retana, Andrew Yourtchenko, Loa 790 Andersson, David Allan, Mach Chen, Mustapha Aissaoui, and Mark Tinka 791 for their detailed reviews, as well as Brian Haberman, Joel Jaeggli, 792 Adrian Farrell, and Nobo Akiya for their comments. 794 6. Contributing Authors 796 The following people have contributed text to this draft: 798 Rajiv Asati 799 Cisco Systems 800 7025 Kit Creek Road 801 Research Triangle Park, NC 27709 802 US 804 Email: rajiva@cisco.com 806 Kamran Raza 807 Cisco Systems 808 2000 Innovation Drive 809 Ottawa, ON K2K-3E8 810 CA 812 Email: skraza@cisco.com 814 Ronald Bonica 815 Juniper Networks 816 2251 Corporate Park Drive 817 Herndon, VA 20171 818 US 820 Email: rbonica@juniper.net 822 Rajiv Papneja 823 Huawei Technologies 824 2330 Central Expressway 825 Santa Clara, CA 95050 826 US 828 Email: rajiv.papneja@huawei.com 830 Dhruv Dhody 831 Huawei Technologies 832 Leela Palace 833 Bangalore, Karnataka 560008 834 IN 836 Email: dhruv.ietf@gmail.com 837 Vishwas Manral 838 Ionos Networks 839 Sunnyvale, CA 94089 840 US 842 Email: vishwas@ionosnetworks.com 844 Nagendra Kumar 845 Cisco Systems, Inc. 846 7200 Kit Creek Road 847 Research Triangle Park, NC 27709 848 US 850 Email: naikumar@cisco.com 852 7. IANA Considerations 854 This memo includes no request to IANA. 856 8. Security Considerations 858 Changing the address family used for MPLS network operation does not 859 fundamentally alter the security considerations currently extant in 860 any of the specifics of the protocol or its features, however, 861 follow-on work recommended by this gap analysis will need to address 862 any effects of the use of IPv6 in their modifications may have on 863 security. 865 9. Informative References 867 [I-D.ietf-l2vpn-evpn] 868 Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. 869 Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn- 870 evpn-07 (work in progress), May 2014. 872 [I-D.ietf-l3vpn-mvpn-mldp-nlri] 873 Wijnands, I., Rosen, E., and U. Joorde, "Encoding mLDP 874 FECs in the NLRI of BGP MCAST-VPN Routes", draft-ietf- 875 l3vpn-mvpn-mldp-nlri-05 (work in progress), May 2014. 877 [I-D.ietf-l3vpn-mvpn-pe-ce] 878 Patel, K., Rekhter, Y., and E. Rosen, "BGP as an MVPN PE- 879 CE Protocol", draft-ietf-l3vpn-mvpn-pe-ce-01 (work in 880 progress), March 2014. 882 [I-D.ietf-mpls-ldp-ipv6] 883 Asati, R., Manral, V., Papneja, R., and C. Pignataro, 884 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-13 885 (work in progress), July 2014. 887 [I-D.itojun-v6ops-v4mapped-harmful] 888 Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire 889 Considered Harmful", draft-itojun-v6ops-v4mapped- 890 harmful-02 (work in progress), October 2003. 892 [I-D.manral-mpls-rfc3811bis] 893 Manral, V., Tsou, T., Will, W., and F. Fondelli, 894 "Definitions of Textual Conventions (TCs) for 895 Multiprotocol Label Switching (MPLS) Management", draft- 896 manral-mpls-rfc3811bis-03 (work in progress), June 2013. 898 [I-D.raza-mpls-oam-ipv6-rao] 899 Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert 900 Option for MPLS OAM", draft-raza-mpls-oam-ipv6-rao-00 901 (work in progress), July 2014. 903 [I-D.smith-v6ops-larger-ipv6-loopback-prefix] 904 Smith, M., "A Larger Loopback Prefix for IPv6", draft- 905 smith-v6ops-larger-ipv6-loopback-prefix-04 (work in 906 progress), February 2013. 908 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 909 E. Lear, "Address Allocation for Private Internets", BCP 910 5, RFC 1918, February 1996. 912 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 913 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 914 Encoding", RFC 3032, January 2001. 916 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 917 BGP-4", RFC 3107, May 2001. 919 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 920 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 921 Tunnels", RFC 3209, December 2001. 923 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 924 (TE) Extensions to OSPF Version 2", RFC 3630, September 925 2003. 927 [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual 928 Conventions (TCs) for Multiprotocol Label Switching (MPLS) 929 Management", RFC 3811, June 2004. 931 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 932 "Multiprotocol Label Switching (MPLS) Traffic Engineering 933 (TE) Management Information Base (MIB)", RFC 3812, June 934 2004. 936 [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, 937 "Multiprotocol Label Switching (MPLS) Label Switching 938 Router (LSR) Management Information Base (MIB)", RFC 3813, 939 June 2004. 941 [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions 942 of Managed Objects for the Multiprotocol Label Switching 943 (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 944 2004. 946 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 947 MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 948 4023, March 2005. 950 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 951 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 952 2005. 954 [RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering 955 Link Management Information Base", RFC 4220, November 956 2005. 958 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 959 Networks (VPNs)", RFC 4364, February 2006. 961 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 962 Label Switched (MPLS) Data Plane Failures", RFC 4379, 963 February 2006. 965 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 966 Heron, "Pseudowire Setup and Maintenance Using the Label 967 Distribution Protocol (LDP)", RFC 4447, April 2006. 969 [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, 970 "Node-ID Based Resource Reservation Protocol (RSVP) Hello: 971 A Clarification Statement", RFC 4558, June 2006. 973 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 974 Element (PCE)-Based Architecture", RFC 4655, August 2006. 976 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 977 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 978 IPv6 VPN", RFC 4659, September 2006. 980 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 981 Private Networks (L2VPNs)", RFC 4664, September 2006. 983 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 984 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 985 4761, January 2007. 987 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 988 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 989 RFC 4762, January 2007. 991 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 992 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 993 Provider Edge Routers (6PE)", RFC 4798, February 2007. 995 [RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label 996 Switching (GMPLS) Traffic Engineering Management 997 Information Base", RFC 4802, February 2007. 999 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and 1000 J. Young, "Encapsulation of MPLS over Layer 2 Tunneling 1001 Protocol Version 3", RFC 4817, March 2007. 1003 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1004 "Extensions to Resource Reservation Protocol - Traffic 1005 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1006 Switched Paths (LSPs)", RFC 4875, May 2007. 1008 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 1009 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 1010 April 2007. 1012 [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP 1013 Extensions for Multiprotocol Label Switching", RFC 4950, 1014 August 2007. 1016 [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of 1017 Addresses in Generalized Multiprotocol Label Switching 1018 (GMPLS) Networks", RFC 4990, September 2007. 1020 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1021 Specification", RFC 5036, October 2007. 1023 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 1024 Pignataro, "The Generalized TTL Security Mechanism 1025 (GTSM)", RFC 5082, October 2007. 1027 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 1028 Connectivity Verification (VCCV): A Control Channel for 1029 Pseudowires", RFC 5085, December 2007. 1031 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1032 "OSPF Protocol Extensions for Path Computation Element 1033 (PCE) Discovery", RFC 5088, January 2008. 1035 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1036 "IS-IS Protocol Extensions for Path Computation Element 1037 (PCE) Discovery", RFC 5089, January 2008. 1039 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 1040 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 1042 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1043 Engineering", RFC 5305, October 2008. 1045 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, 1046 "Traffic Engineering Extensions to OSPF Version 3", RFC 1047 5329, September 2008. 1049 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1050 (PCE) Communication Protocol (PCEP)", RFC 5440, March 1051 2009. 1053 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 1054 Subsequent Address Family Identifier (SAFI) and the BGP 1055 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 1057 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 1058 Topology Confidentiality in Inter-Domain Path Computation 1059 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 1061 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1062 Path Computation Element Communication Protocol (PCEP) for 1063 Route Exclusions", RFC 5521, April 2009. 1065 [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- 1066 Balancing for Mesh Softwires", RFC 5640, August 2009. 1068 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 1069 Rivers, "Extending ICMP for Interface and Next-Hop 1070 Identification", RFC 5837, April 2010. 1072 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 1073 "Bidirectional Forwarding Detection (BFD) for MPLS Label 1074 Switched Paths (LSPs)", RFC 5884, June 2010. 1076 [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 1077 Detection (BFD) for the Pseudowire Virtual Circuit 1078 Connectivity Verification (VCCV)", RFC 5885, June 2010. 1080 [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of 1081 Monitoring Tools for Path Computation Element (PCE)-Based 1082 Architecture", RFC 5886, June 2010. 1084 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 1085 Berger, "A Framework for MPLS in Transport Networks", RFC 1086 5921, July 2010. 1088 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., 1089 and J. Meuric, "Extensions to the Path Computation Element 1090 Communication Protocol (PCEP) for Point-to-Multipoint 1091 Traffic Engineering Label Switched Paths", RFC 6006, 1092 September 2010. 1094 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 1095 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 1097 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 1098 "Provisioning, Auto-Discovery, and Signaling in Layer 2 1099 Virtual Private Networks (L2VPNs)", RFC 6074, January 1100 2011. 1102 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1103 Engineering in IS-IS", RFC 6119, February 2011. 1105 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 1106 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 1108 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 1109 Maintenance Framework for MPLS-Based Transport Networks", 1110 RFC 6371, September 2011. 1112 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 1113 "Label Distribution Protocol Extensions for Point-to- 1114 Multipoint and Multipoint-to-Multipoint Label Switched 1115 Paths", RFC 6388, November 2011. 1117 [RFC6445] Nadeau, T., Koushik, A., and R. Cetin, "Multiprotocol 1118 Label Switching (MPLS) Traffic Engineering Management 1119 Information Base for Fast Reroute", RFC 6445, November 1120 2011. 1122 [RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, 1123 "Using Multipoint LDP When the Backbone Has No Route to 1124 the Root", RFC 6512, February 2012. 1126 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 1127 VPNs", RFC 6513, February 2012. 1129 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1130 Encodings and Procedures for Multicast in MPLS/BGP IP 1131 VPNs", RFC 6514, February 2012. 1133 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 1134 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 1135 RFC 6540, April 2012. 1137 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 1138 Virtual Private Networks Using BGP for Auto-Discovery and 1139 Signaling", RFC 6624, May 2012. 1141 [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security 1142 Mechanism (GTSM) for the Label Distribution Protocol 1143 (LDP)", RFC 6720, August 2012. 1145 [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label 1146 Switched Path (LSP) Ping for Pseudowire Forwarding 1147 Equivalence Classes (FECs) Advertised over IPv6", RFC 1148 6829, January 2013. 1150 [RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C. 1151 Kodeboniya, "Multicast in Virtual Private LAN Service 1152 (VPLS)", RFC 7117, February 2014. 1154 Authors' Addresses 1156 Wesley George (editor) 1157 Time Warner Cable 1158 13820 Sunrise Valley Drive 1159 Herndon, VA 20111 1160 US 1162 Phone: +1-703-561-2540 1163 Email: wesley.george@twcable.com 1164 Carlos Pignataro (editor) 1165 Cisco Systems, Inc. 1166 7200-12 Kit Creek Road 1167 Research Triangle Park, NC 27709 1168 US 1170 Phone: +1-919-392-7428 1171 Email: cpignata@cisco.com