Browse Prior Art Database

IESG Advice from Experience with Path MTU Discovery (RFC1435)

IP.com Disclosure Number: IPCOM000002263D
Original Publication Date: 1993-Mar-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 2 page(s) / 2K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Knowles: AUTHOR

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 100% of the total text.

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.

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