IPv6 MTU and Path MTU Discovery: Avoiding Fragmentation Issues

Packet fragmentation is one of those problems you don't notice until it breaks everything.

Why MTU Matters More in IPv6#

IPv6 removed router-based fragmentation entirely. In IPv4, if a router receives a packet too large for the next hop, it can fragment it. IPv6 routers can't do that—they drop the packet and send an ICMPv6 "Packet Too Big" message back to the source.

The source host is responsible for all fragmentation. This design decision improves router performance and simplifies the protocol, but it shifts the burden to endpoints and makes Path MTU Discovery (PMTUD) critical.

If PMTUD fails, your connections hang mysteriously. TCP handshakes complete, but data transfer stalls. HTTP requests time out. SSH sessions freeze after authentication. These are classic MTU black hole symptoms.

IPv6 Minimum MTU#

All IPv6 links must support at least 1280 bytes. This is the minimum MTU, and it's non-negotiable. If your link can't handle 1280-byte packets, it's not IPv6-compliant.

Most networks use 1500 bytes (standard Ethernet MTU), which provides room for the 40-byte IPv6 header plus 1460 bytes of payload. That's equivalent to IPv4's typical TCP MSS of 1460.

Tunnels and encapsulation protocols reduce available MTU. If you're running IPv6-in-IPv4 (6in4), 6to4, or ISATAP, you lose bytes to the outer header. VPNs, IPsec, GRE, and VXLAN all consume MTU space.

Common MTU values you'll encounter:

• 1500: Standard Ethernet
• 1480: PPPoE (loses 8 bytes for PPP overhead)
• 1460: 6in4 tunnel (loses 20 bytes for IPv4 header)
• 1420: 6in4 over PPPoE
• 1280: Minimum IPv6 MTU, fallback value
• 9000: Jumbo frames (data center networks)

How Path MTU Discovery Works#

PMTUD determines the largest packet size that can traverse the path between source and destination without fragmentation.

The process is straightforward:

1. Host sends packets with the current MTU
2. If a router along the path has a smaller MTU, it drops the packet
3. Router sends ICMPv6 Type 2 "Packet Too Big" message back to source
4. Message includes the MTU of the next hop
5. Host reduces its path MTU and resends
6. Process repeats until packets traverse the entire path

The "Packet Too Big" message (ICMPv6 Type 2, Code 0) contains the MTU value in the message payload. This tells the source exactly how large packets can be, not just that they're too big.

Here's what the ICMPv6 message looks like:

ICMPv6 Packet Too Big:
  Type: 2
  Code: 0
  MTU: 1280
  [Original packet headers up to minimum MTU]

The host maintains a path MTU cache with entries that typically expire after 10 minutes (RFC 8201 recommendation). If network paths change, stale cache entries could cause issues until they expire.

PMTUD Black Holes#

The system breaks when ICMPv6 Type 2 messages get blocked. This creates "PMTUD black holes" where packets disappear silently.

Common causes:

Overzealous firewalls: Administrators sometimes block all ICMP traffic, treating it as a security risk. This is wrong. ICMPv6 is integral to IPv6 operation, not an optional diagnostic protocol like ping.

Stateful inspection issues: Some firewalls don't properly associate ICMPv6 error messages with existing connections, dropping them as unsolicited traffic.

Rate limiting: Security devices may rate-limit ICMPv6, dropping legitimate PMTUD messages during busy periods.

NAT64 gateways: Translation between IPv6 and IPv4 can lose PMTUD information if the gateway doesn't properly translate ICMP messages.

Symptoms of PMTUD black holes:

• TCP connection establishes (SYN, SYN-ACK, ACK complete)
• Small packets work (DNS queries, SSH login banner)
• Large packets fail (file transfers, HTTP POST with body, SSH interactive session after auth)
• No error messages, just timeouts
• Problem appears intermittent (depends on packet size)

Diagnosing MTU Problems#

Start with ping. Send packets of specific sizes to test path MTU:

# Test with 1280 bytes (minimum MTU)
ping6 -M do -s 1232 2001:db8::1
 
# Test with 1500 bytes (standard Ethernet)
ping6 -M do -s 1452 2001:db8::1
 
# Test with 1280 bytes payload
ping6 -c 5 -s 1280 2001:db8::1

The -M do flag prohibits fragmentation (don't fragment). The -s argument specifies payload size—add 8 bytes for ICMPv6 header and 40 for IPv6 header to get total packet size.

If 1452 bytes fails but 1232 succeeds, your path MTU is between 1280 and 1500. Use binary search to find the exact value:

# Try 1400
ping6 -M do -s 1352 2001:db8::1
 
# Try 1450
ping6 -M do -s 1402 2001:db8::1

Use traceroute to identify where MTU changes along the path:

traceroute6 -n 2001:db8::1

Then test MTU to each hop individually. The hop where large packets start failing is your problem point.

For TCP connections, capture packets to observe actual behavior:

# Capture packets
tcpdump -i eth0 -n 'ip6 and (icmp6 or tcp)'

Look for:

• TCP retransmissions after initial handshake
• ICMPv6 Type 2 messages (should appear if PMTUD is working)
• Absence of ICMPv6 Type 2 (indicates blocking or black hole)

Modern tools can automate this. MTR combines traceroute with packet size testing:

# Test with 1400-byte packets
mtr -6 -s 1400 2001:db8::1

This shows per-hop latency and packet loss with specific packet sizes, helping identify MTU issues.

TCP MSS Clamping#

MSS (Maximum Segment Size) is the TCP option that tells the other end how much data it can send in each segment. MSS = MTU - IP header - TCP header.

For IPv6: MSS = MTU - 40 (IPv6) - 20 (TCP) = MTU - 60

With standard 1500-byte MTU: MSS = 1440

MSS clamping forces TCP connections to use a lower MSS value, working around MTU issues without relying on PMTUD. This is common on routers that terminate tunnels or PPPoE connections.

Configure MSS clamping on Linux to limit TCP segment size:

# Clamp MSS to 1280 for IPv6
ip6tables -t mangle -A FORWARD \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1220

The value 1220 accounts for 1280 MTU minus 60 bytes for headers (40 bytes IPv6 + 20 bytes TCP).

For PPPoE connections with 1492 MTU:

ip6tables -t mangle -A FORWARD \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1432

MSS clamping only affects TCP. UDP, SCTP, and other protocols still rely on PMTUD or application-level fragmentation.

Firewall Configuration#

Your firewall must allow ICMPv6 Type 2 messages for PMTUD to function. This is non-negotiable for production IPv6 networks.

Minimal required ICMPv6 types for IPv6 operation:

• Type 1: Destination Unreachable
• Type 2: Packet Too Big (PMTUD)
• Type 3: Time Exceeded
• Type 4: Parameter Problem
• Type 133-137: Neighbor Discovery Protocol

Configure iptables to allow ICMPv6 Type 2 (Packet Too Big) for PMTUD:

# Allow ICMPv6 Packet Too Big
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT
ip6tables -A OUTPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT
ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type 2 -j ACCEPT

Better approach—allow all necessary ICMPv6 types for full IPv6 functionality:

# Allow established ICMPv6
ip6tables -A INPUT -p ipv6-icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# Allow necessary ICMPv6 types
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 1 -j ACCEPT    # Destination Unreachable
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT    # Packet Too Big
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 3 -j ACCEPT    # Time Exceeded
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 4 -j ACCEPT    # Parameter Problem
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 128 -j ACCEPT  # Echo Request
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 129 -j ACCEPT  # Echo Reply
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 133 -j ACCEPT  # Router Solicitation
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 134 -j ACCEPT  # Router Advertisement
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 135 -j ACCEPT  # Neighbor Solicitation
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 136 -j ACCEPT  # Neighbor Advertisement

Rate limiting is acceptable but set generous limits to avoid blocking legitimate PMTUD:

# Allow ICMPv6 with rate limit
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 \
  -m limit --limit 10/sec --limit-burst 20 -j ACCEPT

Never completely block ICMPv6. It's not a security risk—it's a protocol requirement.

Tunnel MTU Considerations#

Tunnels reduce effective MTU by the overhead of encapsulation headers.

Common tunnel types and overhead:

Configure tunnel MTU explicitly to avoid issues. For a 6in4 tunnel:

# 6in4 tunnel
ip tunnel add tun6in4 mode sit remote 203.0.113.1 local 198.51.100.1
ip link set tun6in4 mtu 1480
ip link set tun6in4 up

For WireGuard VPN, set MTU in the configuration file:

[Interface]
MTU = 1420

Some tunnel protocols support MTU discovery, but explicit configuration is more reliable.

Jumbo Frames and Data Centers#

Data center networks often use 9000-byte MTU (jumbo frames) to improve throughput for bulk transfers.

Enable jumbo frames on interfaces:

ip link set eth0 mtu 9000

Ensure all switches and routers in the path support jumbo frames. One device with 1500-byte MTU will become a bottleneck.

PMTUD still applies. If a packet leaves your jumbo frame network toward the Internet, it must reduce to 1500 or less.

Testing and Verification#

Verify your host's MTU configuration:

ip -6 link show

Look for the MTU value on each interface.

Check the current path MTU cache to see what MTU your system has learned for a destination:

ip -6 route get 2001:db8::1

Output shows the cached MTU for that destination.

Test end-to-end connectivity with varying packet sizes to find the maximum working size:

for size in 1232 1352 1402 1452; do
  echo "Testing $size bytes:"
  ping6 -M do -s $size -c 3 2001:db8::1
done

Use netcat to test TCP MSS negotiation. Run a server on one host and connect from another:

# Server
nc -6 -l 8080
 
# Client
nc -6 2001:db8::1 8080

Capture packets with tcpdump and verify MSS values in SYN packets.

Common Scenarios and Fixes#

Problem: Web pages load slowly, images fail Cause: PMTUD black hole due to firewall blocking ICMPv6 Type 2 Fix: Configure firewall to allow ICMPv6 Type 2

Problem: SSH connects but freezes after login Cause: MTU too large, PMTUD not working Fix: Reduce MTU on client interface or enable MSS clamping on router

Problem: VPN works for small transfers, fails for large files Cause: Tunnel MTU not configured correctly Fix: Reduce tunnel MTU to account for encapsulation overhead

Problem: IPv6 works on local network, fails across Internet Cause: Upstream router has smaller MTU, not advertising it properly Fix: Contact ISP or reduce local MTU to 1280 (minimum)

Problem: Some destinations work, others fail Cause: Path-specific MTU issues Fix: Test with ping to identify working MTU, configure interface accordingly

Best Practices#

1. Always allow ICMPv6 Type 2 in firewalls
2. Configure tunnel MTU explicitly rather than relying on auto-detection
3. Test with minimum MTU (1280) to ensure baseline connectivity
4. Use MSS clamping on tunnel endpoints and PPPoE connections
5. Monitor PMTUD failures with packet captures during troubleshooting
6. Document your network's MTU at each layer (physical, tunnel, application)
7. Set conservative MTU values when in doubt (1280 always works)

Related Articles#

• ICMPv6 Explained - Understanding IPv6's control protocol
• IPv6 Firewall Configuration - Secure IPv6 without breaking functionality
• IPv6 Troubleshooting - Debug common IPv6 connectivity issues

Additional Resources#

• RFC 8201: Path MTU Discovery for IPv6
• RFC 4821: Packetization Layer Path MTU Discovery
• IPv6 MTU Issues - RIPE Labs