4 ms·
> 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 route
by avidiax 10mo ago
> 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.
- sgjohnson 10mo ago> 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.
- avidiax 10mo agoI 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.
- sgjohnson 10mo agoNot just the edge router. Every router between the ISP edge and the destination edge. And since the goal is “backwards-compatability”, you’d always need to poll, because a “legacy” IPv4 client would also be unable to send packets to the IPv4+ destination. Or receive packets with an IPv4+ source address. And it would be an absolute nightmare to maintain. CGNAT + a quasi backwards-compatible protocol where the backwards-compatability wouldn’t work in practice. So you would have exactly the same problem as IPv6. I can say the same about v4 and v6 today. You could just turn off IPv4 on the internet, and we’d only need to do translation on the edge for the legacy clients that would still use IPv4. You can even put IPv4 addresses in IPv6 packets!
- Dagger2 10mo agoI think you've actually reinvented 6to4, or something morally very close to it. Each v4 address has a corresponding /48 of IPv6 tunnelled to it. The router with that IP receives the tunnelled v6 packets, extracts them and routes them on natively to the end host. This is something that v6 already does, so you don't need to make posts complaining about how dumb they were for not doing it.
- avidiax 10mo agoThat's quite true, but in this counterfactual, IPv4+ doesn't pretend that 6to4 is just a transition mechanism to an all-IPv6 future. That is, IPv4+ is as-if 6to4 was the default, preferred, or only mechanism, and core routers were never demanded to upgrade. It's an edge based solution similar to NAT, but directly addressable. And given that it extends IPv4, I think it would have been much more "marketable" than IPv6 was. But again, this is all counterfactual. The IETF standardized IPv6, and 30 years on it's still unclear that we will deprecate IPv4 anytime soon.
- Dagger2 10mo agoBut we do want a v6-only future, right? We don't want to be running both protocols forever, which is what you'd be asking for.
- p_l 10mo agoNo, 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.
- throw0101a 10mo ago> 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+.
- almosthere 10mo agoBut 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.
- throw0101a 10mo agoYes: but the process would have been exactly the same whether for a hypothetical IPv4+ or the IPng/IPv6 that was decided on; pushing new code to every last corner of the IP universe. How could it have been otherwise given the original network structures were all of fixed lengths of 32 bits?
- frumplestlatz 10mo agoThe new code would have been vastly simpler. IPv6 is second system syndrome personified. What we needed was the equivalent of ASCII->UTF8.
- AmalgatedAmoeba 10mo agoAs someone with non-ascii and non-latin-1 characters in my surname, I can tell you that the ascii->utf8 migration still hasn’t finished.