On 23 dec 2007, at 15:49, Joel M. Halpern wrote:
So while the theory clearly says that there is a problem with tunnel mTU, the practice seems to suggest that it works.
Is there some other dimension here that explains the mismatch?
There aren't any problems when the least capable point in the path is at one of the ends. In that case, the host in question obviously won't be sending packets that are larger than the path can support, and the TCP MSS option makes sure that the other end doesn't either. (In theory you could have trouble with non-TCP protocols but most non-TCP traffic uses small packets anyway, the apps that don't tend to use a somewhat conservative packet size and often the DF bit isn't set.)
The problematic situation is the one where the point with the smallest MTU is somewhere in the middle of the path. This happens when users have an ethernet LAN and a CPE that terminates PPP over ethernet, for instance. To avoid support calls, those CPEs intercept TCP SYN packets and modify the TCP MSS option to reflect the MTU of the PPPoE link (1492). I'm sure this is what happens in a lot of VPN gear, too.
Note that the support calls I mentioned aren't theoretical: from experience, I can tell you those WILL happen if you don't do this (or clear the DF bit so that fragmentation can happen anyway).
-- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg