3 ms·

> Perhaps understandable given how hilariously little adoption there’s been of jumbo frames on the wider internet. Jumbo frames are not intended¹ to be adopted

> Perhaps understandable given how hilariously little adoption there’s been of jumbo frames on the wider internet. Jumbo frames are not intended¹ to be adopted on the internet, and likely never will be. You need end-to-end control of devices to make sure they work correctly (as the article points out, even PPPoE ⇒ 1492 has PMTU issues on the open internet, it's best practice to run PPPoE on 1508 so you get back to 1500…) But they are very much used inside of administrative domains, e.g. for SANs and cloud interconnects. It's visible when you are a cloud customer, but absolutely not on the open from e.g. your home or mobile internet. [¹] by the current understanding; I have no idea if Internet2 was ever as bold as thinking it might be possible to roll out 9k on the Internet "1".

zamadatix 4y ago
IPv6 got rid of the need to have end-to-end control of devices to get working arbitrary MTU along a path. On the other hand IPv6 also raised the minimum MTU to 1280 and got rid of fragmentation so a lot of big places actually just set 1280 instead.
- fulafel 4y ago
  I think it's only that in v4 the node has the option of requesting MTU discovery, like everyone practically does, or having the on-path routers do fragmentation transparently. In v6 it always works similarly as requesting path MTU discovery in v4 ("don't fragment", aka DF, header bit turned on). So the simplification is that in v6 the legacy mode was eliminated.
  - zamadatix 4y ago
    The change with IPv6 was more than a simplification of removing fragmentation (though that was welcomed since most devices didn't do it anyways). In v4 you had the option to probe, you had to the option play it safe with the minimum 576 bytes, or you had the option to assume it was a larger value. In v6 spec compliant clients must either use the minimum 1280 or probe, the ability to assume anything is no more. The only reason things didn't fall apart in IPv4 despite the rampant blocking of ICMP for "security" reasons is everyone started using TCP which has MSS negotiation and MSS clamping.
beams_of_light 4y ago
MTU is ridiculously difficult in telco networks. Because most transport is moving packets via Ethernet at the endpoints, you’ve got to make sure your customers can use whatever MTU they want, including 9000+. This means a lot of variation in frame size support, even within individual vendor product lines. Now, let’s see here…is a jumbo frame 9000, 9192, 9216, 9500, 10000, 16000 bytes in size? Who knows. That’s just Juniper. Extrapolate this uncertainty to dozens of different vendors and models of networking gear, AND how they each count bytes, interframe gaps, 802.1q and 802.1ad…

zamadatix 4y ago

IPv6 got rid of the need to have end-to-end control of devices to get working arbitrary MTU along a path. On the other hand IPv6 also raised the minimum MTU to 1280 and got rid of fragmentation so a lot of big places actually just set 1280 instead.

fulafel 4y ago
I think it's only that in v4 the node has the option of requesting MTU discovery, like everyone practically does, or having the on-path routers do fragmentation transparently. In v6 it always works similarly as requesting path MTU discovery in v4 ("don't fragment", aka DF, header bit turned on). So the simplification is that in v6 the legacy mode was eliminated.
- zamadatix 4y ago
  The change with IPv6 was more than a simplification of removing fragmentation (though that was welcomed since most devices didn't do it anyways). In v4 you had the option to probe, you had to the option play it safe with the minimum 576 bytes, or you had the option to assume it was a larger value. In v6 spec compliant clients must either use the minimum 1280 or probe, the ability to assume anything is no more. The only reason things didn't fall apart in IPv4 despite the rampant blocking of ICMP for "security" reasons is everyone started using TCP which has MSS negotiation and MSS clamping.

beams_of_light 4y ago

MTU is ridiculously difficult in telco networks. Because most transport is moving packets via Ethernet at the endpoints, you’ve got to make sure your customers can use whatever MTU they want, including 9000+. This means a lot of variation in frame size support, even within individual vendor product lines. Now, let’s see here…is a jumbo frame 9000, 9192, 9216, 9500, 10000, 16000 bytes in size? Who knows. That’s just Juniper. Extrapolate this uncertainty to dozens of different vendors and models of networking gear, AND how they each count bytes, interframe gaps, 802.1q and 802.1ad…