IP Fragmentation

IP fragmentation addresses a mismatch between an IP datagram's size and a link's maximum transmission unit, or MTU. The IP MTU is the largest IP packet that a link can carry without fragmentation; it excludes Ethernet headers and trailers. An Ethernet link with a 1,500-byte IP MTU therefore carries frames larger than 1,500 bytes. Distinguishing frame size from IP MTU is important when configuring switches, virtual interfaces, and cloud connections.

For IPv4, a sender or router can fragment an oversized datagram when the Don't Fragment, or DF, flag is clear. Each fragment has its own IP header and carries information that lets the destination reconstruct the original datagram. If DF is set, a router cannot fragment the packet and normally drops it while returning an ICMP Destination Unreachable message indicating that fragmentation is needed. IPv6 routers never fragment packets: they return ICMPv6 Packet Too Big messages, and only the source can perform IPv6 fragmentation.

The effective path MTU is the smallest IP MTU along the route. A virtual machine configured with a 9,001-byte MTU does not gain a 9,001-byte path to every destination. Traffic may traverse an internet connection, firewall, transit router, or encrypted tunnel with a smaller limit. Encapsulation adds outer headers, reducing the space available for the inner packet unless the underlying network supports a sufficiently larger MTU.

Jumbo frames can improve bulk-transfer efficiency by carrying more application data per packet and reducing header and packet-processing overhead. They are useful for compatible private paths, but they are not an automatic performance improvement. In AWS, supported EC2 interfaces can use a 9,001-byte MTU, while AWS Transit Gateway supports an 8,500-byte MTU on supported non-VPN attachments. AWS Direct Connect supports different MTUs by virtual-interface type: private virtual interfaces can support 9,001 bytes, transit virtual interfaces can support 8,500 bytes, and public virtual interfaces use 1,500 bytes. All relevant components must support the chosen size.

For example, two instances exchanging storage data over a validated jumbo-capable private path may benefit from larger packets. If that traffic is rerouted through an IPsec VPN, the original packet size may no longer fit. Rather than relying on fragmentation, configure an appropriate tunnel or route MTU and, for TCP, consider maximum segment size clamping. With a 1,500-byte MTU and ordinary headers, TCP MSS is 1,460 bytes for IPv4 or 1,440 bytes for IPv6. Additional headers reduce those values. MSS controls TCP payload size; it does not protect UDP applications from sending oversized datagrams.

Classic path MTU discovery uses ICMP feedback to help senders reduce packet sizes. Blocking the necessary ICMP messages can produce an MTU black hole: connection establishment and small requests succeed, but larger transfers stall. Packetization-layer path MTU discovery can reduce dependence on ICMP where the transport and implementation support it. During troubleshooting, use controlled-size probes with fragmentation disabled where supported, packet captures, and tests in both directions; asymmetric paths can have different limits.

Fragmentation is not equivalent to TCP segmentation or NIC offload. Segmentation creates independently transported TCP segments, whereas IP fragmentation splits one datagram that must be reassembled before delivery to the upper-layer protocol. Losing one fragment prevents reconstruction of that datagram, and reassembly consumes memory and processing resources. Some middleboxes also filter fragments. Optimize for the largest reliably supported packet size across each actual path, then measure throughput, CPU use, loss, and retransmissions rather than assuming that larger frames always reduce costs or improve performance.