UDP Path MTU Discovery is a mechanism designed to prevent IP fragmentation by discovering the maximum transmission unit (MTU) along the path between two endpoints.
Here’s how it works in practice:
Let’s say you have a UDP application sending data from 192.168.1.10 to 192.168.2.20. The application wants to send a UDP packet of 1500 bytes.
On 192.168.1.10, the operating system’s network stack prepares the IP packet. If the MTU of the outgoing interface (e.g., eth0) is 1500 bytes, and there’s no information suggesting a smaller MTU further down the path, the packet is sent as is.
However, if a router along the path has an MTU smaller than 1500 bytes (e.g., 1400 bytes due to a VPN tunnel or a specific network configuration), it cannot forward the 1500-byte packet. By default, the router would fragment the packet. But with Path MTU Discovery (PMTUD), the router instead drops the packet and sends back an ICMP "Fragmentation Needed" message to the original sender (192.168.1.10). This ICMP message includes the MTU of the router’s outgoing interface (1400 bytes).
The UDP application on 192.168.1.10 receives this ICMP message. It then updates its internal PMTUD cache, noting that the path to 192.168.2.20 has a maximum MTU of 1400 bytes. Subsequent UDP packets sent to 192.168.2.20 will be capped at 1400 bytes (or slightly less, to account for UDP and IP headers). This prevents fragmentation at the router, as the packets are now small enough to pass through.
The problem this solves is the performance degradation and potential packet loss associated with IP fragmentation. When packets are fragmented, they are broken into smaller pieces at the sender or an intermediate router. These pieces are then reassembled at the receiver. This process consumes CPU resources on both routers and endpoints. Furthermore, if even a single fragment is lost, the entire original packet is lost, leading to retransmissions and further performance issues. PMTUD avoids this by ensuring packets are sized correctly from the start.
Internally, PMTUD relies on the IP layer’s ability to send ICMP "Fragmentation Needed" messages and the transport layer (like UDP) to react to them. For IPv4, this is ICMP type 3, code 4. For IPv6, it’s an ICMPv6 "Packet Too Big" message. The operating system maintains a PMTUD cache for each destination, storing the discovered MTU. This cache is dynamic and can be updated if a router along the path changes its MTU or if the network path itself changes.
The primary lever you control is the initial packet size and how your application or the underlying network stack handles ICMP messages. Most modern operating systems enable PMTUD by default. However, firewalls can sometimes block the necessary ICMP messages, effectively breaking PMTUD. If ICMP is blocked, the sender never learns about the smaller MTU, and fragmentation (or packet drops if the "Don’t Fragment" bit is set) can occur.
A common misconception is that PMTUD is solely an application-level concern. In reality, it’s a cooperative effort between the network stack, routers, and potentially applications that might want to hint at their desired MTU. The "Don’t Fragment" (DF) bit in the IPv4 header is crucial here. When this bit is set, routers are instructed not to fragment the packet. If they cannot forward it due to an MTU mismatch, they drop it and send the ICMP "Fragmentation Needed" message. Without the DF bit set, routers would fragment, and PMTUD wouldn’t be triggered for that packet.
The next concept you’ll likely encounter is how different tunneling technologies (like IPsec or certain VPNs) impact MTU, often requiring specific configuration to ensure PMTUD works correctly or to manually adjust MTU values.