MSS rewrite / MSS clamping?

[Jason Fesler]

Thanks everyone.  I'll summarize the questions I saw, in one message here:

Boris Kochergin wrote:
> pf.conf(5) mentions a "max-mss" option for traffic normalization.

Bingo.  That indeed solved what I was after, and had been
overlooking.  For the mailing list archives, my /etc/pf.conf :

| scrub in on em0 inet6 proto tcp to  XXX port 80  max-mss 1220
| scrub out on em0 inet6 proto tcp from XXX to any port 80 max-mss 1220
| pass all

Mike Tancsa says:
> 	I am curious as to where you would be running into MTU issues on IPv6
> where you would need to manually compensate ? Broken tunnel providers ?

First the why: I do see broken PMTU cases on a site (test-ipv6.com).
My hope is, as I have resources contributed, to find a way to effectively
test different MTU's without having multiple NICs and without tricks
like adding a router in the middle with multiple vlans.

As to causes: It can be people who never learned from IPv4 that filtering 
*all* ICMP is bad, are in charge of the ICMPv6 filters.  It can be the 
6in4 tunnel, hits a smaller MTU - but the ICMPv4 message to the tunnel 
origin does not really help the IPv6 origin.  There is the standard, then 
there is reality; I see a *ton* of people with broken PMTUD on IPv6.  :-(

Bjoern A. Zeeb says:
> MSS clamping is a bad workaround for broken PMTU, and the real answer
> really is, get the paths fixed!

Agreed.  But, like IPv4, fixing PMTU is death by a thousand paper cuts, 
especially when you're the content provider side.


Via private email:
> I do this from my dhcpd, it may be feasible in your environment.
> option max-mtu IIRC

In some environments, that may indeed be feasible. In my case, every 
server I touch has a static address, except during OS install.

I also need different IPs to at least emulate different MTUs;
and one wants to use the same MTU across a given broadcast domain.