Just to be picky the correct term is data gram, which describes layer 2 segmentation. Packets describe segmentation between switches, which is layer 3.
If you want to be picky, you need to get it right first. The actual term is frame. datagram is generally used to refer to layer 4 operation, and the term is not used anywhere in IEEE 802.3.
Also the GP is correct to say we fossilized on 1500 byte packets, since the layer 3 MTU is the relevant thing when talking about fossilization in the internet at large. This number was driven by 802.3's standard frame size being 1514 bytes, but that one is not even fossilized as much. It takes work, but you can control your own network and roll out jumbo frames. You can't roll out larger packets on the internet.
> You can't roll out larger packets on the internet.
Devil's advocate: why not? We're in the middle of a long-term push for IPv6, and we have interim solutions to help the migration like Teredo tunneling. It's slow going, but we'll get there eventually.
Why don't we start a similar global migration to jumbo frames?
What's the backwards compatibility story here? Send out dual 1500/9000 packets? I don't see how that would work for the billions of devices in the wild without replacing everything but maybe there's a better solution that doesn't take 30 years.
IPv6 also required hardware in the wild to be replaced, but that's not a reason to give up and let things ossify. Over the next 30 years most hardware will be landfilled and replaced anyway. Let's get these improvements into the software stack of new devices now, and then let nature take its course.
> IPv6 also required hardware in the wild to be replaced
I understand that, but it was (is) able to do that in a mostly backwards compatible manner.
My question is: how is that possible with different MTU sizes? Have ISPs support 9000 byte frames and fragment to 1500 bytes for compatibility with the wider internet? Then something like PMTUD can be used to bypass this fragmentation when supported?
To be clear, I would love to have larger MTU sizes. I just don't see a straightforward way to transition everything over. I'm not a network engineer though, maybe there just isn't enough a strong enough impetus for anyone to dedicate the resources to this.
Also not a network engineer. But I'd imagine first the Tier 1 ISPs (Level 3 etc) could enable jumbo frames and make sure they work smoothly amongst each other. After a few years of waiting, new consumer devices/OSs can start trying to send jumbo frames, while setting the Don't Fragment flag. If some router in the path doesn't support 9000, it will signal back ICMP Fragmentation Needed, and the device can transparently resend with 1500. Then add some local caching to avoid the roundtrip for subsequent connections to the same noncompliant network/endpoint.
And since it's a big change anyway, why stop at 9000? Why not 65000? Packets don't have to fill the entire MTU after all. If 65000 is supported, you can choose to send 1500, 9000, or 65000 based on your desired latency/throughput tradeoff.
I'm pretty sure a switch is just an L2 bridge but still uses the ethernet address management mechanism (mac addresses) not the L3 IP (or whatever) address / routing mechanisms.
Modern ethernet, on wires anyhow, is very different from the original one with a shared broadcast ___domain. Ironically, wireless networks are still very much like the original "you've got a piece of wire and everyone yells into it after listening for a short period of time" mechanism.
> Ironically, wireless networks are still very much like the original "you've got a piece of wire and everyone yells into it after listening for a short period of time" mechanism.
Maybe not that ironically since Ethernet derives from ALOHANet, the wireless network connecting Hawaiian schools. Early Ethernet was basically ALOHANet piped over a wire instead of radio waves just like cable tv for a while was just broadcast TV over wires instead of radio waves. https://en.wikipedia.org/wiki/ALOHAnet
Well, the "OSI" model where there's a little disassembly and assembly line in your box, where each layer gets taken off by one robot and the payload of that inside package gets handed off to another concern -- all lies.
The chips that do this (if they've got the features, anyhow) do L2, L3, L4, L5, etc all at the same time. So it's not an L2 switch and L3 router -- it's both at the same time, looking at the whole packet at once.
But -- there is no such thing as an ethernet "router" -- it's just a bridge with a forwarding table populated (usually) by listening for MAC addresses and updating forwarding tables. "flood and learn" There are even less ethernetty things out there that use the ethernet signaling but mechanically populate the forwarding tables of switches.
But a "thing that forwards between vlans" usually means "a thing that forwards packets from one L3 subnet to another."
You could probably make some insane custom switch that has routing rules for forwarding mac address packets from one vlan to another based on a bunch of zany rules, but such a cursed object would be hated universally by all who come after you.
