Comment by hypeatei
5 days ago
> A much better solution here would have been an incredibly conservative change to ipv4 to expand the number of available address space
"And what do you base this belief on?
Fact is you'd run into exactly the same problems as with IPv6. Sure, network-enabled software might be easier to rewrite to support 40-bit IPv4+, but any hardware-accelerated products (routers, switches, network cards, etc.) would still need replacement (just as with IPv6), and you'd still need everyone to be assigned unique IPv4+ addresses in order to communicate with each other (just as with IPv6)."[0]
> Fact is you'd run into exactly the same problems as with IPv6.
If you treat IPv4 addresses as a routable prefix (same as today), then the internet core routers don't change at all.
Only the edge equipment would need to be IPv4+ aware. And even that awareness could be quite gradual, since you would have NAT to fall back on when receiving an IPv4 classic packet at the network. It can even be customer deployed. Add an IPv4+ box on the network, assign it the DMZ address, and have it hand out public IPV4+ addresses and NAT them to the local IPv4 private subnet.
IPv6 seems to be a standard that suffered from re-design by committee. Lots of good ideas were incorporated, but it resulted in a stack that had only complicated backwards compatibility. It has taken the scale of mobile carriers to finally make IPv6 more appealing in some cases than IPv4+NAT, but I think we are still a long way from any ISP being able to disable IPv4 support.
> Only the edge equipment would need to be IPv4+ aware.
"Only"? That's still the networking stack of every desktop, laptop, phone, printer, room presentation device, IoT thing-y. Also every firewall device. Then recompile every application to use the new data structures with more bits for addresses.
And let's not forget you have to update all the DNS code because A records are hardcoded to 32-bits, so you need a new record type, and a mechanism to deal with getting both long and short addresses in the reply (e.g., Happy Eyeballs). Then how do you deal with a service that only has a "IPv4+" address but application code that is only IPv4-plain?
Basically all the code and infrastructure that needed to be updated and deployed for IPv6 would have to be done for IPv4+.
But the desktop/laptop/phone/printer was the EASIEST thing to change in that 30 year history. And it would have been the easiest thing to demand a change req from a company for.
7 replies →
And in 30 years, all of that has basically already happened and afoption is still absymal.
14 replies →
No, routers would have to be fixed anyway, because even if you put extra bits into extension header we have 30 years of experience that routers and ISPs will regularly fuck around with those extra bits - it's related to why we have TLS GREASE option.
Application rework would be exactly the same as with v6, because the issue was not with v6 but with BSD Sockets API exposing low-level details to userland.
> Only the edge equipment would need to be IPv4+ aware. And even that awareness could be quite gradual, since you would have NAT to fall back on when receiving an IPv4 classic packet at the network. It can even be customer deployed. Add an IPv4+ box on the network, assign it the DMZ address, and have it hand out public IPV4+ addresses and NAT them to the local IPv4 private subnet.
Congratulations, you’ve re-invented CGNAT, with none of the benefits, and the additional hassle of it being an entirely new protocol!
No. No “extra bits” on an IPv4 address would have ever worked. NAT itself is a bug. Suggesting that as an intentional design is disingenuous.
I have not "reinvented CGNAT". It is hierarchal public addressing similar to IPv4 and IPv6.
The edge router has an IPv4+ subnet (either a classic v4 address, or part of a v4+ address). It maintains an L2 routing table with ARP+, and routes IPv4+ packets to the endpoint without translation. Private subnetting and NAT is only needed to support legacy IPv4 clients.
CGNAT pools IPv4 public addresses and has an expanded key for each connection, and translates either 4 to 6 or into a private IPv4 subnet. My proposal needs no pooling and only requires translation if the remote host is IPv4 classic and the edge router is not assigned a full IPv4+/24.
4 replies →
I agree with that belief, and I've been saying it for over 20 years.
I base it on comparing how the IPv2 to IPv4 rollout went, versus the IPv4 to IPv6 rollout. The fact that it was incredibly obvious how to route IPv2 over IPv4 made it a no-brainer for the core Internet to be upgraded to IPv4.
By contrast it took over a decade for IPv6 folks to accept that IPv6 was never going to rule the world unless you can route IPv4 over it. Then we got DS-Lite. Which, because IPv6 wasn't designed to do that, adds a tremendous amount of complexity.
Will we eventually get to an IPv6 only future? We have to. There is no alternative. But the route is going to be far more painful than it would have been if backwards compatibility was part of the original design.
Of course the flip side is that some day we don't need IPv4 backwards compatibility. But that's still decades from now. How many on the original IPv6 will even still be alive to see it?
The IPv2 to IPv4 migration involved sysadmins at less than 50 institutions (primarily universities and research labs), updating things they considered to be a research project, that didn’t have specialised network hardware that knew anything about IP, and any networked software was primarily written either by the sysadmins themselves or people that one of them could walk down the corridor to the office of. Oh, and several months of downtime if someone was too busy to update right now was culturally acceptable. It’s not remotely the same environment as existed at the time of IPv6 being designed
Hardware would catch up. And IPv4 would never go away. If you connect to 1.1.1.1 it would still be good ole IPv4. You would only have in addition the option to connect to 1.1.1.1.1.1.1.2 if the entire chain supports it. And if not, it could still be worked around through software with proxies and NAT.
So... just a less ambitious IPv6 that would still require dual-stack networking setups? The current adoption woes would've happened regardless, unless someone comes up with a genius idea that doesn't require any configuration/code changes.
I disagree. The current adoption woes are exactly because IPv6 is so different from IPv4. Everyone who tries it out learns the hard way that most of what they know from IPv4 doesn't apply. A less ambitious IPv4 is exactly what we need in order to make any progress
26 replies →
Sort of. I think people would understand
201.20.188.24.6
And most of what they know about how it works clicks in their mind. It just has an extra octet.
I also think hardware would have been upgraded faster.
11 replies →
The main thing is keeping current addresses, not having both an ipv4 and ipv6 address.
Just like for an apartment you append something like 5B. And for a house you don't need that.
Hardware support for ipv6 hasn't been the limiting factor in a long time. Users higher on the stack don't want to adopt something that makes so many unnecessary changes.
You’re focusing on the technical difficulty of implementing it in software. This is not the problem. IPv6 support is now present in almost every product, but people still refuse to set it up because it’s so different to what they’re used to (I’m not arguing whether the changes are good - they’re just changes). IPv4+ would’ve solved this social problem.
There’s absolutely, utterly zero chance IPv4+ would be adopted. CGNAT is the solution to the social problem.
I don’t even buy your way of thinking - unlike an “engineering” solution or an “incentives” solution, the problem with “social solutions I speculate about” is: they offer nothing until implemented. They are literally all the same, no difference between the whole world of social solutions, until they are adopted. They are meaningless. They’re the opposite of plans.
Like what’s the difference between IPv4+, which doesn’t exist, and “lets pass a law that mandates ipv6 support”? Nothing. This is what the mockery of “just pass a law” is about. I don’t like those guys, but they are right: it’s meaningless.
This is a good point. The same “why should I migrate” would affect it. However, it being so close to the predecessor, it would be much easier to do so, catching way more people who are on the fence.
The IPv4+ could pass through a router that doesn't know about it - the cloud host that receives that packet could interpret it in a special way, in fact you could stuff additional data into the next layer of the stack for routing - it's not like many services beyond TCP would need to support the scheme.
> The IPv4+ could pass through a router that doesn't know about it
It couldn't do that reliably. We don't have any flags left for that that. Options are not safe. We've got one reserved flag which is anyways set to 0, so that's not safe either.
> We don't have any flags left for that that.
There's the reserved bit (aka the evil bit[1]). Are you saying gear out there drops packets with reserved bit set to 1? Wouldn't surprise me, just curious.
Seems like IPv4+ would have been a good time to use that bit. Any IPv4+ packets could have more flags in the + portion of the header, if needed.
[1]: https://en.wikipedia.org/wiki/Evil_bit
3 replies →