RFC 7439
Gap Analysis for Operating IPv6-Only MPLS Networks
🎀 RFC 7439: Gap Analysis for Operating IPv6-Only MPLS Networks 🎀
Bestie, this one's a gap analysis for MPLS on IPv6-only networks 💖✨ Written by W. George, Ed. (Time Warner Cable) and C. Pignataro, Ed. (Cisco), it's dated January 2015 and filed as Informational 🧚 It's published by the IETF and has ISSN 2070-1721. The title block doesn't list any "Obsoletes" or "Updates" entries, so it doesn't replace or change any other RFC 💅
Abstract
okay so the abstract is giving: this doc looks at the MPLS protocol suite through an IPv6 lens and flags the gaps that have to be fixed so MPLS stuff can run on IPv6-only networks 🦋 It's meant to focus on gaps in the standards that define MPLS, not to call out particular vendors' implementations (or lack of them) for IPv6-only MPLS 🙈
the data plane is already slay 👑 MPLS fully supports IPv6, and MPLS labeled packets can ride inside IPv6 packets using a bunch of different encapsulations. BUT support across the control-plane protocols, MPLS applications, MPLS Operations, Administration, and Maintenance (OAM), and MIB modules is kinda mixed, and some protocols have major gaps 😭 For most of those major gaps, work is already in progress to upgrade the protocols 🫶
Status of This Memo
this doc is not an Internet Standards Track specification. It's published just for informational purposes 🌸
it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, see Section 2 of RFC 5741 🧐
info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7439 🔗
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 💜
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the publication date. Please read those carefully, because they spell out your rights and restrictions for this doc 📜 Code Components pulled out of this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ✨
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 6
3.2. MPLS Control Plane . . . . . . . . . . . . . . . . . . . 6
3.2.1. Label Distribution Protocol (LDP) . . . . . . . . . . 6
3.2.2. Multipoint LDP (mLDP) . . . . . . . . . . . . . . . . 6
3.2.3. RSVP - Traffic Engineering (RSVP-TE) . . . . . . . . 7
3.2.3.1. Interior Gateway Protocol (IGP) . . . . . . . . . 8
3.2.3.2. RSVP-TE Point-to-Multipoint (P2MP) . . . . . . . 8
3.2.3.3. RSVP-TE Fast Reroute (FRR) . . . . . . . . . . . 8
3.2.4. Path Computation Element (PCE) . . . . . . . . . . . 8
3.2.5. Border Gateway Protocol (BGP) . . . . . . . . . . . . 9
3.2.6. Generalized Multi-Protocol Label Switching (GMPLS) . 9
3.3. MPLS Applications . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Layer 2 Virtual Private Network (L2VPN) . . . . . . . 9
3.3.1.1. Ethernet VPN (EVPN) . . . . . . . . . . . . . . . 10
3.3.2. Layer 3 Virtual Private Network (L3VPN) . . . . . . . 10
3.3.2.1. IPv6 Provider Edge/IPv4 Provider Edge (6PE/4PE) . 11
3.3.2.2. IPv6 Virtual Private Extension/IPv4 Virtual
Private Extension (6VPE/4VPE) . . . . . . . . . . 11
3.3.2.3. BGP Encapsulation Subsequent Address Family
Identifier (SAFI) . . . . . . . . . . . . . . . . 12
3.3.2.4. Multicast in MPLS/BGP IP VPN (MVPN) . . . . . . . 12
3.3.3. MPLS Transport Profile (MPLS-TP) . . . . . . . . . . 13
3.4. MPLS Operations, Administration, and Maintenance (MPLS
OAM) . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 14
3.4.2. Label Switched Path Ping (LSP Ping) . . . . . . . . . 15
3.4.3. Bidirectional Forwarding Detection (BFD) . . . . . . 16
3.4.4. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 16
3.4.5. MPLS Transport Profile (MPLS-TP) OAM . . . . . . . . 16
3.5. MIB Modules . . . . . . . . . . . . . . . . . . . . . . . 17
4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Normative References . . . . . . . . . . . . . . . . . . 19
6.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 281. Introduction ✨
okay so IPv6 [RFC2460] is a huge part of modern networks 🌈 When this doc was written, most IPv6 deployments were dual-stack, meaning IPv4 and IPv6 are both fully supported on lots (or all) of the network nodes. Single-stack basically meant IPv4-only devices 🙈 Dual-stack gives you a nice safety net for protocols and features that can't run on IPv6 alone yet, since they can keep using IPv4 when they need to 🫶
BUT here's the plot twist: as IPv6 gets more pervasive and IPv4 exhaustion starts changing how addresses get used, a lot of networks are going to need some or all of their nodes running as primarily IPv6 (most functions use IPv6, a few legacy features still use IPv4), or as IPv6-only (no IPv4 provisioned on the device) 😭 This shift to IPv6-only operation exposes any spots where features, protocols, or implementations still depend on IPv4 to work properly. So, in the spirit of RFC 6540 [RFC6540], which recommends that implementations stop requiring IPv4 for proper and complete function, this doc reviews the MPLS protocol suite through an IPv6 lens and flags the gaps that must be fixed so MPLS-related protocols and applications can run on IPv6-only networks and on networks that are primarily IPv6 (called IPv6-primary from here on) 💅 Same deal as the abstract: it focuses on gaps in the MPLS standards, not on particular vendor implementations (or lack thereof) for IPv6-only MPLS 🦋
2. Use Case
this section explains why MPLS needs full IPv6-only support 💖 It's not trying to cover every possible use case. It just gives one example to show the context and justify doing this gap analysis 🎀
IP convergence keeps pulling new kinds of devices onto IP 🌸 Think set-top boxes for IP video, cell tower electronics (macro or micro cells), infrastructure Wi-Fi access points, and machine-to-machine (M2M) or Internet of Things (IoT) devices. For some of these, the deployment base is huge, on the order of thousands or even millions of devices across a network 🤯 Put that scale together with RFC 1918 [RFC1918] address space overlapping more and more inside the average network, plus not enough globally routable IPv4 space for long-term growth, and you start needing lots of endpoints to be managed purely over IPv6 🧚 Even when these devices carry some IPv4 user data, it's often wrapped in another protocol, so the link between the endpoint and its upstream devices can be IPv6-only without hurting IPv4 support for the user data. As the number of devices grows, operators are basically forced to move to IPv6 😭 Depending on which MPLS features are needed, it's reasonable to assume the existing MPLS network will need to be extended to these IPv6-only devices 🫶
And it's about to get even more intense 🔥 As IPv4 exhaustion hits harder, more aggressive IPv4 address reclamation measures will be justified. Lots of networks will probably focus on keeping their remaining IPv4 addresses for revenue-generating customers, so legacy IPv4 support can stick around as long as it's needed 💅 As a result, some or all of the network infrastructure, including MPLS Label Switching Routers (LSRs) and Label Edge Routers (LERs), might have its IPv4 addresses reclaimed and move toward IPv6-only operation 👑
3. Gap Analysis
the big question for this section: what breaks when you try to use MPLS features on a network of IPv6-only devices? 🧐 The baseline assumption is that some endpoints, as well as Label Switching Routers (Provider Edge (PE) and Provider (P) routers), only have IPv6 transport available. They still need to support the full suite of MPLS features defined as of this doc's writing, at parity with what they get on an IPv4 network 💖 That's needed whether features are enabled through the Label Distribution Protocol (LDP) [RFC5036], RSVP - Traffic Engineering (RSVP-TE) [RFC3209], or Border Gateway Protocol (BGP) [RFC3107], and whether they're encapsulated in MPLS [RFC3032], IP [RFC4023], Generic Routing Encapsulation (GRE) [RFC4023], or Layer 2 Tunneling Protocol Version 3 (L2TPv3) [RFC4817] 🎀 When you're evaluating these gaps, it's important to tell user data apart from control-plane data. Even though this doc is focused on IPv6-only operation, it's pretty likely that some of the user payload data carried in the IPv6-only MPLS network will still be IPv4 🙈
quick terminology note 📝 Gaps in this doc are labeled "Major" or "Minor". Major gaps need significant changes to one or more standards, either because the existing standards language is missing functionality for IPv6-only operation or because it explicitly requires IPv4 with no IPv6 alternative defined 😭 Minor gaps only need changes to clarify existing standards language. Usually these changes are about explicitly codifying IPv6 support in places where it's implicit or missing today, but the omission isn't likely to stop IPv6-only operation 🦋
3.1. MPLS Data Plane
okay so MPLS labeled packets can ride over a bunch of different data links [RFC3032] 🦋, and they can also get encapsulated inside IP 💅. The MPLS-in-IP-and-GRE encapsulations, plus MPLS over L2TPv3, all support IPv6 🫶. For the details, check Section 3 of RFC 4023 [RFC4023] and Section 2 of RFC 4817 [RFC4817], respectively.
Gap: None. ✨
3.2. MPLS Control Plane
3.2.1. Label Distribution Protocol (LDP)
LDP [RFC5036] 🌸 is the protocol that defines how Label Switching Routers hand out labels to each other so they can use those labels to forward traffic. LDP was built for IPv4 or dual-stack networks, and it's got a bunch of deficiencies that stop it from working in an IPv6-only network 😭. LDP-IPv6 [LDP-IPv6] calls out those deficiencies for LDP running in IPv6-only or dual-stack networks, and it specifies the protocol changes to fix them. The deficiencies are about LSP mapping, LDP identifiers, LDP discovery, LDP session establishment, next-hop address, and LDP Time To Live (TTL) security [RFC5082] [RFC6720]. Lots of little pieces, all main character energy 👑.
Gap: Major; update to RFC 5036 in progress via [LDP-IPv6], which should close this gap. 🔥
3.2.2. Multipoint LDP (mLDP)
Multipoint LDP (mLDP) is a set of LDP extensions for setting up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) LSPs 🧚. Those extensions are specified in RFC 6388 [RFC6388]. When it comes to the IPv6-only gap analysis, mLDP has two areas of interest:
- LDP Control Plane: mLDP uses the LDP control plane to discover and set up sessions with its peers, so it inherits the same gaps as LDP (Section 3.2.1) for control plane stuff (discovery, transport, and session establishment) in an IPv6-only network 🙈.
- Multipoint (MP) Forwarding Equivalence Class (FEC) Root Address: mLDP defines its own MP FECs and rules, which are different from LDP's, for mapping MP LSPs 💜. An mLDP MP FEC has a Root Address field, which is an IP address in IP networks. The current spec lets you specify the root address based on the Address Family Identifier (AFI), so it covers both IPv4 and IPv6 root addresses. That means no extension is needed to support IPv6-only MP LSPs ✨. Each LSR taking part in an MP LSP setup uses the root address so that root address reachability gets resolved with a table lookup against it, which finds the matching upstream neighbor(s). This becomes a problem if an MP LSP crosses IPv4-only and IPv6-only nodes in a dual-stack network on its way to the root node 😬.
For example, consider the following setup, where R1/R6 are IPv4-only, R3/R4 are IPv6-only, and R2/R5 are dual-stack LSRs:
( IPv4-only ) ( IPv6-only ) ( IPv4-only )
R1 -- R2 -- R3 -- R4 -- R5 -- R6
Leaf RootSay R1 is a leaf node for a P2MP LSP rooted at R6, the root node 🌈. R1 uses R6's IPv4 address as the root address in the MP FEC. As the MP LSP signaling moves from R1 toward R6, the setup fails at the first IPv6-only transit/branch LSR (R3) when it tries to find reachability for the IPv4 root address 💀. RFC 6512 [RFC6512] defines a recursive-FEC solution and the mLDP procedures for when the backbone (transit/branch) LSRs have no route to the root. The proposed solution is defined for a BGP-free core in a VPN environment, but a similar concept can be used or extended to fix the problem above, where an IPv6-only backbone gets an MP FEC element with an IPv4 address 🦋. The solution needs a border LSR (the one sitting on the border of an IPv4/IPv6 island, which is R2 and R5 in this example) to translate an IPv4 root address into an equivalent IPv6 address, and vice versa, using procedures similar to RFC 6512 🫶.
Gap: Major; update in progress for LDP via [LDP-IPv6], may need additional updates to RFC 6512. 😭
3.2.3. RSVP - Traffic Engineering (RSVP-TE)
RSVP-TE [RFC3209] defines a set of procedures and enhancements for establishing LSP tunnels that can be automatically routed away from network failures, congestion, and bottlenecks 🚗. RSVP-TE lets you establish an LSP for an IPv4 or IPv6 prefix, thanks to its LSP_TUNNEL_IPv6 object and subobjects 🎀.
Gap: None. 💅
3.2.3.1. Interior Gateway Protocol (IGP)
RFC 3630 [RFC3630] specifies a way to add traffic engineering capabilities to OSPF Version 2. New TLVs and sub-TLVs were added in RFC 5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF Version 3 🌸.
RFC 5305 [RFC5305] specifies a way to add traffic engineering capabilities to IS-IS. New TLVs and sub-TLVs were added in RFC 6119 [RFC6119] to extend TE capabilities to IPv6 networks 🍓.
Gap: None. ✨
3.2.3.2. RSVP-TE Point-to-Multipoint (P2MP)
RFC 4875 [RFC4875] describes extensions to RSVP-TE for setting up Point-to-Multipoint (P2MP) LSPs in MPLS and Generalized MPLS (GMPLS), with support for both IPv4 and IPv6 🧚♀️.
Gap: None. 💖
3.2.3.3. RSVP-TE Fast Reroute (FRR)
RFC 4090 [RFC4090] specifies Fast Reroute (FRR) mechanisms for setting up backup LSP tunnels for local repair, and it supports both IPv4 and IPv6 networks ⚡. Also, [RFC5286] describes using loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS networks when there's a single failure, whether that's a link, a node, or a shared risk link group (SRLG), for both IPv4 and IPv6 🛡️.
Gap: None. 🦋
3.2.4. Path Computation Element (PCE)
The Path Computation Element (PCE), defined in RFC 4655 [RFC4655], is an entity that can compute a network path or route based on a network graph and apply computational constraints 🗺️. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed. The PCE Communication Protocol (PCEP) is designed as the communication protocol between PCCs and PCEs for path computations, and it's defined in RFC 5440 [RFC5440] 💜.
The PCEP specification [RFC5440] is defined for both IPv4 and IPv6, and it supports PCE discovery via an IGP (OSPF [RFC5088] or IS-IS [RFC5089]) using both IPv4 and IPv6 addresses 🌈. Note that PCEP uses the same subobject encoding as RSVP-TE, defined in RFC 3209 [RFC3209], which supports both IPv4 and IPv6 🫶.
The PCEP extensions for confidentiality [RFC5520], route exclusions [RFC5521], monitoring [RFC5886], and P2MP TE LSPs [RFC6006] all have support for both IPv4 and IPv6 👑.
Gap: None. 💅
3.2.5. Border Gateway Protocol (BGP)
RFC 3107 [RFC3107] specifies a set of BGP procedures for distributing labels (for prefixes from any address family) between label switch routers, so they can use those labels to forward traffic 🍓. RFC 3107 lets BGP distribute the label for an IPv4 or IPv6 prefix in an IPv6-only network 🦋.
Gap: None. ✨
3.2.6. Generalized Multi-Protocol Label Switching (GMPLS)
The Generalized Multi-Protocol Label Switching (GMPLS) specification includes signaling functional extensions [RFC3471] and RSVP-TE extensions [RFC3473]. The gap analysis in Section 3.2.3 applies to these 🔍.
RFC 4558 [RFC4558] specifies Node-ID Based RSVP Hello Messages, with capability for both IPv4 and IPv6 🌸. RFC 4990 [RFC4990] clarifies how IPv6 addresses are used in GMPLS networks, including how they're handled in the MIB modules 💖.
The second paragraph of Section 5.3 of RFC 6370 [RFC6370] describes the mapping from an MPLS Transport Profile (MPLS-TP) LSP_ID to RSVP-TE, and it assumes that Node_IDs are derived from valid IPv4 addresses. That assumption fails in an IPv6-only network, since there wouldn't be any IPv4 addresses at all 😬.
Gap: Minor; Section 5.3 of RFC 6370 [RFC6370] needs to be updated. 🛠️
3.3. MPLS Applications
3.3.1. Layer 2 Virtual Private Network (L2VPN)
L2VPN [RFC4664] covers two fundamentally different kinds of Layer 2 VPN services a service provider could offer a customer: Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) 🎀. RFC 4447 [RFC4447] and RFC 4762 [RFC4762] specify the LDP protocol changes to instantiate VPWS and VPLS services, respectively, in an MPLS network that uses LDP as the signaling protocol. RFC 6074 [RFC6074] complements these by specifying procedures for instantiating L2VPNs (e.g., VPWS, VPLS) using BGP as a discovery protocol, with LDP or L2TPv3 as the signaling protocol. RFC 4761 [RFC4761] and RFC 6624 [RFC6624] specify BGP protocol changes to instantiate VPLS and VPWS services in an MPLS network, using BGP for both discovery and signaling 🧚.
In an IPv6-only MPLS network, using L2VPN means connecting Layer 2 islands over an IPv6 MPLS core, and very few changes are needed to support operation over an IPv6-only network 🌈. The L2VPN signaling protocol is either BGP or LDP in an MPLS network, and both can run directly over IPv6 core infrastructure as well as IPv6 edge devices 🫶. RFC 6074 [RFC6074] is the only RFC that appears to have a gap for IPv6-only operation 😭. In its discovery procedures (Sections 3.2.2 and 6 of RFC 6074 [RFC6074]), it suggests encoding PE IP addresses in the Virtual Switching Instance ID (VSI-ID). The VSI-ID is encoded in Network Layer Reachability Information (NLRI) and should not exceed 12 bytes, so that its AFI/SAFI (Subsequent Address Family Identifier) encoding can be told apart from RFC 4761. This means a PE IP address cannot be an IPv6 address 🙈. Also, in its signaling procedures (Section 3.2.3 of RFC 6074 [RFC6074]), it suggests encoding PE_addr in the Source Attachment Individual Identifier (SAII) and the Target Attachment Individual Identifier (TAII). Those are limited to 32 bits (AII Type=1) right now 💀.
RFC 6073 [RFC6073] defines the new LDP Pseudowire (PW) Switching Point PE TLV, which supports both IPv4 and IPv6 💖.
Gap: Minor; RFC 6074 needs to be updated. 🛠️
3.3.1.1. Ethernet VPN (EVPN)
Ethernet VPN [EVPN] defines a method for using BGP MPLS-based Ethernet VPNs 🦋. Because it can use functions in LDP and mLDP, as well as Multicast VPLS [RFC7117], it inherits the LDP gaps identified earlier in Section 3.2.1 🌸. Once those gaps are resolved, it should function properly on IPv6-only networks, as defined ✨.
Gap: Major for LDP; update to RFC 5036 in progress via [LDP-IPv6] that should close this gap (see Section 3.2.1). 👑
3.3.2. Layer 3 Virtual Private Network (L3VPN) 🌐
RFC 4364 [RFC4364] is the one that lays out how a Service Provider can use an IP backbone to run IP VPNs for its customers. ✨ Here are the use cases that pop up in this gap analysis:
- Connecting IPv6 islands over IPv6-only MPLS network
- Connecting IPv4 islands over IPv6-only MPLS network
Okay, both of these need an IP packet to get mapped onto an IPv6-signaled LSP 💅. RFC 4364 defines Layer 3 Virtual Private Networks (L3VPNs) for IPv4-only, and it refers to 32-bit BGP next-hop addresses 🙈. Then RFC 4659 [RFC4659] comes in and adds IPv6 support to L3VPNs, including 128-bit BGP next-hop addresses, and it talks about how things work whether IPv6 is the payload or the underlying transport address family 🦋. The tea though: RFC 4659 does not formally update RFC 4364 🫠. So an implementer could totally miss this extra set of standards unless it gets called out separately from the base stuff in RFC 4364. And Section 1 of RFC 4659 explicitly says use case 2 is out of scope for that document 💀.
The authors don't think there are any extra issues when you use L2TPv3, RSVP, or GRE (instead of MPLS) as transport on an IPv6-only network ✨.
Gap: Major; RFC 4659 needs to be updated to explicitly cover use case 2 (discussed in further detail below) 🔥
3.3.2.1. IPv6 Provider Edge/IPv4 Provider Edge (6PE/4PE) 🎀
RFC 4798 [RFC4798] defines IPv6 Provider Edge (6PE), which explains how to connect IPv6 islands over a MPLS-enabled IPv4 cloud 🌸. Use case 2 does the reverse, so you could call it IPv4 Provider Edge (4PE) 🔄. The method for supporting this use case isn't defined explicitly, though 😤. To make it work, IPv4 edge devices need to be able to map IPv4 traffic to MPLS IPv6 core LSPs 🧚. Also, the core switches may not understand IPv4 at all 🙃. In some cases, though, they might need to exchange Labeled IPv4 routes from one Autonomous System (AS) to a neighboring AS.
Gap: Major; RFC 4798 covers only the "6PE" case. Use case 2 is currently not specified in an RFC. 💜
3.3.2.2. IPv6 Virtual Private Extension/IPv4 Virtual Private Extension (6VPE/4VPE) 🌈
RFC 4659 [RFC4659] defines IPv6 Virtual Private Network Extension (6VPE) 👑. It's a method where a Service Provider uses its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. It lets the core network be MPLS IPv4 or MPLS IPv6, which covers use case 1 above 🫶. RFC 4364 should work as defined for use case 2 above, and you could call that IPv4 Virtual Private Extension (4VPE) ✨. But the RFC explicitly does not discuss this use and defines it as out of scope 😭.
Gap: Minor; RFC 4659 needs to be updated to explicitly cover use case 2. 🦋
3.3.2.3. BGP Encapsulation Subsequent Address Family Identifier (SAFI) 🍓
RFC 5512 [RFC5512] defines the BGP Encapsulation SAFI and the BGP Tunnel Encapsulation Attribute 💖. These can be used to signal tunneling over an IP Core that uses a single address family. This mechanism supports transport of MPLS (and other protocols) over Tunnels in an IP core, including an IPv6-only core 🌊. And load balancing can be provided as specified in RFC 5640 [RFC5640] ⚖️.
Gap: None. ✅
3.3.2.4. Multicast in MPLS/BGP IP VPN (MVPN) 📡
RFC 6513 [RFC6513] defines the procedure for providing multicast service over an MPLS VPN backbone for downstream customers 📣. It's sometimes called Next Generation Multicast VPN (NG-MVPN) 💅. The procedure involves the set of protocols below 👇.
3.3.2.4.1. PE-CE Multicast Routing Protocol 🛣️
RFC 6513 [RFC6513] explains using Protocol Independent Multicast (PIM) as a Provider Edge - Customer Edge (PE-CE) protocol 🧭. Meanwhile, Section 11.1.2 of RFC 6514 [RFC6514] explains using mLDP as a PE-CE protocol 🔧.
The MCAST-VPN NLRI route-type format defined in RFC 6514 [RFC6514] doesn't fully cover every scenario when mLDP is used as a PE-CE protocol 😬. The issue is explained in Section 2 of [mLDP-NLRI], along with a new route type that encodes the mLDP FEC in NLRI 🧩.
Also, [PE-CE] defines using BGP as a PE-CE protocol 💫.
Gap: None. ✅
3.3.2.4.2. P-Tunnel Instantiation 🚇
[RFC6513] explains the use of the tunnels below 🫧:
- RSVP-TE P2MP LSP
- PIM Tree
- mLDP P2MP LSP
- mLDP MP2MP LSP
- Ingress Replication
Gap: Gaps in RSVP-TE P2MP LSP (Section 3.2.3.2) and mLDP (Section 3.2.2) P2MP and MP2MP LSP are covered in previous sections. 📚 There are no MPLS-specific gaps for PIM Tree or Ingress Replication 🙌. Any protocol-specific gaps that aren't related to MPLS are outside the scope of this document 🚫.
3.3.2.4.3. PE-PE Multicast Routing Protocol 🔁
Section 3.1 of RFC 6513 [RFC6513] explains using PIM as a PE-PE protocol 🧶. RFC 6514 [RFC6514] explains using BGP as a PE-PE protocol 🧵.
PE-PE multicast routing isn't specific to P-tunnels or to MPLS 🙅♀️. It can be PIM or BGP, with P-tunnels that are label based or PIM tree based. Turning on PIM as a PE-PE multicast protocol is the same as running it on a non-MPLS IPv6 network, so there aren't any MPLS-specific considerations, and any gaps apply to non-MPLS networks too 💜. Similarly, BGP only includes the P-Multicast Service Interface (PMSI) tunnel attribute as a part of the NLRI 📦. That attribute is inherited from P-tunnel instantiation and is considered an opaque value 🤐. Any gaps in the control plane (PIM or BGP) won't be specific to MPLS 🙌.
Gap: Any gaps in PIM or BGP as a PE-PE multicast routing protocol are not unique to MPLS, and therefore are outside the scope of this document. It is included for completeness. 🫶
3.3.3. MPLS Transport Profile (MPLS-TP) 🦋
MPLS-TP does not require IP (see Section 2 of RFC 5921 [RFC5921]) 🙅♀️. It should not be affected by operation on an IPv6-only network 🌤️. So this is considered out of scope for this document, but it's included for completeness 📝.
Although it isn't required, MPLS-TP can use IP 💡. One example is in Section 3.2.6, where MPLS-TP identifiers can be derived from valid IPv4 addresses 🔢.
Gap: None. MPLS-TP does not require IP. 🎉
3.4. MPLS Operations, Administration, and Maintenance (MPLS OAM) 🛠️
For MPLS LSPs, there are primarily three OAM mechanisms 🔍: Extended ICMP [RFC4884] [RFC4950], LSP Ping [RFC4379], and Bidirectional Forwarding Detection (BFD) for MPLS LSPs [RFC5884]. For MPLS Pseudowires, there's also Virtual Circuit Connectivity Verification (VCCV) [RFC5085] [RFC5885] 🧪. Most of these work fine in pure IPv6 environments, but some problems come up in mixed environments because of address-family mismatches 😵💫. The next subsections cover these gaps in detail 👀.
Gap: Major; RFC 4379 needs to be updated to better support multipath IPv6. 🚨 Additionally, there's potential for dropped messages in Extended ICMP and LSP Ping due to IP version mismatches 📉. It's important to note that this is a more generic problem with tunneling when address-family mismatches exist, and it isn't specific to MPLS 🌍. While MPLS will be affected, it'll be difficult to fix this problem just for MPLS, rather than fixing the more generic problem 🧠.
3.4.1. Extended ICMP 📨
Extended ICMP, which supports Multi-part messages, is defined in RFC 4884 [RFC4884] 💌. This extensibility is defined generally for both ICMPv4 and ICMPv6 🌐. The specific ICMP extensions for MPLS are defined in RFC 4950 [RFC4950] 🏷️. ICMP Multi-part with MPLS extensions works for IPv4 and IPv6 ✅. However, the mechanisms described in RFC 4884 and 4950 may fail when tunneling IPv4 traffic over an LSP that is supported by an IPv6-only infrastructure 😱.
Let's assume the following 🤔:
- The path between two IPv4-only hosts contains an MPLS LSP.
- The two routers that terminate the LSP run dual stack.
- The LSP interior routers run IPv6 only.
- The LSP is signaled over IPv6.
Now picture one of the hosts sending an IPv4 packet to the other 📦. But the packet's TTL expires on an LSP interior router ⏰. According to RFC 3032 [RFC3032], the interior router should examine the IPv4 payload, format an ICMPv4 message, and send it (over the tunnel the original packet arrived on) to the egress LSP 📬. In this case, though, the LSP interior router isn't IPv4-aware 🙈. It can't parse the original IPv4 datagram, and it can't send an IPv4 message either 💔. So no ICMP message gets delivered to the source 🕳️.
Some specific ICMP extensions, like the ones for interface and next-hop identification [RFC5837], restrict the address family of address information included in an Interface Information Object to the same one as the ICMP (see Section 4.5 of RFC 5837) 🔒. These extensions aren't MPLS specific, but they can be used with MPLS packets carrying IP datagrams 🧃. This has no implications for IPv6-only environments 🌷.
Gap: Major; IP version mismatches may cause dropped messages. However, as noted in the previous section, this problem is not specific to MPLS. 🫠
3.4.2. Label Switched Path Ping (LSP Ping) 💖
okay so LSP Ping from RFC 4379 [RFC4379] is specified to work with IPv6, and it's giving full support 💅 The Target FEC Stacks include both IPv4 and IPv6 versions of all FECs (see Section 3.2 of RFC 4379). The only exceptions are the Pseudowire FECs, which are later specified for IPv6 in RFC 6829 [RFC6829]. The multipath info also includes IPv6 encodings (see Section 3.3.1 of RFC 4379) 🦋
LSP Ping packets are UDP packets over either IPv4 or IPv6 (see Section 4.3 of RFC 4379). BUT for IPv6, the destination IP address is a (randomly chosen) IPv6 address from the range 0:0:0:0:0:FFFF:127/104, which means it's using an IPv4-mapped IPv6 address 🙈 This is a transitional mechanism that should not bleed into IPv6-only networks, as [IPv4-MAPPED] explains. The issue is that the MPLS LSP Ping mechanism needs a range of loopback IP addresses to use as destination addresses so it can exercise Equal Cost Multiple Path (ECMP), but the IPv6 address architecture only specifies a single address (::1/128) for loopback. A mechanism to achieve this was proposed in [LOOPBACK-PREFIX] ✨
Also, RFC 4379 does not define the value to be used in the IPv6 Router Alert option (RAO). For IPv4 RAO, a value of zero is used. However, there is no equivalent value for IPv6 RAO. This gap needs to be fixed before LSP Ping can be used in IPv6 networks. Further details on this gap, along with a proposed solution, are captured in [IPv6-RAO] 🎀
Another gap is that the mechanisms described in RFC 4379 may fail when tunneling IPv4 traffic over an LSP that is supported by IPv6-only infrastructure. 😭
Assume the following:
- LSP Ping is operating in traceroute mode over an MPLS LSP.
- The two routers that terminate the LSP run dual stack.
- The LSP interior routers run IPv6 only.
- The LSP is signaled over IPv6.
Packets will expire at LSP interior routers. According to RFC 4379, the interior router must parse the IPv4 Echo Request and then send an IPv4 Echo Reply. However, the LSP interior router is not IPv4-aware. It cannot parse the IPv4 Echo Request, nor can it send an IPv4 Echo Reply. So, no reply is sent 💀
The mechanism described in RFC 4379 also doesn't sufficiently explain the behavior in certain IPv6-specific scenarios. For example, RFC 4379 defines the K value as 28 octets when the Address Family is set to IPv6 Unnumbered, but it doesn't describe how to carry a 32-bit LSR Router ID in the 128-bit Downstream IP Address field 🍓
Gap: Major; LSP Ping uses IPv4-mapped IPv6 addresses. IP version mismatches may cause dropped messages and unclear mapping from the LSR Router ID to Downstream IP Address.
3.4.3. Bidirectional Forwarding Detection (BFD) 🌸
The BFD specification for MPLS LSPs [RFC5884] is defined for IPv4, as well as IPv6, versions of MPLS FECs (see Section 3.1 of RFC 5884). Additionally, the BFD packet is encapsulated over UDP and specified to run over both IPv4 and IPv6 (see Section 7 of RFC 5884). Honestly, this one is clean 🫶
Gap: None. ✨
3.4.4. Pseudowire OAM 🧚
The OAM specifications for MPLS Pseudowires define usage for both IPv4 and IPv6. Specifically, VCCV [RFC5085] can carry IPv4 or IPv6 OAM packets (see Sections 5.1.1 and 5.2.1 of RFC 5085), and VCCV for BFD [RFC5885] also defines an IPv6 encapsulation (see Section 3.2 of RFC 5885) 💜
Additionally, for LSP Ping for pseudowires, the Pseudowire FECs are specified for IPv6 in RFC 6829 [RFC6829].
Gap: None. 👑
3.4.5. MPLS Transport Profile (MPLS-TP) OAM 🦋
As with MPLS-TP, MPLS-TP OAM [RFC6371] does not require IP or existing MPLS OAM functions and should not be affected by operation on an IPv6-only network. Therefore, this is out of scope for this document but is included for completeness. Although not required, MPLS-TP can use IP.
Gap: None. MPLS-TP OAM does not require IP. 🌈
3.5. MIB Modules 📚
RFC 3811 [RFC3811] defines the textual conventions for MPLS. These lack support for IPv6 in defining MplsExtendedTunnelId and MplsLsrIdentifier. These textual conventions are used in the MPLS-TE MIB specification [RFC3812], the GMPLS-TE MIB specification [RFC4802] and the FRR extension [RFC6445]. "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management" [MPLS-TC] tries to resolve this gap by marking this textual convention as obsolete 🥺
The other MIB specifications for LSR [RFC3813], LDP [RFC3815], and TE [RFC4220] have support for both IPv4 and IPv6, so they're in a good place ✨
Lastly, RFC 4990 [RFC4990] discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS-TE MIB modules. In particular, Section 8 of RFC 4990 [RFC4990] describes a method of defining or monitoring an LSP tunnel using the MPLS-TE and GMPLS-TE MIB modules, working around some of the limitations in RFC 3811 [RFC3811] 🧠
Gap: Minor; Section 8 of RFC 4990 [RFC4990] describes a method to handle IPv6 addresses in the MPLS-TE [RFC3812] and GMPLS-TE [RFC4802] MIB modules. Work underway to update RFC 3811 via [MPLS-TC] may also need to update RFC 3812, RFC 4802, and RFC 6445, which depend on it.
4. Gap Summary 💅✨
This document has reviewed a wide variety of MPLS features and protocols to determine their suitability for use on IPv6-only or IPv6-primary networks. While some parts of the MPLS suite will function properly without additional changes, gaps have been identified in others that will need to be addressed with follow-on work. This section will summarize those gaps, along with pointers to any work in progress to address them. Note that because the referenced documents are works in progress and do not have consensus at the time of this document's publication, there could be other solutions proposed at a future time, and the pointers in this document should not be considered normative in any way. Additionally, work in progress on new features that use MPLS protocols will need to ensure that those protocols support operation on IPv6-only or IPv6-primary networks, or explicitly identify any dependencies on existing gaps that, once resolved, will allow proper IPv6-only operation 🔥
Identified Gaps in MPLS for IPv6-Only Networks
+---------+---------------------------------------+-----------------+
| Item | Gap | Addressed in |
+---------+---------------------------------------+-----------------+
| LDP | LSP mapping, LDP identifiers, LDP | [LDP-IPv6] |
| S.3.2.1 | discovery, LDP session establishment, | |
| | next-hop address, and LDP TTL | |
| | security | |
+---------+---------------------------------------+-----------------+
| mLDP | Inherits gaps from LDP, RFC 6512 | Inherits |
| S.3.2.2 | [RFC6512] | [LDP-IPv6], |
| | | additional |
| | | fixes TBD |
+---------+---------------------------------------+-----------------+
| GMPLS | RFC 6370 [RFC6370] Node ID derivation | TBD |
| S.3.2.6 | | |
+---------+---------------------------------------+-----------------+
| L2VPN | RFC 6074 [RFC6074] discovery, | TBD |
| S.3.3.1 | signaling | |
+---------+---------------------------------------+-----------------+
| L3VPN | RFC 4659 [RFC4659] does not define a | TBD |
| S.3.3.2 | method for 4PE/4VPE | |
+---------+---------------------------------------+-----------------+
| OAM | RFC 4379 [RFC4379] No IPv6 multipath | [IPv6-RAO] |
| S.3.4 | support, no IPv6 RAO, possible | |
| | dropped messages in IP version | |
| | mismatch | |
+---------+---------------------------------------+-----------------+
| MIB | RFC 3811 [RFC3811] no IPv6 textual | [MPLS-TC] |
| Modules | convention | |
| S.3.5 | | |
+---------+---------------------------------------+-----------------+
Table 1: IPv6-Only MPLS Gaps5. Security Considerations 🔐
Changing the address family used for MPLS network operation does not fundamentally alter the security considerations currently extant in any of the specifics of the protocol or its features. However, follow-on work recommended by this gap analysis will need to address any effects that the use of IPv6 in their modifications may have on security. This part is serious business, bestie, so don't skip it 🙈
6. References 📖
6.1. Normative References 📚✨
okay bestie, these are the must-reads 🫶 the stuff this whole doc leans on, so you need the exact details
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001, <http://www.rfc-editor.org/info/rfc3032>.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001, <http://www.rfc-editor.org/info/rfc3107>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003, <http://www.rfc-editor.org/info/rfc3471>.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004, <http://www.rfc-editor.org/info/rfc3811>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005, <http://www.rfc-editor.org/info/rfc4023>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006, <http://www.rfc-editor.org/info/rfc4379>.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006, <http://www.rfc-editor.org/info/4659>.
[RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and J. Young, "Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3", RFC 4817, March 2007, <http://www.rfc-editor.org/info/rfc4817>.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011, <http://www.rfc-editor.org/info/rfc6074>.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011, <http://www.rfc-editor.org/info/rfc6370>.
[RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, "Using Multipoint LDP When the Backbone Has No Route to the Root", RFC 6512, February 2012, <http://www.rfc-editor.org/info/rfc6512>.
6.2. Informative References 🌸💜
these are the extra-credit reads, the ones that give you the bigger picture 🧚
[EVPN] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", Work in Progress, draft-ietf-l2vpn-evpn-11, October 2014.
[IPv4-MAPPED] Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire Considered Harmful", Work in Progress, draft-itojun-v6ops-v4mapped-harmful-02, October 2003.
[IPv6-RAO] Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert Option for MPLS OAM", Work in Progress, draft-raza-mpls-oam-ipv6-rao-02, September 2014.
[LDP-IPv6] Asati, R., Manral, V., Papneja, R., and C. Pignataro, "Updates to LDP for IPv6", Work in Progress, draft-ietf-mpls-ldp-ipv6-14, October 2014.
[LOOPBACK-PREFIX] Smith, M., "A Larger Loopback Prefix for IPv6", Work in Progress, draft-smith-v6ops-larger-ipv6-loopback-prefix-04, February 2013.
[mLDP-NLRI] Wijnands, I., Rosen, E., and U. Joorde, "Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes", Work in Progress, draft-ietf-l3vpn-mvpn-mldp-nlri-10, November 2014.
[MPLS-TC] Manral, V., Tsou, T., Will, W., and F. Fondelli, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", Work in Progress, draft-manral-mpls-rfc3811bis-04, September 2014.
[PE-CE] Patel, K., Rekhter, Y., and E. Rosen, "BGP as an MVPN PE-CE Protocol", Work in Progress, draft-ietf-l3vpn-mvpn-pe-ce-02, October 2014.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004, <http://www.rfc-editor.org/info/rfc3812>.
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004, <http://www.rfc-editor.org/info/rfc3813>.
[RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004, <http://www.rfc-editor.org/info/rfc3815>.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005, <http://www.rfc-editor.org/info/rfc4090>.
[RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering Link Management Information Base", RFC 4220, November 2005, <http://www.rfc-editor.org/info/rfc4220>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006, <http://www.rfc-editor.org/info/rfc4447>.
[RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, "Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement", RFC 4558, June 2006, <http://www.rfc-editor.org/info/rfc4558>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006, <http://www.rfc-editor.org/info/rfc4664>.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007, <http://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007, <http://www.rfc-editor.org/info/rfc4762>.
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007, <http://www.rfc-editor.org/info/rfc4798>.
[RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007, <http://www.rfc-editor.org/info/rfc4802>.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007, <http://www.rfc-editor.org/info/rfc4875>.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007, <http://www.rfc-editor.org/info/rfc4884>.
[RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007, <http://www.rfc-editor.org/info/rfc4950>.
[RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks", RFC 4990, September 2007, <http://www.rfc-editor.org/info/rfc4990>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008, <http://www.rfc-editor.org/info/rfc5088>.
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008, <http://www.rfc-editor.org/info/rfc5089>.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008, <http://www.rfc-editor.org/info/rfc5286>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, September 2008, <http://www.rfc-editor.org/info/rfc5329>.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009, <http://www.rfc-editor.org/info/rfc5512>.
Acknowledgements 🫶
okay bestie, this is where the authors say thank u to everyone who helped make this doc happen 🥹 they're giving a big shoutout to Alvaro Retana, Andrew Yourtchenko, Loa Andersson, David Allan, Mach Chen, Mustapha Aissaoui, and Mark Tinka for their detailed reviews ✨ and also to Brian Haberman, Joel Jaeggli, Adrian Farrel, Nobo Akiya, Francis Dupont, and Tobias Gondrom for their comments 💖 literally the whole squad 👑
Contributors 💅
these are the people who actually wrote text for this doc, so they're the main character energy crew 🎀 their details are right below, exactly as the RFC has them 🦋
Rajiv Asati
Cisco Systems
7025 Kit Creek Road
Research Triangle Park, NC 27709
United States
EMail: rajiva@cisco.com
Kamran Raza
Cisco Systems
2000 Innovation Drive
Ottawa, ON K2K-3E8
Canada
EMail: skraza@cisco.com
Ronald Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171
United States
EMail: rbonica@juniper.net
Rajiv Papneja
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
United States
EMail: rajiv.papneja@huawei.com
Dhruv Dhody
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
India
EMail: dhruv.ietf@gmail.com
Vishwas Manral
Ionos Networks
Sunnyvale, CA 94089
United States
EMail: vishwas@ionosnetworks.com
Nagendra Kumar
Cisco Systems, Inc.
7200 Kit Creek Road
Research Triangle Park, NC 27709
United States
EMail: naikumar@cisco.comAuthors' Addresses 🦋
and last but not least, the editors who held this whole thing together 🌸 here's how to reach them ✨
Wesley George (editor)
Time Warner Cable
13820 Sunrise Valley Drive
Herndon, VA 20111
United States
Phone: +1-703-561-2540
EMail: wesley.george@twcable.com
Carlos Pignataro (editor)
Cisco Systems, Inc.
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
United States
Phone: +1-919-392-7428
EMail: cpignata@cisco.com📦 where this page comes from
- ietf: rfc7439 2015-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms