IPv4 and IPv6 handle fragmentation differently. IPv4 expects routers to do all of the heavy lifting (fragmentation) while IPv6 moves that responsibility to the sender.
The biggest issues we have with IPv4 fragmentation is:
1. it’s costly on our weak router CPUs
2. Any firewalls along the path cannot inspect fragments of an IP packet, they need to reassemble it. (sometimes they just let them pass (L4-7 inspection))
3. Losing one part of an IP fragment means the whole packet is lost and needs to be retransmitted.
One cannot talk about IPv4 fragmentation without discussing path MTU discovery, they go hand in hand.
Path MTU discovery is a technique used by end hosts to constantly test the MTU of the path its packets are taking by sending packets out with the don’t fragment bit set.
The secret sauce to all of this is the don’t fragment bit in the IP header (in the flags section as discussed in 1.1.d (ii)).
When a router encounters a packet with this bit set, and it needs to fragment the packet, it will instead drop it and send back an ICMP type 3 Code 4 (as discussed in 1.1.d (i) to
the original sender of the IP packet (host). The problem with this mechanism is if any firewall or router along the path blocks these ICMP type 3 Code 4 messages, the host will never know what the issue is. They will either 1. send packets and they will be fragmented (with crappy performance) 2. dropped along the path where the IP packet is too big.
While path MTU discovery works for the IP layer (thus works for any protocol carried in IP), we also have other tricks up our sleeve to fix MTU issues.
Routers or firewalls along the path can also intercept TCP headers and configure the Maximum Segment Size (MSS) per TCP flow (direction).
On cisco routers this is done with:
ip tcp adjust-mss 1350
or on Cisco ASAs:
sysopt connection tcp-mss maximum 1350
Note: Above I used a TCP MSS of 1350, (usually good for IPsec VPNs) however you should calculate your own.
Another fix possible is at the host level, we can just adjust the host’s MTU to something a little lower. Thus taking control of the situation.
In a situation where the affected hosts are servers, or are in your complete control, the last solution is NOT a “hack”.
Note that you can also set MTU via Windows GPO, or via a DHCP Option.
The methods above are for IPv4, however they may be applied to IPv6.
MTU reduction, MSS clamping and PMTUD are all still valid and required in IPv6, as a matter of fact, they are more important.
Testing IPv4 fragmentation on Windows:
ping 8.8.8.8 -l 1472 -f
Pings google DNS with an ICMP packet that has an MTU of 1500 with the don’t fragment bit set.
Testing IPv4 fragmentation on Linux:
traceroute 8.8.8.8 --mtu
This tests the path MTU for every hop
In IPv6, if we have MTU issues and a router or firewall along the path is blocking the ICMPv6 packet too big message, our hosts will may never transfer the data they wanted to. They may, for example receive the smaller messages, or even negotiate an SSL session, however any bulk transfer exceeding that MTU will cause the session to hang and even cause retransmits.
The above scenario is why NOT filtering ICMPv6 messages is oh so very important to the usage of IPv6.
Best source for PMTU:
https://blog.cloudflare.com/path-mtu-discovery-in-practice/
Other PMTU resources:
https://en.wikipedia.org/wiki/Path_MTU_Discovery
More reading regarding MTU issues, testing and fixing (pretty common but well worded):
https://www.fir3net.com/Networking/Terms-and-Concepts/how-can-i-optimize-the-throughput-of-a-vpn-across-a-wan-based-link.html