Fred Templin;
It should have been designed into TCP over IPv4 and should have
never set don't fragment bit. TCP should be able to know that
packets are reassembled at the IP layer.
Yes - it would have been great if this was designed into the
architecture way back when. But it wasn't, so it would be up
to receiving implementations to add hooks into the IPv4
reassembly cache if they want to inform the TCP of
fragmentation.
As IP and TCP are implemented with a lot of interference,
which is a good thing, it was OK to modify both IP and TCP
to introduce properly designed PMTUD.
IPv6 was badly designed. IPv6 should never use PMTUD and TCP over
IPv6 should work with PMTU of 1280, unless it gets OOB information
that all the pathes have larger MTU. An alternative was to let routers
record MTU, say, in flow label field.
Huh?
First, this is an alternative for those who insits on having
PMTUD. I prefer to just send 1280B.
First, the flow label field is needed for other purposes.
Because of the interaction between fragmentation and QoS assurance,
PMTU of QoS assured flow must also be assured that only best effort
packets need to reuse the unused 16 bit of the field.
Second, untrusted routers can't be counted on to record
accurate MTU values.
It was possible to specify all the IPv6 routers behave so without
having backward compatibility problem.
Finally, not all forwarding nodes
can be counted on to understand IPv6.
What is the problem?
When you receives an IPv6 packet, all the routers on the path
of the packet is IPv6 capable.
The only reliable PMTU information is that which comes
from a trusted end node.
As P of PMTU means PATH, the end node does not have PMTU
information, unless the information is collected by routers
on the path.
Masataka Ohta