Masataka Ohta wrote:
Iljitsch;
On 12-dec-03, at 22:24, Theodore Ts'o wrote:
Does that mean that Path MTU was badly designed, because it failed to take into account stupid firewalls?
Yes, PMTUD was badly designed.
No disagreement here.
Path MTU disovery was implemented very poorly because implementations tend expect certain functionality in routers, and usually don't recover when this functionality is absent. (For whatever reason.)
No, it is not an implementation issue.
It is not a good design to periodically send a large packet expecting it is larger than the current path MTU and dropped.
Again, no disagreement. The packet loss is inefficient.
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.
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, the flow label field is needed for other purposes. Second, untrusted routers can't be counted on to record accurate MTU values. Finally, not all forwarding nodes can be counted on to understand IPv6.
The only reliable PMTU information is that which comes from a trusted end node.
Fred ftemplin@xxxxxxxxxxxxxx