This feels a lot like the arguing that went on during the transition to Python 3. The Python 2.7 hangers-on were so preoccupied with themselves that they didn't notice that the pool of people interested in having the argument at all was getting smaller and smaller.
Until somebody turned off the lights, that is. It is not much fun arguing with yourself in the dark.
I think that's what needed and needs to be done here. I will agree with the IPv4 advocates on one thing: IPv6 adoption has been slow in part because it doesn't work like IPv4 + kludges. That is the point. Clinging to IPv4 standard practices while you switch is just going to make you miserable.
In 2006, the hesitation to go to IPv6 made sense. Support was spotty. In 2026 it does not. IPv6 support is now more than adequate, and a clean cut will force the stragglers to get their asses in gear in a hurry ("fix your IPv6 support RFN or enjoy nobody using your product"). Change is painful, learning new stuff when you were getting by just fine on the old stuff is painful, I get it. But it will happen whether you like it or not. Why not just get it over with?
I finally made the switch to IPv6 last year, and I wouldn't go back.
The pain of change is real, but mercifully, it doesn't last. Within a year this debate will seem quaint.
It's hard to adopt something that schools don't teach. I know someone who graduated from UCI with a CompSci degree with a specialization in networking, just before the COVID19 pandemic began. He recalled that the networking courses he took did not cover IPv6 at all, except to describe the address format (i.e. 128 bits, written as hexadecimal, colon-separated). Everything he learned about IPv6, he had to learn on his own or on the job. A standard that has been published for over two decades, heavily used for over a decade, and critical in the worldwide growth of the Internet, was treated as an afterthought by one of the premier universities in the US.
Obvious disclaimer: This is a sample size of 1, and an anecdote is not data, yada yada. I'm not involved in academia, and have no insight into the adoption of IPv6 in CompSci networking curricula on a broader level.
I don't like to admit this, but at this point honestly I think ipv6 is largely a failure, and I say this as someone that wrote a blog post for APNIC on how to turn on ipv6.
I'll get endless pushback for this, but the reality is that adoption isn't at 100%, it very closely needs to be, and there are still entire ISPs that only assign ipv4, to say nothing of routers people are buying and installing that don't have ipv6 enabled out of the box.
A much better solution here would have been an incredibly conservative "written on a napkin" change to ipv4 to expand the number of available address space. It still would have been difficult to adopt, but it would have the benefit of being a simple change to a system everyone already understands and on top of a stack that largely already exists.
I'm not proposing to abandon ipv6, but at this point I'm really not sure how we proceed here. The status quo is maintaining two separate competing protocols forever, which was not the ultimate intention.
> still hasn't taken over the world
Maybe not in the strict sense, but it kind of has.
In the enterprises I've worked in the past decade with IPv6 running, at least 75% of the Internet traffic is IPv6. In my discussions with other engineers managing large networks, they seem to be seeing more or less that same figure.
The problem is that virtually nobody knows IPv6. I regularly bring up IPv6 in engineers' circles and I'm often the only one who knows much about it. And so, I have doubts about it's long-term future, except for edge cases. I figure some clever scheme utilizing IPv4 and probably NAT will come around at some point.
The fact that this comments section indicates such a yawning chasm of gaps in knowledge (much less, understanding) - in a forum whose users are generally known to be more technically savvy than most - is exactly why IPv6 is still not widely adopted. There is confusion about the less obvious benefits, confusion about how it works, confusion about the dangers (how do I adjust my well honed IPv4 spidey senses?), and confusion about how I transition my current private network. An epic failure of change management.
Here’s a prediction. Linux on the desktop will have >50% penetration well before IPv6 does.
I get so many Second System Syndrome vibes off of IPv6. Surely other people must be picking it up too.
Future proofing it by jumping straight to 128 bits instead of 64. 64 would have been fine. Even with a load factor of 1:1000 by assigning semantics to ranges of IP addresses, 64 bit addressing is still enough addresses for 10 million devices per person.
If we become a galactic empire, we will have to replace the Web anyway because every interaction will have to be a standalone app or edge networking that doesn’t need to hear back from the central office for minutes, hours, days anyway. We could NAT every planet and go on forever.
> For many, the decision of which protocol to use was easy because IPv6 didn't add features that represented major improvements.
This is the obvious and only key to this puzzle.
We tech nerds have this mad idea that everyone will want to spend time and money adapting to new standards because they're technically better in some abstract way, and so we do absolutely no work to create incentives for anyone to switch. Often, the new standard is not (yet) even functionally equivalent to the old one (e.g. Wayland), just to make doubly sure the switch will be as difficult and undesirable for end users as possible.
And when the absolutely inevitable consequences occur - stakeholders do not want to invest in switching to or developing for new standards that give them zero incentive to do so - there's a silly finger pointing game, as though everyone was supposed to switch, and they've failed to do so. Which is, of course, absurd. People don't owe us compliance.
Do not expect to be able to successfully shift behaviour unless you give people incentives - reasons they would want to switch, not just reasons you want them to switch.
Everything I know about IPv6 comes from this one blog post: https://apenwarr.ca/log/20170810. It’s from 2017, when IPv6 adoption was 17% according to https://www.google.com/intl/en/ipv6/statistics.html; today it’s close to 50%.
IPv6 has already won on mobile and been gaining fast traction in IoT space with Matter. The reason IPv4 is still around everywhere else is because we came up with ingeniuous techniques that squeezed the heck out of IPv4 address space. Also, IPv4 addresses are easier to type. That's pretty much it.
I had mentioned some of that in my post: https://ssg.dev/ipv6-for-the-remotely-interested-af214dd06aa...
My prediction [0]: It will take roughly 100 years for IPv6 to be ubiquitous enough to shut off IPv4. That's not intended as hyperbole, if anything it's an understatement.
Because, it's not going away: You can talk all you want about how IPv6 should have been a more straightforward expansion of the address size, but this is all in the rear-view mirror at this point. IPv6 is going to be with us forever, you may as well get used to it. It's already everywhere in 5G deployments, ISP's like Comcast use it for 100% of their out-of-band management, China is making huge progress moving to it as part of their 5-year plan, India is progressing nicely in their transition, the list goes on. We're already way too far along in the transition to abandon it in favor of something else.
But it's not going to happen any quicker than we've seen, either: There's no urgency (no "must-have" use case) except for what organizations are imposing on themselves. Yeah, IPv4 addresses are more expensive, but you don't really need many of them as a business (you can get by with a small handful of public ones, and just using L7 load balancers and SNI for everything) nor as an ISP (CGNAT can get you a long way.)
So we have a situation where things are migrating very slowly, mainly only in places where it makes sense (mobile deployments, home ISP's where the users don't actually administer the network), and generally mostly for new deployments. This is a recipe for IPv4 to be around for a very, very long time. We're used to technology moving at breakneck pace, but that's only the case for the higher-level stuff. The core infrastructure like the internet protocol is likely the textbook example of slow-and-steady, and a case where it's actually not crazy to think of centuries-long timeframes for things.
[0] Barring any unforeseen black-swan events like a world war destroying all technology and having to rebuild from scratch or something. Or a competent international agreement to aggressively migrate to it (I don't know which is more likely.)
My ISP refuses to give you a static IPv6 prefix unless you're a business customer, despite having an "unlimited" amount of them. This results in me not bothering to set it up properly and focusing on IPv4 still.
It was doomed the moment you had to maintain two separate stacks, each with its own address, firewall rules and so on.
It should have been ipv4 with extra optional bits, so you could have the same rules and everything for both stacks.
I turn it off because it's a risk having one of either stacks malconfigured.
IPv6 should've been a superset of IPv4, as in addresses are shared, not that you have a separate IPv4 and IPv6 address for your server.
I remember 10+ years ago we were going to run out of IPv4 addresses and it was the next Y2K unless you adopted IPv6. I was able to get IPv6 for my servers and home, and I thought I was safe!
> "In fact, IPv4's continued viability is largely because IPv6 absorbed that growth pressure elsewhere – particularly in mobile, broadband, and cloud environments," he added. "In that sense, IPv6 succeeded where it was needed most, and must be regarded as a success."
Apparently it turns out IPv6 wasn't for me any way!
I've been native IPv6 at home for a few years now. That worked flawlessly until a recent Windows 11 update somehow broke IPv6 in ways that I don't entirely understand. All the other Linux and Apple and et cetera things in my house are fine, but the Win11 laptop just refuses to handle certain IPv6 ranges (specifically including the address that the host interface for one of my web servers falls in). 100% contained within the Win11 device and TBH I can't be bothered to dig into it further so I just proxy through some other device that does work. (Guessing it'll get fixed a month/year/decade or so from now.)
I agree it's not a failure, but after 3 decades it's still frustratingly annoying to use at times.
It kind of has. The majority of internet traffic is IPv6. The three biggest internet hub regions (USA, Europe, China) have IPv6 mandates. Most apps support IPv6. Google and Apple force them to, od they get kicked off the app store. Almost all mobile networks (which means almost all end devices) are IPv6-only, with slow inefficient tunneling for IPv4. The price of IPv4 addresses is declining.
At what point will we be allowed to say IPv6 hasn't failed? When the IPv4 internet finally switches off for good? It feels like no achievement is high enough for those who don't like IPv6 to change their minds. I would've thought making up 50% of internet traffic and 50% of end devices being on IPv6-only networks would be good Schelling points, but evidently they're not!
Maybe a different take, but as someone that manages a large public API that allows anonymous access, IPv6 has been a nightmare to try and enforce rate limits on. We've found different ISPs assign IPv6 addresses differently - some give a /64 to every server, some give /64 to an entire data center. It seems there is no standard and everyone just makes up what they think will work. This puts us in an awkward place where we need abuse protections, but have to invest into more complicated solutions that were needed for IPv4. Or we give up and just say if you want to use IPv6, you have to authenticate.
Does anyone have any success stories from the server side handling a situation like this? Looks like cloudflare switched to some kind of custom dynamic rate limiting based on like addresses, but it's unrealistic to expect everyone to be able to do such a thing.
I use multiple Google accounts to segregate the data that gets collected on each one - as I don't like having, say, TV logged in to the same account where I send my emails from. One of them, which I use exclusively for Gemini, was banned today (I violated no policies, Google just doesn't like the way I try to sanitize its access I guess).
Now, I can simply restart my router (or cycle airplane mode on mobile) and get a new IPv4 that probably was used by bazillion people before me, or even along with me, and get a new account. So Google has to be very careful here, with IP-linked bans in order to not just ban the whole load of unconnected people just because they used the same IPv4 as me.
With IPv6, they could just ban my entire family and any guests that might have connected to my WiFi, forever.
I like the limitations of IPv4, thank you.
I can't help but think that numbering all the devices was the wrong idea from the beginning. You don't want to talk to devices, you want to talk to (and offer) services. You probably need something like an AS number to make global routing efficient, but 32 bits would be plenty for that. A packet could be (destination AS, stream ID, encrypted( payload )) and DNS would give you a capability (destination AS, stream ID, keys) for a service. You send a packet to that stream asking to open a connection and providing a capability to reply (with a capability for the specific stream). Your network up to the AS level should have an opportunity to augment the stream IDs in whatever way is convenient for its routing. No one reveals any topology information, network neutrality and a degree of privacy is guaranteed at the protocol level, only really serious multipeer networks need to assign addresses above layer 2, and I think it would be reasonably easy to come up with an edges first incentive compatible transition plan (which is where ipv6 went wrong).
(This is of course an incomplete and poorly thought out proposal, you don't need to dogpile me about that.)
I think 30 years should be much more than enough to realise the idiocy of proposing a non-backward-compatible standard to the general public.
I was in college when v6 was going through the RFC process. In my networking class we had to learn Netware (IPX) and v6, which have both turned out to be equally irrelevant, for different reasons. At this stage, I fully expect to retire having never deployed a single resource using v6.
I'm genuinely wondering if western governments (UK) will start issuing ipv6 addresses out to citizens as their digital id so they can track them online and offline.
Only half joking, some UK MPs might actually consider this a reasonable thing considering how many ipv6s there are.
https://www.google.com/intl/en/ipv6/statistics.html it's still going up (we are in some sort of cyclic downturn right now that I don't understand).
Next year that chart will finally cross 50%. It was a mere 30% in 2030. Developing country mobile phone networks will continue to push it higher.
All we need to do is start having rich governments mandate IPv6, and also mandate IPv4 downtime as a punishment for those that don't comply / chaos engineering for the system as a whole. Then we can quickly finish the job.
Contrary to some other comments: no, IPV6 hasn't taken over the world at all.
In my case, I administrate a small server at home, where I self host many services that are made available to myself, friends and families, over the internet.
In that context, IPv6, is SADLY (please note that I have NOTHING against IPv6), a limitation, even a nightmare to use.
Some programs do not handle IPv6 at all. Game servers for instance, do not support it, the one that I think about is: Arma 3. But there are many others
In 2025 (and 2026 too?), 4G (5G?) operators do not all route over IPv6 -> which means that if your domain only has a AAAA record, some people using 4G will not be able to access ANY of your services. This issue forced me to beg my ISP to obtain an IPv4 "fullstack" as they call it.
Without that IPv4 you have to go through some kind of tunneling (like Cloudflare) -> and guess what? Cloudflare sometimes crashes (it happened super recently remember?) and in that situation -> ALL your services accessible through the tunnel are "down" for your users. Plus, it is EXTREMELY unsatisfying to rely on an external private-owned service for a selfhosting project.
In almost ALL context IPv6 is seen as optional, additional, additional configuration and is NEVER the default. NEVER. Which means: more configuration, possibly more struggle.
The problem with IPv6 jokes is that very few people are making them.
Correct me if I'm wrong, doesn't it make you leak your IP outside local network? I'd say this is a great turn off especially nowadays when it will be used for sure for tracking
Nothing have given me more issues than ipv6. Every time I've tried to use it, it gives me so much headache I just give up. I'm not even sure my ISP supports it. My router doesn't get an ipv6, and called my IPS. After going through 3 different people over 2 hours I just gave up. I just hope I get put behind CGNAT...
IPv6 is already here if you're not in the US. I moved house last month and consumer ISPs don't offer a (real) IPv4 connection in my country any more; you get an IPv6 connection and your router does MAP-E if you want to send data over IPv4.
IPv6 continues to rumble along, gaining market share, because China. Increasing IPv6 adoption was in the 14th Five Year Plan, and about 75% of mobile in China is now IPv6.
I started looking at self-hosting many applications at home once I realized that IPv6 could enable me to do that securely without any complicated router/firewall configuration that would need to be maintained.
The only wrinkle I ran into is that apparently ISPs are still reluctant to give out static IPv6 prefixes to residential customers. So you still need some kind of DDNS setup, which is lame.
Yesterday I was required to turn on IPv6 on my router, while setting up some IoT things using Matter over Thread. Apparently that protocol uses IPv6 and doesn't work if your router is only routing IPv4.
DJB understood the problem decades ago. https://cr.yp.to/djbdns/ipv6mess.html
IMO we need to rethink routing for IPv6 so we can finally reduce pressure on router tables and finally cause pressure to ditch IPv4. Here are some of my thoughts on that elsewhere in this thread: https://news.ycombinator.com/item?id=46471898
But here's a more thought-out design:
- register a well-known IPv6 prefix with 20 bits reserved for AS number
- so we'd have ${well_known_prefix}:${AS_number}:${customer_prefix}:${end_entity} (not necessarily that format for display, but just for the purpose of getting the idea across here)
- have DNS servers return AAAA RRs with the AS number filled in
- DNS servers should either have the correct AS numbers filled in their zones, or possibly could subscribe to the RPKI and use the RPKI for mapping ${well_known_prefix}:${all_zero_AS}:${customer_prefix}:* to AS numbers, then fill them in (this would require live signing if using DNSSEC, which is f-i-n-e fine)
- if there are multiple AS numbers for a $customer_prefix, then return multiple AAAA RRs, or if EDNS0 indicates client support for it, one AAAA RR and N RRs of a new type that carry only the AS numbers
- update core routers to route these prefixes based on the AS number in the address
- update edge routers to replace the sender's AS number in its address if its address is below the $well_known_prefix -- this takes care of the return path
- update internal routers to use only the $customer_prefix and the $end_entity for routing for this $well_known_prefix
- end entities should ignore the AS number when receiving packets, thus allowing multi-homing (i.e., let source and destination IPv6 addresses match ${well_known_prefix}:*:${customer_prefix}:${end_entity} for socket 5-tuples)
- for backwards compatibility end entities should map these addresses back to whatever the application used in its calls to bind() and connect() (i.e., if the app found an AAAA with the AS number filled in and used it for connect(), but the ${customer_prefix} is multi-homed, then accept packets from all those homes) (apps should make sure to use TLS / QUIC for security, naturally)
- when an end-entity sees a change in AS number for a peer's address matching a socket 5-tuple then update the peer's AS number / address in the 5-tuple -- this allows for migration and better path finding
I think something like this could be deployed with relatively little effort.
Is there yet answer to question "how to get random self-assigned addresses into dns records, firewall rules and switch acls?" ?
How many people here have put IPv6 addresses into the root DNS servers for their glue records? Curious how this [1] set of charts has evolved. For some reason I have only ever used IPv4 root glue records and never really gave it much thought otherwise.
[1] - https://nlnetlabs.nl/downloads/publications/ipv6/v6rootglue....
Every day I thank NAT that I don't have to memorize IPv6 addresses. I can barely manage my IPv4 numbers.
I question the premise that it’s not taking over. Our logs are at least 50% ipv6 now. A few years ago I feel like a barely saw it.
NAT is the reason for IPV6 not taking over.
Also it acts as a nice security perimeter. If all IoT devices in a home were exposed to internet, It would be absolute mess.
IPv6 was obsolete by the mid-2000s, majorly due to the advent of roaming. It was designed on the rather fanciful assumption that its deployment would simply supersede IPv4, that every software/hardware vendor would cooperate, and we'd have a pure v6 network which would also replace the traditional L2/L3 layers.
Ofcourse legacy compatibility trumps all, along with the ubiquity of NATs and roaming and we're now just in the sunk-cost phase, being left saddled with a horribly bloated protocol (128-bit addresses was a marketing choice; not engineering) that solves no problems.
I love IPv6 but organizations seem to struggle with it. My ISP, for example, had issues routing it after a backend update so they decided to just turn it off. I'm now stuck on CGNAT IPv4 which results in constant captchas :/
For anyone who thinks IPv6 is without merit, I recommend reading up on the various challenges of NAT traversal [1]. In cases where CGNAT is deployed in particular, there are scenarios where the only way to make everyday P2P connections work is to route traffic through a 3rd party - which can impact latency and bandwidth.
While IPv6 doesn’t make establishing a P2P connection trivial (there are still firewalls to contend with) - it does simplify things dramatically. And as someone who is behind CGNAT, I am very grateful for the existence of IPv6.
Is there an obvious reason why it would not have worked to just say that all ipv4 addresses are ipv6 addresses with an implicit leading 96 zero bits?
Not a counter-point, but: the other day I rebuilt my personal server, finishing by pointing the reserved IP at the new box. I then had a period of confusion because I was still seeing old content, because my browser (etc) was obviously querying the AAA record first, which I hadn't updated.
(a while ago I needed to contact support to get an IPv6 allocation at home, but that was a very quick interaction at the time)
IPv6 is the poster child for the second system effect (or solution) [1].
IPv4 really only had 3 problems that anybody cared about:
1. Address space size;
2. Roaming; and
3. Reliable connectionless delivery; and
4. The problems created by the at most once delivery under TCP when what we really needed was at least once delivery in many, many cases.
Even the address space size problem is less of an issue than originally predicted because of improvements in NAT, up to and including cgNAT for cellular network providers (which also somewhat addressed (2) in a limited way).
Interestingly, some of the larger companies have networks simply too large for the 10.0.0.0/8 address space.
By "roaming" I mean maintaining a consistent connection while moving between networks.
(4) has kinda fallen on QUIC (now HTTP3) but this should really be core TCP/IP Layer 3.
You could also say that TCP congestion control is pretty outdated. It's not surprising. It was designed at a time before megabit (let alone gigabit) networks. And, more importantly, latency kills throughput. Some efforts have been made on this, such as Google's BBR [2], but other problems remain like MTU windows being too small for modern networks.
So what did IPv6 do? It only solved one problem, address space, and it did it in a way that kinda created new problems. First, the address space is too large (128 bits) and the last 64 bits are kinda reserved for the job that a 16 port used to do. And why was that? Originally, it was intended that the lower 64 bits were derived from a 48 bit MAC address (as used by Ethernet and later Wifi) but they realized this was a huge privacy problem so it never happened.
[1]: https://en.wikipedia.org/wiki/Second-system_effect
[2]: https://github.com/google/bbr
[2]: https://community.cisco.com/t5/networking-knowledge-base/und...
and it never will, because IPv4 has become a defacto reputation system for the exact same reason that IPv6 was created: a limited supply. It wouldn't surprise me to see the continued balkanization of the internet that there is a particular underclass of exclusively IPv6 traffic, but its not going to take over everything because once decentralized systems are now in the hands of a few decisionmakers in the case of, say, email.
My gut is that this is for the best; I haven't fully fleshed it out but it feels like the practical goal of "decentralizing power" and e.g. ISPs and other powerful entities exploiting end users is easier in an IPv6 regime, and has been practically thwarted somewhat by IPv4.
I'm reminded of way back in the day when they wanted charge per user or per device in households.
IPv6 seems to be a great fit for 1) mobile devices, 2) massive data centers and 3) literally nothing else.
I have met zero network engineers who wanted to put IP version 6 in their network. It causes all sorts of problems and presents all sorts of security risks without much benefit other than the obvious one. In the data center, NAT is a feature, not a bug.
Instead, they provision IPv6-enabled load balancers and pass traffic back to load bearing servers using ipv4 instead.
It's a classic example of "this is the next best thing everyone should use it" which achieves some adoption but it's not really the next best thing. It's not the be all end all it purports to be.
We should just admit to ourselves that we need one kind of ip stack in some situations and another in another.
Can't we just leapfrog to IPv7? or 8 for that matter?
Simple reason it didn't take over: the lack of backwards compatibility with ipv4. Yes, it would have marred the beauty of the new specification. But we will continue paying the price for another 30 years.
I don't use IPv6 because it solves a problem that I don't have and it provides functionality that I don't want. And also because I don't understand it very well.
My points :
- I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.
- Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.
- Stateless auto configuration. What ? No, no, I want my ducks neatly in a row, not wandering about. Again maybe my brain is rotten from years of DHCP usage but yes, I want stateful configuration and I want all devices on my network to automatically use my internal DNS server thank you very much.
- It's hard to remember IPv6 addresses. The prospect of reconfiguring all my router and firewall rules looks rather painful.
- My ISP gives me a /64, what am I supposed to do with that anyways?
- What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.
In short, so far, ignorance is bliss.