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.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
