On Mon, Dec 03, 2001 at 10:01:48AM -0600, Hal Snyder wrote:
> Martin Husemann <martin@duskware.de> writes:
> 
> > Which still means you have to do it for each and every machine
> > behind a pppoe router. It's hard to cope from our understanding of
> > standards conformance, but we *realy* need a MSS clamping option for
> > routers!
> 
> I'll second that. Setting MTU on routes isn't enough, in the case
> where you have NetBSD on an intermediate router. It will help to have
> a way to clamp (selectively) the MSS hint from a host on the inside as
> it passes through the router out a certain interface or out a certain
> route.

Actually, this problem impacts us so severely for two reasons:

1) We don't always use Path MTU in the default configuration.  So, we use
   an MTU of 1500 for "local" hosts -- and a NAT can make hosts seem "local"
   that are actually not.  If we always used Path MTU, even for "local" hosts,
   a whole class of network configurations would stop giving NetBSD hosts
   such a hard time.

2) Our NAT code appears to corrupt locally-generated needs-frag ICMP
   messages, so a NetBSD router separating, say, an MTU-1400 PPPOE link
   and an MTU-1500 Ethernet will create a Path MTU blackhole.  I have an
   open PR on this, but I last time I looked I couldn't figure out how
   checksum regeneration for locally-generated ICMP messages was *supposed*
   to work, so I couldn't fix it.  

Bug #2 above is really serious and is probably responsible for many users'
complaints about PPPOE and Path MTU.  With it fixed, we "shouldn't need a
terrible hack like MSS clamping; with it there, we probably do.

Thor