ICMP Fragmentation Needed Packet Capture

This packet capture shows what happens when a 1500-byte packet with the Don’t Fragment (DF) bit set reaches a link with a smaller MTU. The router can’t forward it and can’t fragment it, so it drops the packet and sends back an ICMP Destination Unreachable, code 4: fragmentation needed, with the MTU of the next hop in the message.

This message is what path MTU discovery depends on. When a firewall blocks it, large packets silently disappear. The ICMP lesson covers the message types, and the IPv4 packet header lesson explains the DF bit. For code 3 of the same message type, see the ICMP Port Unreachable Packet Capture. More captures are in the Packet Capture Library.

Want to open this capture in Wireshark yourself? The pcap file is free with a NetworkLessons account. Your free account also unlocks all our free lessons and every capture in the Packet Capture Library.

Create a free account to download the pcap

Already have an account? Log in and the download button appears here.

Capture overview

File	icmp-fragmentation-needed.pcapng
Packets	2
Protocol	ICMP (RFC 792, RFC 1191), type 3 code 4
Transport	IPv4, protocol 1
Devices	Host 192.168.12.100 pings 3.3.3.3, router 192.168.12.1 has a next-hop link with MTU 1400
Wireshark filter	icmp.type == 3 && icmp.code == 4

Packets in this capture

No.  Time      Source          Destination     Protocol  Info
1    0.000000  192.168.12.100  3.3.3.3         ICMP      Echo (ping) request id=0x0001, seq=0/0, ttl=255
2    0.000444  192.168.12.1    192.168.12.100  ICMP      Destination unreachable (Fragmentation needed)

Packet walkthrough

The large ping (packet 1)

Internet Protocol Version 4, Src: 192.168.12.100, Dst: 3.3.3.3
    Total Length: 1500
    010. .... = Flags: 0x2, Don't fragment
        .1.. .... = Don't fragment: Set
    Time to Live: 255
    Source Address: 192.168.12.100
    Destination Address: 3.3.3.3

Here’s what stands out:

• Total length 1500 and DF set: the host doesn’t allow routers to fragment this packet. On the host’s own link, 1500 bytes fits, so it goes out fine.

Fragmentation needed (packet 2)

Internet Protocol Version 4, Src: 192.168.12.1, Dst: 192.168.12.100
Internet Control Message Protocol
    Type: Destination unreachable (3)
    Code: 4 (Fragmentation needed)
    Checksum: 0x8900 [correct]
    Unused: 0000
    MTU of next hop: 1400
    Internet Protocol Version 4, Src: 192.168.12.100, Dst: 3.3.3.3
        0100 .... = Version: 4
        .... 0101 = Header Length: 20 bytes (5)
        Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
            0000 00.. = Differentiated Services Codepoint: Default (0)
            .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
        Total Length: 1500
        Identification: 0x0001 (1)
        010. .... = Flags: 0x2, Don't fragment
            0... .... = Reserved bit: Not set
            .1.. .... = Don't fragment: Set
            ..0. .... = More fragments: Not set
        ...0 0000 0000 0000 = Fragment Offset: 0
        Time to Live: 254
        Protocol: ICMP (1)
        Header Checksum: 0xa40d [validation disabled]
        Source Address: 192.168.12.100
        Destination Address: 3.3.3.3
    Internet Control Message Protocol
        Type: Echo (ping) request (8)
        Code: 0
        Checksum: 0x6682 [unverified] [in ICMP error packet]
        Identifier (BE): 1 (0x0001)
        Sequence Number (BE): 0 (0x0000)

Let’s look at the important fields:

• From 192.168.12.1, the router: not from the destination. Fragmentation needed is always sent by the router where the packet didn’t fit.
• Type 3, code 4: destination unreachable, fragmentation needed and DF set.
• MTU of next hop: 1400: the original ICMP format had these bytes unused. RFC 1191 added the next-hop MTU, so the sender knows exactly how big its packets can be. A sender that does path MTU discovery lowers its packet size to 1400 bytes for this destination.
• The quoted header: the original packet, total length 1500 and DF set. That’s the evidence of why it was dropped.
• TTL 254 in the quoted header: the host sent the ping with TTL 255 (packet 1). This router decremented the TTL before it found out the packet didn’t fit, and it quotes the header as it was at that moment.