TCP Problems with Path MTU Discovery
RFC 2923
|
| Document |
Type |
|
RFC - Informational
(September 2000; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 2923 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group K. Lahey
Request for Comments: 2923 dotRocket, Inc.
Category: Informational September 2000
TCP Problems with Path MTU Discovery
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This memo catalogs several known Transmission Control Protocol (TCP)
implementation problems dealing with Path Maximum Transmission Unit
Discovery (PMTUD), including the long-standing black hole problem,
stretch acknowlegements (ACKs) due to confusion between Maximum
Segment Size (MSS) and segment size, and MSS advertisement based on
PMTU.
1. Introduction
This memo catalogs several known TCP implementation problems dealing
with Path MTU Discovery [RFC1191], including the long-standing black
hole problem, stretch ACKs due to confusion between MSS and segment
size, and MSS advertisement based on PMTU. The goal in doing so is
to improve conditions in the existing Internet by enhancing the
quality of current TCP/IP implementations.
While Path MTU Discovery (PMTUD) can be used with any upper-layer
protocol, it is most commonly used by TCP; this document does not
attempt to treat problems encountered by other upper-layer protocols.
Path MTU Discovery for IPv6 [RFC1981] treats only IPv6-dependent
issues, but not the TCP issues brought up in this document.
Each problem is defined as follows:
Name of Problem
The name associated with the problem. In this memo, the name is
given as a subsection heading.
Lahey Informational [Page 1]
RFC 2923 TCP Problems with Path MTU Discovery September 2000
Classification
One or more problem categories for which the problem is
classified: "congestion control", "performance", "reliability",
"non-interoperation -- connectivity failure".
Description
A definition of the problem, succinct but including necessary
background material.
Significance
A brief summary of the sorts of environments for which the problem
is significant.
Implications
Why the problem is viewed as a problem.
Relevant RFCs
The RFCs defining the TCP specification with which the problem
conflicts. These RFCs often qualify behavior using terms such as
MUST, SHOULD, MAY, and others written capitalized. See RFC 2119
for the exact interpretation of these terms.
Trace file demonstrating the problem
One or more ASCII trace files demonstrating the problem, if
applicable.
Trace file demonstrating correct behavior
One or more examples of how correct behavior appears in a trace,
if applicable.
References
References that further discuss the problem.
How to detect
How to test an implementation to see if it exhibits the problem.
This discussion may include difficulties and subtleties associated
with causing the problem to manifest itself, and with interpreting
traces to detect the presence of the problem (if applicable).
How to fix
For known causes of the problem, how to correct the
implementation.
Lahey Informational [Page 2]
RFC 2923 TCP Problems with Path MTU Discovery September 2000
2. Known implementation problems
2.1.
Name of Problem
Black Hole Detection
Classification
Non-interoperation -- connectivity failure
Description
A host performs Path MTU Discovery by sending out as large a
packet as possible, with the Don't Fragment (DF) bit set in the IP
header. If the packet is too large for a router to forward on to
a particular link, the router must send an ICMP Destination
Unreachable -- Fragmentation Needed message to the source address.
The host then adjusts the packet size based on the ICMP message.
As was pointed out in [RFC1435], routers don't always do this
correctly -- many routers fail to send the ICMP messages, for a
variety of reasons ranging from kernel bugs to configuration
problems. Firewalls are often misconfigured to suppress all ICMP
messages. IPsec [RFC2401] and IP-in-IP [RFC2003] tunnels
shouldn't cause these sorts of problems, if the implementations
follow the advice in the appropriate documents.
Show full document text