Subject: Re: ip reassembly time exceeded?
To: None <current-users@NetBSD.ORG>
From: Christian Kuhtz <firstname.lastname@example.org>
Date: 01/27/1997 12:03:11
Ok, let me rephrase it. I have never seen anyone use a larger MTU than 296
bytes over a modem line in the years that I had used it before PPP was
Besides, dragging out RFC standards in an attempt to describe SLIP is futile. ;-)
The fact is that most SLIP implementations weren't standards compliant, and
the standards were most of the time written after the damage had already been
done and all sorts of incompatible implementations were out there. That's one
of the biggest reasons why everybody so readily embraced PPP as the savior.
Again, I cannot remember anyone using MTU's other than 296 at the time when
SLIP was the only game in town. Heck, there were implementations around that
didn't support anything else *but* 296.
On Mon, 27 Jan 1997 13:33:50 -0500, "John F. Woods"
> >SLIP has always been a 296 byte MTU.
> RFC 1055 declines to be so forceful as to assert a fixed standard size
> (it is, after all, a "non-standard") but it documents the Berkeley 1006 byte
> MTU and strongly suggests that implementations not send more than that, as
> well as being prepared to accept that much.
> I seem to recall that Romkey's original PC implementation used 2002 bytes,
> though I could be misremembering that.
> Two sides of a SLIP line can, of course, be configured for anything you like
> (in fact, they HAVE to be, which was a primary motivation behind PPP (the
> other major motivation being the desire to transport protocols which IP
> hadn't finished exterminating)), but the assertion that "SLIP has always been
> a 296 byte MTU" is simply wrong.
Christian Kuhtz <email@example.com>
".com is a mistake."