Read the ICMP feedback
02The router reports the MTU of its constricting next hop and quotes enough of the original datagram to identify the affected traffic.
The 36 bytes include the error header and 28-byte quote. The computed checksums can be verified from the displayed bytes; no actual packet is transmitted.
Source for this drawing: RFC 1191 · Read RFC section 4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Next-Hop MTU includes the IP header, not a link-layer header.
- The ICMP header has Type 3, Code 4 and a checksum. The high 16 bits of the formerly unused word MUST be zero; its low 16 bits carry the Next-Hop MTU.
- The MTU counts the largest IP datagram this router can forward unfragmented over that next-hop network, including IP header and data. It does not measure application payload, link framing, bandwidth or the entire reverse path.
- The message quotes the original IPv4 header plus 64 bits of its data. Hosts use the returned header to associate feedback with the relevant path/traffic. Hosts MUST NOT raise a PMTU estimate because a Datagram Too Big message advertises a larger value.
The field layout uses actual 8/8/16 and 16/16 bit widths; quote geometry and dump line wraps are schematic. A complete 36-byte fictional ICMP message includes a 20-byte quoted IPv4 header and 8 TCPbytes; its ICMP and quoted IPv4 checksums are computed. It is not an outer IPv4 packet or actual network traffic. Addresses 192.0.2.10/198.51.100.20 are documentation examples.
Read the RFC section ↗