IP fragmentation and Path MTU

IP fragmentation and Path MTU. A practical guide for network diagnosis and careful interpretation. One technical signal does not describe the whole path, so each connection layer should be checked independently and in a reproducible order.

What happens to the packet or connection

IP fragmentation and Path MTU belongs to the transport or network path. Separate the local socket, IP delivery, TCP or UDP behaviour, firewall filtering and NAT. A successful ping does not prove a TCP port is reachable, and an open port does not prove the application protocol is healthy.

Where to look for blocking

Work from near to far: process and bind address → host firewall → route → NAT/port forwarding → CGNAT or ISP filtering → external test. For packet-size failures, consider MTU and Path MTU Discovery separately. Always interpret a port number together with its transport protocol.

Concrete examples and values

Use these values as anchors when reading documentation or test output: MTU; IPv4 fragmentation; IPv6 routers do not fragment; Path MTU Discovery; ICMP Packet Too Big.

IPv4 routers may fragment in some circumstances, while IPv6 routers do not fragment transit packets. Path MTU Discovery depends on ICMP feedback such as Packet Too Big; blocking that feedback can create connections that work for small packets and stall for larger ones.

Common causes and mistakes

A common mistake is to treat one successful test as proof that the whole path is healthy. A reachable IP address does not prove DNS works, an open port does not validate the application protocol, and a fast speed test does not rule out latency, packet loss, or Wi-Fi contention. NAT, CGNAT, firewalls, CDNs, Anycast, and caches can also change what an observer sees and must be considered according to the question.

What the result does not prove

A technical result has limits. It normally cannot establish a person’s identity, the owner of a device, or the single root cause of an outage without additional evidence. IP geolocation is approximate, registration data can be redacted, and Internet routes can change. Security should not be reduced to one flag, address, or status value. A conclusion should match the specific property that was actually measured.

A reproducible troubleshooting sequence

Begin with a reproducible symptom, then verify local configuration, addressing, and DNS. Continue with routing, ports, and the application protocol. Make one change, repeat the measurement, and compare the outcome. This sequence reduces false conclusions and produces useful evidence for an administrator or Internet provider. After fixing the problem, repeat the original test to confirm that the observed symptom, rather than an unrelated condition, actually changed.