ICMP DF-bit in Echo Request and Reply

When you set the DF-bit, you'll see this in both the ICMP echo request and reply. We can verify this with a packet capture.

Without DF-Bit

Let's start with a packet where fragmentation is allowed:

R1#ping 192.168.12.2 repeat 1        
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms

ICMP Echo Request

We can see the fragmention bit is set to 0:

Frame 41: 114 bytes on wire (912 bits), 114 bytes captured (912 bits) on interface eth1, id 0
Ethernet II, Src: ICANNIANADep_d6:b9:88 (00:00:5e:d6:b9:88), Dst: ICANNIANADep_e9:7a:d2 (00:00:5e:e9:7a:d2)
Internet Protocol Version 4, Src: 192.168.12.1, Dst: 192.168.12.2
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 100
    Identification: 0x000c (12)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 255
    Protocol: ICMP (1)
    Header Checksum: 0x2239 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.12.1
    Destination Address: 192.168.12.2
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0x7744 [correct]
    [Checksum Status: Good]
    Identifier (BE): 8 (0x0008)
    Identifier (LE): 2048 (0x0800)
    Sequence Number (BE): 0 (0x0000)
    Sequence Number (LE): 0 (0x0000)
    [Response frame: 42]
    Data (72 bytes)

ICMP Echo Reply

And as expected it's also disabled in the echo reply:

Frame 42: 114 bytes on wire (912 bits), 114 bytes captured (912 bits) on interface eth1, id 0
Ethernet II, Src: ICANNIANADep_e9:7a:d2 (00:00:5e:e9:7a:d2), Dst: ICANNIANADep_d6:b9:88 (00:00:5e:d6:b9:88)
Internet Protocol Version 4, Src: 192.168.12.2, Dst: 192.168.12.1
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 100
    Identification: 0x000c (12)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 255
    Protocol: ICMP (1)
    Header Checksum: 0x2239 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.12.2
    Destination Address: 192.168.12.1
Internet Control Message Protocol
    Type: 0 (Echo (ping) reply)
    Code: 0
    Checksum: 0x7f44 [correct]
    [Checksum Status: Good]
    Identifier (BE): 8 (0x0008)
    Identifier (LE): 2048 (0x0800)
    Sequence Number (BE): 0 (0x0000)
    Sequence Number (LE): 0 (0x0000)
    [Request frame: 41]
    [Response time: 0,331 ms]
    Data (72 bytes)

With DF-Bit

Now let's try another packet with the DF-bit set to 1:

R1#ping 192.168.12.2 repeat 1 df-bit 
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
Packet sent with the DF bit set
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms

ICMP Echo Request

the DF-bit is enabled in the echo request:

Frame 22: 114 bytes on wire (912 bits), 114 bytes captured (912 bits) on interface eth1, id 0
Ethernet II, Src: ICANNIANADep_d6:b9:88 (00:00:5e:d6:b9:88), Dst: ICANNIANADep_e9:7a:d2 (00:00:5e:e9:7a:d2)
Internet Protocol Version 4, Src: 192.168.12.1, Dst: 192.168.12.2
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 100
    Identification: 0x000b (11)
    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: 255
    Protocol: ICMP (1)
    Header Checksum: 0xe239 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.12.1
    Destination Address: 192.168.12.2
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0x7c31 [correct]
    [Checksum Status: Good]
    Identifier (BE): 7 (0x0007)
    Identifier (LE): 1792 (0x0700)
    Sequence Number (BE): 0 (0x0000)
    Sequence Number (LE): 0 (0x0000)
    [Response frame: 23]
    Data (72 bytes)

ICMP Echo Reply

And also enabled in the echo reply:

Frame 23: 114 bytes on wire (912 bits), 114 bytes captured (912 bits) on interface eth1, id 0
Ethernet II, Src: ICANNIANADep_e9:7a:d2 (00:00:5e:e9:7a:d2), Dst: ICANNIANADep_d6:b9:88 (00:00:5e:d6:b9:88)
Internet Protocol Version 4, Src: 192.168.12.2, Dst: 192.168.12.1
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 100
    Identification: 0x000b (11)
    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: 255
    Protocol: ICMP (1)
    Header Checksum: 0xe239 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.12.2
    Destination Address: 192.168.12.1
Internet Control Message Protocol
    Type: 0 (Echo (ping) reply)
    Code: 0
    Checksum: 0x8431 [correct]
    [Checksum Status: Good]
    Identifier (BE): 7 (0x0007)
    Identifier (LE): 1792 (0x0700)
    Sequence Number (BE): 0 (0x0000)
    Sequence Number (LE): 0 (0x0000)
    [Request frame: 22]
    [Response time: 0,319 ms]
    Data (72 bytes)

Conclusion

The ICMP echo reply mirrors the settings of the ICMP echo request, which is why we see the DF-bit set in the ICMP echo reply. This was tested on Cisco IOS. It might be possible to see a different behavior with another client.