RE: End System PMTUD behavior question

Hemant,

Forgive me if I've misunderstood, but it sounds like you're saying that we should require protocols or applications above IP to always send data in messages small enough to avoid IP fragemntation.

I agree it makes sense for a higher layer to use the PMTU information in IP's cache when it can. Expecting TCP to use the PMTU is perfectly reasonable, as it's already chopping up a byte stream into packets. For protocols which are already packetized, though, I think it's less advantageous to burden them (or the application using them) with the problem of fragmentation and reassembly, to avoid IP fragmentation.

For example, if a user does a "ping -s 1500" to a destination whose PMTU is 1280, the only way to avoid IP fragmentation is for the ping application to split the data into multiple messages, or for IPCMPv6 to do so. Either way, you have to introduce some way to identify them as "ping fragments" and reassemble them in order. That will require changes to the ICMPv6 protocol, I think. Furthermore, you're no longer really doing a "ping 1500", but two pings of 1280 and 220 bytes, respectively.

In the case of an application which sends records in single UDP frames, to avoid fragmentation is must split its messages into MTU-sized chuncks, and come up with a way at the destination to identify and reassemble the chunks in order. This seems a bit unreasonable, given that IPv6 has a perfectly good mechanism to do this already.

So I think the behaviour observed by Thomas during his testing is correct. I don't think ping or ICMPv6 should reduce the ICMP message size to avoid IP fragmentation.

Peter Hunt
Software Engineer
Nokia S&S.