LEARN. PRACTICE. GROW.Concept and mechanism
MTU limits the IP packet size supported by a link; the path can contain a lower limit than the local interface. Encapsulation adds overhead and can reduce usable size. In an IPv4 example without options, a 1500-byte packet with 20-byte IP and TCP headers leaves 1460 bytes of TCP payload. Do not generalize that number to every path. Path MTU Discovery helps the source adapt size: for IPv4 with DF, fragmentation-needed signaling matters; for IPv6, Packet Too Big communicates the limitation. IPv6 routers do not fragment transit packets; fragmentation, when used, belongs to the source.
Guided application
A handshake uses small packets and can work even when a fault blocks larger data. In a fictional case, a firewall change filters Packet Too Big before it reaches the source. Evidence supports correcting the specific policy and testing representative transfers without opening the whole network. ICMP also supports diagnosis: Time Exceeded from transit TTL expiry is not an application business timeout. In IPv6, blocking all ICMPv6 can affect Neighbor Discovery and PMTU alongside echo. This course uses RFC 8200 for the IPv6 base and recognizes RFC 9673, which updates Hop-by-Hop processing; it does not assume old rules describe every implementation. Consult the actual environment behavior and policies.
Completed handshake and stalled large transfer justify comparing sizes, MTU, and ICMP signaling.
Common pitfalls
MTU as application payload; IPv6 fragmented by routers; ICMP only as ping; timeout as a PMTU fix.
Related topics: Addresses, prefixes, and scope · Routes and next-hop resolution · Transport, acknowledgement, and messages
Validate size and signaling alongside confirming that the connection opens.
Reference: IPv6 Path MTU Discovery: RFC8201 · DR TCP/IP 2026-09; TCP RFC 9293; IPv6 RFC 8200 with RFC 9673 update; Linux socket and iproute2 guidance