[squeed]

The real problem is that you can no longer look at a fixed offset for your parameters, which complicates filtering silicon.

In other words, if you want to have a firewall rule of "drop tcp 135", in ipv4 you can just look at bytes 0x24-25 (for Ethernet). IPv6's extension-header mechanism means that the header has a non-fixed length, so you need to do work for the same effect. Given that firewalls are critical in a world without NAT, this can be a scary prospect.

Part of the blame falls on vendors who go "well, IPv6 is fringe so we'll just do all firewalling in software." The protocol is 20 years old, it's time to design the silicon.

[verri]

But IPv4 headers could have a variable length too, it's just that we don't encounter that much in the wild. And what about the AH header, GRE and IPIP tunnel headers, 6rd/6in4 tunnel headers, etc. Filtering at fixed offsets sounds very brittle to me. Isn't the real problem here that network providers and administrators appropriate the right to filter on OSI layers they shouldn't be touching? This problem sounds like the exact reason why Google insisted on having its QUIC headers ciphered: so network equipment can't pull of this kind of misbehaviour.

[noselasd]

At least with IPv4 you can easily compute the start of layer 4, it's just ipv4[0]&0xf * 4 - trivially implemented with little real-estate in hardware.

IPv6 requires you to loop through all extension headers to reach layer 4, and you need to know about a handful of those extension headers as not all follow the same format.

[tssva]

Most enterprise firewalls these days do some level of layer 7 packet inspection which requires going beyond looking at fixed offsets. The silicon to support this already exists. Even the $50 Ubiquiti ER-X router I use at home can do deep packet inspection assisted by silicon.