back
505 comments
My first IPv6 implementation was in 2010-2011 (memory a but fuzzy). Carriers supporting BGP over IPv6 were few, websites over IPv6 were also scarce.

Fast forward 15 years snd the situation has improved quite dramatically.

IPv6 has some quirks that make it harder to digest.

- link local gateway address, makes it hard to understand why the subnet does not have a gateway from the ssme address space

- privacy extensions: it is very hard to explain to people why they have 3-4 IPv6 addresses assigned to their computer

- multicast instead of broadcast

- way too many ways for autoconfiguration (SLAAC, DHCPv6)

- no real tentative mapping to what people were used to. Every IPv6 presentation I did had to start with “forget everything you know about IPv4”

In the enterprise space, if you mention globally reachable address space, the discussion tends to end pretty fast because “its not secure”. Those people love their NAT.

> In the enterprise space, if you mention globally reachable address space, the discussion tends to end pretty fast because “its not secure”.

Topic drift, but for younger people who didn't live it, that's how it used to be!

For most of the 90s my workstation in the office (at several employers) was directly on the Internet. There were no firewalls, no filtering of any kind. I ran my email server on my desktop workstation to receive all emails, both from "internal" (but there was no "internal" really, since every host was on the Internet) people and anyone in the world. I ran my web server on that same workstation, accessible to the whole Internet.

That was the norm, the Internet was completely peer to peer. Good times.

The nice thing about NAT is it makes the security model easier to reason about.

By this, I don’t mean it’s more secure, because I know it isn’t. But it is a lot easier to see and to explain what has access to what. And the problem with enterprise is that 80% of the work is explaining to other people, usually non-technical or pseudo-technical decision makers, why your design is safe.

I really do think IPv6 missed a trick by not offering that.

The SLAAC/DHCPv6 combo seems really strange to me.

Either IP/DNS/gateway discovery with one or the other could be tolerable. But allowing combinations such as SLAAC for addressing and DHCP for DNS discovery is lunacy.

It’s as if one said, let’s take the most basic and critical step and make it as complicated as possible and explore the combinatorial explosion…

> IPv6 has some quirks that make it harder to digest.

Almost every point in your list is wrong.

> - link local gateway address, makes it hard to understand why the subnet does not have a gateway from the ssme address space

IPv4 has link-local addresses, too. Those are the 169.254.X.X addresses that you see on Windows machines. IPv6 adds nothing new.

> - privacy extensions: it is very hard to explain to people why they have 3-4 IPv6 addresses assigned to their computer

Well then, don’t use them. Configure the machines with one address each, just like before. If you want the (arguable) advantages of the privacy extensions, they are available, but not mandatory.

> - multicast instead of broadcast

IPv4 always had multicast, too. IPv6 is simplified by considering the broadcast concept to be a kind of multicast.

> - way too many ways for autoconfiguration (SLAAC, DHCPv6)

SLAAC is just link-local addresses, which you already mentioned above. Did you mean NDP with router advertisements?

If you did, you do have a small point, but DHCP6 is still there like always. IPv6 just offers an additional feature for the simple cases where a host just needs an IP address, netmask and a router address.

> - no real tentative mapping to what people were used to. Every IPv6 presentation I did had to start with “forget everything you know about IPv4”

That’s the complete opposite of my experience. Almost everything in IPv6 works exactly the same as with IPv4.

>In the enterprise space, if you mention globally reachable address space, the discussion tends to end pretty fast because “its not secure”. Those people love their NAT.

Was also designed in the early 90s before security was taken seriously.

In my experience, the IPv6 protocol is much simpler than the IPv4 protocol. However, the IPv6 tooling and documentation is still worse than it is with IPv4, and dual-stack is inherently going to be more complicated than implementing any single protocol, so I do have some sympathy towards "IPv6 is hard".

For example, the IPv6 packet structure [0] is much simpler than the IPv4 packet structure [1]; SLAAC [2] is much simpler than DHCPv4 [3]; IPv6 multicast [4] is much simpler than IGMP [5]; IPv6's lack of NAT simplifies peer-to-peer networking compared to IPv4; ULAs [6] prevent the annoying address conflicts you get with IPv4 [7]; etc.

[0]: https://en.wikipedia.org/wiki/IPv6_packet#Fixed_header

[1]: https://en.wikipedia.org/wiki/IPv4#Packet_structure

[2]: https://en.wikipedia.org/wiki/IPv6_address#Stateless_address...

[3]: https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Pro...

[4]: https://en.wikipedia.org/wiki/IPv6#Multicasting

[5]: https://en.wikipedia.org/wiki/Internet_Group_Management_Prot...

[6]: https://en.wikipedia.org/wiki/Unique_local_address

[7]: https://stackoverflow.com/a/52374482/30512871

ULA give more trouble than what it solves.

Almost all computer have multiple interface (virtual or not). Application now need to know which interface the destination is on, and there is no easy data structure to store the interface

> There was also unnecessary confusion caused by a rather political decision to make IPv6 require support for IP Security (IPsec), which was an immature technology at the time. This was a definite brake on IPv6 deployment until it was dropped after some years.

I don't know anything about the IPv6 situation, but the way this paragraph just slots in so innocently foreshadows some long wordy Wayland retrospective document on why adoption was so slow where someone from deep in the community slips in 1 short "sure we tried to block screenshots and that might have caused some issues with adoption for some users" paragraph in the middle-end. The innocence of the admission is so mild and context-free that it somehow manages to make itself look guilty.

I disagree that it would've been just as hard anyway. The people who say "I just wanted v4 with more bits" have a point that most of these arguments completely ignore, but this one touches on it:

  Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in [RFC3513] but deprecated by [RFC4291] because it turned out to be of no practical use for coexistence or transition.
The practical use would've been going all-in on those, making it as easy as possible for users to switch. But instead, the default way of using v6 was those new addresses, also SLAAC and no NAT, and 6to4 was bolted on in a way that never worked very well.

The thing is, their objective wasn't just to add more bits, it was to defrag the old v4 routes. If you did it the "just add more bits" way, once everyone is on v6 but with the old v4 /32s, the new address space for sale is underneath those. Maybe there'd be a way to defrag afterwards in a separate effort.

How would this have worked in practice, in a way that the NAT464/NAT64 schemes that most mobile operators use haven’t? Would IANA have dedicated some blocks of IPv4 to be used for IPv4-compatible IPv6 addresses on the public internet?
> But instead, the default way of using v6 was those new addresses, also SLAAC and no NAT...

Well, the good news is that we've had DHCPv6 and IPv6 NAT for at least like 25 years. It's true that these weren't standardized in 1995, but I always wonder how long things need to be fully supported [0] before people stop acting like they don't exist.

It took something like a decade for IPv4 to get DHCP, and I don't know how long for it to get NAT, and yet I don't hear people saying that IPv4 has no default mechanism for address autoconfiguration or network address translation.

[0] ...by everyone except Android, of course...

they have no point. some random aesthetic aspect of a standard is not why it does or does not get adopted. it's an evolutionary standard that offers no direct incentives for adoption.

the real obstacle was enterprise sales, that is, someone had to pay Microsoft, Google, Amazon, etc. as a major customer of theirs to implement correct IPv6, which takes time. the people at Microsoft working on ipv6 for customers, they're only going to implement the parts that customers need, they're not going to proactively discover all the bugs and fix everything. this is true about everything, i'm not saying anything that unorthodox, except...

the reason we're talking about ipv6 now is, in a post LLM world, it is now possible to take a well written and thoughtful spec like ipv6 and Just Do It. you don't have to wait for a customer relationship to do it.

I think this is the kind of the topic that can be endlessly debated because you can not easily go back in time and test out alternate hypothesis. I will say that I do not like ipv6 because it tried to fix multiple accumulated problems. I know! How contrarian! How can you be against trying to fix things. But all of those issues made ipv6 a dual stack solution that replaced ipv4.

Address exhaustion, Routing table scalability, restore end to end routability, autoconfiguration, header simplification, mulitcast + anycast, security standardization.

Whereas, I think a lot of those things could have been solved in other ways, or more slowly. I would have preferred a ipv4.2 64 style because it would have prioritized

Address exhaustion, keeping backward operational compatibility, fewer changes to institutional knowledge, and still had incremental rollout (that I think would have occurred much more quickly than ipv6).

> The main reason for IPv6, and its only real reason for existence, was bigger addresses.

Which also allowed for better route aggregation in the core BGP tables.

Better node mobility support. Better multicast support. Genuine link local addresses.

IPv4 had a lot of unfortunate edge cases. I think IPv6's greatest strength and also responsible for it's slow rollout was it's insistence on solving several of these problems at once, along with IPSec as the article notes, and hammering them into the hard requirements for the core stack.

This is the only topic that tempts me to create a throwaway account. (I have not given in) None of the IPv6 proponents are willing to acknowledge that IPv6 is a pain.

All of them seem to have gone to some secret seminar somewhere where they receive their talking points:

- Everyone who dislikes IPv6 doesn't know how NAT works and thinks it's the same as a firewall.

- There's absolutely no downside whatsoever to being publicly addressable. (also this is a good time to reiterate that NO ONE understands that NAT is not a firewall)

- 128 bit addresses are exactly as convenient and memorable as as 32-bit addresses.

- The entire internet would be hosting home servers if not for the evils of NAT.

I installed a new bare metal server from a european cloud provider this week.

Both my clean Debian and the rescue system couldn’t reach internet through IPv6 despite getting an address through DHCP.

I immediately permanently disabled IPV6. I usually do that pretty late in my installation scripts anyway.

I understand the perfect solution didn’t exist and still doesn’t exist, but it’s frustrating. I wish IPv6 could work reliably, not only on major CDNs, and that is appreciated. Then IPv4 would be a vanishing memory.

Personally, i feel it is complicated because ISPs are highly afraid of trying it. I understand that such novel technology would be risky to use. But after 20+ years there are still many countries, like Spain, which are barely using it. After that much time has passed, it is already well battle-tested. At this point, you don't want to make the move either because you are too afraid of anything or you have commercial reasons.

I believe Telefonica has reasons to not use IPv6... Although in the long run is turning to be a bad decision. Look at digi :p

Most of the bitching about IPv6 is from those who really, really want IP addresses to identify machines or users. IP addresses (including IPv4) were never intended to do that and it was never a good idea to put them in that position.

There was a time when most devices had 1 network interface and didn't move. But that was never a guarantee. People thought it was a guarantee when your $400-in-1988-dollars Madge ISA full-height full-width token-ring NICs with dangling AUI dongles next to your tank of an ST225 hard drive were a thing, but we're past that. Today most things that aren't servers have at least 2 - wired/Wi-Fi for laptops, Wi-Fi/cellular for phones. You can talk about NAT and security and mapping all you want, but if I can bypass your corporate internal network security simply by turning off my phone's Wi-Fi, yet still get to your resources - then NAT is a legacy chore that IPv6 makes unnecessary.

My problem with IPv6 is that I can't double click 2001:db8::1428:57ab to select the entire address. It's a silly complaint but representative of real ergonomic issues.
There is no working solution to ipv6 dual WAN failover, 30 years later... A critical design flaw that was simply ignored by the designers despite being used in almost any SME network.

inb4 no you can't have all lan devices have multiple ipv6 addresses and choose for themselves, typically 1 WAN is cheap and the second WAN is expensive/slow and should be used only for WAN1 failover

Inb4 no you can't just advertise new RA, devices on lan can takes minutes to update.

On ipv4, NAT+changing route on router just works, 1-2 seconds failover.

A lot of it seems to boil down to "IPv6 was too early". Had IPv6 been developed a couple years later DHCP would have been mature, and SLAAC would have never been invented (since DHCPv6 is fairly obvious when you have good experiences with DHCP). Also it would have given all the alternative protocols (especially OSI) time to try (and likely fail) to gain traction, freeing IPv6 from the obligation to cram in all of their features. IPv6 could have picked a much smaller set of features that were proven useful by other protocols, then swoop in as the much simpler upgrade from IPv4 than any of the competitors
India on around 80% in the apnic labs active measurement of end users.

https://stats.labs.apnic.net/ipv6/in

They report nearly a billion users, predominantly in mobile.

So, "only" 750 to 800 million users. Think about that: 3x the population of the USA using it most of the time, in one economy.

Here's the rankings:

https://stats.labs.apnic.net/ipv6/XA?o=cINw30x1r1

This is a different measure to Google's. They measure different things,

This is not very substantive, but rather procedural, like this example of an answer doesn't tell you much, but tells you the official paper IDs:

> Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in {{RFC3513}} but deprecated by {{RFC4291}} because it turned out to be of no practical use for coexistence or transition.

Why/how did it turn out?

I have a /56 at the datacenter and Google Fiber gives me something like a /64 or something so I have full IPv6 connectivity everywhere. For the most part this is fine, but I've noticed the Internet is 'less reliable' on IPv6 and so in my head I still feel like it's a little iffy. There are times where a AAAA record points to an IP that doesn't respond, but the A record responds and so on. I just think it's the same as my blog's Gemini protocol server. I don't use it and offer it for fun but it's a best-effort basis. If it went down for months I wouldn't notice.
Short answer: Too many cooks in the kitchen, and too many of 'em motivated to make it more complicated.

A computer standard that is still widely avoided almost 30 years after it became official is a computer standard that should have been tossed in the bin before the ink was dry.

Despite the article title, IPv6 is not the complication. The problem is that IPv4 is incumbent and IPv6 has to live along side of it. It doesn’t matter how it’s done, the dual stack nature of expanding the addressing system will always exist.
I almost wish NAT had never been invented. It's a kludge that effectively added 16 bits to the IPv4 address space and delayed IPv6 as a result.
I've always found the most complicated part of IPv6 to be address scopes and source address selection. The fact that one interface can have any number of addresses in different scopes and prefixes complicates things a lot.

Another thing that will always trip up new IPv6 network engineers is solicited-node multicast. You know the theory, computers talk to ff02::1 for neighbor discovery and then you hop onto a real network and see none of that actually happening.

And probably the most complicated thing for network engineers - how to set up firewall rules if machines are constantly changing their addresses.

For developers and security people - just parsing and validating v6 addresses is a whole bunch more work, but at least for this, the tools are available to help you now.

The problems of IPv6 deployment are ones of incentives, not design.

Increasingly, the vast majority of services are accessed via the service cone of various CDNs and IAAS providers directly at edge servers local to them, and at some point it may be that the industry decides that it's not worth providing ordinary internet users the ability to talk to each other directly at all. At which point, we might just as well have stuck with IPv4. I don't particularly like that outcome, but it's possible.

> Just adding bits to the address isn't as simple as it seems.

They said the same in Y2K, and turned out that people were able to extend their date fields and the systems ran just fine.

At a high level one of the sad things about IPv6 is that it surrenders a wierd, valuable and emergent property of IPv4 for the average home user in $random_country:

IPv4 addresses in logs are not super helpful in tracking a specific person and household’s behavior long term (NAT, reuse etc.)

Almost every end user oriented IPv6 deployment makes it significantly easier to use IPv6 addresses to persistently track individual machines (ie individual people) and map them to a household (yes I’m aware of RFCs 7217 and 8981, I’m mostly talking about long term stable prefixes).

How much of a real concern this is is debatable but it’s perhaps a little bit unfortunate.

Why are we, in 2026, still talking about ipv6? It is time to give it up and start over. Yes, it is unlikely we can agree on an ipv4 successor. But at this point we should be able to agree ipv6 is not going to be it.
Honestly... Its more machine vocab than human level vocab.

Ipv4 is jsut about able still to hold in your head, have a convo or more importantly you can: "Shout an ipv4 across the open office floor from your desk to your tech colleague"

If you shout an ipv6 address in public, you jsut seem broken

The headline is not confirmed in the text:

> First of all, IPv6 really is a conservative design - it doesn't change the basic IP model of connectionless packet switching with topological addresses.

They should have had the UTF-8 guys tackle IPv6. Talk about elegant.
IPv6 is awesome and I'm so happy that my local network is IPv6 and my provider offers IPv6 by default too.

I think it offers hope that we can serve up data in a much more peer-to-peer way without going via "bigcorp" servers.

To break the network as a security measure seems the absolute wrong fix to me and it's hard to understand the logic of it.

>Getting IPv6 to about 50% deployment has taken more than 25 years. Any alternative or new proposal would be the same.

That is oversimplified a few things. The 50% deployment is largely Mobile Phone + Cloudflare and India. ( Not sure about China ). Outside of that things aren't that different from a high level overview.

You could have 50% deployment in less than 10 years if 6G Mobile Phone mandate the use of let say IPv8.

What I don’t understand is why coexistence was so important. TFA notes a lot of protocols were in use back then.

Also what’s with all the problems? I’ve had RA packets leak across VLANs via firewall misconfigurations, some my fault and some not. I get that people designing internet protocols had a lot to think about, but why am I fighting stuff like this?

I recently had to set up basic IP-based country detection in Nginx for a project. Parsing and handling IPv4 is trivial. The second I had to account for IPv6 string formats and update the Geo databases to match, the complexity just spiked for no good reason. It feels like we traded address exhaustion for parsing nightmares.
personally I just hate this -> http://[0123::4567]:5000/whatever
I would be easier to accept if it was just an extension of IPv4. Make the addresses longer but keep the types A,B,C,D. Keep the network address x.x.x.x/y. That way everybody will be familiar with it and change will be done smoothly.
I think we've been shunted into an alternate universe by NAT - one which reinforces the power of large companies because we essentially cannot communicate computer to computer without going through some service.

As for security.........are we really that secure running code in our browsers that we downloaded from who knows where? Is nat really saving us?

And now here we are with IPv6 and the real age of the network could begin.

> Incidentally, "IPv8" proponents often ask why IPv6 didn't simply stick some extra bits on the front of IPv4 addresses, instead of inventing a whole new format. Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in {{RFC3513}} but deprecated by {{RFC4291}} because it turned out to be of no practical use for coexistence or transition.

Any tl;dr on why/how the simplest solution imaginable would have been "of no practical use for coexistence or transition"? Granted, I understand the other points make a strong enough case by themselves.

> Any address length greater than 32 would create all the coexistence and transition problems we have experienced since 1994

This is the author’s assumption and not a conclusion. Why did the other designers even bother if this was the case?

It’s not. It’s IPv4 with more bits and some changes to Ethernet level lookup.

The SLAAC vs DHCPv6 mess is not really a problem with the core V6 spec.

It's not. I learned how IPv6 worked SO LONG AGO that I really can't understand remaining confusion.
if it was easier to use and less of a PITA, it wouldn't be taking decades.