RFC 4817

RFC 4817: Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 🎀

Okay bestie, this is RFC 4817 💖 It's a Standards Track doc from the IETF Network Working Group, dated March 2007. The authors are M. Townsley, C. Pignataro, and S. Wainner (all Cisco Systems), T. Seely (Sprint Nextel), and J. Young (no affiliation listed) ✨ The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice ©️

Copyright (C) The IETF Trust (2007).

Abstract 🌸

The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) is a protocol for tunneling all kinds of payload types over IP networks, so it's giving versatile 🦋 This doc explains how to carry an MPLS label stack and its payload over the L2TPv3 data encapsulation. The result is that an application which normally needs an MPLS-enabled core network can use an L2TPv3 encapsulation over an IP network instead. Iconic behavior, honestly 👑

Table of Contents 🗂️

   1. Introduction ....................................................2
      1.1. Specification of Requirements ..............................2
   2. MPLS over L2TPv3 Encoding .......................................2
   3. Assigning the L2TPv3 Session ID and Cookie ......................4
   4. Applicability ...................................................4
   5. Congestion Considerations .......................................6
   6. Security Considerations .........................................6
      6.1. In the Absence of IPsec ....................................7
      6.2. Context Validation .........................................7
      6.3. Securing the Tunnel with IPsec .............................8
   7. Acknowledgements ................................................9
   8. References .....................................................10
      8.1. Normative References ......................................10
      8.2. Informative References ....................................10

1. Introduction ✨

Okay so this section is the setup 💖 It defines how to encapsulate an MPLS label stack and its payload inside the L2TPv3 tunnel payload. After the MPLS over L2TPv3 encapsulation procedure is defined, other MPLS over IP encapsulation options get discussed in an Applicability section, specifically IP, Generic Routing Encapsulation (GRE), and IPsec, all in context with MPLS over L2TPv3 🎀 This document only describes encapsulation. It doesn't try to cover every MPLS-based application that might run over L2TPv3, which is honestly the right call 🙈

1.1. Specification of Requirements 📝

In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. MPLS over L2TPv3 Encoding 🦋

MPLS over L2TPv3 lets you tunnel an MPLS stack [RFC3032] and its payload over an IP network, using the L2TPv3 encapsulation defined in [RFC3931] 💅 The MPLS Label Stack and payload are carried in their entirety after the IP header (either IPv4 or IPv6) and the L2TPv3 header. Everything comes along for the ride, no cap ✨

                          +-+-+-+-+-+-+-+-+-+-+
                          |        IP         |
                          +-+-+-+-+-+-+-+-+-+-+
                          |      L2TPv3       |
                          +-+-+-+-+-+-+-+-+-+-+
                          | MPLS Label Stack  |
                          +-+-+-+-+-+-+-+-+-+-+
                          |    MPLS Payload   |
                          +-+-+-+-+-+-+-+-+-+-+

                 Figure 2.1 MPLS Packet over L2TPv3/IP

Here's the L2TPv3 encapsulation when it's carrying a single MPLS label stack entry 🧚

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Session ID                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Cookie (optional, maximum 64 bits)...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               ...                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
 |                Label                  | Exp |S|       TTL     | Stack
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

               Figure 2.2 MPLS over L2TPv3 encapsulation

Now the rules 🎀 The L2TPv3 L2-Specific Sublayer MAY be present when you're encapsulating MPLS over L2TPv3. It generally isn't, so it's left out of Figure 2.2. The L2TPv3 Session ID MUST be present. The Cookie MAY be present. 🙈

Session ID 🔑

The L2TPv3 Session ID is a 32-bit identifier field that gets selected locally and works as a lookup key for the context of an L2TP Session. An L2TP Session holds the context needed to process a received L2TP packet. At a minimum, that context says whether the Cookie (more on this below) is present, what value it was assigned, whether an L2TPv3 L2-Specific Sublayer is present along with its type, and what type of tunneled encapsulation follows (for example Frame Relay, Ethernet, MPLS, and so on) 💖

Cookie 🍪

The L2TPv3 Cookie field holds a variable-length value (maximum 64 bits) that's randomly assigned. Its job is to give an extra level of assurance that a data packet was sent to the right L2TP session by the Session ID. The Session ID can be encoded and assigned any value, maybe optimized for local lookups or redirection in a distributed forwarding architecture, but the Cookie MUST be chosen as a cryptographically random value [RFC4086], and it also must not match a recently used value for the same Session ID. A well-chosen Cookie helps stop a stray packet with a recently reused Session ID from being misdirected, stops a Session ID that's been hit by packet corruption from causing trouble, and guards against some specific malicious packet insertion attacks. Section 4 of this document goes into more detail on that 🦋

Label Stack Entry 🏷️

An MPLS label stack entry as defined in [RFC3032].

The optional L2-Specific Sublayer (defined in [RFC3931]) generally isn't present for MPLS over L2TPv3 🌈

Generic IP encapsulation procedures, like fragmentation and MTU considerations, handling of Time to Live (TTL), EXP, and Differentiated Services Code Point (DSCP) bits, and so on, are the same as the "Common Procedures" for IP encapsulation of MPLS defined in Section 5 of [RFC4023]. They aren't repeated here, so go check that one out 💅

3. Assigning the L2TPv3 Session ID and Cookie 🔐

Just like an MPLS label, the L2TPv3 Session ID and Cookie have to be selected and exchanged between the participating nodes before L2TPv3 can operate 🫶 These values might be configured manually or distributed through a signaling protocol. This document only covers encapsulating MPLS over L2TPv3, so how the Session ID and Cookie (if present) get assigned is out of scope ✨

4. Applicability 💜

The methods defined in [RFC4023], [MPLS-IPSEC], and this document all describe ways of carrying MPLS over an IP network. This section talks about when MPLS over L2TPv3 compares to the other options 👑

It's generally simpler to have your border routers refuse to accept an MPLS packet than to configure a router to refuse certain MPLS packets carried in IP or GRE to or from certain IP sources or destinations. So using IP or GRE to carry MPLS packets raises the odds that an MPLS label-spoofing attack will succeed 😭 L2TPv3 adds an extra layer of protection against packet spoofing before a packet is allowed into a Virtual Private Network (VPN). It's a lot like how IPsec adds a layer of protection at a Provider Edge (PE) router instead of relying only on Access Control List (ACL) filters 🦋 Checking the L2TPv3 Cookie is similar to any ACL that inspects the contents of a packet header, except we get the luxury of "seeding" the L2TPv3 header with a value that's super hard to spoof. Iconic 💅

MPLS over L2TPv3 may be advantageous compared to [RFC4023] if:

• Two routers are already "adjacent" over an L2TPv3 tunnel that was set up for some other reason, and they want to exchange MPLS packets over that adjacency 🧚
• Implementation considerations call for MPLS over L2TPv3. For example, a hardware device might be able to take advantage of the L2TPv3 encapsulation for faster or distributed processing ⭐
• Packet spoofing and insertion, service integrity, and resource protection are concerns. This is especially true because an IP tunnel can expose the router to rogue or inappropriate IP packets from unknown or untrusted sources. IP Access Control Lists (ACLs) and numbering methods can protect PE routers from rogue IP sources, but they can be error-prone and annoying to maintain at every edge point all the time 🙈 The L2TPv3 Cookie is a simple way to check the source of an L2TPv3 packet before processing continues. That check adds protection on top of IP ACLs, and it also confirms the Session ID wasn't corrupted in transit or hit an internal lookup error when it was received and processed. If the Cookie gets assigned and distributed automatically, operator error is less of a risk. And if it's chosen in a cryptographically random way, it's harder to blindly guess than source IP addresses, which matters if a hacker can insert packets inside a core network 🔥

(The first two of the above applicability statements were adopted from [RFC4023].)

In summary, L2TPv3 can strike a balance between the limited protection against IP spoofing attacks offered by [RFC4023] and the stronger security, plus the operational and processing overhead, offered by [MPLS-IPSEC] 🌸 MPLS over L2TPv3 may also be faster on some hardware, especially if that hardware is already optimized to classify incoming L2TPv3 packets that carry IP framed in a bunch of different ways. For example, IP encapsulated by High-Level Data Link Control (HDLC) or Frame Relay over L2TPv3 may be about as complex as IP encapsulated by MPLS over L2TPv3 🎀

5. Congestion Considerations 🚦✨

okay so bestie, this section is about not hogging the road 🛣️💅 MPLS can carry a whole bunch of different protocols as payloads, and that matters here 💖

When an MPLS/L2TPv3 flow is carrying IP traffic, the aggregate is assumed to be TCP friendly 🫶 That's because the payload traffic already has its own congestion control built in, so when packets get lost, the sender automatically backs off. Packet loss triggers the reduction in offered load it needs, and no extra congestion avoidance action is necessary 🌸 iykyk, it's the built-in safety net, and it's giving reliable 😭

Now the plot twist 🎀 When an MPLS/L2TPv3 flow carries payload traffic that is not known to be TCP friendly, AND the flow runs across an unprovisioned path that could potentially get congested, the application using this encapsulation MUST employ additional mechanisms to make sure the offered load gets reduced appropriately during congestion 🔥 No skipping this one, periodt 💀 The MPLS/L2TPv3 flow SHOULD NOT exceed the average bandwidth a TCP flow would get across that same path under the same network conditions, measured on a reasonable timescale 🦋

Lowkey the one exception: if it's an unprovisioned path through an over-provisioned network, the congestion risk is basically avoided because there's so much spare room, so this extra step isn't necessary 👑

The TCP comparison isn't an exact science 🧚 It's meant as an "order-of-magnitude" comparison in timescale and throughput, and the timescale for TCP is the roundtrip time of the connection 🍓 Basically, it's NOT acceptable to deploy this on the best-effort Internet if it hogs bandwidth whatever it wants and doesn't compete fairly with TCP within an order of magnitude 🙅‍♀️ One way to figure out an acceptable bandwidth is described in [RFC3448]. Other methods exist too, but they're outside the scope of this doc 💜

---

6. Security Considerations 🔐💀

Real talk, this section is SERIOUS 😭 There are three main concerns when MPLS-labeled traffic goes between PEs over IP tunnels. First, a third party might insert packets into the stream between two PEs. Second, a third party might view the packet stream between two PEs. Third, a third party might alter packets in the stream between two PEs 🙈 How big a deal each one is depends on the security requirements of the applications whose traffic rides the tunnel 💅 Operators can mix and match ways to mitigate the risk, like access lists, authentication, encryption, and context validation 🫶 They SHOULD consider what it costs to mitigate the risk too, because it's not free 💸

Security also comes up in the applicability discussion in Section 4 of this document ✨

6.1. In the Absence of IPsec 🙅‍♀️

So if the tunnels are NOT secured with IPsec, some other method SHOULD be used to make sure packets only get decapsulated and processed by the tunnel tail if the tunnel head actually encapsulated them 🧚 If the tunnel lives entirely inside one administrative domain, address filtering at the boundaries can keep out any packet using a tunnel endpoint's IP address as either source or destination, coming from outside 🌈

BUT 😭 when the tunnel head and tunnel tail are in different administrative domains, that can get really hard, and filtering on the destination address can even become impossible if the packets have to cross the public Internet 💀

Sometimes only source address filtering gets done at the boundaries, and not destination filtering 🙃 If that's the case, the filtering doesn't protect much at all, unless the MPLS over L2TPv3 decapsulator validates the IP source address of the packet 🔥

Also, the "Data Packet Spoofing" considerations in Section 8.2 of [RFC3931] and the "Context Validation" considerations in Section 6.2 of this document both apply 💖 Those two sections show off how good the L2TPv3 Cookie is 🍓

6.2. Context Validation 🎀

Okay, so the L2TPv3 Cookie does NOT give you encryption 🙈 BUT if it's a sufficiently random, 64-bit value that stays secret from an off-path attacker, the Cookie can work as a simple yet effective packet source authentication check 👑 It's quite resistant to brute force packet-spoofing attacks, and it takes the pressure off filter lists of valid source IP addresses 🫶 It also stops attacks that would benefit from spoofing a permitted source IP address 🛡️ The Cookie lets you validate the currently assigned Session ID on the packet flow, which gives you context protection, and it may be considered complementary to securing the tunnel with IPsec ✨

Without cryptographic security on the data plane (like IPsec provides), the Cookie is a simple way to validate the Session ID lookup done on each L2TPv3 packet 🦋 If the Cookie is sufficiently random and stays unknown to an attacker (meaning the attacker can't predict Cookie values or watch traffic between PEs), then it adds an extra layer of protection against malicious spoofed packets inserted at the PE, on top of typical IP address and port ACLs 💅

6.3. Securing the Tunnel with IPsec 🔐🌸

L2TPv3 tunnels can also be secured with IPsec, as specified in Section 4.1.3 of [RFC3931] 🧚 IPsec may provide authentication, privacy protection, integrity checking, and replay protection 💖 The operator may decide these functions are necessary 👑 When using IPsec, the tunnel head and tunnel tail SHOULD be treated as the endpoints of a Security Association 🫶 A single IP address of the tunnel head is used as the source IP address, and a single IP address of the tunnel tail is used as the destination IP address 🦋 How each node learns the other's proper address is outside the scope of this document 🙃 However, if a control protocol is used to set up the tunnels, that control protocol MUST have an authentication mechanism, and it MUST be used when the tunnel is set up 🔥 If the tunnel is set up automatically based on information distributed by BGP, then BGP's Message Digest 5 (MD5)-based authentication mechanism can serve that purpose 🌈

The MPLS over L2TPv3 encapsulated packets SHOULD be considered as originating at the tunnel head and destined for the tunnel tail, so IPsec transport mode SHOULD thus be used 🎀

Now, the tunnel tail and tunnel head are Label Switched Path (LSP) adjacencies (for label distribution adjacencies, see [RFC3031]) 🧚 That means the topmost label of any packet sent through the tunnel MUST be one that the tunnel tail distributed to the tunnel head 🍓 The tunnel tail MUST know precisely which labels it has distributed to the tunnel heads of IPsec-secured tunnels 💅 Labels in that set MUST NOT be distributed by the tunnel tail to any LSP adjacencies other than the tunnel heads of IPsec-secured tunnels 🙅‍♀️ If an MPLS packet arrives without IPsec encapsulation and its topmost label is in that set, the packet MUST be discarded 💀

Securing L2TPv3 with IPsec MUST provide authentication and integrity 🔐 (Note that the authentication and integrity apply to the entire MPLS packet, including the MPLS label stack ✨)

So, the implementation MUST support Encapsulating Security Payload (ESP) with null encryption 🫶 ESP with encryption MAY be supported if a source needs confidentiality 🦋 If ESP is used, the tunnel tail MUST check that the source IP address of any packet received on a given Security Association (SA) is the one expected 👑

Key distribution can be done manually or automatically using the Internet Key Exchange (IKE) Protocol [RFC2409] or IKEv2 [RFC4306] 🗝️ Manual keying MUST be supported 💖 If automatic keying is implemented, IKE in main mode with preshared keys MUST be supported 🌸 A particular application may escalate this requirement and request implementation of automatic keying 🧚 Manual key distribution is much simpler, but also less scalable, than automatic key distribution 🙃 If replay protection is regarded as necessary for a particular tunnel, automatic key distribution SHOULD be configured 🔥

---

7. Acknowledgements 🎀

Big thanks to Robert Raszuk, Clarence Filsfils, and Eric Rosen for reviewing this document 💜🫶 Some text was adopted from [RFC4023] 🌷

8. References 📚

8.1. Normative References

[RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3032]     Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.

[RFC3931]     Lau, J., Townsley, M., and I. Goyret, "Layer Two
              Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
              March 2005.

[RFC4023]     Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
              MPLS in IP or Generic Routing Encapsulation (GRE)", RFC
              4023, March 2005.

[RFC4086]     Eastlake, D., 3rd, Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC
              4086, June 2005.

8.2. Informative References

[MPLS-IPSEC]  Rosen, E., De Clercq, J., Paridaens, O., T'Joens, Y.,
              and C. Sargor, "Architecture for the Use of PE-PE IPsec
              Tunnels in BGP/MPLS IP VPNs", Work in Progress, August
              2005.

[RFC3031]     Rosen, E., Viswanathan, A., and R. Callon,
              "Multiprotocol Label Switching Architecture", RFC 3031,
              January 2001.

[RFC2409]     Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

[RFC4306]     Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

[RFC3448]     Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
              Friendly Rate Control (TFRC): Protocol Specification",
              RFC 3448, January 2003.

Authors' Addresses

W. Mark Townsley
Cisco Systems
USA

Phone: +1-919-392-3741
EMail: mark@townsley.net


Carlos Pignataro
Cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
USA

Phone: +1-919-392-7428
EMail: cpignata@cisco.com


Scott Wainner
Cisco Systems
13600 Dulles Technology Drive
Herndon, VA 20171
USA

EMail: swainner@cisco.com


Ted Seely
Sprint Nextel
12502 Sunrise Valley Drive
Reston, VA 20196
USA

Phone: +1-703-689-6425
EMail: tseely@sprint.net


Jeff Young

EMail: young@jsyoung.net

Full Copyright Statement ✨

okay so this part is the legal fine print at the end 🫶 but it's still important, so I'm keeping every bit of it!! The copyright is (C) The IETF Trust (2007) 💜

This document is subject to the rights, licenses, and restrictions in BCP 78. Except for what BCP 78 says, the authors keep all their rights 🎀

The document and everything in it is given to you "AS IS" 🙈 THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE all say NO to every warranty, whether it's stated or implied. That includes no promise that using the info won't infringe anyone's rights, and no implied promise of merchantability or fitness for a particular purpose 💀

---

Intellectual Property ✨

ngl this one is kinda dramatic, but here's the tea 🍓 The IETF doesn't take a side on whether any Intellectual Property Rights (or other rights) that someone claims about the tech in this document are valid, how far they reach, or whether a license for them is even available. It also doesn't claim it did any independent digging to find those rights 🧚

If you want the details on how rights work for RFC documents, check out BCP 78 and BCP 79 📚

Copies of IPR disclosures sent to the IETF Secretariat are in the IETF online IPR repository at http://www.ietf.org/ipr. That's also where you'll find any assurances that licenses will be made available, along with the result of any attempt to get a general license or permission for implementers or users to use those proprietary rights 💅

The IETF is also inviting anyone to say something if they know of copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 🌸

---

Acknowledgement ✨

The RFC Editor function is funded right now by the Internet Society 🫶💜