> Ok, this will be the fact i need for decision... for now. Because RP seems to
> be the only one to fix the MSS problem.

There is no such thing as a MSS problem. There are some sites that insist
on doing PMTU discovery while blocking all ICMP traffic on their firewalls.
Those are destined to loose for everything with untypical MTUs somewhere
along the path.

With a PPPoE connection, it is probably not a good idea to use PMTU discovery
without working blackhole detection yourself.

> How about MSS
> rewriting in this kernel pppoe stuff? I don't think this is implemented there,
> as i didn't see anything lokking as this.

Routers don't look inside TCP headers.

If you are doing NAT, though, clamping the MSS might be OK for the NAT
machine. (Which has the overhead of recalculating all TCP checksums anyway).
The way to implement this would be an IPF config option to make IPF rewrite
the MSS. Such an option does not exist (AFAICT).

But, to repeat, I do not see any problem with the default MSS of NetBSD or
Windows machines behind a NetBSD-current pppoe router + NAT machine (which
is not fiddling with the MSS). I saw the strong recomendation in the rp-pppoe
docs, but I don't see real lossage (besides a single site with a broken 
firewall I encountered so far).


Martin