RFC 7510
Encapsulating MPLS in UDP
Encapsulating MPLS in UDP 💖
Title block vibes: this one is an Internet Standards Track doc 🎀, published in April 2015 🌸 and written by X. Xu (Huawei Technologies), N. Sheth (Juniper Networks), L. Yong (Huawei USA), R. Callon (Juniper Networks), and D. Black (EMC Corporation). It's RFC 7510 with ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so there's no backstory there. ✨
Abstract ✨
okay so this doc defines an IP-based encapsulation for MPLS called MPLS-in-UDP 🦋. You'd reach for it when UDP encapsulation is the move instead of plain MPLS, like when you want UDP-based ECMP (Equal-Cost Multipath) or link aggregation to work its magic 💅. The catch: MPLS-in-UDP has to be deployed inside a single network (one network operator) or a group of adjacent cooperating operators who manage their traffic to avoid congestion. It is NOT for the open Internet, where congestion control is required 🙈. There are also usage limits for MPLS-in-UDP traffic that isn't congestion controlled, and for UDP zero checksums with IPv6 ⚠️.
Status of This Memo 📜
this is an Internet Standards Track document 🔥.
It's a product of the Internet Engineering Task Force (IETF), so it represents IETF community consensus 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. For more on Internet Standards, check 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/rfc7510 💜.
Copyright Notice 🎀
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 💅.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Read these carefully, bestie, because they spell out your rights and restrictions for this document 🙈. Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🌈.
Table of Contents 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Existing Encapsulations . . . . . . . . . . . . . . . . . 3
1.2. Motivations for MPLS-in-UDP Encapsulation . . . . . . . . 4
1.3. Applicability Statements . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Encapsulation in UDP . . . . . . . . . . . . . . . . . . . . 5
3.1. UDP Checksum Usage with IPv6 . . . . . . . . . . . . . . 6
3.2. Middlebox Considerations for IPv6 UDP Zero Checksums . . 10
4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 10
5. Congestion Considerations . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 191. Introduction ✨
okay so this doc specifies an IP-based encapsulation for MPLS, i.e., MPLS-in-UDP 🦋. It fits situations where an IP-based encapsulation for MPLS is required and you also need fine-grained load balancing of MPLS packets over IP networks using Equal-Cost Multipath (ECMP) and/or Link Aggregation Groups (LAGs) 💖. Other IP-based encapsulations for MPLS already do fine-grained load balancing with a special entropy field in their header. MPLS-in-UDP is still a glow-up, though, because networks have been using UDP port number fields for load balancing for a long time 🌸.
Like the other IP-based MPLS encapsulations, this one lets two Label Switching Routers (LSR) be adjacent on a Label Switched Path (LSP) even though an IP network sits between them 🧚. To make it work, each LSR needs to know that its remote LSRs can decapsulate MPLS-in-UDP 🫶. This spec only covers the data-plane encapsulation and doesn't get into how that knowledge is shared. The capability can be manually configured on each LSR or advertised dynamically, and those methods are outside this document's scope 💅.
Also, the MPLS-in-UDP encapsulation format by itself can't guarantee integrity and privacy for data packets moving through MPLS-in-UDP tunnels, and it can't let tunnel decapsulators authenticate the tunnel encapsulator 🙈. So if any of those security issues matter to you, MPLS-in-UDP SHOULD be secured with IPsec [RFC4301] or Datagram Transport Layer Security (DTLS) [RFC6347] 🔐. For more details, see Section 6 (Security Considerations) 💜.
1.1. Existing Encapsulations 🍓
Right now there are several IP-based encapsulations for MPLS, like MPLS-in-IP, MPLS-in-GRE (Generic Routing Encapsulation) [RFC4023], and MPLS-in-L2TPv3 (Layer 2 Tunneling Protocol Version 3) [RFC4817] 🌈. In all of them, the IP addresses can vary to get load balancing ✨.
All of these IP-based encapsulations for MPLS are specified for both IPv4 and IPv6 💅. With IPv6-based encapsulations, the IPv6 Flow Label can be used for ECMP and LAGs [RFC6438] 🦋. IPv4 headers, though, have no entropy field like that 🙈.
For MPLS-in-GRE and MPLS-in-L2TPv3, the protocol fields (the GRE Key and the L2TPv3 Session ID, respectively) can serve as the load-balancing key, as described in [RFC5640] 🎀. For that to work, intermediate routers need to understand those fields in the context of being load-balancing keys 👀.
1.2. Motivations for MPLS-in-UDP Encapsulation 💖
Most existing routers in IP networks can already spread IP traffic "microflows" [RFC2474] across ECMPs and/or LAGs by hashing the five-tuple of UDP [RFC768] and TCP packets (source IP address, destination IP address, source port, destination port, and protocol) 🔥. So if you encapsulate MPLS packets in a UDP tunnel and use the UDP header's source port as an entropy field, that existing load-balancing power carries over to give fine-grained load balancing of MPLS traffic over IP networks 🫶. Main character energy 👑.
1.3. Applicability Statements 🚧
Here's the big rule 🙈. The MPLS-in-UDP encapsulation technology MUST only be deployed within a single network (with a single network operator) or across networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion. It is NOT meant for the Internet, where congestion control is required 🚫. On top of that, packet filters SHOULD be added so MPLS-in-UDP packets can't escape the network because of misconfiguration or packet errors 🛡️.
2. Terminology 📖
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 RFC 2119 [RFC2119] 🎀. Those are the capitalized keywords with the special meaning, bestie, so keep an eye out for them 👀✨.
3. Encapsulation in UDP ✨
okay so bestie, here's the MPLS-in-UDP packet layout 🎀 it's giving neat rows of fields 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = Entropy | Dest Port = MPLS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MPLS Label Stack ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
~ Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Source Port of UDP
this field holds a 16-bit entropy value 🦋 the encapsulator makes it up so it can tell one flow apart from another. what counts as a flow is up to the encapsulator locally, so that's out of scope for this doc. same goes for how the encapsulator actually cooks up the entropy value 🙈
in case the tunnel doesn't need entropy, every packet in a given flow SHOULD carry the same randomly picked constant value, so the packets don't get shuffled out of order 🌸
now the port range thing 👑 the source port is supposed to land between 49152 and 65535, because ports under 49152 are reserved by IANA for specific apps and protocols. so instead of a full 16-bit hash, the encapsulator SHOULD compute a 14-bit hash and drop those 14 bits into the least significant bits of the source port field. the most significant two bits SHOULD be set to binary 11 💜 that still gives you 14 bits of entropy, which is plenty in practice, ngl ✨
Destination Port of UDP
this one is always the same 🧚 it's set to 6635, which IANA gave us to say "hey, the UDP payload is an MPLS packet" 🎀
UDP Length
this field works the way the UDP spec says it does, per [RFC768] 🍓
UDP Checksum
okay this is the spicy one 🌶️ for IPv4, this field is RECOMMENDED to be set to zero. why? for performance or implementation reasons, because the IPv4 header already has a checksum and the UDP checksum is optional with IPv4 anyway. the exception is if checksum protection of VPN labels matters to you 💀 (see Section 6 for that)
for IPv6 it's a whole different vibe 😭 the IPv6 header has no checksum, so this field MUST contain a UDP checksum, and it MUST be used as specified in [RFC768] and [RFC2460], unless one of the exceptions that lets you use UDP zero-checksum mode (from [RFC6935]) applies. check Section 3.1 for those exceptions and the extra requirements that kick in when zero-checksum mode is used for MPLS-in-UDP traffic over IPv6 🫶
MPLS Label Stack
this field holds an MPLS Label Stack as defined in [RFC3032] 💖
Message Body
and last but not least, this field holds one MPLS message body 🌈
3.1. UDP Checksum Usage with IPv6 ✨
Okay so, when UDP runs over IPv6, the UDP checksum is the thing protecting both the IPv6 and UDP headers from getting corrupted 🛡️ It MUST be used unless the requirements in [RFC6935] and [RFC6936] for using UDP zero-checksum mode with a tunnel protocol are satisfied. MPLS-in-UDP is a tunnel protocol, and MPLS-in-IPv6 without UDP (so, without a checksum covering the IPv6 header or the MPLS label stack) is already deployed successfully and it's honestly iconic 💅 Section 3.1 of [RFC6936] explains it:
There is extensive experience with deployments using tunnel protocols in well-managed networks (e.g., corporate networks and service provider core networks). This has shown the robustness of methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS that do not employ a transport protocol checksum and that have not specified mechanisms to protect from corruption of the unprotected headers (such as the VPN Identifier in MPLS).
Now the main rule 🎀 The UDP checksum MUST be implemented and MUST be used according to [RFC768] and [RFC2460] for MPLS-in-UDP traffic over IPv6, UNLESS one or more of the exceptions below applies AND the extra requirements further down are followed. There are three exceptions that let you use UDP zero-checksum mode for IPv6 with MPLS-in-UDP, and they're subject to the additional requirements stated later in this section. The three are:
- a. Using MPLS-in-UDP in networks under single administrative control (like inside one operator's network) where it's known (maybe from knowing the equipment types and lower-layer checks) that packet corruption is exceptionally unlikely, AND the operator is willing to take the risk of undetected packet corruption. 🫶
- b. Using MPLS-in-UDP in networks under single administrative control (like inside one operator's network) where it's judged through observational measurements (maybe historic or current traffic flows that use a non-zero checksum) that the level of packet corruption is tolerably low, AND the operator is willing to take the risk of undetected packet corruption. 📊
- c. Using MPLS-in-UDP to deliver traffic for applications that are tolerant of misdelivered or corrupted packets (maybe through a higher-layer checksum, validation, and retransmission or transmission redundancy), AND the operator is willing to rely on the applications using the tunnel to survive any corrupt packets. 🌈
These exceptions can also stretch to a set of closely cooperating network administrations (like operators who have agreed to work together to jointly provide specific services) 🤝 Even when one of the exceptions above applies, using UDP checksums may be appropriate when VPN services are provided over MPLS-in-UDP. See Section 6.
So, for IPv6, the UDP checksum for MPLS-in-UDP MUST be used as specified in [RFC768] and [RFC2460] for tunnels that span multiple networks whose administrations don't cooperate closely. This still holds even if each non-cooperating administration separately meets one or more of the exceptions for UDP zero-checksum mode with MPLS-in-UDP over IPv6 🙅♀️
Here are the extra requirements for implementing and using UDP zero-checksum mode for MPLS-in-UDP over IPv6. Pay attention, bestie 👀
- a. Using the UDP checksum with IPv6 MUST be the default configuration of all MPLS-in-UDP implementations.
- b. The MPLS-in-UDP implementation MUST comply with all requirements specified in Section 4 of [RFC6936] and with requirement 1 specified in Section 5 of [RFC6936].
- c. The tunnel decapsulator SHOULD only allow UDP zero-checksum mode for IPv6 on a single received UDP Destination Port, regardless of the encapsulator. The reason for this is possible corruption of the UDP Destination Port, which could send packets to the wrong UDP port. If that other UDP port requires the UDP checksum, the misdelivered packet will be discarded
- d. The tunnel decapsulator MUST check that the source and destination IPv6 addresses are valid for the MPLS-in-UDP tunnel the packet was received on, if that tunnel uses UDP zero-checksum mode, and discard any packet where this check fails. 🚫
- e. The tunnel encapsulator SHOULD use different IPv6 addresses for each MPLS-in-UDP tunnel that uses UDP zero-checksum mode (regardless of decapsulator), so the decapsulator's check on the IPv6 source address is stronger. In other words, the same IPv6 source address SHOULD NOT be used with more than one IPv6 destination address, whether that destination is unicast or multicast. When this isn't possible, it is RECOMMENDED to use each source IPv6 address for as few UDP zero-checksum mode MPLS-in-UDP tunnels (i.e., with as few destination IPv6 addresses) as is feasible. 🧚
- f. Any middlebox support for MPLS-in-UDP with UDP zero-checksum mode for IPv6 MUST comply with requirements 1 and 8-10 in Section 5 of [RFC6936].
- g. Measures SHOULD be taken to stop IPv6 traffic with zero UDP checksums from "escaping" to the general Internet. See Section 5 for examples of such measures. 🙈
- h. IPv6 traffic with zero UDP checksums MUST be actively monitored for errors by the network operator. 👀
The above requirements don't change the requirements in [RFC2460] as modified by [RFC6935], or the requirements in [RFC6936], so nothing there is getting overwritten 📜
Checking the source IPv6 address as well as the destination, plus the strong recommendation against reusing source IPv6 addresses across MPLS-in-UDP tunnels, together give some protection against the lack of UDP checksum coverage of the IPv6 header. On top of that, the MPLS data plane only forwards packets with valid labels (labels that the tunnel egress LSR has distributed), so there's an extra chance to catch a misdelivered MPLS-in-UDP packet when it carries a label that isn't valid for forwarding at the receiving LSR. The expected result for IPv6 UDP zero-checksum mode with MPLS-in-UDP is that corruption of the destination IPv6 address will usually cause a packet discard, because offsetting corruptions to the source IPv6 address and/or the MPLS top label are unlikely. The exceptions above also limit IPv6 UDP zero-checksum mode to well-managed networks where MPLS packet corruption hasn't been a problem in practice, which gives extra assurance ✨
So, MPLS-in-UDP is suitable for transmission over lower layers in the well-managed networks allowed by the exceptions above, and the rate of corruption of the inner IP packet on those networks isn't expected to go up compared to MPLS traffic that isn't encapsulated in UDP. For these reasons, MPLS-in-UDP does not provide an additional integrity check when UDP zero-checksum mode is used with IPv6, and this design follows requirements 2, 3, and 5 in Section 5 of [RFC6936] 🦋
MPLS doesn't accumulate incorrect state because of label stack corruption. A corrupt MPLS label leads either to packet discard or to forwarding (and forgetting) the packet, without MPLS protocol state building up. Active monitoring of MPLS-in-UDP traffic for errors is REQUIRED, because errors will leave some error information building up outside the MPLS protocol for operational and management purposes. This design follows requirement 4 in Section 5 of [RFC6936] 🔍
The other requirements in Section 5 of [RFC6936] don't apply to MPLS-in-UDP. Requirements 6 and 7 don't apply because MPLS doesn't have an MPLS-generic control feedback mechanism. Requirements 8-10 are middlebox requirements that don't apply to MPLS-in-UDP tunnel endpoints, but see Section 3.2 for more middlebox discussion 🍓
In summary, UDP zero-checksum mode for IPv6 is allowed with MPLS-in-UDP when one of the three exceptions above applies, as long as the additional requirements in this section are followed. Otherwise, the UDP checksum MUST be used for IPv6 as specified in [RFC768] and [RFC2460]. 💖
All of this section and its requirements only apply to using UDP zero-checksum mode for IPv6. You can skip all of it by using the UDP checksum as specified in [RFC768] and [RFC2460] 🌸
3.2. Middlebox Considerations for IPv6 UDP Zero Checksums 🚧
IPv6 datagrams with a zero UDP checksum won't get through any middlebox that validates the checksum based on [RFC2460] or that updates the UDP checksum field, like NATs or firewalls 😭 Changing that would mean updating those middleboxes so they can correctly handle datagrams with zero UDP checksums. MPLS-in-UDP doesn't give you a way to safely fall back to using a checksum when a path change sends a tunnel over a path that includes a middlebox discarding IPv6 datagrams with a zero UDP checksum. If that happens, the MPLS-in-UDP tunnel gets black-holed by that middlebox 🕳️ The recommended changes so firewalls, NATs, and other middleboxes can support IPv6 zero UDP checksums are described in Section 5 of [RFC6936] 💜
4. Processing Procedures ✨
okay so this MPLS-in-UDP encapsulation is what lets MPLS packets get forwarded through "UDP tunnels" 🦋 it's giving tunnel glow-up. When the encapsulator does the MPLS-in-UDP encapsulation, it generates the entropy value itself and fills it into the Source Port field of the UDP header 🫶. The Destination Port field gets set to 6635, which IANA allocated to say "this UDP tunnel payload is an MPLS packet" 💖. As for whether the top label of the encapsulated MPLS packet is downstream-assigned or upstream-assigned, that depends on the criteria below, which are compatible with [RFC5332] so no drama ✨
a. If the tunnel destination IP address is a unicast address, the top label MUST be downstream-assigned;
b. If the tunnel destination IP address is an IP multicast address, either all encapsulated MPLS packets in the particular tunnel have a downstream-assigned label at the top of the stack, or all encapsulated MPLS packets in that tunnel have an upstream-assigned label at the top of the stack. The means by which this is determined for a particular tunnel is outside the scope of this specification. In the absence of any knowledge about a specific tunnel, the label SHOULD be presumed to be upstream-assigned.
Intermediate routers, once they receive these UDP encapsulated packets, could balance them based on the hash of the five-tuple of the UDP packets 🌸 Then, when the decapsulator gets these UDP-encapsulated packets, it removes the UDP headers and processes them accordingly. For the other common processing stuff that goes with tunneling encapsulation, including but not limited to Maximum Transmission Unit (MTU) and preventing fragmentation and reassembly, Time to Live (TTL), and differentiated services, the corresponding "Common Procedures" from [RFC4023] SHOULD be followed. Those apply to MPLS-in-IP and MPLS-in-GRE encapsulation formats too 🧚
Note: Each UDP tunnel is unidirectional, because MPLS-in-UDP traffic is sent to the IANA-allocated UDP Destination Port and is never sent back to any port used as a UDP Source Port (which only serves as a source of entropy) 🙈 This is at odds with the typical middlebox (e.g., firewall) assumption that bidirectional traffic uses a common pair of UDP ports. As a result, getting bidirectional MPLS-in-UDP traffic through middleboxes may require separate configuration for each direction of traffic.
5. Congestion Considerations ✨
Section 3.1.3 of [RFC5405] talks about the congestion implications of UDP tunnels 💅 As [RFC5405] discusses, other flows can share the path with one or more UDP tunnels, so congestion control [RFC2914] needs to be considered.
A major motivation for encapsulating MPLS in UDP is to improve the use of multipath (such as ECMP) when traffic is going to traverse routers that can hash on UDP Port and IP address 🔥 So in lots of cases this may reduce congestion and improve usage of the available network capacity. However, the network (including the applications that use it) also needs to respond appropriately in harder cases, like when link or equipment failures have reduced the available capacity 😭
The impact of congestion has to be considered two ways: how a UDP tunnel that's hogging excessive capacity affects the rest of the network, and how it affects the flows using the UDP tunnels 👑 The potential impact of congestion from a UDP tunnel depends on what sort of traffic is carried over the tunnel, plus the path of the tunnel.
MPLS is widely used to carry a huge range of traffic ✨ In many cases, MPLS is used to carry IP traffic. IP traffic is generally assumed to be congestion controlled, so a tunnel carrying general IP traffic (the kind you'd expect to cross the Internet) generally doesn't need extra congestion control mechanisms. As [RFC5405] specifies:
IP-based traffic is generally assumed to be congestion-controlled, i.e., it is assumed that the transport protocols generating IP- based traffic at the sender already employ mechanisms that are sufficient to address congestion on the path. Consequently, a tunnel carrying IP-based traffic should already interact appropriately with other traffic sharing the path, and specific congestion control mechanisms for the tunnel are not necessary.
So where MPLS-in-UDP tunneling is used to carry IP traffic that's known to be congestion controlled, the UDP tunnels MAY be used within a single network or across multiple networks, with cooperating network operators 🎀 Internet IP traffic is generally assumed to be congestion controlled. Similarly, in general, Layer 3 VPNs carry IP traffic that is similarly assumed to be congestion controlled.
Whether or not Layer 2 VPN traffic is congestion controlled may depend on the specific services being offered and what use is being made of the Layer 2 services 🤔
BUT MPLS is also used in lots of cases to carry traffic that is NOT necessarily congestion controlled 😬 For example, MPLS may be used to carry pseudowire or VPN traffic where specific bandwidth guarantees are provided to each pseudowire or to each VPN.
In those cases, network operators may avoid congestion by carefully provisioning their networks, by rate limiting user data traffic, and/or by using MPLS Traffic Engineering (MPLS-TE) to assign specific bandwidth guarantees to each LSP 🍓 Where MPLS is carried over UDP over IP, the identity of each individual MPLS flow is lost, in general, and MPLS-TE can't be used to guarantee bandwidth to specific flows (since many LSPs may be multiplexed over a single UDP tunnel, and many UDP tunnels may be mixed in an IP network).
So, where the MPLS traffic is not congestion controlled, MPLS-in-UDP tunnels MUST only be used within a single operator's network that uses careful provisioning (e.g., rate limiting at the entries of the network while over-provisioning network capacity) to ensure against congestion, or within a limited number of networks whose operators closely cooperate to jointly provide this same careful provisioning 🫶
Which means MPLS-in-UDP MUST NOT be used over the general Internet, or over non-cooperating network operators, to carry traffic that is not congestion controlled 💀
Measures SHOULD be taken to stop non-congestion-controlled MPLS-in-UDP traffic from "escaping" onto the general Internet, e.g.:
a. Physical or logical isolation of the links carrying MPLS-over-UDP from the general Internet.
b. Deployment of packet filters that block the UDP Destination Ports used for MPLS-over-UDP.
c. Imposition of restrictions on MPLS-in-UDP traffic by software tools used to set up MPLS-in-UDP tunnels between specific end systems (as might be used within a single data center).
d. Use of a "Managed Circuit Breaker" for the MPLS traffic as described in [CIRCUIT-BREAKER].
6. Security Considerations ✨
Okay bestie, this part is SERIOUS 🚨 The security problems faced with the MPLS-in-UDP tunnel are exactly the same as the ones faced with MPLS-in-IP and MPLS-in-GRE tunnels [RFC4023]. In other words, the MPLS-in-UDP tunnel as defined in this document can't, by itself, ensure the integrity and privacy of data packets transported through it, and it can't let the tunnel decapsulator authenticate the tunnel encapsulator 😱 For any of the above security issues, the MPLS-in-UDP tunnel SHOULD be secured with IPsec or DTLS.
IPsec was designed as a network security mechanism, so it lives at the network layer 🧱 That means if the tunnel is secured with IPsec, the UDP header would no longer be visible to intermediate routers, in either IPsec tunnel or transport mode. And then the whole point of picking MPLS-in-UDP over MPLS-in-GRE or MPLS-in-IP is lost 💔 DTLS, by comparison, is better suited for application security and can better preserve network- and transport-layer protocol information 🫧 Specifically, if DTLS is used, the destination port of the UDP header MUST be set to the IANA-assigned value 6636 (indicating MPLS-in-UDP with DTLS), and that UDP port MUST NOT be used for other traffic. The UDP Source Port field can still be used to add entropy, e.g., for load-sharing purposes ✨ DTLS usage is limited to a single DTLS session for any specific tunnel encapsulator/decapsulator pair (identified by source and destination IP addresses). Both IP addresses MUST be unicast addresses, because multicast traffic is not supported when DTLS is used 🙅♀️ An MPLS-in-UDP tunnel decapsulator implementation that supports DTLS is expected to be able to establish DTLS sessions with multiple tunnel encapsulators. Likewise, an MPLS-in-UDP tunnel encapsulator implementation is expected to be able to establish DTLS sessions with multiple decapsulators. (However, different source and/or destination IP addresses may be involved. See Section 3.1 for discussion of one situation where using different source IP addresses is important 🌈)
If the tunnel is NOT secured with IPsec or DTLS, some other method should be used to make sure packets are decapsulated and forwarded by the tunnel tail ONLY if those packets were encapsulated by the tunnel head 🔒 If the tunnel lies entirely within a single administrative domain, address filtering at the boundaries can be used to ensure that no packet with the IP source address of a tunnel endpoint, or with the IP destination address of a tunnel endpoint, can enter the domain from outside. However, when the tunnel head and tunnel tail are NOT in the same administrative domain, this may become difficult, and filtering based on the destination address can even become impossible if the packets must traverse the public Internet 😵 Sometimes only source address filtering (but not destination address filtering) is done at the boundaries of an administrative domain. If that's the case, the filtering doesn't provide effective protection at all unless the decapsulator of an MPLS-in-UDP validates the IP source address of the packet.
This document does not require that the decapsulator validate the IP source address of the tunneled packets (with the exception that the IPv6 source address MUST be validated when UDP zero-checksum mode is used with IPv6) 🧐 But it should be understood that failing to validate it presupposes that there is effective destination-based (or a combination of source-based and destination-based) filtering at the boundaries. MPLS-based VPN services rely on a VPN label in the MPLS label stack to identify the VPN. Corruption of that label could leak traffic across VPN boundaries 🚫 Such leakage is highly undesirable when inter-VPN isolation is used for privacy or security reasons. When that's the case, UDP checksums SHOULD be used for MPLS-in-UDP with both IPv4 and IPv6, and in particular, UDP zero-checksum mode SHOULD NOT be used with IPv6 🔐 Each UDP checksum covers the VPN label, which gives you increased assurance of isolation among VPNs 💜
7. IANA Considerations ✨
okay so IANA gave MPLS two UDP destination port numbers, one for plain MPLS-in-UDP and one for the DTLS version 💅 both registrations point back to RFC 7510 🎀
One UDP destination port number indicating MPLS has been allocated by
IANA:
Service Name: MPLS-UDP
Transport Protocol(s): UDP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>.
Description: Encapsulate MPLS packets in UDP tunnels.
Reference: RFC 7510
Port Number: 6635
One UDP destination port number indicating MPLS with DTLS has been
allocated by IANA:
Service Name: MPLS-UDP-DTLS
Transport Protocol(s): UDP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>.
Description: Encapsulate MPLS packets in UDP tunnels with DTLS.
Reference: RFC 7510
Port Number: 66368. References 📚
8.1. Normative References 💖
these are the sources the spec genuinely can't function without, so they're the must-reads 🧚
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005,
<http://www.rfc-editor.org/info/rfc4301>.
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter,
"MPLS Multicast Encapsulations", RFC 5332, August 2008,
<http://www.rfc-editor.org/info/rfc5332>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405, November
2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012,
<http://www.rfc-editor.org/info/rfc6347>.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935, April 2013,
<http://www.rfc-editor.org/info/rfc6935>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, April 2013,
<http://www.rfc-editor.org/info/rfc6936>.8.2. Informative References 🦋
these ones are more like bonus reading, super helpful for context but not strictly required 🍓
[CIRCUIT-BREAKER]
Fairhurst, G., "Network Transport Circuit Breakers", Work
in Progress, draft-ietf-tsvwg-circuit-breaker-01, April
2015.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000,
<http://www.rfc-editor.org/info/rfc2914>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, March 2005,
<http://www.rfc-editor.org/info/rfc4023>.
[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>.
[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-
Balancing for Mesh Softwires", RFC 5640, August 2009,
<http://www.rfc-editor.org/info/rfc5640>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, November 2011,
<http://www.rfc-editor.org/info/rfc6438>.Acknowledgements 🫶
huge thank-you to everyone who dropped valuable comments and suggestions on this document, you literally made it better 🥰
Thanks to Shane Amante, Dino Farinacci, Keshava A K, Ivan Pepelnjak,
Eric Rosen, Andrew G. Malis, Kireeti Kompella, Marshall Eubanks,
George Swallow, Loa Andersson, Vivek Kumar, Stewart Bryant, Wen
Zhang, Joel M. Halpern, Noel Chiappa, Scott Brim, Alia Atlas,
Alexander Vainshtein, Joel Jaeggli, Edward Crabbe, Mark Tinka, Lars
Eggert, Joe Touch, Lloyd Wood, Gorry Fairhurst, Weiguo Hao, Mark
Szczesniak, Stephen Farrell, Martin Stiemerling, Zhenxiao Liu, and
Xing Tong for their valuable comments and suggestions on this
document.
Special thanks to Alia Atlas for her insightful suggestion of adding
an applicability statement.
Thanks to Daniel King, Gregory Mirsky, and Eric Osborne for their
valuable MPLS-RT reviews on this document. Thanks to Charlie Kaufman
for his SecDir review of this document. Thanks to Nevil Brownlee for
the OPS-Dir review of this document. Thanks to Roni Even for the
Gen-ART review of this document. Thanks to Pearl Liang for the IANA
review of this document.Contributors 🌸
these folks put in serious work on the document 💜 contributors are listed alphabetically by last name, so no drama about who goes first 💅
Yongbing Fan
China Telecom
EMail: fanyb@gsta.com
Adrian Farrel
Juniper Networks
EMail: adrian@olddog.co.uk
Zhenbin Li
Huawei Technologies
EMail: lizhenbin@huawei.com
Carlos Pignataro
Cisco Systems
EMail: cpignata@cisco.com
Curtis Villamizar
Outer Cape Cod Network Consulting, LLC
EMail: curtis@occnc.comAuthors' Addresses 🦋
and finally, where to find the authors. the contact details are below 🎀
Xiaohu Xu
Huawei Technologies
No.156 Beiqing Rd
Beijing 100095
China
Phone: +86-10-60610041
EMail: xuxiaohu@huawei.com
Nischal Sheth
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
United States
EMail: nsheth@juniper.net
Lucy Yong
Huawei USA
EMail: Lucy.yong@huawei.com
Ross Callon
Juniper Networks
EMail: rcallon@juniper.net
David Black
EMC Corporation
176 South Street
Hopkinton, MA 01748
United States
EMail: david.black@emc.com📦 where this page comes from
- ietf: rfc7510 2015-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms