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(_at_)iprg(_dot_)nokia(_dot_)com