[ On Sat, November 21, 1998 at 07:24:04 (-0500), Perry E. Metzger wrote: ]
> Subject: Re: SOLVED! The cause of puzzling TCP (eg. WHOIS) connection failures with some InterNIC.net hosts 
>
> This totally violates the required behavior of routers. It is a
> bad idea. Among other things, it probably breaks path MTU
> discovery.

Where in the heck did you get that idea?  My proposal fixes broken PMTUD
(i.e. when it doesn't work and the connection fails because big packets
get stuck somewhere in the middle), but it certainly wouldn't cause any
existing, working, PMTUD implementations to fail.  My proposed fix only
kicks in after initial attempts at co-operating with PMTUD have already
failed.

> I'd very strongly suggest forgeting about this.

Actually a simpler fix has been proposed, which may need a wee bit of
tweaking to not cause problems with PMTUD, but which would totally avoid
all scaling and log abuse problems (at the cost of leaving these
problems, assuming they are problems, blowing in the wind -- i.e. they
go un-noticed).

*Something* needs to be done since it's clear that there will be ongoing
problems with broken PMTUD.  Either the protocol needs fixing (and I
admit I've not yet read the RFCs to see if the problem is actually in
the protocol, or just in NetBSD-1.3.2's implementation of it), or
work-arounds to possible possible protocol design problems do need to be
made available.  I currently cannot get e-mail from at least one known
site unless either they fix their firewall or I find some way to ensure
the path MTU is 1500 bytes all the way through.  Since I can't control
their firewall, and I have other reasons not to want to change the path
MTU in this case, I want to find some way to disable PMTUD on my end.
That means either breaking PMTUD by always ignoring the DF bit, or
finding some way of ignoring the DF bit after PMTUD has failed to get
the packet size down as necessary.

If indeed PMTUD is not robust as designed then "we" also should be
putting forward proposals to get it fixed at the RFC level.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>