Subject: I-D ACTION:draft-ietf-tcpimpl-pmtud-00.txt

From: [email-masked]
Date: Thu, 07 Jan 1999 10:11:00 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Implementation Working Group of the IETF.

	Title		: TCP Problems with Path MTU Discovery
	Author(s)	: K. Lahey
	Filename	: draft-ietf-tcpimpl-pmtud-00.txt
	Pages		: 15
	Date		: 06-Jan-99
	
   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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tcpimpl-pmtud-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-tcpimpl-pmtud-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-tcpimpl-pmtud-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: John Hanley <[email-masked]>
Date: Wed, 13 Jan 1999 19:21:24 -0800

Thanks for writing up these MTU issues.

FYI, there is a common form of blackhole which may be located very close
to a TCP server (such as a web server).  It might be worth mentioning.

Various vendors have layer-4 "load balancers" which accept port 80 requests
sent to a "virtual IP" and divvy up the work among multiple backend web
servers.  Such a device will use a table or a socket identifier hash
to map particular request packets to a particular server.  When such a
device recieves an ICMP packet saying "fragmentation required", it is
essential that is use that *same* mapping to send the ICMP to the
proper backend server.  (Flooding to all servers Would Be Bad :-(

Detection:

Suppose the backend server implementing PMTUD has at least two IP
addresses besides the loopback address:  one address is subject to the
layer-4 munging and one address gets plain old boring layer-3 service.
Arrange for TCP traffic to be exchanged between a single client IP and both
server IPs, and notice that only conversations which use the "virtual IP"
suffer from blackholing.  The second IP (to avoid munging) is not needed
with some configurations; just use a TCP port other than 80, or use a
protocol other than TCP.

There is one more configuration issue which may be worth mentioning.
Some people believe it is reasonable to use rfc1918 addresses (net 10)
on point-to-point circuits within their cloud.  This causes traceroute
misery if you get "TTL exceeded" ICMPs with source address of 10.0.0.1.
Worse, if you get "frag required" ICMPs with source address of 10.0.0.1,
and a topology-enforcing ACL on some router filters bogus/spoofed
source addresses, then PMTUD sees a blackhole.

	Cheers,
	JH