5

There are many scientific paper for Jumbo frame, even more, some real implementations and deployments. But it is not the case for Jumbogram !!

Jumbo frame (geant frame) for Layer 2; Jumbogram (geant packet) for Layer 3.

From RFC 2675:

Jumbogram are IPv6 packets with payloads between 65,536 and 4,294,967,295 octets

My questions:

  1. Is there any real use of Jumbogram (at least with its minimum payload) at a large scale ?
  2. In case not, is it possible to use it on WAN ? specially with the recent advancement in Ethernet (200 GbE ... 800 GbE), or by using other technologies like: MPLS, tunneling, ...

2 Answers 2

6

Is there any real use of Jumbogram (at least with its minimum payload) at a large scale ?

That is actually a good question - I fail to see any real use case currently.

The RFC states:

Jumbograms are relevant only to IPv6 nodes that may be attached to
links with a link MTU greater than 65,575 octets
, and need not be
implemented or understood by IPv6 nodes that do not support
attachment to links with such large MTUs.

So, lacking common networks with such huge MTUs, jumbograms currently serve little purpose and can be safely ignored. The RFC goes on to point out that currently implemented transport layer protocols may not be able to make use of jumbograms. It also defines ways to make UDP and TCP support jumbograms.

Hence, jumbograms are mainly designed for future use and to make sure that there are no proprietary and subsequently incompatible workarounds, should the necessity arise.

Trying to use fragmented jumbograms on networks with smaller MTU may be possible but doesn't serve any purpose and is detrimental to packet integrity (one lost fragment loses the whole packet).

In case not, is it possible to use it on WAN ? specially with the recent advancement in Ethernet (200 GbE ... 800 GbE), or by using other technologies like: MPLS, tunneling, ...

WAN as in the Internet doesn't support MTUs larger than Ethernet's 1500 bytes (with rare, local exceptions).

WAN as in long-distance connectivity may support MTUs larger than 1500 bytes - but then again it is likely to make use of common transport protocols that might lack support of any packets larger than 216 bytes.

1
  • "I fail to see any real use case currently" – I can see some niche ones in inter-VM communication a la IBM's HiperSockets which is a para-virtualized network socket between VMs that is essentially just a block of shared memory. However, these technologies usually insert themselves even higher in the stack by replacing / augmenting the TCP/UDP socket implementation in the kernel, acting like a NIC with TCP Segmentation Offloading and an infinitely large buffer. Sep 11, 2022 at 11:06
4

IPv6 does not have in-path fragmentation the way IPv4 does, and you cannot depend on an Internet MTU of more than 1500 octets.

IPv6 uses path MTU discovery (PMTUD) to discover the smallest MTU in the path, and it will send packets that fit in that MTU (IPv6 requires an MTU of at least 1280 octets). One way to do that is to have the source host pre-fragment the IPv6 packet using the IPv6 fragment extension header.

You could certainly send an IPv6 jumbogram, but it will be pre-fragmented in the host to multiple IPv6 packets using the IPv6 fragment extension header so that each fit into the smallest MTU in the path.

In reality, there are no data-link protocols that have an MTU even approaching the standard 65,575 (65,535 octet payload and 40 octet header) maximum IPv6 packet size, much less that of an IPv6 jumbogram, so any IPv6 packets larger than the smallest MTU in the path will need to be pre-fragmented.


The reason IPv6 has eliminated in-path fragmentation, putting the burden on the source host, is that puts a real burden on routers, and that slows packet delivery. Certain IPv6 features (fixed header size, no fragmentation, etc.) were designed to reduce the router burden, speeding packet forwarding.

3
  • “Path discovery” is such a fundamental misunderstanding of how the internet works that I can’t believe it’s actually baked into the protocol. What if there are two different paths between hosts? What if there are a thousand!? Sep 11, 2022 at 16:01
  • "Nodes not implementing Path MTU Discovery must use the IPv6 minimum link MTU defined in [RFC8200] as the maximum packet size. In most cases, this will result in the use of smaller packets than necessary, because most paths have a PMTU greater than the IPv6 minimum link MTU. A node sending packets much smaller than the Path MTU allows is wasting network resources and probably getting suboptimal throughput." and "IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater. This is known as the IPv6 minimum link MTU."
    – Ron Maupin
    Sep 11, 2022 at 16:13
  • @JacobKrall, all major OSes implement PMTUD or PLPMTUD. (even for IPv4) If you have something like an IoT device that has a minimal OS and network stack that does not implement PMTUD, you cannot send any IPv6 packets larger than the IPv6 minimum link MTU (1280 octets).
    – Ron Maupin
    Sep 11, 2022 at 16:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.