>From Christian Kuhtz <ckuhtz@paranet.com>:
> 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"  
> <jfw@jfwhome.funhouse.com> wrote:
> > >SLIP has always been a 296 byte MTU.
> >
> > "always"?
> >
> > 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.

Here's the top 10 IP packet sizes as measured from a backbone router

Size (bytes)  Probability (%)
    40           44.8
   552            9.2
  1500            6.8
   576            5.8
    44            4.7
    52            1.2
    48            0.9
    41            0.8
    56            0.7
   296            0.7

(this is from a list of 1800 distinct sizes, so these really are popular).

I'd conclude two things:

(1) 296 is a frequently occurring packet size, so something is frequently
    choosing this as a link MTU.  My guess would be that the first paragraph
    above is pretty accurate.

(2) 296 is so frequently occurring that I wouldn't want to bet the problem
    is entirely the fault of the Microsoft software, as one would assume
    they would have had plenty of opportunity to notice by now and fix it
    (I'm pretty sure the 552 in second place is microsoft's preferred number,
    so there may be a lot of those machines out there).  It hence might be a
    bit dangerous to assume that the NetBSD kernel is entirely blameless in
    this.

Dennis Ferguson