1 files changed, 115 insertions, 0 deletions
diff --git a/doc/rfc/rfc1435.txt b/doc/rfc/rfc1435.txt
new file mode 100644
index 0000000..414682e
--- /dev/null
+++ b/doc/rfc/rfc1435.txt
@@ -0,0 +1,115 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+Knowles                                                         [Page 1]
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Knowles                                                         [Page 2]
+
+\ No newline at end of file