idnits 2.17.1 draft-ietf-mpls-ipv6-only-gap-04.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 (November 25, 2014) is 3411 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-mvpn-mldp-nlri-07 == Outdated reference: A later version (-17) exists of draft-ietf-mpls-ldp-ipv6-13 -- 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: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 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: May 29, 2015 Cisco 6 November 25, 2014 8 Gap Analysis for Operating IPv6-only MPLS Networks 9 draft-ietf-mpls-ipv6-only-gap-04 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 intended to focus on gaps in the standards defining the MPLS suite, 18 and not to highlight particular vendor implementations (or lack 19 thereof) in the context of IPv6-only MPLS functionality. 21 In the data plane, MPLS fully supports IPv6 and MPLS labeled packets 22 can be carried over IPv6 packets in a variety of encapsulations. 23 However, support for IPv6 among MPLS control plane protocols, MPLS 24 applications, MPLS Operations, Administration, and Maintenance (OAM), 25 and MIB modules is mixed, with some protocols having major gaps. For 26 most major gaps work is in progress to upgrade the relevant 27 protocols. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 29, 2015. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. MPLS Control Plane . . . . . . . . . . . . . . . . . . . 5 68 3.2.1. Label Distribution Protocol (LDP) . . . . . . . . . . 5 69 3.2.2. Multipoint LDP (mLDP) . . . . . . . . . . . . . . . . 6 70 3.2.3. RSVP - Traffic Engineering (RSVP-TE) . . . . . . . . 7 71 3.2.3.1. Interior Gateway Protocol (IGP) . . . . . . . . . 7 72 3.2.3.2. RSVP-TE - Point-to-Multipoint (P2MP) . . . . . . 7 73 3.2.3.3. RSVP-TE Fast Reroute (FRR) . . . . . . . . . . . 7 74 3.2.4. Path Computation Element (PCE) . . . . . . . . . . . 8 75 3.2.5. Border Gateway Protocol (BGP) . . . . . . . . . . . . 8 76 3.2.6. Generalized Multi-Protocol Label Switching (GMPLS) . 8 77 3.3. MPLS Applications . . . . . . . . . . . . . . . . . . . . 9 78 3.3.1. Layer 2 Virtual Private Network (L2VPN) . . . . . . . 9 79 3.3.1.1. Ethernet VPN (EVPN) . . . . . . . . . . . . . . . 10 80 3.3.2. Layer 3 Virtual Private Network (L3VPN) . . . . . . . 10 81 3.3.2.1. IPv6 Provider Edge/IPv4 Provider Edge (6PE/4PE) . 10 82 3.3.2.2. IPv6 Virtual Private Extension/IPv4 Virtual 83 Private Extension (6VPE/4VPE) . . . . . . . . . . 11 84 3.3.2.3. BGP Encapsulation Subsequent Address Family 85 Identifier (SAFI) . . . . . . . . . . . . . . . . 11 86 3.3.2.4. Multicast in MPLS/BGP IP VPN (MVPN) . . . . . . . 11 87 3.3.3. MPLS Transport Profile (MPLS-TP) . . . . . . . . . . 13 88 3.4. MPLS Operations, Administration, and Maintenance (MPLS 89 OAM) . . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 3.4.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 13 91 3.4.2. Label Switched Path Ping (LSP Ping) . . . . . . . . . 14 92 3.4.3. Bidirectional Forwarding Detection (BFD) . . . . . . 16 93 3.4.4. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 16 94 3.4.5. MPLS Transport Profile (MPLS-TP) OAM . . . . . . . . 16 95 3.5. MIB Modules . . . . . . . . . . . . . . . . . . . . . . . 16 96 4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 98 6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 19 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 102 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 103 9.2. Informative References . . . . . . . . . . . . . . . . . 21 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 106 1. Introduction 108 IPv6 [RFC2460] is an integral part of modern network deployments. At 109 the time when this document was written, the majority of these IPv6 110 deployments were using dual-stack implementations, where IPv4 and 111 IPv6 are supported equally on many or all of the network nodes, and 112 single-stack primarily referred to IPv4-only devices. Dual-stack 113 deployments provide a useful margin for protocols and features that 114 are not currently capable of operating solely over IPv6, because they 115 can continue using IPv4 as necessary. However, as IPv6 deployment 116 and usage becomes more pervasive, and IPv4 exhaustion begins driving 117 changes in address consumption behaviors, there is an increasing 118 likelihood that many networks will need to start operating some or 119 all of their network nodes either as primarily IPv6 (most functions 120 use IPv6, a few legacy features use IPv4), or as IPv6-only (no IPv4 121 provisioned on the device). This transition toward IPv6-only 122 operation exposes any gaps where features, protocols, or 123 implementations are still reliant on IPv4 for proper function. To 124 that end, and in the spirit of the recommendation in RFC 6540 125 [RFC6540] that implementations need to stop requiring IPv4 for proper 126 and complete function, this document reviews the Multi-Protocol Label 127 Switching (MPLS) protocol suite in the context of IPv6 and identifies 128 gaps that must be addressed in order to allow MPLS-related protocols 129 and applications to be used with IPv6-only networks and networks that 130 are primarily IPv6 (hereafter referred to as IPv6-primary). This 131 document is intended to focus on gaps in the standards defining the 132 MPLS suite, and not to highlight particular vendor implementations 133 (or lack thereof) in the context of IPv6-only MPLS functionality. 135 2. Use Case 137 This section discusses some drivers for ensuring that MPLS completely 138 supports IPv6-only operation. It is not intended to be a 139 comprehensive discussion of all potential use cases, but rather a 140 discussion of one use case to provide context and justification to 141 undertake such a gap analysis. 143 IP convergence is continuing to drive new classes of devices to begin 144 communicating via IP. Examples of such devices could include set top 145 boxes for IP Video distribution, cell tower electronics (macro or 146 micro cells), infrastructure Wi-Fi Access Points, and devices for 147 machine to machine (M2M) or Internet of Things applications. In some 148 cases, these classes of devices represent a very large deployment 149 base, on the order of thousands or even millions of devices network- 150 wide. The scale of these networks, coupled with the increasingly 151 overlapping use of RFC 1918 [RFC1918] address space within the 152 average network, and the lack of globally-routable IPv4 space 153 available for long-term growth begins to drive the need for many of 154 the endpoints in this network to be managed solely via IPv6. Even if 155 these devices are carrying some IPv4 user data, it is often 156 encapsulated in another protocol such that the communication between 157 the endpoint and its upstream devices can be IPv6-only without 158 impacting support for IPv4 on user data. As the number of devices to 159 manage increases, the operator is compelled to move to IPv6. 160 Depending on the MPLS features required, it is plausible to assume 161 that the (existing) MPLS network will need to be extended to these 162 IPv6-only devices. 164 Additionally, as the impact of IPv4 exhaustion becomes more acute, 165 more and more aggressive IPv4 address reclamation measures will be 166 justified. Many networks are likely to focus on preserving their 167 remaining IPv4 addresses for revenue-generating customers so that 168 legacy support for IPv4 can be maintained as long as necessary. As a 169 result, it may be appropriate for some or all of the network 170 infrastructure, including MPLS Label Switch Routers (LSRs) and Label 171 Edge Routers (LERs), to have its IPv4 addresses reclaimed and 172 transition toward IPv6-only operation. 174 3. Gap Analysis 176 This gap analysis aims to answer the question, "what fails when one 177 attempts to use MPLS features on a network of IPv6-only devices?" 178 The baseline assumption for this analysis is that some endpoints as 179 well as Label Switch Routers (Provider Edge (PE) and Provider (P) 180 routers) only have IPv6 transport available, and need to support the 181 full suite of MPLS features defined as of the time of this document's 182 writing at parity with the support on an IPv4 network. This is 183 necessary whether they are enabled via Label Distribution Protocol 184 (LDP) RFC 5036 [RFC5036], Resource Reservation Protocol Extensions 185 for MPLS Traffic Engineering (RSVP-TE) RFC 3209 [RFC3209], or Border 186 Gateway Protocol (BGP) RFC 3107 [RFC3107], and whether they are 187 encapsulated in MPLS RFC 3032 [RFC3032], IP RFC 4023 [RFC4023], 188 Generic Routing Encapsulation (GRE) RFC 4023 [RFC4023], or Layer 2 189 Tunneling Protocol Version 3 (L2TPv3) RFC 4817 [RFC4817]. It is 190 important when evaluating these gaps to distinguish between user data 191 and control plane data, because while this document is focused on 192 IPv6-only operation, it is quite likely that some amount of the user 193 payload data being carried in the IPv6-only MPLS network will still 194 be IPv4. 196 A note about terminology: Gaps identified by this document are 197 characterized as "Major" or "Minor". Major gaps refer to significant 198 changes necessary in one or more standards to address the gap due to 199 existing standards language having either missing functionality for 200 IPv6-only operation or explicit language requiring the use of IPv4 201 with no IPv6 alternatives defined. Minor gaps refer to changes 202 necessary primarily to clarify existing standards language. Usually 203 these changes are needed in order to explicitly codify IPv6 support 204 in places where it is either implicit or omitted today, but the 205 omission is unlikely to prevent IPv6-only operation. 207 3.1. MPLS Data Plane 209 MPLS labeled packets can be transmitted over a variety of data links 210 RFC 3032 [RFC3032], and MPLS labeled packets can also be encapsulated 211 over IP. The encapsulations of MPLS in IP and GRE as well as MPLS 212 over L2TPv3 support IPv6. See Section 3 of RFC 4023 [RFC4023] and 213 Section 2 of RFC 4817 [RFC4817] respectively. 215 Gap: None. 217 3.2. MPLS Control Plane 219 3.2.1. Label Distribution Protocol (LDP) 221 Label Distribution Protocol (LDP) RFC 5036 [RFC5036] defines a set of 222 procedures for distribution of labels between label switch routers 223 that can use the labels for forwarding traffic. While LDP was 224 designed to use an IPv4 or dual-stack IP network, it has a number of 225 deficiencies that prevent it from working in an IPv6-only network. 226 LDP-IPv6 [I-D.ietf-mpls-ldp-ipv6] highlights some of the deficiencies 227 when LDP is enabled in IPv6 only or dual-stack networks, and 228 specifies appropriate protocol changes. These deficiencies are 229 related to LSP mapping, LDP identifiers, LDP discovery, LDP session 230 establishment, next hop address and LDP Time To Live (TTL) security 231 RFC 5082 [RFC5082] and RFC 6720 [RFC6720]. 233 Gap: Major, update to RFC 5036 in progress via LDP-IPv6 234 [I-D.ietf-mpls-ldp-ipv6] that should close this gap. 236 3.2.2. Multipoint LDP (mLDP) 238 Multipoint LDP (mLDP) is a set of extensions to LDP for setting up 239 Point to Multipoint (P2MP) and Multipoint to Multipoint (MP2MP) LSPs. 240 These extensions are specified in RFC 6388 [RFC6388]. In terms of 241 IPv6-only gap analysis, mLDP has two identified areas of interest: 243 1. LDP Control plane: Since mLDP uses the LDP control plane to 244 discover and establish sessions with the peer, it shares the same 245 gaps as LDP (Section 3.2.1) with regards to control plane 246 (discovery, transport, and session establishment) in an IPv6-only 247 network. 249 2. Multipoint (MP) FEC Root address: mLDP defines its own MP 250 Forwarding Equivalence Classes (FECs) and rules, different from 251 LDP, to map MP LSPs. mLDP MP FEC contains a Root Address field 252 which is an IP address in IP networks. The current specification 253 allows specifying Root address according to Address Family 254 Identifier (AFI) and hence covers both IPv4 or IPv6 root 255 addresses, requiring no extension to support IPv6-only MP LSPs. 256 The root address is used by each LSR participating in an MP LSP 257 setup such that root address reachability is resolved by doing a 258 table lookup against the root address to find corresponding 259 upstream neighbor(s). This will pose a problem if an MP LSP 260 traverses IPv4-only and IPv6-only nodes in a dual-stack network 261 on the way to the root node. 263 For example, consider following setup, where R1/R6 are IPv4-only, R3/ 264 R4 are IPv6-only, and R2/R5 are dual-stack LSRs: 266 ( IPv4-only ) ( IPv6-only ) ( IPv4-only ) 267 R1 -- R2 -- R3 -- R4 -- R5 -- R6 268 Leaf Root 270 Assume R1 to be a leaf node for an P2MP LSP rooted at R6 (root node). 271 R1 uses R6's IPv4 address as the Root address in MP FEC. As the MP 272 LSP signaling proceeds from R1 to R6, the MP LSP setup will fail on 273 the first IPv6-only transit/branch LSRs (R3) when trying to find IPv4 274 root address reachability. RFC 6512 [RFC6512] defines a recursive- 275 FEC solution and procedures for mLDP when the backbone (transit/ 276 branch) LSRs have no route to the root. The proposed solution is 277 defined for a BGP-free core in an VPN environment, but a similar 278 concept can be used/extended to solve the above issue of IPv6-only 279 backbone receiving an MP FEC element with an IPv4 address. The 280 solution will require a border LSR (the one which is sitting on 281 border of an IPv4/IPv6 island(s) (R2 and R5) to translate an IPv4 282 root address to equivalent IPv6 address (and vice vera) through 283 procedures similar to RFC 6512. 285 Gap: Major, update in progress for LDP via LDP-IPv6 286 [I-D.ietf-mpls-ldp-ipv6], may need additional updates to RFC 6512. 288 3.2.3. RSVP - Traffic Engineering (RSVP-TE) 290 Resource Reservation Protocol Extensions for MPLS Traffic Engineering 291 (RSVP-TE) RFC 3209 [RFC3209] defines a set of procedures and 292 enhancements to establish label-switched tunnels that can be 293 automatically routed away from network failures, congestion, and 294 bottlenecks. RSVP-TE allows establishing an LSP for an IPv4 or IPv6 295 prefix, thanks to its LSP_TUNNEL_IPv6 object and subobjects. 297 Gap: None 299 3.2.3.1. Interior Gateway Protocol (IGP) 301 RFC 3630 [RFC3630] specifies a method of adding traffic engineering 302 capabilities to OSPF Version 2. New TLVs and sub-TLVs were added in 303 RFC 5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF 304 Version 3. 306 RFC 5305 [RFC5305] specifies a method of adding traffic engineering 307 capabilities to IS-IS. New TLVs and sub-TLVs were added in RFC 6119 308 [RFC6119] to extend TE capabilities to IPv6 networks. 310 Gap: None 312 3.2.3.2. RSVP-TE - Point-to-Multipoint (P2MP) 314 RFC 4875 [RFC4875] describes extensions to RSVP-TE for the setup of 315 point-to-multipoint (P2MP) LSPs in MPLS and Generalized MPLS (GMPLS) 316 with support for both IPv4 and IPv6. 318 Gap: None 320 3.2.3.3. RSVP-TE Fast Reroute (FRR) 322 RFC 4090 [RFC4090] specifies FRR mechanisms to establish backup LSP 323 tunnels for local repair supporting both IPv4 and IPv6 networks. 324 Further RFC 5286 [RFC5286] describes the use of loop-free alternates 325 to provide local protection for unicast traffic in pure IP and MPLS 326 networks in the event of a single failure, whether link, node, or 327 shared risk link group (SRLG) for both IPv4 and IPv6. 329 Gap: None 331 3.2.4. Path Computation Element (PCE) 333 The Path Computation Element (PCE) defined in RFC 4655 [RFC4655] is 334 an entity that is capable of computing a network path or route based 335 on a network graph, and applying computational constraints. A Path 336 Computation Client (PCC) may make requests to a PCE for paths to be 337 computed. The PCE Communication Protocol (PCEP) is designed as a 338 communication protocol between PCCs and PCEs for path computations 339 and is defined in RFC 5440 [RFC5440]. 341 The PCEP specification RFC 5440 [RFC5440] is defined for both IPv4 342 and IPv6 with support for PCE discovery via an IGP (OSPF RFC 5088 343 [RFC5088], or ISIS RFC 5089 [RFC5089]) using both IPv4 and IPv6 344 addresses. Note that PCEP uses identical encoding of subobjects as 345 in the Resource Reservation Protocol Traffic Engineering Extensions 346 (RSVP-TE) defined in RFC 3209 [RFC3209] which supports both IPv4 and 347 IPv6. 349 The extensions of PCEP to support confidentiality RFC 5520 [RFC5520], 350 Route Exclusion RFC 5521, [RFC5521] Monitoring RFC 5886 [RFC5886], 351 and P2MP RFC 6006 [RFC6006] have support for both IPv4 and IPv6. 353 Gap: None. 355 3.2.5. Border Gateway Protocol (BGP) 357 RFC 3107 [RFC3107] specifies a set of BGP protocol procedures for 358 distributing the labels (for prefixes corresponding to any address- 359 family) between label switch routers so that they can use the labels 360 for forwarding the traffic. RFC 3107 allows BGP to distribute the 361 label for IPv4 or IPv6 prefix in an IPv6 only network. 363 Gap: None. 365 3.2.6. Generalized Multi-Protocol Label Switching (GMPLS) 367 The Generalized Multi-Protocol Label Switching (GMPLS) specification 368 includes signaling functional extensions RFC 3471 [RFC3471] and RSVP- 369 TE extensions RFC 3473 [RFC3473]. The gap analysis on Section 3.2.3 370 applies to these. 372 RFC 4558 [RFC4558] specifies Node-ID Based RSVP Hello Messages with 373 capability for both IPv4 and IPv6. RFC 4990 [RFC4990] clarifies the 374 use of IPv6 addresses in GMPLS networks including handling in the MIB 375 modules. 377 Section 5.3, second paragraph of RFC 6370 [RFC6370] describes the 378 mapping from an MPLS Transport Profile (MPLS-TP) LSP_ID to RSVP-TE 379 with an assumption that Node_IDs are derived from valid IPv4 380 addresses. This assumption fails in an IPv6-only network, given that 381 there would not be any IPv4 addresses. 383 Gap: Minor; Section 5.3. of RFC 6370 needs to be updated. 385 3.3. MPLS Applications 387 3.3.1. Layer 2 Virtual Private Network (L2VPN) 389 L2VPN RFC 4664 [RFC4664] specifies two fundamentally different kinds 390 of Layer 2 VPN services that a service provider could offer to a 391 customer: Virtual Private Wire Service (VPWS) and Virtual Private LAN 392 Service (VPLS). RFC 4447 [RFC4447] and RFC 4762 [RFC4762] specify 393 the LDP protocol changes to instantiate VPWS and VPLS services 394 respectively in an MPLS network using LDP as the signaling protocol. 395 This is complemented by RFC 6074 [RFC6074], which specifies a set of 396 procedures for instantiating L2VPNs (e.g., VPWS, VPLS) using BGP as 397 discovery protocol and LDP as well as L2TPv3 as signaling protocol. 398 RFC 4761 [RFC4761] and RFC 6624 [RFC6624] specify BGP protocol 399 changes to instantiate VPLS and VPWS services in an MPLS network, 400 using BGP for both discovery and signaling. 402 In an IPv6-only MPLS network, use of L2VPN represents connection of 403 Layer 2 islands over an IPv6 MPLS core, and very few changes are 404 necessary to support operation over an IPv6-only network. The L2VPN 405 signaling protocol is either BGP or LDP in an MPLS network, and both 406 can run directly over IPv6 core infrastructure, as well as IPv6 edge 407 devices. RFC 6074 [RFC6074] is the only RFC that appears to have a 408 gap for IPv6-only operation. In its discovery procedures (section 409 3.2.2 and section 6), it suggests encoding PE IP address in the VSI- 410 ID, which is encoded in Network Layer Reachability Information 411 (NLRI), and should not exceed 12 bytes (to differentiate its AFI/SAFI 412 (Subsequent Address Family Identifier) encoding from RFC 4761). This 413 means that PE IP address can NOT be an IPv6 address. Also, in its 414 signaling procedures (section 3.2.3), it suggests encoding PE_addr in 415 Source Attachment Individual Identifier (SAII) and Target Attachment 416 Individual Identifier (TAII), which are limited to 32-bit (AII 417 Type=1) at the moment. 419 RFC 6073 [RFC6073] defines the new LDP Pseudowire (PW) Switching 420 Point PE TLV, which supports IPv4 and IPv6. 422 Gap: Minor. RFC 6074 needs to be updated. 424 3.3.1.1. Ethernet VPN (EVPN) 426 Ethernet VPN (EVPN) [I-D.ietf-l2vpn-evpn] defines a method for using 427 BGP MPLS-based Ethernet VPNs. Because it can use functions in LDP 428 and mLDP, as well as RFC 7117 [RFC7117] Multicast VPLS, it inherits 429 gaps previously identified in LDP (Section 3.2.1). Once those gaps 430 are resolved, it should function properly on IPv6-only networks as 431 defined. 433 Gap: Major for LDP, update to RFC 5036 in progress via LDP-IPv6 434 [I-D.ietf-mpls-ldp-ipv6] that should close this gap (see 435 Section 3.2.1). 437 3.3.2. Layer 3 Virtual Private Network (L3VPN) 439 RFC 4364 [RFC4364] defines a method by which a Service Provider may 440 use an IP backbone to provide IP Virtual Private Networks (VPNs) for 441 its customers. The following use cases arise in the context of this 442 gap analysis: 444 1. Connecting IPv6 islands over IPv6-only MPLS network 446 2. Connecting IPv4 islands over IPv6-only MPLS network 448 Both use cases require mapping an IP packet to an IPv6-signaled LSP. 449 RFC 4364 defines Layer 3 Virtual Private Networks (L3VPNs) for IPv4 450 only and has references to 32-bit BGP next hop addresses. RFC 4659 451 [RFC4659] adds support for IPv6 on L3VPNs including 128-bit BGP next 452 hop addresses, and discusses operation whether IPv6 is the payload or 453 the underlying transport address family. However, RFC 4659 does not 454 formally update RFC 4364, and thus an implementer may miss this 455 additional set of standards unless it is explicitly identified 456 independently of the base functionality defined in RFC 4364. 457 Further, section 1 of RFC 4659 explicitly identifies use case number 458 2 as out of scope for the document. 460 The authors do not believe that there are any additional issues 461 encountered when using L2TPv3, RSVP, or GRE (instead of MPLS) as 462 transport on an IPv6-only network. 464 Gap: Major. RFC 4659 needs to be updated to explicitly cover use 465 case number 2. (Discussed in further detail below) 467 3.3.2.1. IPv6 Provider Edge/IPv4 Provider Edge (6PE/4PE) 469 RFC 4798 [RFC4798] defines IPv6 Provider Edge (6PE), which defines 470 how to interconnect IPv6 islands over a MPLS-enabled IPv4 cloud. 471 However, use case 2 is doing the opposite, and thus could also be 472 referred to as IPv4 Provider Edge (4PE). The method to support this 473 use case is not defined explicitly. To support it, IPv4 edge devices 474 need to be able to map IPv4 traffic to MPLS IPv6 core LSP's. Also, 475 the core switches may not understand IPv4 at all, but in some cases 476 they may need to be able to exchange Labeled IPv4 routes from one AS 477 to a neighboring AS. 479 Gap: Major. RFC 4798 covers only the "6PE" case. Use case number 2 480 is currently not specified in an RFC. 482 3.3.2.2. IPv6 Virtual Private Extension/IPv4 Virtual Private Extension 483 (6VPE/4VPE) 485 RFC 4659 [RFC4659] defines IPv6 Virtual Private Network Extension 486 (6VPE), a method by which a Service Provider may use its packet- 487 switched backbone to provide Virtual Private Network (VPN) services 488 for its IPv6 customers. It allows the core network to be MPLS IPv4 489 or MPLS IPv6, thus addressing use case 1 above. RFC 4364 should work 490 as defined for use case 2 above, which could also be referred to as 491 IPv4 Virtual Private Extension (4VPE), but the RFC explicitly does 492 not discuss this use and defines it as out of scope. 494 Gap: Minor. RFC 4659 needs to be updated to explicitly cover use 495 case number 2 497 3.3.2.3. BGP Encapsulation Subsequent Address Family Identifier (SAFI) 499 RFC 5512 [RFC5512] defines the BGP Encapsulation SAFI and the BGP 500 Tunnel Encapsulation Attribute, which can be used to signal tunneling 501 over a single-Address Family IP core. This mechanism supports 502 transport of MPLS (and other protocols) over Tunnels in an IP core 503 (including an IPv6-only core). In this context, load-balancing can 504 be provided as specified in RFC 5640 [RFC5640]. 506 Gap: None. 508 3.3.2.4. Multicast in MPLS/BGP IP VPN (MVPN) 510 RFC 6513 [RFC6513] defines the procedure to provide multicast service 511 over an MPLS VPN backbone for downstream customers. It is sometimes 512 referred to as Next Generation Multicast VPN (NG-MVPN) The procedure 513 involves the below set of protocols: 515 3.3.2.4.1. PE-CE Multicast Routing Protocol 517 RFC 6513 [RFC6513] explains the use of Protocol Independent Multicast 518 (PIM) as Provider Edge-Customer Edge (PE-CE) protocol while 519 Section 11.1.2 of RFC 6514 [RFC6514] explains the use of mLDP as PE- 520 CE protocol. 522 The MCAST-VPN NLRI route-type format defined in RFC 6514 [RFC6514] is 523 not sufficiently covering all scenarios when mLDP is used as PE-CE 524 protocol. The issue is explained in section 2 of 525 [I-D.ietf-l3vpn-mvpn-mldp-nlri] along with new route-type that 526 encodes the mLDP FEC in NLRI. 528 Further [I-D.ietf-l3vpn-mvpn-pe-ce] defines the use of BGP as PE-CE 529 protocol. 531 Gap: None. 533 3.3.2.4.2. P-Tunnel Instantiation 535 RFC 6513 [RFC6513] explains the use of the below tunnels: 537 o RSVP-TE P2MP LSP 539 o PIM Tree 541 o mLDP P2MP LSP 543 o mLDP MP2MP LSP 545 o Ingress Replication 547 Gap: Gaps in RSVP-TE P2MP LSP (Section 3.2.3.2) and mLDP 548 (Section 3.2.2) P2MP and MP2MP LSP are covered in previous sections. 549 There are no MPLS-specific gaps for PIM Tree or Ingress Replication 550 and any protocol-specific gaps not related to MPLS are outside the 551 scope of this document. 553 3.3.2.4.3. PE-PE Multicast Routing Protocol 555 Section 3.1 of RFC 6513 [RFC6513] explains the use of PIM as PE-PE 556 protocol while RFC 6514 [RFC6514] explains the use of BGP as PE-PE 557 protocol. 559 PE-PE multicast routing is not specific to P-tunnel or to MPLS. It 560 can be PIM or BGP with label based or PIM tree based P-Tunnels. 561 Enabling PIM as a PE-PE multicast protocol is equivalent to running 562 it on a non-MPLS IPv6 network, so there are not any MPLS-specific 563 considerations, and any gaps are applicable for non-MPLS networks as 564 well. Similarly, BGP only includes the PMSI tunnel attribute as a 565 part of the NLRI which is inherited from P-tunnel instantiation and 566 considered to be an opaque value. So any gaps in the Control plane 567 (PIM or BGP) will not be specific to MPLS. 569 Gap: Any gaps in PIM or BGP as PE-PE Multicast Routing protocol are 570 not unique to MPLS, and therefore are outside the scope of this 571 document. It is included for completeness. 573 3.3.3. MPLS Transport Profile (MPLS-TP) 575 MPLS-TP does not require IP (see section 2 of RFC 5921 [RFC5921]) and 576 should not be affected by operation on an IPv6-only network. 577 Therefore this is considered out of scope for this document, but is 578 included for completeness. 580 Although not required, MPLS-TP can use IP. One such example is 581 included in Section 3.2.6, where MPLS-TP identifiers can be derived 582 from valid IPv4 addresses. 584 Gap: None. MPLS-TP does not require IP. 586 3.4. MPLS Operations, Administration, and Maintenance (MPLS OAM) 588 For MPLS LSPs, there are primarily three Operations, Administration, 589 and Maintenance (OAM) mechanisms: Extended ICMP RFC 4884 [RFC4884] 590 RFC 4950 [RFC4950], LSP Ping RFC 4379 [RFC4379], and Bidirectional 591 Forwarding Detection (BFD) for MPLS LSPs RFC 5884 [RFC5884]. For 592 MPLS Pseudowires, there is also Virtual Circuit Connectivity 593 Verification (VCCV) RFC 5085 [RFC5085] RFC 5885 [RFC5885]. Most of 594 these mechanisms work in pure IPv6 environments, but there are some 595 problems encountered in mixed environments due to address-family 596 mismatches. The next subsections cover these gaps in detail. 598 Gap: Major. RFC 4379 needs to be updated to better support multipath 599 IPv6. Additionally, there is potential for dropped messages in 600 Extended ICMP and LSP ping due to IP version mismatches. It is 601 important to note that this is a more generic problem with tunneling 602 when IP address family mismatches exist, and is not specific to MPLS, 603 so while MPLS will be affected, it will be difficult to fix this 604 problem specifically for MPLS, rather than fixing the more generic 605 problem. 607 3.4.1. Extended ICMP 609 Extended ICMP to support Multi-part messages is defined in RFC 4884 610 [RFC4884]. This extensibility is defined generally for both ICMPv4 611 and ICMPv6. The specific ICMP extensions for MPLS are defined in RFC 612 4950 [RFC4950]. ICMP Multi-part with MPLS extensions works for IPv4 613 and IPv6. However, the mechanisms described in RFC 4884 and 4950 may 614 fail when tunneling IPv4 traffic over an LSP that is supported by an 615 IPv6-only infrastructure. 617 Assume the following: 619 o the path between two IPv4 only hosts contains 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 Now assume that one of the hosts sends an IPv4 packet to the other. 628 However, the packet's TTL expires on an LSP interior router. 629 According to RFC 3032 [RFC3032], the interior router should examine 630 the IPv4 payload, format an ICMPv4 message, and send it (over the 631 tunnel upon which the original packet arrived) to the egress LSP. In 632 this case, however, the LSP interior router is not IPv4-aware. It 633 cannot parse the original IPv4 datagram, nor can it send an IPv4 634 message. So, no ICMP message is delivered to the source. Some 635 specific ICMP extensions, in particular ICMP Extensions for Interface 636 and Next-Hop Identification RFC 5837 [RFC5837] restrict the address 637 family of address information included in an Interface Information 638 Object to the same one as the ICMP (see Section 4.5 of RFC 5837). 639 While these extensions are not MPLS specific, they can be used with 640 MPLS packets carrying IP datagrams. This has no implications for 641 IPv6-only environments. 643 Gap: Major. IP version mismatches may cause dropped messages. 644 However, as noted in the previous section, this problem is not 645 specific to MPLS. 647 3.4.2. Label Switched Path Ping (LSP Ping) 649 The LSP Ping mechanism defined in RFC 4379 [RFC4379] is specified to 650 work with IPv6. Specifically, the Target FEC Stacks include both 651 IPv4 and IPv6 versions of all FECs (see Section 3.2 of RFC 4379). 652 The only exceptions are the Pseudowire FECs, which are later 653 specified for IPv6 in RFC 6829 [RFC6829]. The multipath information 654 also includes IPv6 encodings (see Section 3.3.1 of RFC 4379). 656 LSP Ping packets are UDP packets over either IPv4 or IPv6 (see 657 Section 4.3 of RFC 4379). However, for IPv6 the destination IP 658 address is a (randomly chosen) IPv6 address from the range 659 0:0:0:0:0:FFFF:127/104. That is, using an IPv4-mapped IPv6 address. 660 This is a transitional mechanism that should not bleed into IPv6-only 661 networks, as [I-D.itojun-v6ops-v4mapped-harmful] explains. The issue 662 is that the MPLS LSP Ping mechanism needs a range of loopback IP 663 addresses to be used as destination addresses to exercise Equal Cost 664 Multiple Path (ECMP), but the IPv6 address architecture specifies a 665 single address (::1/128) for loopback. A mechanism to achieve this 666 was proposed in [I-D.smith-v6ops-larger-ipv6-loopback-prefix]. 668 Additionally, RFC 4379 does not define the value to be used in the 669 IPv6 Router Alert option (RAO). For IPv4 RAO, a value of zero is 670 used. However, there is no equivalent value for IPv6 RAO. This gap 671 needs to be fixed to be able to use LSP Ping in IPv6 networks. 672 Further details on this gap are captured, along with a proposed 673 solution, in [I-D.raza-mpls-oam-ipv6-rao]. 675 Another gap is that the mechanisms described in RFC 4379 may fail 676 when tunneling IPv4 traffic over an LSP that is supported by 677 IPv6-only infrastructure. 679 Assume the following: 681 o LSP Ping is operating in traceroute mode over an MPLS LSP 683 o the two routers that terminate the LSP run dual stack 685 o the LSP interior routers run IPv6 only 687 o the LSP is signaled over IPv6 689 Packets will expire at LSP interior routers. According to RFC 4379, 690 the interior router must parse the IPv4 Echo Request, and then, send 691 an IPv4 Echo Reply. However, the LSP interior router is not 692 IPv4-aware. It cannot parse the IPv4 Echo Request, nor can it send 693 an IPv4 Echo Reply. So, no reply is sent. 695 The mechanism described in RFC 4379 also does not sufficiently 696 explain the behavior in certain IPv6-specific scenarios. For 697 example, RFC 4379 defines the K value as 28 octets when Address 698 Family is set to IPv6 Unnumbered, but it doesn't describe how to 699 carry a 32 bit LSR Router ID in the 128 bit Downstream IP Address 700 Field. 702 Gap: Major. LSP ping uses IPv4-mapped IPv6 addresses, IP version 703 mismatches may cause dropped messages and unclear mapping from LSR 704 Router ID to Downstream IP Address. 706 3.4.3. Bidirectional Forwarding Detection (BFD) 708 The BFD specification for MPLS LSPs RFC 5884 [RFC5884] is defined for 709 IPv4 as well as IPv6 versions of MPLS FECs (see Section 3.1 of RFC 710 5884). Additionally the BFD packet is encapsulated over UDP and 711 specified to run over both IPv4 and IPv6 (see Section 7 of RFC 5884). 713 Gap: None. 715 3.4.4. Pseudowire OAM 717 The OAM specifications for MPLS Pseudowires define usage for both 718 IPv4 and IPv6. Specifically, VCCV RFC 5085 [RFC5085] can carry IPv4 719 or IPv6 OAM packets (see Section 5.1.1 and 5.2.1 of RFC 5085), and 720 VCCV for BFD RFC 5885 [RFC5885] also defines an IPv6 encapsulation 721 (see Section 3.2 of RFC 5885). 723 Additionally, for LSP Ping for Pseudowires, the Pseudowire FECs are 724 specified for IPv6 in RFC 6829 [RFC6829]. 726 Gap: None. 728 3.4.5. MPLS Transport Profile (MPLS-TP) OAM 730 As with MPLS-TP, MPLS-TP OAM RFC 6371 [RFC6371] does not require IP 731 or existing MPLS OAM functions, and should not be affected by 732 operation on an IPv6-only network. Therefore, this is out of scope 733 for this document, but is included for completeness. Although not 734 required, MPLS-TP can use IP. 736 Gap: None. MPLS-TP OAM does not require IP. 738 3.5. MIB Modules 740 RFC 3811 [RFC3811] defines the textual conventions for MPLS. These 741 lack support for IPv6 in defining MplsExtendedTunnelId and 742 MplsLsrIdentifier. These textual conventions are used in the MPLS TE 743 Management Information Base (MIB) specification RFC 3812 [RFC3812], 744 GMPLS TE MIB specification RFC 4802 [RFC4802] and Fast ReRoute (FRR) 745 extension RFC 6445 [RFC6445]. RFC 3811bis 746 [I-D.manral-mpls-rfc3811bis] tries to resolve this gap by marking 747 this textual convention as obsolete. 749 The other MIB specifications for LSR RFC 3813 [RFC3813], LDP RFC 3815 750 [RFC3815] and TE RFC 4220 [RFC4220] have support for both IPv4 and 751 IPv6. 753 Lastly, RFC 4990 [RFC4990] discusses how to handle IPv6 sources and 754 destinations in the MPLS and GMPLS Traffic Engineering (TE) 755 Management Information Base (MIB) modules. In particular, Section 8 756 of RFC 4990 [RFC4990] describes a method of defining or monitoring an 757 LSP tunnel using the MPLS-TE and GMPLS-TE MIB modules, working around 758 some of the limitations in RFC 3811 [RFC3811]. 760 Gap: Minor. Section 8 of RFC 4990 [RFC4990] describes a method to 761 handle IPv6 addresses in the MPLS-TE RFC 3812 [RFC3812] and GMPLS-TE 762 RFC 4802 [RFC4802] MIB modules. Work underway to update RFC 3811 via 763 RFC 3811bis [I-D.manral-mpls-rfc3811bis], may also need to update RFC 764 3812, RFC 4802, and RFC 6445, which depend on it. 766 4. Gap Summary 768 This draft has reviewed a wide variety of MPLS features and protocols 769 to determine their suitability for use on IPv6-only or IPv6-primary 770 networks. While some parts of the MPLS suite will function properly 771 without additional changes, gaps have been identified in others, 772 which will need to be addressed with follow-on work. This section 773 will summarize those gaps, along with pointers to any work in 774 progress to address them. Note that because the referenced drafts 775 are works in progress and do not have consensus at the time of this 776 document's publication, there could be other solutions proposed at a 777 future time, and the pointers in this document should not be 778 considered normative in any way. Additionally, work in progress on 779 new features that use MPLS protocols will need to ensure that those 780 protocols support operation on IPv6-only or IPv6-primary networks, or 781 explicitly identify any dependencies on existing gaps that, once 782 resolved, will allow proper IPv6-only operation. 784 Identified gaps in MPLS for IPv6-only networks 786 +---------+--------------------------+------------------------------+ 787 | Item | Gap | Addressed in | 788 +---------+--------------------------+------------------------------+ 789 | LDP | LSP mapping, LDP | LDP-IPv6 | 790 | S.3.2.1 | identifiers, LDP | [I-D.ietf-mpls-ldp-ipv6] | 791 | | discovery, LDP session | | 792 | | establishment, next hop | | 793 | | address and LDP TTL | | 794 | | security | | 795 +---------+--------------------------+------------------------------+ 796 | mLDP | inherits gaps from LDP, | inherits LDP-IPv6 | 797 | S.3.2.2 | RFC 6512 [RFC6512] | [I-D.ietf-mpls-ldp-ipv6], | 798 | | | additional fixes TBD | 799 +---------+--------------------------+------------------------------+ 800 | GMPLS | RFC 6370 [RFC6370] Node | TBD | 801 | S.3.2.6 | ID derivation | | 802 +---------+--------------------------+------------------------------+ 803 | L2VPN | RFC 6074 [RFC6074] | TBD | 804 | S.3.3.1 | discovery, signaling | | 805 +---------+--------------------------+------------------------------+ 806 | L3VPN | RFC 4659 [RFC4659] | TBD | 807 | S.3.3.2 | define method for | | 808 | | 4PE/4VPE | | 809 +---------+--------------------------+------------------------------+ 810 | OAM | RFC 4379 [RFC4379] no | IPv6 RAO for MPLS OAM | 811 | S.3.4 | IPv6 multipath support, | [I-D.raza-mpls-oam-ipv6-rao] | 812 | | no IPv6 RAO, possible | | 813 | | dropped messages in IP | | 814 | | version mismatch | | 815 +---------+--------------------------+------------------------------+ 816 | MIB | RFC 3811 [RFC3811] no | RFC 3811bis | 817 | Modules | IPv6 textual convention | [I-D.manral-mpls-rfc3811bis] | 818 | S.3.5 | | | 819 +---------+--------------------------+------------------------------+ 821 Table 1: IPv6-only MPLS Gaps 823 5. Acknowledgments 825 The authors wish to thank Alvaro Retana, Andrew Yourtchenko, Loa 826 Andersson, David Allan, Mach Chen, Mustapha Aissaoui, and Mark Tinka 827 for their detailed reviews, as well as Brian Haberman, Joel Jaeggli, 828 Adrian Farrel, Nobo Akiya, Francis Dupont, and Tobias Gondrom for 829 their comments. 831 6. Contributing Authors 833 The following people have contributed text to this draft: 835 Rajiv Asati 836 Cisco Systems 837 7025 Kit Creek Road 838 Research Triangle Park, NC 27709 839 US 841 Email: rajiva@cisco.com 843 Kamran Raza 844 Cisco Systems 845 2000 Innovation Drive 846 Ottawa, ON K2K-3E8 847 CA 849 Email: skraza@cisco.com 851 Ronald Bonica 852 Juniper Networks 853 2251 Corporate Park Drive 854 Herndon, VA 20171 855 US 857 Email: rbonica@juniper.net 859 Rajiv Papneja 860 Huawei Technologies 861 2330 Central Expressway 862 Santa Clara, CA 95050 863 US 865 Email: rajiv.papneja@huawei.com 867 Dhruv Dhody 868 Huawei Technologies 869 Leela Palace 870 Bangalore, Karnataka 560008 871 IN 873 Email: dhruv.ietf@gmail.com 874 Vishwas Manral 875 Ionos Networks 876 Sunnyvale, CA 94089 877 US 879 Email: vishwas@ionosnetworks.com 881 Nagendra Kumar 882 Cisco Systems, Inc. 883 7200 Kit Creek Road 884 Research Triangle Park, NC 27709 885 US 887 Email: naikumar@cisco.com 889 7. IANA Considerations 891 This memo includes no request to IANA. 893 8. Security Considerations 895 Changing the address family used for MPLS network operation does not 896 fundamentally alter the security considerations currently extant in 897 any of the specifics of the protocol or its features, however, 898 follow-on work recommended by this gap analysis will need to address 899 any effects of the use of IPv6 in their modifications may have on 900 security. 902 9. References 904 9.1. Normative References 906 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 907 (IPv6) Specification", RFC 2460, December 1998. 909 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 910 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 911 Encoding", RFC 3032, January 2001. 913 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 914 BGP-4", RFC 3107, May 2001. 916 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 917 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 918 Tunnels", RFC 3209, December 2001. 920 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 921 (GMPLS) Signaling Functional Description", RFC 3471, 922 January 2003. 924 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 925 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 926 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 928 [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual 929 Conventions (TCs) for Multiprotocol Label Switching (MPLS) 930 Management", RFC 3811, June 2004. 932 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 933 MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 934 4023, March 2005. 936 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 937 Label Switched (MPLS) Data Plane Failures", RFC 4379, 938 February 2006. 940 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 941 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 942 IPv6 VPN", RFC 4659, September 2006. 944 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and 945 J. Young, "Encapsulation of MPLS over Layer 2 Tunneling 946 Protocol Version 3", RFC 4817, March 2007. 948 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 949 Specification", RFC 5036, October 2007. 951 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 952 "Provisioning, Auto-Discovery, and Signaling in Layer 2 953 Virtual Private Networks (L2VPNs)", RFC 6074, January 954 2011. 956 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 957 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 959 [RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, 960 "Using Multipoint LDP When the Backbone Has No Route to 961 the Root", RFC 6512, February 2012. 963 9.2. Informative References 965 [I-D.ietf-l2vpn-evpn] 966 Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. 967 Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn- 968 evpn-11 (work in progress), October 2014. 970 [I-D.ietf-l3vpn-mvpn-mldp-nlri] 971 Wijnands, I., Rosen, E., and U. Joorde, "Encoding mLDP 972 FECs in the NLRI of BGP MCAST-VPN Routes", draft-ietf- 973 l3vpn-mvpn-mldp-nlri-07 (work in progress), October 2014. 975 [I-D.ietf-l3vpn-mvpn-pe-ce] 976 Patel, K., Rekhter, Y., and E. Rosen, "BGP as an MVPN PE- 977 CE Protocol", draft-ietf-l3vpn-mvpn-pe-ce-02 (work in 978 progress), October 2014. 980 [I-D.ietf-mpls-ldp-ipv6] 981 Asati, R., Manral, V., Papneja, R., and C. Pignataro, 982 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-13 983 (work in progress), July 2014. 985 [I-D.itojun-v6ops-v4mapped-harmful] 986 Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire 987 Considered Harmful", draft-itojun-v6ops-v4mapped- 988 harmful-02 (work in progress), October 2003. 990 [I-D.manral-mpls-rfc3811bis] 991 Manral, V., Tsou, T., Will, W., and F. Fondelli, 992 "Definitions of Textual Conventions (TCs) for 993 Multiprotocol Label Switching (MPLS) Management", draft- 994 manral-mpls-rfc3811bis-04 (work in progress), September 995 2014. 997 [I-D.raza-mpls-oam-ipv6-rao] 998 Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert 999 Option for MPLS OAM", draft-raza-mpls-oam-ipv6-rao-02 1000 (work in progress), September 2014. 1002 [I-D.smith-v6ops-larger-ipv6-loopback-prefix] 1003 Smith, M., "A Larger Loopback Prefix for IPv6", draft- 1004 smith-v6ops-larger-ipv6-loopback-prefix-04 (work in 1005 progress), February 2013. 1007 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1008 E. Lear, "Address Allocation for Private Internets", BCP 1009 5, RFC 1918, February 1996. 1011 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1012 (TE) Extensions to OSPF Version 2", RFC 3630, September 1013 2003. 1015 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 1016 "Multiprotocol Label Switching (MPLS) Traffic Engineering 1017 (TE) Management Information Base (MIB)", RFC 3812, June 1018 2004. 1020 [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, 1021 "Multiprotocol Label Switching (MPLS) Label Switching 1022 Router (LSR) Management Information Base (MIB)", RFC 3813, 1023 June 2004. 1025 [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions 1026 of Managed Objects for the Multiprotocol Label Switching 1027 (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 1028 2004. 1030 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 1031 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 1032 2005. 1034 [RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering 1035 Link Management Information Base", RFC 4220, November 1036 2005. 1038 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1039 Networks (VPNs)", RFC 4364, February 2006. 1041 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1042 Heron, "Pseudowire Setup and Maintenance Using the Label 1043 Distribution Protocol (LDP)", RFC 4447, April 2006. 1045 [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, 1046 "Node-ID Based Resource Reservation Protocol (RSVP) Hello: 1047 A Clarification Statement", RFC 4558, June 2006. 1049 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1050 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1052 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1053 Private Networks (L2VPNs)", RFC 4664, September 2006. 1055 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 1056 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 1057 4761, January 2007. 1059 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 1060 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 1061 RFC 4762, January 2007. 1063 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 1064 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 1065 Provider Edge Routers (6PE)", RFC 4798, February 2007. 1067 [RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label 1068 Switching (GMPLS) Traffic Engineering Management 1069 Information Base", RFC 4802, February 2007. 1071 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1072 "Extensions to Resource Reservation Protocol - Traffic 1073 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1074 Switched Paths (LSPs)", RFC 4875, May 2007. 1076 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 1077 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 1078 April 2007. 1080 [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP 1081 Extensions for Multiprotocol Label Switching", RFC 4950, 1082 August 2007. 1084 [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of 1085 Addresses in Generalized Multiprotocol Label Switching 1086 (GMPLS) Networks", RFC 4990, September 2007. 1088 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 1089 Pignataro, "The Generalized TTL Security Mechanism 1090 (GTSM)", RFC 5082, October 2007. 1092 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 1093 Connectivity Verification (VCCV): A Control Channel for 1094 Pseudowires", RFC 5085, December 2007. 1096 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1097 "OSPF Protocol Extensions for Path Computation Element 1098 (PCE) Discovery", RFC 5088, January 2008. 1100 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1101 "IS-IS Protocol Extensions for Path Computation Element 1102 (PCE) Discovery", RFC 5089, January 2008. 1104 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 1105 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 1107 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1108 Engineering", RFC 5305, October 2008. 1110 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, 1111 "Traffic Engineering Extensions to OSPF Version 3", RFC 1112 5329, September 2008. 1114 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1115 (PCE) Communication Protocol (PCEP)", RFC 5440, March 1116 2009. 1118 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 1119 Subsequent Address Family Identifier (SAFI) and the BGP 1120 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 1122 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 1123 Topology Confidentiality in Inter-Domain Path Computation 1124 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 1126 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1127 Path Computation Element Communication Protocol (PCEP) for 1128 Route Exclusions", RFC 5521, April 2009. 1130 [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- 1131 Balancing for Mesh Softwires", RFC 5640, August 2009. 1133 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 1134 Rivers, "Extending ICMP for Interface and Next-Hop 1135 Identification", RFC 5837, April 2010. 1137 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 1138 "Bidirectional Forwarding Detection (BFD) for MPLS Label 1139 Switched Paths (LSPs)", RFC 5884, June 2010. 1141 [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 1142 Detection (BFD) for the Pseudowire Virtual Circuit 1143 Connectivity Verification (VCCV)", RFC 5885, June 2010. 1145 [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of 1146 Monitoring Tools for Path Computation Element (PCE)-Based 1147 Architecture", RFC 5886, June 2010. 1149 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 1150 Berger, "A Framework for MPLS in Transport Networks", RFC 1151 5921, July 2010. 1153 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., 1154 and J. Meuric, "Extensions to the Path Computation Element 1155 Communication Protocol (PCEP) for Point-to-Multipoint 1156 Traffic Engineering Label Switched Paths", RFC 6006, 1157 September 2010. 1159 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 1160 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 1162 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1163 Engineering in IS-IS", RFC 6119, February 2011. 1165 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 1166 Maintenance Framework for MPLS-Based Transport Networks", 1167 RFC 6371, September 2011. 1169 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 1170 "Label Distribution Protocol Extensions for Point-to- 1171 Multipoint and Multipoint-to-Multipoint Label Switched 1172 Paths", RFC 6388, November 2011. 1174 [RFC6445] Nadeau, T., Koushik, A., and R. Cetin, "Multiprotocol 1175 Label Switching (MPLS) Traffic Engineering Management 1176 Information Base for Fast Reroute", RFC 6445, November 1177 2011. 1179 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 1180 VPNs", RFC 6513, February 2012. 1182 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1183 Encodings and Procedures for Multicast in MPLS/BGP IP 1184 VPNs", RFC 6514, February 2012. 1186 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 1187 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 1188 RFC 6540, April 2012. 1190 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 1191 Virtual Private Networks Using BGP for Auto-Discovery and 1192 Signaling", RFC 6624, May 2012. 1194 [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security 1195 Mechanism (GTSM) for the Label Distribution Protocol 1196 (LDP)", RFC 6720, August 2012. 1198 [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label 1199 Switched Path (LSP) Ping for Pseudowire Forwarding 1200 Equivalence Classes (FECs) Advertised over IPv6", RFC 1201 6829, January 2013. 1203 [RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C. 1204 Kodeboniya, "Multicast in Virtual Private LAN Service 1205 (VPLS)", RFC 7117, February 2014. 1207 Authors' Addresses 1209 Wesley George (editor) 1210 Time Warner Cable 1211 13820 Sunrise Valley Drive 1212 Herndon, VA 20111 1213 US 1215 Phone: +1-703-561-2540 1216 Email: wesley.george@twcable.com 1218 Carlos Pignataro (editor) 1219 Cisco Systems, Inc. 1220 7200-12 Kit Creek Road 1221 Research Triangle Park, NC 27709 1222 US 1224 Phone: +1-919-392-7428 1225 Email: cpignata@cisco.com