In IPv4, who sends an ICMP type 3 code 4 (fragmentation needed and DF set), and what does RFC 1191 make it carry?

## The condition that triggers it Every link has a **maximum transmission unit (MTU)**: the largest IP datagram it carries in one frame. In IPv4 a router that must forward a datagram larger than the outgoing link's MTU normally **fragments** it. The sender can forbid that by setting the **Don't Fragment (DF)** flag in the IPv4 header. RFC 792 covers the collision: "a datagram must be fragmented to be forwarded by a gateway yet the Don't Fragment flag is on. In this case the gateway must discard the datagram and may return a destination unreachable message." That message is **type 3, code 4 — fragmentation needed and DF set**. ## Who generates it - A **router** on the path, at the point where the datagram meets a smaller link. RFC 792 lists code 4 among the codes received from a gateway, and RFC 1812 defines it as "generated if a router needs to fragment a datagram but cannot since the DF flag is set". - **Not the destination host.** By the time a datagram reaches the destination it has already crossed every link; the receiver has no fragmentation decision to make. - The ICMP packet's source address is therefore the router's own address, which tells the sender *where* the narrow link sits. ## What RFC 1191 added: the next-hop MTU RFC 792's version only said "too big". It did not say how big would fit, so a sender had to guess. RFC 1191 (Path MTU Discovery) redefined the header so the router reports the number: | Bits | Field | Content | |---|---|---| | 0-7 | Type | 3 | | 8-15 | Code | 4 | | 16-31 | Checksum | ICMP checksum | | 32-47 | unused | MUST be zero | | 48-63 | **Next-Hop MTU** | MTU of the link the datagram could not cross | | then | Original datagram | its IP header plus at least 64 bits of its data | The rules around that field: 1. The router MUST include the next-hop MTU in the **low-order 16 bits** of the field RFC 792 called unused; the high-order 16 bits remain zero. 2. The value is "the size in octets of the largest datagram that could be forwarded ... without being fragmented at this router", and it **includes the IP header and IP data, not any lower-level headers**. An Ethernet header is not counted. 3. It is **never less than 68**, because every IPv4 router must be able to forward a 68-octet datagram without fragmentation. 4. RFC 1812 makes the RFC 1191 form mandatory: a router MUST use it when originating code 4. 5. A **zero** in the field marks an "old-style" message from a router that predates RFC 1191; the sender knows its datagram was too big but must estimate a smaller size itself. ### A worked example A host at `192.0.2.10` sends a 1,500-byte datagram with DF set toward `203.0.113.20`. A router at `198.51.100.1` must forward it onto a link whose MTU is 1,400 bytes. The router discards the datagram and returns type 3 code 4 with Next-Hop MTU = 1,400, quoting the dropped datagram's header. The sender now knows that datagrams of at most 1,400 bytes, IP header included, can pass that router unfragmented. ## Why the message matters Code 4 is the signal that **Path MTU Discovery** runs on for IPv4: senders set DF, and each code 4 tells them to send smaller. The discovery procedure itself, and what happens when the signal never arrives, is a fragmentation subject; the consequence worth knowing here is simple: - If a filter on the return path discards code 4, the sender never learns, keeps sending datagrams that are too big, and those datagrams disappear. Small exchanges such as a handshake succeed while large transfers stall. - For TCP, RFC 1122 and RFC 9293 list codes 2 to 4 as hard errors, but RFC 5927 notes that code 4 is a **soft error** when TCP implements Path MTU Discovery: it means "resend smaller", not "give up". ## The IPv6 contrast IPv6 routers never fragment; only the source does. So ICMPv6 (RFC 4443) uses a separate message, **Packet Too Big** (type 2), which always carries the MTU. Type 3 code 4 is purely IPv4.