> -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > RJ Atkinson > Sent: Wednesday, July 20, 2011 2:36 PM > To: ipv6@ietf.org > Subject: Re: PMTUD and MTU < 1280 > > 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.)
IPv6 specs have always said that ICMPv6 packet-too-big for less than the minimum MTU should cause the IPv6 host to send packets (of that minimum MTU size) with an additional fragmentation header. This existed in the first IPv6 RFC, RFC1883 (when the IPv6 minimum MTU was 576): In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 576. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 576, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 528 octets (576 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. and in the current IPv6 RFC, RFC2460: In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. -d > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
