IPv6's biggest problem remains not that it's badly designed (at least not nowadays, there were problems but they were solved ten years ago) but that millions of network engineers never bothered to look deeper into IPv6 than "I don't get it, this feels off".
You can't make a backwards compatible "IPv4 with more bits" like people dream of. L2 routers and middleboxes would still need to be replaced, software would still need to be rewritten, nothing would be different. IPv4 changed how private networks worked because its first attempt at private networks failed.
People are stuck with the IPv4 mindset through a combination of lacking education (who even taught IPv6 when our current sysadmins were in college?) or assuming IPv4 is normal and well thought out. There are free guides, books, and playgrounds out there if you want to learn IPv6, so the education problem is one you can solve yourself. Realizing the flawed nature of IPv4 is harder.
I've come from IPv4 networking, but learning IPv6 later made me realize how silly old networks really are. DHCP is a hack to solve a design failure in IPv4 and SLAAC is a much better solution. Companies have started relying on awful hacks originating from when companies decided to staple features to a side effects of a generic address distribution protocol. ARP feels more like a placeholder that should've been included a layer lower or higher in the network graph, put in its own little place to solve the theoretical "what if we don't run IP over our switch" problem that stopped being relevant decades ago.
As annoying as it may be, we live in an age where the OSI model with seven layers of networking protocols don't exist. Token ring is dead, SCTP died in the womb, Ethernet II exist purely in theory. The world now runs on HTTPS on top of UDP or TCP on top of IPv6/4, on top of some kind of wire that carries ethernet.
Ethernet now exists to support IP and vice versa in 99% of all use cases. TCP and UDP exist to serve HTTPS, or some legacy protocol that will be rewritten into HTTPS in the next ten years. WiFi and high-speed data networks came in as a whole new networking system and have turned out to be "what if ethernet, but wireless" with some control logic to make the wireless antennae talk. The OSI model and all the expansion and flexibility it provided simply died over a decade ago. Anything on top of the data link exists purely to support Ethernet + IP + HTTPS.
The migration path to IPv6 is now blocked by excuses. People pretended to care about servers not supporting IPv6 as the reason not to use but, but three or four different ways of providing backwards compatibility to all IPv4 clients were thought up and nobody actually asked for any of them. People complained that their data center provider didn't support IPv6 but now that enabling IPv6 is just a single click in a web UI they don't enable it anyway. People cared about the IPv6 privacy risks but never let go of that concept even after rfc4941 fixed that oversight. Companies like Microsoft and Github, too incompetent to set up a network that their dollar store competitors have supported for years now, have become something to point at and go "see? we need those!" as if NAT64/DNS64/464XLAT/SIIT/whatever haven't been providing IPv4 compatibility for years now.
"I don't know enough about it" and "I don't like it" are perfectly good excuses not to enable IPv6 in your home network, but they're not design flaws or protocol problems. If you're willing to accept the packet maiming we have nicknamed "NAT" or even "CG-NAT", you should feel refreshed at the sight of the plain and simple protocols IPv6 provides you with.
The way people talk about IPv6 now reminds me of the way people talked about HTTPS back when Let's Encrypt started gaining popularity, and the way people dealt with systemd reinventing a better Linux management system. Grumpy people, clinging to what they know, delaying unavoidable change until the very last moment. You can be like the Dracut people running ipromiseiwillneverrunssl.com if you want, but it's a losing battle.
If the people who would use IPv6 don't like it and don't want it, if they think it's bad, then it's bad.
When forest rangers observe hikers repeatedly deviating from the official trail at certain spots, the ranger understands this to mean the trail is wrong, and he re-designs it to accommodate the hikers. The forest ranger is able to do this because he understands what the trail is for: it's for the hikers, and he empathizes with and adapts to the hiker's needs, not his own needs, not his ego, not his whims. Never does the forest ranger defend a bad trail. The forest ranger takes feedback without ego, and he is able to do so because he does not personally identify with the trail, he identifies with the needs of the hikers.
Engineers would do well to become more like the forest ranger. Many engineers seriously lack empathy for end-users, which results in the engineer creating inadequate products/services that don't meet the user's real needs. Even worse, when the product/service is criticized, when the engineer is given an opportunity to improve the product, the engineer instead blames the user, rather than himself, rather than adapt and recalibrate to the user's needs, he submits to his own ego, his own pride.
It's this lack of empathy and user-blame that yields poor results, results like IPv6.
I really like this – thank you for writing it! A related (but not quite the same, I think) idea is that people should not have to bend to technology; technology should bend to people.
It can be difficult to design for people, though. People tend to over- or underestimate the frequency and severity of rare events, are susceptible to the normalization of deviance, and due to their finite nature, fail to consider wider or longer-term implications of their decisions. Going along with the analogy: forest rangers also have a duty to protect the forest (and in fact, I think this ought to take precedent over accommodating hikers) and they also want to guide hikers away from dangerous terrain or wildlife that underprepared hikers may be tempted to visit.
I think the core idea here is "design around the way users actually behave, not the way they ought to behave".
> Many engineers seriously lack empathy for end-users, which results in the engineer creating inadequate products/services that don't meet the user's real needs.
Ain't that the truth. Modern operating systems are getting worse by the year.
That said, IPv6 has been significantly altered. SLAAC was fixed with two RFCs, one a decade IPv6 was designed, and another in 2015 for fixing oversights in duplicate address detection. DHCPv6 got updated with all kinds of options and it was already late to the party. RDDNS got added in 2007 and updated with more options in 2017. IPv6 Privacy Extensions got added when people brought up the privacy issues with SLAAC. People set up their own weird 4-to-6 translation mechanisms so various standards were introduced to cover any use case you may need.
IPv6 as it was originally designed is practically unusuable today. The trails have since been adjusted and the hungry mountains lions are gone. The hikers don't even notice the difference from their old paths.
However, park management decided that hikers should never go down the new and improved trail because they heard a story from their friend once that someone got lost there fifteen years ago, and some of them have lost the map to the start of the trail.
Users aren’t cognizant of the design issues. Users don’t like ipv6 because it causes them operational problems. ISPs have done a really shit job of managing the transition.
I gave a couple of talks promoting IPv6 in 1999 and I'm happy that I finally have it at home as a residential customer. (I didn't until this year.)
I'm also working on a project to reclaim some IPv4 address space, which people often object to on the grounds that people should "just use IPv6". So I have to defend the legitimacy of the demand for IPv4 address space.
In connection with this issue, I recently ran some DNS lookups against lists of top 1,000,000 domains (the last Alexa one and the Cisco Umbrella one). What we see is that only dozens to hundreds of "top million sites" (depending on one's definition of "sites" and so on) are IPv6-only. That is, less than 0.1% of Internet sites currently have an AAAA record without a corresponding A record, notwithstanding things like Mythic Beasts's offering to sell this configuration to them.
The over 99.9% of sites that still have an A record have it for a very good reason, which is that somewhere around half of all of their users (of course, quite a bit more in some regions and markets, and quite a bit less in others) would be unable to reach them at all otherwise. This is probably going to be true for a long time, even if that fraction keeps creeping steadily downward, and there's not much the site operators can do about that.
On the other hand, maybe you're talking about things like the "A record but no AAAA record" case (sites that don't offer IPv6 support). This is around 45% of FQDNs that have any form of address record, according to my scans using recent Cisco Umbrella data. I don't particularly have a defense of this; in fact, I find it really unfortunate. I happen to also be involved with Let's Encrypt, and I've often seen a pattern where smaller site operators, at least, show no awareness of what IPv6 is and no desire to debug it (e.g. if their certificate request fails because their old AAAA record was broken). I think Happy Eyeballs has been kind of bad on this particular dynamic: small site operators will themselves perceive their sites as working fine with completely broken IPv6 configurations, and it can be hard to convince them otherwise!
I'd love to see some kind of tool, messaging, initiative, or whatever that would encourage the long tail of site operators to be willing to spend, like, three minutes learning that IPv6 is a thing and that it's good if they have it set up correctly rather than not having it set up correctly. I still don't know what that would look like. I've seen dozens, if not hundreds, of forum posts telling people various forms of "it looks like your AAAA record is out of date; maybe you should delete it".
> The over 99.9% of sites that still have an A record have it for a very good reason
A records work on v4 and v6, so they'll probably stick around for a while. Perhaps they'll end up being concentrated around 4-to-6 forwarding NAT-as-a-service companies, but they're the fallback mechanism. I don't think anyone is advocating for dropping A all together unless you're really trying to pinch pennies.
> I'd love to see some kind of tool, messaging, initiative, or whatever
If Google and Microsoft decided to put even the slightest bit of preference towards IPv6 capable websites, I think SEO hacking would do the rest for us.
> like, three minutes learning that IPv6 is a thing and that it's good if they have it set up correctly rather than not having it set up correctly
Learning to set up IPv6 properly will take more than three minutes. As much as I think IPv6 is a better designed protocol now that the necessary RFCs have come out, there's still a huge difference with legacy IP stuff. The concept of link-local addresses needs to be conveyed or people will put fe80:: addresses in their DNS records, and concepts like /48 or /64 subnets representing customers needs to be explained to prevent bots and spammers from taking over. Unlearning NAT and realizing NAT≠firwall is also something that can take surprisingly long. Enabling IPv6 may take five minutes, but the required background knowledge can take a day or more of learning and experimenting.
Internet forum posts about deleting AAAA records are a great helpfulness thermometer for a forum. I treat them the same as the "just disable SELinux" posts; if that's a popular opinion, the forum probably doesn't know what it's talking about so all advice that gets upvoted there needs to be taken with a grain of salt. They're a problem, but also a warning beacon.
NAT is certainly not a firewall, but it is a very useful router function. I still don't understand how IPv6 makes NAT a thing that isn't useful to know.
I want to expose my servers to the internet through a single shared IP address, and to be able to have those servers exist on different IP addresses inside my network. How does IPv6 allow this without NAT?
By reverse proxying. Run a load balancer on a single machine and have that reverse proxy connections to their destination.
But what if you insist on not using a proxy for whatever reason?
When people say "NAT", they're usually talking about SNAT/MASQUERADE, i.e. NATing outbound connections. What you're asking for here is port forwards/DNAT, i.e. applying NAT to redirect an inbound connection.
If you want to NAT inbound connections, you can do it without NATing outbound connections. Essentially: you don't need to "NAT", you just need to port forward.
Honestly, I think you should just suck it up and use different hostnames for different services, because running all of your services on one IP is really bad for security since it makes it much easier to enumerate every service you're running -- it only takes scanning 65k ports on one IP to find them all, rather than 65k ports on 2^64 IPs. That's the difference between megabytes and yottabytes of port scan traffic.
(If you NATed outbound connections to also come from this IP then things get even worse because every outbound connection from any of your machines immediately informs the server of the IP needed to make an inbound connection to you. That's a completely unnecessary security sacrifice.)
But if you're going to run everything on one IP without proxying, you only need port forwards to do it, you don't need to run the network on some local IP range too.
> I think you should just suck it up and use different hostnames for different services, because running all of your services on one IP is really bad for security since it makes it much easier to enumerate every service you're running
I really, really don't want to do this for a ton of reasons. Port scanning isn't high on my security worries, to be honest. I've been dealing with that for decades and am well-protected, so that's not a compelling reason for me.
> The world now runs on HTTPS on top of UDP or TCP on top of IPv6/4, on top of some kind of wire that carries ethernet.
Am I misunderstanding what you mean by "the world" here? Most of the networks I work with are not HTTPS on top of UDP or TCP.
> Grumpy people, clinging to what they know, delaying unavoidable change until the very last moment
This seems unrealistically broad. For all of the things you cite, there are downsides along with upsides. For all of them, we lose something as well as gain something. That means there's a cost (even ignoring the cost of making the change itself) as well as a benefit. That means a cost/benefit calculation takes place, and the results of that calculation are not guaranteed to be in favor of the replacement tech.
You can't make a backwards compatible "IPv4 with more bits" like people dream of. L2 routers and middleboxes would still need to be replaced, software would still need to be rewritten, nothing would be different. IPv4 changed how private networks worked because its first attempt at private networks failed.
People are stuck with the IPv4 mindset through a combination of lacking education (who even taught IPv6 when our current sysadmins were in college?) or assuming IPv4 is normal and well thought out. There are free guides, books, and playgrounds out there if you want to learn IPv6, so the education problem is one you can solve yourself. Realizing the flawed nature of IPv4 is harder.
I've come from IPv4 networking, but learning IPv6 later made me realize how silly old networks really are. DHCP is a hack to solve a design failure in IPv4 and SLAAC is a much better solution. Companies have started relying on awful hacks originating from when companies decided to staple features to a side effects of a generic address distribution protocol. ARP feels more like a placeholder that should've been included a layer lower or higher in the network graph, put in its own little place to solve the theoretical "what if we don't run IP over our switch" problem that stopped being relevant decades ago.
As annoying as it may be, we live in an age where the OSI model with seven layers of networking protocols don't exist. Token ring is dead, SCTP died in the womb, Ethernet II exist purely in theory. The world now runs on HTTPS on top of UDP or TCP on top of IPv6/4, on top of some kind of wire that carries ethernet.
Ethernet now exists to support IP and vice versa in 99% of all use cases. TCP and UDP exist to serve HTTPS, or some legacy protocol that will be rewritten into HTTPS in the next ten years. WiFi and high-speed data networks came in as a whole new networking system and have turned out to be "what if ethernet, but wireless" with some control logic to make the wireless antennae talk. The OSI model and all the expansion and flexibility it provided simply died over a decade ago. Anything on top of the data link exists purely to support Ethernet + IP + HTTPS.
The migration path to IPv6 is now blocked by excuses. People pretended to care about servers not supporting IPv6 as the reason not to use but, but three or four different ways of providing backwards compatibility to all IPv4 clients were thought up and nobody actually asked for any of them. People complained that their data center provider didn't support IPv6 but now that enabling IPv6 is just a single click in a web UI they don't enable it anyway. People cared about the IPv6 privacy risks but never let go of that concept even after rfc4941 fixed that oversight. Companies like Microsoft and Github, too incompetent to set up a network that their dollar store competitors have supported for years now, have become something to point at and go "see? we need those!" as if NAT64/DNS64/464XLAT/SIIT/whatever haven't been providing IPv4 compatibility for years now.
"I don't know enough about it" and "I don't like it" are perfectly good excuses not to enable IPv6 in your home network, but they're not design flaws or protocol problems. If you're willing to accept the packet maiming we have nicknamed "NAT" or even "CG-NAT", you should feel refreshed at the sight of the plain and simple protocols IPv6 provides you with.
The way people talk about IPv6 now reminds me of the way people talked about HTTPS back when Let's Encrypt started gaining popularity, and the way people dealt with systemd reinventing a better Linux management system. Grumpy people, clinging to what they know, delaying unavoidable change until the very last moment. You can be like the Dracut people running ipromiseiwillneverrunssl.com if you want, but it's a losing battle.