Encapsulating MPLS in UDP
Extracted elements (29)
IPsec is a less suitable security option because it hides the UDP header from intermediate routers (in both tunnel and transport mode), negating the load-balancing benefit that motivates MPLS-in-UDP. DTLS is preferred because it preserves network- and transport-layer header visibility for intermediaries.
MPLS-in-UDP is motivated by the fact that most existing routers already perform five-tuple (source IP, destination IP, source port, destination port, protocol) load-balancing for UDP/TCP, so using the UDP source port as an entropy field enables fine-grained ECMP and LAG distribution without requiring router upgrades.
Each MPLS-in-UDP tunnel is strictly unidirectional: traffic is always directed to destination port 6635 and never sent back to the ephemeral source port. This contradicts the common middlebox assumption of bidirectional UDP traffic on a symmetric port pair, requiring separate per-direction configuration to traverse firewalls and NATs.
IPv6 datagrams with a zero UDP checksum will be discarded by any middlebox (NAT, firewall) that validates checksums per RFC 2460 or rewrites the UDP checksum. MPLS-in-UDP provides no fallback mechanism when a path change routes traffic through such a middlebox, resulting in a black hole.
Any middlebox support for MPLS-in-UDP with IPv6 UDP zero-checksum mode MUST comply with requirements 1 and 8–10 in Section 5 of RFC 6936.
For IPv4, the UDP checksum is RECOMMENDED to be set to zero for performance or implementation reasons, since the IPv4 header already includes a checksum and UDP checksum use is optional, unless checksum protection of VPN labels is important.
For IPv6, the UDP checksum MUST be implemented and MUST be used as specified in RFC 768 and RFC 2460 for MPLS-in-UDP traffic unless one of the three defined exceptions for UDP zero-checksum mode applies and all additional requirements in Section 3.1 are satisfied.
For multicast tunnel destinations, all encapsulated MPLS packets within a given tunnel must consistently use either downstream-assigned or upstream-assigned top labels; in the absence of specific knowledge, the label SHOULD be presumed upstream-assigned.
For unicast tunnel destination addresses, the top MPLS label MUST be downstream-assigned, in accordance with RFC 5332.
IPv6 traffic with zero UDP checksums MUST be actively monitored for errors by the network operator, and measures SHOULD be taken to prevent such traffic from escaping to the general Internet.
Measures SHOULD be taken to prevent non-congestion-controlled MPLS-in-UDP traffic from escaping to the general Internet, such as physical/logical isolation of links, packet filters on UDP destination port 6635, software-based tunnel restrictions, or a managed circuit breaker.
MPLS-in-UDP MUST NOT be used over the general Internet or across non-cooperating network operators to carry traffic that is not congestion controlled.
MPLS-in-UDP MUST only be deployed within a single network (single operator) or networks of a closely cooperating adjacent set of operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required.
Packet filters SHOULD be added to prevent MPLS-in-UDP packets from escaping the network due to misconfiguration or packet errors.
The common processing procedures from RFC 4023 covering MTU/fragmentation prevention, TTL handling, and differentiated services for MPLS-in-IP and MPLS-in-GRE SHOULD be followed for MPLS-in-UDP as well.
The tunnel encapsulator SHOULD use a distinct IPv6 source address for each MPLS-in-UDP tunnel that uses UDP zero-checksum mode, to strengthen the decapsulator's source-address check; the same source address SHOULD NOT be reused across multiple destination addresses.
The UDP Destination Port field MUST be set to the IANA-allocated value 6635 (service name MPLS-UDP) to indicate that the UDP tunnel payload is an MPLS packet.
To keep the source port in the range 49152–65535, the encapsulator SHOULD calculate a 14-bit hash and set the two most significant bits to binary 11, placing the result in the least-significant 14 bits of the source port field.
Use of the UDP checksum with IPv6 MUST be the default configuration of all MPLS-in-UDP implementations; UDP zero-checksum mode is an explicit opt-in subject to additional requirements.
When a tunnel uses UDP zero-checksum mode with IPv6, the tunnel decapsulator MUST verify that the source and destination IPv6 addresses are valid for that tunnel and MUST discard any packet failing this check.
When DTLS is used to secure MPLS-in-UDP, the UDP Destination Port MUST be set to the IANA-assigned value 6636 (MPLS-UDP-DTLS) and MUST NOT be used for other traffic; both source and destination IP addresses MUST be unicast — multicast is not supported with DTLS.
Where MPLS-in-UDP carries congestion-controlled IP traffic, the tunnels MAY be used within a single network or across cooperating networks. Where MPLS traffic is not congestion controlled, tunnels MUST only be used within a single operator's carefully provisioned network or among closely cooperating operators.
The UDP Source Port field carries a 16-bit entropy value generated by the encapsulator to uniquely identify a flow for load-balancing purposes. When no entropy is needed, the field SHOULD be set to a randomly selected constant for all packets in a given flow to avoid packet reordering.
IANA allocated UDP destination port 6635 (service name MPLS-UDP) to indicate that the UDP tunnel payload is an MPLS packet, as defined by this document.
IANA allocated UDP destination port 6636 (service name MPLS-UDP-DTLS) to indicate MPLS packets encapsulated in UDP tunnels secured with DTLS, as defined by this document.
Corruption of the VPN label in the MPLS label stack can cause traffic to leak across VPN boundaries. When inter-VPN isolation is used for privacy or security, UDP checksums SHOULD be used for both IPv4 and IPv6 MPLS-in-UDP, and UDP zero-checksum mode SHOULD NOT be used with IPv6.
The MPLS-in-UDP encapsulation by itself cannot ensure the integrity or privacy of transported data, nor can it authenticate the tunnel encapsulator. When any of these security properties is required, MPLS-in-UDP SHOULD be secured with IPsec (RFC 4301) or DTLS (RFC 6347).
Without IPsec or DTLS, address filtering at domain boundaries is needed to prevent unauthorized decapsulation. If only source-address filtering is deployed at boundaries, the decapsulator must also validate the IP source address; the IPv6 source address MUST be validated when UDP zero-checksum mode is in use.
The MPLS-in-UDP frame consists of a standard UDP header (Source Port = 16-bit entropy, Destination Port = 6635, UDP Length, UDP Checksum) followed by the MPLS Label Stack (per RFC 3032) and the MPLS Message Body.