"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@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@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@aix1.segi.ulg.ac.be> by Andri Pirard pirard@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." "