In your letter dated Wed, 20 Jul 2011 17:35:31 -0400 you wrote: >I am not sure the specs insist that an IPv6 implementation >must treat an ICMPv6 Packet-Too-Big for less than 1280 bytes >as "unrecoverable". (I haven't re-read the IPv6 specs recently.)
Some services, like big DNS server cannot afford to do PMTU. It requires them to store the original DNS reply just in case an ICMP comes back. Without that, the host will see that its first request fails and has to retry. Over time, this will happen again and again because big servers cannot maintain all PMTU state forever. >It is very unfortunate that IPv6 specifies this very large minimum MTU size >(i.e. 1280 bytes), because it is impeding the ability of various organisations > >to deploy IPv6 on a number of existing links that already support IPv4. The root cause of this are routers that don't do fragmentation. Any lower minimum MTU would force any host that cannot maintain PMTU state to fragment in small sizes, which is bad for the 99% of the world that has MTUs bigger than 1280. I'd say that for any link that is mostly reliable, adding a fragmentation layer should not cost more than 16 bits. There are even the payload length, flow label and traffic class fields ready to be abused if need be. So it can we without any increase in length. >IPv4 can run over nearly any link without protocol changes or requiring >special case handling. Sadly, IPv6 cannot make the same claim. One hopes >IPv6 implementers will be tolerant of IPv6 MTUs below 1280 bytes, because >they do exist in the deployed world and aren't going away anytime soon. I don't think that silently doing something that goes against the standard is a good thing. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
