IESG Advice from Experience with Path MTU Discovery
IESG advice on which ICMP message routers should still send when ICMP suppression is enabled.
Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, DOI 10.17487/RFC1435, March 1993, <https://www.rfc-editor.org/info/rfc1435>.
@misc{rfc1435,
series = {Request for Comments},
number = 1435,
howpublished = {RFC 1435},
publisher = {RFC Editor},
doi = {10.17487/RFC1435},
url = {https://www.rfc-editor.org/info/rfc1435},
author = {S. Knowles},
title = {{IESG Advice from Experience with Path MTU Discovery}},
pagetotal = 2,
year = 1993,
month = mar,
} RFC text
Contents
Network Working Group S. Knowles
Request for Comments: 1435 ftp Software
March 1993
IESG Advice from Experience with Path MTU Discovery
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.
Abstract
In the course of reviewing the MTU Discovery protocol for possible
elevation to Draft Standard, a specific operational problem was
uncovered. The problem results from the optional suppression of ICMP
messages implemented in some routers. This memo outlines a
modification to this practice to allow the correct functioning of MTU
Discovery.
Advice on the Deployment of Path MTU Discovery Protocol
While reviewing the Path MTU Discovery Protocol for Draft Standard
[RFC1191], the Internet Engineering Steering Group (IESG) became
aware from the reports of various implementors that some vendors have
added to their routers the ability to disable ICMP messages generated
by the router. This is to protect older BSD hosts, which would drop
all connections to a host it found an ICMP message on any of the
connections, even if it was a non-fatal ICMP message. While this
protects older BSD hosts, it causes MTU discovery to fail in a
silent, hard to diagnose way.
From the descriptions the IESG has obtained, adjusting the routers to
continue to send ICMP message Type 3 code 4 (destination unreachable,
don't fragment (DF) bit sent and fragmentation required) even when
they have their "don't send ICMP messages" switch turned on would
allow path MTU discovery to work but not effect older BSD hosts,
since they never set the DF bit in their packets.
Author's Note
This document was the result of an IESG meeting discussing MTU
Discovery. This author was chosen to write the document as the
Internet Engineering Task Force (IETF) Internet Area Director.
RFC 1435 IESG Advice from Experience with Path MTU Discovery March 1993
References
[RFC1191] Mogul, J., and S. Deering, S., "Path MTU Discovery",
RFC 1191, DECWRL, Stanford University, November 1990.
Security Considerations
Security issues are not discussed in this memo.
Author's Address
Stev Knowles
ftp Software
2 High Street
North Andover, Ma, 01845
EMail: stev@ftp.com
ISO Plain Language
On this page
§1Why ICMP Suppression Causes a Problem
While reviewing Path MTU Discovery for possible advancement to Draft Standard, the IESG learned that some routers could be configured to disable ICMP messages generated by the router. The reported reason was to protect older BSD hosts, which could drop all connections to a host after receiving an ICMP message on any connection, even a non-fatal message.
The memo says this suppression can make Path MTU Discovery fail silently and make the failure hard to diagnose. Without the router's message, the sender does not learn that a packet needs to be smaller for part of its path.
Some routers suppress ICMP messages to avoid problems with older BSD hosts. But Path MTU Discovery needs a router to report when a packet is too large.
§1The ICMP Message to Keep Sending
The IESG advice is to keep sending ICMP Type 3 code 4, meaning destination unreachable because fragmentation is required while the Don't Fragment (DF) bit is set. Routers should send this message even when their “don't send ICMP messages” switch is enabled.
The memo says this should allow Path MTU Discovery to work without affecting the older BSD hosts described above, because those hosts never set the DF bit in their packets.
Even with general ICMP suppression enabled, a router should report that a packet with DF set is too large to forward without fragmentation. The memo says older BSD hosts are unaffected because they do not set DF.
§3Security Considerations
The memo states that security issues are not discussed. Its subject is router behavior needed for Path MTU Discovery.
The memo does not discuss security. It focuses on keeping a specific router message available to Path MTU Discovery.