Skip to content

CONCEPT Cited by 1 source

MTU IPv6 floor

Definition

QUIC, as standardised by the IETF in RFC 9000, does not support network MTUs below 1280 bytes. This matches the IPv6 minimum MTU (RFC 8200), which mandates that every IPv6 link must carry at least 1280-byte packets without fragmentation.

The 1280-byte floor is therefore a protocol-level design constraint of QUIC: every QUIC datagram is at least this big, so every path must be able to carry at least this much in one hop.

Canonical framing on the wiki

Zalando's 2024-06 post describes the consequences:

"The QUIC protocol, as it is being standardised by the IETF, does not support network MTUs smaller than 1280 bytes. It makes the protocol compatible with IPv6 networks (1280 bytes is IPv6 MTU). However, this poses challenges for networks operating on 'non-standard' IPv4 configurations, potentially leading to packet fragmentation, especially on radio channels. Presently, the industry predominantly adheres to Ethernet standards, assuming a physical link MTU of 1500. While larger datagrams are feasible, they necessitate the utilisation of the Path Maximum Transmission Unit Discovery protocol to ensure optimal performance and compatibility across diverse network environments." (Source: sources/2024-06-17-zalando-next-level-customer-experience-with-http3-traffic-engineering)

The three MTU anchors

  1. QUIC minimum: 1280 bytes (= IPv6 minimum). QUIC implementations reject path that cannot carry this.
  2. Ethernet common: 1500 bytes. The overwhelmingly dominant MTU for L2 frames. Fine for QUIC — leaves ~1200 bytes for payload after headers.
  3. Larger datagrams — possible via Path MTU Discovery (PMTUD). Without PMTUD, the safe floor is 1280 bytes.

Where the floor bites

  • Non-standard IPv4 configurations — some legacy IPv4 networks use MTUs below 1280, often on constrained links (satellite, some cellular fallback, legacy tunnelling). QUIC cannot traverse these without fragmentation at the IP layer — which is particularly undesirable on radio channels where retransmission of a fragment is expensive.
  • Radio channels — wireless links may have effective MTUs that fluctuate with link quality; coalescing QUIC streams into a fixed-size datagram means small-MTU failure modes fragment the datagram, and loss of any fragment invalidates the whole QUIC packet.
  • VPN / tunnel overhead — each encapsulation layer (IPsec, WireGuard, GRE) steals bytes from the outer MTU. Systems have to know their actual path MTU or pad conservatively.

PMTUD caveat

Path MTU Discovery depends on ICMP "Fragmentation Needed" messages propagating back to the sender. In practice:

  • ICMP is often rate-limited or dropped by firewalls and middleboxes.
  • Blackholing (silent drop of too-large packets) is a known PMTUD failure mode.
  • Datagram Packetization Layer PMTUD (DPLPMTUD, RFC 8899) lets QUIC probe path MTU at the packet layer without depending on ICMP — this is the mechanism QUIC implementations typically use.

Implication

The MTU floor is a design decision that keeps QUIC simple at the cost of some deployment friction. Rather than carry a fragmentation-and-reassembly protocol (TCP's approach), QUIC requires the underlying path to carry 1280 bytes, and uses DPLPMTUD to probe for more. For IPv6, this is free; for IPv4 on constrained links, it's a compatibility wart.

Seen in

Last updated · 501 distilled / 1,218 read