Hacker News Reader

Comment by CountSessine | Hacker News Reader

In theory this could be handled by stuffing the extra 96 bits in an IP extension header. But this solves nothing because then any switch that isn’t IPv4+ aware will route packets incorrectly. Literally every single switch on the internet needs to be updated/replaced before you could start generating IPv4+ traffic otherwise the one outlier will send your IPv4+ packets off to Uzbekistan.

Maybe you don’t use those 96 bits for routing. But then it becomes nothing but a sort of subnet address and you haven’t fixed the routing table size problem. And actually every endpoint needs to upgrade too because endpoints that don’t recognize the header extension will generate crazy responses and confuse TCP packets from different computers as coming from the same machine.

There’s no useful and backward compatible way of extending IPv4.

View on HN

Couple things:

1) Instead of stuffing the extra 96 bits in an extension, you stuff all 128 in the extension and use a reserved unrouted address in the v4 header field. Devices with no clue will just drop those packets.

2) Pedantically, switches are layer 2 devices. Some some of them act as routers also, but only routing is relevant.

Devices with no clue of IPv6 also just drop those packets. What have we gained?

The only thing I can imagine is that while you still need to alter or replace every piece of equipment on the net, software adoption would likely have been much easier and thus immediately higher if 128 bit addresses were the only change (I still don't see the benefit of tucking it in as a field into IPv4, but if IPv6 was just IPv4 with wider addresses), and all the other protocols and semantics that were changed with IPv6 stayed the same. But arguably, since you do need to change every piece of equipment, this was the time to make desirable, fundamental, not-backward compatible changes, and possibly the only opportunity at that.

Even better, instead of using a reserved unrouted address, use the "IP version" header field, which literally exists for this exact purpose.

I'm struggling to see how this would improve anything over what v6 did though.

Or you extend on network level, and even kernel level, but keep programming API compatible. I don't think people like IPv4 packets that much, it is all the APIs which are giving problem.

I bet if we kept everything about IPv6 the same, but (1) made IPV6_V6ONLY mandatory and default to zero (2) did not use colon in IP address representation (3) recommended firewalls use same config rules for IPv4/IPv6 address.. then IPv6 would have significantly higher adoption right now.

That mistake was already baked in to the sockaddr_t ABI.

BSD Sockets were one giant mistake of not enough abstraction and leaky implementation internals like that.

On Windows firewall matches ip4 and ip6 with the same rule. The address field there isn't numeric, but text, and can be ip4 address, ip4 network, ip6 address, ip6 network, address range, gateway or "any". Most rules specify "any" for addresses and focus more on ports, application paths and subprotocols like TCP/UDP.

Reply on news.ycombinator.com