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 remember like 10 different IPv4 addresses, 6 of which are DNS servers where each octet is a single number, 1 is my router, 1 is my home network switch, 1 is my home server and the last one localhost.
The main thing all those have in common is they are either something I frequently use (all mentioned local IPs) or just stupid easy to remember (DNS servers), neither of which isn't possible for IPv6.
From memory isn't localhost for IPv6 not shorter than for IPv4? The answer is yes, it is ::1 and I was thinking of the Multicast and Link-local address prefixes which are ff00:: and fe80:: respectively.
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.
IPv6 cannot be backward-compatible with IPv4 in the way UTF-8 is with ASCII. Any argument built on that comparison reflects a misunderstanding of the protocols and leads to flawed conclusions.
Why not? Sincere question. As a very superficial idea, if we go back to the drawing board, for example we could decide our new cool concept of address to be an IPv4 + an hex suffix, maybe at the expense of not having a humongous address space.
So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version.
I just made this up, so I'm sure that a couple years of deep thought by a council of scientists and engineers could come up with something even better.
- Where in the bit pattern IPv4 mapped addresses should go
- Coming up with some variation of NAT64, NAT464, or similar concepts to communicate between/over IPv4 and IPv6 networks
- Blaming the optional extensions/features of IPv6 for being too complex and then inventing something which has 90% of the same parts which are actually required to use
It's even easy to get distracted in a world of "what you can do with IPv6" instead of just using the basics. The things that actually make IPv6 adoption slow are:
- A change in the size of the address field which requires special changes and configuration in network gear, operating systems, and apps because it's not just one protocol to think about the transport of again until the migration is 100% complete.
If IPv4 were more painfully broken then the switch would have happened long ago. People just don't care to move fast because they don't need to. IPv6 itself is fine though and, ironically, it's the ones getting the most value out of the optional extensions (such as cellular providers) who actually started to drive IPv6 adoption.
In IPv4 you only need to transmit IPv4 addresses. If the "cannot be" in parent post is referring to the exact byte disposition in packets, then I go the other way around to claim that I agree. Because the only way that a UTF8 character can pretend to be ASCII is because ASCII didn't use all of the 8 bits in a byte to begin with. Only way to have something similar in this case, would be that IPv4 didn't use all of the allocated bits for addresses... Which is not the case.
What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it. But I agree, that the actual packet header layouts would need to look at least a bit different.
> What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it.
Like:
> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]
They did that. Problem is that an ipv4 only host can't talk to ipv6. Adding more bits to ipv4 creates a new protocol just like ipv6 and has the same transition issues.
> So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version.
Like
> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
So you have to ship new code to every 'network element' to support your "IPv4+" plan. Just like with IPv6.
So you 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 "A+" address (for "IPv4+" 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. In any 'address extension' plan the legacy code cannot use the new address space; you have to:
* update the IP stack (like with IPv6)
* tell applications about new DNS records (like IPv6)
* set up translation layers for legacy-only code to reach extended-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.
Deploying the new "IPv4+" code will take time, there will partial deployment of IPv4+ is no different than having partial deployment of IPv6: you have islands of it and have to fall back to the 'legacy' IPv4-plain protocol when the new protocol fails to connect:
"Just adding more bits" means updating a whole bunch of code (routers, firewalls, DNS, APIs, userland, etc) to handle the new data structures. There is no "just": it's the same work for IPv6 as with any other idea.
(This idea of "just add more addresses" comes up in every discussion of IPv6, and people do not bother thinking about what needs to change to "just" do it.)
> If IPv4 were more painfully broken then the switch would have happened long ago.
IPv4 is very painful for people not in the US or Western Europe that (a) were now there early enough to get in on the IPv4 address land rush, or (b) don't have enough money to buy as many IPv4 addresses as they need (assuming someone wants to sell them).
So a lot of areas of the world have switched, it's just that you're perhaps in a privileged demographic and are blind to it.
> IPv4 is very painful for people not in the US or Western Europe that (a) were now there early enough to get in on the IPv4 address land rush, or (b) don't have enough money to buy as many IPv4 addresses as they need (assuming someone wants to sell them).
The lack of pain is not really about the US & Western Europe have plenty of addresses or something of that nature, it's that alternative answers such as NAT and CG-NAT (i.e. double NAT where the carrier uses non-public ranges for the consumer connections) deployments are still growing faster in those regions than IPv6 adoption when excluding cellular networks (they've been pretty good about adopting IPv6 and are where most of the IPv6 traffic in those regions comes from).
I think your summary is really great. One of the better refutations I've seen about the "what about v4 but longer??" question.
However, I think people do get tripped up by the paradigm shift from DHCP -> SLAAC. That's not something that is an inevitable consequence of increasing address size. And compared to other details (e.g. the switch to multicasting, NDP, etc.), it's a change that's very visible to all operators and really changes how things work at a conceptual level.
The real friction with SLAAC was that certain people (particularly some at Google) tried to force it as the only option on users, not that IPv6 ever forced it as the only option. The same kind of thing would likely occur with any new IP version rolling out.
Just split the address into two 32-bit chunks (call the top word the "pool", bottom word "address") and assign the full IPV4 range to pool 0x00000000. Done.
But then think about what the routing tables would look like, how would an IPv4-only host find an IPv6 host not in pool 0? You'd be reinventing NAT, but in a less-structured context than how NAT works today. There's more issues to it too.
If it was really that simple they would have done exactly that. "Just adding more bits to IPv4" just isn't possible to do backwards-compatibly. IPv6 is the closest you can get to that while also dealing with the complexity that arises with longer addresses.
Until you upgrade every router between 2 hosts so that it understands the IPv4b addressing scheme, those 2 hosts can't talk. And if you're going to upgrade them all anyway, then might as well do it right.
That doesn't change anything - until everyone adopts the new chunk nobody can use it (even one windows XP machine that you don't personally care about is enough to still kill it today). IPv6 is better because at least it can work side by side by IPv6.
> The first thing in the IP header is the version number.
So you just change the version number… like was done with IPv6?
How would this be any different: all hosts, firewalls, routers, etc, would have to be updated… like with IPv6. So would all application code to handle (e.g.) connection logging… like with IPv6.
I was addressing the narrow claim that you cannot distinguish ASCII from UTF-7. You can distinguish IPv4 from IPv6 by looking at the version field (and I forgot to mention the L2 protocol field is out of band from IP's perspective). Obviously if the receiver doesn't support UTF-7 or IPv6 then it won't be understood. Forward compatibility isn't possible in this case.
Right, the variable-length thing was my point. That's fine when you're dealing with byte slices that you scan through incrementally. But it's not fine for packets and OS data structures that had their lengths fixed at 32 bits.
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.
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.
People claim this all the time, but every time I push I discover they have no clue how networks work and just handwave away as "easy" or "details" the very reasons people who understand networks say it can't work.
I think you’re making my point - someone decided to surface a very low level concept “as is” (without a suitable abstraction) on a level where people also need it for use cases that don’t justify knowledge of the arcane. Or dealing with gatekeepers for that matter.
For most people there is no UX. Most US houses are IPv6 and use it without knowing anything about networking at all (most cable internet is IPv6, as the big cell networks).
The people who have to make networks work need to know how IPv6 works - but there is no getting around that - they know how IPv4 works too.
>every time I push I discover they have no clue how networks work
Listen here, if there is a networking technology or feature that I wasn't forced learn when I half-assed a SOHO router config in 2005, then it shouldn't exist at all.
Like there was any chance to see UX of this to work or not in most of places. I've never had an ISP that even offered any IPv6 connectivity besides mobile internet.
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.
That's because the Internet is basically broadcast TV 2.0 so no one cares about having public IPv4's at home as long as they can get to their memes and streaming. Great job, we took something that was meant to be a next frontier in humanity and let anyone connect with anyone else without gatekeepers/intermediaries and turned it 21st century brainrot troughs. Perhaps a society not in slow intellectual decline would have chosen otherwise.
> Great job, we took something that was meant to be a next frontier in humanity and let anyone connect with anyone else without gatekeepers/intermediaries
We already had that, it's called shortwave radio. The internet, especially as it's implemented and as it's used, is a terrible way to achieve this. It's service providers the whole way down.
It would be funny if HAM radio came back because the social filter imposed by the limitations wound up being more important than the technological capability.
His point is that you're managing alright because you live in a country where your ISP can give you a public IP address. The author lives in a country where that is not possible and accesses the Internet behind layers of NAT.
It's possible for Indian ISPs to buy IPv4 addresses and assign them to customers. Maybe not for $5/month but if you're willing to pay US prices (plus tax) you should be able to get US quality service.
> What's the difference, other than port forwarding? Does NAT cause some sort of unique issue that makes existence miserable?
The difference is that your home router does not get a public IP on its WAN interface, but perhaps the non-publicly-routable 100.64.0.0/10 [1] with CG-NAT.
So if you don't have a public IP address, how exactly are you supposed to forward anything? What is the other end supposed to connect to as an IP address?
> The difference is that your home router does not get a public IP on its WAN interface, but perhaps the non-publicly-routable 100.64.0.0/10 [1] with CG-NAT.
Yes...? I know that, but does that cause any issues in practice other than death of P2P?
> So if you don't have a public IP address, how exactly are you supposed to forward anything? What is the other end supposed to connect to as an IP address?
I already mentioned port forwarding because with something like CG-NAT, it is often not possible (or not allowed). But I am not aware of any issues that stem from this other than an inability for others to establish connections directly to you. In fact, my network has a public IPv4 without CG-NAT and yet I am already used to being unable to receive data other than back through a TCP stream. That is the entire reason reverse proxy tunnels (such as ngrok, etc.) exist.
Hole punching, which has various forms, may or may not work.
This means if you're doing something realtime, you may need to stick a server(reachable endpoint) in between it, at the very least reducing performance.
I have never seen any situation where this is not already necessary other than UPnP which already almost never works reliably. A publicly-addressable relay is already practically non-negotiable for anything over the internet.
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.
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.
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.
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...
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.
Whole model same as IPv4 (DHCP, NAT, ICMP, DNS, ...) just in v6. If IPv6 and IPv4 would be essentially the same from the get go, IPv4 would be a niche 20 years.
Sure everything above IPv6 have, but it took years and years of screaming to get it.
> Whole model same as IPv4 (DHCP, NAT, ICMP, DNS, ...) just in v6.
All of those things exist in IPv6.
And it is physically impossible for DNS to be the same, as you have 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.
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.
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.
Yup. People learn parts of v4 through osmosis because it's the default. Then when networking topics come up, it's easier to keep going with stuff that looks familiar rather than un-learning assumptions. Why bother with the weird other thing that's not even mandatory?
Because IPv4 is logical and makes sense. First thing which IPv6 came up with? No NATs everything will have a public address. It turned out that this was hare brained idea so let's just cover it up with firewall. However misconfigured firewall means that everything is open... IPv6 has been designed by people who were unable to think further than what is going to be tomorrow for a lunch.
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.
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.
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.
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).
> 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.
What makes you suggest that it's backbone hardware that is the problem? It's largely enterprise customers and tier 3 providers that don't really do IPv6 afaics.
>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.
Would say the opposite is true. Core routers were the first to enable V6 support in any network as they would need support it for anything else to even use it. They got regularly replaced as bandwidth needs keeps rising as well.
Plenty of isps advertise ipv6 but haven't managed to give it to customers yet.
Interrupts are hardly a problem with any nics of the last decade really.
> 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 remember like 10 different IPv4 addresses, 6 of which are DNS servers where each octet is a single number, 1 is my router, 1 is my home network switch, 1 is my home server and the last one localhost.
The main thing all those have in common is they are either something I frequently use (all mentioned local IPs) or just stupid easy to remember (DNS servers), neither of which isn't possible for IPv6.
From memory isn't localhost for IPv6 not shorter than for IPv4? The answer is yes, it is ::1 and I was thinking of the Multicast and Link-local address prefixes which are ff00:: and fe80:: respectively.
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.
IPv6 cannot be backward-compatible with IPv4 in the way UTF-8 is with ASCII. Any argument built on that comparison reflects a misunderstanding of the protocols and leads to flawed conclusions.
Why not? Sincere question. As a very superficial idea, if we go back to the drawing board, for example we could decide our new cool concept of address to be an IPv4 + an hex suffix, maybe at the expense of not having a humongous address space.
So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version.
I just made this up, so I'm sure that a couple years of deep thought by a council of scientists and engineers could come up with something even better.
Programmers really like to focus on things like:
- How they would format the display of the bits
- Where in the bit pattern IPv4 mapped addresses should go
- Coming up with some variation of NAT64, NAT464, or similar concepts to communicate between/over IPv4 and IPv6 networks
- Blaming the optional extensions/features of IPv6 for being too complex and then inventing something which has 90% of the same parts which are actually required to use
It's even easy to get distracted in a world of "what you can do with IPv6" instead of just using the basics. The things that actually make IPv6 adoption slow are:
- A change in the size of the address field which requires special changes and configuration in network gear, operating systems, and apps because it's not just one protocol to think about the transport of again until the migration is 100% complete.
If IPv4 were more painfully broken then the switch would have happened long ago. People just don't care to move fast because they don't need to. IPv6 itself is fine though and, ironically, it's the ones getting the most value out of the optional extensions (such as cellular providers) who actually started to drive IPv6 adoption.
How would you get someone that only knows about IPv4 addresses like 10.20.30.40 to send a packet to someone with an address 10.20.30.40:fa:be:4c:9d?
How do you squeeze that in IPv4 packet? Especially in a way that won't get mangled by random ossified devices in between?
In IPv4 you only need to transmit IPv4 addresses. If the "cannot be" in parent post is referring to the exact byte disposition in packets, then I go the other way around to claim that I agree. Because the only way that a UTF8 character can pretend to be ASCII is because ASCII didn't use all of the 8 bits in a byte to begin with. Only way to have something similar in this case, would be that IPv4 didn't use all of the allocated bits for addresses... Which is not the case.
What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it. But I agree, that the actual packet header layouts would need to look at least a bit different.
https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5....
& the following section for the follow-up embedding.
> What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it.
Like:
> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]
* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...
They did that. Problem is that an ipv4 only host can't talk to ipv6. Adding more bits to ipv4 creates a new protocol just like ipv6 and has the same transition issues.
> So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version.
Like
> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]
* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...
Or:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
* https://en.wikipedia.org/wiki/6to4
So you have to ship new code to every 'network element' to support your "IPv4+" plan. Just like with IPv6.
So you 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 "A+" address (for "IPv4+" 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. In any 'address extension' plan the legacy code cannot use the new address space; you have to:
* update the IP stack (like with IPv6)
* tell applications about new DNS records (like IPv6)
* set up translation layers for legacy-only code to reach extended-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.
Deploying the new "IPv4+" code will take time, there will partial deployment of IPv4+ is no different than having partial deployment of IPv6: you have islands of it and have to fall back to the 'legacy' IPv4-plain protocol when the new protocol fails to connect:
* https://en.wikipedia.org/wiki/Happy_Eyeballs
"Just adding more bits" means updating a whole bunch of code (routers, firewalls, DNS, APIs, userland, etc) to handle the new data structures. There is no "just": it's the same work for IPv6 as with any other idea.
(This idea of "just add more addresses" comes up in every discussion of IPv6, and people do not bother thinking about what needs to change to "just" do it.)
> If IPv4 were more painfully broken then the switch would have happened long ago.
IPv4 is very painful for people not in the US or Western Europe that (a) were now there early enough to get in on the IPv4 address land rush, or (b) don't have enough money to buy as many IPv4 addresses as they need (assuming someone wants to sell them).
So a lot of areas of the world have switched, it's just that you're perhaps in a privileged demographic and are blind to it.
> IPv4 is very painful for people not in the US or Western Europe that (a) were now there early enough to get in on the IPv4 address land rush, or (b) don't have enough money to buy as many IPv4 addresses as they need (assuming someone wants to sell them).
The lack of pain is not really about the US & Western Europe have plenty of addresses or something of that nature, it's that alternative answers such as NAT and CG-NAT (i.e. double NAT where the carrier uses non-public ranges for the consumer connections) deployments are still growing faster in those regions than IPv6 adoption when excluding cellular networks (they've been pretty good about adopting IPv6 and are where most of the IPv6 traffic in those regions comes from).
I think your summary is really great. One of the better refutations I've seen about the "what about v4 but longer??" question.
However, I think people do get tripped up by the paradigm shift from DHCP -> SLAAC. That's not something that is an inevitable consequence of increasing address size. And compared to other details (e.g. the switch to multicasting, NDP, etc.), it's a change that's very visible to all operators and really changes how things work at a conceptual level.
The real friction with SLAAC was that certain people (particularly some at Google) tried to force it as the only option on users, not that IPv6 ever forced it as the only option. The same kind of thing would likely occur with any new IP version rolling out.
For comparison IPv4 had:
And for IPv6: Some of these have had subsequent minor updates, e.g. DHCP was updated in 1997 and so on.DHCPv6 now exists and every OS except Android supports it.
> except Android
That alone is significant.
Furthermore, DHCPv6 holds you back from various desirable things like privacy addresses and (arguably even more importantly) IPv6 Mostly.
Wait, why couldn't it?
Just split the address into two 32-bit chunks (call the top word the "pool", bottom word "address") and assign the full IPV4 range to pool 0x00000000. Done.
Well for starters, IPv6 has 128 bit addrs.
But then think about what the routing tables would look like, how would an IPv4-only host find an IPv6 host not in pool 0? You'd be reinventing NAT, but in a less-structured context than how NAT works today. There's more issues to it too.
If it was really that simple they would have done exactly that. "Just adding more bits to IPv4" just isn't possible to do backwards-compatibly. IPv6 is the closest you can get to that while also dealing with the complexity that arises with longer addresses.
>how would an IPv4-only host find an IPv6 host not in pool 0?
Ah.
Until you upgrade every router between 2 hosts so that it understands the IPv4b addressing scheme, those 2 hosts can't talk. And if you're going to upgrade them all anyway, then might as well do it right.
In what world does is such a protocol any more *”””compatible”””* with IPv4 than IPv6 already is? It is a different header after all.
That doesn't change anything - until everyone adopts the new chunk nobody can use it (even one windows XP machine that you don't personally care about is enough to still kill it today). IPv6 is better because at least it can work side by side by IPv6.
Yep. Translation technologies like NAT64 and company basically as good a job as can be hoped for. And they're quite good nowadays!
But to stick with the ASCII->UTF-8 comparison: how would you have done the transition if you had to stay within ASCII's size of 7 bits?
https://en.wikipedia.org/wiki/UTF-7 exists, but was rarely used.
UTF-8 is convenient because ASCII has a spare bit, but UTF-8 is fundamentally possible because ASCII is variable-length. IPv4 is not variable-length.
> https://en.wikipedia.org/wiki/UTF-7 exists, but was rarely used.
UTF-7 was possible because there was an out-of-band mechanism to signal its use, "Content-Type: text/plain; charset=UTF-7":
* https://datatracker.ietf.org/doc/html/rfc2152
What's the OOB signalling in IP packet transmission between two random nodes on the Internet.
The first thing in the IP header is the version number.
> The first thing in the IP header is the version number.
So you just change the version number… like was done with IPv6?
How would this be any different: all hosts, firewalls, routers, etc, would have to be updated… like with IPv6. So would all application code to handle (e.g.) connection logging… like with IPv6.
I was addressing the narrow claim that you cannot distinguish ASCII from UTF-7. You can distinguish IPv4 from IPv6 by looking at the version field (and I forgot to mention the L2 protocol field is out of band from IP's perspective). Obviously if the receiver doesn't support UTF-7 or IPv6 then it won't be understood. Forward compatibility isn't possible in this case.
Right, the variable-length thing was my point. That's fine when you're dealing with byte slices that you scan through incrementally. But it's not fine for packets and OS data structures that had their lengths fixed at 32 bits.
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.
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.
People claim this all the time, but every time I push I discover they have no clue how networks work and just handwave away as "easy" or "details" the very reasons people who understand networks say it can't work.
I think you’re making my point - someone decided to surface a very low level concept “as is” (without a suitable abstraction) on a level where people also need it for use cases that don’t justify knowledge of the arcane. Or dealing with gatekeepers for that matter.
For most people there is no UX. Most US houses are IPv6 and use it without knowing anything about networking at all (most cable internet is IPv6, as the big cell networks).
The people who have to make networks work need to know how IPv6 works - but there is no getting around that - they know how IPv4 works too.
>every time I push I discover they have no clue how networks work
Listen here, if there is a networking technology or feature that I wasn't forced learn when I half-assed a SOHO router config in 2005, then it shouldn't exist at all.
SLAAC + mDNS makes IPv6 basically invisible.
Like there was any chance to see UX of this to work or not in most of places. I've never had an ISP that even offered any IPv6 connectivity besides mobile internet.
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.
That's because the Internet is basically broadcast TV 2.0 so no one cares about having public IPv4's at home as long as they can get to their memes and streaming. Great job, we took something that was meant to be a next frontier in humanity and let anyone connect with anyone else without gatekeepers/intermediaries and turned it 21st century brainrot troughs. Perhaps a society not in slow intellectual decline would have chosen otherwise.
> Great job, we took something that was meant to be a next frontier in humanity and let anyone connect with anyone else without gatekeepers/intermediaries
We already had that, it's called shortwave radio. The internet, especially as it's implemented and as it's used, is a terrible way to achieve this. It's service providers the whole way down.
It would be funny if HAM radio came back because the social filter imposed by the limitations wound up being more important than the technological capability.
> It's service providers the whole way down.
And still likely better than heavily regulated airwaves.
There are definitely problems, but IRC in the 90s had strong ham radio vibes imo.
I do agree.
But at the same time there is a quote by Stanisław Lem...
"Until I used the Internet, I didn't know there were so many idiots in the world"
His point is that you're managing alright because you live in a country where your ISP can give you a public IP address. The author lives in a country where that is not possible and accesses the Internet behind layers of NAT.
It's possible for Indian ISPs to buy IPv4 addresses and assign them to customers. Maybe not for $5/month but if you're willing to pay US prices (plus tax) you should be able to get US quality service.
You can even buy a block, but the smallest one has 256 addresses.
What's the difference, other than port forwarding? Does NAT cause some sort of unique issue that makes existence miserable?
> What's the difference, other than port forwarding? Does NAT cause some sort of unique issue that makes existence miserable?
The difference is that your home router does not get a public IP on its WAN interface, but perhaps the non-publicly-routable 100.64.0.0/10 [1] with CG-NAT.
So if you don't have a public IP address, how exactly are you supposed to forward anything? What is the other end supposed to connect to as an IP address?
[1] https://en.wikipedia.org/wiki/IPv4_shared_address_space
> The difference is that your home router does not get a public IP on its WAN interface, but perhaps the non-publicly-routable 100.64.0.0/10 [1] with CG-NAT.
Yes...? I know that, but does that cause any issues in practice other than death of P2P?
> So if you don't have a public IP address, how exactly are you supposed to forward anything? What is the other end supposed to connect to as an IP address?
I already mentioned port forwarding because with something like CG-NAT, it is often not possible (or not allowed). But I am not aware of any issues that stem from this other than an inability for others to establish connections directly to you. In fact, my network has a public IPv4 without CG-NAT and yet I am already used to being unable to receive data other than back through a TCP stream. That is the entire reason reverse proxy tunnels (such as ngrok, etc.) exist.
Hole punching, which has various forms, may or may not work. This means if you're doing something realtime, you may need to stick a server(reachable endpoint) in between it, at the very least reducing performance.
I have never seen any situation where this is not already necessary other than UPnP which already almost never works reliably. A publicly-addressable relay is already practically non-negotiable for anything over the internet.
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.
> I have multiple static IPv4 addresses and they have suited me just fine for decades
IPv6 is for the people (countries, continents) who did not get in early on the IPv4 address gold rush. Your take is basically "got mine, F you".
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.
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.
Yes, there's lots of content on IPv4, and there is also a lot of traffic from India...
If India were to turn off IPv4, it would be a great incentive for IPv4-only sites in the US and Europe to add an IPv6 address.
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...
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%:
* 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.
What changes to IPv6 would you make to make it easier to transition?
Whole model same as IPv4 (DHCP, NAT, ICMP, DNS, ...) just in v6. If IPv6 and IPv4 would be essentially the same from the get go, IPv4 would be a niche 20 years.
Sure everything above IPv6 have, but it took years and years of screaming to get it.
> Whole model same as IPv4 (DHCP, NAT, ICMP, DNS, ...) just in v6.
All of those things exist in IPv6.
And it is physically impossible for DNS to be the same, as you have 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.
> All of those things exist in IPv6.
And it has not existed at the start of the IPv6 and is one of the many reasons why after all those years we are having a poor penetration of IPv6.
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.
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.
ARP-schmarp. That doesn't matter to almost anyone who doesn't need to go deep into the network.
But yeah, SLAAC's paradigm of moving assignment logic into the node (away from network infra like in DHCP) is definitely a stumbling point.
Yup. People learn parts of v4 through osmosis because it's the default. Then when networking topics come up, it's easier to keep going with stuff that looks familiar rather than un-learning assumptions. Why bother with the weird other thing that's not even mandatory?
Because IPv4 is logical and makes sense. First thing which IPv6 came up with? No NATs everything will have a public address. It turned out that this was hare brained idea so let's just cover it up with firewall. However misconfigured firewall means that everything is open... IPv6 has been designed by people who were unable to think further than what is going to be tomorrow for a lunch.
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.
No mention of Indian ISPs just buying IPv4 addresses. Prices are even declining.
Author if you are reading comments, rss feed entries point to example.com
the link to the full table somehow doesn't work for me
Fixed
Thanks! Check now.
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.
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.
2026:
Yeah, that's the problem. And I bet they could enable it, they just don't want to for some reason.
Azure has very poor V6 support last I tried it.
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).
[1]: https://en.wikipedia.org/wiki/Second-system_effect
[2]: https://en.wikipedia.org/wiki/Robustness_principle
[3]: https://lwn.net/Articles/362339/
> 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.
What makes you suggest that it's backbone hardware that is the problem? It's largely enterprise customers and tier 3 providers that don't really do IPv6 afaics.
>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.
Would say the opposite is true. Core routers were the first to enable V6 support in any network as they would need support it for anything else to even use it. They got regularly replaced as bandwidth needs keeps rising as well.
Plenty of isps advertise ipv6 but haven't managed to give it to customers yet.
Interrupts are hardly a problem with any nics of the last decade really.
Companies like Facebook can and do use 240/4.
> 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.
[1] https://en.wikipedia.org/wiki/IPv4_shared_address_space
so ipv6 is now a social justice issue? I'll send you the $2 a month for a elastic IP .
To reduce doing things twice there is NAT64/646XLAT. How many v4 addresses have you memorized, I normally use DNS or mDNS.
that reduces part of the scope for some of the customers
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.
that address doesn’t even work in the address bar
... and annoying casting from `sockaddr` to either `sockaddr_in` or `sockaddr_in6*` while you pass around a socklen_t.
10 years ago I was all gung-ho about IPv6, but it's annoying at every level.
Having 2 sockets for loopback or multiple interfaces is a huge pain
IPv6 is totally an equality issue. If a sizeable proportion of this forum had to share an IP address we would've had IPv6 done years ago.