skip to content

How do IPv6's ban on router fragmentation and its 1,280-byte minimum MTU change path MTU handling compared with IPv4?

level: seniorimportance: should knowfreq 30%

answer

  1. who may fragment in each family
  2. IPv4's escape hatch: DF clear
  3. a size that always fits
  4. probing instead of waiting for errors

basics

~20 s

IPv4 routers fragment oversized packets unless DF is set; IPv6 routers never do, so the sender alone must size packets from Packet Too Big feedback or probing. In return, every IPv6 link carries 1,280 bytes, a size that always fits.

solid answer

~50 s

In IPv4 a router facing a smaller link fragments the packet unless the sender set DF, and only then returns ICMP Destination Unreachable code 4, so a sender can always fall back to letting routers fragment. RFC 8200 removes that option: only the source may fragment, with a Fragment header, and a router drops an oversized packet and returns ICMPv6 Packet Too Big. Path MTU handling therefore becomes mandatory work for every IPv6 sender, and losing that feedback stalls large packets with no fallback. The counterweight is the 1,280-byte minimum link MTU: a packet that size or smaller always fits, a minimal sender may stay below it and skip PMTUD, and RFC 8201 says a Packet Too Big reporting less than 1,280 must be discarded. Sound senders keep packets within the path MTU, probe at the packetisation layer (RFC 4821, RFC 8899), and avoid relying on fragmentation at all.

go deeper

for a junior

Recall that IPv6 routers never fragment, that only the source may, and that every IPv6 link must carry at least 1,280 bytes.

for a middle

Contrast IPv4's DF-dependent router behaviour with IPv6's drop-and-report rule, and explain what the 1,280-byte floor guarantees a sender.

for a senior

Explain why size feedback becomes load-bearing, why sub-1,280 reports are discarded, and when probing or a 1,280-byte cap is the right sender strategy.

for a principal

Weigh the trade IPv6 made, simpler routers for stricter senders, and decide where packet sizing is owned across transport, tunnel and application layers.

## Path MTU in one paragraph The **path MTU** is the smallest link MTU between two hosts. A packet bigger than it cannot cross that link whole, so something has to give: either the packet is split into fragments, or the sender learns to send smaller packets. IPv4 and IPv6 answer that question differently. ## IPv4: the network may fragment In IPv4 (RFC 791) any router may fragment. What happens at a smaller link depends on the **DF** (Don't Fragment) flag: - **DF clear:** the router splits the packet; the destination reassembles it. - **DF set:** the router drops the packet and returns **ICMP Destination Unreachable, code 4, "fragmentation needed and DF set"**, which RFC 1191 extended to carry the next-hop MTU for Path MTU Discovery. The floor is low: every IPv4 router must forward a 68-byte datagram, and hosts must accept 576-byte datagrams. A sender always has an escape hatch: clear DF and let routers fragment. ## IPv6: only the source may fragment RFC 8200: "unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers". A router at a smaller link always drops the packet and sends **ICMPv6 Packet Too Big** with the next-hop MTU. There is no DF flag, because there is no router fragmentation to switch off. The sender then: 1. lowers its path MTU estimate for that destination (Path MTU Discovery for IPv6, RFC 8201); 2. resends smaller packets; or, as a last resort, 3. fragments at the source with a **Fragment extension header**, and only the destination reassembles. | | IPv4 | IPv6 | |---|---|---| | Who may fragment | the source or any router | the source only | | Sender's opt-out | clear DF and let routers fragment | none | | Router at a smaller link | fragments, or code 4 if DF set | drops, Packet Too Big | | Guaranteed size | forward 68 bytes; hosts accept 576 | 1,280 bytes on every link | | Reassembly guarantee | 576 bytes | 1,500 bytes | ## What the 1,280-byte floor buys RFC 8200 requires every link to carry at least **1,280 bytes**; a link that cannot must fragment and reassemble below the IP layer. That changes the sender's options: - A packet of **1,280 bytes or less** always fits, so a minimal implementation may send nothing larger and omit PMTUD entirely, which RFC 8200 explicitly allows. - A **Packet Too Big reporting less than 1,280** is bogus: RFC 8201 says it must be discarded and the estimate never lowered below 1,280. RFC 2460 had told senders to answer such a message with a Fragment header on every packet, the so-called atomic fragments; RFC 8200 removed that rule, following RFC 6946 and RFC 8021. - Every node must accept a fragmented packet that reassembles to **1,500 bytes**. ## Why the stakes are higher Because routers cannot fragment, the size feedback is load-bearing. In IPv4, losing the code 4 message causes PMTUD black holes for DF traffic, but traffic without DF still gets through. In IPv6 nothing above the path MTU gets through without the feedback: small packets such as handshakes succeed and full-size packets vanish, so connections open and then stall. This is why ICMPv6 filtering policy matters more than ICMP policy did for IPv4. ## How a well-behaved IPv6 sender handles it - **Fit the path.** Use the path MTU estimate and keep packets within it. - **Probe without ICMP.** Packetisation Layer PMTUD (RFC 4821) and its datagram version (RFC 8899) send probes of increasing size and treat loss of large probes as the signal, so they work even when feedback is filtered. - **Cap at 1,280 bytes** for datagram protocols that cannot probe and do not know the path. - **Avoid depending on fragmentation.** Packets with a Fragment header are often dropped: in one RFC 7872 dataset about 30% of fragmented test packets sent to web servers were lost. RFC 8900 (BCP 230) calls IP fragmentation fragile in both families. - **Leave headroom on links you configure.** RFC 8200 recommends a link MTU of 1,500 bytes or more where it is configurable, so tunnels do not push paths down towards the floor. ## The short version for an interview IPv4 lets the network fix oversized packets; IPv6 makes the sender responsible and gives it a guaranteed 1,280-byte floor in exchange. Everything else, from mandatory size feedback to avoiding fragmentation, follows from that trade.

  • How can an IPv6 sender find a working packet size if Packet Too Big messages never arrive?
    By probing at the packetisation layer: RFC 4821 for TCP-like protocols and RFC 8899 for datagram protocols send probes of increasing size and treat loss of the large probes as evidence the path is smaller. That finds a working size without ICMP. A datagram protocol that cannot probe can stay at or below the 1,280-byte minimum link MTU.
  • Why not simply rely on IPv6 source fragmentation for large datagrams?
    Because fragmented IPv6 packets are fragile in practice. Middleboxes often cannot see transport ports in non-first fragments and drop packets with a Fragment header; RFC 7872 measured about 30% of such test packets to web servers lost in one dataset. RFC 8900 (BCP 230) advises against relying on IP fragmentation altogether.

saying these in an interview costs you the question

  • IPv6 routers fragment a packet when the next link is smaller.
  • IPv6 senders clear the DF flag when Path MTU Discovery fails.
  • A Packet Too Big reporting 1,000 bytes should lower the path MTU to 1,000.
  • 1,280 bytes is the MTU of an Ethernet link.
  • If the handshake succeeds, the path cannot have an MTU problem.