MTU path discovery and IPSec
jmaimon at ttec.com
Thu Dec 4 23:28:08 UTC 2003
Barney Wolff wrote:
>On Thu, Dec 04, 2003 at 05:54:42PM -0500, Valdis.Kletnieks at vt.edu wrote:
>>On Thu, 04 Dec 2003 16:40:45 EST, Joe Maimon <jmaimon at ttec.com> said:
>>>I was wondering would it not be wiser for fraggers to frag in half
>>>instead of just the overflow?
>>There's 2 cases here:
>>1) This is the final frag on the path - if PMTUD is in use, we want to frag
>>right at the overflow so the connection can use the max (so if we're fragging
>>from 1500 down to 1410, they end up with 1410 rather than 750).
>>2) There's an even more restrictive frag further downstream. We frag from 1500
>>to 1460, and somebody else frags from 1460 down to 1410. If you frag at overflow,
>>you end up with a PMTU of 1410. If you fragged it in half, you avoid the second
>>frag but end up with a PMTU of 750.
>>After several dozen packets, the difference between 750 and 1410 will start to become
>That's not how PMTUD works. If DF is set, you discard the packet and
>report back with ICMP. If DF is not set, you frag the packet - but
>that's not PMTUD, because no report ever goes back to the sender.
Probaly better to say that in this day and age PMTUD doesnt work and the
best interoperability feature of IP, the fragmenting is becoming useless
as the internet remains pegged to a 1500 MTU everywhere, with evil hacks
everywhere else to keep things working (mss adjustment/clamping, DF bit
Is there any discussion on better alternatives to PMTUD such as leaving
off DF and a new ICMP subtype, rate limited, to inform senders that
they've been fragged and at what (call it reverse PMTUD?) ? Or how about
a new TCP option (Call it MSSr/s maximum segment size sent/received) for
the receiver to tell the sender if packet sizes are less than
expected/fragged? (again with DF off)?
Does IP6 really do away with fragmenting? Is there any current
discussion on all this?
I see I have to go do some research.
More information about the NANOG