▲ 231 points
back
166 comments
Our world. It was a good design in our world.
I don't think v6 is the absolute pinnacle of protocol design, but whenever anybody says it's bad and tries to come up with a better alternative, they end up coming up with something equivalent to IPv6. If people consistently can't do better than v6, then I'd say v6 is probably pretty decent.
> they end up coming up with something equivalent to IPv6
Not just that. Almost every single thing people think up that's "better" is something that was considered and rejected by the IPv6 design process, almost always for well-considered reasons.
In retrospect I think just adding another 16 or 32 bits to V4 would have been fine, but I don’t disagree with you. V6 is fine and it works great.
All the complaints I hear are pretty much all ignorance except one: long addresses. That is a genuine inconvenience and the encoding is kind of crap. Fixing the human readable address encoding would help.
You know that's not what he meant. the world is always changing. it was designed in 1998 by networking gear companies, with their own company needs in mind. It wasn't engineered with end user, or even network administrators and app developers in mind.
The only reason it's around is because of sunken cost fallacy and people stuck in decades old tech-debt. A new protocol designed today will be different, much the same as how Rust is different than Ada. SD-WAN wasn't a thing in 1998, the cost of chips and the demand of mobile customers wasn't a thing. supply/demand economics have changed the very requirments behind the protocol.
Even concepts like source and destination addressing should be re-thought. The very concept of a network layer protocol that doesn't incorporate 0RTT encryption by default is ridiculous in 2026. Even protocols like ND, ARP, RA, DHCP and many more are insecure by default. Why is my device just trusting random claims that a neighbor has a specific address without authentication? Why is it connecting to a network (any! wired,wireless, why does it matter, this is a network layer concern) without authenticating the network's security and identity authority? I despise the corporatized term "zero trust" but this is what it means more or less.
People don't talk about security, trust, identity and more, because ipv6 was designed to save networking gear vendors money, and any new costly features better come with revenue streams like SD-WAN hosting by those same companies. There are lots and lots of new things a new layer-3 protocol could bring to the scene. But security aside, the main thing would be replacing numbered addressing with identity-based addressing.
It all comes down to how much money it costs the participants of the RFC committees. given how dependent the world is on this tech, I'm hoping governments intervene. It's sad that this is the tech we're passing to future generations. We'll be setting up colonies on mars, and troubleshooting addressing and security issues like it's 2005.
you're implying that they could not have done better.
I think they "shipped it" and washed their hands of it.
But I think there should have been more iterations, until we got a little more ipv4+ and less ipv6.
Previous discussions:
https://news.ycombinator.com/item?id=14986324 (2017)
https://news.ycombinator.com/item?id=20167686 (2019)
Thanks! Macroexpanded...
The world in which IPv6 was a good design (2017) - https://news.ycombinator.com/item?id=37116487 - Aug 2023 (306 comments)
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)
I don't like this post's negativity towards ARP. ARP is the reason we can have IP networking on a LAN without a router. The default gateway just becomes a special case of general IP networking on a LAN.
Otherwise, the networking history part of this post is amazing. I haven't gotten to the IPv6 part yet.
But it's not the only way to tackle the problem of resolving layer 2 addresses, and you can do so without introducing the layering violations and expansive broadcast traffic that ARP implies (along with the consequent problems with WiFi and such).
For instance, IPv6's NDP is built on actual IPv6 packets (ICMPv6), rather than some spoofed IP-lookalike thing. No layering violation, and, thanks to multicasting, no need to dump a bunch of broadcast traffic on the layer 2 network.
What is this article even on about? The stuff on my network assigns itself ipv6 addresses based on their mac address? That's how you can do stateless ipv6?
Regardless, ipv6 was to have more IP addresses because of ipv4 exhaustion and NAT?
My Xbox tells me my network sucks because it doesn't have ipv6, but this is a very North-American perspective regardless.
> The stuff on my network assigns itself ipv6 addresses based on their mac address? That's how you can do stateless ipv6?
Nit: per RFC8064[0], most modern, non-server devices do/should configure their addresses with "semantically opaque interface identifiers"[1] rather than using their MAC address/EUI64. That stable address gets used for inbound traffic, and then outbound traffic can use temporary/privacy addresses that are randomized and change over time.
Statelessness is accomplished simply by virtue of devices self-assigning addresses using SLAAC, rather than some centralized configuration thing like DHCPv6.
[0] https://datatracker.ietf.org/doc/rfc8064/ [1] https://datatracker.ietf.org/doc/rfc7217/
> My Xbox tells me my network sucks because it doesn't have ipv6
Pretty sure that it's complaining about lack of upnp. Which, yes, would not be an issue if we had ipv6... but ironically consoles typically have been slow to adopt ipv6 support themselves, so I'm curious if the xbox even supports it..
Does Xbox work if there’s no IPv4? Because my corporate windows device doesn’t and I know other gaming consoles don’t.
Thanks for sharing this very interesting read.
There's one point I don't really get and I would be glad if someone could clarify it for me. When the author says that even over wifi, the CSMDA/CD protocol is not used anymore. Then how does it actually work?
Discussing this, the author explains:
> If you have two wifi stations connected to the same access point, they don't talk to each other directly, even when they can hear each other just fine.
So, each station still has to decide at some point if what its hearing is for them or not, as it could be another station talking to the AP, or the AP talking to another station. How is that done if not using CSMA/CD (or something very similar at least)?
> How is that done if not using CSMA/CD (or something very similar at least)?
AFAIK, WiFi has always been doing CSMA/CA and starting with the 802.11ax standard also OFDMA. See https://en.wikipedia.org/wiki/Hidden_node_problem#Background
I have come to think that having both SLAAC and DHCPv6 were a big flaw in IPv6. SLAAC is awesome but having two config mechanisms is confusing. It doesn't help that Android refuses to support DHCPv6.
I think SLAAC came from world where computers were expensive, DHCP servers were separate, and they wanted to eliminate them. But we are in world where computers are cheap and every router can run DHCP.
We could have had easy config with DHCPv6 giving out MAC based addresses by default. The auto config would still work on link-local.
there's Prefix Delegation support since Android 11 (so there's some DHCPv6 support, but of course in a fucking worse way with the mandatory "we know better" attitude)
https://blog.ipspace.net/2025/09/android-dhcpv6-prefix-deleg...
This is one of my favourite blog posts ever. For those unaware (or who didn't read right to the bottom), the author is the CEO of Tailscale.
One of the problems we have is when we're born we don't question anything. It just is the way it is. This, of course, lets us do things in the world much more quickly than if we had to learn everything from basic principles, but it's a disadvantage too. It means we get stuck in these local optima and can't get out. Each successive generation only finally learns enough to change anything fundamental once they're already too old and set in their ways doing the standard thing.
How I wish we could have a new generation of network engineers who just say "fuck this shit" and build their own internet.
> One of the problems we have is when we're born we don't question anything
I don't know about you personally but every grade-school, high-school, & college level instructor I ever had would probably vehemently disagree with this statement about me. I remember at least 70 year old college instructor becoming visibly irritated that I would ask what research supported the assertions he made
> How I wish we could have a new generation of network engineers who just say "fuck this shit" and build their own internet.
And doing so would improve nothing, and be no different than the IPV6 rollout. So you have to ship new code to every 'network element' to support an "IPv4+" protocol. 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:
> the author is the CEO of Tailscale.
That explains it. Like I wrote two years ago¹:
The eternal problem with companies like Tailscale (and Cloudflare, Google, etc. etc.) is that, by solving a problem with the modern internet which the internet should have been designed to solve by itself, like simple end-to-end secure connectivity, Tailscale becomes incentivized to keep the problem. What the internet would need is something like IPv6 with automatic encryption via IPSEC, with IKE provided by DNSSEC. But Tailscale has every incentive to prevent such things to be widely and compatibly implemented, because it would destroy their business. Their whole business depends on the problem persisting.
I was reading the Tailscale docs one day and I stumbled across this support page, which has similar vibes: https://tailscale.com/docs/reference/faq/ipv6
It was somewhat unexpected to find section headings such as "Is IPv6 a failure?" in the product support documentation, but I thought it was interesting and informative nonetheless.
> How I wish we could have a new generation of network engineers who just say "fuck this shit" and build their own internet.
There are plenty of anarchists and disaster aid groups interested in building a more decentralized alternative to the internet. Meshtastic, AnoNet, Reticulum, MeshCore, etc are all evidence of that
Then there's also stuff like Dave Ackley's robust-first computing that's looking towards a completely different paradigm for computing in general that focuses on robustness.
Very interesting post. I never considered the fact that IPv6 was going to be more than just a bigger IPv4.
Also funny it was made in 1990 and it only recently reached 50% adoption.
Don't let the year deceive you; IPv6, while designed in the 90s, was considered launched since only 2012.
And that 50% adoption is only as high as it is because China went from almost zero in 2017 to over 80% in 2025 after they included IPv6 adoption in one of their 5-year plans
I remember when ipv6 seemed like an inevitable next step. The fact that it fizzled seems like the problem it was trying to solve just doesn't matter? We somehow found enough ipv4 addresses to make the whole thing keep working just fine (from practical end user perspective) which seems like we never truly needed ipv6? Is that the wrong conclusion?
It matters, that's the why the workarounds like NAT exist. People have been trained to accept less. High-latency calls are the norm now. Network infrastructure like Cloudflare going down and preventing people from communicating is accepted despite being the very thing the internet was designed to prevent.
Saying it doesn't matter is like saying traffic congestion doesn't matter because you got to work today. Think bigger. Think longer term. It's depressing that people 30 years ago were thinking on a longer timescale than people today.
I don't really know which "we" you refer to that did find enough v4 ips. Once you could get a /24 by just applying for it, now you have to purchase second-hand ranges from some previous spammer network taken down so the ip reputation of those is total crap, and if you don't intend to run a "whole" network, you more or less have to lease one v4 ip from an American company in order to host something yourself.
That is like saying "uranium is globally available to purchase" except you can't find it in stores anywhere and you go to jail if you seriously start asking around for where to buy it.
> Now imagine that X changes addresses to Q. It still sends out packets tagged with (uuid,80), to IP address Y, but now those packets come from address Q. On machine Y, it receives the packet and matches it to the socket associated with (uuid), notes that the packets for that socket are now coming from address Q, and updates its cache. Its return packets can now be sent, tagged as (uuid), back to Q instead of X. Everything works! (Modulo some care to prevent connection hijacking by impostors.2)
And how the fuck anything in-between knows where to route it ? The article glows a blazing beacon of ignorance about everything in-between.
The whole entire problem with mobile IP is "how we get intermediate devices to know where to go?" we're back to
> The problem with ethernet addresses is they're assigned sequentially at the factory, so they can't be hierarchical.
Which author hinted at then forgot. We can't have globally routable, unique, random-esque ID precisely because it has to be hierarchical. Keeping connection flow ID at L4 instead of L3+L4 changes very little, yeah, you can technically roam the client except how the fuck server would know where to send the packet back when L3 address changes ? It would have to get client packet with updated L3 address and until then all packets would go to void.
But hey, at least it's some progress ? NOPE, nothing at protocol layer can be trusted before authentication, it would make DoS attacks far easier (just flood the host in a bunch of random uuids), and you would still end up doing it QUIC way of just re-implementing all of that stuff after encryption of the insides
Isn’t the whole point that when the client roams it opens a brand new L3 connection to the server, then sends over L4 packets to reconnect the L4 session over the new L3 link. Thus keeping L4 session state separate from L3 routing mechanics.
As for L3 packets going into the void. Yeah they’re gonna get lost, can’t be helped. But the server also isn’t going to get any L4 acks for those packets. So when a new L3 connection is created, and the L4 session recovered, the lost packet just get replayed over the new L3 connection.
> And how the fuck anything in-between knows where to route it ? The article glows a blazing beacon of ignorance about everything in-between.
Because the IP address changed, so classic routing still works. Their point is about identifying a session with something non-constant (the IP of the client), rather than a session token.
Instead of identifying the "TCP" socket with (src ip, src port, dst ip, dst port), they use (src uuid, dst uuid) which allows flows to keep working when you change IP addresses. Just like you can change networks and still have your browser still logged in to most websites.
The packets carrying those UUIDs still are regular old IP packets, UDP in the case of QUIC. Only the server needs to track anything, and only has to change the dst ip of outgoing packets.
As for flooding and DDoS, that’s what handshakes are for, and QUIC already does it (disclaimer: never dug deep in how QUIC works so I can’t explain the mechanism here).
> We can't have globally routable, unique, random-esque ID precisely because it has to be hierarchical
This is not, technically, true. We could have globally-routable, unique, random-esque IDs if every routing device in the network had the capacity to store and switch on a full table of those IDs.
I'm not saying this is feasible, mind you, just that it's not impossible.
(2017)
Are there any parts in the design of v6 that provide opportunities for companies to further enshittify our experience of the internet?
Everyone forgets that the Internet Architecture Board took a religious view on "Internet transparency and the end-to-end principle" which was counter to the realities of limited tooling and actual site maintainers needs. [0]
There were many of us who, even when it was still IPng (IP Next Generation) in the mid 1990's, tried to get it working and spent significant amount of effort to do so, only to be hit with unrealistic ideological ideals that blocked our ability to deploy it, especially with the limitations of the security tools back in the day.
Remember when IPng started, even large regional ISPs like xmission had finger servers, many people used telnet and actually slackware enabled telnet with no root password by default!!! I used both to get wall a coworker who was late to work because he was playing tw2000.
Back then we had really bad application firewalls like Altavista and PIX was just being invented, and the large surveillance capitalism market simply didn't exist then.
The IAB hampered deployment by choosing hills to die on without providing real alternatives, and didn't relent until IPv4 exhaustion became a problem, and they had lost their battle because everyone was forced into CGNAT etc...because of the IETF, not in spite of it.
The IAB and IETF was living in a MIT ITS mindset when the real world was making that model hazardous and impossible. End to end transparency may be 'pretty' to some people, but it wasn't what customers needed. When they wrote the RFCs to make other services simply fail and time out if you enabled IPv6 locally, but didn't have ISP support they burned a lot of good will and everyone just started ripping out the IPv6 stack and running IPv4 only.
IMHO, Like almost all tech failures, it didn't flail based on technical merits, it flailed based on ignorance of the users needs and a refusal to consider them, insisting that adopters just had to drink their particular flavor of Kool-aid or stick to IPv4, and until forced most people chose the latter.
In fact, 30 years later, I just had to add a IPv6 block on Ubuntu’s apt mirrors this week, because the aaaa record query has higher priority and was timing out on my CI, killing build times.
That behavior is due to the same politics mentioned above.
A few more pragmatic decisions, or at least empathetic guidance would have dramatically changed the acceptance of ipv6.
you repeat several times that IAB was too ivory tower and refused to address the critical issues of the day, but don't really go into much detail. I wrote an early implementation of v6, before ratification (and even won the UNH interop prize!). and I struggle to understand exactly what blame you are placing at their feet. just that maybe they took the e2e principle too seriously and should have backed the awful bodge that was NAT?
[flagged]
The article is from 2017?
I just read something about IPv8! Can anyone confirm this is real?
Real in what sense?
Lots of people have come up with alternate L3 protocols for the Internet. For example, check out [1] which goes up to 999.999.999.999.999, or [2] which gets updated with some typo fixes every 6 months each time it's about to expire.
Someone did post another one of these recently, but it's just a random person on the Internet. The IETF's draft database is more or less a pastebin service -- anyone can upload something there without it being a thing that's being taken seriously.
Sometimes you get drafts like [3] as a demonstration of that.
[1] https://datatracker.ietf.org/doc/html/draft-eromenko-ipff-05
[2] https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv...
Why repeating the old news?
> Internet routing can't handle mobility - at all.
so all the fairy tales about IP invented for nuclear war was a lie? the moment military started moving around, IP became useless?