Handle a router that reports zero
04An old router can return a Too Big message with zero in the newly defined MTU field. The host still has to reduce its estimate.
A 1006-octet DF datagram fits 1280. The suggested search stopped below the actual path limit; it has not measured a 1006 link.
Source for this drawing: RFC 1191 · Read RFC section 5 ↗
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.
Unknown MTU is not a zero-byte path.
- Hosts MUST handle old-style messages that omit the Next-Hop MTU (field zero), and MUST never reduce the PMTU estimate below 68 octets.
- Sections 5 and 7 describe implementation suggestions, not protocol requirements. Their historical plateau search chooses the greatest plateau strictly below the corrected quoted Total Length; the table is not a required or current universal MTU list.
- The section 5 compatibility note says: if quoted Total Length is not less than the current estimate, conservatively subtract 4×the quoted IHL (header length in 32-bit words) to allow for an old BSD reporting bug. A zero-MTU message does not authorize an increase.
This worked historical algorithm uses table values 1492 and 1006, current estimate 1500 and actual path 1280. First old quote 1520/IHL 5 corrects to 1500, selecting 1492. Another quote 1512/IHL 5 corrects to 1492, selecting 1006. It converges conservatively below 1280 rather than discovering the exact value. Other strategies, including bounded fallback with DF cleared, are possible; table values should be maintained by implementations.
Read the RFC section ↗