PC Bozo's World bites again (CNN, too)

Tue Jun 2 18:02:07 UTC 1998

>"Matt Sommer" writes:
>> Does RFC-879 still have any validity?
>
.
.
>No, that rule is no longer valid qua valid, in so far as negotiation
>and Path MTU discovery make it obsolete.
>
>Perry

ahhh, and 95 has a path mtu discovery problem:

(from Rich Graves (mailto:win95netbugs-owner at lists.stanford.edu)
http://burks.bton.ac.uk/burks/pcinfo/osdocs/hansie/nwtcpip.htm#c10  )

"If you can't send mail or news longer than 10 lines or so, or if you can't
upload files with FTP or Microsoft networking, this is likely your problem.
Downloads (from the net to your PC) are not affected. This assumes that you
can upload files and send one-line messages fine; if not, you have a more
fundamental problem. If the technical and political details don't interest
you, skip them.

In late November, Microsoft finally documented this known problem in
Knowledge Base Article Q138025. However, they got it wrong, because the
Usenet article that Microsoft evidently copied,
<199509242223.PAA04539 at Networking.Stanford.EDU>, was unclear (my fault). In
late December or early January, after reading this FAQ repeatedly through
the tide and jericho proxy servers, Microsoft removed this article and every
other mention of the PathMTU problem from the Knowledge Base. Apparently
it's just to embarrassing to leave documented. I would appreciate it if
Microsoft would please mail me when they have restored and corrected the KB
article, so that I can remove this paragraph from the FAQ.

Anyway, the problem, as originally diagnosed in article
<443n5c$ff9 at aix1.segi.ulg.ac.be> by Andri Pirard pirard at vm1.ulg.ac.be, is
that Microsoft does MTU path discovery according to RFC 1191 (written in
1990 by folks from DEC and Stanford University), but many routers don't.
Since Microsoft jumped on the TCP/IP bandwagon so late, they apparently
don't understand that a standard only drafted in 1990 is an infant not
likely to be adopted Internet-wide.

To fix this problem, run RegEdit.EXE and open it to the following key:

Hkey_Local_Machine\System\CurrentControlSet\Services\VxD\MSTCP

Create the following binary variable with a value of 1:

PMTUBlackHoleDetect = 0 or 1

This should always fix the problem, unless there's a bug in their code, and
we know that couldn't happen. If this doesn't solve the problem, create this
variable in the same place:

PMTUDiscovery = 0 or 1

Now, this is where I believe Microsoft gets it wrong. Knowledge Base Article
Q138025 says to create this with a binary value of 1. This does nothing. You
really want to create it with a value of 0.

Setting MTU to some ridiculously low value is another effective way to fix
the problem, but it hurts performance -- except over dialup, where an MTU of
576 or so might be a good idea anyway, especially if you have a cheap modem
whose buffering doesn't work well.

All other TCP/IP stacks available for DOS and Windows fragment properly
according to existing Internet standards. You'll only see this problem with
the stack that Microsoft includes "free." "