--pgp-sign-Multipart_Wed_Jun_27_04:54:33_2007-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "sb" == Stephane Bortzmeyer <stephane@sources.org> writes:

    sb> Why 33076?

someone explained this to me on some list like this, so I'll take my
best shot at repeating it.

The reasoning is, within the guts of the Internet, asymmetric routing
is the rule rather than the exception---packets usually do not take
the same path A->B as they do B->A, so packets could return on an
interface with larger MTU, and TCP is prepared to take advantage of
this.  For end systems, I guess packets generally do have the same
minimum MTU on some junky symmetric link close to the end system, so
the mss_ifmtu sysctl isn't a crazy thing to do, but don't mistake it
for some kidn of fundamental correctness---it isn't.

but if you had an end system with a 4kByte MTU to the Internet, you'd
probably notice a lot of connetions with asymmetric PMTU's.

I think setting the mss based on MTU is still not ideal even in the
typical end system case because sometimes there are varying size TCP
options?  but since the popular options in actual use change slowly
over the years AIUI the mss_ifmtu trick usually works well.

    sb> apparently, the ICMP "Packet too big" message got lost.

AFAICT, this is the real problem here.  It's ``the PPPoE problem''.
The packet does not just ``get lost''.  Someone is blocking it.
Whatever sysadmin is blocking that toobig ICMP needs a few spankings.
On IPv6 especially, it's absolutely not okay for firewalls to do this.

now...if the toobig message sent doesn't include enough
offending-packet context to properly match the firewall's state entry,
that could be the tcp stack's fault again rather than the firewall's.

--pgp-sign-Multipart_Wed_Jun_27_04:54:33_2007-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iQCVAwUARoIl0onCBbTaW/4dAQIxLQP8CcZPDWFXUP2jW73mDhOxM7WMNKKFdZ+J
T3/x8IzTiV9tNTfMg8Dm/SkREJ1dkUsws+y9Y8BaWoRj63EY3/duIp/K5Kv2qWqg
ZlDcRPn3bgry6HwHyO72HTBvJ03eY9VZQ5V4Hc+VBZqG9K2Y18TWGvjZ4iyQfXwo
ny8L+4By7RQ=
=ZtKG
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Wed_Jun_27_04:54:33_2007-1--