Todd wrote:

> > This still won't do a uniform application, because the router machine
> > itself won't get the attribute, since NAT only affects machines
> > *other than* the router.

Yes, but the NAT router itself is not affected by the problem, as long
as it has net.inet.tcp.mss_ifmtu=1.

> >  (From an aesthetic perspective, that's very
> > `dirty'.  8-)

Sure. MSS clamping is dirty. It's cheating. We are lying about our TCP
stacks capabilities to make broken systems not fail over their own errors.

But see below.

der Mouse replied:

> Perhaps ipfilter might be the right place?  Or does it not rewrite
> packets at present?

Yes, and that's where my first suggestion puts it.
On a side note I think it is important (my NAT routers are slow sparcs!)
to keep the number of times the packet checksum is touched to a minimum.

> As long as it's done in a way that doesn't bloat things for people who
> don't want it (for example, anything that has to go in a common
> codepath should disappear completely in the absence of "options
> MSS_CLAMPING_KLUDGE" (or whatever it's called)).

That is true. And of course we won't have this cludge enabled by default
(but turning it on needs to be simple).

My current view of the world is:

 - I'd like to have it in ip_nat.c like I initialy proposed. For many 
   applications this will be enough. That's the "it is ready, tested,
   and works for me" part.

 - A second variant can go into ip_forward, guarded by "options MSS_CLAMPING",
   enabled per route via a routing metric ("route add default
   -mssclamp 1452 <dest>"). If zero nothing happens, if != zero the
   clamping is active for this route.

It's unclear to me at the moment if using the second variant and doing NAT
together would degrade performance. If not, I could live with having only the
second version available.

Martin