Reply to comment:

Ole Trøan
The explanation for the 1280 minimum IPv6 MTU can we found in a post from Steve Deering to the ipng mailing list on November 13th 1997. Message-Id: <v03110702b0598e80008d@[]> In the ipngwg meeting in Munich, I proposed increasing the IPv6 minimum MTU from 576 bytes to something closer to the Ethernet MTU of 1500 bytes, (i.e., 1500 minus room for a couple layers of encapsulating headers, so that min- MTU-size packets that are tunneled across 1500-byte-MTU paths won't be subject to fragmentation/reassembly on ingress/egress from the tunnels, in most cases). After the short discussion in the Munich meeting, I called for a show of hands, and of those who raised their hands (about half the attendees, if I recall correctly), the vast majority were in favor of this change -- there were only two or three people opposed. However, we recognized that a fundamental change of this nature requires thoughtful discussion and analysis on the mailing list, to allow those who were not at the meeting and those who were there but who have since had second thoughts, to express their opinions. A couple of people have already, in private conversation, raised some concerns that were not identified in the discussion at the meeting, which I report below. We would like to get this issue settled as soon as possible, since this is the only thing holding up the publication of the updated Proposed Standard IPv6 spec (the version we expect to advance to Draft Standard), so let's see if we can come to a decision before the ID deadline at the end of next week (hoping there isn't any conflict between "thoughtful analysis" and "let's decide quickly" :-). The reason I would like to increase the minimum MTU is that there are some applications for which Path MTU Discovery just won't work very well, and which will therefore limit themselves to sending packets no larger than the minimum MTU. Increasing the minimum MTU would improve the bandwidth efficiency, i.e., reduce the header overhead (ratio of header bytes to payload bytes), for those applications. Some examples of such applications are: (1) Large-fanout, high-volume multicast apps, such as multicast video ("Internet TV"), multicast netnews, and multicast software distribution. I believe these applications will end up limiting themselves to packets no large than the min MTU in order to avoid the danger of incurring an "implosion" of ICMP Packet-Too-Big messages in response. Even though we have specified that router implementations must carefully rate-limit the emission of ICMP error messages, I am nervous about how well this will work in practice, especially once there is a lot of high-speed, bulk multicasting happening. An appropriate choice of rate or probability of emission of Packet-Too-Big responses to multicasts really depends on the fan-out of the multicast trees and the MTUs of all the branches in that tree, which is unknown and unknowable to the routers. Being sensibly conservative by choosing a very low rate could, in many cases, significantly increase the delay before the multicast source learns the right MTU for the tree and, hence, before receivers on smaller-MTU branches can start receiving the data. (2) DNS servers, or other similar apps that have the requirement of sending a small amount of data (a few packets at most) to a very large and transient set of clients. Such servers often reside on links, such as Ethernet, that have an MTU bigger than the links on which many of their clients may reside, such as dial-up links. If those servers were to send many reply messages of the size of their own links (as required by PMTU Discovery), they could incur very many ICMP packet-too-big messages and consequent retransmissions of the replies -- in the worse case, multiplying the total bandwidth consumption (and delivery delay) by 2 or 3 times that of the alternative approach of just using the min MTU always. Furthermore, the use of PMTU Discovery could result in such servers filling up lots of memory withed cached PMTU information that will never be used again (at least, not before it gets garbage-collected). The number I propose for the new minimum MTU is 1280 bytes (1024 + 256, as compared to the classic 576 value which is 512 + 64). That would leave generous room for encapsulating/tunnel headers within the Ethernet MTU of 1500, e.g., enough for two layers of secure tunneling including both ESP and AUTH headers. For medium-to-high speed links, this change would reduce the IPv6 header overhead for min MTU packets from 7% to 3% (a little less than the IPv4 header overhead for 576-byte IPv4 packets). For low-speed links such as analog dial-up or low-speed wireless, I assume that header compression will be employed, which compresses out the IPv6 header completely, so the IPv6 header overhead on such links is effectively zero in any case. Here is a list of *disadvantages* to increasing the IPv6 minimum MTU that have been raised, either publically or privately: (1) This change would require the specification of link-specific fragmentation and reassembly protocols for those link-layers that can support 576-byte packets but not 1280-byte packets, e.g., AppleTalk. I think such a protocol could be very simple, and I briefly sketch such a protocol in Appendix I of this message, as an example. Often, those links that have a small native MTU are also the ones that have low bandwidth. On low-bandwidth links, it is often desirable to locally fragment and reassemble IPv6 packets anyway (even 576-byte ones) in order to avoid having small, interactive packets (e.g., keystrokes, character echoes, or voice samples) be delayed excessively behind bigger packets (e.g., file transfers); the small packets can be interleaved with the fragments of the big packets. Someone mentioned in the meeting in Munich that the ISSLL WG was working on a PPP-specific fragmentation and reassembly protocol for precisely this reason, so maybe the job of specifying such a protocol is already being taken care of. (2) Someone raised the concern that, if we make the minimum MTU close to Ethernet size, implementors might never bother to implement PMTU Discovery. That would be regrettable, especially if the Internet evolves to much more widespread use of links with MTUs bigger than Ethernet's, since IPv6 would then fail to take advantage of the bandwidth efficiencies possible on larger MTU paths. (3) Peter Curran pointed out to me that using a larger minimum MTU for IPv6 may result in much greater reliance on *IPv4* fragmentation and reassembly during the transition phase while much of the IPv6 traffic is being tunneled over IPv4. This could incur unfortunate performance penalties for tunneled IPv6 traffic (disasterous penalties if there is non-negligible loss of IPv4 fragments). I have included Peter's message, describing his concern in more detail, in Appendix II of this message. (4) Someone expressed the opinion that the requirement for link-layer fragmentation and reassembly of IPv6 over low-cost, low-MTU links like Firewire, would doom the potential use of IPv6 in cheap consumer devices in which minimizing code size is important -- implementors of cheap Firewire devices would choose IPv4 instead, since it would not need a fragmenting "shim" layer. This may well be true, though I suspect the code required for local frag/reasm would be negligible compared to the code required for Neighbor Discovery. Personally, I am not convinced by the above concerns that increasing the minimum MTU would be a mistake, but I'd like to hear what the rest of the WG thinks. Are there other problems that anyone can think of? As I mentioned earlier, the clear consensus of the Munich attendees was to increase the minimum MTU, so we need to find out if these newly-identified problems are enough to swing the consensus in the other direction. Your feedback is heartily requested. Steve