Overview

How Applications Handle MTU

Pushing Up the Internet MTU

Larger MTU - PROs and CONs

Available Large MTU Networks

Ethernet Jumbo Frames

Jumbo Frames Demonstration
TCP Performance
IPv6 Jumbograms
IPv6 Jumbograms

IPv6 (RFC 2460) is the next generation of IP networking protocol. IPv6 was mainly designed to resolve the address space shortage brought by the unexpected growth of the Internet and its adoption of IPv4, and it does so by expanding the addressing scheme from 32bit addresses, to 128bit addresses. This is, however, not the only change brought about by IPv6 to the familiar IPv4 networking environment. We will focus on IPv6's impact on fragmentation and its support of very large frames, sized beyond 65,535 bytes and up to 4GB bytes, adequately called Jumbograms.

IPv6 takes a different approach to MTU than that of IPv4. It recognizes that two separate and inherently different MTU types exist:

  • Link MTU: that is the maximal framing size of the link layer. Frames larger than the Link MTU can not traverse this link.
  • Path MTU: the minimum IPv4 MTU along the path between source and destination.

IPv6 imposes some requirements regarding these MTU:

  • IPv6 nodes must be connected to links supporting a minimum of 1,280 bytes frame.
  • Using RFC 1981 MTU path discovery is a perquisite for using IPv6 on any source node.

Considering the majority of network infra-structures support links of at least traditional Ethernet's 1,500 byte links, it seems easy enough to meet the first requirement. An exception to this may be PPP where the ISP limits node MTU through negotiations. The other requirement is far more problematic, considering that the vast majority of IPv4 stacks shipped with operating systems have this MTU discovery mechanism disabled, and use fixed MTU. The reasoning behind this requirement is another great difference from IPv4 - Packet fragmentation is only allowed at the source!

This is indeed a completely different approach to servicing upper layers. IPv4 permits the upper layers to hand in frames of every size. If the need arises, frames are fragmented at the source station, to meet link layer MTU demands. As the packet traverses through networks with an even smaller MTU, it may also be fragmented. Reassembly is performed at the destination. The approach of IPv6 is stricter. First, applications are discouraged from producing frames that will lead to fragmentation (This however, can hardly be enforced). Second, fragmentation is performed at the source station only, where the fragment size is determined by discovering the MTU through the MTU discovery mechanism mentioned above. Reassembly is performed at the destination station. This approach adheres to the Internet protocol family's 'pushing it to the edges' dogma. It certainly conserves some precious router computational power, enabling them to handle more IPv6 packets per second.

IPv6's fragmentation mechanism will surely benefit from the IETF recommendations to set Internet2 MTU to 9,000 bytes, as it will reduce the need to perform fragmentation, even at the source station. IPv6 Jumbograms however, take MTU demands to a different scale altogether - Jumbograms can be used on links supporting a minimum link MTU of 65,537 bytes, taking the header to payload ratio to a minimum.

Support for Jumbograms seems impossible, considering that the 16bit length field of the IPv6 header seems to prevent us from sending frames larger than 65,535 bytes. Here comes into play IPv6's standardized mechanism for header options.

The IPv6 header is constructed of a minimal set of fields, and zero or more extension headers. These extension headers may contain any number of options:


The IPv6 RFC defines some important extension headers, like the fragmentation header and the hop-by-hop header, and also defines a standard way for the addition of new extension headers and options. One new option, defined in RFC 2675, is the Jumbo payload extension header:


The procedure for sending a Jumbogram sized 65,535 - 4,294,967,295 bytes would be:

  • Set the IPv6 payload length to zero.
  • Create a hop-by-hop extension header, and append the Jumbo payload option to it.

Having the Jumbo payload option within the hop-by-hop extension header, means that every router along the way becomes aware of this packet's unusual size, and will discard it if it needs to traverse a link whose link MTU is smaller than required by the packet size.

While the existence of IPv6 Jumbograms really pushes the IPv4 packet size limit of 65,535 bytes, it also creates some compatibility issues with current implementations of UDP and TCP. The IPv6 Jumbogram RFC clearly states that UDP and TCP implementations need to be modified to support UDP/TCP Jumbograms.

UDP's 16bit length field clearly prevents it from supporting payloads greater than 65,535 bytes. A relaxation to UDP's parsing mechanism allows sending of Jumbograms by setting the UDP length field to zero for payloads beyond 65,535 bytes. The receiver will calculate the true length of the UDP header and payload using the IPv6 Jumbogram payload option.

While TCP has no length field as part of its header, it does have a 16 bit 'urgent' filed used to point to the payload field. While sending Jumbo frames with the 'urgent' bit set, it is not possible to point to data after the first 65,535 octets. To solve this problem, if the 'urgent' offset is greater than 65,535, the TCP frame should be split, so the first part includes all data up to the 'urgent' offset, and the second part the rest of the data.

It is not clear when or whether IPv6 will become the dominant Internet's network protocol, or whether the excessive link MTU demands can be met so Jumbograms can be used. Using Jumbograms certainly maximizes revenues of large MTU networks, as it defines a mechanism enabling the network layer to take advantage of these large MTU.