▲ 179 points
back
306 comments
I have several times cited it as a key article, more insightful than almost anything else I've ever read about IPv6, but I concede it is overlong and unclear and needs more illustrations. (Which, as a technical writer myself, I generally regard as a crutch.)
I think the core argument can be summarised as this:
1. IPv6 is flawed because it has 2 main layers, but it needed 3.
2. It understands physical addresses, and it has its own logical addresses.
3. But it really needed another layer in between them: a virtual translation/mapping layer.
4. Crucially, it lacks this. As such it is not better enough than IPv4 to ever totally replace IPv4.
5. But apenwarr proposes that it is, in essence, possible to fake this using QUIC.
https://en.wikipedia.org/wiki/QUIC <- note the diagram in that article.
6. Using this, it's possible to fake what IPv6 should have had but didn't, and get some of the benefits at the cost of more work.
7. However IPv6 remains doomed to never totally replace IPv4.
Boiling that down to 2 key points:
Point A: IPv6 is broken because it didn't go far enough; its mapping model is fundamentally inadequate.
Point B: It's OK, here's how we can work around that, but it doesn't fix the problem & never will.
And generalising from that argument, my take is this:
Butler Lampson said: "All problems in computer science can be solved by another level of indirection."
David Wheeler pointed out: "… except for the problem of too many layers of indirection."
The corollary of this is: it is imperative to closely track how many layers of indirection you have.
Too many is bad, but arguably, not enough is worse.
With too many, you get inefficiency, but you can nonetheless get the job done. But with too few, you might not usefully be able to do the job at all.
IPv6 did not have enough, and so failed to achieve its primary goal.
I read the article, also found it a bit confusing and wayward, and couldn't quite articulate why I disagreed with it at first, but I think I can now.
- The "mobile IP" problem isn't IP's job and should not be. IP should be as stateless as possible because this makes it cheap and easy to add capacity and redundancy to a network.
- IP addresses are assigned to interfaces, not people, computers, devices, applications, nodes, etc. If you want a fixed reference identifier associated to something across the wire, it is correct to implement that in addition to the state it requires on top of IP. If your application assigns or assumes identity based on IP address, that's a badly written application at this point.
> Y has no idea what that means, and throws it away.
X should have sent Y a session ID? The client and server should maintain session IDs and not the IP layer (imagine the security issues)?
- I think the author mostly has a problem with TCP. QUIC may become the next TCP. And that's fine.
The single biggest mistake IPv6 made was not encompassing the entire IPv4 space within it to ease transition.
As it is, I am seeing a transition to either non-IP or LISP/HIP based methodologies due to security and attestation concerns.
> As such it is not better enough than IPv4
That's the crux of it.
Sometimes I think we'd be better off forgetting about IPv6, and starting afresh with an IPv7 - something that provides a meaningful incentive to upgrade.
> Point A: IPv6 is broken because it didn't go far enough
Alternatively, it failed because it went too far. When you have an established system which is used everywhere, it is immensely difficult to replace it.
Something like IPv4, with 64 bit addressed might have been easier to push through. Eg, addresses like 123.123.123.123.123.123.123.123.
We have jumbo frames, why not jumbo addresses?
I pulled out this as the most salient point in the article: IPV6 designers assumed that IPV4 would be phased out completely in a short period of time, for some definition of a short period of time, and IPV6 would completely replace internet networking.
I think it was protocol design hubris: we are fixing SO MUCH STUFF that people will flock to this irresistible shining trophy of protocol design.
And now it's been ... almost ... 30 years.
Which means what is really necessary is a new IP protocol that will somehow, SOMEHOW (don't ask me how, I don't effing know) speak seamlessly to IPV4 and IPV6, and be so irresistible that people will want to migrate off of both.
I almost wonder if what is necessary isn't a formally predesigned protocol. What is needed is someone, somewhere, to come up with an approach that becomes a grassroots, and the industry rushes towards it. I don't even know if such a thing is possible anymore, IPV4 land may at this point be complexity theory/mathematically impossible to make a N+1 umbrella protocol of any real "elegance".
Lampson attributed that “fundamental theorem of software engineering” to Wheeler, he did not claim to have said it first.
(2017), and it should be noted that the author has updated his views since then: https://apenwarr.ca/log/20200708 ("IPv4, IPv6, and a sudden change in attitude", 2020).
And, lest anybody be misled by the title you quoted,
> No, I'm not switching sides. IPv6 is just as far away from universal adoption, or being a "good design" for our world, as it was three years ago.
"The awesome unstoppable terribleness that is Postel's Law."
Eloquence for the ages.
About a year ago I started the IPv6 migration for my home network (2 Remote sites, connected via IPSEC, with 10 VLANs (subnets) and about 70 devices, 10 people).
- I started on one side of the IPSEC, where I have an OPNsense
- there were like 5 updates of OPNsense in the last year where different IPv6 issues were fixed (and others have been introduced).
- my ISP only hands out /64-Prefixes, and these are also dynamic, which makes configuration more difficult
- a number of times I had to turn off IPv6 because different parts were suddenly not working anymore, mostly based on software issues in my stack
All of that over 20 years after IPv6 was introduced makes me wonder if it is the correct technology, if it is so difficult to implement.
I really really don't get ISPs' difficulties in deploying IPv6. The only conclusion I can reach that actually makes sense is that they don't have the in-house talent to deploy it and refuse to hire someone who does. I guess there's just not enough pain in staying IPv4-only or halfway implementing IPv6 to make them get up and do something about it?
> there were like 5 updates of OPNsense in the last year where different IPv6 issues were fixed (and others have been introduced)
That's a bummer. I've been using FreeBSD + pf at home for years now, and it's been smooth sailing.
> my ISP only hands out /64-Prefixes, and these are also dynamic, which makes configuration more difficult
Comcast/Xfinity hands out a /60, which means I get 16 x /64 subnets. And they haven't changed my subnets in at least four years. Pro-tip: when you change firewall hardware, keep the same MAC addr to keep the same IPv4, keep the same DHCP Unique Identifier (DUID) (/var/db/dhcp6c_duid on FreeBSD) to keep the same IPv6 subnets.
You're comparing two remote sites linked by IPv4 NAT to distributing IPv6 from a /64 (which was never meant to be subdivided) which is dynamic..
IPv6 failed because they tried to boil the ocean. It was design by committee, where everyone got their pet feature thrown in to appease and gain consensus. Alternatively IPv4 is a mountain of small hacks, which is its biggest strength.
We could have done a lot of good by adopting proposals to extend v4 like 0/8 and class D, but instead the decision was made to collectively drown the babies in the bathwater and insist on v6 at all costs.
It's looking more like a slow victory than a failure: https://www.google.com/intl/en/ipv6/statistics.html
People like to complain a lot about the new features in v6, but they don't make it any worse as a v4 replacement.
I run a large multi-campus network. At least 75% of our outgoing Internet traffic is IPv6. Looking at home ISPs accessing our services, it’s at least the majority of them coming in on IPv6. My guess is it’s a similar ratio as outgoing.
IPv6 has issues but it hasn’t failed.
IPv6 did not fail. It's used by a sizeable chunk of hosts, network owners made investitions in hardware, software and skills. It's not going anywhere, like it or not. Just like IPv4 will not go anywhere. They will coexist.
I still don't understand why IPv6 is a thing. End users can use NAT just fine. Servers can use CDNs and reverse proxies, sharing single IPv4 address among any number of hostnames. But it is a thing, so it's hard to imagine any other protocol to take over.
Freeing up more IPv4 space wouldn't have helped. IANA was assigning /8 per month at the end. The extra space would have gone in less than a year.
IPv6 would have worked better if they had made minimal changes to the support protocols. But it was have had slow adoption because there was no incentive to switch until addresses ran out.
It really doesn't matter if your part of the ocean didn't make it to the boiling committee.
The one thing that mattered was more address space. 4 billion addresses are not enough for the world. Anything else in ip6 is nice to have but falls off a cliff of importance and naval gazing that, if really of even nearly comparable significance, would be better directed to ipX or whatever's next.
IP6 is already facilitating connectivity for billions. Globally. That's a pretty major thing, more so than renditions of doing it my way.
The author would have liked Xerox Network Services. The Xerox plan was that devices had a 48-bit Ethernet address, and local area networks had a 32-bit network ID. Routing was by network ID until the packet hit the final LAN. No need for IP-level addressing.
Early Stanford and PARC routers could route XNS packets, but this died out some time in the 1980s.
Ugh. This is one of my favorite "what ifs" in the computer engineering.
Things I would change:
1. Use 72-bit addresses. 56 bits for the network address, 16 bits for the end-user networks.
2. Just use the IPv4 "local subnet" prefix logic for broadcast domains. No "on-link" nonsense.
3. Replacing ARP with neighbor discovery via multicast messages to interface addresses is... ok? But it's not necessary.
4. Remove SLAAC and stateless DHCPv6. Statefulness is helpful for network management.
5. Reify the MTU into the IP layer. No more ICMP nonsense for PMTU.
6. Rework extension headers to be actually useful. No more "next header" bullshit.
I must admit I'm at a loss about this IPv6 hate. I love IPv6.
I love that (almost) every IPv6 subnet is a /64. Just this morning I assumed an IPv4 subnet was a /24, only to discover it was a /20, causing me to spend a couple of minutes re-working.
I love that (almost) every IPv6 is a /64 because you'll never have to widen a subnet because you started of with a /24, but then after your office grew to 200 people you had to switch to a /20. And no matter how automated you are, there are always some important devices that have static IPs and that you have to reconfigure manually.
I love that every IPv6 client gets a routable IP. This means NAT isn't necessary. NAT is a clever hack, but we've grown so accustomed to it that we've become blind to its failings. I've had to trace packets coming out of a corporate NAT, then into an AWS ELB (Elastic Load Balancer) back into a different NAT. With the IP address remappings, it's awful
IPv4 NAT can also lead to IP address collisions. Your home subnet is 192.168.0.0/24? And so's your work? Good luck VPN'ing in.
I like that IPv6 has an abundance of IPv6 addresses—I don't need to share the ports on my sole IPv4 address to 5 different machines.
The IP/Ethernet section is surprising to me. It sort of claims that there is no reason to have ARP and give your default router an IP when you could just give it a MAC address and skip the ARP. Maybe this is true now but it reads like it was a bad idea at the time.
I wasn’t there (sounds like Apen was?) so I could be missing context, but I was under the impression that there were loads of layer 2 protocols at the time IP was designed (token ring, frame relay, etc) and so IP needed to be agnostic to the L2 protocol in order to be adopted.
Related:
The world in which IPv6 was a good design (2017) - https://news.ycombinator.com/item?id=25568766 - Dec 2020 (131 comments)
The world in which IPv6 was a good design (2017) - https://news.ycombinator.com/item?id=20167686 - June 2019 (238 comments)
The world in which IPv6 was a good design - https://news.ycombinator.com/item?id=14986324 - Aug 2017 (191 comments)
>It's hard to imagine a network interface (except ppp0) without a 48-bit MAC address?
Not super common but there's Infiniband. Latter versions supported encapsulating ethernet frames (Ethernet over InfiniBand) but not all hardware supports it. Otherwise it's straight IP over IB. There must be other niche networking technology that does IP without Ethernet.
35% worldwide by population of users in random samples at APNIC:
https://stats.labs.apnic.net/ipv6/XA
US on 50%, India on 70% and China just shy of 40% -As China continues to grow (and it will) the likely outcome is > 50% IPv6 Capable. I doubt any new Mobile deployment will be single stack, the most likely is pure IPv6 with CGN for 4. So Africa which is still in growth, the most likely outcome is dualstack preferring 6
It may not be ideal, there may be significant issues with EH for instance, but at scale its alive and kicking.
Now, if only we could get jumbogram more widely deployed. Thats older than V6 is and still struggling to break the 1500 byte MTU limit.
I've always seen "The Internet" as a network of networks.
I interpreted the article as inferring that "every device should only speak internet, and we shouldn't have non-internet hacks to allow devices to connect to the internet."
But, if we interpret the internet as a network built on top of other networks, it negates the thesis (as I interpret it) of the article. It also locks us into networking, as understood in the late 1990s, and designed into IPv6.
IMO: It seems like IPv6 suffers from second system syndrome. The authors lost sight of the purpose "network built on top of other networks" and tried to add lots of features for the "other networks" that really aren't needed.
Maybe it's time for IPv7? Really, all we need is IPv4 + larger address space. I'd even argue that NAT is a good thing (security feature,) because allowing devices on a private network to automatically open ports on the public internet is insecure.
I was asked by my employer in 2003 when IPv6 would replace IPv4? After substantial research, my answer was, "never"!!! I almost got fired for that answer but I am correct so far.
There are a large class of people out there who do not understand the end to end argument in system design and who never saw a piece of bloatware they didn't love. For them IPv6 will happen tomorrow. They are to internet like maga people are to democracy - caustic.
In 2004 IPv6 was hyped as solving the impending IPv4 address shortage. NAT had already been invented and there was no shortage as IPv4 addresses were allocated as inefficiently as possible and there was no market to buy and sell IP addresses nor was there any rental cost for owning ipv4 addresses. So it was solving a non problem.
My employer Qualcomm eventually proposed using IPv6 for cell phone handsets in an overlay network called openran. This was a convenience and not a necessity because there are more than 4 billion cell phones in the world.
You just don't need these bloated addresses in IPv6. You need banks of addresses mainly for the server. The client never needs 65,000 incoming or outgoing connections. The number of client computers in the world that are running as servers and that need open datagram accessibility from anywhere in the internet is virtually zero. Want it? yes! Need it - meaning impossible to do without it - No! There are always bridging workarounds to avoid giving client machines dedicated IP addresses!
IPv6 is not respectful of small system design and hardly provides usable improvements to IPv4. IPv6 was a marketing tool invented by Cisco to sell bigger more expensive routers, not to solve a problem with any economy ... It is especially detrimental to IOT.
Does google downrank sites that are IPv4-only yet? That would shift some behaviors
> configuring DHCP really is a huge pain
Not sure why the author is so sniffy about DHCP. To me it seems easy to understand and configure.
Having said that, I appreciate the author's remarks about DHCP being a 'fake' IP protocol, and in reality being an ethernet protocol; I hadn't seen it that way before, but it's a reasonable way to look at it.
A bit off topic but the most interesting part of this was clicking through to the link about TCP BBR. It's available for the Linux kernel but not bundled / enabled by default, but if these related posts are telling the truth, maybe it should be:
https://djangocas.dev/blog/huge-improve-network-performance-...
https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c...
One thing that isn't discussed very often but is IMHO one of the bigger roadblocks for IPv6 deployment is the Berkley Socket Interface. The API that loads of code is built upon to do internet communication.
The problem is that the API is too low level, or more specifically there is no high level API for it. Ideally it would have a function that looks like:
int sockfd = connect_to(hostname, port, SOCK_STREAM, options_bitfield);
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.
Anyone else mostly fine with IPv6 like it is?
Biggest complaint here is that I wish I had a way to correlate SLAAC addresses with hostnames somewhere other than the host. But I don't so when it matters I run a DDNS client on the host, which is probably the "more correct" answer anyway because the host always keeps DNS updated with its current address.
The myth that it would have been easier to switch to a protocol that is just ip4 with more bits needs to die.
The companies too cheap or lazy to adopt ipv6 would still be clinging to classic ipv4 with NAT.
Connection roaming seems more like a TCP problem than an IP one. Wouldn’t it be wise to extend the TCP side? Or, rather, should we expect IPv6 to solve it?
One thing I’ve realized lately is that scarcity is actually a benefit of ipv4, much in the way of the maximum amount of bitcoins theoretically increases their value.
Ipv4 addresses are being ranked by their reputation. This is a good thing, at least right now, as it makes scammers/spammers/hackers/ddosers lives more expensive to acquire fresh addresses. This can only exist when a shortage exists.
The core network stack is going to be dual stack any way during at least the transition phrase, OSes like linux should allow v4/v6 communication.
"Actually, RARP worked quite fine and did the same thing as bootp and DHCP while being much simpler, but we don't talk about that."
RARP is basically dhcp but only for your IP address. DHCP/bootp won because you sort of need a bit more than your ip. It was also easier to manage.
RARP probably still works mostly.
I have said for the last decade or so whenever IPV6 comes up on HN that IPV6 was way too big of an address space for anything but having some sort of unique identifier in there to support an online digital ID. Like some space for a hash of a biometric or something in the lower 64 bits.
The author is unaware of, or has ignored, Mobile IP [1]. There are implementation of it available.
Cloud providers don't even support ipv6 that well let alone expecting the general public to switch over.
isn't the "mostly good enough" aspect of ipv4 the biggest problem for ipv6?
The "I don't like it, it's different" mob are out in force today. This isn't the Daily Mail.
I've only dabbled in IPv6, but the one thing that blew my mind was that you cannot set DNS automatically without DHCPv6. Other methods of "automatic addressing" are thus useless.