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.
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.
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.
With NAT removed, you've still got the firewall rules, and that's fairly easy to reason about for me: Block anything from outside to inside, except X. Allow A talking to B. Allow B to receive Y from outside.
But we aren’t talking about someone technical glancing at their home routers firewall. We are talking about explaining a network topology to enterprise teams like change management, CISO, etc in large infrastructure environments.
That’s a whole different problem and half the time the people signing off that change either aren’t familiar with the infrastructure (which means explaining the entire context from the ground up) and often aren’t even engineers so need those changes explained in a simplified yet still retaining the technical detail.
These types of organisations mandate CIS / NIST / etc compliance even where it makes zero sense and getting action items in such reports marked as “not required” often takes a meeting in itself with deep architectural discussing with semi-technical people.
Are these types of organisations overly bureaucratic? Absolutely. But that’s typical for any enterprise organisation where processes have been placed to protect individuals and the business from undue risk.
In short, what works for home set ups or even a start up isn’t necessarily what’s going to work for enterprise.
Are we not? Because I suppose most people here are only disgruntled by a new protocol that changes how their home router works, and having to spend some learning effort.
For network admins in commercial settings, this is even less of an excuse. IPv6, the protocol, is fairly well documented and understandable if you put in the work to do so. And I am confident in saying it is absolutely able to deliver on any kind of corporate network scenario, even moreso than IPv4.
I did make the context pretty clear when I said:
> the problem with enterprise is…
Also, you completely missed my point when you said:
> if you put in the work to do so. And I am confident in saying it is absolutely able to deliver on any kind of corporate network scenario, even moreso than IPv4.
My point wasn’t that IPv6 cannot deliver enterprise solutions. It’s that some of the design around it makes the process of deploying enterprise solutions more painful than it needed to be.
IPv6 supports NAT [0], and nearly all routers make it easy to enable. The primary differences compared to IPv4 is that no-NAT is the default, and that it's more heavily discouraged, but it still works just as well as it does with IPv4.
[0]: In the same way that IPv4 "supports" NAT, meaning that the protocol doesn't officially support it, but it's still possible to implement.
IPv6 the protocol supported NAT just as well back then as it does now, but the software probably didn't. Which goes back to my point [0] [1] that IPv6 is a great protocol with bad tooling and documentation.
> Part of the adoption curve seems to be that it took years to abandon some of the bad ideas around IPv6 and readopt some of the better ones from IPv4.
The only abandoned IPv6 concept that I'm personally aware of is A6 records [2], but I'm pretty young, so I'm sure that there are others that I'm just not aware of. My impression from reading the RFCs and Wikipedia is that IPv6 hasn't changed very much, but that doesn't really mean anything, since I wouldn't expect for current sources to talk about concepts abandoned 20+ years ago.
[0]: https://news.ycombinator.com/item?id=47814070
https://en.wikipedia.org/wiki/IPv6-to-IPv6_Network_Prefix_Tr...
A small company might have a /48. You don't have to be concerned about address space when you just go, ok, first bit is for security zones. Or first 2 bits. Or first 3 bits. Do you need more than 8 security zones?
(Also, ULAs¹ exist, and most people should use them, independent of a possible consideration to not roll out GUAs² in parallel as one would normally do.)
¹ Unique Local Address, fc..: and fd..:
² Global Unicast Address
Was also designed in the early 90s before security was taken seriously.
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.
> 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?
It is extremely hard (for Brian, but even more so for anyone else, I certainly can't) to give a good answer to that, since you're talking about the absence of utility. People had applications in mind but dismissed them because they either found better ways or it wasn't practical. But that very frequently doesn't result in a "paper trail".
(It's a bit like LLMs having problems with negatives/absences.)
After this I go out of my way to disable, remove and nuke ipv6, out of every setup and deployment I do. Ipv6 is already quite complicated, but supporting TWO competing network stacks, with complicated pseudo compatibility, just multiplies unnecessary complexity!
(IPv6 sockets by default accept IPv4 connections, unless you disable that either system-wide or on the specific socket.)
By the way, I do agree the colon was a really poor choice for separating the blocks, when it is also used to separate the port number.
If customer wants proper ipv6 support, we can sign a contract and talk about it. But do not expect me to support some technology for free, just because it is enabled by default.
(Worst case, you moved the problem to your finance department, for buying IPv4 address space. But even if you didn't do that, at some point sooner or later you'll get pressure to support IPv6. And then you'll have to "un-fix" everything you did, and fix the actual problem. Maybe it'll be after you're retire, but I wouldn't take bets on that.)
[ed.: best case, you moved the problem to someone else outside your company or scope. Good for you, I guess. Like the sibling post says, address space shortage is an issue for everyone, and personally speaking I would consider it rude to make it other people's problem.]
I've been told that for 20+ years. Nothing has changed.
> you didn't fix anything, you just moved the problem around.
I do not get this attitude "ipv6 is inevitable". So far no customer even asked about it. We have way more urgent problems like cloudflare blocking, ddos from clankers, state regulations...
If the problem actually becomes real in like 20 years. The clankers will probably solve it in like 10 seconds. There is zero benefit right now to deal with headaches of dual routing and addressing.
Yes I did, and I no longer support that either. For my setups it is local private ipv4 networks all the way now! How tailscale or other VPN deals with that is not my problem!
If two nodes are on different networks, they should not be allowed to talk to each other anyway. Seems like security risk! Clean design, simple rules!
We are so lucky people like you aren't in charge, or we wouldn't have the internet in the first place.
I’ll also sign the “numbers bigger than 2^32” contract and a “weird looking characters in text” contract.
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,
[1] https://www.dot.gov.in/ipv6-transition-across-stakeholders Edit: hey look the govt drupal page is broken again, shocker. here is another source: https://icrier.org/pdf/IPv6_Transition.pdf
[2] The pricing pressure was _real_. 4G was the first time networks moved away from circuit switched to IP-based. So the marginal cost equation became better. And no legacy infra to support. By 2020, they also had funding from google and meta.
[3] https://broadbandindiaforum.in/wp-content/uploads/2022/08/Re...
Obviously economies that rely largely on second hand technology are going to have old technology. Much of Africa is in this bucket. But looking past the extremes, India is at nearly 80% right alongside Germany. They fall in very different average income brackets. So the correlation isn't tight.
I can't see any value in pointing out vague correlation between income and proliferation of a new technology. It's the most obvious of observations.
The problem here is that India alone would be consuming 20% of the IPv4 address space.
afaics, it probably has more to do with large indian-isp’s f.e. jio adopting ipv6.
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.
Edit: or maybe they added 12 more extra configuration protocols to manage, in the name of "ease of use".
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.
Actual solution could be extending TCP and UDP or make a new transport layer procotol that handles changing addresses, similar to what QUIC do. But we cannot do it exactly because things like NATs existing, thus QUIC build was build on ossificated UDP. Imagine if instead of IP+port a connection use unique per-connection hash to persist IP addreses changing. No more trying fighting to keep the IP the same.
It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to replace NNTP. GPRS/HSDPA/3G/4G/5G They all rolled out just fine and were pretty backwards and forwards compatible with each other.
The whole SLAAC/DHCPv6/RA thing is a total clusterfuck. I’m sure there’s many reasons that’s the case but my god. What does your ISP support? Good luck.
We need IPv6 we really do. But it seems to this day the designers of it took everything good/easy/simple and workable about v4 and threw it out. And then are wondering why v6 uptake is so slow.
If they’d designed something that was easy to understand, not too hard to implement quickly and easily, and solved a tangible problem it’d have taken off like a rocket ship. Instead they expected humans to parse hex, which no one does, and massive long numbers that aren’t easily memorable. Sure they threw that one clever :: hack in there but it hardly opened it up to easy accessibility.
Of course hindsight is easy to moan but the “It’s great what’s the problem?” tone of this article annoys me.
All that's required to implement each of those is two computers: 1 client and 1 server. Whereas supporting IPv6 requires every router between the two computers to also support IPv6. Similarly, if your current software doesn't support SSL/SSH/Gzip/etc., it's pretty easy to switch to different software, whereas it's hard or impossible for most people to switch ISPs.
> GPRS/HSDPA/3G/4G/5G
Radio spectrum costs providers millions of dollars, and each new cellular protocol increased spectrum efficiency, so upgrading means that providers can support more users with less spectrum. The problem is that most of the "Western" countries still have lots of IPv4 addresses, so there isn't much cost benefit to switching to IPv6. However, China and India both have lots of users and fewer IPv4 addresses, so there is a cost benefit to switching to IPv6 there, and unsurprisingly both of these countries have really high IPv6 adoption rates.
Of all aspects of IPv6 you took the only one that doesn't complicate implementations and can easily be swapped if you wanted.
$ ping -c 1 1.65793
PING 1.65793 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=54 time=1.56 ms
--- 1.65793 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.560/1.560/1.560/0.000 ms
SLAAC is easily the thing I love most about IPv6. It just works. Routers publish advertisements, clients configure themselves. No DHCP server, no address collisions, no worry. What's bugging you about it?
Don't get me wrong, SLAAC also works fine, but is it solving anything important enough to justify sacrificing 64 entire address bits for?
* deriving additional addresses for specific functions is great (e.g. XLAT464/CLAT)
* you don't get collisions when you lose your DHCP lease database
* as Brian says, DHCP wasn't quite there yet when IPv6 was designed
* ability to proactively change things by sending different RAs (e.g. router or prefix failover, though these don't work as well as one would hope)
* ability to encode mnemonic information into those 64 bits (when configuring addresses statically)
* optimization for the routing layers in assuming prefixes mostly won't be longer than /64
… and probably 20 others that don't come to mind immediately. I didn't even spend seconds thinking about the ones I listed here.
With SLAAC, it's just another implementation detail of the protocol that you usually don't have to even think about, because it just works. That is a clear benefit to me.
My ISP is Spectrum. They get a 0/10 on IPv6 support on this test page [1].
My only gripe with IPv6 addresses is they look too similar to MAC addresses. But as a representation, I think they’re absolutely fine.
It's a nice band-aid technology, no less and no more.
You're comparing incremental rollout with migratory rollout for most of these; (not the mobile phone standards.) That's apples and oranges.
You can argue for other proposals. But at the end of the day the best you could've done is steal bits from TCP and UDP port numbers, which is... NAT. Other than that if you want to make a serious claim you need to do the work (or find and understand other people's work. It's not that people haven't tried before. They just failed.)
And, ultimately, this is quite close to typical political problems. Unpopular choices have to be made, for the benefit of all, but people don't like them especially in the short term so they don't get voted for.
> If they’d designed something that was easy to understand, […]
I can't argue on this since it's been far too long since I had to begin understanding IPv4 or IPv6… bane of experience, I guess.
> […] not too hard to implement quickly and easily, […]
As someone actually writing code for routers, IPv6 is easier in quite a few regards, especially link-local addresses make life so much easier. (Yet they're also a frequent point of hate. I absolutely cannot agree with that based on personal experience, like, it's not even within my window of possible opinions.)
> […] expected humans to parse hex […]
You're assuming hex is worse than decimal with binary ranges. Why? Of course it's clear to you that the numbers go to 256 because you're a tech person. But if you know that, you very likely also know hex. (And I'll claim the disjunct sets between these are the same size magnitude.)
Anyway I think I've bulletpointed enough, there's arguments to be made, and they have been made 25 years ago, and 20 years ago, and 15 years ago, and 10 years ago and 5 years ago.
Please, just stop. The herd is moving. If anything had enough sway, it would've had enough sway 15 years ago. Learn some IPv6. There's cool things in there. For example, did you know you can "ping ff02::1%eth0"?
It wasn't even on the map until 1994. Prior to that it was an ad-hoc mess of "encryption" standards. It wasn't even important enough to become ubiquitous until Firesheep existed.
Even then SSL just incorporated a bunch of things that already existed into an extensible agreement protocol, which, in the long run, due to middleware machines, became inextensible and the protocol somewhat inelegant for it's task. 30 years later and it's due for a replacement but we're stuck with it. Perhaps slow adoption isn't a metric that portends doom.
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...
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
How? They're essentially the same as IPv4 addresses; the only difference is that there are way more of them, so address conflicts are much less likely.
> Almost all computer have multiple interface (virtual or not)
Sure, but that's the case with IPv4 too: my cell phone has one IPv4 address over WiFi and another over cellular, and my laptop has one IPv4 address over WiFi and another over Ethernet.
Edit: Ah, I think that eqvinox's comment [0] is what you were getting at here. And yeah, I agree that LLAs are kinda confusing and annoying. The difference is that LLAs aren't routable [1] and don't have an IPv4 analog, while ULAs are routable and are mostly equivalent to IPv4 addresses [2].
[0]: https://news.ycombinator.com/item?id=47814154
(ULAs don't need the interface specified.)
ULA: fc..:… and fd..:…
LLA: fe80:…
[ed.: By the way, sin6_scope_id is where the interface identifier is stored in struct sockaddr_in6. So, basically every single IPv6 address object you're handling has the field for it.]
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.
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
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.
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?
Military, corporate, tech... it isn't. (If your people like flag day migrations. It's… "a choice".) But if you have to explain to an end user why some things work and some don't, you're just f'd.
And note "coexistence" here means that an end host can implement IPv4 and IPv6 at the same time, without them interacting at all. Imagine if you had to choose between IPv4 and IPv6 on your devices, maybe something like "you need a 2nd network card". Can you imagine anyone switching to the less popular protocol?
You raise a good point that we also should't take dual- stack for granted. But I think the more precise question 'why not dual-stack as the only coexistence option' also seems like a good one, and one the article does not explore or even acknowledge
NAT64 started happening because it solves real problems — large eyeball networks, particularly mobile phone networks, didn't want to pay for twice as large table sizes on their routers and twice the maintenance effort. So they made IPv6 end hosts capable of connecting to IPv4 systems. But this is 2010 era, IPv6 was ≈15 years old at that point!
* It was designed by people who didn't have the full picture and were missing representatives from hardware vendors, small businesses, home network admins and a bunch of other people that will be affected by design.
* It was designed by people who didn't consider the cost of migration and the amount of work that would require (see previous point).
* It was designed by people who lived in an ivory tower of "noone will run dual stack for a long time", "everyone will love to run two completely separate network designs".
* It was designed on a premise that end-to-end, fully accessbile devices are something we actually want and won't cause privacy issues.
I think it should be a study material on how standards and designs by commitee can go wrong if they're not headed by people with extensive experience across the industry with enough authority to push for good solutions.
IPv6 tried to do too much (just like many software "let's refactor this legact code") and was done by people who didn't consider all perspectives and costs (again, like many less experienced architects trying to rewrite legacy software).
I don't understand this sentiment—as if learning IPv4 was enough work on your part, and now you're entitled to networking protocols never changing anymore.
What I learned about IPv4 at the turn of the century allows me to comfortably plan and manage networks up to a few thousand nodes, maybe a few tens of thousands.
I don't work in networking anymore. I really don't care about what those who are in that business. What you need to manage contemporary billion-node size networks and interchange between them is not my problem. You try to make it my problem, but I don't care.
I'll continue organizing the very few and very small networks that are still my responsibility using pre-CIDR ideas.
Maybe it becomes impossible some day. I'll deal with it then.
Could with approximately zero services requiring IPv6, the collapsing cost of IPv4 addressing, and it makes IPv6 very much a hidden protocol for phones. When I tether off my phone I get an IPv4 address, the phone may well do a 4:6 translate and then something else does a 6:4 translate. That doesn’t matter, I can still open a socket to 1.1.1.1 from my application.
Had IPv4 been transparently supported IPv6 wouldn’t have taken 30 years and a whole new ecosystem (phones) to get partway there.
It only gets complex if you try to micro-manage it.
Oh no, last time I asked on HN I got 24 to 48 easy steps involving a lot more acronyms than this (please don't repeat them).
IPv6 is easy to use only if you let your one router manage everything and you give up control of your home network.
Edit: again, please don't help. There have been HNers trying to help before, but my home network is non trivial and all the "easy" autoconfiguration actually gets in the way.
> give up control of your home network.
What does that even mean? What do you gain by deciding your Apple TV should be at 192.168.0.3? With IPv6, you can just `ping appletv` and it works fine. What more "control" do you need?
With IPv6 I actually want it more and it becomes possible since we can just use the MAC address as an IP address.
I have IPv6 service at my ISP right now but I'm hesitant to turn it on on my local network because it does make my firewalling concerns much more critical.
Same here, which is why I use DHCPv6. It's pretty easy to set up, nearly everything supports it, and it's super reliable.
The only catch is that Android refuses to support DHCPv6 for some reason, which is kinda annoying since it means that you need to keep SLAAC enabled if you have any Android devices on your network. Which means that your DHCPv6-supporting devices will end up with two addresses, but there aren't any real downsides to that.
With IPv4 you need to remember ... one number per machine. The one at the end, since it's usually a /24 and everything has the same prefix.
I'm sure it's trivial to remember mac addresses from different vendors with no connection to each other too :)
> Isn't it really stable hostnames that you want?
Hostnames are another layer. Your apple tv example may advertise itself on its own. My toys don't all do that.
My home network isn't the Internet and isn't large: DNS is a much more complicated system to keep running then just fixed IP addresses in that circumstance.
Above a certain scale, that flips but not at the home level.
What do you mean by robustness? Isn't it really stable hostnames that you want? I don't understand how fixed IPs increase resilience (to what?).
> I'm hesitant to turn it on on my local network because it does make my firewalling concerns much more critical.
Block everything coming in from outside the network. Allow established connections. That's all there is to it.
Still want to help? :)
And really... everyone is pushing for SSL everywhere - among other things so that the ISP doesn't MITM your traffic.
Why would you allow the ISP to know what machines are inside your home network then?
What would your ISP do with the information that there are 73 unique addresses in your network at this point in time? Especially given that devices may mint any number of them for different reasons, so you can’t even really assume that corresponds to the number of physical devices in your network?
So I should cancel one of my pipes because the "commitee" overcomplicated things in the name of autoconfiguration?
> What would your ISP do with the information that there are 73 unique addresses in your network at this point in time?
Sell it of course. Good info for targeting marketing/political propaganda per household.
> I haven’t seen a bog-standard router yet that didn’t just do it out of the box.
Which one, the one from ISP A or the one from ISP B? :)
That is absolutely not what I said. It’s a more complex setup than a single connection with either protocol, and can be solved with both.
> Which one, the one from ISP A or the one from ISP B? :)
Realistically it is going to return an A record with both addresses, maybe also the link-local one, any works locally. That is a non-issue.
NAT is a firewall with extra steps. IPv6 reduces complexity. Privacy (illusion of it, anyway, just like in ipv4 NAT) is handled by private addresses.
…and if you really want to, NAT for ipv6 just works.
Any sane router also uses a firewall for IPv6. A correctly configured router will deny inbound traffic for both v4 and v6. You are not less secure on IPv6.
And concerning the NAT: That's just another word for firewall, which you still have in your router, which still needs to forward packages, and still can decide to block some of them.