The main problem with IPv6 is that it is different from IPv4. There's SLAAC, there's no ARP and there're also some other differences. In the end, it's simpler to just not bother.
If IPv6 was going to be successful, it would have been successful years ago. It seems, people are just more comfortable with layers of NAT than native IPv6 everywhere. I'd guess that it should have been more backwards compatible. Similar to UTF-8 and ASCII.
My Verizon connection has a CGNAT IPv4 and a publicly routable IPv6 address. It's at least partly a success, if you're using a cell phone on Verizon in the US.
IPv4 has been "in crisis" for the entire 20 years I've worked in tech and we seem to be managing alright. Not to say things can't be better or we shouldn't try to improve. But I'll be surprised if v4 isn't still the default for most use cases in another 20 years.
Part of the issue is this affects different countries differently, based on residential IP allocations to household ratios. I am currently on CGNAT in Australia split 256 ways, and any site that doesn't support IPv6 can be borderline unusable. I can't imagine what it's like in countries with worse ratios, like India.
It's been in crisis for decades, but it's also getting increasingly worse every year.
If UTF-8 represents the triumph of a design prioritizing backwards compatibility with an existing standard (ASCII) to facilitate a transition, then IPv6 is the cautionary tale of a design which could have made the transition simpler but did not.
I don’t know how you measure “metric tons of content” but I suspect in general there’s lots of US-available content on IPv4 that the countries like China and India want to access, and not much the other way around.
But that should be a perfect playground for an IPv6-only network that has gateways to the IPv4 content; eventually the home-developed content will begin to drive demand elsewhere.
Someone should’ve thought about the UX of IPv6 before declaring it to be “the way”. It’s like having to learn Klingon just to setup your printer. IPvNext could sort that out… maybe it’s time to consider moving on.
I learned the basics of IPv6 a few years ago, and forgot some of it... but NDP, the built in default addresses for router solicitation, address assignments and so on.
I'll tell you that if you just think of it on its own, it's really no harder than IPv4 + ARP + DHCP, just one or two extra things to remember.
The difficulty of adoption is the featureset and the UX of operating systems and home routers in particular. It is really difficult to find a consumer router, or even home networking OS, that exposes sensible working defaults for IPv6. The problem extends to the ISPs.
I am behind cgnat but have a native ipv6 /64 at home. I've got a great fibre connection (2G5) and everything "just works". I can host on ipv6 native machines and see them from anywhere in the world that has native ipv6 access.
The trouble is that 1) my employers do not have native ipv6 access; 2) neither does my mobile connection; and 3) really nor do a lot of my friends. Moreover, 4) if you browse a website from a native world-reachable ipv6 address, you're fingerprinted by it and it's overwhelmingly unique to you. So, it doesn't really work for hosting, and I don't get any direct benefits from it.
Instead I have a vps with a public ipv4 address and have a router that creates a wireguard tunnel to it. The reverse proxy works great over ipv6 and I am now in a position where I can forward ports and have direct connections -- albeit with hugely increased technical complexity. Ipv6 has many great ideas in it. If it's universally used it might just catch on...
> 4) if you browse a website from a native world-reachable ipv6 address, you're fingerprinted by it and it's overwhelmingly unique to you.
IPv6 privacy extensions exist & are enabled by default in most (if not all) operating systems today, which (this is my understanding; take it with a grain of salt) create what essentially are extra IPv6 addresses, used for outbound traffic, that aren't generated via your MAC address.
The US doesn't have excessive IPv4 Addresses. We have a real shortage and big pain because we don't have anywhere near enough. Sure we have 40% of them all - but that has no indication of what enough is.
I worked at an ISP way back in the dark ages of 2008 and we were all worried about IP exhaustion then. It's now 17 years later and what do you know, IPv4 is still trucking.
I think we'd be surprised how much address space is actually wasted, not announced or routed.
I have my own /24 that I registered back in the 90's. It is, in fact, routed and announced globally. I know several "early Internet" nerds with the same.
I know three local companies with /16's that aren't even announcing their blocks! Perhaps they use them internally.
> There are countless threads online on forums like Hacker News, Reddit where people who never really got comfortable with idea of IPv6
It’s clumsier than ipv4. It’s unnecessary since NAT was invented. In practice IPv6 requires dual stack, which means twice as many firewalls, names and routes to manage — so 4x the debugging because you have 2 dimensions that can either be working or failing. Addresses are too long to remember, too clumsy to write, and after 30 years still don’t have consistent representation (how many colons and brackets?).
Look, IPv6 has some benefits, but until the usability is fixed, it will be another 30 years before it’s close to 95% adoption.
> It’s clumsier than ipv4. It’s unnecessary since NAT was invented.
This is a privileged view of someone whose ISP has enough money (or was around early enough) to get enough IPv4 addresses to assign one to every customer's WAN interface. Not everyone is so lucky.
A lot of folks get non-publicly-routable 100.64.0.0/10[1] on their WAN interface with no way to do hole punching because they're behind CG-NAT.
Why would you be typing of remembering ipv6 addresses? Representation has always been consistent, if you learn the rules, like how 1337::1/64 is a valid address.
I don't understand why people are so negative about IPv6. I have done essentially zero home networking work and I just ran this successfully. It just works!
```
> ping6 google.com
PING6(56=40+8+8 bytes) 2605:59c0:236f:3a08:7883:9d04:c26d:5fa1 --> 2607:f8b0:4005:806::200e
16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=0 hlim=117 time=22.262 ms
16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=1 hlim=117 time=26.124 ms
16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=2 hlim=117 time=26.807 ms
^C
--- google.com ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 22.262/25.064/26.807/2.001 ms
```
That's literally impossible, to hear some people tell it. "And also, look how hard it'd be to memorize that address", say the people who remember like 2 IPv4 addresses, one of them being 127.0.0.1.
> I don't understand why people are so negative about IPv6. [...] It just works!
Networking is a lot more than being able to ping a single host.
As a concrete counter-example, IPv6 routinely broke for me when I was using pfSense as a router. Why? Because pfSense, with no way of disabling this behavior, published its public IP as the DNS server for internal clients.
So each time I got a new prefix from my ISP, which happens about once a week or more often, machines stopped being able to perform DNS lookups for hours or until I rebooted them.
And, if I had bothered configuring IPv6 firewall rules, those would have had to be reconfigured manually with the new prefix. I understand this is mostly fixed in pfSense recently, but this was the case for many, many years.
Another counter-example is that Android only supports SLAAC, and SLAAC only supports providing a few key infrastructure details like router and DNS. If you want to tell the Android client something else, like NTP server, you're outta luck. Also, if Android successfully gets an IPv6 address via SLAAC, it requires the DNS server IP to also be an IPv6 address. So your internal DNS server must then also serve on IPv6. If that wasn't the case, it would just silently use Google's own DNS servers, breaking any local configuration you had.
Another point is that a lot of us tried using IPv6 decades ago, and so we still have scars from that time. IPv6 today is a lot better, but I still have a lot of IPv6 frustration associated with it from 15-20 years ago.
IPv6 feels like we just can't admit to ourselves that it has been a failed transition. What would it take to come up with IPv7 which takes in the lessons of IPv6 and produces something better that we can all agree is worth transitioning to over IPv4.
> What would it take to come up with IPv7 which takes in the lessons of IPv6 and produces something better that we can all agree is worth transitioning to over IPv4.
The only lesson to learn from IPv6 deployment is that if there's a workaround available and the world isn't burning, it'll take 30 years from initial design to actual adoption. So if you went out and took 10 years to design IPv7, it'd likely take until 2070 for it to gain some adoption. This is because big network hardware is costly and has very long replacement cycles.
IPv6 was already designed as a lessons-learnt protocol from IPv4 issues. The header is greatly simplified and it's more hardware-friendly, it incorporates the required features into the protocol and leaves extensibility as an optional add-on that doesn't slow down routing packets, all the while granting an infinite address space.
> IPv6 feels like we just can't admit to ourselves that it has been a failed transition. What would it take to come up with IPv7 which takes in the lessons of IPv6 and produces something better that we can all agree is worth transitioning to over IPv4.
Per Google, quite a few countries (including the US) are at >50%:
So I'm not quite sure where "failed" enters the equation.
And what exactly would be different with IPv7? Anything that needs more address bits would have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A7" address (for "IPv7" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6.
The only place the IPv6 transition seems to be failing is in "command-and-control" corporate networks. (A majority of home/consumer/cellular users are quietly using IPv6 by default every day, per most statistics.) The lessons to be learned there don't seem to be technical but economic incentives.
Big companies believe that they have plenty of IPv4 space, especially because they've always been lax in how they read IPv4 RFCs and use IPv4 routing behind corporate firewalls. Big companies also have the most cash to buy IPv4 blocks as they go to auction. Big companies have massive firewalls and strict VPNs which also insulate them from IPv4 scarcity.
IPv4 leases don't impact enough companies' bottom lines today that they need to assess IPv6 support.
Solving those economic incentive problems would likely be a massive sociopolitical problem: you would need IANA and the RIRs to agree to inflate costs in various ways (and in the short term that might have done a lot of harm to small countries already facing IPv4 inequity and their RIRs that lost the very earliest IPv4 assignment lotteries). You'd probably need new RFCs and political enforcement to support things like "taxing" company to company IPv4 block assignments. You'd probably need collusion or regulation from the big "Cloud Providers" to enforce higher costs on IPv4-only networking.
It would take those kind of "strong handed" tactics to speed up IPv6 adoption in corporate networks. Waiting for the "invisible hand" of the "free market" can be very slow and takes patience. That's mostly what we've been seeing with IPv6 adoption: the "invisible hand" is a lot slower than some people predicted. Especially engineers that hoped technical superiority alone would be a market winner.
I agree. If you click through to the original Wikipedia table that's cited in this article you can see a pretty clear correlation between countries with more IPv4 addresses than people vs. wealth/hegemonic clout of the country. In the UK, US, Germany, France, Canada, Japan, etc. there are way more than enough IPv4s to go around. Some ISPs here in the UK will even lease you bundles of four or eight IPv4s for very little additional cost.
The way forward for what though? It remains to be seen if this level of infrastructure and complexity has any kind of resilience. I seriously doubt it does, looking back on history. I think it's far more likely that the post-industrial population contraction (which hasn't even really begun) as well as climate change (anthropogenic or not) will make it far more likely that this model of "everybody uses a computer" ends up in the junk bin of history. Can't say I'd be sad to see it go. Somebody who has no interest in computers shouldn't ever have to touch one.
I find it fascinating how these key technologies handle upgrades and breaking changes. For example, Python eschewed breaking changes through 2.7.x but the dam has burst since 3.0 and every point release (it seems?) makes breaking changes, sometimes reversing itself (eg the whole s/u string prefix thing).
Many here will be familiar with the second system effect [1]. Usually people want to avoid making breaking changes but once they do, they can go a little nuts. My personal opinion is only major versions should make breaking changes and a lot of thought should go into making them as painless as possible.
IPv6 is fascinating for these reasons but also that it's a product of its time in two main ways:
1. It doesn't do anything about roaming because that wasn't an issue in the 1990s but it certainly is now;
2. A 64 bit address space would've basically been infinite addresses but instead they went with 128 bit addresses (rolling in ports) but then giving individual users a /64 address range. For some reason people deny it now or simply weren't aware but that too is a historical artifact because it was intended to put a 48 bit MAC address into that space but later we realized that's a huge PII and tracking issue; and
3. History has shown that upgrading network backbone hardware (in particular) is incredibly difficult through a process that's been described as "ossification", which is a nice description. Basically, network relays and routers wanted to avoid security issues and decided to discard things they didn't understand.
That's interesting because it violates Postel's Law [2], which basically says be liberal in what you accept and conservative in what you send.
But this shows up in all sorts of interesting ways, like it's practically impossible to reliably use MTUs larger than about 1536. When IPv4 was designed, that wasn't an issue. With 1-100G+ networks it is. There are RFCs about using large MTUs but you're dependent on backbone hardware you have no control over.
Even Linux struggles with this, to the point where you need to do some configuration for high-bandwidth networks (eg RPS [3]). Just handling all those interrupts presents a bunch of problems beyond the original scope. And again, it's hard to fix through no fault of Linux's.
I'm old enough to remember the talk about us running out of IPv4 addresses back in the 1990s. It's been interesting to watch how this has consistently been kicked down the street (eg cgNAT).
What is funny though is large companies (eg Facebook) actualy ran out of internal addresses on a 10/8 network and there's no good solution for that (with IPv4 at least).
I honestly don't understand why IPv6 is not actively deployed in 2026. Every piece of networking hardware over past decade supports IPv6 and often dual stack too. And to switch between both often takes a few clicks if DHCPv6 server is up and reachable. Absolutely transparent, free, zero performance hit. But no, so many persist at doing v4.
PS: I'm talking about MSO hardware. But client hardware should be at the same level of compatibility for years too.
It is the only way forward, but the reason for that is not the correlation between population and IP addresses. After all, most of the use of internet today is not by people, but by bots, crawlers, AI agents, b2b and more, and that is far more than the human population, and then you have the virtual networks built over IP like VPNs, Tor and more. It is more related to privacy, bidirectional communication and protocols, security, identity and possibilities.
The only place I have utilized an IPv6 address publicly is on my authoritative name servers only because some DNS testing tools assume it is there. It's not really needed however. My home firewall does have one but I have never used it. I can't think of a use for it. I have multiple static IPv4 addresses and they have suited me just fine for decades. I suppose I could bind a Squid SSL Bump MitM proxy to it in case a site blocks me but I would probably leave it off most of the time.
I never use them on my web, chat, voice, IRC and other servers as I personally find blocking shenanigans on IPv4 and not having to implement the same checks on IPv6 is just easier for a lazy person like me. IPv6 just feels like an after-thought bolt on to me. Clunky, not well thought out. Some privacy gotchas that can be disabled but some will not. That's just my take. I doubt anyone will have the same take.
I think IPv4 will be fine for another 100 years even if we have to re-purpose some DoD/MoD ranges given they don't use them and maybe annex some /8's from a few greedy companies. But that's a problem for Gen Delta. Gen Foxtrot can deal with repurposing some multicast ranges.
One of the biggest, I would assume in the current year, blockers to an IPv6 only world would be the fact that the major "cloud" vendors do not support it.
If IPv6 doesn't dominate in the next, let's say, 10 years, they might publish the IPv8 which will be an 64bit space, backwards compatible with IPv4. It will be the only case where a newer version of software comes back closer to an older one.
Both IPv4 and IPv6 addresses are 'just' u_ints: one is 2^32 and the other is 2^128. The fact that we display them in a particular format (10.11.12.13; ff:ee::bb:aa) is only for human UX purposes.
Strictly speaking everything in a computer is 'just' a number represented in base-2 (binary digits: bits) that we affix certain labels to (char, int, float, struct).
Imagine being able to connect two computers over the internet using sockets. WebRTC is a marvel, but I miss the whimsical days of running something on a port at home and connecting to it without thinking about NAT.
63 comments
[ 3.0 ms ] story [ 82.0 ms ] threadBut yeah, SLAAC's paradigm of moving assignment logic into the node (away from network infra like in DHCP) is definitely a stumbling point.
It's been in crisis for decades, but it's also getting increasingly worse every year.
Found this visual breakdown of IPv4 -> IPv6 transition.
Dual stack and tunneling sections show how much complexity came from not having a clean migration path - https://vectree.io/c/ipv4-vs-ipv6-address-architecture-nat-a...
But that should be a perfect playground for an IPv6-only network that has gateways to the IPv4 content; eventually the home-developed content will begin to drive demand elsewhere.
I'll tell you that if you just think of it on its own, it's really no harder than IPv4 + ARP + DHCP, just one or two extra things to remember.
The difficulty of adoption is the featureset and the UX of operating systems and home routers in particular. It is really difficult to find a consumer router, or even home networking OS, that exposes sensible working defaults for IPv6. The problem extends to the ISPs.
The spec is fine.
The trouble is that 1) my employers do not have native ipv6 access; 2) neither does my mobile connection; and 3) really nor do a lot of my friends. Moreover, 4) if you browse a website from a native world-reachable ipv6 address, you're fingerprinted by it and it's overwhelmingly unique to you. So, it doesn't really work for hosting, and I don't get any direct benefits from it.
Instead I have a vps with a public ipv4 address and have a router that creates a wireguard tunnel to it. The reverse proxy works great over ipv6 and I am now in a position where I can forward ports and have direct connections -- albeit with hugely increased technical complexity. Ipv6 has many great ideas in it. If it's universally used it might just catch on...
IPv6 privacy extensions exist & are enabled by default in most (if not all) operating systems today, which (this is my understanding; take it with a grain of salt) create what essentially are extra IPv6 addresses, used for outbound traffic, that aren't generated via your MAC address.
I have my own /24 that I registered back in the 90's. It is, in fact, routed and announced globally. I know several "early Internet" nerds with the same.
I know three local companies with /16's that aren't even announcing their blocks! Perhaps they use them internally.
It’s clumsier than ipv4. It’s unnecessary since NAT was invented. In practice IPv6 requires dual stack, which means twice as many firewalls, names and routes to manage — so 4x the debugging because you have 2 dimensions that can either be working or failing. Addresses are too long to remember, too clumsy to write, and after 30 years still don’t have consistent representation (how many colons and brackets?).
Look, IPv6 has some benefits, but until the usability is fixed, it will be another 30 years before it’s close to 95% adoption.
This is a privileged view of someone whose ISP has enough money (or was around early enough) to get enough IPv4 addresses to assign one to every customer's WAN interface. Not everyone is so lucky.
A lot of folks get non-publicly-routable 100.64.0.0/10[1] on their WAN interface with no way to do hole punching because they're behind CG-NAT.
[1] https://en.wikipedia.org/wiki/IPv4_shared_address_space
``` > ping6 google.com PING6(56=40+8+8 bytes) 2605:59c0:236f:3a08:7883:9d04:c26d:5fa1 --> 2607:f8b0:4005:806::200e 16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=0 hlim=117 time=22.262 ms 16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=1 hlim=117 time=26.124 ms 16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=2 hlim=117 time=26.807 ms ^C --- google.com ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 22.262/25.064/26.807/2.001 ms ```
Networking is a lot more than being able to ping a single host.
As a concrete counter-example, IPv6 routinely broke for me when I was using pfSense as a router. Why? Because pfSense, with no way of disabling this behavior, published its public IP as the DNS server for internal clients.
So each time I got a new prefix from my ISP, which happens about once a week or more often, machines stopped being able to perform DNS lookups for hours or until I rebooted them.
And, if I had bothered configuring IPv6 firewall rules, those would have had to be reconfigured manually with the new prefix. I understand this is mostly fixed in pfSense recently, but this was the case for many, many years.
Another counter-example is that Android only supports SLAAC, and SLAAC only supports providing a few key infrastructure details like router and DNS. If you want to tell the Android client something else, like NTP server, you're outta luck. Also, if Android successfully gets an IPv6 address via SLAAC, it requires the DNS server IP to also be an IPv6 address. So your internal DNS server must then also serve on IPv6. If that wasn't the case, it would just silently use Google's own DNS servers, breaking any local configuration you had.
Another point is that a lot of us tried using IPv6 decades ago, and so we still have scars from that time. IPv6 today is a lot better, but I still have a lot of IPv6 frustration associated with it from 15-20 years ago.
The only lesson to learn from IPv6 deployment is that if there's a workaround available and the world isn't burning, it'll take 30 years from initial design to actual adoption. So if you went out and took 10 years to design IPv7, it'd likely take until 2070 for it to gain some adoption. This is because big network hardware is costly and has very long replacement cycles.
IPv6 was already designed as a lessons-learnt protocol from IPv4 issues. The header is greatly simplified and it's more hardware-friendly, it incorporates the required features into the protocol and leaves extensibility as an optional add-on that doesn't slow down routing packets, all the while granting an infinite address space.
Per Google, quite a few countries (including the US) are at >50%:
* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
Every handset on T-Mobile US's network gets IPv6 (and they're not the only carrier like that):
* https://www.youtube.com/watch?v=d6oBCYHzrTA
So I'm not quite sure where "failed" enters the equation.
And what exactly would be different with IPv7? Anything that needs more address bits would have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A7" address (for "IPv7" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6.
Big companies believe that they have plenty of IPv4 space, especially because they've always been lax in how they read IPv4 RFCs and use IPv4 routing behind corporate firewalls. Big companies also have the most cash to buy IPv4 blocks as they go to auction. Big companies have massive firewalls and strict VPNs which also insulate them from IPv4 scarcity.
IPv4 leases don't impact enough companies' bottom lines today that they need to assess IPv6 support.
Solving those economic incentive problems would likely be a massive sociopolitical problem: you would need IANA and the RIRs to agree to inflate costs in various ways (and in the short term that might have done a lot of harm to small countries already facing IPv4 inequity and their RIRs that lost the very earliest IPv4 assignment lotteries). You'd probably need new RFCs and political enforcement to support things like "taxing" company to company IPv4 block assignments. You'd probably need collusion or regulation from the big "Cloud Providers" to enforce higher costs on IPv4-only networking.
It would take those kind of "strong handed" tactics to speed up IPv6 adoption in corporate networks. Waiting for the "invisible hand" of the "free market" can be very slow and takes patience. That's mostly what we've been seeing with IPv6 adoption: the "invisible hand" is a lot slower than some people predicted. Especially engineers that hoped technical superiority alone would be a market winner.
Many here will be familiar with the second system effect [1]. Usually people want to avoid making breaking changes but once they do, they can go a little nuts. My personal opinion is only major versions should make breaking changes and a lot of thought should go into making them as painless as possible.
IPv6 is fascinating for these reasons but also that it's a product of its time in two main ways:
1. It doesn't do anything about roaming because that wasn't an issue in the 1990s but it certainly is now;
2. A 64 bit address space would've basically been infinite addresses but instead they went with 128 bit addresses (rolling in ports) but then giving individual users a /64 address range. For some reason people deny it now or simply weren't aware but that too is a historical artifact because it was intended to put a 48 bit MAC address into that space but later we realized that's a huge PII and tracking issue; and
3. History has shown that upgrading network backbone hardware (in particular) is incredibly difficult through a process that's been described as "ossification", which is a nice description. Basically, network relays and routers wanted to avoid security issues and decided to discard things they didn't understand.
That's interesting because it violates Postel's Law [2], which basically says be liberal in what you accept and conservative in what you send.
But this shows up in all sorts of interesting ways, like it's practically impossible to reliably use MTUs larger than about 1536. When IPv4 was designed, that wasn't an issue. With 1-100G+ networks it is. There are RFCs about using large MTUs but you're dependent on backbone hardware you have no control over.
Even Linux struggles with this, to the point where you need to do some configuration for high-bandwidth networks (eg RPS [3]). Just handling all those interrupts presents a bunch of problems beyond the original scope. And again, it's hard to fix through no fault of Linux's.
I'm old enough to remember the talk about us running out of IPv4 addresses back in the 1990s. It's been interesting to watch how this has consistently been kicked down the street (eg cgNAT).
What is funny though is large companies (eg Facebook) actualy ran out of internal addresses on a 10/8 network and there's no good solution for that (with IPv4 at least).
[1]: https://en.wikipedia.org/wiki/Second-system_effect
[2]: https://en.wikipedia.org/wiki/Robustness_principle
[3]: https://lwn.net/Articles/362339/
PS: I'm talking about MSO hardware. But client hardware should be at the same level of compatibility for years too.
I never use them on my web, chat, voice, IRC and other servers as I personally find blocking shenanigans on IPv4 and not having to implement the same checks on IPv6 is just easier for a lazy person like me. IPv6 just feels like an after-thought bolt on to me. Clunky, not well thought out. Some privacy gotchas that can be disabled but some will not. That's just my take. I doubt anyone will have the same take.
I think IPv4 will be fine for another 100 years even if we have to re-purpose some DoD/MoD ranges given they don't use them and maybe annex some /8's from a few greedy companies. But that's a problem for Gen Delta. Gen Foxtrot can deal with repurposing some multicast ranges.
Both IPv4 and IPv6 addresses are 'just' u_ints: one is 2^32 and the other is 2^128. The fact that we display them in a particular format (10.11.12.13; ff:ee::bb:aa) is only for human UX purposes.
Strictly speaking everything in a computer is 'just' a number represented in base-2 (binary digits: bits) that we affix certain labels to (char, int, float, struct).