Every network link has a maximum transmission unit, or MTU, that limits the size of an IP packet carried in one link-layer frame. A route can cross links with different limits, so the smallest relevant MTU along that route constrains packet size end to end.
Path MTU Discovery, commonly shortened to PMTUD, lets an endpoint find that constraint and adjust packet sizes rather than relying on fragmentation.
One route can contain several MTU limits
Ethernet commonly uses an IP MTU of 1500 bytes, but tunnels, VPNs, encapsulation, and other link types can reduce the usable size. A packet that fits the sender’s local interface can therefore be too large for a later hop.
The path MTU is the smallest MTU that matters along the current route. It is a path property, not simply a property of either endpoint.
Routes can also change. A value that worked earlier is not guaranteed to remain valid for the lifetime of a long connection.
IPv4 and IPv6 handle oversized packets differently
In IPv4, a router can fragment an oversized packet when fragmentation is permitted. If the Don’t Fragment flag is set, the router instead drops the packet and sends an ICMP message indicating that fragmentation is required.
Classic IPv4 PMTUD uses that feedback. The sender transmits packets with fragmentation disabled, receives an ICMP error when a hop cannot forward one, and reduces its packet size.
IPv6 routers do not fragment packets in transit. An IPv6 router that encounters an oversized packet drops it and returns an ICMPv6 Packet Too Big message. The source then sends smaller packets. IPv6 fragmentation, when used, is performed by the source endpoint.
ICMP feedback carries the limiting signal
PMTUD depends on control messages reaching the sender. For IPv4, the relevant message can report that a packet needs fragmentation and can include the next-hop MTU. For IPv6, Packet Too Big includes the MTU that caused the failure.
The sender can cache a path MTU estimate and use it when forming later traffic. Transport protocols then keep their payloads within the resulting IP packet budget.
For TCP, this interacts with the maximum segment size, or MSS. TCP payload must leave room for IP and TCP headers, so an IP path MTU and a TCP MSS are related values rather than interchangeable ones.
Blocking ICMP can create stalled transfers
A firewall that discards required ICMP feedback can hide an MTU problem from the sender. Small packets may pass while larger packets disappear at the restrictive hop.
This can produce a connection that starts normally and then stalls when an application sends enough data for larger packets. The symptom is sometimes called a PMTUD black hole.
Permitting the required ICMP and ICMPv6 control traffic avoids this failure mode. Treating every ICMP message as expendable can break normal IP behavior.
Packetization Layer PMTUD can probe without ICMP dependence
Packetization Layer Path MTU Discovery, or PLPMTUD, moves more of the detection logic into a transport or another packetization layer. It sends probes of selected sizes and uses successful delivery or loss signals to adjust the working packet size.
This approach can operate even when ICMP feedback is missing, although protocol-specific details differ. It also requires care because packet loss can have causes unrelated to MTU.
Protocols such as TCP and QUIC can apply packetization-layer techniques to keep packet sizing responsive to the actual path.
Tunnels reduce the payload budget
Encapsulation adds headers around an existing packet. A tunnel that crosses a 1500-byte physical path cannot always carry a full 1500-byte inner packet without another accommodation.
Operators can lower the tunnel interface MTU so endpoints create smaller inner packets. TCP deployments may also adjust advertised MSS at a boundary to keep TCP segments within the available encapsulated packet budget.
MSS adjustment only affects TCP. It does not solve packet sizing for UDP or other IP traffic, so a correct interface MTU and functioning path discovery remain important.
Jumbo frames need end-to-end support
A local network can use an MTU above 1500 bytes when every relevant device and link supports it. Such jumbo-frame configurations can reduce per-packet processing overhead for large transfers.
A large MTU on one segment does not make the full route capable of carrying packets of that size. Traffic leaving the jumbo-capable segment can encounter a smaller limit, and path discovery must account for that boundary.
Mixed MTU environments therefore require consistent configuration and reliable control-message handling.
Path MTU is a live routing constraint
PMTUD keeps packet size aligned with the narrowest link on a route. Its practical value appears when local interface settings do not describe the complete path, especially across tunnels, provider networks, and mixed link technologies.
Correct ICMP handling, suitable interface MTUs, and transport-level probing all contribute to reliable delivery. When those pieces work together, endpoints can avoid oversized packets without assuming that every route has the same capacity.