Earlier, Brian Carpenter wrote: > It's always been my understanding that an interface sending IPv6 packets > MUST implement some (unspecified) form of framentation and reassembly > *below layer 3* if the link MTU is less than 1280. In other words a > PTB for a packet of length 1280 is an unrecoverable violation.
I also understand that the IPv6 specifications say that the minimum IPv6 MTU for any link type is 1280 bytes. 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.) I understand that some deployed IPv6 implementations will tolerate and support Packet-Too-Big messages with a link MTU at least as small as 576 -- following the Postel Principle of "generous in what one accepts" and being practical about several radio link technologies that do not support a 1280 byte IP MTU. Such implementations are more resilient than the IPv6 specifications require; this is helpful. > For example, if you're tunneling IPv6 over an IPv4 network whose PMTU > (to the other end of the tunnel) is, to take a random example, 576, > the tunnel end points could use IPv4 fragmentation and reassembly > to provide a 1280 MTU for the IPv6 traffic. One could do that. Over low-bandwidth radio links the overhead of doing that would effectively make it preferable to deploy an IPv6::IPv4 translator or some other protocol translation scheme (and continue with IPv4 forever, at least on that link) than to encapsulate IPv6 in anything more than just the radio link layer just to meet the 1280 byte requirement. As I recall, I noted this problem to the IPv6 WG back in the middle 1990s.[1] Sadly. that prediction seems to have come true. So I understand that today, over some deployed radio link technologies, several IPv6 implementations use the raw link encapsulation and fragment IPv6 into chunks at that raw link MTU size (even though that is below 1280 bytes). > Of course this doesn't cover the NAT64 case; so what? NAT breaks many things. > We just have to rely on the real world, where the layer 2 link MTU is pretty > much always 1500 today. I agree that the IEEE standard Ethernet link MTU is very widely deployed today. Many, possibly most, Ethernet switches also support a link MTU somewhat over 9K bytes. I'm told that SONET links most commonly use the old FDDI link MTU (roughly 4500 bytes). ATM links, which seem to be going away, most commonly support an IP MTU near 9180 bytes (which value seems to have driven the Jumbo Ethernet implementations). However, there are still a number of link types, mostly radio link types (as near as I can tell), that have a link MTU well below 1280 bytes. As near as I can tell, IPv6 would have been much better off selecting 512 bytes as the minimum IPv6 MTU size.[1] 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. This is just the kind of obstacle to deployment that IPv6 does not need. Specifying the value 1280 is not solving a real technical problem, IMHO. A lower value would facilitate faster, easier, simpler, and more widespread deployment and use of IPv6, IMHO. 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. Yours, Ran Atkinson [1] <ftp://ftp.ietf.org/ietf-online-proceedings/94dec/area.and.wg.reports/ipng/ipngwg/ipngwg-minutes-94dec.txt> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
