IPv6 Adoption in 2026(netmeister.org)
netmeister.org
IPv6 Adoption in 2026
https://www.netmeister.org/blog/ipv6-adoption.html
22 comments
They *are* making progress on it: https://aws.amazon.com/new/?ams%23article-feed%23pattern-dat...
They seem to have been averaging about two services per week for the past year. But they have a lot of services...
They seem to have been averaging about two services per week for the past year. But they have a lot of services...
This seems like an evergreen content topic. It's obvious that IPv6 adoption is high enough and critical for some industries in particular (i.e. cellular providers) with lots of endpoints. Increasing endpoint adoption is good. But service providers need to care about the remaining percentage. Say you get to 80, 90, even 99% adoption. An SP still can't flip IPv4 off. So what does it matter? It really doesn't warrant much concern.
> So what does it matter?
Yeah. There's a type of person who's obsessed with "cleanliness". For such a person, the goal is to have exactly one protocol on The Internet.
Such a person would lose their goddamn minds if they had to actually work as a WAN administrator or datacenter operator.
One of IPv6's purposes is to reduce pressure on the IPv4 address space. I don't expect IPv4 to get deactivated within the lifetime of any current HN reader; there's really no point in doing so. I expect the future for noncommercial sites to be "globally-routable IPv6 service, and IPv4 service by way of a CGN", which is how things are set up today in some parts of the world.
IPv6 will be the default, with v4 as a fallback for folks need to talk with others who can't be bothered to update their software or kit.
Yeah. There's a type of person who's obsessed with "cleanliness". For such a person, the goal is to have exactly one protocol on The Internet.
Such a person would lose their goddamn minds if they had to actually work as a WAN administrator or datacenter operator.
One of IPv6's purposes is to reduce pressure on the IPv4 address space. I don't expect IPv4 to get deactivated within the lifetime of any current HN reader; there's really no point in doing so. I expect the future for noncommercial sites to be "globally-routable IPv6 service, and IPv4 service by way of a CGN", which is how things are set up today in some parts of the world.
IPv6 will be the default, with v4 as a fallback for folks need to talk with others who can't be bothered to update their software or kit.
When you get to high 90s adoption you can start to run v4 as an overlay on a V6 native network. That's what the big US mobile carriers do, when they use 464XLAT, the edges get v4, but it all gets tunneled/translated to v6 in the middle.
I think we're tracking the wrong number. We should not be tracking adoption, we should be tracking it's integral value. Not the current position of IPv6 adoption but abasement of IPv6 adoption.
https://en.wikipedia.org/wiki/Absement#Applications
https://en.wikipedia.org/wiki/Absement#Applications
There's also the question of whether we should be tracking percentage or number of users -- there's about 3 billion v6 users at the moment based on Google's stats, but 12 years ago there were only 3 billion Internet users in total. Even if the percentage was flat, that would still represent ongoing v6 deployment for as long as the Internet itself is growing.
(As a side note, Google and APNIC disagree significantly on China's deployment percentage -- 6.5% vs 52% -- so there's actually something like another half a billion v6 users not represented in Google's stats which would push the world percentage from ~48% to ~56%, and that "x years ago" stat to 10 years ago.)
(As a side note, Google and APNIC disagree significantly on China's deployment percentage -- 6.5% vs 52% -- so there's actually something like another half a billion v6 users not represented in Google's stats which would push the world percentage from ~48% to ~56%, and that "x years ago" stat to 10 years ago.)
[deleted]
having less addresses than humans is a feature that gets broken by IPv6. IMO, there ought to be less globally valid IPv4 addresses (say, a kilo less or so, maybe even a mega. We probably could even do with a giga less if you're willing to do continent/major compass routing first).
IPv6 is a bit of a surveillance backbone. First you need an ID space that is big enough to give everybody a (or many) unique tags. The rest follows. If identity clashes are too costly, the identifier ceases being a useful tracking tool. If your network is based on an ID space that can satisfy your tracking needs already, how nice is that?
In the past thirty years, I have not encountered a use-case where I thought, Oh, I wish I had one (or a million, billion, or whatever) IPv6 addresses available here! But then again, I haven't developed software for bad actors.
IPv6 is a bit of a surveillance backbone. First you need an ID space that is big enough to give everybody a (or many) unique tags. The rest follows. If identity clashes are too costly, the identifier ceases being a useful tracking tool. If your network is based on an ID space that can satisfy your tracking needs already, how nice is that?
In the past thirty years, I have not encountered a use-case where I thought, Oh, I wish I had one (or a million, billion, or whatever) IPv6 addresses available here! But then again, I haven't developed software for bad actors.
Most of your comment is pretty incoherent, but:
> In the past thirty years, I have not encountered a use-case where...
For me, the two things IPv6 does that I care about are
1) I get at least one globally-routable IP address for every machine on my LAN that I wish to have one.
2) I get multiple globally-routable subnets so that I can have networks on my LAN that are isolated from all other LAN networks, but are still able to have globally-routable addresses.
To make #2 work, you do need networking gear that's slightly better than bottom-of-the-barrel so that you can set up VLANs. If network gear vendors cared, they could pretty easily make those sorts of features standard in even bottom-of-the-barrel gear, but they do not, so they are not.
> In the past thirty years, I have not encountered a use-case where...
For me, the two things IPv6 does that I care about are
1) I get at least one globally-routable IP address for every machine on my LAN that I wish to have one.
2) I get multiple globally-routable subnets so that I can have networks on my LAN that are isolated from all other LAN networks, but are still able to have globally-routable addresses.
To make #2 work, you do need networking gear that's slightly better than bottom-of-the-barrel so that you can set up VLANs. If network gear vendors cared, they could pretty easily make those sorts of features standard in even bottom-of-the-barrel gear, but they do not, so they are not.
Except not really. You can't assign v6 addresses to people, because IPs are picked ephemerally by devices based on the IP range of the network they're attached to.
You need a separate protocol (like HIP or LISP) on top to map the identifier to its current network location, and at that point you're no longer limited by the size of the underlying address space.
You need a separate protocol (like HIP or LISP) on top to map the identifier to its current network location, and at that point you're no longer limited by the size of the underlying address space.
Gonna re-post my 2023 comment on IPv6:
>It is gradually becoming acceptable to dismiss IPv6 and suggest searching for a modern, practically minded alternative. Important first step in untangling the mess.
>Naturally opinions vary as to what exactly would constitute modern. Common complaint is the significant mixing of OSI layers, in particular application level concerns like significant baggage of encryption & authentication. And then there's my pet peeve of BSD Sockets API incompatibility which was introduced accidentally.
https://news.ycombinator.com/item?id=37119627
>It is gradually becoming acceptable to dismiss IPv6 and suggest searching for a modern, practically minded alternative. Important first step in untangling the mess.
>Naturally opinions vary as to what exactly would constitute modern. Common complaint is the significant mixing of OSI layers, in particular application level concerns like significant baggage of encryption & authentication. And then there's my pet peeve of BSD Sockets API incompatibility which was introduced accidentally.
https://news.ycombinator.com/item?id=37119627
I think that's an incredibly silly take. Any new protocol would first have to be implemented by all the routing dbd switching vendors. It would probably have a 3rd mutually incompatible addressing scheme, because yes IPv4s limited addresses space is still a problem there are countries that depend on v6s expanded address space to have sufficient connectivity (Particularly in APNIC).
Switching out the fundamental addressing protocol of the Internet is hard. You have to herd the cats of the hundreds of thousands of operators, device, operating system, and application vendors, and as long as the old protocol still works, no one has a strong incentive to switch. But they have a big distinctive of missing out on customers, or having to figure out the new protocol.
Any IPvNG is going to run face first into the same incentive problems that v6 has.
Switching out the fundamental addressing protocol of the Internet is hard. You have to herd the cats of the hundreds of thousands of operators, device, operating system, and application vendors, and as long as the old protocol still works, no one has a strong incentive to switch. But they have a big distinctive of missing out on customers, or having to figure out the new protocol.
Any IPvNG is going to run face first into the same incentive problems that v6 has.
Yeah. It's particularly silly because OP is suggesting to replace something that everyone except for network administrators and network hardware vendors can treat as "IP with large addresses" [0] with a "modern, practically minded alternative".
Like, does OP propose that we switch away from IP to something that behaves significantly differently? Good fucking luck getting all the little bugs and behavioral assumptions baked in to just about everything squared away over the next fifty years.
[0] And -for the most part- network admins can treat it like that, too.
Like, does OP propose that we switch away from IP to something that behaves significantly differently? Good fucking luck getting all the little bugs and behavioral assumptions baked in to just about everything squared away over the next fifty years.
[0] And -for the most part- network admins can treat it like that, too.
SMTP will never go IPv6 in my opinion.
IP reputation scoring is feasible with 4.3 billion IPv4 addresses.
That model breaks down when you’re dealing with 340,282,366,920,938,463,463,374,607,431,768,211,456 possible IPv6 addresses.
IP reputation scoring is feasible with 4.3 billion IPv4 addresses.
That model breaks down when you’re dealing with 340,282,366,920,938,463,463,374,607,431,768,211,456 possible IPv6 addresses.
That's not how SMTP reputation scoring works. Even in IPv4 per-IP reputation stopped being sufficient many years ago because bulk senders churn pools and rotate addresses. Modern systems typically score prefixes, ASNs, DKIM/SPF alignment, TLS and behavior.
About 58% of all of the email my company sends out of it's outbound relays is to IPv6 MXs. I've never really had to deal with discoverability issues related to v6
Microsoft and Google both have IPv6 addresses published for their MX
I published AAAA records for my MX hostnames a few years ago and so far only gmail.com is sending mails via IPv6, which is disappointing.
You can score subnets instead of individual ips.
Perhaps you mean “prefixes” such as they are assigned by registrars, and announced by routing protocols.
The instructor of my Cisco classes said that the only module that caused students to break down in tears was VLSM.
The instructor of my Cisco classes said that the only module that caused students to break down in tears was VLSM.
Weird. Once I made the analogy with street addresses that are divided into blocks then subnet masking was pretty easy to understand.
This forced me to dual stack just for AWS services to intercommunicate...