Summary

  • RFC 791 made DF a hard constraint: routers may not fragment a marked datagram, but they may discard it.
  • RFC 1191 made that failure informative by requiring an ICMP Type 3 Code 4 reply carrying the limiting Next-Hop MTU.
  • RFC 2923 showed the dependency the design could not enforce: if the ICMP reply is suppressed, small exchanges may work while large transfers vanish into a PMTUD black hole.

A packet designed to fail intact

The original IPv4 flags field contains three bits: a reserved bit, Don't Fragment and More Fragments. RFC 791 assigns DF a stark binary meaning. Zero permits fragmentation; one forbids it. When DF is set, a router is not allowed to divide the datagram, although the datagram may be discarded.

That last clause matters. DF was not an assurance that an intact packet would arrive. It was an instruction about what a router must not do when a downstream link is too narrow. RFC 791 offered a receiver with insufficient reassembly resources as one reason to prohibit fragmentation. The flag protected an endpoint constraint by accepting a different outcome: loss rather than an unwanted set of fragments.

In that first contract, DF says no. It does not by itself tell the sender which size would have worked.

Turning refusal into a measurement

RFC 1191 made the prohibited operation the trigger for Path MTU Discovery. A source begins with an estimate based on the MTU of its first hop and sends datagrams with DF set. If every link can carry the datagram, it passes intact. If some router reaches a link whose MTU is smaller than the datagram, the router cannot obey both the packet's size and the DF instruction.

The prescribed response is to discard the datagram and send the source an ICMP Destination Unreachable message, Type 3 Code 4: fragmentation needed and DF set. The dropped packet becomes a probe, and the error becomes evidence about the path.

RFC 1191 sharpened that evidence. In the ICMP header, it assigned the low-order sixteen bits of a field previously labelled unused to Next-Hop MTU. The value is the largest IP datagram that the router could have forwarded on the relevant next hop without fragmentation. It includes the IP header and data, but not lower-layer overhead.

The number changes the quality of the feedback. Without it, the source knows only that its current datagram was too large. With it, the limiting router supplies a concrete upper bound at the point of failure.

Convergence belongs to the source

Receiving the message is not the end of discovery. RFC 1191 requires the host to reduce its PMTU estimate for the relevant path. It must also avoid provoking repeated errors in the near future, either by reducing the datagrams it sends or by ceasing to set DF. The specification deliberately leaves room for different implementation and application strategies, but it insists that the process converge.

This division of work is important. The router reports a local forwarding constraint. It does not rewrite the original packet into fragments and does not decide the source's long-term packetization policy. The source incorporates the observation and changes what it emits.

An estimated PMTU can also increase, but probing upward risks another loss. RFC 1191 therefore makes such tests infrequent: no sooner than five minutes after a Datagram Too Big message for the destination, and no sooner than one minute after a previous successful increase attempt. It recommends intervals twice those minima. Discovery is not a continuous demand for the largest possible packet; it is a controlled balance between efficiency and the cost of testing a path that may not have changed.

Compatibility when the number is missing

The new Next-Hop MTU field could not assume that every router would be upgraded at once. An older router would send the appropriate ICMP error with zero in the field that its specification still considered unused. RFC 1191 requires hosts to handle that old-style message.

The source must then recover from less precise evidence. It may lower its estimate using known MTU plateaus or another bounded strategy. The mechanism still learns from failure, but it searches rather than following a reported limit. This compatibility path preserved deployment across mixed generations at the cost of ambiguity and extra discarded probes.

When the return signal disappears

RFC 2923 documented the failure mode that made PMTUD notorious. Some routers failed to send the required ICMP message. Firewalls were often configured to suppress all ICMP. When the error never reaches the source, the source continues sending packets that are both too large for a link and forbidden to fragment. They disappear repeatedly because the sender never receives the fact needed to reduce their size.

The result is a PMTUD black hole. Its symptoms are misleading because packet size determines what works. A short TCP handshake can cross the path. Small application writes can succeed. Ordinary pings may return. The failure appears when a bulk transfer begins emitting large packets; progress stops and the connection eventually times out.

This is not evidence that the destination is unreachable in every sense. It is evidence that one size-and-control combination cannot traverse the path and that the feedback loop has been broken.

RFC 2923 describes endpoint detection and fallback behavior, including reducing packet size or disabling PMTUD for a connection. Yet it also warns that fallback can conceal the faulty network and add hidden delay. Its preferred remedy is to fix the ICMP black hole, not make every endpoint permanently compensate for it.

What the history established

DF did not eliminate fragmentation by magic. It reassigned control. The sender could prohibit routers from fragmenting a packet, while the limiting router could return a quantified constraint and let the source choose a new size. An error message became part of normal adaptation rather than merely a terminal complaint.

The design also exposed a dependency that no header bit could secure. The source, limiting router, ICMP return path, filters and upper-layer sender all had to preserve their part of one loop. DF without feedback yields repeated loss. Feedback without a responsive source yields repeated errors. A cached PMTU remains an observation about a path at a time, not a permanent property of the destination.

Sources