Comment by mort96 19 hours ago
Nothing's realistically dropping support for v4 any time soon, so v6 support is optional. On the other hand, we're far, far away from all users supporting v6, so v4 support is not optional.
Running a single IP stack is infinitely simpler and easier than running two concurrently, and until that "single IP stack" can be v6, I see very little reason to support it.
I didn't recommend dropping IPv4. It's a terrible it to start a new project in 2024 without IPv6 support though. It's easy enough to build in from the beginning that there's not any real reason not to go for it.
And running a dual stack is trivially easy for almost everyone using it. That chart has almost half of Google's users coming in via IPv6. I promise you less than 1% of that 50% have ever even heard of IPv6, let alone done a single thing to configure it. With my ISP I'd have to go out of my way to turn it off, which I haven't done because this isn't 2008 where it broke things more often than never.
> It's a terrible it to start a new project in 2024 without IPv6 support though.
Why? Radical complexity reduction at essentially no cost to yourself or your customers seems like a tempting proposition.
Exactly! IPv4 management is hideous compared to IPv6 once you grok it. The sooner you upgrade to it, the sooner you can deprecate horrid mitigations like NAT.
Out of curiosity, what parts of NAT management tend to be so horrible in practice?
You're missing the point, I believe intentionally. You can't get away from IPv4 as long as you have users who can't access IPv6-only servers. All your users and potential users can access IPv4-only servers.
Depends on your users; there are, for instance, plenty of phones that only natively have v6 and have to use NAT64 to reach v4 websites. So if you have such users, there might be a benefit to supporting v6 directly.
Its easier to get good latency and bandwidth over v6 than natted v4
What is the latency or bandwidth bottleneck in nat v4?
> Nothing's realistically dropping support for v4 any time soon […]
Or potentially ever, as predicted when IPng was being originally thought about:
We believe that it is not possible to have a "flag-day" form of
transition in which all hosts and routers must change over at
once. The size, complexity, and distributed administration of the
Internet make such a cutover impossible.
Rather, IPng will need to co-exist with IPv4 for some period of
time. There are a number of ways to achieve this co-existence
such as requiring hosts to support two stacks, converting between
protocols, or using backward compatible extensions to IPv4. Each
scheme has its strengths and weaknesses, which have to be weighed.
Furthermore, we note that, in all probability, there will be IPv4
hosts on the Internet effectively forever. IPng must provide
mechanisms to allow these hosts to communicate, even after IPng
has become the dominant network layer protocol in the Internet.
IPv4 at the edge and call it a day.
Why build today with deprecated technology ? Build your infra v6-only, add a layer at the edge to support old clients via IPv4. Job's done.
You should design your infrastructure to avoid paying too much for other people's legacy.
I personally push for IPv6-only internal networks whenever possible, and have deployed several such designs in datacenters.
Unfortunately, a lot of applications are building on platforms where IPv6 is an afterthought if even present at all. Take for example Azure, where IPv6 support is a fucking joke. From core services like Route Server not supporting it, to it being impossible to build v6-only networks due to forced v4 subnet and vNIC requirements, to many services that Microsoft provides only running on v4.
As much as I want to push IPv6 everywhere, that physically cannot happen until companies support it for all use cases. In the mean time dual stacking can be better than nothing but the complexity is non-trivial when the alternative is just running straight v4...
IMO the separate-stack nature of ipv6 was a mistake. I can see why they did it, but the changes could've been a lot more incremental otherwise, and we might've been done already. Everyone talks about the biggest change being the 128-bit address space, but the real leap is that pre-existing ipv4 blocks weren't preserved in ipv6.
The changes couldn’t have been more incremental. Routing hardware only understood the IPv4 header (and at that time I believe a lot of this was baked in silicon). There was no way to create an IPv4+ without needing to replace all the internet’s routers before it could reliably work.
How would have it made it easier to migrate when all of the new blocks wouldn’t be accessible (in either direction) if the traffic passed through any router that hadn’t yet been upgraded? Nobody could really use any of the extended space at all until every single router had been upgraded to this IPv4+.
It is a common misunderstanding (I hear “we could have just made IPv4 bigger” a lot) but apart from the routing issues above (needing to replace every router before it could work at all), the endpoints are also a problem. Nothing in the expanded space could actually call out to a legacy IPv4 endpoint - it could sent packets to it, but that legacy host wouldn’t be able to return packets back since it wouldn’t understand the larger address. And of course the legacy endpoint couldn’t initiate a connection to anything in the extended space either from its side.
So you not only have all the same problems of IPv6 (like needing to upgrade everything), you actually add a bunch of problems of breaking the ability of big parts of the internet from being able to communicate with the rest.
Dual-stack was necessary because everything couldn’t be switched over on the same day. If everything was upgraded at once, your extended-IPv4 idea would work, but otherwise it would break the internet!
I'm on a laptop on an ipv6 only subnet at the moment which mostly does the job with dn64/nat64.
The only benefit of this is to increase familiarity with ipv6. I'm trying to push some colleagues to do an ipv6 only section of our network which has limited interconnect, but there's a lot of concern about devices that still don't support ipv6, and ultimately what's the business reason to do it compared with subnetting 10.0/8 and natting at your firewalls
And many people are happy to not know what an IP address is either. That's fine.
I find it amazing how that lack of curiosity about how computers work extends into modern software developers, I guess that the majority of the industry nowadays are people that do things like "bootcamps" and go into it for the money.
I have no need for ipv6, however I wanted to know about it so spent a couple of hours setting myself up with it. I don't bother with the latest fads that last 3 or 4 years and then are replaced by a new fad, but ipv6 has been around long enough that it's clearly not a fad.
I have plenty of curiosity around how computers work. I've implemented compilers and interpreters, designed CPUs (I made a RISC-V CPU in Logisim which could run programs compiled with clang!), designed ISAs, back in university I had a lot of fun both writing a networking stack from almost-scratch (starting with only C and the raw ethernet packet API in Linux, building toy versions of ARP, IP, routing daemons and TCP) and writing a toy kernel, I have an ongoing game project where I'm writing the engine from scratch in C++ and using plain OpenGL to render, and this past year I've taken up PCB design and CAD. All this just because I want to learn stuff and make stuff. Don't assume that just because someone doesn't share your particular interests, they lack curiosity.
IPv6 has been around long enough that it's clearly a failed project. It's been 30 years and it hasn't even breached 50% adoption. It's not even at the hard part yet, which will be the long tail.
>IPv6 has been around long enough that it's clearly a failed project
You have a very radical definition of "failed". Take your emotions out, and perhaps you would get a more objective evaluation of the technology.
For one, it's very clear that IPv6 has only, truly received global attention after the depletion of IPv4 address space -- someone has already linked the Google IPv6 adoption page, go have a look at it. That means 10~15 years of deployment time, and getting 50% in such a time period is not what I'd describe as a failure.
Secondly, if you are defining failure as "less than 50% prevalence in 30 years" then HTTPS before 2014 will probably fall under the same category too. But we know HTTPS is ubiquitous now ;)
The only way this stuff trickles down to the masses is people that know what they are doing forcing it on them through their products. Very, very few 'engineers' actually go out and learn the state of the art these days in my experience, with most just culting around whatever the current marketing fad is.
Hell just look at SDWAN land and everyone acting like it is the second coming of jesus when it is just a fancy marketed version of technologies that have been available for decades.
Fun fact: US government agencies are required to progressively migrate to IPv6-only environment, beginning with completing at least one pilot of IPv6-only system by FY 2021: https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-0.... Apparently, National Archives decided to pick archived Clinton White House website for this: https://clintonwhitehouse1.archives.gov/