Hacker News Reader

Comment by dragonwriter | Hacker News Reader

You can’t just change the size of an IPv4 address without creating a whole new thing.

Yes, but let's not pretend that IPv6 was just IPv4 with a larger addr size. A lot of other unnecessary cruft got changed. That is kinda the issue. Add an extra octet to IPv4, call it IPv5. Done. DHCP (as is) can already handle variable-length addresses so it'll work unmodified for 5-byte addrs, for example. Same for ARP.

I am wondering if we could hack the ipip tunnel to automagically handle a bigger address space.

Much akin to your idea but mostly supported already

But the IPv6 changes are actually good, right? IPv4 was designed for an entirely different world and IPv6 was designed for this world. You're only going to get one chance to make these kind of improvements.

IPv6 has link-local, v4 doesn't. That is a huge configuration win.

IPv4 also has link-local addresses. They belong to the range 169.254.0.0/16.

And is it enabled by default?

Also is it mathematically unique not to cause any potential conflicts.

Yes. 169.254.0.0/24 addresses show up quite often.

> Yes, but let's not pretend that IPv6 was just IPv4 with a larger addr size. A lot of other unnecessary cruft got changed.

Mostly removed (e.g. removing fragmentation). If you're making an incompatible protocol, might as well take the chance to remove the cruft.

> Add an extra octet to IPv4, call it IPv5. Done.

Have fun debugging nondeterministic routing loops lol.

Fragmentation is mostly removed on IPv4 as well. Almost everything sends DF, and there's very little legitimate fragmented traffic. You can just drop fragments wherever convenient. If you want to be nice, it's a good idea to have a small reassembly buffer, but if it's too much work, just drop them.

It's beyond too late to change anything, but I imagine if IPv6 had started with a sensible rollout plan and worked backward from there, it would look somewhat different and it would have taken a lot less time to take hold.

IPv6 doesn't remove fragmentation. IPv6 fragmentation works differently. See https://www.rfc-editor.org/rfc/rfc8200#section-4.5

The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination. (Note: unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path -- see Section 5.)

You can though, there is an options field in IPv4 that could have been made to hold extended address values.

It was used as part of the Extended Internet Protocol: https://www.rfc-editor.org/rfc/rfc1385

And the Address Extension protocol aka IPv7: https://www.rfc-editor.org/rfc/rfc1475

And now you need all routers in your path to support it. Effectively creating two incompatible networks and achieving a worse result.

Routers already support the Options field, it's part of IPv4. The old RFCs mentioned are specifically designed so only routers at the edge need to support them.

You should try reading the specs before making technical claims instead of completely missing the point of why those RFCs were created in the first place.

Instead we have to rehash an argument from 30 years ago.

Reply on news.ycombinator.com