I don't use IPv6 because it solves a problem that I don't have and it provides functionality that I don't want. And also because I don't understand it very well.
My points :
- I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.
- Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.
- Stateless auto configuration. What ? No, no, I want my ducks neatly in a row, not wandering about. Again maybe my brain is rotten from years of DHCP usage but yes, I want stateful configuration and I want all devices on my network to automatically use my internal DNS server thank you very much.
- It's hard to remember IPv6 addresses. The prospect of reconfiguring all my router and firewall rules looks rather painful.
- My ISP gives me a /64, what am I supposed to do with that anyways?
- What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.
> - I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.
What happens when multiple devices in your /8 want to listen on port 80 and 443 on the public address? Only one of them can. Now you're running a proxy.
> - Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.
It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall. NAT is usually configured as part of your firewall, but is not a firewall.
> - Stateless auto configuration. What ? No, no, I want my ducks neatly in a row, not wandering about. Again maybe my brain is rotten from years of DHCP usage but yes, I want stateful configuration and I want all devices on my network to automatically use my internal DNS server thank you very much.
DHCPv6
> - My ISP gives me a /64, what am I supposed to do with that anyways?
What are you supposed to do with a /8? Do you have several million computers?
> - What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.
What happens if your ISP changes your IPv4 address?
Wow. It's like your reply is doing an impression of IPv6! (I'm just teasing. I hope you are having a happy new year.)
Not GP, but:
> What happens when multiple devices in your /8 want to listen on port 80 and 443 on the public address? Only one of them can. Now you're running a proxy.
I don't want any of my devices listening on the public address, much less multiple.
> It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall. NAT is usually configured as part of your firewall, but is not a firewall.
That's a non sequitur. I can have a both a firewall and a NAT. The two layers are better than one because at least my address is shouldn't be routable even if I failed to configure my firewall correctly.
> DHCPv6
Okay? DHCPv4
> What are you supposed to do with a /8? Do you have several million computers?
That's GP's point. Running out of address space is not a problem even on IPv4 with NAT.
> What happens if your ISP changes your IPv4 address?
Well, an ostensible advantage of IPv6 is publicly routable addresses. I know how to configure my internal IPv4 network with host table entries and so on. If I move to IPv6 then my "internal" network address space is at the whim of my ISP.
> It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall. NAT is usually configured as part of your firewall, but is not a firewall.
Expanding on this. NAT as deployed in most soho/residential settings requires a stateful firewall to track connections + port mapping logic.A stateful firewall is also used for IPv6 edge security and using the same basic posture (out allow, in established/related only) except the only difference is it isn't also doing an address mapping. Nobody is out there saying folks should run a wide open IPv6 edge, and as far as I'm aware no one is shipping IPv6 ready consumer routers that do that (but I'm prepared to be proven wrong in the responses).
"What happens when multiple devices in your /8 want to listen on port 80 and 443 on the public address?"
This is a feature not a flaw. The average person doesn't have anything acting as a server, and that's a good thing, because the only servers they'd have would be embedded garbage in poorly maintained or completely abandoned IOT devices with incompetent code that should not be publicly exposed, ever, in anything but a call out model.
> What happens when multiple devices in your /8 want to listen on port 80 and 443 on the public address? Only one of them can. Now you're running a proxy.
I want to be running a proxy in that scenario, because I don't want any of it accidentally exposed.
> It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall. NAT is usually configured as part of your firewall, but is not a firewall.
Yes, but it's arguably helpful to have configuration mistakes still leave your internal network unexposed. It's harder to accidentally expose resources when your ISP won't route to them.
You're not wrong, yet there's still no compelling reason to make an extra effort to switch to ipv6 when the limitations of ipv4 don't personally affect you.
> > - My ISP gives me a /64, what am I supposed to do with that anyways?
> What are you supposed to do with a /8? Do you have several million computers?
Except you can subnet an IPv4 /8. You can't subnet an IPv6 /64. For whatever stupid reason, and despite having 18 quintillion available addresses in a /64, you can't actually do anything useful with it other than yeet a bunch of devices on the same LAN segment.
(At least on pfSense, and when I looked into it some, that's apparently IPv6 design for some reason)
> > - My ISP gives me a /64, what am I supposed to do with that anyways?
> What are you supposed to do with a /8? Do you have several million computers?
The /8 was for private addresses, so "free" and uncontested, while the /64 is a public resource. Looking at it as extraneous or over provided is understandable IMHO, even if mathematically it's not supposed to get depleted.
TLS SNI routing has fixed the multiple authorities listening on one IPv4 address port 443.
Most ISP’s implement IPv6 by using the single IPv4 address as a v6 prefix. This results in the entire LAN needing to change local addresses every time the public IP changes. In practice this means a single brief power outage causes hundreds of devices to break instead of none.
Generally speaking ipv6 is useless for most home network users.
Overlapping 10/8 with corporate networks is not a problem, wireguard has solved this in all cases I’ve run into.
> It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall.
With NAT, I absolutely know my ESP32 is not vulnerable and exposed on the wild wild web. With a firewall, I may have a configuration issue or there might be a bug in the implementation or there might be some UDP nuisance I didn't know about or a dozen other concerns. I don't want to hire a network admin not play one at home.
> > - What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.
>
> What happens if your ISP changes your IPv4 address?
To my internal net: nothing. All my internal addresses stay the same. All my firewall settings remain the same. Just to the outside world I come from elsewhere (which is good for my privacy, not sufficient obviously, though)
However if my IPv6 prefix changes all my IP based access control, which is a layer I use to limit what Internet of Shit devices can do, breaks. I could go to fe80 addresses for my local network, but those won't work across different network segments.
> - I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.
That's great until you need to connect to a work/client VPN that decided to also use 10.0.0.0/8.
> - Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.
Even on IPv4, having normal addresses for all your computers makes life so much nicer. Perhaps-trivial example, but one that matters to me: if two people live in one house and a third person lives in a different house, can they all play a network game together? IPv4 sucks at this.
> - My ISP gives me a /64, what am I supposed to do with that anyways?
For me, it is main problem. /64 is too small: SLAAC needs /64 per collision domain, and I have more than one (wired network, my WiFi, guest WiFi, control plane for UniFI APs), and it is painful to distribute /64 among them. I'm using HE tunnel which provides /48 to client and it is easy to configure, as intended.
There is recommendation (SHOULD, not MUST in RFC lingo) for ISPs to provide at least /56 to clients, but most domestic ISPs ignore this recommendation.
> - What happens if my ISP decides to change my prefix ?
And it is another problem: tooling. There is no standard way to reconfigure router with dynamic prefix(es). Yes, it is possible to write scripts for it, but it will be fragile. No Linux distribution or FreeBSD is ready to have dynamically allocated prefixes. It is not a real problem with IPv4 because real life practice to dynamically allocate one address and then configuration changes are trivial, and if you are delegated /24, it is typically static delegation.
That's a gripe I have with IPv6. There are too damn many special networks and addresses!
With IPv4 I can easily remember 10.0.0.0/8 and 192.168.0.0/16, but I can't remember the other one off the top of my head. (172.16.0.0/12 I think?). Multicast is 224.x.x.x/x IIRC, but definitely need to look that one up when I need it.
IPv6 has SO many special networks. Network. Public. Multicast. Link local. (Which isn't like an IPv4 link local, but apparently it can actually be on the LAN? IDK - I was just learning about it earlier today.) And every interface seems to have about 5 different addresses of each type.
> - I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.
10/8 is great until two organizations with 10.0.0.0/24 in their OSPF or IS-IS topologies are brought together via a merger/acquisition. Then you can end up with NAT with-in an organization itself. (Internal split-horizon DNS here we come.)
ipv6 just gives you two configurations to maintain, two firewalls to write rules for and cross-leaks that are hard to understand.
I make my internal network ipv4 only, I have a lovable static config, one firewall to maintain. I also use vlans to separate into "can get out", "can only get out through a whitelist proxy", and "can't get out ever". and I am very happy.
I just don't understand how people can just plug every device they own into a promiscuous ipv4 and ipv6 router and contribute to profiling, television snooping, vacuum cleaner house mapping, data leaks, botnets and more...
I do the opposite. IPv6-only in my LAN and Kubernetes Cluster and NAT46/NAT64 for external ipv4-only egress/ingress. Makes it much easier than both dualstack or IPv4 alone.
>I don't use IPv6 because it solves a problem that I don't have
At least here in the U.S., my observation has been it's usually a bit faster and has more efficient routes than IPv4. I assume part of that is using newer equipment and architecture than practical for IPv4 and ability to have more granular routes.
I regularly see 1-2ms improvement to first hop outside my ISP network (10ms vs 12ms)
Remembering addresses is a solved problem with DNS.
> NAT per se does not prevent an outside host from connecting to a host on your local network.
Yep, and a firewall per se does not prevent an outside host from connecting to a host on your local network. You can bang your head all day long, the side effect of NAT is to only allow incoming traffic that refers to an established connection that was initiated from the local network. How is this different from a firewall that does
I guess technically you are right, in that NAT doesn't prevent connections, it enables connections. But in the situation where you would have a NAT, behind a residential router, an outside host cannot connect to an arbitrary host on my internal network.
On a publicly routed PC, I can call `listen` and an outside host can connect to me.
On a PC behind a NAT - if I don't set up port forwarding - I can call `listen` and nobody from outside can connect to me.
So one could say, going from publicy routed to behind a NAT means that only allowed incoming connections are possible. Or am I missing something and you can really, from the outside, open a connection to a PC on a residential network which is behind a simple NAT (TCP server listening on that PC)?
Every single time. But that actually gives a simple answer for why IPv6 is still not commonly used. People can’t wrap their heads around the (simple) fact that NAT is orthogonal to firewalls - and IPv6 has more difficult concepts to offer.
Practically every single device or program that is connected in that ipv4 network will have a built in tunnel into the garden, with nat traversal being standard practice for everything. Your fridge, car, door lock, light fixture, all the applications on the phone, everything can and likely is a whole into the garden where someone can get full access. There are quite a few companies who has lost millions because they assumed that the garden was safe from threats within.
Never understood why they decided to include letters instead of keeping it numeric.
Hell, going from 199.120.121.122 to 199.120.121.122.123 will have expanded IPv4 by 254 times. It took us, what? 40 years to exhaust Ipv4... Just increasing it by 254 alone is insane large amount.
Belgium used this solution for their number plates They used to have a 6 letters/digit mix. Like abc-001 type of number plate. It started to run out, so they simply created a expansion, so new number plates started with 1-abc-001 in 2010, ... and in 2021 did 2-abc-def ( they did not run out of 1, they seem to simply use the first number to indicate the decade more and more). At that rate, Belgium will run out of numbers in they year 11990 ...
Ipv4 is easy to work with, easy to remember, write down, read ... Ipv6 is always a struggle. And yea, the idea that every device may need its own IP from your provider, is just insane.
I have so much more issues configuring things with IPv6, vs just basic IPv4+NATS. Its simply, its easy...
And maybe some people do not have this issue, but our provider gives DYNAMIC IPv6, so the pre-fix keeps altering! What makes configuring things on a NAS even more hell.
O and that :: range modifier is so fun. And the whole pre-fix and post-fix structure...
I hate it. Its complex for my little brain as i do not work daily with it, and whenever i need to deal with Ipv6, i need to relearn the quirks of it every time because of issues like the whole pre-fix/post-fix, dynamic pre-fix etc. Where as IPv4 ... so easy.
> Hell, going from 199.120.121.122 to 199.120.121.122.123 will have expanded IPv4 by 254 times. It took us, what? 40 years to exhaust Ipv4... Just increasing it by 254 alone is insane large amount.
In it's original design, SIPP, the design that was chosen for IPng had 'only' 64-bits, but it was decided that it would be impossible do another transition, and going to 128 would be better future-proofing:
So 199.120.121.122 could have grown to 199.120.121.122.152.183.166.197, which I do not think would have made a practical difference to those who complain about "hard to remember" addresses.
And it took 40 years to exhaust IPv4 because NAT was invented (RFC 1631), and now we're stuck with that kludge and have to have all sorts of workaround for it (ICE/TURN/STUN). IMHO it has also has contributed to the centralization of the Internet because doing P2P is just a pain in the ass.
The letters are hex digits, and make it more compact, regular. That’s the good part.
But I agree, using a reserved byte to select internet, say 0 for original, next two hundred for each region, with the rest for planets/moons/nearby stars, would have been easier to understand.
> - I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.
Remember, mate, with a /64 you can host your own ISP. You can finally have real Internet access! (Oh, wait -- it's not actually your /64 and your local ISP[s] wouldn't route it to you if it were, so you really can't.)
> - Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.
Oh, come on. Just look around. Almost everyone here agrees: NAT isn't a security function. Furthermore: NAT is literally the devil and has been for all of the decades you've been using it. Just think of all the stuff it breaks! Like FTP! (Remember how broken FTP was with NAT back in 1995? Or, *shudder*, h.323?)
Besides, with a /64, you can even have every computer on your network changing addresses for every IP connection! Doesn't that kind of obscurity sound nice? (Except... No, that doesn't sound nice at all. That just sounds bizarre and weird -- like dancing about architecture, or maybe some analogy about babies and bathwater.)
> - Stateless auto configuration. What ? No, no, I want my ducks neatly in a row, not wandering about. Again maybe my brain is rotten from years of DHCP usage but yes, I want stateful configuration and I want all devices on my network to automatically use my internal DNS server thank you very much.
Have you ever considered the concept of giving each machine two different IPv6 addresses? One for you to control, and one for your ISP to be in charge of. That'd be quite lovely, wouldn't it? (Except: Now you have two problems.)
> - It's hard to remember IPv6 addresses. The prospect of reconfiguring all my router and firewall rules looks rather painful.
Yeah, well. Uh. Have you tried looking into using ULA addresses like fe80::? (It's awesome! It's got all the hypothetical network convergence problems that an RFC 1918 10/8 has with which to bite you in the mysterious future, except it's also hexadecimal! And unlike the grossly prevalent DHCP system that your 10/8 LAN uses today, nobody can agree on how to centrally assign these addresses to devices!)
> - What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.
Look, man. Let me just move these goalposts for you. The real problem here is that people, like you, need to adopt IPv6. So adopt it already. Your router's implicitly always-on stateful firewall will just take care of it, just like it has almost certainly both incidentally and irrevocably done for your entire history of using NAT with IPv4. And the advantage to you is... you have that big, beautiful /64 to play with however you want (except: it isn't yours, so you don't), free of the chains of that ugly hack of NAT.
(See? That wasn't so hard! The goalposts are heavy, but they can still be moved easily-enough. These new chains are better than the old chains, anyway. The chains of IPv4 NAT were getting a little bit old and dusty, and learning which /64 your ISP will decide to number your LAN with this week is like opening a surprise box! Unless your ISP provides a /56 or something instead! Don't you like surprises? Hey, did I mention ULA? It's always important to mention ULA at least thrice because maybe you want at least two sets of LAN addresses for everything!
(All snark aside: ULA+DHCP+local NAT doesn't sound so bad at all. fd00::3 instead of 10.0.0.3? Gateway at fd00::1 instead of 10.0.0.1? Singular static LAN addresses if we feel like it -- without them being world-known, and regardless of which residential ISP we're using at the moment? People can get used to that. And it would at least present a familiar set of problems that would respond to a familiar set of solutions -- plus, with bonus nachos consisting of a whole dynamic /64 to play with if we ever feel like using that for some reason.
But AFAICT nobody does it that way because NAT is in and of itself some kind of evil thing even when it is under our direct control, so we're just stuffed. Thus, instead of local NAT, we get some combination of prefix bingo, global per-device identifiers or bizarro randomness, and/or overlayed logical networks with local ULA+public Internet addresses for the same friggin' doorbell.
And that shit is simply weird.
As a response to the weirdness, we get the resultant and inevitable pushback that all weird shit deserves.))
Half your complaints don't make sense, but most importantly if you think NAT isn't a problem and is under your control you must have never experienced the growing plague of CGNAT.
This isn't ignorance. This is an example of a little knowledge is a dangerous thing.
Ignorance is the internet just works the way it's meant to work for everyone. That's only practically possible with IPv6 these days. Your limited use case and privileged circumstances (ie. you even get a publicly routable v4 address) do not mean anything for someone who just wants things to work.
It's hard to adopt something that schools don't teach. I know someone who graduated from UCI with a CompSci degree with a specialization in networking, just before the COVID19 pandemic began. He recalled that the networking courses he took did not cover IPv6 at all, except to describe the address format (i.e. 128 bits, written as hexadecimal, colon-separated). Everything he learned about IPv6, he had to learn on his own or on the job. A standard that has been published for over two decades, heavily used for over a decade, and critical in the worldwide growth of the Internet, was treated as an afterthought by one of the premier universities in the US.
Obvious disclaimer: This is a sample size of 1, and an anecdote is not data, yada yada. I'm not involved in academia, and have no insight into the adoption of IPv6 in CompSci networking curricula on a broader level.
Meanwhile, I was taught and practiced IPv6 in 2003-5 in engineering school (France).
As of 2024, IPv6 deployment in France was >97% mobile and >98% residential due to not being required for obtaining a 5G radio license (and then v6 simply carried downward to being available on 4G) + every ISP that provides FTTH also providing v6.
Tbh it’s is a huge PITA with little practical benefit. IPv6 is the Perl 6 of networking.
Many of the big benefits are things that don’t deliver anything that folks are lacking. You also need to understand how you fit in the overall universe more.
An example for a small environment: I've got the whole homelab on unique ipv6 range. Whatever VPN connection happens to another network, I'll never have range collisions or need any fancy rewriting. Also the DNS will point at a specific address on my network, never at a random 192.168.x.x in a network I happen to be connected to.
No One believes us on hacker News. It feels very gaslighty. I have never talked to an IT engineer in person that thought IP version 6 in the data center or in the corporate network was a good idea.
I recently passed the CCNA again and they really spend a lot more time on IPv6 compared to 15 years ago. It inspired me to go all in this time and configured my home network with a PD allocation from my ISP. I also came up with some fun labs and even got a IPv6 sage T-shirt from Hurricane Electric.
Any recommended courses? I'm a SWE and never felt compelled for the CCNA but my intersection with networking-related problems seems to continuously increase and I would like to up my game before getting in over my head at work.
This doesn’t hold up. Schools can’t teach everything, especially in a field where innovation happens in the workplace, not the classroom. Should I have learned about LLMs when I was an undergraduate 20 years ago?
This is just further proof that university educations are still not job training. The sooner we disabuse ourselves of that perception the better off society will be.
Higher education is about creating a breadth of knowledge, not specific marketable skills. CompSci is a research field, not job training.
If your friend wanted to learn specific job skills a technical college would be the appropriate setting.
I realize this misperception is perpetuated by the job market but I’m still not surprised at the education provided by UCI and don’t fault them for providing it.
They taught us, they also taught ipv4 in the old "separate address per host" way instead of jumping to NAT, but I think ipv6 is inherently more complicated than ipv4 for the average use case. It's not just a thinking shift.
Separate from that, deliberate decisions were made to make it a "clean slate" without consideration for existing ipv4 hosts. Guess they were hoping the separate stacks would go away eventually, but in hindsight, no way.
> ... but I think ipv6 is inherently more complicated than ipv4 for the average use case. It's not just a thinking shift.
IPv6 isn't all that complicated for most common use cases. Its fundamental concepts and rules are simple. It also obviates the necessity of the complicated workaround called NAT, without which IPv4 is impractical these days.
It's more like the imperial vs metric system debate. If the world hadn't seen IPv4, I believe that we'd all be using IPv6 without any complaints. The real problem is that IPv6 isn't taught well.
> Separate from that, deliberate decisions were made to make it a "clean slate" without consideration for existing ipv4 hosts. Guess they were hoping the separate stacks would go away eventually, but in hindsight, no way.
I'm not sure what to make of this. The presence of the IPv4 stack isn't what blocks the adoption of IPv6 - at least not technically. They can coexist on the same host and function concurrently without interfering with each other. It was designed to operate like that. The actual blocker is the attitude that people hold towards IPv6 - "We have IPv4 that works already. Why should we care about an alternative?". You can see that expressed on this discussion thread itself.
There is one crucial detail that the IPv6 detractors neglect - the scarcity of IPv4 addresses means that IPv4 address blocks are now heavily coveted and therefore subject to moneyed interests. That isn't very good for the health of the open internet, digital rights and equity. They're thinking about individual trees and losing sight of the whole damn forest. IPv6 isn't a solution looking for a problem. It's the solution for a problem that people simply ignore.
I can’t think of any technology where mass adoption was driven by knowledge forcibly inserted into students’ brains by schools… if anything, adoption comes when people realize their out-of-touch curriculum is no longer relevant.
To be clear, degree programs have value, but it’s not in future-proofing students against needing to learn things after they leave school. Ideally it should prepare them and encourage them to do so.
>> I know someone who graduated from UCI with a CompSci degree with a specialization in networking, just before the COVID19 pandemic began. He recalled that the networking courses he took did not cover IPv6 at all...
I am not doubting you, but I feel this story is too hard to believe without adding further nuances...
The issue is that it’s not taught with IPv6 first. Networking courses do all kinds of stuff using IPv4 to demonstrate various protocols on top (e.g. http, tcp, icmp, etc).
Then there is usually a chapter on IPv6 that just briefly covers the differences.
I.e. the exercises all tend to use IPv4 as the foundation so people don’t practice v6
I've been of the opinion this is one of those "the art advances one funeral at a time." A lot of people are married to IPv4 and its arcane warts and really, really do not want to deal with IPv6 even though most of the core concepts are almost exactly the same thing, except better. I can't imagine anyone who dealt with V4 multicast ever wanting to go back, and I bet they've memory-holed parts of V4 that simply can't be used anymore and so have been turned off for decades(RIP to RIP). Has anyone seen the automated address assignment in V4 ever work? The usual hint it even exists is that if you see one of those addresses it means something is messed up in your Windows host or the DHCP server died.
People complain about dual stacks and all that but with a modicum of planning it is minimal extra effort. Anything made in the last decade has V4/V6 support and unless you're messing with low level network code, it's often difficult to even know which way you're being routed. Network devices pretty much all support using groups of names or addresses and not hard coded dotted-quad config statements now, and have for a while. And that was good practice on V4 networks too.
Part of it is probably that remembering various V4 magic is easy enough to do but feels complicated enough to be an accomplishment. In V6, there is no point in doing most of that because the protocol has so much more automation of addressing schemes. But if you like those addressing schemes, V6 can do them even better. You can do all sorts of crazy address translation on either the network or host id portion, like giving an internal network a ULA that is magically translated to a public network prefix without any stateful tracking unless that is desirable.
I feel there is some analog to DNS in that regard, people who have gotten used to DNS don't give a damn about host IP addresses but some people seem to really like the idea of a fixed address statement. People also seem to be stuck on the idea that NAT creates some kind of security when that's really the stateful tracking that is required for many-to-few translations (thus making firewalls a common place to implement it), not the translation itself. Similar to certificates/pki versus shared keys, yes, one is more upfront effort but that's because it's solving the problem of the Sisyphean task that is the other.
edit: This all reminded me that we lived with dual stacks before, in the IP and IPX days, or DECnet, and that GE Ether-whatever, and those had less in common. IPX mostly died with Netware but it had a number of advantages that wouldn't be bolted on top of IP for years, some of which are present in IPv6. I rather liked IPX and had history gone differently that it used 48-bit addressing would be causing us to discuss whether or not EUID was a mistake or not :)
80% of my career knowledge as a devops engineer, systems administrator, and IT engineer has been on the job training. That's just how it works.
The real reason is IT people hate ipv6. They want NAT. They don't want all the security holes and extra complexity. I don't want having to work with a network stack that is poorly supported by some switches and routers.
IPv6 was superceded by NAT a long time ago. It will die a slw and quiet death which is why it is now being ignored by training facilities and experts worldwide.
Oh no, somebody should warn all the ISPs deploying IPv6-native connections with v4 reachable over some fallback technology (464XLAT, DS-Lite, NAT64 etc.) to their hundreds of millions if not billions of customers!
Digital Ocean didn’t even have an ipv6 address on by default in the droplet I created last week. It’s just a switch to flip, but I’ll bet the support costs of hobbyists/enthusiasts not realizing they needed to also write firewall rules, make sure ports weren’t open for databases and things like that for ipv6.
NAT doesn't solve everything, and creates a whole new class of problems that you can just avoid by adopting IPv6 natively. And it's definitely not being ignored at larger companies.
In particular, just off the top of my head...
- T-Mobile US doesn't even assign clients an IPv4 address anymore. Their entire network is IPv6 native.
- Many cloud providers charge extra for IPv4 addresses, but give IPv6 addresses out for free.
What are you even basing that on? Here are some facts:
- You have to pay money to get a static IPv4 address for cloud machines on eg AWS. Anything needing a static IPv4 will cost more and more as demand increases. NAT doesn’t exactly fix that.
- Mainstream IoT protocols have a hard dependency on IPv6 (eg Matter/Thread). Not to mention plenty of 5g deployments.
- Many modern networks quietly use IPv6 internally. I mean routing is simpler without NAT.
So it almost definitely won’t die. It’s more likely it’ll slowly and quietly continue growing behind the scenes, even if consumers are still seeing IPv4 on their home networks.
This feels a lot like the arguing that went on during the transition to Python 3. The Python 2.7 hangers-on were so preoccupied with themselves that they didn't notice that the pool of people interested in having the argument at all was getting smaller and smaller.
Until somebody turned off the lights, that is. It is not much fun arguing with yourself in the dark.
I think that's what needed and needs to be done here. I will agree with the IPv4 advocates on one thing: IPv6 adoption has been slow in part because it doesn't work like IPv4 + kludges. That is the point. Clinging to IPv4 standard practices while you switch is just going to make you miserable.
In 2006, the hesitation to go to IPv6 made sense. Support was spotty. In 2026 it does not. IPv6 support is now more than adequate, and a clean cut will force the stragglers to get their asses in gear in a hurry ("fix your IPv6 support RFN or enjoy nobody using your product"). Change is painful, learning new stuff when you were getting by just fine on the old stuff is painful, I get it. But it will happen whether you like it or not. Why not just get it over with?
I finally made the switch to IPv6 last year, and I wouldn't go back.
The pain of change is real, but mercifully, it doesn't last. Within a year this debate will seem quaint.
As of 2024, literally none of the customers deploying the robots I worked on had ipv6 support on their networks. (We seriously considered switching to ipv6 for our backend controller-to-device network since it would inherently avoid conflicts that way - but none of the hardware devices had ipv6 support yet either, even the ones that were linux boxes underneath; turned out that network namespaces were a better approach to that problem anyway.) These were pretty technophilic areas (within otherwise "traditional" companies - the crossover between "wanting robots" and "being able to afford robots" is a little weird :-) and none of them were even talking about ipv6, to the point that we took "add configuration for ipv6 to the management console in a hurry because a customer wants it" off of our threat-to-schedule list entirely.
I get the feeling it's another 5-10 years before "not getting around to ipv6" will actually be a mistake in that space...
EDIT add: A lot of home users also like Ubiquiti ecosystem for local recording security cameras without a cloud subscription. Another competitor like Reolink with local capability also doesn't support IPv6: https://support.reolink.com/hc/en-us/articles/900000645446-D...
The practical home usage of deploying IPv6 depends on combination of the ISP, the devices you want to use, software stack, etc.
I can't use vlans because my isp only gives me a /64.
So I either need to use ipv6 + kludges or ipv4 + kludges. ipv4 is obviously easier and more reliable at that point, it's a no brainer.
Any sort of hot spot / bridge faces the same problem.
Now RFC 9663 is supposed to help here but guess what? It's only like a year old and barely exists. Not 20 years.
It's not that change is painful, it's the ipv6's original design of a shallow depth network was just... bad. Bolting on RFCs to fix it is taking a long time.
I would say this analogy is not properly when talking about IPv4 to IPv6 transition. Moving from Python 2.7 to 3 is a pure software problem while moving IPv4 to IPv6 is hardware, software, and logistics problem.
There are number of embedded OSes and devices that do not have firewalls nor the ability to disable network ports. Example of these invisible world items are motors, servos, PLCs, and label printers that get configured over IP. These devices do the bare minimum to get the IP stack up and running. These UI tools also need to be updated for allowing configuring an IPv6 address.
I would love to leave IPv4 and move fully to IPv6. Currently it is not cost effect to do so at scale. Companies do not want to spend money on the extra hardware to allow their IPv4 devices to talk IPv6 when they can save that money and keep running IPv4. Nor do they want to spend money on newer hardware. I still have clients running Windows XP Embedded, hopefully air gaped, in the automation world.
*You would be surprised on the number of large corporate IT managers that rather have a completely open label printer connected directly to their network instead of bridged behind a state full firewall running Windows or Linux hosting the main product.
That is an unusual luxury, especially mobile providers still using IPv4.
Mobile providers have been the first and most aggressive to migrate to IPv6. Probably helped along by the cost and difficulty of running CGNATs when your network clients are constantly moving around. At least in the UK all the mobile providers are IPv6, and I think a handful are IPv6 only.
I think it's different. Python 3 had a couple slightly annoying quirks that were resolved and once we got past that hurdle conversion was pretty seamless. I've been doing IPv6 in one form or another since, oh, 2010 or thereabouts, and it still remains pretty opaque and a pain in the ass compared to IPv4.
I do use it often, at least for Internet communication (I haven't checked recently to see what my traffic split is between v4/v6, but it's probably on the verge of tilting in favor of v6, if not already there), but I just can't see using it for my internal network anytime soon.
I'm not sure you understand what you're proposing. If you end IPv4 support on your product, all you're doing is banning the users on ISPs that don't have IPv6 support.
The people feeling the pain would not be in any position to fix the problem, and their experience will be that your site is down which leads to support burden and reputation risk for your product. If your support tells me to switch ISPs I'm going to roll my eyes and find another product that works.
I interpreted it to be about vendor contracts. Suppose you're setting up a new thing and you have a choice of vendors. They're all about the same but one of them supports IPv6. You're more likely to pick that one.
I think the big difference is that python 3 took over rather quickly once it hit a threshold. There was a clearer path for adoption too: as more major packages started supporting python3, adoption accelerated and eventually python2 support was dropped. For IPv6 it's a lot less straightforward. You could cling on to IPv4 with basically 0 practical downsides in the current ecosystem as everything that supports IPv6 also supports IPv4, and IPv6 only networking basically doesn't exist. Even mobile users with only IPv6 adresses get to use IPv4-only services through some translation layer that every ISP has to provide when running IPv6.
I don't like to admit this, but at this point honestly I think ipv6 is largely a failure, and I say this as someone that wrote a blog post for APNIC on how to turn on ipv6.
I'll get endless pushback for this, but the reality is that adoption isn't at 100%, it very closely needs to be, and there are still entire ISPs that only assign ipv4, to say nothing of routers people are buying and installing that don't have ipv6 enabled out of the box.
A much better solution here would have been an incredibly conservative "written on a napkin" change to ipv4 to expand the number of available address space. It still would have been difficult to adopt, but it would have the benefit of being a simple change to a system everyone already understands and on top of a stack that largely already exists.
I'm not proposing to abandon ipv6, but at this point I'm really not sure how we proceed here. The status quo is maintaining two separate competing protocols forever, which was not the ultimate intention.
> A much better solution here would have been an incredibly conservative change to ipv4 to expand the number of available address space
"And what do you base this belief on?
Fact is you'd run into exactly the same problems as with IPv6. Sure, network-enabled software might be easier to rewrite to support 40-bit IPv4+, but any hardware-accelerated products (routers, switches, network cards, etc.) would still need replacement (just as with IPv6), and you'd still need everyone to be assigned unique IPv4+ addresses in order to communicate with each other (just as with IPv6)."[0]
> Fact is you'd run into exactly the same problems as with IPv6.
If you treat IPv4 addresses as a routable prefix (same as today), then the internet core routers don't change at all.
Only the edge equipment would need to be IPv4+ aware. And even that awareness could be quite gradual, since you would have NAT to fall back on when receiving an IPv4 classic packet at the network. It can even be customer deployed. Add an IPv4+ box on the network, assign it the DMZ address, and have it hand out public IPV4+ addresses and NAT them to the local IPv4 private subnet.
IPv6 seems to be a standard that suffered from re-design by committee. Lots of good ideas were incorporated, but it resulted in a stack that had only complicated backwards compatibility. It has taken the scale of mobile carriers to finally make IPv6 more appealing in some cases than IPv4+NAT, but I think we are still a long way from any ISP being able to disable IPv4 support.
I agree with that belief, and I've been saying it for over 20 years.
I base it on comparing how the IPv2 to IPv4 rollout went, versus the IPv4 to IPv6 rollout. The fact that it was incredibly obvious how to route IPv2 over IPv4 made it a no-brainer for the core Internet to be upgraded to IPv4.
By contrast it took over a decade for IPv6 folks to accept that IPv6 was never going to rule the world unless you can route IPv4 over it. Then we got DS-Lite. Which, because IPv6 wasn't designed to do that, adds a tremendous amount of complexity.
Will we eventually get to an IPv6 only future? We have to. There is no alternative. But the route is going to be far more painful than it would have been if backwards compatibility was part of the original design.
Of course the flip side is that some day we don't need IPv4 backwards compatibility. But that's still decades from now. How many on the original IPv6 will even still be alive to see it?
Hardware would catch up. And IPv4 would never go away. If you connect to 1.1.1.1 it would still be good ole IPv4. You would only have in addition the option to connect to 1.1.1.1.1.1.1.2 if the entire chain supports it. And if not, it could still be worked around through software with proxies and NAT.
You’re focusing on the technical difficulty of implementing it in software. This is not the problem. IPv6 support is now present in almost every product, but people still refuse to set it up because it’s so different to what they’re used to (I’m not arguing whether the changes are good - they’re just changes). IPv4+ would’ve solved this social problem.
Hardware support for ipv6 hasn't been the limiting factor in a long time. Users higher on the stack don't want to adopt something that makes so many unnecessary changes.
The IPv4+ could pass through a router that doesn't know about it - the cloud host that receives that packet could interpret it in a special way, in fact you could stuff additional data into the next layer of the stack for routing - it's not like many services beyond TCP would need to support the scheme.
This whole discussion reminds me of the beautiful design of UTF-8. They used the lower bits to be ASCII which made backwards compatibility so much easier. It also reminds me of the failure of Intels Itanium and the success of AMD x64. Engineers often want to abandon backwards compatibility to make a new "beautiful" design, but it's the design that has full backwards compatibility that's actual impressive.
It reminds me of python 3. Basically, a huge chunk of people (in my case, scientific programming) get an enormous mess and nothing at all of value until... 3.6 maybe (the infix matrix mult operator). Stunningly, people weren't enthused about this deal.
It would maybe be okay at the router to break some things, but ffs even in software I have to choose? Why do I need both ping and ping6 this is stupid!! They really screwed up by making it a breaking change to the OS and not just internet routing.
The only solution is a gov't mandate. China went from almost no adoption to leading the world in adoption (77% of all Chinese internet users) in a few years because they explicitly prioritized it in their last 5-year-plan.
US government has finally learnt from how vendors break the mandates and there's now IPv6 mandate if you want to sell to federal government, and waivers are only available for buyers not vendors, and individually every time.
I wouldn't say "failure". There are many, many IPv6 client devices out there, mostly on mobile networks. And it works great and they do well and the tools all support it very well.
But IPv4 will never, ever die. The rise of NAT as a pervasive security paradigm[1] basically neuters the one true advantage IPv6 brought to the table by hiding every client environment behind a single address, and the rise of "cloud everything" means that no one cares enough about reaching peer devices anyway. Just this morning my son asked me to share a playlist, so of course I just send him a link to a YouTube Music URL. Want to work on a spreadsheet for family finances with your spouse in the next room? It lives in a datacenter in The Dalles.
[1] And yes, we absolutely rely as a collective society on all our local devices being hidden. Yes, I understand how it works, and how firewalls could do this with globally writable addresses too, yada yada. But in practice NAT is best. It just is.
> I wouldn't say "failure". There are many, many IPv6 client devices out there, mostly on mobile networks.
Honestly it's a huge success due to this fact alone.
IPv6 is failure only if you measure success by replacing IPv4 or if you called "time" on it before the big mobile providers rolled it out. The fact that all mobile phones support it and many mobile networks exclusively deploy it tells you what you really need to know.
IPv6 is a backbone of the modern Internet for clients, even if your servers don't have to care about it due to nat64.
I toyed with using ipv6 in my local network just to learn it and what a headache that was. Ultimately not worth the hassle. I can remember most of the important device ipv4 on my network, I can't say the same for v6.
This is the first time I've heard this critique. I think most people don't care if their IP address is easily human readable/memorizable. In my experience when people do deal with ipv4/v6 addresses directly, they just copy-paste.
Circa 1999 I was working for Cisco as a sysadmin. I got my CCNP through internal training and considered making a career of network administration, but ipv6 changed my mind. It seemed so much more difficult and unpleasant to deal with. I didn't want that to be my day to day work.
I think the same thing happens on a different scale with ISPs. They don't want to deal with it until they have to for largely the same reason.
> It seemed so much more difficult and unpleasant to deal with.
In my experience it’s much easier and much more pleasant do deal with. Every VLAN is a /64 exactly. Subnetting? Just increment on a nibble boundary. Every character can be split 16 ways. It’s trivial.
You don’t even need to use a subnet calculator for v6, because you can literally do that in your head.
Network of 2a06:a003:1234:5678::555a:bcd7/64? Easy - the first 4 octets.
Network of 10.254.158.58/27? Your cheapest shotgun and one shell please.
At first I though so too but IPv6 is actually easier. instead of CIDR you always have 64 bits for network and 64 for host. You get a public /48 IPv6 prefix that allows for 16 bits of subnets and then the host addresses can just start at 1 if you really want. So addresses can be prefix_1_1 if you want. And the prefix is easy to memorize since it never changes.
I DO think using 64 bits for hosts was stupid but oh well.
I actually think it would have had a better chance of success if ipv6 had embraced the breaking changes to add some killer feature that would have made it worthwhile to upgrade even for entities who didn't need to worry about running out of ipv4 addresses.
IPv6's failure was mostly caused by the IETF's ivory tower dwellers, who seem to generally have no practical experience or understanding whatsoever of how networks are actually built and run today, especially at the small to mid scale.
Small site multihoming, for example, is an absolute disaster. Good luck if you're trying to add a cellular backup to your residential DSL connection.
IETF says you should either have multiple routers advertising multiple provider-assigned prefixes (a manageability nightmare), or that you should run BGP with provider independent address space; have fun getting your residential ISP or cellular carrier onboard with this idea.
IETF has a history of being hostile to network operators. I mean actual network operators - not the people who show up at conferences or work the mailing list who just happen to get a paycheck from a company that runs a network (and have zero production access / not on call / not directly involved in running shit). It's gotten better in the last few years in certain areas (and credit to the people who have been willing to fight the good fight). But it's very much a painful experience where you see good ideas shot down and tons of people who want to put their fingerprint on drafts/proposals - it's still a very vendor heavy environment.
The fact is that already in 1993 routing tables were just too big, and the fact is that having a "flat" address space was always going to mean huge routing tables, and the fact is that because IPv6 is still "flat" routing tables only got larger.
The fix would have been to have a subset of the address space that is routed as usual for bootstrapping ex-router address->AS number mapping, and then do all other routing on the basis of AS numbers _only_. This would have allowed us to move prefix->AS number mappings into.. well, DNS or something like it (DNS sucks for prefix mapping, but it could have been extended to not suck for prefix mapping), and all routing would be done based on AS numbers, making routing tables in routers _very small_ by comparison to now. Border routers could then have had tiny amounts of RAM and worked just fine. The IP packets could have borne AS numbers in addition to IP addresses, and all the routers in the middle would use only the AS numbers, and all the routers at the destination AS would know the routes to the destination IPs.
But, no. Great missed chance.
Well, we still could do this with IPv6, but it would be a lot of heavy lifting now.
EDIT: Ah, I see draft-savola-multi6-asn-pi existed.
> a cellular backup to your residential DSL connection
Hmm, what's the problem? I suppose your home devices should never be exposed to the public internet, and should only be accessible via a VPN like Wireguard. NAT64 is a thing if your home network is IPv4.
BTW what's the trouble with multi-homing? Can't an interface have two separate IPv6 addresses configured on it, the same way as IPv4 addresses?
I've been thinking we could simply extend the ipv4 address to be 11 bytes by (ab)using the options field. That is, add an option that holds more bytes for the source and destination address, which are to be appended to the address already present in the header.
I am thinking that since an option starts with 2 bytes and everything must be padded to a multiple of 4 bytes, we can add 16 bytes to the packet, which would hold 7 extra address bytes per source and destination, giving us 11 byte addresses. ISPs would be given a bunch of 4-byte toplevel addresses and can generate 7-byte suffixes dynamically for their subscribers, in a way that is almost the same as CGNAT used today but without all the problems that has.
Most routers will only need to be updated to pass along the option and otherwise route as normal, because the top level address is already enough to route the packet to the ISP's routers. Then only at the edge will you need to do extra work to route the packet to the host. Not setting the option would be equivalent to setting it to all 0s, so all existing public hosts will be automatically addressable with the new scheme.
There will of course need to be a lot more work done for DNS, DHCP, syntax in programs, etc, but it would be a much easier and more gradual transition than IPv6 is demanding.
I don't think so. It would be more confusion because no one will know if a network is ipv4 or ipv4+, leading to edge case bugs and confusion and people will similarly be lazy and choose to only implement ipv4 knowing it will always be reverse compatible and the cost is transferred to the consumer.
Plus, it's only 2048x the address space. It's within the realm of possibility that we will need to upgrade again once this place is swarming with robots.
ipv6 adoption is still steadily rising. Not as fast as anyone hoped, but at least steadily. There is no way it can be abandoned at this point even if we wanted to.
I wonder if it could still be usurped by another standard that is somehow more popular. If adoption of that leapfrogs over IPV6 then maybe it will have just been a waypoint along the way.
Truth is there are too many devices that only speak IPv4 or have untested IPv6 stack. People still can’t even agree on how ipv6 address is represented.
Stripped of all the other baggage that came with it (e.g. SLAAC, IPsec, etc) IPv6 is an incredibly conservative addressing extension. The only thing even more conservative than v6 would have been to drop the lower 64 bits of the address and the associated EUI-64 local addressing scheme. Which... to be fair, that turned out to be a very bad idea, but the length of the field isn't what was holding up v6 adoption.
I suspect by "incredibly conservative" you mean "backwards compatible", which... no. You can't make an addressing extension backwards compatible with hardware that doesn't read all of the address. Of course, we did that anyway with CGNAT, and predictably it causes huge problems with end-to-end connectivity, which is the whole point of IPv6. You're probably thinking more along the lines of an explicit "extension addressing header" for v4. Problem is, that'd mean a more awkward version of IPv6's /64 address split[0], combined with all sorts of annoying connectivity problems. The same corporate middleboxes that refuse to upgrade to IPv6 also choke on anything that isn't TCP traffic to ports 80 and 443. So you'd need Happy Eyeballs style racing between CGNAT IPv4 and "extended IPv4".
Also, that would just be a worse version of 6in4. Because they also thought of just tunneling IPv6 traffic in IPv4 links. I don't think you understand how incredibly conservative IPv6 actually is.
The problem with "incredibly conservative" IP extensions is that nothing beats the conservatism of doing literally nothing. IT infrastructure is never ripped out and replaced unless there is a business case for doing so. The current problem with IPv6 adoption is that nobody has yet said "let's stop processing IPv4 traffic", they've only said "let's get more dual-stack hosts online", which is a process that only asymptotes to 100% IPv6, and never reaches it.
IPv4 was not the first version of the Internet protocol. That honor goes to Network Control Protocol (NCP). The reason why we don't have an asymptotic long tail of Internet hosts still demanding NCP connectivity is because this was back when "having a connection to the Internet" meant "having a connection to ARPANET". The US military could just refuse to process NCP packets and actively did this to force people onto IPv4. Now imagine if someone big like Google said "we're going to stop accepting IPv4 connections" - people would jump onto v6 immediately.
[0] Let's say we add a 32-bit extension header onto IPv4
"Stripped of all the other baggage that came with it..."
But that baggage is a huge part of the problem. Almost nothing you know about IPv4 applies when you switch to IPv6, and most of us found that out the hard way when we tried to make the switch. Leaves a pretty bad taste in your mouth.
> The current problem with IPv6 adoption is that nobody has yet said "let's stop processing IPv4 traffic"
Mobile carriers have done that between consumer devices and network towers. That forced a lot of innovation (including tools like better DNS64 and "happy eyeballs" protocols) and network stack hardening.
The roll out of out CGNAT in some cases is "let's drop IPv4 traffic randomly" and "happy eyeballs" in consumer devices is transparently driving a lot of consumer traffic to IPv6.
This is why mobile and consumer devices are leading the pack on IPv6 adoption.
It's maybe not all of Google that next needs to say "we're going to stop accepting IPv4 traffic", it's maybe more specifically GCP (and AWS and Azure) that need to do that to drive the non-consumer IPv6 push we need. The next best thing would be for all the cloud providers to at least start raising IPv4 address prices until their clients start to feel them.
> The current problem with IPv6 adoption is that nobody has yet said "let's stop processing IPv4 traffic"…
One of the giant CDNs translates all IPv4 traffic to IPv6 at the edge (stateless NAT46) and is IPv6-only in its core network (for one of its primary product networks; like everybody they have multiple networks.)
I think this is defeatist talk where it’s not warranted. I remember IPX networks in the 90s were still a thing because people believed they could eke out a little more performance for their games. It’s taking a long time to move to IPv6 in some parts of the world. eg: anyone who doesn’t feel the pain of the IPv4 address crunch likely due to having a large chunk to begin with. Many influential organizations in North America definitely fall in that category.
IPv6 is a success IMHO because it is used in so many places. Google’s IPv6 traffic graph shows close to 50% adoption and still trending up. We can’t possibly expect the world to be near 100% overnight… the internet is a big place with the whole spectrum of humans influencing IT; There will always be someone who will cling to IPv4 for dear life.
> I'm not proposing to abandon ipv6, but at this point I'm really not sure how we proceed here. The status quo is maintaining two separate competing protocols forever, which was not the ultimate intention.
The end game will be a cryptographically large address space allocated based on some cryptographic operation, rather than a committee carving up the space arbitrarily.
Tor already does this, addresses allocation is not a problem.
I think they used to use hashes, but now use Ed25519 public keys.
Obviously, Tor is not suitable for most tasks.
No one should have to pay for the extra latency if they don't need the anonymity.
The real problem is routing in these address spaces, and there have been a few projects like CJDNS which try to solve it.
Imagine every address along a major road is 3 digits, and some shortsighted post office code assumes 3. Your business is 845 Oak St. One day they say hey, this road is getting too long, let's update that code to support 10 digits and we never worry about this again.
Oh and btw, your address is now 9245593924 Oak St.
Maybe not in the strict sense, but it kind of has.
In the enterprises I've worked in the past decade with IPv6 running, at least 75% of the Internet traffic is IPv6. In my discussions with other engineers managing large networks, they seem to be seeing more or less that same figure.
The problem is that virtually nobody knows IPv6. I regularly bring up IPv6 in engineers' circles and I'm often the only one who knows much about it. And so, I have doubts about it's long-term future, except for edge cases. I figure some clever scheme utilizing IPv4 and probably NAT will come around at some point.
IPv4s are about to be bought, held, portfoilo'ed, speculated, and rented/mortgaged/sold like real estate. Companies like IPXO are already doing it. The costs of public IPv4's are going to go up for no technical reason because a new distinct ownership layer is springing up between you and the ISP. You're going to start renting them or paying a holder for the right to use them (on top of your ISP to transport it) at some point. And you can continue to do that, or get IPv6's for free.
Just to be pedantic, it's "illegal" to hoard IPv4 or to buy it for any purpose other than using it directly. But yeah, in the real world it may become more financialized than it already is. OTOH if prices keep dropping maybe they won't bother.
I'm a networking noob, but would it be possible to extend DNS/HTTPS so as to allow a URL to point to a port other than 443? Doing so would allow each IP address to serve multiple websites/computers making the pool of addresses at least thousands of times larger.
We own our own IPv4 and IPv6 ranges, which is nice. There already is a holder for the US: ARIN.net and I hear it's a pretty spendy annual fee for most orgs (we're legacy. we've had ours for decades)
> Maybe not in the strict sense, but it kind of has.
I challenge you to find:
1. A hotel in the US that provides IPv6. I have NEVER been in one, and I once stayed in a hotel (in Mountain View, CA) that was giving out public IPv4 addresses.
2. An easier task: a SIP provider that has IPv6 (in the US). You know, for the VoIP that is supposed to be a poster child of end-to-end connectivity.
> In the enterprises I've worked in the past decade with IPv6 running
What about those without IPv6 running?
Anyway, in the enterprises I've worked in the past decade - of course, another anecdote - not once has anyone ever specified an IPv6 address of anything. Inside the organization or outside of it.
> not once has anyone ever specified an IPv6 address of anything. Inside the organization or outside of it.
If you deploy IPv6 correctly, you shouldn't have to disclose IPv6 addresses to users inside or out -- DNS keeps the address literals abstract, hidden from users.
Ok then: most people in the US do. The rest of the world is looking increasingly ipv6 too: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
India is 71% IPv6 (probably thanks to Jio), China has it in its 5 year plan, Europe is doing well, etc
The fact that this comments section indicates such a yawning chasm of gaps in knowledge (much less, understanding) - in a forum whose users are generally known to be more technically savvy than most - is exactly why IPv6 is still not widely adopted. There is confusion about the less obvious benefits, confusion about how it works, confusion about the dangers (how do I adjust my well honed IPv4 spidey senses?), and confusion about how I transition my current private network. An epic failure of change management.
Here’s a prediction. Linux on the desktop will have >50% penetration well before IPv6 does.
It's so funny to see predictions that aged worse than milk. Ipv6 adoption isn't up to individuals, it's up to ISPs. We consumers aren't supposed to know about ipv6. The change will be silent and continuous.
“Given addresses” != adoption. Hell, I had to disable it in osx because it breaks the damn hotspot connection functionality. Wasn’t using it, it’s just there, breaking shit and being useless.
> The fact that this comments section indicates such a yawning chasm of gaps in knowledge (much less, understanding) - in a forum whose users are generally known to be more technically savvy than most - is exactly why IPv6 is still not widely adopted.
No, it isn't. Everyone here has the causality backwards. We don't know it because we've never needed to know it, and we've never needed to know it because it's not really required for anything (i.e. the cost of adopting/learning it > benefit).
This has been a frustrating HN discussion to read, to be honest, because the consensus view strikes me as so off base. It's not that IPv6 has been miscommunicated, or that it hasn't been taught enough to undergrads. It's that it has been designed with virtually no incentives to encourage people to actually adopt it, with the entirely predictable consequence that no one adopted it. Therefore, none of us need to know it, schools don't need to teach it, etc.
Folk are internalising the wrong lesson here. Incentives matter. No amount of mandated IPv6 instruction or well-intentioned blog posts explaining IPv6 are going to change anyone's incentive structure. And then when those things fail, there's a predictable and tiresome tendency to blame the users for not switching.
If you want people to adopt new tech, make it actually do something new. Give people some reason to want to switch. "It mostly does the same thing as the old tech did, but it also takes effort and money to learn it / switch to it" is a terrible pitch, with entirely predictable consequences, and it's far too common in technical circles.
> There is confusion about the less obvious benefits, confusion about how it works, confusion about the dangers (how do I adjust my well honed IPv4 spidey senses?), and confusion about how I transition my current private network
Could you be specific about what the misconceptions are?
One would think that in 30 years there will be some sort of best practises established. Some articles to refer people to. Or at least some people to share their experience and answer practical questions.
And yet there is still only "you doing it wrong, and I won't tell you how to do it right"
IPv6 existence is questioned not because people fail to configure it. It’s because they do not understand the problems it solves. Those problems are so large they’re invisible at the individual human scale. You either know them (which is not a secret) or invent superficial charges against the design.
I get so many Second System Syndrome vibes off of IPv6. Surely other people must be picking it up too.
Future proofing it by jumping straight to 128 bits instead of 64. 64 would have been fine. Even with a load factor of 1:1000 by assigning semantics to ranges of IP addresses, 64 bit addressing is still enough addresses for 10 million devices per person.
If we become a galactic empire, we will have to replace the Web anyway because every interaction will have to be a standalone app or edge networking that doesn’t need to hear back from the central office for minutes, hours, days anyway. We could NAT every planet and go on forever.
The point is not really to support a galactic empire, the idea is that you have a network part and an interface part, each is 64 bits. The "network" part is used by routers, the interface part is to identify the device on the endpoint. Each interface have an identifier that is world unique (usually based on the MAC address), each network is also unique. Usually, your ISP gives you a /48 prefix, so you have 16 bits for potentially 64k internal networks. This way, you don't need something like DHCP to get an address, you just take it and you won't have conflicts.
But because you have two independent unique parts, you need twice as many bits, so 64+64=128 bits. It simplifies routing and address allocation, at the cost of 16 bytes per packet compared to 64 bit addresses.
That we could use IPv6 on galactic empires is an added bonus, but not really the reason.
> Future proofing it by jumping straight to 128 bits instead of 64. 64 would have been fine. Even with a load factor of 1:1000 by assigning semantics to ranges of IP addresses, 64 bit addressing is still enough addresses for 10 million devices per person.
128 bit is like the least of adoption issues and basically meaningless difference vs 64.
But it shows weird priorities when they decided 128 then immediately wasted half of it on host part just to achieve "globally unique" host part that isn't really all that useful characteristic of the protocol.
> to achieve "globally unique" host part that isn't really all that useful characteristic of the protocol.
That's the essential part of self-configured addresses in IPv6 that does away with DHCP in most cases. DHCP is a stateful system that has to track every device's addresses individually. You don't need that with IPv6 thanks to this.
Don't think the problem is 64 vs 128. I don't think the problem is end users either, the vast majority of which don't even know what the IP protocol is in the first place (nor should they). The fault I think is on ISPs.
I use hyperoptic in the UK, if you replace the original router (which reserves the external 443 port for itself, i.e. no one sophisticated would keep it), there seems to be no way to get a v6 address. This is pure incompetence and carelessness. Like ISPs allowing their network to send packets spoofing IPs from outside their network. Add to that foreign ISPs (which means that even if your own network supports v6, you need v4 support when you are on holidays/travelling), and you have a situation where v4 cannot simply be switched off.
So for a website, what is the point of supporting v6 if v4 is never going away?
It's understandable that IPv6 would be ambitious rather than incremental given the cost of rolling out a new protocol; the bells-and-whistles IPv6 design is probably just a relatively small constant factor more expensive than the simplest possible address space expansion. Viewed that way, you only get the one chance to update the protocol, you might as well fix whatever you can.
It's not Second System Syndrome. Nearly every complaint against IPv6 is downstream of the decision to enforce a global centralized namespace for an end-to-end principle many don't care for.
e.g. Getting a unique address would be way more risky with 64 bits (there's a reason UUIDs are 128 bits too!), even before considering the network:interface split.
> Future proofing it by jumping straight to 128 bits instead of 64.
It's hard to disagree with your point since 64 would definitely have been better than the 32 we have. I'm not convinced the choice of going for 128 bits posed any real challenge to adoption though.
The irony that I forgot to voice is that if we had gone 64 and feeder features we’d be farther along in adoption now and probably be consuming the address space at least a fraction as fast as people feared.
By raising the barrier to entry so high we guaranteed the features would likely never be needed.
> For many, the decision of which protocol to use was easy because IPv6 didn't add features that represented major improvements.
This is the obvious and only key to this puzzle.
We tech nerds have this mad idea that everyone will want to spend time and money adapting to new standards because they're technically better in some abstract way, and so we do absolutely no work to create incentives for anyone to switch. Often, the new standard is not (yet) even functionally equivalent to the old one (e.g. Wayland), just to make doubly sure the switch will be as difficult and undesirable for end users as possible.
And when the absolutely inevitable consequences occur - stakeholders do not want to invest in switching to or developing for new standards that give them zero incentive to do so - there's a silly finger pointing game, as though everyone was supposed to switch, and they've failed to do so. Which is, of course, absurd. People don't owe us compliance.
Do not expect to be able to successfully shift behaviour unless you give people incentives - reasons they would want to switch, not just reasons you want them to switch.
I'd assume a lot of this is because of mobile devices of some type. Getting legacy network operators like cable providers to supply IPv6 has been hell.
Eyeball networks and cloud providers have been implementing IPv6. In the US all major phone carriers are v6 only with XLAT, the large residential ISP all have implemented v6 (Charter/Spectrum, Comcast/Xfinity, altice/optimum). The lagging networks are smaller residential ISP and enterprise networks.
In Asia they've implemented v6 everywhere pretty much because their v4 allocation is woefully insufficient. APNIC has like 4 billion people in it but less IP space than ARIN, with a population of less than 500 million.
Is that worldwide adoption or adoption in the US? China went from almost nothing to 77% adoption is just a few years because they included it in their last 5-year-plan. How much of that adoption would be explained by China alone
That's the best thing I've read all year. Ok, it's the best thing I've read last year too. I kinda knew all this stuff but I never knew how it all happened. I never thought of MAC as unnecessary in an IPv6 world.
IPv6 has already won on mobile and been gaining fast traction in IoT space with Matter. The reason IPv4 is still around everywhere else is because we came up with ingeniuous techniques that squeezed the heck out of IPv4 address space. Also, IPv4 addresses are easier to type. That's pretty much it.
Yes, they are easier to type, and to remember, and it turns out, that's actually a big deal! When you are troubleshooting network problems, it's really nice to take everything but simple raw addresses out of the picture. It's really nice to be able to look at an address and instantly recognize if it's on the same (V)LAN as you are expecting, if it's unique, if it changed from what it was last time you checked, if it's an address for a VPN interface, if the packet you are sniffing is for this host or that host, if DNS is resolving correctly, etc., etc.
I agree that it's a big deal. IPv6 has some "well-known short addresses" to alleviate this issue like accesing well-known broadcast addresses etc with `fe80::` prefix, but it's sad that they don't have one for the gateway (something like `fe80::1`). I know that there's a reason for that like supporting multiple network connections, but just have a shortcut for the "first gateway" at least which is the most common.
You can do the exact same thing in V6 if you want, there are so many extra bits you can have DHCPv6 or assigned addresses pack all kinds of things in there. With ULAs there are 16-bits for network ID, which is so sparse you can type the VLAN ID in decimal and ignore that you're losing the overhead. People will often put in joke address like deadbeef that can be fit into hex (the 40-bit global ID should be random but for hobbyist purposes most people are willing to suffer re-numbering it in the unlikely event their homelab is bought out by IBM). If you'd rather eat into the interface id portion, you can technically do whatever you want in there although packing too much in may locally cause problems in some routers if you try to treat it like additional network id bits. It's the equivalent to have both middle bytes of 10.x.y.z available for whatever while still having a few hundred billion available subnets.
Just as an example google's public DNS is 2001:4860:4860::8888 because their v4 dns is 8.8.8.8.
Where IPv6 is struggling the most is corporate networks. There are many network admins that are afraid of IPv6 and don't want to learn about it, so they just block it at the gateway.
My prediction [0]: It will take roughly 100 years for IPv6 to be ubiquitous enough to shut off IPv4. That's not intended as hyperbole, if anything it's an understatement.
Because, it's not going away: You can talk all you want about how IPv6 should have been a more straightforward expansion of the address size, but this is all in the rear-view mirror at this point. IPv6 is going to be with us forever, you may as well get used to it. It's already everywhere in 5G deployments, ISP's like Comcast use it for 100% of their out-of-band management, China is making huge progress moving to it as part of their 5-year plan, India is progressing nicely in their transition, the list goes on. We're already way too far along in the transition to abandon it in favor of something else.
But it's not going to happen any quicker than we've seen, either: There's no urgency (no "must-have" use case) except for what organizations are imposing on themselves. Yeah, IPv4 addresses are more expensive, but you don't really need many of them as a business (you can get by with a small handful of public ones, and just using L7 load balancers and SNI for everything) nor as an ISP (CGNAT can get you a long way.)
So we have a situation where things are migrating very slowly, mainly only in places where it makes sense (mobile deployments, home ISP's where the users don't actually administer the network), and generally mostly for new deployments. This is a recipe for IPv4 to be around for a very, very long time. We're used to technology moving at breakneck pace, but that's only the case for the higher-level stuff. The core infrastructure like the internet protocol is likely the textbook example of slow-and-steady, and a case where it's actually not crazy to think of centuries-long timeframes for things.
[0] Barring any unforeseen black-swan events like a world war destroying all technology and having to rebuild from scratch or something. Or a competent international agreement to aggressively migrate to it (I don't know which is more likely.)
My ISP refuses to give you a static IPv6 prefix unless you're a business customer, despite having an "unlimited" amount of them. This results in me not bothering to set it up properly and focusing on IPv4 still.
I don't have a static IPv4 address and I have to use a DDNS built into the Caddy plugin on my OPNSense router. From what I understand, you can't get a static "local" (I know, IPv6 has no direct equivalent) address to use for a reverse proxy — at least not in an easy manner. I might be completely wrong but that's why I don't bother with IPv6.
My ISP is xfinity. They say the same thing but my IPv6 address hasn't changed any more frequently than my IPv4. In my experience it changing isn't any more annoying than my v4 changing so I'm not sure why people still get up in arms about it.
This should be illegal. Yes, in this case, I'm not saying that as a figure of speech. ISPs are a utility, and building that kind of artificial scarcity into something that is really damned near infinite is highly anti-consumer.
Get a virtual server and do the things on it that you'd want a static address for. Use a VPN connection back to your home to merge it with your network. This is a great way to deal with CGNAT.
For those in the UK who want a static IPv4 or IPv6 block AAISP offer a L2TP service for £2/month. It's limited to 3 megabit/s but might be enough for some use cases.
I recently moved house and looked at a new offer from a new ISP for a long term lockin but a cheap price. They used CG-NAT. I instead chose one which gives me as many ipv4s or ipv6s as I can reasonably use, doesn't oversubscribe its upsteam connectivity etc.
For home internet service I would prefer to pay extra for a better service, it's too important to try to penny-pinch 0.1% of my income on it.
But then I live in a capitalist country where there's competition, I believe some countries you don't get a choice.
FYI it's practically impossible not to oversubscribe your upstream connectivity unless they either spend way too much money or offer very slow service to users. Consider ten thousand users with 1G connections - should they have 10 terabit upstream?
The more practical thing to look for is that they aim to upgrade it based on need, instead of arbitrarily throttling the users.
That’s why my home network is IPv6 only. NAT64 and DNS64 and 464XLAT work very well, and you only need to configure IPv4 once: in your router, where you need special configuration anyways.
>It was doomed the moment you had to maintain two separate stacks
Pray, tell me, how are we supposed to extend IPv4 with another {insert a number here} bits without creating a new protocol (that neccessitates running two stacks)?
Suppose that you have an old computer that understands only 32 bit addresses -- good ol' IPv4. Let's name it 192.168.10.10.
It then receives a packet from another computer with hypothetical "IPv4+" support, 172.12.10.98.12.4.24.31... ...Wait a minute, it can't, because your old computer understands only 32 bit addresses!
What if we really forced it to receive the packet anyway? It will see that the packet is from 172.12.10.98, because once again, it understands 32 bit addresses only.
It then sends back the reply to... you guessed it, 172.12.10.98. Not 172.12.10.98.12.4.24.31.
Yeah,172.12.10.98.12.4.24.31 will never get its reply back.
Do you see why any "IPv4 with extra octets" proposal are doomed to begin with now?
It wouldn't be able to receive it. That simple. Which is not a problem, any server would still have an old ipv4 address (172.12.10.98 from your example), like they currently do and probably will for decades.
Having just optional field in the ipv4 header with extra address bits would leave all the stack source code with just some 100 lines of extra code. Would mean, you can have one stack that handles just both. Make special addresses where the additional bits are all 0, which means the field is not there at all. These addresses could reach ipv4 only addresses and could be reached from them.
When you really want to make sure these devices aren't parsing ipv4+ packets, change the checksum-code for all packages that contain the optional field. That would mean all ipv4 only devices would ignore ipv4+ packages. Instead you could change the version to 5 for all with optional address bits.
This is stuff that could be implemented in any ipv4 stack in some days of work.
IPv6 is overengineered, thats the reason why it's not adopted after 30 years.
I remember 10+ years ago we were going to run out of IPv4 addresses and it was the next Y2K unless you adopted IPv6. I was able to get IPv6 for my servers and home, and I thought I was safe!
> "In fact, IPv4's continued viability is largely because IPv6 absorbed that growth pressure elsewhere – particularly in mobile, broadband, and cloud environments," he added. "In that sense, IPv6 succeeded where it was needed most, and must be regarded as a success."
Apparently it turns out IPv6 wasn't for me any way!
It kind of has. The majority of internet traffic is IPv6. The three biggest internet hub regions (USA, Europe, China) have IPv6 mandates. Most apps support IPv6. Google and Apple force them to, od they get kicked off the app store. Almost all mobile networks (which means almost all end devices) are IPv6-only, with slow inefficient tunneling for IPv4. The price of IPv4 addresses is declining.
At what point will we be allowed to say IPv6 hasn't failed? When the IPv4 internet finally switches off for good? It feels like no achievement is high enough for those who don't like IPv6 to change their minds. I would've thought making up 50% of internet traffic and 50% of end devices being on IPv6-only networks would be good Schelling points, but evidently they're not!
> At what point will we be allowed to say IPv6 hasn't failed?
"IPv6 ... still hasn't taken over the world [after thirty years of deployment]." is a very different statement than "IPv6 has failed.".
Noone who has successfully extracted their head from their ass says that IPv6 has failed. It's widely deployed on the Internet, and on who knows how many corporate intranets and SOHO/home LANs.
IMO, it's stupid to ever consider turning off IPv4. There surely exist useful systems out there that will never be updated to work with IPv6.
I see IPv6 as an "IPv4 address pressure relief system". In the future, SOHO/home LANs can run servers on IPv6, datacenters can run servers mostly on IPv6 but also v4 if they really want, and SOHO/home networks can be behind an IPv4 CGN because all of their unsolicited inbound traffic will come over IPv6.
>IPv6 ... still hasn't taken over the world [after thirty years of deployment]." is a very different statement than "IPv6 has failed.".
It's incredibly likely that the GP was referring to comments in this thread, which were indeed claiming that IPv6 has failed, despite the fact that its deployment has been steadily climbing up worldwide.
By the way...
>In the future, SOHO/home LANs can run servers on IPv6
The future is now. My web server is IPv6 only precisely due to the same reason you mentioned: my ISP has put me under a CGNAT. People can still connect to my website through the Cloudflare reverse proxy though (which I have only enabled for IPv4, IPv6 users get to enjoy direct connection).
I've been native IPv6 at home for a few years now. That worked flawlessly until a recent Windows 11 update somehow broke IPv6 in ways that I don't entirely understand. All the other Linux and Apple and et cetera things in my house are fine, but the Win11 laptop just refuses to handle certain IPv6 ranges (specifically including the address that the host interface for one of my web servers falls in). 100% contained within the Win11 device and TBH I can't be bothered to dig into it further so I just proxy through some other device that does work. (Guessing it'll get fixed a month/year/decade or so from now.)
I agree it's not a failure, but after 3 decades it's still frustratingly annoying to use at times.
Maybe a different take, but as someone that manages a large public API that allows anonymous access, IPv6 has been a nightmare to try and enforce rate limits on. We've found different ISPs assign IPv6 addresses differently - some give a /64 to every server, some give /64 to an entire data center. It seems there is no standard and everyone just makes up what they think will work. This puts us in an awkward place where we need abuse protections, but have to invest into more complicated solutions that were needed for IPv4. Or we give up and just say if you want to use IPv6, you have to authenticate.
Does anyone have any success stories from the server side handling a situation like this? Looks like cloudflare switched to some kind of custom dynamic rate limiting based on like addresses, but it's unrealistic to expect everyone to be able to do such a thing.
The ISPs assigning only /64s to whole data centers are not following the standards and best practices. For rate limiting I would block at the /64 level. Just like if someone is behind a CG-NAT they might run into ip reputation issues. They need to complain to their carrier about the poor service/configuration or switch providers.
I use multiple Google accounts to segregate the data that gets collected on each one - as I don't like having, say, TV logged in to the same account where I send my emails from. One of them, which I use exclusively for Gemini, was banned today (I violated no policies, Google just doesn't like the way I try to sanitize its access I guess).
Now, I can simply restart my router (or cycle airplane mode on mobile) and get a new IPv4 that probably was used by bazillion people before me, or even along with me, and get a new account. So Google has to be very careful here, with IP-linked bans in order to not just ban the whole load of unconnected people just because they used the same IPv4 as me.
With IPv6, they could just ban my entire family and any guests that might have connected to my WiFi, forever.
Only for the device identifier part of the address. Prefix that the ISP will allocate will remain static, unless ISP does rotate the prefix too, which they don't really have a need to, unless for privacy reasons. And knowing ISPs and demand for privacy, it's highly unlikely to happen.
> Further, user fingerprinting flourishes without IP addresses.
It does, but is still hard to do. Static IP prefix is going to make the heuristics much, much better.
Besides, evading most of the fingerprinting techniques is not that complicated - most of it is in the hands of the client. IPv6 adds something out of the hands of the client.
Yes, it is. But it's not just Google. User fingerprinting is already a massive market and is growingly user hostile. There's at least one HN post each month of someone losing access to their account for no real reason and no way to get it back.
I don't want internet infrastructure to support this behavior. On contrary, I want it to resist it, and IPv4 does, to some extent, while IPv6 makes it much easier.
We replaced VHS with DVDs. It took 42 years before we gave up on VHS. DVDs have been around for 29 years but were mostly replaced with BDs before disappearing off the shelves in favor of streaming.
We replaced records with tapes, tapes with more tapes, and more tapes with CDs before they, too, disappeared from the shelves in favor of streaming. Except that some stalwarts have successfully resurrected vinyl.
We replaced AM with FM, and analog radio with digital radio, then streaming. We replaced broadcast analog TV with digital, then cable and satelite, then streaming. Mostly.
None of these changes were backwards compatible, and all of them were meant for the general public. They took a while. They were successful.
Anyone who bought DVD player immediately had the benefits of better quality. The same applies to all other examples.
The problem with IPv6 is that you don't get benefits. If the designed protocol needs an equivalent of big bang, it's doomed. ASCII->UTF8 didn't need big bang. x86 to Itanium needed big bang.
You'd think it would be long enough for people to realize that v6 is backwards compatible! Yet no, here we are, constantly dealing with people making the same damn claim that it isn't every single time a v6 story is posted.
v6 is about as backwards compatible with v4 as it's possible to be. If you have a way to make it more backwards compatible then I'd love to hear it, but when I ask this all I ever get are things that don't work, or things that v6 already does.
It's often impossible to make backwards-compatible changes to a format which wasn't designed to allow for future changes and which is designed to be as space-efficient as possible.
That doesn't mean that the limits of the old design won't hit anyway and force a switch off it.
The problem is that IPv4 has no provisions to be forward-compatible with anything with a larger address space. Thus whatever replacement you can think of will have the same problems as IPv6.
I was in college when v6 was going through the RFC process. In my networking class we had to learn Netware (IPX) and v6, which have both turned out to be equally irrelevant, for different reasons. At this stage, I fully expect to retire having never deployed a single resource using v6.
I'm genuinely wondering if western governments (UK) will start issuing ipv6 addresses out to citizens as their digital id so they can track them online and offline.
Only half joking, some UK MPs might actually consider this a reasonable thing considering how many ipv6s there are.
Since ipv6 is just a 128-address, you could say any unique national ID is already an assigned ipv6. Heck, if you assign your services a UUID, you have also already assigned them an ipv6.
What makes an ipv6 useful is that you can route to it. Since you will never be connected to the network. The network will never be able to route packets to you, making the whole thing a little pointless.
We're not routable yet. Fairly certain people are trying to create computer/brain interfaces...
I'm thinking the gov issuing you an ipv6 address that you must use to connect to the internet. But it's also you're id too, since nearly all services are either online or getting pushed that way.
Contrary to some other comments: no, IPV6 hasn't taken over the world at all.
In my case, I administrate a small server at home, where I self host many services that are made available to myself, friends and families, over the internet.
In that context, IPv6, is SADLY (please note that I have NOTHING against IPv6), a limitation, even a nightmare to use.
Some programs do not handle IPv6 at all. Game servers for instance, do not support it, the one that I think about is: Arma 3. But there are many others
In 2025 (and 2026 too?), 4G (5G?) operators do not all route over IPv6 -> which means that if your domain only has a AAAA record, some people using 4G will not be able to access ANY of your services. This issue forced me to beg my ISP to obtain an IPv4 "fullstack" as they call it.
Without that IPv4 you have to go through some kind of tunneling (like Cloudflare) -> and guess what? Cloudflare sometimes crashes (it happened super recently remember?) and in that situation -> ALL your services accessible through the tunnel are "down" for your users. Plus, it is EXTREMELY unsatisfying to rely on an external private-owned service for a selfhosting project.
In almost ALL context IPv6 is seen as optional, additional, additional configuration and is NEVER the default. NEVER. Which means: more configuration, possibly more struggle.
>ALL your services accessible through the tunnel are "down" for your users
Not all.
I operate site with IPv6 only origins behind cloudflare.
During the outage I manged to login to the dashboard after some time and remove cloudflare for nearly 2 hours, and traffic level stayed close to 50% during the IPv6 only period.
Nobody complained: those who did not have working IPv6 probably blamed it on cloudflare.
> traffic level stayed close to 50% during the IPv6 only period.
> Nobody complained: those who did not have working IPv6 probably blamed it on cloudflare.
You described a situation where the outage resulted in 50% of your customers were unable to reach you and you were unable to do anything about it. I don’t think this story is a win for IPv6, regardless of whether your customers blame CloudFlare or not.
> In almost ALL context IPv6 is seen as optional, additional, additional configuration and is NEVER the default.
Weird. The past two ISPs I've had (Comcast and Monkeybrains) both had IPv6 enabled by default. I've looked at a bunch of SOHO networking gear and IPv6 is on by default. On every Linux and Windows system I've touched in the past ten, fifteen years you have to go significantly out of your way to disable IPv6.
> Some programs do not handle IPv6 at all. Game servers for instance, do not support it...
Depends on the game server. Many I run absolutely do.
Your complaints smell like you tried to run an IPv6-only client network, which would be an absolute nightmare. That's just a stupid thing for a SOHO network (and the networks that serve most corporate client hosts) to do. IPv4-only Internet hosts exist, so it's a no-brainer to provide IPv4 connectivity to clients.
On the other hand, running IPv6-only infrastructure networks can make a ton of sense. One very large such operator is Comcast, a US ISP.
Most 4G networks are actually IPv6-only, with IPv4 traffic being routed through inefficient tunnel systems. This is why Apple and Google require all mobile apps to use IPv6.
I have fiber to my house and no native IPv6 support. I did some research and it seems there is a way to enable IPv6, but it’s janky and just tunnels over IPv4 so what’s the point?
I would love for IPv6 to actually take off but somehow it feels like we are still a decade away from ubiquitous adoption.
I have Verizon Fios and after they upgraded my network speed from 1G to 2.5G and ONT to some "next gen" one I lost IPv6 support because supposedly this newer ONT does not support it, lol. Verizon is going backwards.
idk if arma3 does server discovery, but in case of manual ip input there some kind of OS-networking-level adapter should help. Usecase seems too obvious for something like that not to exist
Next year that chart will finally cross 50%. It was a mere 30% in 2030. Developing country mobile phone networks will continue to push it higher.
All we need to do is start having rich governments mandate IPv6, and also mandate IPv4 downtime as a punishment for those that don't comply / chaos engineering for the system as a whole. Then we can quickly finish the job.
I can't help but think that numbering all the devices was the wrong idea from the beginning. You don't want to talk to devices, you want to talk to (and offer) services. You probably need something like an AS number to make global routing efficient, but 32 bits would be plenty for that. A packet could be (destination AS, stream ID, encrypted( payload )) and DNS would give you a capability (destination AS, stream ID, keys) for a service. You send a packet to that stream asking to open a connection and providing a capability to reply (with a capability for the specific stream). Your network up to the AS level should have an opportunity to augment the stream IDs in whatever way is convenient for its routing. No one reveals any topology information, network neutrality and a degree of privacy is guaranteed at the protocol level, only really serious multipeer networks need to assign addresses above layer 2, and I think it would be reasonably easy to come up with an edges first incentive compatible transition plan (which is where ipv6 went wrong).
(This is of course an incomplete and poorly thought out proposal, you don't need to dogpile me about that.)
Correct me if I'm wrong, doesn't it make you leak your IP outside local network? I'd say this is a great turn off especially nowadays when it will be used for sure for tracking
I'm not sure what you mean by "leak your IP" since IP address is always how you communicate. I guess you mean you no longer have a 192.168 or a 10. address that is "hidden" from the Internet for whatever value that has? One nice thing about IPv6 is your local client can continually change their address if they so want (and this is actually a common feature) to disrupt tracking. Sure you have the same prefix, but that's exactly the same boat you were in with IPv4 and NAT.
So this 'feature' is just a fix for the issue with tracking that would not be there with ipv4 beside that my internal ip's are changing every day to bring more confusion into my internal net. nice!
Nothing have given me more issues than ipv6. Every time I've tried to use it, it gives me so much headache I just give up. I'm not even sure my ISP supports it. My router doesn't get an ipv6, and called my IPS. After going through 3 different people over 2 hours I just gave up. I just hope I get put behind CGNAT...
IPv6 continues to rumble along, gaining market share, because China. Increasing IPv6 adoption was in the 14th Five Year Plan, and about 75% of mobile in China is now IPv6.
I started looking at self-hosting many applications at home once I realized that IPv6 could enable me to do that securely without any complicated router/firewall configuration that would need to be maintained.
The only wrinkle I ran into is that apparently ISPs are still reluctant to give out static IPv6 prefixes to residential customers. So you still need some kind of DDNS setup, which is lame.
IPv6 is already here if you're not in the US. I moved house last month and consumer ISPs don't offer a (real) IPv4 connection in my country any more; you get an IPv6 connection and your router does MAP-E if you want to send data over IPv4.
I want to echo this comment. I am on Map-e in Asia and it is very difficult to get an exclusive ipv4 address without paying extra money.
And I want to connect to my machines without some stupid vpn or crappy cloud reverse tunneling service. Not everyone in the world wants to subscribe to some stupid SaaS service just to get functionality that comes by default with ipv6.
I think Silicon Valley is in a thought bubble and for people there ipv4 is plentiful and cheap. So good for them. However, the more these SaaS services delay ipv6 support, the more I pray to any deity out there I can move off these services permanently.
Yesterday I was required to turn on IPv6 on my router, while setting up some IoT things using Matter over Thread. Apparently that protocol uses IPv6 and doesn't work if your router is only routing IPv4.
There is a rich history of IoT devices using IPv6 to communicate among themselves without relying on the cloud. I think Nest started this trend. One Nest device sends a specific RA to make itself the router of all other Nest devices. All other devices can configure themselves thanks to SLAAC. The benefit of v6 is that there are so many addresses out there that the Nest device can just pick an arbitrary ULA and there won’t be collisions.
Don’t know about Matter though. If it requires the user to turn on IPv6 then it’s a user experience downgrade. It should just use IPv6 internally as an implementation detail.
That's incorrect. Matter-over-Thread absolutely does NOT require IPv6 on your router. Even Matter-over-WiFi will happily work in IPv4-only networks, as long as your router does not filter the IPv6 announcements.
Some routers can work as _relays_ between the Thread network and WiFi, but this is entirely optional.
Not really. DJB’s clearly a very, very smart person, but he missed the mark on almost all of that. The problems he described which are real have been satisfactorily solved; they weren’t intractable. The rest turned out to be non-issues.
Also, his proposed alternative solution (essentially expecting someone to change all software and hardware in the world first, and then have a flag day with zero operational experience) was completely non-workable. Well, actually the document is so vague that you could interpret his “solution” in like three additional different ways, but none of them make much sense.
Intriguing take that he "missed the mark", yet we are still utterly dependant and reliant on IPv4 30 years later since v6, the situation he essentially predicted. How much longer until IPv6 becomes the incumbent?
IMO we need to rethink routing for IPv6 so we can finally reduce pressure on router tables and finally cause pressure to ditch IPv4. Here are some of my thoughts on that elsewhere in this thread: https://news.ycombinator.com/item?id=46471898
But here's a more thought-out design:
- register a well-known IPv6 prefix with 20 bits reserved for AS number
- so we'd have ${well_known_prefix}:${AS_number}:${customer_prefix}:${end_entity} (not necessarily that format for display, but just for the purpose of getting the idea across here)
- have DNS servers return AAAA RRs with the AS number filled in
- DNS servers should either have the correct AS numbers filled in their zones, or possibly could subscribe to the RPKI and use the RPKI for mapping ${well_known_prefix}:${all_zero_AS}:${customer_prefix}:* to AS numbers, then fill them in (this would require live signing if using DNSSEC, which is f-i-n-e fine)
- if there are multiple AS numbers for a $customer_prefix, then return multiple AAAA RRs, or if EDNS0 indicates client support for it, one AAAA RR and N RRs of a new type that carry only the AS numbers
- update core routers to route these prefixes based on the AS number in the address
- update edge routers to replace the sender's AS number in its address if its address is below the $well_known_prefix -- this takes care of the return path
- update internal routers to use only the $customer_prefix and the $end_entity for routing for this $well_known_prefix
- end entities should ignore the AS number when receiving packets, thus allowing multi-homing (i.e., let source and destination IPv6 addresses match ${well_known_prefix}:*:${customer_prefix}:${end_entity} for socket 5-tuples)
- for backwards compatibility end entities should map these addresses back to whatever the application used in its calls to bind() and connect() (i.e., if the app found an AAAA with the AS number filled in and used it for connect(), but the ${customer_prefix} is multi-homed, then accept packets from all those homes) (apps should make sure to use TLS / QUIC for security, naturally)
- when an end-entity sees a change in AS number for a peer's address matching a socket 5-tuple then update the peer's AS number / address in the 5-tuple -- this allows for migration and better path finding
I think something like this could be deployed with relatively little effort.
802.1x instead of switch ACLs
SSSD (Linux) or Active Directory (Windows) or other more custom solutions for dynamic DNS
Firewalls rules that use those dynamic DNS names
Dynamic DNS, DHCP, and static assignment are all still part of IPv6. Putting single IPs in switch ACLs is an anti pattern. Consider zero trust or working with whole subnets(they're plentiful in v6) instead.
How many people here have put IPv6 addresses into the root DNS servers for their glue records? Curious how this [1] set of charts has evolved. For some reason I have only ever used IPv4 root glue records and never really gave it much thought otherwise.
This gaslighting keeps being repeated, but fact of the matter is that any consumer/home network will be exposed to the internet if they're using SOHO equipment via IPv6 and won't be via IPv4.
And huge % of SOHO routers won't even allow configuring IPv6 firewall which makes security a disaster.
IPv6 was obsolete by the mid-2000s, majorly due to the advent of roaming. It was designed on the rather fanciful assumption that its deployment would simply supersede IPv4, that every software/hardware vendor would cooperate, and we'd have a pure v6 network which would also replace the traditional L2/L3 layers.
Ofcourse legacy compatibility trumps all, along with the ubiquity of NATs and roaming and we're now just in the sunk-cost phase, being left saddled with a horribly bloated protocol (128-bit addresses was a marketing choice; not engineering) that solves no problems.
I love IPv6 but organizations seem to struggle with it. My ISP, for example, had issues routing it after a backend update so they decided to just turn it off. I'm now stuck on CGNAT IPv4 which results in constant captchas :/
Meanwhile, there is a whole grey market built around this. People sell “CGNAT mobile proxies” that ride on carrier and ISP NAT, and the whole point is that they are a pain to block without nuking huge ISP ranges. So they get marketed as a convenient way to dodge shadowbans, spam filters, and basically any abuse defense that relies on IP reputation.
It would be nice if we had a blackout CGNAT day where a bunch of major sites don't serve traffic to people behind CGNAT to give the ISPs a bit of a scare.
For anyone who thinks IPv6 is without merit, I recommend reading up on the various challenges of NAT traversal [1]. In cases where CGNAT is deployed in particular, there are scenarios where the only way to make everyday P2P connections work is to route traffic through a 3rd party - which can impact latency and bandwidth.
While IPv6 doesn’t make establishing a P2P connection trivial (there are still firewalls to contend with) - it does simplify things dramatically. And as someone who is behind CGNAT, I am very grateful for the existence of IPv6.
This is already a thing in IPv6 pretty much.
You can write applications IPv6-only and support IPv4 via IPv4-mapped addresses (::ffff:1.2.3.4 for the IPv4 1.2.3.4). The host still needs to be dualstacked for that to work though.
In case the host is IPv6-only you can use NAT64 (or similar technologies), where the IPv4-space is embedded behind some other prefix, but the application just talks plain IPv6 and doesn't have to care too much what happens in the background.
I’ve asked both ChatGPT and other users and the consensus is “NO YOU CAN’T BECAUSE YOU’D HAVE TO REWRITE THE SOFTWARE”
As if IPv6 doesn’t require a full rewrite too. So basically, no there’s no reason. They just wanted to be edgy and use hexadecimal and they’ve ruined everything.
It's hard to believe there are people that think letters in an IP have a meaningful impact.
"edgy"? Come on.
And if they used decimal I bet the complaints they didn't use hex would be just as loud and just as certain, since an IP address in dotted decimal is 50% longer than in hex.
On top of that, hex would make IPv4 a lot easier to use because of how subnets get optimized. Instead of constantly rounding to weird multiples of 8 or 16 or 32 you'd only have to deal with one hex digit at a time. And in most deployments you could skip the address math entirely by sizing your subnets 4 bits at a time: /16, /20, /24, /28.
That's in there. ::ffff:0:0/96 and 2002::/16 are for v4 addresses in different circumstances, but that doesn't address the issue of routing so there are capabilities like NAT64 that allow network operators to map their IPv4 networks via routers and it mostly works. There were exceptions, software that cares about lower level network functionality tend to break.
NAT64 works much better for 6->4 connection scenarios than vice versa, but 4->6 with specific connection pairs and careful split DNS is possible.
IPv6 is the poster child for the second system effect (or solution) [1].
IPv4 really only had 3 problems that anybody cared about:
1. Address space size;
2. Roaming; and
3. Reliable connectionless delivery; and
4. The problems created by the at most once delivery under TCP when what we really needed was at least once delivery in many, many cases.
Even the address space size problem is less of an issue than originally predicted because of improvements in NAT, up to and including cgNAT for cellular network providers (which also somewhat addressed (2) in a limited way).
Interestingly, some of the larger companies have networks simply too large for the 10.0.0.0/8 address space.
By "roaming" I mean maintaining a consistent connection while moving between networks.
(4) has kinda fallen on QUIC (now HTTP3) but this should really be core TCP/IP Layer 3.
You could also say that TCP congestion control is pretty outdated. It's not surprising. It was designed at a time before megabit (let alone gigabit) networks. And, more importantly, latency kills throughput. Some efforts have been made on this, such as Google's BBR [2], but other problems remain like MTU windows being too small for modern networks.
So what did IPv6 do? It only solved one problem, address space, and it did it in a way that kinda created new problems. First, the address space is too large (128 bits) and the last 64 bits are kinda reserved for the job that a 16 port used to do. And why was that? Originally, it was intended that the lower 64 bits were derived from a 48 bit MAC address (as used by Ethernet and later Wifi) but they realized this was a huge privacy problem so it never happened.
Not a counter-point, but: the other day I rebuilt my personal server, finishing by pointing the reserved IP at the new box. I then had a period of confusion because I was still seeing old content, because my browser (etc) was obviously querying the AAA record first, which I hadn't updated.
(a while ago I needed to contact support to get an IPv6 allocation at home, but that was a very quick interaction at the time)
and it never will, because IPv4 has become a defacto reputation system for the exact same reason that IPv6 was created: a limited supply. It wouldn't surprise me to see the continued balkanization of the internet that there is a particular underclass of exclusively IPv6 traffic, but its not going to take over everything because once decentralized systems are now in the hands of a few decisionmakers in the case of, say, email.
IPv6 seems to be a great fit for 1) mobile devices, 2) massive data centers and 3) literally nothing else.
I have met zero network engineers who wanted to put IP version 6 in their network. It causes all sorts of problems and presents all sorts of security risks without much benefit other than the obvious one. In the data center, NAT is a feature, not a bug.
Instead, they provision IPv6-enabled load balancers and pass traffic back to load bearing servers using ipv4 instead.
It's a classic example of "this is the next best thing everyone should use it" which achieves some adoption but it's not really the next best thing. It's not the be all end all it purports to be.
We should just admit to ourselves that we need one kind of ip stack in some situations and another in another.
20 years ago there were a lot of peer to peer applications. For example, Skype used to bounce calls across peers. Now, all calls gets routed through big-brother Microsoft.
NAT and American assymmetric bandwidth ISPs both killed this business model and now we are stuck with tech monopolies like Cloudflare. I see this ipv4-only strategy as another monopoly tactic to kill competition.
And in Asia, it is getting more difficult not to get stuffed behind a double NAT (CGNAT), which means you can't even play games without using big-brother rent-seeker services (no port-forwarding/upnp). But at least here you get ipv6 for free and everything just works.
My gut is that this is for the best; I haven't fully fleshed it out but it feels like the practical goal of "decentralizing power" and e.g. ISPs and other powerful entities exploiting end users is easier in an IPv6 regime, and has been practically thwarted somewhat by IPv4.
I'm reminded of way back in the day when they wanted charge per user or per device in households.
Simple reason it didn't take over: the lack of backwards compatibility with ipv4. Yes, it would have marred the beauty of the new specification. But we will continue paying the price for another 30 years.
I'd love to have ipv6. The idea every device in my network can have its own unique worldwide address is awesome.
Having said that I still want to have a router with routing rules and firewalls and a network range I can divide into separate protected networks but in reality your home ISP will most likely give you a router with a /64 address.
You're aware of DHCPv6 Prefix Delegation? The two US-based ISPs I've used in the past ~twenty years (Comcast and Monkeybrains) use it to provide IPv6 service and permit your DHCPv6 client to request a /60 prefix to use as you see fit. It's not a /56, but it's also very much not a /64.
I'd expect "Give home users a /60 via DHCPv6-PD" to be considered "best current practice" in the ISP "community"... so if I switched to another ISP that claimed to provide IPv6 addresses, "ask for a PD-assigned /60" would be the first thing I'd try.
IPv6-only is the future for mobile phones, and mobile devices are the future of the internet.
And it is consumer devices (and IoT devices) which are the most numerous and also the most price sensitive, and this is where IPv4 is disappearing first.
I think this is the same as : we are a big company that does banking and payment processing for decades. We were planning to switch to golang/rust/C/python whatever for a long time but we still use age old java that has been patched several times with known security risks and no longer supported. Unless we have a huge problem we don’t see the need to fix something that is broken but not fallen apart yet.
* (S|D)NAT are not first class citizen in IPV6 Standards and Implementation
* there's no mapping of the IPv4 Adresspace into the v6 space, so people can reroute stuff which is needed.
because only then, we can
a) migrate
b) rebuild the same structures.
> as long as [...] (S|D)NAT are not first class citizen in IPV6 Standards and Implementation
Yeah, I mostly agree... IMO, a ULA (equivalent to RFC1918, so 192.168.x.x and so forth) is the only sane way to set up your IPv6 network at home, unless you're one of the wizards who owns their own prefix. Dynamic prefix delegation just breaks too many things when the prefix changes, and I really wish NPTv6 was more supported and ubiquitous, because it solves the problem in the most elegant way IMO.
> there's no mapping of the IPv4 Adresspace into the v6 space
You don't need NPTv6 to use ULA. Just use both ULA and the dynamic prefix from your ISP. The latter is handled automatically by DHCPv6-PD, and if you're only using it for outbound connections then it changing isn't going to break anything.
I'd say this is actually elegant, compared to NPTv6 which is a kludge and will break things (and isn't well-supported anyway).
I was expecting Google's IPv6 availability monitor[1] to show a crossover to a (slim) majority of their users accessing their services over IPv6 sometime soon, though it's sort of fascinating how close it gets to 50% recently without ever actually crossing over:
It's reaching around 50% adoption according to Google stats? Steady growth, though still annoyingly slow. It will need a few more decades at this rate.
My criteria for success, which is the goals that were set forth for IPng was to no longer depend or rely on IP. It didn't even achieve the goal of averting the issue of impending address exhaustion.
It’s all fun and games until your ISP changes your prefix and breaks all your firewall/routing rules. I tried to adopt IP6 with Spectrum internet, but every time the cable modem reboots, my prefix changes and breaks everything. No thanks.
I still don't have IPv6 at home in the middle of San Francisco with Google Fiber / Webpass and have to egress through an HE.net tunnel like it's 2002 again
I run an IPv6 only VPS as a side project to keep an eye on what doesn't work. My most recent discovery: I tried moving from `lego` to the new native ACME `nginx` support. `nginx` refuses to talk to letsencrypt on IPv6; it's not a letsencrypt flaw because it works perfectly on the same server with `lego`.
I have noticed that on my last Windows computer (Windows 10) and my current computer (Windows 11) IPv6 works great for a little while after a reboot, but then just seems to die. I have my house and all internal automation configured for IPv6 first and its great on all my Linux computers and phones.
If I need to connect to my home Fedora machine from work, a simple "ssh fed.nono.io" works just fine — I don't need to activate my Wireguard VPN; I don't need to worry about address space collisions.
That is because your provider is nice and gives you a static pre-fix. Around here, all the providers give dynamic IPv6 pre-fixes to prevent people from running servers. This is partially why some see Ipv6 as a advantage, and others see it as nothing but trouble. We still have the whole Ipv4 CGNAT disadvantage, with the added complexity of Ipv6 on top.
IPv6 is an inequality issue. Far too many luddites refuse to learn it because IPv4 works well enough for them. I think it would be a totally different story if the majority of US/European people ended up with CGNAT.
It is so disappointing to have people who allegedly work with networks and technology act like IPv6 is too much for their delicate sensibilities. From thinking it is more complex than IPv4 (it is in fact simpler), to thinking that NAT is a security measure (the firewall is and routers have an IPv6 firewall on by default), to thinking there are no benefits (the benefits are clearly there), to thinking nobody uses it (loads of mobile devices access the web via IPv6 and lots of enterprise networks are IPv6), and so on, it is anti-curiosity and anti-hacker ethos. Go ask your favorite LLM how it works if you can’t be bothered to Google it but if you start your comment with “it has no use cases” or “it is too complicated” you are just outing yourself as ignorant on this subject.
IPv4 should have been converted directly to IPv6. Every IPv4 address should have been given an equivalent IPv6 address. 192.168.1.1 becomes 2001:00C0:00A8:0000:0000:0000:0001:0001 or 2001:00C0:00A8::0001:0001.
The reason being? IP proxy gateways. They obviated the need to move away from the limited address space of IPv4. Which was 90% of the reason to do IPv6.
It's not a failure of IP6 but a failure of society.
We all thought the internet would become decentralized and that everyone should have an IP and a funky website. But instead social media took over, big tech and a few big discussion sites where we all must fit in a digital life and watch ads and share our data to become a good product for all the others to consume.
people don't understand how expensive it is to support ipv6, tcam is limited and having to split it in half to support ipv6 is just not an option for a lot of businesses. Route caches exist with software routing - but for larger networks it is not an option
I'm sure someone will fuck this up for us, but IPv6 should at least in theory enable us to be rid of NAT. Anyone who has ever done NAT traversal for peer discovery is having wet dreams about that future!
I will fully and honestly admit I don't understand much about IPv6 - however, I have a question - why didn't they just add 8-32 bits to IPv4 and call it a day?
Legacy IPv4 would be trivial to support via NAT, and we wouldn't have to deal with address shortages either globally or locally. I'm sure every sysadmin/cloud person dealt with having to arrange subnets by hand, or the fallout when you just ran out of addresses and had to tear down multiple layers of routing just to make more address space.
Computers default to 64 bit integers, I don't see why this couldn't be done on the network.
Because there isn't "empty space" in the IPv4 packet header (or even the pseudoheader format from which TCP or UDP checksums etc are derived) to expand your new bits into. By breaking the packet format, you just invented a new network protocol that all of the routers, firewalls and middleware of the world don't know how to handle.
Yes, it’s true that any change they made would be incompatible with the existing software and routers and such. But nowadays everything can handle IPv6 just fine. All the upgrades and new software came out between 20 and 30 years ago, and is ubiquitous now.
They pretty much did. "Just add N bits to v4" is far more work than you're thinking it is, and most of what v6 does is a direct consequence of taking v4 and adding more bits to it.
The amount of work doesn't depend on the number of bits either, so adding fewer bits is a false economy. Deploying a new version of IP is so hard that you only want to be doing it once, not once every time you need an extra few bits.
the other day I had to change my node server to prefer ipv4 dns records because fly.io doesn’t support outbound ipv6 connections but defaults to a dns server that returns them
Meh. IPv4 is used to deliver Netflix to the masses and act as a tunnel for your IPv6 network. It's not how I would have set things up, but since content delivery is the primary use case for most ISPs, they're unlikely to support v6. Contrary to the "Comcast is shit" narrative, I had a GREAT experience a couple living situations ago where I got dual stack from Comcast. It just sort of worked out of the gate and whenever I had to call the support line, I was immediately transferred to someone who knew what they were talking about because I had this exotic / non-standard service.
It's sort of interesting dude says Security and Plug-and-Play weren't available in v6 since SLAAC and IPSec are mandatory parts of the spec. But sure, AH and ESP options are never as simple as they should have been and it's not impossible to pick options for your organization that don't match what a remote organization supports. I still prefer it to the crap-shoot that is TLS ChangeCipherSpec. (Though 1.2 and 1.3 aren't as bad as the old days.)
Contrary to the narrative about your parents not being able to cope with anything technical, my mom was able to configure her mac to speak to the family VPN with no problem. Of course, my mom taught me code in Lisp in the 70s and used a Sun 3/60 as her daily driver in the late 80s, so maybe that's not the best example.
Sure. V6 didn't take over the world, but neither did SNA or IPX/SPX, though I would argue v6 is MUCH more common these days than either IBM or Novell protocols. V6 is used in the corner of the internet by people who want to use V6. Maybe there's a "those who know don't tell, those who tell don't know" narrative here. I've sort of stopped evangelizing. If the main thing you worry about is watching Netflix, MMORPGing and commenting on Reddit, you don't need V6 and it does require a different bit of knowledge than setting up V4.
In my country, the last big _mobile_ internet provider finished its move to IPv6.
Land lines internet have been IPv6 for more than a decade.
While developping custom IPv6 internet software I am not blocked by NAT anymore, real p2p fiesta, everything works as intended.
The real challenge now is IPv6 with fixed mobile internet address (not random as it is is now, it should be device uniq). That to replace for good the phone numbers (the challenge of international roaming... which is already done for phone numbers). The idea would be to avoid a third party centralized internet account->ipv6 mapping.
Every few months I turn on IPv6 at my house. I try to use it. I find random sites just not working, random delays accessing sites, and so on. Then I switch back to IPv4 and everything works.
I used to be a network admin, so I know how to configure networks. IPv6 zealots accuse me of incorrect config, doing it wrong, etc. Maybe that is the case, but if I, a sophisticated user, can't get it working well, what chance does a non-technical person have?
My assumption is they just deal with the issues and chalk it up to "technology sucks". But I know better. I've experienced the internet when it works, and I know when it isn't working right.
I think IPv6 is better in theory, and I look forward to the day that it is in practice. But today is not that day.
I suspect you forgot to implement a workaround for servers with broken pMTUd. The quickest test for that is probably to run `ip link set mtu 1280 dev eth0` on a client machine and see if it helps.
You'll encounter the same problem on v4, where it's just as difficult to fix as it is on v6. Why single out the latter?
> "IPv6 wasn't about turning IPv4 off, but about ensuring the internet could continue to grow without breaking,"
Then it's failure is by design. I should not want to multiplex/bridge different versions of the network-layer protocol; and certainly not to avoid using the new protocol because the old one seems more usable and approachable.
My "conspiracy theory" is IPv6's point to point connectivity is inconvenient to anyone except end users. And, rent-seekers can't extract money if the ranges aren't limited. American mind can't comprehend not rent-seeking any new invention.
IPv4 "works" and ISPs are incredibly resistant to changing things that "work".
Because support is needed basically end to end, it's going to take an ungodly amount of time for ISPs to figure this stuff out.
It's pretty frustrating having all my hardware support v6 with the only barrier being my ISP who refuses to support it in my location (they support it in other locations).
What's up with those comments? Am I still on HackerNews or did I visit Reddit with some HackerNews theme applied?
Internet engineers pre-2000 had some idealistic, heavly mathematically proven ideas that still seem revolutionary today. Due to human nature, not everything got through, but IPv6 is the best of what we have and creating another standard would be XKCD 927.
Under every IPv6 discussion people all of sudden have the urge to manually assign numbers, need to remember their cousin's phone IP and MAC address, forget firewalls exists, argue that ISP fiddling with TCP+UDP selling it as "Internet" is a good thing or that "sender" field on the envelope is a huge privacy issue.
Because NAT and VPNs are a permanent temporary fix. Before you get a global flat Internet, you have to make NAT illegal just like we did with VPNs. Good luck with that.
I spent an excruciating 3 months or so learning about IPV6 in a college networking class circa 1994 so that I could be "current" in order to land a job right out of college.
Dual stack is a hack and binding to an interface like localhost or a single interface does not support dual stack . So your L6 code has to be modified and re tested to support L3 changes .
Even if ipv6 was just as simple , the cost of rebuild , retest and re-deploy is enough of a barrier against migration
Dual stack is a natural part of migrating between two protocols, because it's the most compatible way of handling both of them. You don't need to use dual stack to use both v4 and v6, but you'll probably choose to the instant you hit even the most minor incompatibility.
Your L6 code should work perfectly fine if you wrote it properly in the first place. If you pass "localhost" to getaddrinfo() with flags=AI_PASSIVE, it returns a list of socket addresses to listen on, and all you need to do is pass those to socket(). You don't need to look inside the sockaddrs and they might as well be opaque data to you, so it doesn't matter what L3 protocol they represent.
I agree in theory, but doing so would have been very difficult practically. The IPv4 header structure is very rigid, and it wouldn't have been possible to just add more bits to the src/dst fields without breaking things.
The only reasonable route I've seen would have been to add an "area code" or "country code" to the Options fields and have huge border routers to translate packets between different locales. It would have solved one problem, only by creating an arguably much worse one.
Sure, but there was also no need to reinvent address assignment, routing and bunch of other stuff that now causes a massive headache due to mismatch of architectures on dual-stack deployments.
It was not possible to make a "superset" of IPv4, if only because one of the early major blockers was that BSD Sockets suck by leaking low-level details of addressing so you'd have exactly the same argument of "why should I bother writing entire second copy of connection code in my application" for any superset you want to imagine.
Similarly, we have 30 years of experience that vendors will happily break optional headers or flags.
I don't think this is how it would have played out at all.
I'm no expert on IPv4 or IPv6, but if they had designed IPv6 to be able to route fine to IPv4, we'd be OK.
It would at least give people an upgrade path where their old stuff that couldn't be patched / updated and were stuck on IPv4 could be slowly killed off in the path of least resistance down the dependency line.
This 'dual stack' approach doubled up on everything up front and meant we all had to do both during the transition (which has taken 30 years).
I have yet to encounter a situation where I _NEED_ IPv6, or there's a very substantial benefit of using IPv6 over IPv4 beyond just "academic arguments on the internet".
And I work with IP networks all the time, as well as run LAN Parties as a business. You'd think I would have encountered at least ONE reason to give a crap about IPv6 by now.
But nope, not one reason.
IPv4 gets work done. IPv6 is just a topic that we can wax poetic about, but nothing else.
> It failed to solve the problem of impending IP address depletion
I wouldn't say so. Some mobile carriers and big data centers have used IPv6 to pretty much completely solve the problem of being able to assign a unique address to devices.
For mobile devices, moving 50% of traffic over to IPv6 means buying half as many CGNAT/v6-to-v4 boxes (of various kinds).
And on the v6-inside, unique address can be assigned. Legal requirement and court orders suck when you get "who had A.A.A.A:32800 at time T?" if you have to go through three levels of NAT to decode that. So even if a customer only accesses IPv4, having their actual handset only be assigned IPv6 makes things easier and cheaper. Even if they share an outside address, there's only one translation so the inside is unique.
For big data companies, it means not needing to solve the problem of running out of 10/8 (yes I'm aware of the other private addresses), and having an address plan problem any time they make an acquisition.
And I've seen large providers who build their whole actual network with IPv6, and only tunnel IPv4 on top of it. Huge savings in complexity and cost of IPv4 addresses.
So what I'm saying is that I've seen first hand in multiple large providers of different kinds how IPv6 is delivering incremental payoff for incremental adoption.
It doesn't have to be 100% before we get ROI.
> it is not a success.
About half of even public traffic on the most complex and distributed system ever built is IPv6.
It's going slower than I'd like, but it's definitely paying off.
There are still ATM and X.25 networks out there, so is IPv4 a failure? (admittedly, a bit hyperbolic)
I'm working on a problem right now at a large company to move a thing from IPv4 to IPv6 because the existing IPv4 solution is running out of addresses, and it's impossible (for multiple reasons) to "just add more IPv4". Can't go into details, sorry.
This is mainly due to mobile devices only being issued ipv6 addresses by the telco 4g networks. They are the only ones using ipv6 on the millions of clients scale.
It’s ok to understand something and disagree with it. It’s another to proudly wear ignorance on one’s sleeve. That’s never a good look.
There’s no way in which IPv6 is less private than IPv4. An ISP issues your house an IPv4 address and an IPv6 /48 network. Both of those can be subpoenaed equally. The privacy extensions work as advertised.
And in reality land, the big companies are the ones pushing for the upgrade because they’re the ones hardest hit by IPv4’s inherent limitations and increasing costs. Same rando in Tampa isn’t leading the charge because it doesn’t affect them much either way.
> There’s no way in which IPv6 is less private than IPv4
With IPv4 behind CGNAT you share an address with hundreds of other users. This won't protect you against a targeted subpoena, but tracking companies typically don't have this kind of power, so they have to resort to other fingerprinting options.
On the other hand, an IPv6 address is effectively a unique, and somewhat persistent, tracking ID, 48/56/64-bit long (ISP dependent), concatenated with some random garbage. And of course every advertiser, every tracking company and their dog know which part is random garbage; you are not going to fool anyone by rotating it with privacy extensions.
Perhaps this is the difference, some people are concerned with being anonymous from companies like google, amazon, etc. Some don't mind that, as long as they are anonymous from a government.
Your mention of subpoena suggests you don't care about google tracking you.
Unless my understanding of how IPv6 is flawed, I don’t think your assertion is true in practice. One of the big benefits to IPv6 is that addresses are plentiful and fairly disposable. Getting a /48 block and configuring a router to assign from the block is pretty straightforward.
I’m aka unsure if IPv4 really gets you the privacy advantages you think it does. Your IP address is a data point, but the contents of your TCP/HTTP traffic, your browser JS runtime, and your ISP are typically the more reliable ways to identify you individually.
You can nat all your ipv6 traffic behind a single IP if you want. Or a new IP for every connection.
Realistically though there's enough fingerprinting in browsers to track you regardless of your public IP and whether it's shared between every device in the house or if you dole out a routable ipv4 to every device.
CG-NAT gives more privacy benefits as you have more devices behind the same IP, but the other means of tracking still tend to work.
For me I just don't see the appeal of supporting both ipv4 and ipv6. It means a larger attack surface. Every year or two I move onto my ipv6 vlan and last a few hours before something doesn't work. I still don't see any benefit to me, the user.
> Realistically though there's enough fingerprinting in browsers to track you regardless of your public IP and whether it's shared between every device in the house or if you dole out a routable ipv4 to every device.
Yes, browser fingerprinting is a big issue, but it can be mitigated. The first thing everyone should do is to use a network-wide DNS blacklist against all known trackers (e.g. https://github.com/hagezi/dns-blocklists) and run uBlock Origin in the browser.
You can go further and restrict third party scripts in uBlock, or even all scripts. This will break at lot of websites, but it is a surefire way to prevent fingerprinting.
IPv6 itself seems to provide a larger attack surface based on IPv6-specific CVEs. I don’t know if it’s the added complexity or that it’s treated as a second class citizen by devs, but I still see a solid number of these coming across the CVE feed.
> Realistically though there's enough fingerprinting in browsers to track you regardless...
Yep. For the OP, IPv6 "Privacy" addresses do what he's looking for. You can change how long they're valid for on Linux, so you can churn through them very frequently if you wish.
> Every year or two I move onto my ipv6 vlan and last a few hours before something doesn't work.
Odd. I've been using IPv6 for like fifteen, twenty years now with no trouble at all. If you've been using a "single stack" IPv6-only network, well, there's your problem.
> For me I just don't see the appeal of supporting both ipv4 and ipv6. It means a larger attack surface.
The attack surface with IPv6 is exactly as large as if each of your LAN hosts had a globally-routable IPv4 address. Thinking otherwise is as smart as thinking that the attack surface on a host increases linearly with the number of autoconfigured IPv6 addresses assigned to that host from the same subnet.
If you don't want the IPv6 hosts on your LAN to be reachable by unsolicited traffic, set the default policy for your router's ip6tables FORWARD chain to DROP, and ACCEPT forwarded packets for ESTABLISHED or RELATED connections. If you're not using ip6tables, do whatever is the equivalent in the firewall software you're using. If you know that you have rules in your FORWARD chain that this change would break, then you already knew that you could simply drop unsolicited traffic in the FORWARD chain.
Unrelated to that, I see no reason to get rid of IPv4.
I expect that the future will be that nearly all "residental" [0] and non-datacenter business connections provide globally-routable IPv6 service and provide IPv4 via CGNAT, as IPv6 will be used for servers deployed at these sorts of sites. [1] I expect that the future will be that all datacenters and "clouds" will provide globally-routable IPv6 to servers and VMs, and globally-routable IPv4 to the same by way of load balancers.
So, home servers [1] will use IPv6, datacenter and "cloud" servers will use IPv4 and IPv6, and "legacy" devices that work fine but will never have their IP software updated will use IPv4.
I see IPv6 as a "reduce the pressure on the IPv4 address pool" mechanism, rather than a "replace IPv4" system. Again, I see no reason to get rid of "short" IP addresses. Default to using "long" ones, and keep the "short" ones around just in case.
[0] I'm including people's personal mobile computers in this definition of "residential".
[1] "Servers" here include things like "listen" video game servers or short-lived servers for file transfers and stuff like that.
It's virtually always used with some firewall rules, so it sort of is? It's just dogma to insist that there are no security benefits to having a single choke point for traffic.
IPv6 addresses are ugly and hard to memorize. IPv4 addresses are pretty and easier to memorize. That's about the end of the discussion as to why it's basically a failure.
I used to like the idea of an IPv4 replacement, but I've come around.
A large number of my devices and websites I visit use IPv6. Its success has highlighted the fact that I don't want it. Just today I disabled IPv6 on my router because I suspect it as a vector for tracking.
IPv6 offers nothing of value to the user. It might as well be shelved forever.
IPv6 means no more NAT. Your home computer can have the same kind of network connection to the rest of the internet as the server at the AWS data center.
ISPs do not want this.
That is all you need to know about why you can’t have IPv6.
I don't use IPv6 because it solves a problem that I don't have and it provides functionality that I don't want. And also because I don't understand it very well.
My points :
- I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.
- Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.
- Stateless auto configuration. What ? No, no, I want my ducks neatly in a row, not wandering about. Again maybe my brain is rotten from years of DHCP usage but yes, I want stateful configuration and I want all devices on my network to automatically use my internal DNS server thank you very much.
- It's hard to remember IPv6 addresses. The prospect of reconfiguring all my router and firewall rules looks rather painful.
- My ISP gives me a /64, what am I supposed to do with that anyways?
- What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.
In short, so far, ignorance is bliss.
> - I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.
What happens when multiple devices in your /8 want to listen on port 80 and 443 on the public address? Only one of them can. Now you're running a proxy.
> - Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.
It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall. NAT is usually configured as part of your firewall, but is not a firewall.
> - Stateless auto configuration. What ? No, no, I want my ducks neatly in a row, not wandering about. Again maybe my brain is rotten from years of DHCP usage but yes, I want stateful configuration and I want all devices on my network to automatically use my internal DNS server thank you very much.
DHCPv6
> - My ISP gives me a /64, what am I supposed to do with that anyways?
What are you supposed to do with a /8? Do you have several million computers?
> - What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.
What happens if your ISP changes your IPv4 address?
Wow. It's like your reply is doing an impression of IPv6! (I'm just teasing. I hope you are having a happy new year.)
Not GP, but:
> What happens when multiple devices in your /8 want to listen on port 80 and 443 on the public address? Only one of them can. Now you're running a proxy.
I don't want any of my devices listening on the public address, much less multiple.
> It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall. NAT is usually configured as part of your firewall, but is not a firewall.
That's a non sequitur. I can have a both a firewall and a NAT. The two layers are better than one because at least my address is shouldn't be routable even if I failed to configure my firewall correctly.
> DHCPv6 Okay? DHCPv4
> What are you supposed to do with a /8? Do you have several million computers? That's GP's point. Running out of address space is not a problem even on IPv4 with NAT.
> What happens if your ISP changes your IPv4 address? Well, an ostensible advantage of IPv6 is publicly routable addresses. I know how to configure my internal IPv4 network with host table entries and so on. If I move to IPv6 then my "internal" network address space is at the whim of my ISP.
103 replies →
> It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall. NAT is usually configured as part of your firewall, but is not a firewall.
Expanding on this. NAT as deployed in most soho/residential settings requires a stateful firewall to track connections + port mapping logic.A stateful firewall is also used for IPv6 edge security and using the same basic posture (out allow, in established/related only) except the only difference is it isn't also doing an address mapping. Nobody is out there saying folks should run a wide open IPv6 edge, and as far as I'm aware no one is shipping IPv6 ready consumer routers that do that (but I'm prepared to be proven wrong in the responses).
"What happens when multiple devices in your /8 want to listen on port 80 and 443 on the public address?"
This is a feature not a flaw. The average person doesn't have anything acting as a server, and that's a good thing, because the only servers they'd have would be embedded garbage in poorly maintained or completely abandoned IOT devices with incompetent code that should not be publicly exposed, ever, in anything but a call out model.
3 replies →
> What happens when multiple devices in your /8 want to listen on port 80 and 443 on the public address? Only one of them can. Now you're running a proxy.
I want to be running a proxy in that scenario, because I don't want any of it accidentally exposed.
> It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall. NAT is usually configured as part of your firewall, but is not a firewall.
Yes, but it's arguably helpful to have configuration mistakes still leave your internal network unexposed. It's harder to accidentally expose resources when your ISP won't route to them.
You're not wrong, yet there's still no compelling reason to make an extra effort to switch to ipv6 when the limitations of ipv4 don't personally affect you.
1 reply →
> > - My ISP gives me a /64, what am I supposed to do with that anyways?
> What are you supposed to do with a /8? Do you have several million computers?
Except you can subnet an IPv4 /8. You can't subnet an IPv6 /64. For whatever stupid reason, and despite having 18 quintillion available addresses in a /64, you can't actually do anything useful with it other than yeet a bunch of devices on the same LAN segment.
(At least on pfSense, and when I looked into it some, that's apparently IPv6 design for some reason)
10 replies →
>What happens if your ISP changes your IPv4 address?
Absolutely nothing, because the private IPs behind the NAT are agnostic of the public IP.
5 replies →
> > - My ISP gives me a /64, what am I supposed to do with that anyways?
> What are you supposed to do with a /8? Do you have several million computers?
The /8 was for private addresses, so "free" and uncontested, while the /64 is a public resource. Looking at it as extraneous or over provided is understandable IMHO, even if mathematically it's not supposed to get depleted.
At least it's not doing anything helpful for OP.
6 replies →
TLS SNI routing has fixed the multiple authorities listening on one IPv4 address port 443.
Most ISP’s implement IPv6 by using the single IPv4 address as a v6 prefix. This results in the entire LAN needing to change local addresses every time the public IP changes. In practice this means a single brief power outage causes hundreds of devices to break instead of none.
Generally speaking ipv6 is useless for most home network users.
Overlapping 10/8 with corporate networks is not a problem, wireguard has solved this in all cases I’ve run into.
With NAT, I absolutely know my ESP32 is not vulnerable and exposed on the wild wild web. With a firewall, I may have a configuration issue or there might be a bug in the implementation or there might be some UDP nuisance I didn't know about or a dozen other concerns. I don't want to hire a network admin not play one at home.
5 replies →
DHCPv6 sadly has the Android problem.
1 reply →
> DHCPv6
Not supported by >50% of mobile devices
> > - What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea. > > What happens if your ISP changes your IPv4 address?
To my internal net: nothing. All my internal addresses stay the same. All my firewall settings remain the same. Just to the outside world I come from elsewhere (which is good for my privacy, not sufficient obviously, though)
However if my IPv6 prefix changes all my IP based access control, which is a layer I use to limit what Internet of Shit devices can do, breaks. I could go to fe80 addresses for my local network, but those won't work across different network segments.
1 reply →
> - I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.
That's great until you need to connect to a work/client VPN that decided to also use 10.0.0.0/8.
> - Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.
Even on IPv4, having normal addresses for all your computers makes life so much nicer. Perhaps-trivial example, but one that matters to me: if two people live in one house and a third person lives in a different house, can they all play a network game together? IPv4 sucks at this.
> That's great until you need to connect to a work/client VPN that decided to also use 10.0.0.0/8.
There's numerous other reserved IPv4 blocks that can be used: https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4. Would definitely not recommend to use 10/8 for private networks.
1 reply →
> I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know.
Your ISP has paid 40€ for your IPv4 address. That's a cost they're most probably passing on to you.
> Every host routable from anywhere on the Internet? No thanks.
Every time you start a videoconference, there is a couple of seconds' pause while the peers perform NAT traversal.
For me, it is main problem. /64 is too small: SLAAC needs /64 per collision domain, and I have more than one (wired network, my WiFi, guest WiFi, control plane for UniFI APs), and it is painful to distribute /64 among them. I'm using HE tunnel which provides /48 to client and it is easy to configure, as intended.
There is recommendation (SHOULD, not MUST in RFC lingo) for ISPs to provide at least /56 to clients, but most domestic ISPs ignore this recommendation.
And it is another problem: tooling. There is no standard way to reconfigure router with dynamic prefix(es). Yes, it is possible to write scripts for it, but it will be fragile. No Linux distribution or FreeBSD is ready to have dynamically allocated prefixes. It is not a real problem with IPv4 because real life practice to dynamically allocate one address and then configuration changes are trivial, and if you are delegated /24, it is typically static delegation.
> - It's hard to remember IPv6 addresses. The prospect of reconfiguring all my router and firewall rules looks rather painful.
fd00::1 is pretty easy to remember. It's your network, give yourself a sane and short prefix.
That's a gripe I have with IPv6. There are too damn many special networks and addresses!
With IPv4 I can easily remember 10.0.0.0/8 and 192.168.0.0/16, but I can't remember the other one off the top of my head. (172.16.0.0/12 I think?). Multicast is 224.x.x.x/x IIRC, but definitely need to look that one up when I need it.
IPv6 has SO many special networks. Network. Public. Multicast. Link local. (Which isn't like an IPv4 link local, but apparently it can actually be on the LAN? IDK - I was just learning about it earlier today.) And every interface seems to have about 5 different addresses of each type.
16 replies →
Thank You. You summarise it really well. Kind of surprised this is top comment given HN ( in terms comments )tends to be very pro IPV6.
It's time for IPv5, I know its been taken so may be IPv7.
> - I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.
10/8 is great until two organizations with 10.0.0.0/24 in their OSPF or IS-IS topologies are brought together via a merger/acquisition. Then you can end up with NAT with-in an organization itself. (Internal split-horizon DNS here we come.)
exactly.
ipv6 just gives you two configurations to maintain, two firewalls to write rules for and cross-leaks that are hard to understand.
I make my internal network ipv4 only, I have a lovable static config, one firewall to maintain. I also use vlans to separate into "can get out", "can only get out through a whitelist proxy", and "can't get out ever". and I am very happy.
I just don't understand how people can just plug every device they own into a promiscuous ipv4 and ipv6 router and contribute to profiling, television snooping, vacuum cleaner house mapping, data leaks, botnets and more...
I do the opposite. IPv6-only in my LAN and Kubernetes Cluster and NAT46/NAT64 for external ipv4-only egress/ingress. Makes it much easier than both dualstack or IPv4 alone.
>I don't use IPv6 because it solves a problem that I don't have
At least here in the U.S., my observation has been it's usually a bit faster and has more efficient routes than IPv4. I assume part of that is using newer equipment and architecture than practical for IPv4 and ability to have more granular routes.
I regularly see 1-2ms improvement to first hop outside my ISP network (10ms vs 12ms)
Remembering addresses is a solved problem with DNS.
> Maybe I've been irreparably corrupted by being behind NAT for too long
Bangs head against desk
NAT per se does not prevent an outside host from connecting to a host on your local network.
> NAT per se does not prevent an outside host from connecting to a host on your local network.
Yep, and a firewall per se does not prevent an outside host from connecting to a host on your local network. You can bang your head all day long, the side effect of NAT is to only allow incoming traffic that refers to an established connection that was initiated from the local network. How is this different from a firewall that does
Allow established, related
Allow outbound
Deny inbound
4 replies →
I guess technically you are right, in that NAT doesn't prevent connections, it enables connections. But in the situation where you would have a NAT, behind a residential router, an outside host cannot connect to an arbitrary host on my internal network.
On a publicly routed PC, I can call `listen` and an outside host can connect to me.
On a PC behind a NAT - if I don't set up port forwarding - I can call `listen` and nobody from outside can connect to me.
So one could say, going from publicy routed to behind a NAT means that only allowed incoming connections are possible. Or am I missing something and you can really, from the outside, open a connection to a PC on a residential network which is behind a simple NAT (TCP server listening on that PC)?
2 replies →
Every single time. But that actually gives a simple answer for why IPv6 is still not commonly used. People can’t wrap their heads around the (simple) fact that NAT is orthogonal to firewalls - and IPv6 has more difficult concepts to offer.
2 replies →
IPv6 also makes it unfeasible to scan the whole address space, unlike IPv4 which is regularly scanned.
ASN addresses are public information.
1 reply →
Will be amazed if the parent comment stays at #1
I share some of the same thoughts
IPv6 should be optional, not mandatory
I disable IPv6 whenever and wherever I can
Gateway is always IPv4 only
No "smartphone" gets direct connection to the internet
IPv6 can be useful. For example, cjdns
I like having the option to use it, but it should not be mandatory
[dead]
Practically every single device or program that is connected in that ipv4 network will have a built in tunnel into the garden, with nat traversal being standard practice for everything. Your fridge, car, door lock, light fixture, all the applications on the phone, everything can and likely is a whole into the garden where someone can get full access. There are quite a few companies who has lost millions because they assumed that the garden was safe from threats within.
Other points aside, I didn’t think ISPs were meant to issue space as small as a 64.
> It's hard to remember IPv6 addresses.
Never understood why they decided to include letters instead of keeping it numeric.
Hell, going from 199.120.121.122 to 199.120.121.122.123 will have expanded IPv4 by 254 times. It took us, what? 40 years to exhaust Ipv4... Just increasing it by 254 alone is insane large amount.
Belgium used this solution for their number plates They used to have a 6 letters/digit mix. Like abc-001 type of number plate. It started to run out, so they simply created a expansion, so new number plates started with 1-abc-001 in 2010, ... and in 2021 did 2-abc-def ( they did not run out of 1, they seem to simply use the first number to indicate the decade more and more). At that rate, Belgium will run out of numbers in they year 11990 ...
Ipv4 is easy to work with, easy to remember, write down, read ... Ipv6 is always a struggle. And yea, the idea that every device may need its own IP from your provider, is just insane.
I have so much more issues configuring things with IPv6, vs just basic IPv4+NATS. Its simply, its easy...
And maybe some people do not have this issue, but our provider gives DYNAMIC IPv6, so the pre-fix keeps altering! What makes configuring things on a NAS even more hell.
O and that :: range modifier is so fun. And the whole pre-fix and post-fix structure...
I hate it. Its complex for my little brain as i do not work daily with it, and whenever i need to deal with Ipv6, i need to relearn the quirks of it every time because of issues like the whole pre-fix/post-fix, dynamic pre-fix etc. Where as IPv4 ... so easy.
> Hell, going from 199.120.121.122 to 199.120.121.122.123 will have expanded IPv4 by 254 times. It took us, what? 40 years to exhaust Ipv4... Just increasing it by 254 alone is insane large amount.
In it's original design, SIPP, the design that was chosen for IPng had 'only' 64-bits, but it was decided that it would be impossible do another transition, and going to 128 would be better future-proofing:
* https://datatracker.ietf.org/doc/html/rfc1752#section-9
So 199.120.121.122 could have grown to 199.120.121.122.152.183.166.197, which I do not think would have made a practical difference to those who complain about "hard to remember" addresses.
And it took 40 years to exhaust IPv4 because NAT was invented (RFC 1631), and now we're stuck with that kludge and have to have all sorts of workaround for it (ICE/TURN/STUN). IMHO it has also has contributed to the centralization of the Internet because doing P2P is just a pain in the ass.
1 reply →
The letters are hex digits, and make it more compact, regular. That’s the good part.
But I agree, using a reserved byte to select internet, say 0 for original, next two hundred for each region, with the rest for planets/moons/nearby stars, would have been easier to understand.
2 replies →
> cue 500 replies of people telling you to eat your vegetables and wear the IPv6 hair shirt
Gee thanks, network experts, for solving a problem I don't have and making me pay for it!
> - I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.
Remember, mate, with a /64 you can host your own ISP. You can finally have real Internet access! (Oh, wait -- it's not actually your /64 and your local ISP[s] wouldn't route it to you if it were, so you really can't.)
> - Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.
Oh, come on. Just look around. Almost everyone here agrees: NAT isn't a security function. Furthermore: NAT is literally the devil and has been for all of the decades you've been using it. Just think of all the stuff it breaks! Like FTP! (Remember how broken FTP was with NAT back in 1995? Or, *shudder*, h.323?)
Besides, with a /64, you can even have every computer on your network changing addresses for every IP connection! Doesn't that kind of obscurity sound nice? (Except... No, that doesn't sound nice at all. That just sounds bizarre and weird -- like dancing about architecture, or maybe some analogy about babies and bathwater.)
> - Stateless auto configuration. What ? No, no, I want my ducks neatly in a row, not wandering about. Again maybe my brain is rotten from years of DHCP usage but yes, I want stateful configuration and I want all devices on my network to automatically use my internal DNS server thank you very much.
Have you ever considered the concept of giving each machine two different IPv6 addresses? One for you to control, and one for your ISP to be in charge of. That'd be quite lovely, wouldn't it? (Except: Now you have two problems.)
> - It's hard to remember IPv6 addresses. The prospect of reconfiguring all my router and firewall rules looks rather painful.
Yeah, well. Uh. Have you tried looking into using ULA addresses like fe80::? (It's awesome! It's got all the hypothetical network convergence problems that an RFC 1918 10/8 has with which to bite you in the mysterious future, except it's also hexadecimal! And unlike the grossly prevalent DHCP system that your 10/8 LAN uses today, nobody can agree on how to centrally assign these addresses to devices!)
> - What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.
Look, man. Let me just move these goalposts for you. The real problem here is that people, like you, need to adopt IPv6. So adopt it already. Your router's implicitly always-on stateful firewall will just take care of it, just like it has almost certainly both incidentally and irrevocably done for your entire history of using NAT with IPv4. And the advantage to you is... you have that big, beautiful /64 to play with however you want (except: it isn't yours, so you don't), free of the chains of that ugly hack of NAT.
(See? That wasn't so hard! The goalposts are heavy, but they can still be moved easily-enough. These new chains are better than the old chains, anyway. The chains of IPv4 NAT were getting a little bit old and dusty, and learning which /64 your ISP will decide to number your LAN with this week is like opening a surprise box! Unless your ISP provides a /56 or something instead! Don't you like surprises? Hey, did I mention ULA? It's always important to mention ULA at least thrice because maybe you want at least two sets of LAN addresses for everything!
(All snark aside: ULA+DHCP+local NAT doesn't sound so bad at all. fd00::3 instead of 10.0.0.3? Gateway at fd00::1 instead of 10.0.0.1? Singular static LAN addresses if we feel like it -- without them being world-known, and regardless of which residential ISP we're using at the moment? People can get used to that. And it would at least present a familiar set of problems that would respond to a familiar set of solutions -- plus, with bonus nachos consisting of a whole dynamic /64 to play with if we ever feel like using that for some reason.
But AFAICT nobody does it that way because NAT is in and of itself some kind of evil thing even when it is under our direct control, so we're just stuffed. Thus, instead of local NAT, we get some combination of prefix bingo, global per-device identifiers or bizarro randomness, and/or overlayed logical networks with local ULA+public Internet addresses for the same friggin' doorbell.
And that shit is simply weird.
As a response to the weirdness, we get the resultant and inevitable pushback that all weird shit deserves.))
Half your complaints don't make sense, but most importantly if you think NAT isn't a problem and is under your control you must have never experienced the growing plague of CGNAT.
5 replies →
> In short, so far, ignorance is bliss.
This isn't ignorance. This is an example of a little knowledge is a dangerous thing.
Ignorance is the internet just works the way it's meant to work for everyone. That's only practically possible with IPv6 these days. Your limited use case and privileged circumstances (ie. you even get a publicly routable v4 address) do not mean anything for someone who just wants things to work.
It's hard to adopt something that schools don't teach. I know someone who graduated from UCI with a CompSci degree with a specialization in networking, just before the COVID19 pandemic began. He recalled that the networking courses he took did not cover IPv6 at all, except to describe the address format (i.e. 128 bits, written as hexadecimal, colon-separated). Everything he learned about IPv6, he had to learn on his own or on the job. A standard that has been published for over two decades, heavily used for over a decade, and critical in the worldwide growth of the Internet, was treated as an afterthought by one of the premier universities in the US.
Obvious disclaimer: This is a sample size of 1, and an anecdote is not data, yada yada. I'm not involved in academia, and have no insight into the adoption of IPv6 in CompSci networking curricula on a broader level.
Meanwhile, I was taught and practiced IPv6 in 2003-5 in engineering school (France).
As of 2024, IPv6 deployment in France was >97% mobile and >98% residential due to not being required for obtaining a 5G radio license (and then v6 simply carried downward to being available on 4G) + every ISP that provides FTTH also providing v6.
https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arc...
Over here IPv6 JustWorks to the point of absolute boredom.
I was taught IPv6 in the mid 2000s too, in Italy.
But penetration there is just about 15% or so :/
Is it commonly used within small/medium/large businesses?
10 replies →
Tbh it’s is a huge PITA with little practical benefit. IPv6 is the Perl 6 of networking.
Many of the big benefits are things that don’t deliver anything that folks are lacking. You also need to understand how you fit in the overall universe more.
An example for a small environment: I've got the whole homelab on unique ipv6 range. Whatever VPN connection happens to another network, I'll never have range collisions or need any fancy rewriting. Also the DNS will point at a specific address on my network, never at a random 192.168.x.x in a network I happen to be connected to.
9 replies →
What about the benefit of there being enough addresses?
58 replies →
That's a pretty bold claim. IMO IPv6 is not hard at all, and delivers significant benefit when dealing with anything outside your local network.
I absolutely love the things that IPv6 delivers and employ it on purpose.
5 replies →
This is so right.
No One believes us on hacker News. It feels very gaslighty. I have never talked to an IT engineer in person that thought IP version 6 in the data center or in the corporate network was a good idea.
I recently passed the CCNA again and they really spend a lot more time on IPv6 compared to 15 years ago. It inspired me to go all in this time and configured my home network with a PD allocation from my ISP. I also came up with some fun labs and even got a IPv6 sage T-shirt from Hurricane Electric.
Did you have to do anything special to get the t shirt? I got the sage cert ages ago and they never sent my shirt...
Any recommended courses? I'm a SWE and never felt compelled for the CCNA but my intersection with networking-related problems seems to continuously increase and I would like to up my game before getting in over my head at work.
This doesn’t hold up. Schools can’t teach everything, especially in a field where innovation happens in the workplace, not the classroom. Should I have learned about LLMs when I was an undergraduate 20 years ago?
This is just further proof that university educations are still not job training. The sooner we disabuse ourselves of that perception the better off society will be.
Higher education is about creating a breadth of knowledge, not specific marketable skills. CompSci is a research field, not job training.
If your friend wanted to learn specific job skills a technical college would be the appropriate setting.
I realize this misperception is perpetuated by the job market but I’m still not surprised at the education provided by UCI and don’t fault them for providing it.
They taught us, they also taught ipv4 in the old "separate address per host" way instead of jumping to NAT, but I think ipv6 is inherently more complicated than ipv4 for the average use case. It's not just a thinking shift.
Separate from that, deliberate decisions were made to make it a "clean slate" without consideration for existing ipv4 hosts. Guess they were hoping the separate stacks would go away eventually, but in hindsight, no way.
> ... but I think ipv6 is inherently more complicated than ipv4 for the average use case. It's not just a thinking shift.
IPv6 isn't all that complicated for most common use cases. Its fundamental concepts and rules are simple. It also obviates the necessity of the complicated workaround called NAT, without which IPv4 is impractical these days.
It's more like the imperial vs metric system debate. If the world hadn't seen IPv4, I believe that we'd all be using IPv6 without any complaints. The real problem is that IPv6 isn't taught well.
> Separate from that, deliberate decisions were made to make it a "clean slate" without consideration for existing ipv4 hosts. Guess they were hoping the separate stacks would go away eventually, but in hindsight, no way.
I'm not sure what to make of this. The presence of the IPv4 stack isn't what blocks the adoption of IPv6 - at least not technically. They can coexist on the same host and function concurrently without interfering with each other. It was designed to operate like that. The actual blocker is the attitude that people hold towards IPv6 - "We have IPv4 that works already. Why should we care about an alternative?". You can see that expressed on this discussion thread itself.
There is one crucial detail that the IPv6 detractors neglect - the scarcity of IPv4 addresses means that IPv4 address blocks are now heavily coveted and therefore subject to moneyed interests. That isn't very good for the health of the open internet, digital rights and equity. They're thinking about individual trees and losing sight of the whole damn forest. IPv6 isn't a solution looking for a problem. It's the solution for a problem that people simply ignore.
6 replies →
ipv6 would have been a breaking change anyway, just take the opportunity to push through any changes that they want to make
Helsinki CS masters had ipv6 20 years ago, but nobody listened at the lectures because all of our home LANs ran ipv4
I got taught IPv6 in 1995. At that time they said it was super important because it would replace IPv4 within a year lolololol
You have it backwards, education always lags industry adoption. (*Assuming it's a software engineering-focused curriculum.)
Programs will teach Docker only years after it is adopted.
Same with AWS, JavaScript, etc.
If it’s not adopted by industry, it won’t be taught about in schools.
I can’t think of any technology where mass adoption was driven by knowledge forcibly inserted into students’ brains by schools… if anything, adoption comes when people realize their out-of-touch curriculum is no longer relevant.
To be clear, degree programs have value, but it’s not in future-proofing students against needing to learn things after they leave school. Ideally it should prepare them and encourage them to do so.
>> I know someone who graduated from UCI with a CompSci degree with a specialization in networking, just before the COVID19 pandemic began. He recalled that the networking courses he took did not cover IPv6 at all...
I am not doubting you, but I feel this story is too hard to believe without adding further nuances...
MIT 6.829 teaches IPv6 since 2002: https://ocw.mit.edu/courses/6-829-computer-networks-fall-200...
In Portugal and other countries, there are subjects on Computer Science before College or University, and they teach it on High School...
The issue is that it’s not taught with IPv6 first. Networking courses do all kinds of stuff using IPv4 to demonstrate various protocols on top (e.g. http, tcp, icmp, etc).
Then there is usually a chapter on IPv6 that just briefly covers the differences.
I.e. the exercises all tend to use IPv4 as the foundation so people don’t practice v6
3 replies →
I've been of the opinion this is one of those "the art advances one funeral at a time." A lot of people are married to IPv4 and its arcane warts and really, really do not want to deal with IPv6 even though most of the core concepts are almost exactly the same thing, except better. I can't imagine anyone who dealt with V4 multicast ever wanting to go back, and I bet they've memory-holed parts of V4 that simply can't be used anymore and so have been turned off for decades(RIP to RIP). Has anyone seen the automated address assignment in V4 ever work? The usual hint it even exists is that if you see one of those addresses it means something is messed up in your Windows host or the DHCP server died.
People complain about dual stacks and all that but with a modicum of planning it is minimal extra effort. Anything made in the last decade has V4/V6 support and unless you're messing with low level network code, it's often difficult to even know which way you're being routed. Network devices pretty much all support using groups of names or addresses and not hard coded dotted-quad config statements now, and have for a while. And that was good practice on V4 networks too.
Part of it is probably that remembering various V4 magic is easy enough to do but feels complicated enough to be an accomplishment. In V6, there is no point in doing most of that because the protocol has so much more automation of addressing schemes. But if you like those addressing schemes, V6 can do them even better. You can do all sorts of crazy address translation on either the network or host id portion, like giving an internal network a ULA that is magically translated to a public network prefix without any stateful tracking unless that is desirable.
I feel there is some analog to DNS in that regard, people who have gotten used to DNS don't give a damn about host IP addresses but some people seem to really like the idea of a fixed address statement. People also seem to be stuck on the idea that NAT creates some kind of security when that's really the stateful tracking that is required for many-to-few translations (thus making firewalls a common place to implement it), not the translation itself. Similar to certificates/pki versus shared keys, yes, one is more upfront effort but that's because it's solving the problem of the Sisyphean task that is the other.
edit: This all reminded me that we lived with dual stacks before, in the IP and IPX days, or DECnet, and that GE Ether-whatever, and those had less in common. IPX mostly died with Netware but it had a number of advantages that wouldn't be bolted on top of IP for years, some of which are present in IPv6. I rather liked IPX and had history gone differently that it used 48-bit addressing would be causing us to discuss whether or not EUID was a mistake or not :)
Ipv6 was a protocol engineered in isolation from the social / political environment it had to be adopted in.
A successor to ipv4 wasnt a technical issue. duh, use longer addresses. The problem was social.
It's a miracle it was used at all
What's annoying about ipv6 discussions is that the ipv6 people are incredibly condescending when the problems of its adoption were engineered by them.
6 replies →
IPv4 link local addressing is awesome for direct PC to PC connectivity with no hassle
5 replies →
80% of my career knowledge as a devops engineer, systems administrator, and IT engineer has been on the job training. That's just how it works.
The real reason is IT people hate ipv6. They want NAT. They don't want all the security holes and extra complexity. I don't want having to work with a network stack that is poorly supported by some switches and routers.
> Everything he learned about IPv6, he had to learn on his own or on the job.
Replace "IPv6" in that sentence with any practical knowledge or skill and it's probably true for my entire master's degree....
Weird, I graduated from RIT in 2009 with a B.S. in Applied Networking and Systems Administration and we covered IPV6 quite a bit
I certainly can validate this anecdote, I also had to learn almost everything about IPv6 myself.
IPv6 was superceded by NAT a long time ago. It will die a slw and quiet death which is why it is now being ignored by training facilities and experts worldwide.
Oh no, somebody should warn all the ISPs deploying IPv6-native connections with v4 reachable over some fallback technology (464XLAT, DS-Lite, NAT64 etc.) to their hundreds of millions if not billions of customers!
--Sent from my IPv6
1 reply →
Digital Ocean didn’t even have an ipv6 address on by default in the droplet I created last week. It’s just a switch to flip, but I’ll bet the support costs of hobbyists/enthusiasts not realizing they needed to also write firewall rules, make sure ports weren’t open for databases and things like that for ipv6.
26 replies →
NAT doesn't solve everything, and creates a whole new class of problems that you can just avoid by adopting IPv6 natively. And it's definitely not being ignored at larger companies.
In particular, just off the top of my head...
- T-Mobile US doesn't even assign clients an IPv4 address anymore. Their entire network is IPv6 native.
- Many cloud providers charge extra for IPv4 addresses, but give IPv6 addresses out for free.
1 reply →
This is not even funny to read, given huge networks like T-Mobile USA being IPv6-only.
12 replies →
It was?
Isn’t it what all the cell phones networks use these days? And most ISP’s?
They may hand the end user device a IPv4 address but don’t they actually use IPv6?
9 replies →
AWS charges for ipv4 addresses but ipv6 addresses are free. ipv4 with NAT doesn't supercede ipv6, it just extends its life.
What are you even basing that on? Here are some facts:
- You have to pay money to get a static IPv4 address for cloud machines on eg AWS. Anything needing a static IPv4 will cost more and more as demand increases. NAT doesn’t exactly fix that.
- Mainstream IoT protocols have a hard dependency on IPv6 (eg Matter/Thread). Not to mention plenty of 5g deployments.
- Many modern networks quietly use IPv6 internally. I mean routing is simpler without NAT.
So it almost definitely won’t die. It’s more likely it’ll slowly and quietly continue growing behind the scenes, even if consumers are still seeing IPv4 on their home networks.
5 replies →
https://www.google.com/intl/en/ipv6/statistics.html
32 replies →
This feels a lot like the arguing that went on during the transition to Python 3. The Python 2.7 hangers-on were so preoccupied with themselves that they didn't notice that the pool of people interested in having the argument at all was getting smaller and smaller.
Until somebody turned off the lights, that is. It is not much fun arguing with yourself in the dark.
I think that's what needed and needs to be done here. I will agree with the IPv4 advocates on one thing: IPv6 adoption has been slow in part because it doesn't work like IPv4 + kludges. That is the point. Clinging to IPv4 standard practices while you switch is just going to make you miserable.
In 2006, the hesitation to go to IPv6 made sense. Support was spotty. In 2026 it does not. IPv6 support is now more than adequate, and a clean cut will force the stragglers to get their asses in gear in a hurry ("fix your IPv6 support RFN or enjoy nobody using your product"). Change is painful, learning new stuff when you were getting by just fine on the old stuff is painful, I get it. But it will happen whether you like it or not. Why not just get it over with?
I finally made the switch to IPv6 last year, and I wouldn't go back.
The pain of change is real, but mercifully, it doesn't last. Within a year this debate will seem quaint.
As of 2024, literally none of the customers deploying the robots I worked on had ipv6 support on their networks. (We seriously considered switching to ipv6 for our backend controller-to-device network since it would inherently avoid conflicts that way - but none of the hardware devices had ipv6 support yet either, even the ones that were linux boxes underneath; turned out that network namespaces were a better approach to that problem anyway.) These were pretty technophilic areas (within otherwise "traditional" companies - the crossover between "wanting robots" and "being able to afford robots" is a little weird :-) and none of them were even talking about ipv6, to the point that we took "add configuration for ipv6 to the management console in a hurry because a customer wants it" off of our threat-to-schedule list entirely.
I get the feeling it's another 5-10 years before "not getting around to ipv6" will actually be a mistake in that space...
>In 2026 it does not. IPv6 support is now more than adequate,
Youtuber apalrd periodically revisits the Ubiquiti Unifi devices to see if they finally support IPv6 and he concluded it still doesn't work correctly.
The linked comment from Ubiquiti acknowledges they're still trying to improve the situation : https://www.youtube.com/watch?v=KZpJvpm1Ris&lc=UgwXlto--2NbO...
EDIT add: A lot of home users also like Ubiquiti ecosystem for local recording security cameras without a cloud subscription. Another competitor like Reolink with local capability also doesn't support IPv6: https://support.reolink.com/hc/en-us/articles/900000645446-D...
The practical home usage of deploying IPv6 depends on combination of the ISP, the devices you want to use, software stack, etc.
What it sounds like to me is: don't use Ubiquiti.
1 reply →
There's transition tech for 4to6 to handle embedded devices, though.
Obviously the gateway or router missing proper v6 support is an issue and a bit surprising ubt hasn't done a good job.
Even my mid range TP-Link Archer I had 10 years ago properly supported IPv6
I can't use vlans because my isp only gives me a /64.
So I either need to use ipv6 + kludges or ipv4 + kludges. ipv4 is obviously easier and more reliable at that point, it's a no brainer.
Any sort of hot spot / bridge faces the same problem.
Now RFC 9663 is supposed to help here but guess what? It's only like a year old and barely exists. Not 20 years.
It's not that change is painful, it's the ipv6's original design of a shallow depth network was just... bad. Bolting on RFCs to fix it is taking a long time.
I would say this analogy is not properly when talking about IPv4 to IPv6 transition. Moving from Python 2.7 to 3 is a pure software problem while moving IPv4 to IPv6 is hardware, software, and logistics problem.
There are number of embedded OSes and devices that do not have firewalls nor the ability to disable network ports. Example of these invisible world items are motors, servos, PLCs, and label printers that get configured over IP. These devices do the bare minimum to get the IP stack up and running. These UI tools also need to be updated for allowing configuring an IPv6 address.
I would love to leave IPv4 and move fully to IPv6. Currently it is not cost effect to do so at scale. Companies do not want to spend money on the extra hardware to allow their IPv4 devices to talk IPv6 when they can save that money and keep running IPv4. Nor do they want to spend money on newer hardware. I still have clients running Windows XP Embedded, hopefully air gaped, in the automation world.
*You would be surprised on the number of large corporate IT managers that rather have a completely open label printer connected directly to their network instead of bridged behind a state full firewall running Windows or Linux hosting the main product.
> In 2026 it does not.
There are no ISP providing ipv6 for home and mobile users here in hong kong
That is an unusual luxury, especially mobile providers still using IPv4.
Mobile providers have been the first and most aggressive to migrate to IPv6. Probably helped along by the cost and difficulty of running CGNATs when your network clients are constantly moving around. At least in the UK all the mobile providers are IPv6, and I think a handful are IPv6 only.
The hardware support is very likely already there.
I live in the USA and my ISP doesn't support ipv6
I think it's different. Python 3 had a couple slightly annoying quirks that were resolved and once we got past that hurdle conversion was pretty seamless. I've been doing IPv6 in one form or another since, oh, 2010 or thereabouts, and it still remains pretty opaque and a pain in the ass compared to IPv4.
I do use it often, at least for Internet communication (I haven't checked recently to see what my traffic split is between v4/v6, but it's probably on the verge of tilting in favor of v6, if not already there), but I just can't see using it for my internal network anytime soon.
I'm not sure you understand what you're proposing. If you end IPv4 support on your product, all you're doing is banning the users on ISPs that don't have IPv6 support.
The people feeling the pain would not be in any position to fix the problem, and their experience will be that your site is down which leads to support burden and reputation risk for your product. If your support tells me to switch ISPs I'm going to roll my eyes and find another product that works.
No, but imagine if Google, Meta and Netflix all publicly agreed to stop supporting IPv4 in X years.
_Everybody_ would rush and make sure to switch everything to IPv6.
6 replies →
I interpreted it to be about vendor contracts. Suppose you're setting up a new thing and you have a choice of vendors. They're all about the same but one of them supports IPv6. You're more likely to pick that one.
I think the big difference is that python 3 took over rather quickly once it hit a threshold. There was a clearer path for adoption too: as more major packages started supporting python3, adoption accelerated and eventually python2 support was dropped. For IPv6 it's a lot less straightforward. You could cling on to IPv4 with basically 0 practical downsides in the current ecosystem as everything that supports IPv6 also supports IPv4, and IPv6 only networking basically doesn't exist. Even mobile users with only IPv6 adresses get to use IPv4-only services through some translation layer that every ISP has to provide when running IPv6.
I don't see the difference. You are describing the adoption curve (a logistic function) for almost anything.
As with IPv4/IPv6, with Python 2.7/3 you had, even at the very end, a group of stubborn maintainers who didn't put in the effort to transition.
The hard end of Python 2.7 support took care of all that in a hurry.
I don't like to admit this, but at this point honestly I think ipv6 is largely a failure, and I say this as someone that wrote a blog post for APNIC on how to turn on ipv6.
I'll get endless pushback for this, but the reality is that adoption isn't at 100%, it very closely needs to be, and there are still entire ISPs that only assign ipv4, to say nothing of routers people are buying and installing that don't have ipv6 enabled out of the box.
A much better solution here would have been an incredibly conservative "written on a napkin" change to ipv4 to expand the number of available address space. It still would have been difficult to adopt, but it would have the benefit of being a simple change to a system everyone already understands and on top of a stack that largely already exists.
I'm not proposing to abandon ipv6, but at this point I'm really not sure how we proceed here. The status quo is maintaining two separate competing protocols forever, which was not the ultimate intention.
> A much better solution here would have been an incredibly conservative change to ipv4 to expand the number of available address space
"And what do you base this belief on?
Fact is you'd run into exactly the same problems as with IPv6. Sure, network-enabled software might be easier to rewrite to support 40-bit IPv4+, but any hardware-accelerated products (routers, switches, network cards, etc.) would still need replacement (just as with IPv6), and you'd still need everyone to be assigned unique IPv4+ addresses in order to communicate with each other (just as with IPv6)."[0]
0: https://news.ycombinator.com/item?id=37120422
> Fact is you'd run into exactly the same problems as with IPv6.
If you treat IPv4 addresses as a routable prefix (same as today), then the internet core routers don't change at all.
Only the edge equipment would need to be IPv4+ aware. And even that awareness could be quite gradual, since you would have NAT to fall back on when receiving an IPv4 classic packet at the network. It can even be customer deployed. Add an IPv4+ box on the network, assign it the DMZ address, and have it hand out public IPV4+ addresses and NAT them to the local IPv4 private subnet.
IPv6 seems to be a standard that suffered from re-design by committee. Lots of good ideas were incorporated, but it resulted in a stack that had only complicated backwards compatibility. It has taken the scale of mobile carriers to finally make IPv6 more appealing in some cases than IPv4+NAT, but I think we are still a long way from any ISP being able to disable IPv4 support.
31 replies →
I agree with that belief, and I've been saying it for over 20 years.
I base it on comparing how the IPv2 to IPv4 rollout went, versus the IPv4 to IPv6 rollout. The fact that it was incredibly obvious how to route IPv2 over IPv4 made it a no-brainer for the core Internet to be upgraded to IPv4.
By contrast it took over a decade for IPv6 folks to accept that IPv6 was never going to rule the world unless you can route IPv4 over it. Then we got DS-Lite. Which, because IPv6 wasn't designed to do that, adds a tremendous amount of complexity.
Will we eventually get to an IPv6 only future? We have to. There is no alternative. But the route is going to be far more painful than it would have been if backwards compatibility was part of the original design.
Of course the flip side is that some day we don't need IPv4 backwards compatibility. But that's still decades from now. How many on the original IPv6 will even still be alive to see it?
1 reply →
Hardware would catch up. And IPv4 would never go away. If you connect to 1.1.1.1 it would still be good ole IPv4. You would only have in addition the option to connect to 1.1.1.1.1.1.1.2 if the entire chain supports it. And if not, it could still be worked around through software with proxies and NAT.
42 replies →
You’re focusing on the technical difficulty of implementing it in software. This is not the problem. IPv6 support is now present in almost every product, but people still refuse to set it up because it’s so different to what they’re used to (I’m not arguing whether the changes are good - they’re just changes). IPv4+ would’ve solved this social problem.
1 reply →
Hardware support for ipv6 hasn't been the limiting factor in a long time. Users higher on the stack don't want to adopt something that makes so many unnecessary changes.
The IPv4+ could pass through a router that doesn't know about it - the cloud host that receives that packet could interpret it in a special way, in fact you could stuff additional data into the next layer of the stack for routing - it's not like many services beyond TCP would need to support the scheme.
5 replies →
This whole discussion reminds me of the beautiful design of UTF-8. They used the lower bits to be ASCII which made backwards compatibility so much easier. It also reminds me of the failure of Intels Itanium and the success of AMD x64. Engineers often want to abandon backwards compatibility to make a new "beautiful" design, but it's the design that has full backwards compatibility that's actual impressive.
So well said! Those are great comparisons.
It reminds me of python 3. Basically, a huge chunk of people (in my case, scientific programming) get an enormous mess and nothing at all of value until... 3.6 maybe (the infix matrix mult operator). Stunningly, people weren't enthused about this deal.
It would maybe be okay at the router to break some things, but ffs even in software I have to choose? Why do I need both ping and ping6 this is stupid!! They really screwed up by making it a breaking change to the OS and not just internet routing.
2 replies →
The only solution is a gov't mandate. China went from almost no adoption to leading the world in adoption (77% of all Chinese internet users) in a few years because they explicitly prioritized it in their last 5-year-plan.
The ISPs aren't gonna do it on their own.
US government has finally learnt from how vendors break the mandates and there's now IPv6 mandate if you want to sell to federal government, and waivers are only available for buyers not vendors, and individually every time.
I wouldn't say "failure". There are many, many IPv6 client devices out there, mostly on mobile networks. And it works great and they do well and the tools all support it very well.
But IPv4 will never, ever die. The rise of NAT as a pervasive security paradigm[1] basically neuters the one true advantage IPv6 brought to the table by hiding every client environment behind a single address, and the rise of "cloud everything" means that no one cares enough about reaching peer devices anyway. Just this morning my son asked me to share a playlist, so of course I just send him a link to a YouTube Music URL. Want to work on a spreadsheet for family finances with your spouse in the next room? It lives in a datacenter in The Dalles.
[1] And yes, we absolutely rely as a collective society on all our local devices being hidden. Yes, I understand how it works, and how firewalls could do this with globally writable addresses too, yada yada. But in practice NAT is best. It just is.
> I wouldn't say "failure". There are many, many IPv6 client devices out there, mostly on mobile networks.
Honestly it's a huge success due to this fact alone.
IPv6 is failure only if you measure success by replacing IPv4 or if you called "time" on it before the big mobile providers rolled it out. The fact that all mobile phones support it and many mobile networks exclusively deploy it tells you what you really need to know.
IPv6 is a backbone of the modern Internet for clients, even if your servers don't have to care about it due to nat64.
1 reply →
Yep, just call it IPv8 and make it double the length of IPv4.
Ultimately, an address system that replaces “1.1.1.1” with “JEDBSO:7372B6D6A:727:8:72829:762927” or whatever just isn’t viable.
Even AWS doesn’t let you use IPv6 with anything… and they charge you for using IPv4 now.
I toyed with using ipv6 in my local network just to learn it and what a headache that was. Ultimately not worth the hassle. I can remember most of the important device ipv4 on my network, I can't say the same for v6.
This is the first time I've heard this critique. I think most people don't care if their IP address is easily human readable/memorizable. In my experience when people do deal with ipv4/v6 addresses directly, they just copy-paste.
5 replies →
AWS supports IPv6 on a number their services now: https://aws.amazon.com/vpc/ipv6/ For example there are options to use their hosted memcache/redis service IPv6-only: https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/netw...
Shocking it took them so long but, hey, it's there now.
Circa 1999 I was working for Cisco as a sysadmin. I got my CCNP through internal training and considered making a career of network administration, but ipv6 changed my mind. It seemed so much more difficult and unpleasant to deal with. I didn't want that to be my day to day work.
I think the same thing happens on a different scale with ISPs. They don't want to deal with it until they have to for largely the same reason.
> It seemed so much more difficult and unpleasant to deal with.
In my experience it’s much easier and much more pleasant do deal with. Every VLAN is a /64 exactly. Subnetting? Just increment on a nibble boundary. Every character can be split 16 ways. It’s trivial.
You don’t even need to use a subnet calculator for v6, because you can literally do that in your head.
Network of 2a06:a003:1234:5678::555a:bcd7/64? Easy - the first 4 octets.
Network of 10.254.158.58/27? Your cheapest shotgun and one shell please.
5 replies →
At first I though so too but IPv6 is actually easier. instead of CIDR you always have 64 bits for network and 64 for host. You get a public /48 IPv6 prefix that allows for 16 bits of subnets and then the host addresses can just start at 1 if you really want. So addresses can be prefix_1_1 if you want. And the prefix is easy to memorize since it never changes.
I DO think using 64 bits for hosts was stupid but oh well.
3 replies →
I actually think it would have had a better chance of success if ipv6 had embraced the breaking changes to add some killer feature that would have made it worthwhile to upgrade even for entities who didn't need to worry about running out of ipv4 addresses.
I'm not sure what that feature would be though.
This is actually unwanted in a dual-stack world. Once you have divergent behaviors on your networks, you have a complex/weakened security model.
Networking should be boring.
IPv6's failure was mostly caused by the IETF's ivory tower dwellers, who seem to generally have no practical experience or understanding whatsoever of how networks are actually built and run today, especially at the small to mid scale.
Small site multihoming, for example, is an absolute disaster. Good luck if you're trying to add a cellular backup to your residential DSL connection.
IETF says you should either have multiple routers advertising multiple provider-assigned prefixes (a manageability nightmare), or that you should run BGP with provider independent address space; have fun getting your residential ISP or cellular carrier onboard with this idea.
IETF has a history of being hostile to network operators. I mean actual network operators - not the people who show up at conferences or work the mailing list who just happen to get a paycheck from a company that runs a network (and have zero production access / not on call / not directly involved in running shit). It's gotten better in the last few years in certain areas (and credit to the people who have been willing to fight the good fight). But it's very much a painful experience where you see good ideas shot down and tons of people who want to put their fingerprint on drafts/proposals - it's still a very vendor heavy environment.
2 replies →
IPv6 was a total failure of imagination.
The fact is that already in 1993 routing tables were just too big, and the fact is that having a "flat" address space was always going to mean huge routing tables, and the fact is that because IPv6 is still "flat" routing tables only got larger.
The fix would have been to have a subset of the address space that is routed as usual for bootstrapping ex-router address->AS number mapping, and then do all other routing on the basis of AS numbers _only_. This would have allowed us to move prefix->AS number mappings into.. well, DNS or something like it (DNS sucks for prefix mapping, but it could have been extended to not suck for prefix mapping), and all routing would be done based on AS numbers, making routing tables in routers _very small_ by comparison to now. Border routers could then have had tiny amounts of RAM and worked just fine. The IP packets could have borne AS numbers in addition to IP addresses, and all the routers in the middle would use only the AS numbers, and all the routers at the destination AS would know the routes to the destination IPs.
But, no. Great missed chance.
Well, we still could do this with IPv6, but it would be a lot of heavy lifting now.
EDIT: Ah, I see draft-savola-multi6-asn-pi existed.
EDIT: Ah, see also LISP [https://www.rfc-editor.org/rfc/rfc6830]. But LISP is essentially dead.
> a cellular backup to your residential DSL connection
Hmm, what's the problem? I suppose your home devices should never be exposed to the public internet, and should only be accessible via a VPN like Wireguard. NAT64 is a thing if your home network is IPv4.
BTW what's the trouble with multi-homing? Can't an interface have two separate IPv6 addresses configured on it, the same way as IPv4 addresses?
43 replies →
I've been thinking we could simply extend the ipv4 address to be 11 bytes by (ab)using the options field. That is, add an option that holds more bytes for the source and destination address, which are to be appended to the address already present in the header.
I am thinking that since an option starts with 2 bytes and everything must be padded to a multiple of 4 bytes, we can add 16 bytes to the packet, which would hold 7 extra address bytes per source and destination, giving us 11 byte addresses. ISPs would be given a bunch of 4-byte toplevel addresses and can generate 7-byte suffixes dynamically for their subscribers, in a way that is almost the same as CGNAT used today but without all the problems that has.
Most routers will only need to be updated to pass along the option and otherwise route as normal, because the top level address is already enough to route the packet to the ISP's routers. Then only at the edge will you need to do extra work to route the packet to the host. Not setting the option would be equivalent to setting it to all 0s, so all existing public hosts will be automatically addressable with the new scheme.
There will of course need to be a lot more work done for DNS, DHCP, syntax in programs, etc, but it would be a much easier and more gradual transition than IPv6 is demanding.
I don't think so. It would be more confusion because no one will know if a network is ipv4 or ipv4+, leading to edge case bugs and confusion and people will similarly be lazy and choose to only implement ipv4 knowing it will always be reverse compatible and the cost is transferred to the consumer.
Plus, it's only 2048x the address space. It's within the realm of possibility that we will need to upgrade again once this place is swarming with robots.
1 reply →
ipv6 adoption is still steadily rising. Not as fast as anyone hoped, but at least steadily. There is no way it can be abandoned at this point even if we wanted to.
I wonder if it could still be usurped by another standard that is somehow more popular. If adoption of that leapfrogs over IPV6 then maybe it will have just been a waypoint along the way.
5 replies →
Truth is there are too many devices that only speak IPv4 or have untested IPv6 stack. People still can’t even agree on how ipv6 address is represented.
People have totally agreed on how IPv6 addresses are represented.
Stripped of all the other baggage that came with it (e.g. SLAAC, IPsec, etc) IPv6 is an incredibly conservative addressing extension. The only thing even more conservative than v6 would have been to drop the lower 64 bits of the address and the associated EUI-64 local addressing scheme. Which... to be fair, that turned out to be a very bad idea, but the length of the field isn't what was holding up v6 adoption.
I suspect by "incredibly conservative" you mean "backwards compatible", which... no. You can't make an addressing extension backwards compatible with hardware that doesn't read all of the address. Of course, we did that anyway with CGNAT, and predictably it causes huge problems with end-to-end connectivity, which is the whole point of IPv6. You're probably thinking more along the lines of an explicit "extension addressing header" for v4. Problem is, that'd mean a more awkward version of IPv6's /64 address split[0], combined with all sorts of annoying connectivity problems. The same corporate middleboxes that refuse to upgrade to IPv6 also choke on anything that isn't TCP traffic to ports 80 and 443. So you'd need Happy Eyeballs style racing between CGNAT IPv4 and "extended IPv4".
Also, that would just be a worse version of 6in4. Because they also thought of just tunneling IPv6 traffic in IPv4 links. I don't think you understand how incredibly conservative IPv6 actually is.
The problem with "incredibly conservative" IP extensions is that nothing beats the conservatism of doing literally nothing. IT infrastructure is never ripped out and replaced unless there is a business case for doing so. The current problem with IPv6 adoption is that nobody has yet said "let's stop processing IPv4 traffic", they've only said "let's get more dual-stack hosts online", which is a process that only asymptotes to 100% IPv6, and never reaches it.
IPv4 was not the first version of the Internet protocol. That honor goes to Network Control Protocol (NCP). The reason why we don't have an asymptotic long tail of Internet hosts still demanding NCP connectivity is because this was back when "having a connection to the Internet" meant "having a connection to ARPANET". The US military could just refuse to process NCP packets and actively did this to force people onto IPv4. Now imagine if someone big like Google said "we're going to stop accepting IPv4 connections" - people would jump onto v6 immediately.
[0] Let's say we add a 32-bit extension header onto IPv4
"Stripped of all the other baggage that came with it..."
But that baggage is a huge part of the problem. Almost nothing you know about IPv4 applies when you switch to IPv6, and most of us found that out the hard way when we tried to make the switch. Leaves a pretty bad taste in your mouth.
4 replies →
> The current problem with IPv6 adoption is that nobody has yet said "let's stop processing IPv4 traffic"
Mobile carriers have done that between consumer devices and network towers. That forced a lot of innovation (including tools like better DNS64 and "happy eyeballs" protocols) and network stack hardening.
The roll out of out CGNAT in some cases is "let's drop IPv4 traffic randomly" and "happy eyeballs" in consumer devices is transparently driving a lot of consumer traffic to IPv6.
This is why mobile and consumer devices are leading the pack on IPv6 adoption.
It's maybe not all of Google that next needs to say "we're going to stop accepting IPv4 traffic", it's maybe more specifically GCP (and AWS and Azure) that need to do that to drive the non-consumer IPv6 push we need. The next best thing would be for all the cloud providers to at least start raising IPv4 address prices until their clients start to feel them.
> The current problem with IPv6 adoption is that nobody has yet said "let's stop processing IPv4 traffic"…
One of the giant CDNs translates all IPv4 traffic to IPv6 at the edge (stateless NAT46) and is IPv6-only in its core network (for one of its primary product networks; like everybody they have multiple networks.)
1 reply →
I think this is defeatist talk where it’s not warranted. I remember IPX networks in the 90s were still a thing because people believed they could eke out a little more performance for their games. It’s taking a long time to move to IPv6 in some parts of the world. eg: anyone who doesn’t feel the pain of the IPv4 address crunch likely due to having a large chunk to begin with. Many influential organizations in North America definitely fall in that category.
IPv6 is a success IMHO because it is used in so many places. Google’s IPv6 traffic graph shows close to 50% adoption and still trending up. We can’t possibly expect the world to be near 100% overnight… the internet is a big place with the whole spectrum of humans influencing IT; There will always be someone who will cling to IPv4 for dear life.
> I'm not proposing to abandon ipv6, but at this point I'm really not sure how we proceed here. The status quo is maintaining two separate competing protocols forever, which was not the ultimate intention.
The end game will be a cryptographically large address space allocated based on some cryptographic operation, rather than a committee carving up the space arbitrarily.
Tor already does this, addresses allocation is not a problem. I think they used to use hashes, but now use Ed25519 public keys. Obviously, Tor is not suitable for most tasks. No one should have to pay for the extra latency if they don't need the anonymity.
The real problem is routing in these address spaces, and there have been a few projects like CJDNS which try to solve it.
Imagine every address along a major road is 3 digits, and some shortsighted post office code assumes 3. Your business is 845 Oak St. One day they say hey, this road is getting too long, let's update that code to support 10 digits and we never worry about this again.
Oh and btw, your address is now 9245593924 Oak St.
> still hasn't taken over the world
Maybe not in the strict sense, but it kind of has.
In the enterprises I've worked in the past decade with IPv6 running, at least 75% of the Internet traffic is IPv6. In my discussions with other engineers managing large networks, they seem to be seeing more or less that same figure.
The problem is that virtually nobody knows IPv6. I regularly bring up IPv6 in engineers' circles and I'm often the only one who knows much about it. And so, I have doubts about it's long-term future, except for edge cases. I figure some clever scheme utilizing IPv4 and probably NAT will come around at some point.
IPv4s are about to be bought, held, portfoilo'ed, speculated, and rented/mortgaged/sold like real estate. Companies like IPXO are already doing it. The costs of public IPv4's are going to go up for no technical reason because a new distinct ownership layer is springing up between you and the ISP. You're going to start renting them or paying a holder for the right to use them (on top of your ISP to transport it) at some point. And you can continue to do that, or get IPv6's for free.
Just to be pedantic, it's "illegal" to hoard IPv4 or to buy it for any purpose other than using it directly. But yeah, in the real world it may become more financialized than it already is. OTOH if prices keep dropping maybe they won't bother.
2 replies →
I'm a networking noob, but would it be possible to extend DNS/HTTPS so as to allow a URL to point to a port other than 443? Doing so would allow each IP address to serve multiple websites/computers making the pool of addresses at least thousands of times larger.
3 replies →
IPv4s have been bought and sold for years
https://auctions.ipv4.global/prior-sales
Prices have been going down in nonimal terms for years, let alone real terms. In terms of investment they're a terrible asset.
3 replies →
How does one get an IPv6 allocation for free? Or, do you mean the ULA space? Because the latter doesn't really count.
16 replies →
We own our own IPv4 and IPv6 ranges, which is nice. There already is a holder for the US: ARIN.net and I hear it's a pretty spendy annual fee for most orgs (we're legacy. we've had ours for decades)
Now all we need is for someone to make a crypto currency so you can fractionally own IPv4 addresses.
3 replies →
> Maybe not in the strict sense, but it kind of has.
I challenge you to find:
1. A hotel in the US that provides IPv6. I have NEVER been in one, and I once stayed in a hotel (in Mountain View, CA) that was giving out public IPv4 addresses.
2. An easier task: a SIP provider that has IPv6 (in the US). You know, for the VoIP that is supposed to be a poster child of end-to-end connectivity.
> In the enterprises I've worked in the past decade with IPv6 running
What about those without IPv6 running?
Anyway, in the enterprises I've worked in the past decade - of course, another anecdote - not once has anyone ever specified an IPv6 address of anything. Inside the organization or outside of it.
why would an enterprise turn to IPv6?
everything fit's nicely in the 10.0.0.0/8 range
in my many decades of enterprise infrastructure, no-one has ever mentioned IP6 either.
why would they, whats the business case?
19 replies →
> not once has anyone ever specified an IPv6 address of anything. Inside the organization or outside of it.
If you deploy IPv6 correctly, you shouldn't have to disclose IPv6 addresses to users inside or out -- DNS keeps the address literals abstract, hidden from users.
I am on my company's VPN right now and I get a 0/10 at test-ipv6.com
>Maybe not in the strict sense, but it kind of has.
>In the enterprises I've worked in the past decade with IPv6 running, at least 75% of the Internet traffic is IPv6.
Nobody cares about those. What matters is if my device has an IPv6 address assigned.
Ok then: most people in the US do. The rest of the world is looking increasingly ipv6 too: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-... India is 71% IPv6 (probably thanks to Jio), China has it in its 5 year plan, Europe is doing well, etc
2 replies →
> at least 75% of the Internet traffic is IPv6.
> Nobody cares about [that]. What matters is if my device has an IPv6 address assigned.
This seems to be the weird dichotomy in these comments. Some people are arguing from the position that is absolutely everywhere and is doing great.
Others are saying since their machine doesn’t show it it’s dead and no one cares.
Is there a term for this? A successful failure? A failed success?
Kind of odd.
4 replies →
75% or 99% does not matter. Until you can't forget about IPv4, IPv6 us useless.
The fact that this comments section indicates such a yawning chasm of gaps in knowledge (much less, understanding) - in a forum whose users are generally known to be more technically savvy than most - is exactly why IPv6 is still not widely adopted. There is confusion about the less obvious benefits, confusion about how it works, confusion about the dangers (how do I adjust my well honed IPv4 spidey senses?), and confusion about how I transition my current private network. An epic failure of change management.
Here’s a prediction. Linux on the desktop will have >50% penetration well before IPv6 does.
IPv6 already hit 50% https://www.google.com/intl/en/ipv6/statistics.html
It's so funny to see predictions that aged worse than milk. Ipv6 adoption isn't up to individuals, it's up to ISPs. We consumers aren't supposed to know about ipv6. The change will be silent and continuous.
“Given addresses” != adoption. Hell, I had to disable it in osx because it breaks the damn hotspot connection functionality. Wasn’t using it, it’s just there, breaking shit and being useless.
2 replies →
Measly 30 years after it was approved. We will likely get AGI before we finish the transition.
> The fact that this comments section indicates such a yawning chasm of gaps in knowledge (much less, understanding) - in a forum whose users are generally known to be more technically savvy than most - is exactly why IPv6 is still not widely adopted.
No, it isn't. Everyone here has the causality backwards. We don't know it because we've never needed to know it, and we've never needed to know it because it's not really required for anything (i.e. the cost of adopting/learning it > benefit).
This has been a frustrating HN discussion to read, to be honest, because the consensus view strikes me as so off base. It's not that IPv6 has been miscommunicated, or that it hasn't been taught enough to undergrads. It's that it has been designed with virtually no incentives to encourage people to actually adopt it, with the entirely predictable consequence that no one adopted it. Therefore, none of us need to know it, schools don't need to teach it, etc.
Folk are internalising the wrong lesson here. Incentives matter. No amount of mandated IPv6 instruction or well-intentioned blog posts explaining IPv6 are going to change anyone's incentive structure. And then when those things fail, there's a predictable and tiresome tendency to blame the users for not switching.
If you want people to adopt new tech, make it actually do something new. Give people some reason to want to switch. "It mostly does the same thing as the old tech did, but it also takes effort and money to learn it / switch to it" is a terrible pitch, with entirely predictable consequences, and it's far too common in technical circles.
> with the entirely predictable consequence that no one adopted it
As the sibling comment pointed out: it's very close to 50% adoption, you just don't see it https://www.google.com/intl/en/ipv6/statistics.html
> There is confusion about the less obvious benefits, confusion about how it works, confusion about the dangers (how do I adjust my well honed IPv4 spidey senses?), and confusion about how I transition my current private network
Could you be specific about what the misconceptions are?
I had Copilot produce this for you based on the comments in this discussion (as at just before the timestamp of this comment).
https://copilot.microsoft.com/shares/656dEMHWyFye5cCeicgGv
6 replies →
One would think that in 30 years there will be some sort of best practises established. Some articles to refer people to. Or at least some people to share their experience and answer practical questions.
And yet there is still only "you doing it wrong, and I won't tell you how to do it right"
IPv6 existence is questioned not because people fail to configure it. It’s because they do not understand the problems it solves. Those problems are so large they’re invisible at the individual human scale. You either know them (which is not a secret) or invent superficial charges against the design.
3 replies →
> less obvious benefits
if they are so unobvious that nobody knows about them, perhaps they are not benefits at all, but fringe minutiae?
Perhaps. Who knows? <<< that’s the point I’m making.
> such a yawning chasm of gaps in knowledge ... in a forum whose users are generally known to be more technically savvy
There is a heck of a Dunning–Kruger joke to be made here.
No. It's not adopted everywhere because it's awful. At least on the data center side.
I get so many Second System Syndrome vibes off of IPv6. Surely other people must be picking it up too.
Future proofing it by jumping straight to 128 bits instead of 64. 64 would have been fine. Even with a load factor of 1:1000 by assigning semantics to ranges of IP addresses, 64 bit addressing is still enough addresses for 10 million devices per person.
If we become a galactic empire, we will have to replace the Web anyway because every interaction will have to be a standalone app or edge networking that doesn’t need to hear back from the central office for minutes, hours, days anyway. We could NAT every planet and go on forever.
The point is not really to support a galactic empire, the idea is that you have a network part and an interface part, each is 64 bits. The "network" part is used by routers, the interface part is to identify the device on the endpoint. Each interface have an identifier that is world unique (usually based on the MAC address), each network is also unique. Usually, your ISP gives you a /48 prefix, so you have 16 bits for potentially 64k internal networks. This way, you don't need something like DHCP to get an address, you just take it and you won't have conflicts.
But because you have two independent unique parts, you need twice as many bits, so 64+64=128 bits. It simplifies routing and address allocation, at the cost of 16 bytes per packet compared to 64 bit addresses.
That we could use IPv6 on galactic empires is an added bonus, but not really the reason.
Bypassing the router to get to the device directly via IP sounds like insanity. Like a forever-open port.
8 replies →
> Future proofing it by jumping straight to 128 bits instead of 64. 64 would have been fine. Even with a load factor of 1:1000 by assigning semantics to ranges of IP addresses, 64 bit addressing is still enough addresses for 10 million devices per person.
128 bit is like the least of adoption issues and basically meaningless difference vs 64.
But it shows weird priorities when they decided 128 then immediately wasted half of it on host part just to achieve "globally unique" host part that isn't really all that useful characteristic of the protocol.
IP addresses were always meant to be globally reachable. Of course, NAT has corrupted this - which is why NAT is a scourge.
2 replies →
> to achieve "globally unique" host part that isn't really all that useful characteristic of the protocol.
That's the essential part of self-configured addresses in IPv6 that does away with DHCP in most cases. DHCP is a stateful system that has to track every device's addresses individually. You don't need that with IPv6 thanks to this.
2 replies →
64 bits would have been much easier to read and transcribe. It does matter.
I kinda think we could fix/save IPv6 by taking away almost everything but the 128-bit address extension.
6 replies →
Don't think the problem is 64 vs 128. I don't think the problem is end users either, the vast majority of which don't even know what the IP protocol is in the first place (nor should they). The fault I think is on ISPs.
I use hyperoptic in the UK, if you replace the original router (which reserves the external 443 port for itself, i.e. no one sophisticated would keep it), there seems to be no way to get a v6 address. This is pure incompetence and carelessness. Like ISPs allowing their network to send packets spoofing IPs from outside their network. Add to that foreign ISPs (which means that even if your own network supports v6, you need v4 support when you are on holidays/travelling), and you have a situation where v4 cannot simply be switched off.
So for a website, what is the point of supporting v6 if v4 is never going away?
It's understandable that IPv6 would be ambitious rather than incremental given the cost of rolling out a new protocol; the bells-and-whistles IPv6 design is probably just a relatively small constant factor more expensive than the simplest possible address space expansion. Viewed that way, you only get the one chance to update the protocol, you might as well fix whatever you can.
It's not Second System Syndrome. Nearly every complaint against IPv6 is downstream of the decision to enforce a global centralized namespace for an end-to-end principle many don't care for.
e.g. Getting a unique address would be way more risky with 64 bits (there's a reason UUIDs are 128 bits too!), even before considering the network:interface split.
> Future proofing it by jumping straight to 128 bits instead of 64.
It's hard to disagree with your point since 64 would definitely have been better than the 32 we have. I'm not convinced the choice of going for 128 bits posed any real challenge to adoption though.
The irony that I forgot to voice is that if we had gone 64 and feeder features we’d be farther along in adoption now and probably be consuming the address space at least a fraction as fast as people feared.
By raising the barrier to entry so high we guaranteed the features would likely never be needed.
2 replies →
how would you do SLAAC with 64 bits?
Was DHCP so bad? It carries information important to using such a device anyway.
4 replies →
The same way you do it now. The router announces a prefix, and devices negotiate unique addresses.
Keep in mind that SLAAC isn't. Modern IPv6 stacks use privacy addresses, so they still need to run the address collision detection.
There's also a proposal to have SLAAC with longer prefixes, because otherwise you need to use DHCP-PD if you want to have subnetting in IPv6.
You don't, and that's fine.
> For many, the decision of which protocol to use was easy because IPv6 didn't add features that represented major improvements.
This is the obvious and only key to this puzzle.
We tech nerds have this mad idea that everyone will want to spend time and money adapting to new standards because they're technically better in some abstract way, and so we do absolutely no work to create incentives for anyone to switch. Often, the new standard is not (yet) even functionally equivalent to the old one (e.g. Wayland), just to make doubly sure the switch will be as difficult and undesirable for end users as possible.
And when the absolutely inevitable consequences occur - stakeholders do not want to invest in switching to or developing for new standards that give them zero incentive to do so - there's a silly finger pointing game, as though everyone was supposed to switch, and they've failed to do so. Which is, of course, absurd. People don't owe us compliance.
Do not expect to be able to successfully shift behaviour unless you give people incentives - reasons they would want to switch, not just reasons you want them to switch.
If it ain't broken, don't fix it. Life is short
Everything I know about IPv6 comes from this one blog post: https://apenwarr.ca/log/20170810. It’s from 2017, when IPv6 adoption was 17% according to https://www.google.com/intl/en/ipv6/statistics.html; today it’s close to 50%.
I'd assume a lot of this is because of mobile devices of some type. Getting legacy network operators like cable providers to supply IPv6 has been hell.
Eyeball networks and cloud providers have been implementing IPv6. In the US all major phone carriers are v6 only with XLAT, the large residential ISP all have implemented v6 (Charter/Spectrum, Comcast/Xfinity, altice/optimum). The lagging networks are smaller residential ISP and enterprise networks.
In Asia they've implemented v6 everywhere pretty much because their v4 allocation is woefully insufficient. APNIC has like 4 billion people in it but less IP space than ARIN, with a population of less than 500 million.
5 replies →
> Getting legacy network operators like cable providers to supply IPv6 has been hell.
In my experience it's actually the large enterprises that are having issues.
Is that worldwide adoption or adoption in the US? China went from almost nothing to 77% adoption is just a few years because they included it in their last 5-year-plan. How much of that adoption would be explained by China alone
Google's stats are Google International, i.e. everywhere Google provides service. Whether that includes China depends on the whims of the Politbüro.
That's the best thing I've read all year. Ok, it's the best thing I've read last year too. I kinda knew all this stuff but I never knew how it all happened. I never thought of MAC as unnecessary in an IPv6 world.
IPv6 has already won on mobile and been gaining fast traction in IoT space with Matter. The reason IPv4 is still around everywhere else is because we came up with ingeniuous techniques that squeezed the heck out of IPv4 address space. Also, IPv4 addresses are easier to type. That's pretty much it.
I had mentioned some of that in my post: https://ssg.dev/ipv6-for-the-remotely-interested-af214dd06aa...
Yes, they are easier to type, and to remember, and it turns out, that's actually a big deal! When you are troubleshooting network problems, it's really nice to take everything but simple raw addresses out of the picture. It's really nice to be able to look at an address and instantly recognize if it's on the same (V)LAN as you are expecting, if it's unique, if it changed from what it was last time you checked, if it's an address for a VPN interface, if the packet you are sniffing is for this host or that host, if DNS is resolving correctly, etc., etc.
I agree that it's a big deal. IPv6 has some "well-known short addresses" to alleviate this issue like accesing well-known broadcast addresses etc with `fe80::` prefix, but it's sad that they don't have one for the gateway (something like `fe80::1`). I know that there's a reason for that like supporting multiple network connections, but just have a shortcut for the "first gateway" at least which is the most common.
You can do the exact same thing in V6 if you want, there are so many extra bits you can have DHCPv6 or assigned addresses pack all kinds of things in there. With ULAs there are 16-bits for network ID, which is so sparse you can type the VLAN ID in decimal and ignore that you're losing the overhead. People will often put in joke address like deadbeef that can be fit into hex (the 40-bit global ID should be random but for hobbyist purposes most people are willing to suffer re-numbering it in the unlikely event their homelab is bought out by IBM). If you'd rather eat into the interface id portion, you can technically do whatever you want in there although packing too much in may locally cause problems in some routers if you try to treat it like additional network id bits. It's the equivalent to have both middle bytes of 10.x.y.z available for whatever while still having a few hundred billion available subnets.
Just as an example google's public DNS is 2001:4860:4860::8888 because their v4 dns is 8.8.8.8.
Everyone who says this is a web developer. I have yet to actually meet someone with networking experience who has this opinion.
The reason it's not winning in the other places is because Network engineers hate IP version 6 as a rule .
It makes sense that it's won on mobile. In that scenario, NATs are stupid and lots of addresses are needed.
In the data center, fewer addresses are needed and NATs are vital for security.
Could you please elaborate on what's wrong with it compared to 4?
Where IPv6 is struggling the most is corporate networks. There are many network admins that are afraid of IPv6 and don't want to learn about it, so they just block it at the gateway.
>won on mobile and been gaining fast traction in IoT space
The two worst uses of the internet.
I dunno. A library with a great big chunk of all human knowledge, in my pocket at all times? That sounds like a freaking miracle to me.
My prediction [0]: It will take roughly 100 years for IPv6 to be ubiquitous enough to shut off IPv4. That's not intended as hyperbole, if anything it's an understatement.
Because, it's not going away: You can talk all you want about how IPv6 should have been a more straightforward expansion of the address size, but this is all in the rear-view mirror at this point. IPv6 is going to be with us forever, you may as well get used to it. It's already everywhere in 5G deployments, ISP's like Comcast use it for 100% of their out-of-band management, China is making huge progress moving to it as part of their 5-year plan, India is progressing nicely in their transition, the list goes on. We're already way too far along in the transition to abandon it in favor of something else.
But it's not going to happen any quicker than we've seen, either: There's no urgency (no "must-have" use case) except for what organizations are imposing on themselves. Yeah, IPv4 addresses are more expensive, but you don't really need many of them as a business (you can get by with a small handful of public ones, and just using L7 load balancers and SNI for everything) nor as an ISP (CGNAT can get you a long way.)
So we have a situation where things are migrating very slowly, mainly only in places where it makes sense (mobile deployments, home ISP's where the users don't actually administer the network), and generally mostly for new deployments. This is a recipe for IPv4 to be around for a very, very long time. We're used to technology moving at breakneck pace, but that's only the case for the higher-level stuff. The core infrastructure like the internet protocol is likely the textbook example of slow-and-steady, and a case where it's actually not crazy to think of centuries-long timeframes for things.
[0] Barring any unforeseen black-swan events like a world war destroying all technology and having to rebuild from scratch or something. Or a competent international agreement to aggressively migrate to it (I don't know which is more likely.)
I’m honestly a bit surprised that the move to v6 has even been this strong considering the arguably-small-but-clearly-significant-enough downsides.
The world could pretty easily run on heavily NATed v4 for a long, long time.
My ISP refuses to give you a static IPv6 prefix unless you're a business customer, despite having an "unlimited" amount of them. This results in me not bothering to set it up properly and focusing on IPv4 still.
Do you have a static IPv4, presumably a single IP?
I find it useful, mine does change periodically, but I just have a script that Updates DNS when it changes:
Sure some services might notice for a bit, but it's plenty good for me.
I don't have a static IPv4 address and I have to use a DDNS built into the Caddy plugin on my OPNSense router. From what I understand, you can't get a static "local" (I know, IPv6 has no direct equivalent) address to use for a reverse proxy — at least not in an easy manner. I might be completely wrong but that's why I don't bother with IPv6.
5 replies →
I technically have a dynamic IPv4 address from my ISP. I've had the same for five years now, across multiple power outages.
I also have a dynamic IPv6 prefix. That one changes at least once a week, regardless.
My ISP is xfinity. They say the same thing but my IPv6 address hasn't changed any more frequently than my IPv4. In my experience it changing isn't any more annoying than my v4 changing so I'm not sure why people still get up in arms about it.
In about a year of treating my comcast-assigned ipv6 address as static, it changed once.
Sadly, this happened despite me specifically requesting the same address as always. That caused me some grief. But it's not common.
4 replies →
This should be illegal. Yes, in this case, I'm not saying that as a figure of speech. ISPs are a utility, and building that kind of artificial scarcity into something that is really damned near infinite is highly anti-consumer.
Get a virtual server and do the things on it that you'd want a static address for. Use a VPN connection back to your home to merge it with your network. This is a great way to deal with CGNAT.
My ISP (naming no names...erum...Spectrum) refuses to even admit they know what IPv6 is. It's like asking the NSA what Menwith Hill is for...
https://www.spectrum.net/support/internet/ipv6
https://www.spectrum.net/support/internet/ipv6-faq
> IPv6 is available today with an IPv6 capable modem in the majority of Spectrum’s footprint.
I've had v6 on spectrum for 5 years
For those in the UK who want a static IPv4 or IPv6 block AAISP offer a L2TP service for £2/month. It's limited to 3 megabit/s but might be enough for some use cases.
I recently moved house and looked at a new offer from a new ISP for a long term lockin but a cheap price. They used CG-NAT. I instead chose one which gives me as many ipv4s or ipv6s as I can reasonably use, doesn't oversubscribe its upsteam connectivity etc.
For home internet service I would prefer to pay extra for a better service, it's too important to try to penny-pinch 0.1% of my income on it.
But then I live in a capitalist country where there's competition, I believe some countries you don't get a choice.
FYI it's practically impossible not to oversubscribe your upstream connectivity unless they either spend way too much money or offer very slow service to users. Consider ten thousand users with 1G connections - should they have 10 terabit upstream?
The more practical thing to look for is that they aim to upgrade it based on need, instead of arbitrarily throttling the users.
1 reply →
Same here, I had a working IPv6 setup previously with my DSL provider, but now that I moved to a fibre connection, the new one refuses to support it.
But do they give you PD?
My prefix is tied to the mac address of the device that's connected to the PON.
It was doomed the moment you had to maintain two separate stacks, each with its own address, firewall rules and so on.
It should have been ipv4 with extra optional bits, so you could have the same rules and everything for both stacks.
I turn it off because it's a risk having one of either stacks malconfigured.
IPv6 should've been a superset of IPv4, as in addresses are shared, not that you have a separate IPv4 and IPv6 address for your server.
That’s why my home network is IPv6 only. NAT64 and DNS64 and 464XLAT work very well, and you only need to configure IPv4 once: in your router, where you need special configuration anyways.
for me, I don't need to even setup NAT64. My ISP provides it for me free.
What do you do about IoT devices?
2 replies →
Another day, another Godwin's law of networking.
>It was doomed the moment you had to maintain two separate stacks
Pray, tell me, how are we supposed to extend IPv4 with another {insert a number here} bits without creating a new protocol (that neccessitates running two stacks)?
Suppose that you have an old computer that understands only 32 bit addresses -- good ol' IPv4. Let's name it 192.168.10.10.
It then receives a packet from another computer with hypothetical "IPv4+" support, 172.12.10.98.12.4.24.31... ...Wait a minute, it can't, because your old computer understands only 32 bit addresses!
What if we really forced it to receive the packet anyway? It will see that the packet is from 172.12.10.98, because once again, it understands 32 bit addresses only.
It then sends back the reply to... you guessed it, 172.12.10.98. Not 172.12.10.98.12.4.24.31.
Yeah,172.12.10.98.12.4.24.31 will never get its reply back.
Do you see why any "IPv4 with extra octets" proposal are doomed to begin with now?
It wouldn't be able to receive it. That simple. Which is not a problem, any server would still have an old ipv4 address (172.12.10.98 from your example), like they currently do and probably will for decades.
1 reply →
Having just optional field in the ipv4 header with extra address bits would leave all the stack source code with just some 100 lines of extra code. Would mean, you can have one stack that handles just both. Make special addresses where the additional bits are all 0, which means the field is not there at all. These addresses could reach ipv4 only addresses and could be reached from them. When you really want to make sure these devices aren't parsing ipv4+ packets, change the checksum-code for all packages that contain the optional field. That would mean all ipv4 only devices would ignore ipv4+ packages. Instead you could change the version to 5 for all with optional address bits.
This is stuff that could be implemented in any ipv4 stack in some days of work.
IPv6 is overengineered, thats the reason why it's not adopted after 30 years.
1 reply →
And 2 listeners
I remember 10+ years ago we were going to run out of IPv4 addresses and it was the next Y2K unless you adopted IPv6. I was able to get IPv6 for my servers and home, and I thought I was safe!
> "In fact, IPv4's continued viability is largely because IPv6 absorbed that growth pressure elsewhere – particularly in mobile, broadband, and cloud environments," he added. "In that sense, IPv6 succeeded where it was needed most, and must be regarded as a success."
Apparently it turns out IPv6 wasn't for me any way!
It kind of has. The majority of internet traffic is IPv6. The three biggest internet hub regions (USA, Europe, China) have IPv6 mandates. Most apps support IPv6. Google and Apple force them to, od they get kicked off the app store. Almost all mobile networks (which means almost all end devices) are IPv6-only, with slow inefficient tunneling for IPv4. The price of IPv4 addresses is declining.
At what point will we be allowed to say IPv6 hasn't failed? When the IPv4 internet finally switches off for good? It feels like no achievement is high enough for those who don't like IPv6 to change their minds. I would've thought making up 50% of internet traffic and 50% of end devices being on IPv6-only networks would be good Schelling points, but evidently they're not!
> At what point will we be allowed to say IPv6 hasn't failed?
"IPv6 ... still hasn't taken over the world [after thirty years of deployment]." is a very different statement than "IPv6 has failed.".
Noone who has successfully extracted their head from their ass says that IPv6 has failed. It's widely deployed on the Internet, and on who knows how many corporate intranets and SOHO/home LANs.
IMO, it's stupid to ever consider turning off IPv4. There surely exist useful systems out there that will never be updated to work with IPv6.
I see IPv6 as an "IPv4 address pressure relief system". In the future, SOHO/home LANs can run servers on IPv6, datacenters can run servers mostly on IPv6 but also v4 if they really want, and SOHO/home networks can be behind an IPv4 CGN because all of their unsolicited inbound traffic will come over IPv6.
>IPv6 ... still hasn't taken over the world [after thirty years of deployment]." is a very different statement than "IPv6 has failed.".
It's incredibly likely that the GP was referring to comments in this thread, which were indeed claiming that IPv6 has failed, despite the fact that its deployment has been steadily climbing up worldwide.
By the way...
>In the future, SOHO/home LANs can run servers on IPv6
The future is now. My web server is IPv6 only precisely due to the same reason you mentioned: my ISP has put me under a CGNAT. People can still connect to my website through the Cloudflare reverse proxy though (which I have only enabled for IPv4, IPv6 users get to enjoy direct connection).
1 reply →
The majority of traffic might be IPv6, but the majority of people using and understanding IPv6 is not.
Wait, so, what people are we talking about? Nearly everyone uses domain names.
I've been native IPv6 at home for a few years now. That worked flawlessly until a recent Windows 11 update somehow broke IPv6 in ways that I don't entirely understand. All the other Linux and Apple and et cetera things in my house are fine, but the Win11 laptop just refuses to handle certain IPv6 ranges (specifically including the address that the host interface for one of my web servers falls in). 100% contained within the Win11 device and TBH I can't be bothered to dig into it further so I just proxy through some other device that does work. (Guessing it'll get fixed a month/year/decade or so from now.)
I agree it's not a failure, but after 3 decades it's still frustratingly annoying to use at times.
I had a much less annoying time with ipv6 on windows after I explicitly disabled all ipv6 tunnel interfaces.
https://learn.microsoft.com/en-us/troubleshoot/windows-serve...
> I agree it's not a failure, but after 3 decades it's still frustratingly annoying to use at times.
Anyone sane would call a standard that remains annoying to use after 30 years a failure.
I agree. Windows is a failure.
Maybe a different take, but as someone that manages a large public API that allows anonymous access, IPv6 has been a nightmare to try and enforce rate limits on. We've found different ISPs assign IPv6 addresses differently - some give a /64 to every server, some give /64 to an entire data center. It seems there is no standard and everyone just makes up what they think will work. This puts us in an awkward place where we need abuse protections, but have to invest into more complicated solutions that were needed for IPv4. Or we give up and just say if you want to use IPv6, you have to authenticate.
Does anyone have any success stories from the server side handling a situation like this? Looks like cloudflare switched to some kind of custom dynamic rate limiting based on like addresses, but it's unrealistic to expect everyone to be able to do such a thing.
The ISPs assigning only /64s to whole data centers are not following the standards and best practices. For rate limiting I would block at the /64 level. Just like if someone is behind a CG-NAT they might run into ip reputation issues. They need to complain to their carrier about the poor service/configuration or switch providers.
Common practice is to block no finer than /64s. If you treat an IPv6 /64 like an IPv4 /32, you should be off to the races.
I use multiple Google accounts to segregate the data that gets collected on each one - as I don't like having, say, TV logged in to the same account where I send my emails from. One of them, which I use exclusively for Gemini, was banned today (I violated no policies, Google just doesn't like the way I try to sanitize its access I guess).
Now, I can simply restart my router (or cycle airplane mode on mobile) and get a new IPv4 that probably was used by bazillion people before me, or even along with me, and get a new account. So Google has to be very careful here, with IP-linked bans in order to not just ban the whole load of unconnected people just because they used the same IPv4 as me.
With IPv6, they could just ban my entire family and any guests that might have connected to my WiFi, forever.
I like the limitations of IPv4, thank you.
Doesn’t IPv6 have random, anonymous addresses (RFC 4941)? Further, user fingerprinting flourishes without IP addresses.
> Doesn’t IPv6 have random, anonymous addresses
Only for the device identifier part of the address. Prefix that the ISP will allocate will remain static, unless ISP does rotate the prefix too, which they don't really have a need to, unless for privacy reasons. And knowing ISPs and demand for privacy, it's highly unlikely to happen.
> Further, user fingerprinting flourishes without IP addresses.
It does, but is still hard to do. Static IP prefix is going to make the heuristics much, much better.
Besides, evading most of the fingerprinting techniques is not that complicated - most of it is in the hands of the client. IPv6 adds something out of the hands of the client.
1 reply →
The problem is google
Yes, it is. But it's not just Google. User fingerprinting is already a massive market and is growingly user hostile. There's at least one HN post each month of someone losing access to their account for no real reason and no way to get it back.
I don't want internet infrastructure to support this behavior. On contrary, I want it to resist it, and IPv4 does, to some extent, while IPv6 makes it much easier.
I think 30 years should be much more than enough to realise the idiocy of proposing a non-backward-compatible standard to the general public.
We replaced VHS with DVDs. It took 42 years before we gave up on VHS. DVDs have been around for 29 years but were mostly replaced with BDs before disappearing off the shelves in favor of streaming.
We replaced records with tapes, tapes with more tapes, and more tapes with CDs before they, too, disappeared from the shelves in favor of streaming. Except that some stalwarts have successfully resurrected vinyl.
We replaced AM with FM, and analog radio with digital radio, then streaming. We replaced broadcast analog TV with digital, then cable and satelite, then streaming. Mostly.
None of these changes were backwards compatible, and all of them were meant for the general public. They took a while. They were successful.
The quality jump from vhs to dvd was massive. In comparison v6 doesn't offer much above v4
Anyone who bought DVD player immediately had the benefits of better quality. The same applies to all other examples.
The problem with IPv6 is that you don't get benefits. If the designed protocol needs an equivalent of big bang, it's doomed. ASCII->UTF8 didn't need big bang. x86 to Itanium needed big bang.
Yes, I've never played a DVD or CD on my Bluray player. That just didn't works.
You'd think it would be long enough for people to realize that v6 is backwards compatible! Yet no, here we are, constantly dealing with people making the same damn claim that it isn't every single time a v6 story is posted.
v6 is about as backwards compatible with v4 as it's possible to be. If you have a way to make it more backwards compatible then I'd love to hear it, but when I ask this all I ever get are things that don't work, or things that v6 already does.
No, it's not. If I have an ipv6 network, an ipv4 address is invalid. It's that simple.
4 replies →
It's often impossible to make backwards-compatible changes to a format which wasn't designed to allow for future changes and which is designed to be as space-efficient as possible.
That doesn't mean that the limits of the old design won't hit anyway and force a switch off it.
IPv4 allows future changes. There are some reserved bits in the header that could change a big part of it.
1 reply →
The problem is that IPv4 has no provisions to be forward-compatible with anything with a larger address space. Thus whatever replacement you can think of will have the same problems as IPv6.
I was in college when v6 was going through the RFC process. In my networking class we had to learn Netware (IPX) and v6, which have both turned out to be equally irrelevant, for different reasons. At this stage, I fully expect to retire having never deployed a single resource using v6.
I'm genuinely wondering if western governments (UK) will start issuing ipv6 addresses out to citizens as their digital id so they can track them online and offline.
Only half joking, some UK MPs might actually consider this a reasonable thing considering how many ipv6s there are.
That wouldn't work anyway. IPv6 addresses aren't routable on an address-by-address basis.
Whether it's workable or not it's besides the point when certainly the UK gov gets it in mind to implement.
Yeah but the digital ID could be the 64bit suffix of the IP. Kind of like that horrendous and moronic idea of using the MAC address as the suffix.
But Mobile IP could do it https://www.rfc-editor.org/rfc/rfc6275
2 replies →
Since ipv6 is just a 128-address, you could say any unique national ID is already an assigned ipv6. Heck, if you assign your services a UUID, you have also already assigned them an ipv6.
What makes an ipv6 useful is that you can route to it. Since you will never be connected to the network. The network will never be able to route packets to you, making the whole thing a little pointless.
We're not routable yet. Fairly certain people are trying to create computer/brain interfaces...
I'm thinking the gov issuing you an ipv6 address that you must use to connect to the internet. But it's also you're id too, since nearly all services are either online or getting pushed that way.
Contrary to some other comments: no, IPV6 hasn't taken over the world at all.
In my case, I administrate a small server at home, where I self host many services that are made available to myself, friends and families, over the internet.
In that context, IPv6, is SADLY (please note that I have NOTHING against IPv6), a limitation, even a nightmare to use.
Some programs do not handle IPv6 at all. Game servers for instance, do not support it, the one that I think about is: Arma 3. But there are many others
In 2025 (and 2026 too?), 4G (5G?) operators do not all route over IPv6 -> which means that if your domain only has a AAAA record, some people using 4G will not be able to access ANY of your services. This issue forced me to beg my ISP to obtain an IPv4 "fullstack" as they call it.
Without that IPv4 you have to go through some kind of tunneling (like Cloudflare) -> and guess what? Cloudflare sometimes crashes (it happened super recently remember?) and in that situation -> ALL your services accessible through the tunnel are "down" for your users. Plus, it is EXTREMELY unsatisfying to rely on an external private-owned service for a selfhosting project.
In almost ALL context IPv6 is seen as optional, additional, additional configuration and is NEVER the default. NEVER. Which means: more configuration, possibly more struggle.
>ALL your services accessible through the tunnel are "down" for your users
Not all.
I operate site with IPv6 only origins behind cloudflare.
During the outage I manged to login to the dashboard after some time and remove cloudflare for nearly 2 hours, and traffic level stayed close to 50% during the IPv6 only period.
Nobody complained: those who did not have working IPv6 probably blamed it on cloudflare.
> traffic level stayed close to 50% during the IPv6 only period.
> Nobody complained: those who did not have working IPv6 probably blamed it on cloudflare.
You described a situation where the outage resulted in 50% of your customers were unable to reach you and you were unable to do anything about it. I don’t think this story is a win for IPv6, regardless of whether your customers blame CloudFlare or not.
5 replies →
> In almost ALL context IPv6 is seen as optional, additional, additional configuration and is NEVER the default.
Weird. The past two ISPs I've had (Comcast and Monkeybrains) both had IPv6 enabled by default. I've looked at a bunch of SOHO networking gear and IPv6 is on by default. On every Linux and Windows system I've touched in the past ten, fifteen years you have to go significantly out of your way to disable IPv6.
> Some programs do not handle IPv6 at all. Game servers for instance, do not support it...
Depends on the game server. Many I run absolutely do.
Your complaints smell like you tried to run an IPv6-only client network, which would be an absolute nightmare. That's just a stupid thing for a SOHO network (and the networks that serve most corporate client hosts) to do. IPv4-only Internet hosts exist, so it's a no-brainer to provide IPv4 connectivity to clients.
On the other hand, running IPv6-only infrastructure networks can make a ton of sense. One very large such operator is Comcast, a US ISP.
Most 4G networks are actually IPv6-only, with IPv4 traffic being routed through inefficient tunnel systems. This is why Apple and Google require all mobile apps to use IPv6.
Certainly not all networks. Optus (Australia's #2 carrier) for example does not support IPv6 at all on their mobile network.
I have fiber to my house and no native IPv6 support. I did some research and it seems there is a way to enable IPv6, but it’s janky and just tunnels over IPv4 so what’s the point?
I would love for IPv6 to actually take off but somehow it feels like we are still a decade away from ubiquitous adoption.
I have Verizon Fios and after they upgraded my network speed from 1G to 2.5G and ONT to some "next gen" one I lost IPv6 support because supposedly this newer ONT does not support it, lol. Verizon is going backwards.
so it turned into a good ol' legacy problems
idk if arma3 does server discovery, but in case of manual ip input there some kind of OS-networking-level adapter should help. Usecase seems too obvious for something like that not to exist
https://www.google.com/intl/en/ipv6/statistics.html it's still going up (we are in some sort of cyclic downturn right now that I don't understand).
Next year that chart will finally cross 50%. It was a mere 30% in 2030. Developing country mobile phone networks will continue to push it higher.
All we need to do is start having rich governments mandate IPv6, and also mandate IPv4 downtime as a punishment for those that don't comply / chaos engineering for the system as a whole. Then we can quickly finish the job.
> we are in some sort of cyclic downturn right now that I don't understand
consumer networks have significantly higher adoption rates compared to corporate/edu, and people are on vacations during summer
Ah OK, there are workday/weekend and vacation/no-vacation cycles. Gotcha.
Well, to the extent the rich country laggards are institutional, then regulation should be more effective!
I can't help but think that numbering all the devices was the wrong idea from the beginning. You don't want to talk to devices, you want to talk to (and offer) services. You probably need something like an AS number to make global routing efficient, but 32 bits would be plenty for that. A packet could be (destination AS, stream ID, encrypted( payload )) and DNS would give you a capability (destination AS, stream ID, keys) for a service. You send a packet to that stream asking to open a connection and providing a capability to reply (with a capability for the specific stream). Your network up to the AS level should have an opportunity to augment the stream IDs in whatever way is convenient for its routing. No one reveals any topology information, network neutrality and a degree of privacy is guaranteed at the protocol level, only really serious multipeer networks need to assign addresses above layer 2, and I think it would be reasonably easy to come up with an edges first incentive compatible transition plan (which is where ipv6 went wrong).
(This is of course an incomplete and poorly thought out proposal, you don't need to dogpile me about that.)
The problem with IPv6 jokes is that very few people are making them.
Correct me if I'm wrong, doesn't it make you leak your IP outside local network? I'd say this is a great turn off especially nowadays when it will be used for sure for tracking
I'm not sure what you mean by "leak your IP" since IP address is always how you communicate. I guess you mean you no longer have a 192.168 or a 10. address that is "hidden" from the Internet for whatever value that has? One nice thing about IPv6 is your local client can continually change their address if they so want (and this is actually a common feature) to disrupt tracking. Sure you have the same prefix, but that's exactly the same boat you were in with IPv4 and NAT.
So this 'feature' is just a fix for the issue with tracking that would not be there with ipv4 beside that my internal ip's are changing every day to bring more confusion into my internal net. nice!
3 replies →
Nothing have given me more issues than ipv6. Every time I've tried to use it, it gives me so much headache I just give up. I'm not even sure my ISP supports it. My router doesn't get an ipv6, and called my IPS. After going through 3 different people over 2 hours I just gave up. I just hope I get put behind CGNAT...
IPv6 continues to rumble along, gaining market share, because China. Increasing IPv6 adoption was in the 14th Five Year Plan, and about 75% of mobile in China is now IPv6.
I started looking at self-hosting many applications at home once I realized that IPv6 could enable me to do that securely without any complicated router/firewall configuration that would need to be maintained.
The only wrinkle I ran into is that apparently ISPs are still reluctant to give out static IPv6 prefixes to residential customers. So you still need some kind of DDNS setup, which is lame.
IPv6 is already here if you're not in the US. I moved house last month and consumer ISPs don't offer a (real) IPv4 connection in my country any more; you get an IPv6 connection and your router does MAP-E if you want to send data over IPv4.
I want to echo this comment. I am on Map-e in Asia and it is very difficult to get an exclusive ipv4 address without paying extra money.
And I want to connect to my machines without some stupid vpn or crappy cloud reverse tunneling service. Not everyone in the world wants to subscribe to some stupid SaaS service just to get functionality that comes by default with ipv6.
I think Silicon Valley is in a thought bubble and for people there ipv4 is plentiful and cheap. So good for them. However, the more these SaaS services delay ipv6 support, the more I pray to any deity out there I can move off these services permanently.
Yesterday I was required to turn on IPv6 on my router, while setting up some IoT things using Matter over Thread. Apparently that protocol uses IPv6 and doesn't work if your router is only routing IPv4.
There is a rich history of IoT devices using IPv6 to communicate among themselves without relying on the cloud. I think Nest started this trend. One Nest device sends a specific RA to make itself the router of all other Nest devices. All other devices can configure themselves thanks to SLAAC. The benefit of v6 is that there are so many addresses out there that the Nest device can just pick an arbitrary ULA and there won’t be collisions.
Don’t know about Matter though. If it requires the user to turn on IPv6 then it’s a user experience downgrade. It should just use IPv6 internally as an implementation detail.
That's incorrect. Matter-over-Thread absolutely does NOT require IPv6 on your router. Even Matter-over-WiFi will happily work in IPv4-only networks, as long as your router does not filter the IPv6 announcements.
Some routers can work as _relays_ between the Thread network and WiFi, but this is entirely optional.
iirc some of the matter devices want/need connection to the mothership outside. hence ipv6 on router
this is one of reasons why i stick to z-wave. totally self contained.
DJB understood the problem decades ago. https://cr.yp.to/djbdns/ipv6mess.html
Not really. DJB’s clearly a very, very smart person, but he missed the mark on almost all of that. The problems he described which are real have been satisfactorily solved; they weren’t intractable. The rest turned out to be non-issues.
Also, his proposed alternative solution (essentially expecting someone to change all software and hardware in the world first, and then have a flag day with zero operational experience) was completely non-workable. Well, actually the document is so vague that you could interpret his “solution” in like three additional different ways, but none of them make much sense.
Intriguing take that he "missed the mark", yet we are still utterly dependant and reliant on IPv4 30 years later since v6, the situation he essentially predicted. How much longer until IPv6 becomes the incumbent?
IMO we need to rethink routing for IPv6 so we can finally reduce pressure on router tables and finally cause pressure to ditch IPv4. Here are some of my thoughts on that elsewhere in this thread: https://news.ycombinator.com/item?id=46471898
But here's a more thought-out design:
- register a well-known IPv6 prefix with 20 bits reserved for AS number
- so we'd have ${well_known_prefix}:${AS_number}:${customer_prefix}:${end_entity} (not necessarily that format for display, but just for the purpose of getting the idea across here)
- have DNS servers return AAAA RRs with the AS number filled in
- DNS servers should either have the correct AS numbers filled in their zones, or possibly could subscribe to the RPKI and use the RPKI for mapping ${well_known_prefix}:${all_zero_AS}:${customer_prefix}:* to AS numbers, then fill them in (this would require live signing if using DNSSEC, which is f-i-n-e fine)
- if there are multiple AS numbers for a $customer_prefix, then return multiple AAAA RRs, or if EDNS0 indicates client support for it, one AAAA RR and N RRs of a new type that carry only the AS numbers
- update core routers to route these prefixes based on the AS number in the address
- update edge routers to replace the sender's AS number in its address if its address is below the $well_known_prefix -- this takes care of the return path
- update internal routers to use only the $customer_prefix and the $end_entity for routing for this $well_known_prefix
- end entities should ignore the AS number when receiving packets, thus allowing multi-homing (i.e., let source and destination IPv6 addresses match ${well_known_prefix}:*:${customer_prefix}:${end_entity} for socket 5-tuples)
- for backwards compatibility end entities should map these addresses back to whatever the application used in its calls to bind() and connect() (i.e., if the app found an AAAA with the AS number filled in and used it for connect(), but the ${customer_prefix} is multi-homed, then accept packets from all those homes) (apps should make sure to use TLS / QUIC for security, naturally)
- when an end-entity sees a change in AS number for a peer's address matching a socket 5-tuple then update the peer's AS number / address in the 5-tuple -- this allows for migration and better path finding
I think something like this could be deployed with relatively little effort.
Is there yet answer to question "how to get random self-assigned addresses into dns records, firewall rules and switch acls?" ?
802.1x instead of switch ACLs SSSD (Linux) or Active Directory (Windows) or other more custom solutions for dynamic DNS Firewalls rules that use those dynamic DNS names
Bonus: the relatively recent RFC 9686 that I hope will get some good traction: https://datatracker.ietf.org/doc/rfc9686/
Dynamic DNS, DHCP, and static assignment are all still part of IPv6. Putting single IPs in switch ACLs is an anti pattern. Consider zero trust or working with whole subnets(they're plentiful in v6) instead.
Every IPv6 networker fan has rabidly torn me to pieces when I asked how to deploy DHCPv6.
Apparently it's "not how it's done" and we're "doing it wrong".
My SOHO equipment doesn't really support it either, so it's just as well, staying on IPv4 which does DHCP and solves that problem.
> DHCP
Not if you're on Android. https://issuetracker.google.com/issues/36949085
1 reply →
How do you setup dynamic dns in your network? Which software do you use?
Turn off temp addresses. If your prefix changes then use ULA addresses.
I suppose I could have said how.
Windows in powershell:
Linux:
or in NetworkManager config file:
OpenBSD:
Yeah. ULA and nat66 would work nicely. Except you would get murdered for asking about nat66.
1 reply →
"Build yourself an IPAM solution, at great operational cost and complexity."
I question the premise that it’s not taking over. Our logs are at least 50% ipv6 now. A few years ago I feel like a barely saw it.
Every day I thank NAT that I don't have to memorize IPv6 addresses. I can barely manage my IPv4 numbers.
How many people here have put IPv6 addresses into the root DNS servers for their glue records? Curious how this [1] set of charts has evolved. For some reason I have only ever used IPv4 root glue records and never really gave it much thought otherwise.
[1] - https://nlnetlabs.nl/downloads/publications/ipv6/v6rootglue....
NAT is the reason for IPV6 not taking over.
Also it acts as a nice security perimeter. If all IoT devices in a home were exposed to internet, It would be absolute mess.
Setting up a firewall with an IPv6 deny inbound policy takes about 30 seconds. How is this an absolute mess?
NAT doesn't act as a security perimeter, and not having NAT doesn't mean that your devices are exposed to the Internet.
NAT is about dealing with address space shortages, not security.
This gaslighting keeps being repeated, but fact of the matter is that any consumer/home network will be exposed to the internet if they're using SOHO equipment via IPv6 and won't be via IPv4.
And huge % of SOHO routers won't even allow configuring IPv6 firewall which makes security a disaster.
6 replies →
IPv6 was obsolete by the mid-2000s, majorly due to the advent of roaming. It was designed on the rather fanciful assumption that its deployment would simply supersede IPv4, that every software/hardware vendor would cooperate, and we'd have a pure v6 network which would also replace the traditional L2/L3 layers.
Ofcourse legacy compatibility trumps all, along with the ubiquity of NATs and roaming and we're now just in the sunk-cost phase, being left saddled with a horribly bloated protocol (128-bit addresses was a marketing choice; not engineering) that solves no problems.
I love IPv6 but organizations seem to struggle with it. My ISP, for example, had issues routing it after a backend update so they decided to just turn it off. I'm now stuck on CGNAT IPv4 which results in constant captchas :/
Meanwhile, there is a whole grey market built around this. People sell “CGNAT mobile proxies” that ride on carrier and ISP NAT, and the whole point is that they are a pain to block without nuking huge ISP ranges. So they get marketed as a convenient way to dodge shadowbans, spam filters, and basically any abuse defense that relies on IP reputation.
> the whole point is that they are a pain to block
What makes them a pain to block? Angry users or some central database that lists these addresses as "do not block"?
2 replies →
It would be nice if we had a blackout CGNAT day where a bunch of major sites don't serve traffic to people behind CGNAT to give the ISPs a bit of a scare.
2 replies →
For anyone who thinks IPv6 is without merit, I recommend reading up on the various challenges of NAT traversal [1]. In cases where CGNAT is deployed in particular, there are scenarios where the only way to make everyday P2P connections work is to route traffic through a 3rd party - which can impact latency and bandwidth.
While IPv6 doesn’t make establishing a P2P connection trivial (there are still firewalls to contend with) - it does simplify things dramatically. And as someone who is behind CGNAT, I am very grateful for the existence of IPv6.
[1] https://tailscale.com/blog/how-nat-traversal-works
Is there an obvious reason why it would not have worked to just say that all ipv4 addresses are ipv6 addresses with an implicit leading 96 zero bits?
This is already a thing in IPv6 pretty much. You can write applications IPv6-only and support IPv4 via IPv4-mapped addresses (::ffff:1.2.3.4 for the IPv4 1.2.3.4). The host still needs to be dualstacked for that to work though. In case the host is IPv6-only you can use NAT64 (or similar technologies), where the IPv4-space is embedded behind some other prefix, but the application just talks plain IPv6 and doesn't have to care too much what happens in the background.
I’ve asked both ChatGPT and other users and the consensus is “NO YOU CAN’T BECAUSE YOU’D HAVE TO REWRITE THE SOFTWARE”
As if IPv6 doesn’t require a full rewrite too. So basically, no there’s no reason. They just wanted to be edgy and use hexadecimal and they’ve ruined everything.
It's hard to believe there are people that think letters in an IP have a meaningful impact.
"edgy"? Come on.
And if they used decimal I bet the complaints they didn't use hex would be just as loud and just as certain, since an IP address in dotted decimal is 50% longer than in hex.
On top of that, hex would make IPv4 a lot easier to use because of how subnets get optimized. Instead of constantly rounding to weird multiples of 8 or 16 or 32 you'd only have to deal with one hex digit at a time. And in most deployments you could skip the address math entirely by sizing your subnets 4 bits at a time: /16, /20, /24, /28.
That's in there. ::ffff:0:0/96 and 2002::/16 are for v4 addresses in different circumstances, but that doesn't address the issue of routing so there are capabilities like NAT64 that allow network operators to map their IPv4 networks via routers and it mostly works. There were exceptions, software that cares about lower level network functionality tend to break.
NAT64 works much better for 6->4 connection scenarios than vice versa, but 4->6 with specific connection pairs and careful split DNS is possible.
IPv6 is the poster child for the second system effect (or solution) [1].
IPv4 really only had 3 problems that anybody cared about:
1. Address space size;
2. Roaming; and
3. Reliable connectionless delivery; and
4. The problems created by the at most once delivery under TCP when what we really needed was at least once delivery in many, many cases.
Even the address space size problem is less of an issue than originally predicted because of improvements in NAT, up to and including cgNAT for cellular network providers (which also somewhat addressed (2) in a limited way).
Interestingly, some of the larger companies have networks simply too large for the 10.0.0.0/8 address space.
By "roaming" I mean maintaining a consistent connection while moving between networks.
(4) has kinda fallen on QUIC (now HTTP3) but this should really be core TCP/IP Layer 3.
You could also say that TCP congestion control is pretty outdated. It's not surprising. It was designed at a time before megabit (let alone gigabit) networks. And, more importantly, latency kills throughput. Some efforts have been made on this, such as Google's BBR [2], but other problems remain like MTU windows being too small for modern networks.
So what did IPv6 do? It only solved one problem, address space, and it did it in a way that kinda created new problems. First, the address space is too large (128 bits) and the last 64 bits are kinda reserved for the job that a 16 port used to do. And why was that? Originally, it was intended that the lower 64 bits were derived from a 48 bit MAC address (as used by Ethernet and later Wifi) but they realized this was a huge privacy problem so it never happened.
[1]: https://en.wikipedia.org/wiki/Second-system_effect
[2]: https://github.com/google/bbr
[2]: https://community.cisco.com/t5/networking-knowledge-base/und...
Not a counter-point, but: the other day I rebuilt my personal server, finishing by pointing the reserved IP at the new box. I then had a period of confusion because I was still seeing old content, because my browser (etc) was obviously querying the AAA record first, which I hadn't updated.
(a while ago I needed to contact support to get an IPv6 allocation at home, but that was a very quick interaction at the time)
Browsers add an additional layer of fun where they can cache an IP address long past the TTL as long as the old IP keeps responding correctly.
and it never will, because IPv4 has become a defacto reputation system for the exact same reason that IPv6 was created: a limited supply. It wouldn't surprise me to see the continued balkanization of the internet that there is a particular underclass of exclusively IPv6 traffic, but its not going to take over everything because once decentralized systems are now in the hands of a few decisionmakers in the case of, say, email.
IPv6 seems to be a great fit for 1) mobile devices, 2) massive data centers and 3) literally nothing else.
I have met zero network engineers who wanted to put IP version 6 in their network. It causes all sorts of problems and presents all sorts of security risks without much benefit other than the obvious one. In the data center, NAT is a feature, not a bug.
Instead, they provision IPv6-enabled load balancers and pass traffic back to load bearing servers using ipv4 instead.
It's a classic example of "this is the next best thing everyone should use it" which achieves some adoption but it's not really the next best thing. It's not the be all end all it purports to be.
We should just admit to ourselves that we need one kind of ip stack in some situations and another in another.
20 years ago there were a lot of peer to peer applications. For example, Skype used to bounce calls across peers. Now, all calls gets routed through big-brother Microsoft.
NAT and American assymmetric bandwidth ISPs both killed this business model and now we are stuck with tech monopolies like Cloudflare. I see this ipv4-only strategy as another monopoly tactic to kill competition.
And in Asia, it is getting more difficult not to get stuffed behind a double NAT (CGNAT), which means you can't even play games without using big-brother rent-seeker services (no port-forwarding/upnp). But at least here you get ipv6 for free and everything just works.
My gut is that this is for the best; I haven't fully fleshed it out but it feels like the practical goal of "decentralizing power" and e.g. ISPs and other powerful entities exploiting end users is easier in an IPv6 regime, and has been practically thwarted somewhat by IPv4.
I'm reminded of way back in the day when they wanted charge per user or per device in households.
Can't we just leapfrog to IPv7? or 8 for that matter?
The first thing I do whenever I see a discussion about IPv6 is to search for the jokers who talk about IPv5 or IPv7.
Evolution is the survival of good enough. IPv4 is good enough.
> but IPv6 is better
It doesn't solve any life-changing problem.
Simple reason it didn't take over: the lack of backwards compatibility with ipv4. Yes, it would have marred the beauty of the new specification. But we will continue paying the price for another 30 years.
true. I am CSE student in third year, and just started learning about networking.
We just take the sheer amount of engineering that went to designing network protocols for granted.
I'd love to have ipv6. The idea every device in my network can have its own unique worldwide address is awesome.
Having said that I still want to have a router with routing rules and firewalls and a network range I can divide into separate protected networks but in reality your home ISP will most likely give you a router with a /64 address.
You're aware of DHCPv6 Prefix Delegation? The two US-based ISPs I've used in the past ~twenty years (Comcast and Monkeybrains) use it to provide IPv6 service and permit your DHCPv6 client to request a /60 prefix to use as you see fit. It's not a /56, but it's also very much not a /64.
I'd expect "Give home users a /60 via DHCPv6-PD" to be considered "best current practice" in the ISP "community"... so if I switched to another ISP that claimed to provide IPv6 addresses, "ask for a PD-assigned /60" would be the first thing I'd try.
I don't know about anyone else's reasoning but personally IPV4 works just fine for 100% of my use cases.
I don't have anything against it per-say but I have no reason to use it either.
IPv6 is the protocol of the future. And will be.
IPv6-only is the future for mobile phones, and mobile devices are the future of the internet.
And it is consumer devices (and IoT devices) which are the most numerous and also the most price sensitive, and this is where IPv4 is disappearing first.
Solution looking for a problem is why. No value is why.
Breaks NAT privacy and the extensions do not do enough.
Top down pushed solution NOBODY WANTS.
Unfortunately, TIL that Linux doesn't use DNSv6 if DNSv4 is available ;(
https://github.com/systemd/systemd/issues/16322
That seems to be about resolved, part of systemd, not Linux?
it's resolved in the sense of "won't fix".
systemd is part of Linux Distros?
1 reply →
I think this is the same as : we are a big company that does banking and payment processing for decades. We were planning to switch to golang/rust/C/python whatever for a long time but we still use age old java that has been patched several times with known security risks and no longer supported. Unless we have a huge problem we don’t see the need to fix something that is broken but not fallen apart yet.
IMHO:
And it will not be, as long as
* (S|D)NAT are not first class citizen in IPV6 Standards and Implementation * there's no mapping of the IPv4 Adresspace into the v6 space, so people can reroute stuff which is needed.
because only then, we can a) migrate b) rebuild the same structures.
because people will never let go of something.
> as long as [...] (S|D)NAT are not first class citizen in IPV6 Standards and Implementation
Yeah, I mostly agree... IMO, a ULA (equivalent to RFC1918, so 192.168.x.x and so forth) is the only sane way to set up your IPv6 network at home, unless you're one of the wizards who owns their own prefix. Dynamic prefix delegation just breaks too many things when the prefix changes, and I really wish NPTv6 was more supported and ubiquitous, because it solves the problem in the most elegant way IMO.
> there's no mapping of the IPv4 Adresspace into the v6 space
Uh, what? What do you think ::ffff:1.2.3.4 is?
https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5....
https://datatracker.ietf.org/doc/html/rfc4038#section-4.2
You don't need NPTv6 to use ULA. Just use both ULA and the dynamic prefix from your ISP. The latter is handled automatically by DHCPv6-PD, and if you're only using it for outbound connections then it changing isn't going to break anything.
I'd say this is actually elegant, compared to NPTv6 which is a kludge and will break things (and isn't well-supported anyway).
1 reply →
huh, i was NOT aware of that. NICE!
now applications (including DNS/NAT) have to support it
i also forgot something (but not against your comment):
* there needs to be guidelines how applications should differentiate between used ipadresses (link, site, global and so on)
I was expecting Google's IPv6 availability monitor[1] to show a crossover to a (slim) majority of their users accessing their services over IPv6 sometime soon, though it's sort of fascinating how close it gets to 50% recently without ever actually crossing over:
[1] - https://www.google.com/intl/en/ipv6/statistics.html
Heh, 49.84% on Aug 2nd. Pretty sure it'll cross 50% in 2026, even if only for a few peaks.
It's reaching around 50% adoption according to Google stats? Steady growth, though still annoyingly slow. It will need a few more decades at this rate.
My criteria for success, which is the goals that were set forth for IPng was to no longer depend or rely on IP. It didn't even achieve the goal of averting the issue of impending address exhaustion.
It’s all fun and games until your ISP changes your prefix and breaks all your firewall/routing rules. I tried to adopt IP6 with Spectrum internet, but every time the cable modem reboots, my prefix changes and breaks everything. No thanks.
Matter iot devices are IPv6 only.
Apple TV, Amazon Echo/eero, Google Nest are all Thread/Matter hub.
Ikea just started to selling cheap Thread devices. It will soon be mainstream to have IPv6 devices in your home network.
Google's ipv6 stats[0] are stuck in Dec 17.
However, extrapolation suggests the 50% mark might have finally been crossed around year end.
0. https://www.google.com/intl/en/ipv6/statistics.html
I still don't have IPv6 at home in the middle of San Francisco with Google Fiber / Webpass and have to egress through an HE.net tunnel like it's 2002 again
I run an IPv6 only VPS as a side project to keep an eye on what doesn't work. My most recent discovery: I tried moving from `lego` to the new native ACME `nginx` support. `nginx` refuses to talk to letsencrypt on IPv6; it's not a letsencrypt flaw because it works perfectly on the same server with `lego`.
I have noticed that on my last Windows computer (Windows 10) and my current computer (Windows 11) IPv6 works great for a little while after a reboot, but then just seems to die. I have my house and all internal automation configured for IPv6 first and its great on all my Linux computers and phones.
My work has IPv6, and my home has IPv6.
If I need to connect to my home Fedora machine from work, a simple "ssh fed.nono.io" works just fine — I don't need to activate my Wireguard VPN; I don't need to worry about address space collisions.
That is because your provider is nice and gives you a static pre-fix. Around here, all the providers give dynamic IPv6 pre-fixes to prevent people from running servers. This is partially why some see Ipv6 as a advantage, and others see it as nothing but trouble. We still have the whole Ipv4 CGNAT disadvantage, with the added complexity of Ipv6 on top.
IPv6 is an inequality issue. Far too many luddites refuse to learn it because IPv4 works well enough for them. I think it would be a totally different story if the majority of US/European people ended up with CGNAT.
IPv6 might not have taken over the world, but it sure seems to be getting forced on the world.
Even more than IPv4, not knowing enough about IPv6 can introduce a lot of unintended issue, consequence and even security gaps in your assumptions.
Maybe there was an IPv7 or 8 that will be more palatable.
Haven't we been crying about the IPv4 apocalypse and the need to adopt IPv6 since the slashdot days? It's like fetch, it's not happening.
> IPv6 was not backward-compatible with IPv4
I don't think there is any way it could have been.
It is so disappointing to have people who allegedly work with networks and technology act like IPv6 is too much for their delicate sensibilities. From thinking it is more complex than IPv4 (it is in fact simpler), to thinking that NAT is a security measure (the firewall is and routers have an IPv6 firewall on by default), to thinking there are no benefits (the benefits are clearly there), to thinking nobody uses it (loads of mobile devices access the web via IPv6 and lots of enterprise networks are IPv6), and so on, it is anti-curiosity and anti-hacker ethos. Go ask your favorite LLM how it works if you can’t be bothered to Google it but if you start your comment with “it has no use cases” or “it is too complicated” you are just outing yourself as ignorant on this subject.
Well, my ISP dosent support ipv6, and i get a non shared public ipv4, so no ipv6 here.
The article itself is fairly short & fluffy.
Vs. real meat is in the comments on the Register's site.
IPv4 should have been converted directly to IPv6. Every IPv4 address should have been given an equivalent IPv6 address. 192.168.1.1 becomes 2001:00C0:00A8:0000:0000:0000:0001:0001 or 2001:00C0:00A8::0001:0001.
that exists - ::ffff:0:0/96 space. It even supports dots.
::ffff:192.168.1.1 == 192.168.1.1 (as far as the linux kernel is concerned, in most contexts)
You mean, like 6to4? We did that.
So NAT64?
https://www.nat64.net
Roughly 40% of the Internet is IPv6. That's not taken over, and disappointing for a 30 year old standard, but it's not nothing. https://www.potaroo.net/ispcol/2024-10/ipv6-transition.html
I've been using IPv6 via Starlink for months now and it was a big ho-hum when I deployed it. It just works.
The reason being? IP proxy gateways. They obviated the need to move away from the limited address space of IPv4. Which was 90% of the reason to do IPv6.
It's not a failure of IP6 but a failure of society.
We all thought the internet would become decentralized and that everyone should have an IP and a funky website. But instead social media took over, big tech and a few big discussion sites where we all must fit in a digital life and watch ads and share our data to become a good product for all the others to consume.
All those discussions are making it harder than it need to be.
I have ONE static external IPv4 for my network.
I can handle everything I want with it. And block everything I dont want my network to be.
So I just disable IPv6 on router (Mikrotik).
Not interested, not wanting it. That is it. If someone needs it, feel free to use it. I wont support double configurations on my router because of it.
people don't understand how expensive it is to support ipv6, tcam is limited and having to split it in half to support ipv6 is just not an option for a lot of businesses. Route caches exist with software routing - but for larger networks it is not an option
I really don't get why people hate on IPv6.
I'm sure someone will fuck this up for us, but IPv6 should at least in theory enable us to be rid of NAT. Anyone who has ever done NAT traversal for peer discovery is having wet dreams about that future!
I prefer NAT over IPv6. Mostly because NAT is more reliable over time.
Sure NAT traversal for peer discovery doesn’t sound pleasant, but routing issues that no one understands or care about is worse.
I will fully and honestly admit I don't understand much about IPv6 - however, I have a question - why didn't they just add 8-32 bits to IPv4 and call it a day?
Legacy IPv4 would be trivial to support via NAT, and we wouldn't have to deal with address shortages either globally or locally. I'm sure every sysadmin/cloud person dealt with having to arrange subnets by hand, or the fallout when you just ran out of addresses and had to tear down multiple layers of routing just to make more address space.
Computers default to 64 bit integers, I don't see why this couldn't be done on the network.
Because there isn't "empty space" in the IPv4 packet header (or even the pseudoheader format from which TCP or UDP checksums etc are derived) to expand your new bits into. By breaking the packet format, you just invented a new network protocol that all of the routers, firewalls and middleware of the world don't know how to handle.
Yes, it’s true that any change they made would be incompatible with the existing software and routers and such. But nowadays everything can handle IPv6 just fine. All the upgrades and new software came out between 20 and 30 years ago, and is ubiquitous now.
They pretty much did. "Just add N bits to v4" is far more work than you're thinking it is, and most of what v6 does is a direct consequence of taking v4 and adding more bits to it.
The amount of work doesn't depend on the number of bits either, so adding fewer bits is a false economy. Deploying a new version of IP is so hard that you only want to be doing it once, not once every time you need an extra few bits.
the other day I had to change my node server to prefer ipv4 dns records because fly.io doesn’t support outbound ipv6 connections but defaults to a dns server that returns them
Their document states they support v6, and given how much of their stack involves v6 I would be shocked if they didn't support v6 outbound.
> Outbound IP addresses
> Fly Machines have IPv6 addresses from which they make requests to the wider internet without going through the Fly Proxy.
https://fly.io/docs/networking/services/
Meh. IPv4 is used to deliver Netflix to the masses and act as a tunnel for your IPv6 network. It's not how I would have set things up, but since content delivery is the primary use case for most ISPs, they're unlikely to support v6. Contrary to the "Comcast is shit" narrative, I had a GREAT experience a couple living situations ago where I got dual stack from Comcast. It just sort of worked out of the gate and whenever I had to call the support line, I was immediately transferred to someone who knew what they were talking about because I had this exotic / non-standard service.
It's sort of interesting dude says Security and Plug-and-Play weren't available in v6 since SLAAC and IPSec are mandatory parts of the spec. But sure, AH and ESP options are never as simple as they should have been and it's not impossible to pick options for your organization that don't match what a remote organization supports. I still prefer it to the crap-shoot that is TLS ChangeCipherSpec. (Though 1.2 and 1.3 aren't as bad as the old days.)
Contrary to the narrative about your parents not being able to cope with anything technical, my mom was able to configure her mac to speak to the family VPN with no problem. Of course, my mom taught me code in Lisp in the 70s and used a Sun 3/60 as her daily driver in the late 80s, so maybe that's not the best example.
Sure. V6 didn't take over the world, but neither did SNA or IPX/SPX, though I would argue v6 is MUCH more common these days than either IBM or Novell protocols. V6 is used in the corner of the internet by people who want to use V6. Maybe there's a "those who know don't tell, those who tell don't know" narrative here. I've sort of stopped evangelizing. If the main thing you worry about is watching Netflix, MMORPGing and commenting on Reddit, you don't need V6 and it does require a different bit of knowledge than setting up V4.
#OldManYellsAtClouds
In my country, the last big _mobile_ internet provider finished its move to IPv6.
Land lines internet have been IPv6 for more than a decade.
While developping custom IPv6 internet software I am not blocked by NAT anymore, real p2p fiesta, everything works as intended.
The real challenge now is IPv6 with fixed mobile internet address (not random as it is is now, it should be device uniq). That to replace for good the phone numbers (the challenge of international roaming... which is already done for phone numbers). The idea would be to avoid a third party centralized internet account->ipv6 mapping.
Every few months I turn on IPv6 at my house. I try to use it. I find random sites just not working, random delays accessing sites, and so on. Then I switch back to IPv4 and everything works.
I used to be a network admin, so I know how to configure networks. IPv6 zealots accuse me of incorrect config, doing it wrong, etc. Maybe that is the case, but if I, a sophisticated user, can't get it working well, what chance does a non-technical person have?
My assumption is they just deal with the issues and chalk it up to "technology sucks". But I know better. I've experienced the internet when it works, and I know when it isn't working right.
I think IPv6 is better in theory, and I look forward to the day that it is in practice. But today is not that day.
I suspect you forgot to implement a workaround for servers with broken pMTUd. The quickest test for that is probably to run `ip link set mtu 1280 dev eth0` on a client machine and see if it helps.
You'll encounter the same problem on v4, where it's just as difficult to fix as it is on v6. Why single out the latter?
Because I don't have the problem on v4 (and it's not the MTU, I checked that).
> "IPv6 wasn't about turning IPv4 off, but about ensuring the internet could continue to grow without breaking,"
Then it's failure is by design. I should not want to multiplex/bridge different versions of the network-layer protocol; and certainly not to avoid using the new protocol because the old one seems more usable and approachable.
I think the original plan was definitely to turn IPv4 off. Obviously that's probably not practical in our lifetimes.
it was an explicit non goal to ever schedule the end of ipv4
1 reply →
reminder that in 2026 Microsoft GitHub(TM) still doesn't support ipv6
but if you need maximum AI slop, that's everywhere
As GitHub keeps Azureifying, it'll be interesting to see if this changes.
Goes hand in hand with dnssec.
Only 30? It feels like it's been ages!
You and me both, IPv6.
My "conspiracy theory" is IPv6's point to point connectivity is inconvenient to anyone except end users. And, rent-seekers can't extract money if the ranges aren't limited. American mind can't comprehend not rent-seeking any new invention.
Oh it's much more mundane.
IPv4 "works" and ISPs are incredibly resistant to changing things that "work".
Because support is needed basically end to end, it's going to take an ungodly amount of time for ISPs to figure this stuff out.
It's pretty frustrating having all my hardware support v6 with the only barrier being my ISP who refuses to support it in my location (they support it in other locations).
America has one of the highest IPv6 adoptions in the world.
> America has one of the highest IPv6 adoptions in the world.
Except for people. Specifically, wireline end users. Triply so if they're on Fiber.
ex: T-Mobile fiber rollout is IPv4-only and CGNAT.
6 replies →
Aren't all the smartphones IPV6?
Second system effect.
What's up with those comments? Am I still on HackerNews or did I visit Reddit with some HackerNews theme applied?
Internet engineers pre-2000 had some idealistic, heavly mathematically proven ideas that still seem revolutionary today. Due to human nature, not everything got through, but IPv6 is the best of what we have and creating another standard would be XKCD 927.
Under every IPv6 discussion people all of sudden have the urge to manually assign numbers, need to remember their cousin's phone IP and MAC address, forget firewalls exists, argue that ISP fiddling with TCP+UDP selling it as "Internet" is a good thing or that "sender" field on the envelope is a huge privacy issue.
Good enough beats better.
Because NAT and VPNs are a permanent temporary fix. Before you get a global flat Internet, you have to make NAT illegal just like we did with VPNs. Good luck with that.
I spent an excruciating 3 months or so learning about IPV6 in a college networking class circa 1994 so that I could be "current" in order to land a job right out of college.
Dual stack is a hack and binding to an interface like localhost or a single interface does not support dual stack . So your L6 code has to be modified and re tested to support L3 changes .
Even if ipv6 was just as simple , the cost of rebuild , retest and re-deploy is enough of a barrier against migration
Dual stack is a natural part of migrating between two protocols, because it's the most compatible way of handling both of them. You don't need to use dual stack to use both v4 and v6, but you'll probably choose to the instant you hit even the most minor incompatibility.
Your L6 code should work perfectly fine if you wrote it properly in the first place. If you pass "localhost" to getaddrinfo() with flags=AI_PASSIVE, it returns a list of socket addresses to listen on, and all you need to do is pass those to socket(). You don't need to look inside the sockaddrs and they might as well be opaque data to you, so it doesn't matter what L3 protocol they represent.
Most listeners I’ve seen assume a single FD. It’s IPv6 snobbery to say “you should have written your code to expect IPv6 upgrade 20 years ago”
Is IPv6 going to see it's epitaph instead of it's takeover soon?
should be just about done by 2050 at that rate
I just want things to work.
Well if you think IPv6 adoption is a problem, wait until you hear ISPs offering IPv6 are providing a /64 prefix. IPv6 rollout is a mess.
they should have made it backwards compatible. they were forever doomed by not make it a superset of IPv4.
I agree in theory, but doing so would have been very difficult practically. The IPv4 header structure is very rigid, and it wouldn't have been possible to just add more bits to the src/dst fields without breaking things. The only reasonable route I've seen would have been to add an "area code" or "country code" to the Options fields and have huge border routers to translate packets between different locales. It would have solved one problem, only by creating an arguably much worse one.
https://en.wikipedia.org/wiki/IPv4#Header https://en.wikipedia.org/wiki/Internet_Protocol_Options https://en.wikipedia.org/wiki/IPv4#/media/File:IPv4_Packet-e...
Sure, but there was also no need to reinvent address assignment, routing and bunch of other stuff that now causes a massive headache due to mismatch of architectures on dual-stack deployments.
It was not possible to make a "superset" of IPv4, if only because one of the early major blockers was that BSD Sockets suck by leaking low-level details of addressing so you'd have exactly the same argument of "why should I bother writing entire second copy of connection code in my application" for any superset you want to imagine.
Similarly, we have 30 years of experience that vendors will happily break optional headers or flags.
I don't think this is how it would have played out at all.
I'm no expert on IPv4 or IPv6, but if they had designed IPv6 to be able to route fine to IPv4, we'd be OK.
It would at least give people an upgrade path where their old stuff that couldn't be patched / updated and were stuck on IPv4 could be slowly killed off in the path of least resistance down the dependency line.
This 'dual stack' approach doubled up on everything up front and meant we all had to do both during the transition (which has taken 30 years).
1 reply →
i was using ipv6 at home for years but then one day at&t broke it and never fixed it
I have yet to encounter a situation where I _NEED_ IPv6, or there's a very substantial benefit of using IPv6 over IPv4 beyond just "academic arguments on the internet".
And I work with IP networks all the time, as well as run LAN Parties as a business. You'd think I would have encountered at least ONE reason to give a crap about IPv6 by now.
But nope, not one reason.
IPv4 gets work done. IPv6 is just a topic that we can wax poetic about, but nothing else.
btw it's only been getting seriously deployed since 2010
ipv6's::syntax::is::weird
cuz it sucks
Except it has
Has it? Why are we still utterly dependant and reliant on IPv4 addresses?
We aren't. There's a variety of reasons people choose to use v4 (some good, some bad), but you don't have to.
The network my desktop is on doesn't use v4. It works. v4 isn't a required dependency.
3 replies →
For Google connecting clients it's only half the internet.
Half. The. Internet.
What a failure. /s
It failed to solve the problem of impending IP address depletion and reliance. So at the very least, and being charitable, it is not a success.
> It failed to solve the problem of impending IP address depletion
I wouldn't say so. Some mobile carriers and big data centers have used IPv6 to pretty much completely solve the problem of being able to assign a unique address to devices.
For mobile devices, moving 50% of traffic over to IPv6 means buying half as many CGNAT/v6-to-v4 boxes (of various kinds).
And on the v6-inside, unique address can be assigned. Legal requirement and court orders suck when you get "who had A.A.A.A:32800 at time T?" if you have to go through three levels of NAT to decode that. So even if a customer only accesses IPv4, having their actual handset only be assigned IPv6 makes things easier and cheaper. Even if they share an outside address, there's only one translation so the inside is unique.
For big data companies, it means not needing to solve the problem of running out of 10/8 (yes I'm aware of the other private addresses), and having an address plan problem any time they make an acquisition.
And I've seen large providers who build their whole actual network with IPv6, and only tunnel IPv4 on top of it. Huge savings in complexity and cost of IPv4 addresses.
So what I'm saying is that I've seen first hand in multiple large providers of different kinds how IPv6 is delivering incremental payoff for incremental adoption.
It doesn't have to be 100% before we get ROI.
> it is not a success.
About half of even public traffic on the most complex and distributed system ever built is IPv6.
It's going slower than I'd like, but it's definitely paying off.
There are still ATM and X.25 networks out there, so is IPv4 a failure? (admittedly, a bit hyperbolic)
I'm working on a problem right now at a large company to move a thing from IPv4 to IPv6 because the existing IPv4 solution is running out of addresses, and it's impossible (for multiple reasons) to "just add more IPv4". Can't go into details, sorry.
2 replies →
This is mainly due to mobile devices only being issued ipv6 addresses by the telco 4g networks. They are the only ones using ipv6 on the millions of clients scale.
My current home ISP and my last one both support IPv6 just fine. It is not a mobile-only thing.
10 replies →
Comcast/Xfinity implemented v6 on their residential cable network 14 years ago ( https://corporate.comcast.com/comcast-voices/ipv6-deployment...)
Most other large eyeball networks have as well.
1 reply →
[flagged]
It’s ok to understand something and disagree with it. It’s another to proudly wear ignorance on one’s sleeve. That’s never a good look.
There’s no way in which IPv6 is less private than IPv4. An ISP issues your house an IPv4 address and an IPv6 /48 network. Both of those can be subpoenaed equally. The privacy extensions work as advertised.
And in reality land, the big companies are the ones pushing for the upgrade because they’re the ones hardest hit by IPv4’s inherent limitations and increasing costs. Same rando in Tampa isn’t leading the charge because it doesn’t affect them much either way.
> There’s no way in which IPv6 is less private than IPv4
With IPv4 behind CGNAT you share an address with hundreds of other users. This won't protect you against a targeted subpoena, but tracking companies typically don't have this kind of power, so they have to resort to other fingerprinting options.
On the other hand, an IPv6 address is effectively a unique, and somewhat persistent, tracking ID, 48/56/64-bit long (ISP dependent), concatenated with some random garbage. And of course every advertiser, every tracking company and their dog know which part is random garbage; you are not going to fool anyone by rotating it with privacy extensions.
7 replies →
Google aren't subpoenaed
Perhaps this is the difference, some people are concerned with being anonymous from companies like google, amazon, etc. Some don't mind that, as long as they are anonymous from a government.
Your mention of subpoena suggests you don't care about google tracking you.
10 replies →
Unless my understanding of how IPv6 is flawed, I don’t think your assertion is true in practice. One of the big benefits to IPv6 is that addresses are plentiful and fairly disposable. Getting a /48 block and configuring a router to assign from the block is pretty straightforward.
I’m aka unsure if IPv4 really gets you the privacy advantages you think it does. Your IP address is a data point, but the contents of your TCP/HTTP traffic, your browser JS runtime, and your ISP are typically the more reliable ways to identify you individually.
> Incoming HN downvotes because I'm not using the coolest latest technology.
The downvotes are because you’re needlessly combative, preemptively complaining about downvotes.
You can nat all your ipv6 traffic behind a single IP if you want. Or a new IP for every connection.
Realistically though there's enough fingerprinting in browsers to track you regardless of your public IP and whether it's shared between every device in the house or if you dole out a routable ipv4 to every device.
CG-NAT gives more privacy benefits as you have more devices behind the same IP, but the other means of tracking still tend to work.
For me I just don't see the appeal of supporting both ipv4 and ipv6. It means a larger attack surface. Every year or two I move onto my ipv6 vlan and last a few hours before something doesn't work. I still don't see any benefit to me, the user.
> Realistically though there's enough fingerprinting in browsers to track you regardless of your public IP and whether it's shared between every device in the house or if you dole out a routable ipv4 to every device.
Yes, browser fingerprinting is a big issue, but it can be mitigated. The first thing everyone should do is to use a network-wide DNS blacklist against all known trackers (e.g. https://github.com/hagezi/dns-blocklists) and run uBlock Origin in the browser.
You can go further and restrict third party scripts in uBlock, or even all scripts. This will break at lot of websites, but it is a surefire way to prevent fingerprinting.
Then of course there is Tor.
IPv6 itself seems to provide a larger attack surface based on IPv6-specific CVEs. I don’t know if it’s the added complexity or that it’s treated as a second class citizen by devs, but I still see a solid number of these coming across the CVE feed.
This one was particularly scary: https://malwaretech.com/2024/08/exploiting-CVE-2024-38063.ht...
2 replies →
> Realistically though there's enough fingerprinting in browsers to track you regardless...
Yep. For the OP, IPv6 "Privacy" addresses do what he's looking for. You can change how long they're valid for on Linux, so you can churn through them very frequently if you wish.
> Every year or two I move onto my ipv6 vlan and last a few hours before something doesn't work.
Odd. I've been using IPv6 for like fifteen, twenty years now with no trouble at all. If you've been using a "single stack" IPv6-only network, well, there's your problem.
> For me I just don't see the appeal of supporting both ipv4 and ipv6. It means a larger attack surface.
The attack surface with IPv6 is exactly as large as if each of your LAN hosts had a globally-routable IPv4 address. Thinking otherwise is as smart as thinking that the attack surface on a host increases linearly with the number of autoconfigured IPv6 addresses assigned to that host from the same subnet.
If you don't want the IPv6 hosts on your LAN to be reachable by unsolicited traffic, set the default policy for your router's ip6tables FORWARD chain to DROP, and ACCEPT forwarded packets for ESTABLISHED or RELATED connections. If you're not using ip6tables, do whatever is the equivalent in the firewall software you're using. If you know that you have rules in your FORWARD chain that this change would break, then you already knew that you could simply drop unsolicited traffic in the FORWARD chain.
Unrelated to that, I see no reason to get rid of IPv4.
I expect that the future will be that nearly all "residental" [0] and non-datacenter business connections provide globally-routable IPv6 service and provide IPv4 via CGNAT, as IPv6 will be used for servers deployed at these sorts of sites. [1] I expect that the future will be that all datacenters and "clouds" will provide globally-routable IPv6 to servers and VMs, and globally-routable IPv4 to the same by way of load balancers.
So, home servers [1] will use IPv6, datacenter and "cloud" servers will use IPv4 and IPv6, and "legacy" devices that work fine but will never have their IP software updated will use IPv4.
I see IPv6 as a "reduce the pressure on the IPv4 address pool" mechanism, rather than a "replace IPv4" system. Again, I see no reason to get rid of "short" IP addresses. Default to using "long" ones, and keep the "short" ones around just in case.
[0] I'm including people's personal mobile computers in this definition of "residential".
[1] "Servers" here include things like "listen" video game servers or short-lived servers for file transfers and stuff like that.
> Incoming HN downvotes because I'm not using the coolest latest technology.
"IPv6 just turned 30" - literally the first part of the post title.
The rest of the post is equally baffling, you are just clinging to a legacy bottleneck (NAT) that was never designed to be a security feature
> never designed to be a security feature
It's virtually always used with some firewall rules, so it sort of is? It's just dogma to insist that there are no security benefits to having a single choke point for traffic.
3 replies →
NAT superceded ipv6 quite plainly, and it is obvious what technology won out.
10 replies →
what is ipv6, btw?
sudo networksetup -setv6off Wi-Fi ; sudo networksetup -setv6off Ethernet
to protect your privacy
IPv6 addresses are ugly and hard to memorize. IPv4 addresses are pretty and easier to memorize. That's about the end of the discussion as to why it's basically a failure.
I don't remember ipv4 addresses either, that's what dns is for!
I used to like the idea of an IPv4 replacement, but I've come around.
A large number of my devices and websites I visit use IPv6. Its success has highlighted the fact that I don't want it. Just today I disabled IPv6 on my router because I suspect it as a vector for tracking.
IPv6 offers nothing of value to the user. It might as well be shelved forever.
IPv6 means no more NAT. Your home computer can have the same kind of network connection to the rest of the internet as the server at the AWS data center.
ISPs do not want this.
That is all you need to know about why you can’t have IPv6.
In lieu of complaining about the downvotes, I’ll just quote George Santayana:
“ Those who cannot remember the past are condemned to repeat it”