skip to content

Why does RFC 8900 call IP fragmentation fragile, and what should a protocol that sends large IPv4 datagrams do instead?

level: seniorimportance: should knowfreq 24%

answer

  1. fragments lack the transport header
  2. middleboxes guess or drop
  3. 16-bit Identification wraps
  4. lose one, lose all
  5. size to the path instead

basics

~20 s

Fragments lack ports, which confuses firewalls, NAT and load balancers; one lost fragment loses the datagram; IPv4's 16-bit Identification wraps at high rates and splices data. RFC 8900 says new protocols should size to the path MTU instead.

solid answer

~40 s

RFC 8900 (BCP 230, 2020) lists how fragmentation fails in today's networks. Only the first fragment carries ports, so stateless firewalls must pass or block the rest blindly, NAT devices must virtually reassemble, and ECMP or link-aggregation hashing can send fragments of one flow down different links. Reassembly is state an attacker can exhaust, and overlapping fragments evade filters. At high data rates IPv4's 16-bit `Identification` wraps within the reassembly timeout, so fragments of different datagrams get spliced, and TCP and UDP checksums do not reliably catch it (RFC 4963). PMTUD can black-hole, and some paths drop fragments outright. RFC 8900 does not deprecate fragmentation, but says new protocols SHOULD NOT rely on it: a sender should size its messages to the path MTU, preferably found by packetization-layer PMTUD.

go deeper

for a junior

Recall that only the first fragment carries the port numbers and that losing any fragment loses the whole datagram.

for a middle

Explain how firewalls, NAT and load balancers each stumble on fragments without ports, and why the receiver must hold reassembly state until a timer expires.

for a senior

Show the production reasoning: Identification wraparound silently corrupts data at high rates, paths drop fragments, and a protocol should size its messages to a probed path MTU instead.

for a principal

Treat it as a design rule for new protocols: anything that hands IP oversized datagrams inherits failures no operator can fix, so the sizing responsibility belongs in the transport or application.

## What RFC 8900 is **RFC 8900, "IP Fragmentation Considered Fragile"**, is a Best Current Practice (BCP 230, September 2020). It collects operational experience with fragmentation in IPv4 and IPv6, explains why it makes communication fragile, and gives recommendations. Importantly, it **does not deprecate** fragmentation: some environments still need it, such as IPsec tunnel mode and IP-in-IP encapsulation. It asks protocols to stop **depending** on it. ## Why fragments confuse the network The root cause is simple: only the **first fragment** carries the transport header with its ports. Every device that decides by ports is affected: - **Stateless firewalls** can apply port rules to the first fragment only, and must either accept all later fragments, admitting some attacks, or block them, breaking legitimate traffic. RFC 8900 calls neither option attractive. - **NAT** maps flows by address and port, so a translator must **virtually reassemble** fragments to translate and forward each one. - **ECMP, link aggregation and stateless load balancers** typically hash a packet with a transport header on five values (addresses, protocol, ports) and one without on three. Fragments of one flow can therefore be hashed differently from its unfragmented packets and spread across links, with reordering as a side effect. - **Policy-based routing** that selects a path by port has the same blind spot. ## Why fragments are fragile end to end - **Loss multiplication.** The destination needs every fragment; IP never retransmits one. A datagram cut into three pieces is lost if any one is, and the whole datagram must be resent. - **Reassembly state.** The receiver holds partial datagrams until a timer fires (RFC 1122 recommends 60 to 120 seconds), which is memory an attacker can exhaust with incomplete datagrams. - **Security.** Overlapping-fragment attacks (RFC 1858, RFC 3128), predictable `Identification` values and intrusion-detection evasion all ride on reassembly. - **Filtering.** Some paths simply drop fragments. RFC 8900 cites measurements of IPv6 (RFC 7872) where at least 28% of sampled paths did not carry packets with the Fragment header. - **PMTUD black holes.** The alternative to fragmenting, sending with `DF` and learning the path MTU from ICMP, fails when that ICMP is lost or filtered. ## IPv4 Identification wraparound RFC 791 says a sender must keep `Identification` unique per source, destination and protocol for as long as a datagram could be alive. With 16 bits that allows only 65,536 datagrams per lifetime. RFC 4963 works the numbers: | Condition | What it implies | |---|---| | 1,500-byte packets, 30-second packet lifetime | Strict uniqueness caps a sender at about 26 Mb/s | | Filling 1 Gb/s with 1,500-byte packets | 65,536 packets go out in under one second | RFC 4963 notes the rule is widely ignored, so at high rates an `Identification` value repeats while an older datagram's fragments still wait in the reassembly buffer. The receiver can **mis-associate** fragments from two datagrams and deliver a spliced one; the 16-bit TCP and UDP checksums are not strong enough to catch every such corruption. IPv6's fragment header uses a **32-bit** identification, so the problem needs packet rates 65,536 times higher. RFC 6864 adds that for an **atomic** IPv4 datagram, with `DF` set, `MF` clear and offset 0, the `Identification` has no meaning and need not be unique. ## What a protocol should do instead RFC 8900's recommendations, by audience: 1. **Protocol and application developers** SHOULD NOT build new protocols that rely on IP fragmentation, and legacy ones SHOULD be updated to break the dependency. 2. Size messages to the path: use a small enough fixed size, or adapt the segment or message size to a **path MTU estimate**, ideally from **packetization-layer PMTUD (PLPMTUD)** (RFC 4821 for TCP, RFC 8899 for datagram transports), which does not depend on ICMP. 3. **System developers** SHOULD provide PLPMTUD in their libraries for each transport. 4. **Middlebox developers** should handle fragments as RFC 791 and RFC 8200 specify, and document any non-standard behaviour. 5. **Network operators** MUST make PMTUD work, which includes routers generating the too-big errors. ## The interview answer in one line Fragmentation still works on paper, but every port-aware device on a modern path and every high-rate sender makes it unreliable, so the robust design is to never need it: send datagrams that fit the path and discover that size from the transport itself.

  • Why does IPv4 Identification wraparound corrupt data instead of just dropping it?
    The receiver groups fragments by source, destination, protocol and `Identification`. If the sender reuses an `Identification` while fragments of an older datagram still wait in the reassembly buffer, a new fragment can complete the old datagram. The result has the right length and offsets but mixed data, and the 16-bit TCP or UDP checksum does not catch every such splice, so corrupted data can reach the application (RFC 4963).
  • Why can fragments of one flow take different links through ECMP or link aggregation?
    Many devices hash a packet that carries a transport header on addresses, protocol and ports, and a packet without one on addresses and protocol only. The first fragment has ports, later ones do not, and the flow's unfragmented packets do, so parts of one flow may hash to different links. That brings reordering and uneven load; RFC 8900 lists it among the fragility causes.
  • Does RFC 8900 deprecate IP fragmentation?
    No. RFC 8900 explicitly does not recommend deprecation, because some environments still need fragmentation, such as IPsec tunnel mode and IP-in-IP encapsulation. It recommends that upper-layer protocols handle sizing at their own layer, that new protocols not rely on fragmentation, and that legacy ones be updated to break the dependency.

saying these in an interview costs you the question

  • RFC 8900 deprecates IP fragmentation, so routers no longer fragment IPv4.
  • TCP and UDP checksums always catch fragments spliced from different datagrams.
  • A stateless firewall can apply port rules to every fragment.
  • Fragmentation only costs a few extra header bytes per datagram.
  • IPv4 Identification values never repeat on a busy sender.