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.
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?
German situation is mostly/rarely/never. Small businesses have their DSL line where their cheapo router will announce an IPv6 prefix which almost all ISPs over here provide. Medium to large businesses usually have some braindead security policies that include switching off all IPv6 functionality in devices.
Are they still faxing?
It comes from the same place as "passwords expire every 30 days".
People don't understand something and just apply the most annoying rule possible.
The craziest one I saw in Germany was "cookies are allowed, localStorage is not", that was for our app. CTO overrode the CISO on the spot and called him an idiot for making rules he doesn't understand. Interesting day.
Usually there is no official justification given, just a list (in excel...) of security requirements that have to be ticked off. One of them is "Disable IPv6".
I've heard some ex-post justifications, make of them what you will: Existing infrastructure like firewalls, VPNs and routers might not be able to handle IPv6 properly. Address distribution in IPv6 is unpredictable. No inhouse knowledge of IPv6. Everything has an address in IPv6, so the whole internet can access it. No NAT in IPv6, so it is insecure. IPv6 makes things slow.
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.
You’re not wrong, but I have been running complicated multi-site VPNs with a small homelab multi-subnet / VLAN setup for 25 years and still have yet to have a collision.
My home network is dual-stack these days, but because my IPv6 prefix is dynamically delegated by my ISP, I actually use site-private IPv6 addresses for all my internal servers and infrastructure.
The thing is though, I don’t even need IPv6. Comcast Business broke my delegation for six+ months and I literally didn’t even notice.
IPv6 tried to do way too much. The second system syndrome was strong. It’s no wonder folks are annoyed at the complexity, and as long as IPv4 continues to works for them, they aren’t particularly pressed to adopt it.
Only one has to change, the smaller one presumably. Do it on the weekend, done. Planned ahead, easier than crowdstrike.
Ubiquiti software was uniquely awful at IPv6 for a very, very long time. It's one of the reasons I abandoned it for OpenWRT and Mikrotik.
> never at a random 192.168.x.x in a network I happen to be connected to.
That’s a pretty good benefit, I hadn’t considered that!
Eh, I've been thus far unimpressed.
Part of it being that a lot of ISP's don't have static prefixes, they do get rotated pretty often and have no guarantee of CIDR size that you're going to get. By default my ISP will only give a single /64. You have to go out of your way to request more subnets and there's no guarantee that the ISP will honor that request.
It's really problematic to try and base a non trivial network setup, when you have no guarantee of how many subnets you can run. Today I've got 256. Tomorrow it might be 16. Or 2. Maybe just 1 again. ISP's can be weird when they smell monetization dollars in the water.
So I have to run a ULA in parallel to the publicly accessible networks specifically for internal routing, and then use a DNS server to try and correct it. Which works great! ...except when you run into this little niche operating system called Android. Which by default doesn't obey a network provided DNS server if you've got privacy DNS enabled. So if I've got guests over and I want them on a network in my place to access some sort of internal resource, then I've got to walk them through disabling privacy DNS.
Either that or I need to go out and buy a domain... for my internal network...and then get a TLS certification for my private internal domain.
I get how IPv6 can be great. But a lot of the advantages are also overhead I don't want to deal with.
Short hand is a good example; I've lost count at the number of times I've typo'd short hand addresses because my eyes skip over a colon. At this point I've gotten into the habit of just writing out the whole address, leading 0's included because the time saved from not making a mistake reading the address often faster overall then making mistakes with shorthand.
> So I have to run a ULA in parallel to the publicly accessible networks specifically for internal routing, and then use a DNS server to try and correct it. Which works great! ...except when you run into this little niche operating system called Android. Which by default doesn't obey a network provided DNS server if you've got privacy DNS enabled. So if I've got guests over and I want them on a network in my place to access some sort of internal resource, then I've got to walk them through disabling privacy DNS.
This also sounds like it would be a problem for v4? I'm not clear on how this is a v6 problem. If I'm picturing it correctly, it's a difference of handing the guests a local v4 address vs disabling privacy DNS and handing them a DNS name. I'd think the latter would be easier
Using a public domain for TLS certs for private networking is pretty standard in /r/selfhosted and /r/homelab at least.
Fair point on ISPs handing out /64 prefixes, but this is the first I've heard of them varying the prefix length once you know what you've got. I don't doubt it though
> Either that or I need to go out and buy a domain... for my internal network...and then get a TLS certification for my private internal domain.
TBF, if you are on HN that should be extremely simple for you. I use a subdomain of my primary email domain I own, and use LetsEncrypt to issue TLS certs on my internal network. Well beyond the means of my mom and sister, but probably pretty easy for most people here.
What about the benefit of there being enough addresses?
That particular benefit has no value if you still need to support v4.
It's almost a self-inflicted tragedy of the commons or reverse network-effect.
Adopting IPv6 doesn't alleviate the pain of IPv4 exhaustion if you still need to support dual-stack.
Really using port 22 is very ill advised anyway because you will get constant nuisance brute force attacks (accomplishing nothing because you're using keys or certificates I hope) but still eating up cycles for the crypto handshake.
NAT accelerated hardware exists almost everywhere now. But yes NAT is a pita overall. CGNAT is even more of a problem.
> Adopting IPv6 doesn't alleviate the pain of IPv4 exhaustion if you still need to support dual-stack.
Sure it does: the more server-side stuff has IPv6 the fewer IPv4 addresses you need.
If you have money (or were around early in the IPv4 land grab) you have plenty of IPv4 addresses so can give each customer one to for NATing. But if you don't have money to spend (many community-based ISPs) you have to start sharing addresses (16:1 to 64:1 is common in MAP-T deployments). You also have to spend CapEx on CG-NAT hardware to handle traffic loads.
Some of the highest bandwidth loads on the Internet are for video, and Youtube/Google, Netflix, and MetaBook all support IPv6: that's a lot of load that can skip the CG-NAT if the client is given a IPv6 address.
If you can go from 1:1 to 16:1 (or higher) because so few things use IPv4 that means every ISPs can reduce their legacy addressing needs.
On company/university wifi networks, v6 cuts your v4 DHCP pool address usage by something like 70%, without hurting connectivity to v4 hosts.
You can run a V6 first network with a tiny bit of v4 sprinkled in on the edge where it's needed. The tech to do this is mature and well understood.
The widespread deployment of NAT and VPNs has counter acted the market forces that were assumed to make IPv6 appealing.
Honestly the games issue might be out of day. Game devs have access to great services to punch through NAT at this point.
Tech finds a way…
Isn't CGnat due to IPv6 use on the mobiles? You could quit and say that's an IPv6 problem that didn't get solved in the IPv6 engineering
It's my dream that one day I'll be able to run an AWS VPC that only has IPv6 for the private subnets and then I'll never have to worry about managing the address space or how many IP addresses each ALB consumes.
That is a collective problem, though, not an individual one. I have always been able to get enough v4 addresses for all my needs.
No, because sensibly configured routers would still block incoming traffic regardless of NAT.
I’m assuming you don’t know how iPv6 works. With SLAAC every device usually rotates the v6 address every few hours and maintains multiple of these. Each subnet for each customer is huge. With rotating MAC it’s virtually impossible to maintain a connection with an IPv6 only device by just IP address. It’s one of the features of IPv6 that such attacks are not going to be feasible.
Why? My router won’t even let me DMZ a single ipv6 device or open all ports to a single ipv6 device. It will only let me open one port at a time.
different routers have different options, but all of them have come with a pretty strong firewall out of the box, turned on by default, for the last 10 years.
There’s zero benefit to you because the carrier is NATing you for other purposes.
They get better network management.
Enough addresses for what? Nobody needs or even wants all of their devices to have globally routable addresses.
> Enough addresses for what? Nobody needs or even wants all of their devices to have globally routable addresses.
They do if they have applications, such as Xbox/PS gaming applications, broken VoIP in gaming lobbies, failure of SIP client to punch through etc. And if an ISP does not have, or cannot afford, to get enough IPv4 to hand each of their customers at least one to assign to the CPE's WAN port, you're now talking about CG-NAT, which a whole other level of breakage.
We’re supposedly mere years away from superintelligence, but it’s still literally impossible to just send a file between two clients without configuring intermediate network hardware or performing some hack to get around NAT (which can still fail and then require an intermediate server) if both clients are behind CGNAT.
It’s genuinely disheartening to see so many people here not even begin to try to understand how much we’re missing by not having effortless end-to-end connectivity, in favor of expensive cloud services. This literally used to be what the “Internet” is - we’re definitionally not on one without this.
Everyone who says this is obviously a web developer.
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.
The world very clearly doesn’t revolve around what HN users “love”.
> For a practical example: peer-to-peer sharing like Airdrop is much easier to implement in a world with ipv6.
And without firewalls. Unfortunately this world does not exist.
According to my last job interview, linux servers are only for websites and worthless otherwise.
The world at large doesn't care what I love, correct. But my users care about whether they have to remember that they're supposed to use port bla instead of the standard port foo, which is a common scenario with v4. Not enough addresses, and / or you can't get them to the VM or container or VPN client or whatever that needs them. IPv6 can often fix these kinds of issues.
Does the world at large care? No.
Do I care? Yes.
Do my users care? Yes, albeit indirectly.
Does my organization care? Yes, in the sense that it removes friction from what it needs the employees to do.
And that's all the justification that's needed, I'd say. The world very clearly doesn't need to revolve around what I love for IPv6 to be a good thing.
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...
No, but it did arrive several months later. Maybe they wait and send it in batches?
It arrived. Maybe the send them out yearly.
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.
I just bought the official exam guide found Neil Anderson’s videos helpful. One thing that bugged me a bit was they spent a little too much time on their WiFi, including the obsolete Airie OS.
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.
The IPv6 spec was being modified up through 2017. It has more kinds of addresses that behave in fancier ways, with one host having multiple. The very first thing you see with ipv6 is your nice memorable ipv4 addr replaced with a long hex string with some ::s thrown in. Local DNS is commonly recommended with ipv6 for that reason, which maybe is just some misguided advice because it sounds crazy. I guess you could assign and memorize ULAs?
NAT is technically complicated if you're looking inside it, but most people aren't, and for them it's really easier to think about. You've got a public and a private, and there's a very strong default that private isn't exposed. People screw up firewall rules all the time or routers have bad defaults, but it takes more deliberate action to publicly expose a port over NAT. Plus you don't need privacy addresses that way (introduced to ipv6 in 2007). I know "NAT isn't security" but for most people, it is.
Still not even sure what the accepted default firewall behavior is in ipv6, cause some people say "ipv6 lets any device do p2p by its own choice" and then when you ask about security, "your router firewall should always default-deny anyway," so which one is it?
> The presence of the IPv4 stack isn't what blocks the adoption of IPv6
It is. Like they say, most technical problems are really people problems, especially this one.
I wasn't under the impression that SOHO routers normally have DHCPv6 enabled by default. At least checked mine now and it doesn't.
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
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 got taught IPv6 in 1995. At that time they said it was super important because it would replace IPv4 within a year lolololol
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
But TCP or HTTP don’t care about the underlying transport. They’re higher level protocols that are payloads to either IPv4 or IPv6. It’s irrelevant what the transport is when dissecting HTTP and very little time should be spent on it.
IPv4 is, for all intents and purposes, still the default transport. It’s also simpler than IPv6 in some regards. When teaching layer 3, it makes sense to teach both, and teach IPv4 first. Though I fully agree that they should be taught with equal emphasis. I don’t doubt there’s a good number of programs out there that don’t into sufficient detail on IPv6.
No, this is wrong and it’s why academia is failing.
IP addresses show up everywhere when you are working with both TCP and HTTP. Sockaddr is all over sockets programming, IPs show up in HTTP headers, etc.
They absolutely care about the underlying protocol because the underlying protocol is how you address the other end.
Well it makes sense, no one uses ipv6 anyhow. Most I know are waiting for ipv8.
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.
Exactly. IPv6 was developed in the ivory towers where it was still assumed that everyone wanted to be a full participant of the internet.
But the social/political environment was that everyone just wants to be a passive consumer, paying monthly fees to centralized hosts to spoon-feed them content through an algorithm. For that, everyone being stuck behind IPv4 CG-NAT and not being able to host anything without being gatekept by the cloud providers is actually a feature and not a bug.
We've seen only the world where everything has been adopted to IPv4. p2p technologies strive even under it, but they could really shine with the ability to connect directly between devices. Imagine BitTorrent on steroids, where you don't have peers with assigned IPv4 and seedboxes and everybody else. Torrents are generally faster than usual channels to download things, but with ipv6 it would be far faster than now.
Cloudless cameras streaming to your phone without Chinese vendor clouds, e2e encrypted emails running on your phone without snooping by marketing people and three-leter agencies, content distribution network without vendor lock-ins. The possibilities are impressive if we have a way to do it without TURN servers that cost money and create a technical and legal bottlenecks.
We can't say nobody wants that world because we've never tried it in the first place. I definitely would like to see that.
Don't you think everyone should have the option to be a full participant? Being locked behind cloud providers and multiple layers of NAT with IPv4 means that can never happen, even if consumers want it to.
I was lucky enough to experience the 90's internet where static IP addresses were common. I had a /24 (legacy "class C" block) routed to my home, and still do.
> Exactly. IPv6 was developed in the ivory towers where it was still assumed that everyone wanted to be a full participant of the internet.
IPv6 was developed in the open on mailing lists that anyone could subscribe to:
The criteria presented here were culled from several sources,
including "IP Version 7" [1], "IESG Deliberations on Routing and
Addressing" [2], "Towards the Future Internet Architecture" [3], the
IPng Requirements BOF held at the Washington D.C. IETF Meeting in
December of 1992, the IPng Working Group meeting at the Seattle IETF
meeting in March 1994, the discussions held on the Big-Internet
mailing list (big-internet-at-munnari.oz.au, send requests to join to
big-internet-request-at-munnari.oz.au), discussions with the IPng Area
Directors and Directorate, and the mailing lists devoted to the
individual IPng efforts.
Just like all current IETF discussions are in the open and free for all to participate. If you don't like the direction things are going in participate: as Gandhi did (not) say, “Be the change you want to see in the world.”
One of the co-authors on that RFC worked at BBN: you know, the folks that actually built the first the routers (IMPs) that created the ARPA/Internet in the first place. I would hazard to guess they have know something about network operations.
* https://www.goodreads.com/book/show/281818.Where_Wizards_Sta...
> But the social/political environment was that everyone just wants to be a passive consumer, paying monthly fees to centralized hosts to spoon-feed them content through an algorithm.
Disagree, especially with the hoops that users and developers have to jump through to deal with (CG-)NAT:
> [Residential customers] don't care about engineering, but they sure do create support tickets about broken P2P applications, such as Xbox/PS gaming applications, broken VoIP in gaming lobbies, failure of SIP client to punch through etc. All these problems don't exist on native routed (and static) IPv6.
* https://blog.ipspace.net/2025/03/response-end-to-end-connect...
Well, with such a description of the 'vices' of IPv6 vs the 'virtues' of IPv4 count me as one who considers himself in full support of the ivory towered greybeards who decided the 'net was meant to be more than a C&C network for sheeple. Once I got a /56 delegated by my IAP - which coincided with me digging down the last 60 metres of fibre conduit after which our farm finally got a real network connection instead of the wires-on-poles best-effort ADSL connection we had before that - I implemented IPv6 in nearly all - but not all - services. Not all of them, no, because IPv6 can make life harder than it needs to be. Internally some services still run IPv4 only and will probably remain doing so but everything which is meant to be reachable from outside can be reached through both IPv4 as well as IPv6. I recently started adding SIP services which might be the first instance of something which I'll end up going IPv6-only due to the problems caused by NATting the SIP control channels as well as the RTP media channels, something reminiscent of how FTP could make life difficult for those on the other side of firewalls and NAT routers. With IPv6 I do not need NAT so as long as the SIP clients support it I should be OK. Now that last bit, client support... yes, that might be a problem sometimes.
The problem of IPv6 adoption in the US was largely engineered by major ISPs not caring while hardware manufacturers take their cues from major ISPs.
IPv4 link local addressing is awesome for direct PC to PC connectivity with no hassle
Well you will be happy to hear that ipv6 has the same thing with the FFfe::/10 network just like 169.254.0.0/16 apipa range
I get this strong feeling that most of the opposition against IPv6 stems from misconceptions.
So like plugging two laptops together? Honestly curious, I can't recall ever seeing anyone using it and the situations that it seems like it should be good for, like initial configuration of stuff coming out of the box, instead come with instructions for setting specific IPv4 addressing or use DHCP. Possibly a lack of some LLNMR equivalent at the time.
Did you reply to the wrong comment? I know link-local works in IPV6, we were discussing IPv4.
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
The only ISPs issuing IPv6 only connections are mobile device operators and Telcos. THey are a small subset of ISPs in the world and IPv6 only connections will never gain any traction outside of that world.
I agree it will not die so I retract that statement, but it will never fully replace IPv4 in standard wired internet connections.
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.
My memory of IPv6 is getting waves of support tickets from people who took their (already questionable) practice of blocking ICMP on IPv4, blocked ICMPv6, and then got confused when IPv6 stopped working.
The legacy of the Ping of Death and redirect abuse still looms over people that may not have been born yet :)
It's a "just doesn't work" experience every time that I try it and I don't experience any value from it, it's not like there isn't anything I can connect to on IPv6 that I can't connect to on IPv4.
My ISP has finally mastered providing me with reliable albeit slow DSL. Fiber would change my life, there just isn't any point in asking for IPv6.
Also note those bloated packets are death for many modern applications like VoIP.
The biggest tangible benefit is you don't need to worry about NAT port mapping any more. Every device can have a public address, and you can have multiple servers exposing services on the same port without a conflict.
(The flip side is having a network-level firewall is more important than ever.)
You also don't have to worry about running a DHCP server anymore, at least on small networks. The simplicity of SLAAC is a breath of fresh air, and removes DHCP as a single point of failure for a network.
> All of my devices are assigned 4 IPv6 IPs
Loopback, link local and network assigned. What's that problem? Your ipv4 hosts are can reach themselves through millions of addresses already.
> hostnames are replaced by auto assigned stuff from the ISP
Hostnames replaced? IPv6 doesn't do DNS...
> lots of random things don’t work.
Lots of random things also don't work on ipv4. :)
I have tailscale on all my mobile/portable devices I use away from home. It punches holes so I don't have to, even makes DNS work for my tailnet in a way I've never been able to get to work the way I want the normal way.
It's not the bandwidth it's the latency. Because of the latency you need to pack a small amount of data in VoIP packets so the extra header size of IPv6 stings more than it would for ordinary http traffic
https://www.nojitter.com/telecommunication-technology/ipv6-i...
Last time I looked at Digital Ocean they had completely missed the purpose of IPv6 and would only assign a droplet a /124 and even then only as a fixed address like they were worried we are going to run out of addresses.
Because 2^128 is too big to be reasonably filled even if you give a ip address to every grain of sand. 64 bits is good enough for network routing and 64 bits for the host to auto configure an ip address is a bonus feature. The reason why 64 bits is because it large enough for no collisions with picking a ephemeral random number or and it can fit your 48 bit mac address if you want a consistent number.
With a fixed size host identifier compared to a variable size ipv4 host identifier network renumbering becomes easier. If you separate out the host part of the ip address a network operator can change ip ranges by simply replacing the top 64 bits with prefix translation and other computers can still be routed to with the unique bottom 64 bits in the new ip network.
This is what you do if you start with a clean sheet and design a protocol where you don't need to put address scarcity as the first priority.
Yeah, the current system is really weird, with many address assigning services refusing to create smaller pools. I really hope that's fixed one day. We already got an RFC saying effectively "going back to classful ranges was stupid" https://datatracker.ietf.org/doc/html/rfc6177 (for over a decade...)
Point of fact it's giving 4 billion Internets worth of addresses to every local subnet.
You will sometimes see admins complain that IPv6 demands that you allow ICMP (at least the TOOBIG messages) through the firewall because they're worried that people on the internet will start doing pingscans of their network. This is because they do not understand what 2^64 is.
Do you think anything other than trivial internal networking is a common requirement on DO? I’m not saying it’s not, I really don’t know— I haven’t been in the production end of things for a while and when I was, everyone was basically using AWS et. al. for non-trivial applications. They make it easy enough to set up a private ipv4 subnet to connect your internal services. Does that not satisfy you use case or are you just avoiding tooling that might be obsolete sooner than ipv6?
I use IPv6 on my authoritative DNS servers and that's basically it. To your point keeping it disabled on all my hobby crap keeps everything simple for me. If someone can not reach IPv4 then something is broken on their end.
IMO ipv6 is a perfect example of why interface designers can be valuable on technical projects. One of the genius things about ipv4 is it’s a pre-chunked number you can shout across the room or keep in your head as you run down the hall to your keyboard. IPv6 addresses simply don’t have that feature. If they had kept the 4-chunk format and made it alphanumeric, or added a chunk and made it hexadecimal, or something along those lines, I think they could have reasonably alleviated the problem of running out of addresses while not making the addresses SO unfriendly to remember.
But when designers bring things like that up, you get “it’s really not that complicated,” or “I explained this to my 200 year old grandmother over tea/my 16 month old child over the course of a diaper change/my non-technical wife that I intellectually respect less than I should/etc. and they wrote a book on it the next day,” kind of crap. Human factors engineering. Ergonomics matter in technical products.
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.
For trivial cases NAT is easy, for complex situations it's a nightmare. I've been fighting a lonely battle against multiple-NAT VPNs as being the solution to the wrong problem for longer than I care to remember, and I'm tired boss. A few years ago we had a client site go offline because a local network guy just didn't like IPv6 and turned it off, not realizing that a huge amount of stuff was happening automatically and that's why he hadn't been needing to work on it.
This is not even funny to read, given huge networks like T-Mobile USA being IPv6-only.
Yep, mobile device space ISPs again which is what keeps being argued. IPv6 only connections will never gain full traction outside of the mobile marketplace.
They are using IPv6 as a fancy transport protocol for IPv4 NAT.
I run dual stack at home with dns64/nat64. I average 50/50 traffic v4/v6. Web browsing gets skewed v6 but large file transfers and some streaming pushed it back to 50/50 overall. My family would revolt if I went v6 only so I'm not sure I'd say its just there for holdouts. Major annoyances include any old device and my hue bridge.
Well, yes. Except that AC came to dominance much faster than IPv6, the AC/DC war lasted less than 10 years, with the AC quickly coming to domination. Because AC provides a clear performance advantage over DC.
This is not really true of IPv6. It _still_ has tons of actual operational issues, and in the best case, it does not provide any tangible improvements over IPv4+NAT for the vast majority of users.
For example, in-flight entertainment works by assigning you an IPv4 address and allowlisting it in the gateway rules. This does not work with IPv6 because of privacy addresses and SLAAC. You might think that you just need to do stateful DHCPv6, but Android doesn't support it. Heck, even simple DHCPv6 PD automatic configuration is _still_ not a standard ( https://datatracker.ietf.org/doc/rfc9762/ )!
So to this day, some of the most visited sites like amazon.com, ebay.com, tiktok.com, slack.com or even github.com do not support IPv6. I also keep providing this example, year after year: there are no public VoIP SIP providers in the US that simply _support_ IPv6. Go on, try to find one.
High voltage AC actually gives more overhead than the same voltage DC.
464XLAT is for dealing with IPv4 literal addresses in a v6 only network. Non-literals can be addressed with DNS64 & NAT64
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?
Yes as I said in a sibling post the telcos are the only ones using it, and that is the only reason that graphs like the google client one exist. That is only because it already exists and is cheaper than using NAT when you have hundreds of millions of clients.
IPv6 only ISPs will never leave the mobile space.
Maybe in the US. I've seen IPv6-only connections via DS-Lite in more than one other country on wired home ISPs.
I disagree. If they were the largest ISPs then adoption would already be over 50% instead of stalling below it.
I would say its more "Wireless only ISPs are the only ones using it"
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.
IPv4 addresses have been dropping in price for a few years and are cheaper in real terms than at my point in the last 15
IPv4 addresses are basically free - indeed they are a profit centre. At $20 an address that’s $2 a year at most (10% ROI) where many charge 20 times that ($5/month isn’t unheard of)
Matter/Thread use private IPv6 addresses so it's just an implementation detail. Nobody is exposing light switches to the public Internet.
NAT fixes it in the sense that blocks become available when providers switch to CGNAT.
People love this graph and regularly tout it as if it explains full internet usage. Especially when they dont bother to add any explanation or comment alongside it.
This graph is mainly due to the fact that telcos use IPv6 for mobile devices, nothing more. Over time you will see that graph flatline and peter out as mobile device uage reaches critical mass.
Yep, every ISP and every device supports IPv6 and has done for ages.
Show me one where they have disabled IPv4 and only use IPv6 that is not a mobile device or Telco ISP.
Yes good point, I agree that IPv4 addresses are going to become a commodity in the future and their value will start to increase dramatically to the point where it is only corporations which can afford to use them. IPv6 use may well start to spike again if that happens.
Yep, and even with all those countries with their billions of mobile devices IPv6 use still hasnt even reached 50%.
Pretty much all ISPs hand out both IPv6 and IPv4 addresses to their clients, this is nothing new. When they start only issueing IPv6 IPs is when it would start truly taking off, but it will never get to that point and it will never happen.
If you were correct, that graph would have been over 50% ages ago.
As it is, that graph is showing how adoption is slowing and has been for the last 10 years.
Hardly anybodies physical internet connection is using IPv6 primarily worldwide, those numbers are all mobile device space.
I don't think they are arguing for a decrease. I took flatline and peter out to mean stabilize.
I am arguing that at some point there wont be any more people without phones, meaning it has reached critical mass and so IPv6 adoption will stall. The number of smartphones in the world will not keep on going up forever.
What is the source of the seasonality in that graph? Spikes up a little each summer.
If that is the case then why does it drop in absolute terms later in the year?
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.
> Only the edge equipment would need to be IPv4+ aware.
"Only"? That's still the networking stack of every desktop, laptop, phone, printer, room presentation device, IoT thing-y. Also every firewall device. Then recompile every application to use the new data structures with more bits for addresses.
And let's not forget you have to update all the DNS code because A records are hardcoded to 32-bits, so you need a new record type, and a mechanism to deal with getting both long and short addresses in the reply (e.g., Happy Eyeballs). Then how do you deal with a service that only has a "IPv4+" address but application code that is only IPv4-plain?
Basically all the code and infrastructure that needed to be updated and deployed for IPv6 would have to be done for IPv4+.
Yes: but the process would have been exactly the same whether for a hypothetical IPv4+ or the IPng/IPv6 that was decided on; pushing new code to every last corner of the IP universe.
How could it have been otherwise given the original network structures were all of fixed lengths of 32 bits?
v6 has nearly 3 billion users. How is that abysmal?
We've never done something like the v4->v6 migration before, on this sort of scale. It's not clear what the par time for something like this is. Maybe 30 years is a normal amount of time for it to take?
No, routers would have to be fixed anyway, because even if you put extra bits into extension header we have 30 years of experience that routers and ISPs will regularly fuck around with those extra bits - it's related to why we have TLS GREASE option.
Application rework would be exactly the same as with v6, because the issue was not with v6 but with BSD Sockets API exposing low-level details to userland.
> 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.
Congratulations, you’ve re-invented CGNAT, with none of the benefits, and the additional hassle of it being an entirely new protocol!
No. No “extra bits” on an IPv4 address would have ever worked. NAT itself is a bug. Suggesting that as an intentional design is disingenuous.
Not just the edge router. Every router between the ISP edge and the destination edge.
And since the goal is “backwards-compatability”, you’d always need to poll, because a “legacy” IPv4 client would also be unable to send packets to the IPv4+ destination. Or receive packets with an IPv4+ source address.
And it would be an absolute nightmare to maintain. CGNAT + a quasi backwards-compatible protocol where the backwards-compatability wouldn’t work in practice.
So you would have exactly the same problem as IPv6. I can say the same about v4 and v6 today. You could just turn off IPv4 on the internet, and we’d only need to do translation on the edge for the legacy clients that would still use IPv4. You can even put IPv4 addresses in IPv6 packets!
I think you've actually reinvented 6to4, or something morally very close to it.
Each v4 address has a corresponding /48 of IPv6 tunnelled to it. The router with that IP receives the tunnelled v6 packets, extracts them and routes them on natively to the end host. This is something that v6 already does, so you don't need to make posts complaining about how dumb they were for not doing it.
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?
The IPv2 to IPv4 migration involved sysadmins at less than 50 institutions (primarily universities and research labs), updating things they considered to be a research project, that didn’t have specialised network hardware that knew anything about IP, and any networked software was primarily written either by the sysadmins themselves or people that one of them could walk down the corridor to the office of. Oh, and several months of downtime if someone was too busy to update right now was culturally acceptable. It’s not remotely the same environment as existed at the time of IPv6 being designed
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.
So... just a less ambitious IPv6 that would still require dual-stack networking setups? The current adoption woes would've happened regardless, unless someone comes up with a genius idea that doesn't require any configuration/code changes.
It’s not _that_ different. Larger address space, more emphasis on multicast for some basic functions. If you understand those functions in IPv4, learning IPv6 is very straightforward. There’s some footguns once you get to enterprise scale deployments but that’s just as true of IPv4.
> The current adoption woes are exactly because IPv6 is so different from IPv4. Everyone who tries it out learns the hard way that most of what they know from IPv4 doesn't apply.
In my experience the differences are just an excuse, and however similar you made the protocol to IPv4 the people who wanted an excuse would still manage to find one. Deploying IPv6 is really not hard, you just have to actually try.
Part of the ipv6 ambition was fixing all the suboptimally allocated ipv4 routes. They considered your idea and decided against it for that reason. But had they done it, we would've already been on v6 for years and had plenty of time to build some cleaner routes too.
I think they also wanted to kill NAT and DHCP everywhere, so there's SLAAC by default. But turns out NAT is rather user-friendly in many cases! They even had to bolt on that v6 privacy extension.
> I disagree. The current adoption woes are exactly because IPv6 is so different from IPv4.
How is IPv6 "so different" than IPv4 when looking at Layer 3 and above?
(Certainly ARP vs ND is different.)
But that is a bug in history. IPv6 was standardized BEFORE NAT.
“most what they know from IPv6” is just NAT.
> A less ambitious IPv4 is exactly what we need in order to make any progress
but we’re already making very good progress with IPv6? Global traffic to Google is >50% IPv6 already.
It would've been even easier and lasted longer to use two bytes of hex at the start. That would've expanded the Internet to 65536x its current space.
Something like aaff:a.b.c.d
Leaving off the prefix: could just mean strictly IPv4.
Think of it like phone numbers. For decades people have accepted gradual phone number prefix additions. I remember in rural Ireland my parents got an extra digit in the late 70s, two more in the 90s, and it was conceptually easy. It didn't change how phones work, turn your phone into a party line or introduce letters or special characters into the rotary dial, or allow you to skip consecutive similar digits.
For people who deal with ip addresses, the switch from ipv4 to ipv6 means moving from 4 digits (1.2.3.4) to this:
2001:0db8:0000:0000:0008:0800:200c:417a
2001:db8:0:0:8:800:200c:417a
2001:db8::8:800:200c:417a
Plus switching completely to ipv6 overnight means throwing away all your current knowledge of how to secure your home network. For lazy people, ipv4 NAT "accidentally" provides firewall-like features because none of your home ipv4 addresses are public. People are immediately afraid of ipv6 in the home and now they need to know about firewalls. With ipv4, firewalls were simple enough. "My network starts with 192.168, the Internet doesn't". You need to learn unlearn NAT and port forwarding and realise that with already routable ipv6 addresses you just need a firewall with default deny, and then add rules that "unlock" traffic on specific ports to specific addresses. Of course more complexity gets in the way... devices use "Privacy Extensions" and change their addresses, so making firewall rules work long-term, you should use the device's MAC Address. Christ on a bike.
I totally see why people open this bag of crazy shit and say to themselves "maybe next time I buy a new router I'll do this, but right now I have a home with 4 phones, 3 TVs, 2 consoles, security cameras, and some god damn kitchen appliances that want to talk to home connect or something". Personally, I try to avoid fucking with the network as much as possible to avoid the wrath of my wife (her voice "Why are you breaking shit for ideological reasons? What was broken? What new amazing thing can I do after this?").
The main thing is keeping current addresses, not having both an ipv4 and ipv6 address.
Just like for an apartment you append something like 5B. And for a house you don't need that.
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.
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.
There’s absolutely, utterly zero chance IPv4+ would be adopted. CGNAT is the solution to the social problem.
I don’t even buy your way of thinking - unlike an “engineering” solution or an “incentives” solution, the problem with “social solutions I speculate about” is: they offer nothing until implemented. They are literally all the same, no difference between the whole world of social solutions, until they are adopted. They are meaningless. They’re the opposite of plans.
Like what’s the difference between IPv4+, which doesn’t exist, and “lets pass a law that mandates ipv6 support”? Nothing. This is what the mockery of “just pass a law” is about. I don’t like those guys, but they are right: it’s meaningless.
This is a good point. The same “why should I migrate” would affect it. However, it being so close to the predecessor, it would be much easier to do so, catching way more people who are on the fence.
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.
> The IPv4+ could pass through a router that doesn't know about it
It couldn't do that reliably. We don't have any flags left for that that. Options are not safe. We've got one reserved flag which is anyways set to 0, so that's not safe either.
That bit is currently defined as "Bit 0: reserved, must be zero", so there will be network gear out there, that either drops the packet otherwise or resets the bit to 0 when forwarding.
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.
So well said! Those are great comparisons.
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.
They didn't screw up. They made it a breaking change to OSs because it had to be a breaking change to OSs. If anyone screwed up here, it was the people who made v4, not the ones that made v6.
For ping, I think it originally had different binaries because ICMPv4 and ICMPv6 are different protocols, but Linux has had a dual-stack `ping` binary for a very long time now. You can just use `ping` for either address family.
The whole ping vs ping6 seems more likely than lazy developers.
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.
The IETF explicitly says the goal of IPv6 is to replace IPv4, not to run alongside it. We're very far from that goal. https://datatracker.ietf.org/doc/html/rfc8200#page-4
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.
because you dont need to. Thats what (m)DNS is for.
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.
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.
Man, readability of IP numbers is a important thing. You are not always in a situation where you can simply copy the address.
I can tell you what is what simply from the Ipv4 address, but when its IPv6, my dyslexia is going to kick my behind.
Readability reduces errors, and IPv6 is extreme unreadable. And we have not talked yet about pre-fix, post-fix, that range :: indicator, ... Reading a Ipv6 network stack is just head pain inducing, where as Ipv4 is not always fun but way more readable.
They where able to just extend IPv4 with a extra range, like 1.192.120.121.122, 2.... and you have another 255 Ipv's ... They did the same thing for the Belgium number plates (1-abc-001) and they will run out in the year 11990 somewhere lol...
The problem is, that Ipv6 is over engineered, and had no proper transition from Ipv4 > Ipv6 build in, and that is why 30 years later, we are still dealing with the fallout.
Genuinely speaking, that sounds like a process issue if you really can't copy/paste. Perhaps you don't have control over whichever scenario you're talking about but not describing, but data entry is famously error prone regardless of it being 12 characters or 32, and if you're trying to focus on reliability, avoiding errors, you should be avoiding it at all costs.
Sure most people don't care, just the ones who have to figure out why it's not working, and man does it suck for them.
I can keep a v4 in my head, briefly. v6 not so much. Or shout one across a room to someone.
Of course that’s due to the relatively small amount of information it contains and having a larger address space is always going to break that.
Do you live under a rock? The memorability of ipv4 was one of the major issues brought up from the very beginning.
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.
"Hey Bob, what network is that machine on?"
"Easy,2a06:a003:1234:5678"
"2806:8003: and then what, I forgot the rest?"
If you want you can check free app to calculate it -> https://alertsleep.com/tools/subnet-calculator
remembering 10.254.158.58. Easy - the first 4 octets.
remembering 2a06:a003:1234:5678::555a:bcd7/64. Your cheapest shotgun and one shell please.
and xx is birtday ?
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.
That seems oddly rigid though. I need to known in advance which networks will definitely never need subnetting so I can assign them a /64.
Why have so, so many address bits and then give us so few for subnetting? People shame ISPs endlessly for only giving out /56s instead of /48s, pointing at the RFCs and such. But we still have 64 entire bits left over there on the right! For what? SLAAC? Was DHCP being stateful really such a huge problem that it deserves sacrificing half of our address bits?
> That seems oddly rigid though.
We're past that for a decade, but various services have not caught up yet https://datatracker.ietf.org/doc/html/rfc6177
The actual intention has always been that there be no hard-
coded boundaries within addresses, and that Classless Inter-
Domain Routing (CIDR) continues to apply to all bits of the
routing prefixes.> I DO think using 64 bits for hosts was stupid but oh well.
Hey man, if I want to assign an address for each individual transistor in my system, that's my business.
Or do funny things like encode RGB values https://hackaday.com/2018/12/24/ipv6-christmas-display-uses-...
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.
Even the vendor representatives are mostly getting paid to post on mailing lists and show up at conferences.
They're not building products, and they're not supporting, visiting or even talking to their customers. Design-by-committee is a full time job that people actually building things for a living tend to not have time for.
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?
> 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?
Yes, an interface can hsve two separate IPv6 addresses, but that doesn't make it easy.
If you do the easy and obvious thing of setting up two routers to advertise their prefix with your preferred priority when they're available (and advertise it as unavailable when they're not), your devices are likely to configure themselves for addresses on both prefixes, which is great.
Then when you open a new tcp connection (for example), they'll pick a source address more or less randomly... There's a RFC suggestion to select the source address with the largest matching prefix with the destination address, which is useful if the prefix is pretty long, but not so useful when the prefix is 2001:: vs 2602::
Anyway, once the source address is selected, the machine will send the packet to whichever router most recently sent an announcement. Priorities only count among prefixes in the same announcement. If you manage to get a connection established, future packets will use the same source address, but will be sent as appropriate for the most recently received advertisement.
This is pretty much useless, if you want it to work well, you're better off with NAT66 and a smart NAT box.
> If you have a server that listens to requests though, such as an HTTP server, I don't see how this setup would be grossly inadequate for the purpose.
That's the problem. It sounds like it would work if you do this. The documentation suggests multi homing like this would work. When your server gets a request, it sends back the response from the address it received on... but the problem is what router it sends to; when it sends to the correct router, everything is good, when it sends to the wrong router, that router's ISP should drop the packets, because they come from a prefix they don't know about.
> I would experiment with advertising two default routes, one with a significantly higher metric than the other.
Sounds like it would work, but as far as I've found, the priority metric only works if the prefixes are in the same advertisement. If each router advertises its own prefix, the actual metric used is most recent advertisement wins as default route.
As I recall, I tried Windows, Linux, and FreeBSD and it was circa 2020. 25 years in, bad OS support for a supposed feature means the feature doesn't work.
> 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?
Because it breaks your network when that router goes away. Your switch ACLs, firewall rules, and DNS records all become invalid because they contain addresses that no longer exist, that your devices continue trying to reach anyway.
Had to move away from pfSense due to this. It just wasn't possible to stop it giving my devices its public IP as DNS.
So every time I got a new prefix, machines would lose connectivity, usually until I rebooted them.
Switched to OpenWRT which respected my ULA.
In the IPv4 world, it's easy. Just use NAT, and forward everything over your preferred bearer. Have your router ping 8.8.8.8 or something periodically from that WAN interface to verify reachability. If your preferred link goes down, make your backup link the primary route, clear your NAT translation table, and your local devices remain mostly oblivious that anything happened.
> It's easiest to do by abstracting your site away. Make it use a LAN, and do port-forwarding and proxying through a box that knows about the multiple uplinks, and handles the switch-over when one of them goes down. I don't see how it might be easier with IPv4 than with IPv6.
In the IPv6 world, this is pretty much what you have to do. A whole lot of extra complexity and expense that you didn't have previously.
> You should be using dynamic DNS
That doesn't solve the problem. DNS remains broken until each and every device, assuming VERY generously that it is capable of dynamic DNS at all, realises that one of its prefixes has disappeared and it updates its DNS records. With DNS TTL and common default timeouts for prefix lifetime and router lifetime, that can take anywhere from 30 minutes to 30 days.
> and firewall rules should be on the subnet boundary in this scenario, any decent firewall (including referee PFsense/OpnSense) support ACLs that follow IPv6 address changes.
This requires you to assign one VLAN per device, unless perhaps you've got lots of money, space, and power to buy high end switches that can do EVPN-VXLAN so that you can map MAC addresses to SGTs and filter on those instead.
The amount of ignorance in these ipv6 posts is astounding (seems to be one every two months). It isn't hard at all, I'm just a homelabber and I have a dual-stack setup for WAN access (HE Tunnel is set up on the router since Bell [my isp] still doesn't give ipv6 address/prefixes to non-mobile users), but my OpenStack and ceph clusters are all ipv6 only, it's easy peasy. Plus subnetting is a heck of a lot less annoying that with ipv4, not that that was difficult either.
I want to send my ssh via my low latency reliable connection, I want to route my streaming via another connection. That’s just a routing rule and srcnat in ipv4
That’s before you go on to using PBR. I want to route traffic with different dscp via different routes.
Ultimately I want the rout g to be handled by the network, not by the client.
IPv4 and nat makes that a breeze.
> any decent firewall (including referee PFsense/OpnSense) support ACLs that follow IPv6 address changes
In the case of pfSense this is a recent change. It was not supported when I migrated away from it less than five years ago.
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.
x2048 is a lot though! Maybe we should let the robots figure out their own solution, rather than trying to make every atom on Earth individually addressable :)
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.
What would a new standard do that would make it more popular? IPv6, for all its faults, is designed to be the last Internet Protocol we will ever need.
Funny enough I actually looked at a scheme for corporate networks where your personal corporate ID is encoded as part of the host bits of the IPv6 packet and policy could be applied based on who you are instead of what machine it is (or both). It was kind of neat but the complexity was too high for it to gain traction, and also it turns out that most corporate networks are allergic to IPv6 and government networks doubly so.
It will not. People underestimate the amount of effort went into IPv6 implementations.
This absolutely can and should happen
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.
I mean this is just wrong. Routing and switching behave exactly the same in V6 vs V4. Details on how you get an IP and what it looks like changed but there's TONS of knowledge shared between the two.
When I configure a new router at my home, routing is barely a blip on the radar. I mean, everything that's not local goes upstream. Switches just swich, I plug in cables and they work.
The things I need to think about are precisely the things that changed radically. Firewall rules aren't the same due to prefix changes and no NAT. DHCP isn't the same, DNS isn't quite the same, distributing NTP servers isn't the same.
Almost nothing of what I knew about configuring my home router for IPv4 has transferred to IPv6 configuration.
Yes, the only key difference is that NAT is gone.
Also a nitpick: switching is irrelevant here, that’s L2. L2 doesn’t even know what’s an IP address :)
There was some dude on YouTube that resurrected the first Ethernet bridge (which was built for thicknet) - I recall even that worked with IPv6.
"Details on how you get an IP and what it looks like changed but..."
This is exactly what I'm talking about. When you have problems with your IP network, that's the first thing you try and figure out, "what's my address? Why is that my address? Did it change? If so, why? Are other devices able to get packets? What are their addresses? Why can those addresses get packets but this address can't?"
> 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.)
Multiple networks do the same - Both T-Mobile (at least in EU) and Orange no longer actually support v4 other than through funky 464 and by funky I mean really funky at times.
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.
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.
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...
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.
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.
>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.
Maybe but it's a common platform and explains why IPv6 support still isn't fully there.
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 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.
> In 2026 it does not.
There are no ISP providing ipv6 for home and mobile users here in hong kong
The hardware support is very likely already there.
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 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.
Just thinking of the mountains of ewaste that decision would produce makes me ill.
What about end user hardware? Chromecasts, TVs, IoT-whatevers, POS machines, kiosks, signage, etc.
Almost every network in existence runs on layers of tunnelling, so you can run arbitrary protocols over fixed hardware. We tunnel IP over Ethernet and then we don't have to replace our switches to use new IP versions or features. Most clouds use VXLAN. Many ISPs actually tunnel your IPv4 traffic over a purely-IPv6-only network, to a specific device whose job is to deal with legacy IPv4. The reverse is also possible if you have a network that can only handle IPv4.
If they set the deadline in 10 years, there would be (smaller) mountains generated in that period anyway.
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.
> 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.
Ford Motor Company has both a /8 and a /9. They own over 16 million ip addresses.
Relatedly, I've been seeing some people buying up old domains and squatting on them with AI generated content. Not even ads, but content that seems like something that might actually show up in a rare Google search query. Not really sure what the play is or why this is better than advertising the domain for sale (do registrars punish overt squatting these days?).
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.
IPv6 and CGNAT growth has finally started to suppress IPv4 prices. There was a huge pump when hyperscalers decided they needed more. But IPv6 keeps growing and is the majority of traffic in many networks. If you own significantly more IPv4 addresses today than you need, I would dump them on the market yesterday. Spend some of the profits to move to IPv6 if still needed.
nice. I wish I could buy an address instead of renting from aws...
It seems like the addresses cost about $20 each, and can be rented out for ~$5/year.
That doesn't seem terrible.
How does one get an IPv6 allocation for free? Or, do you mean the ULA space? Because the latter doesn't really count.
You just ask your RIR. For example: https://www.arin.net/resources/guide/ipv6/first_request/
Yeah. If you're not an ISP or other LIR yourself, the correct path is to ask your ISP or a third-party ISP for a provider-independent allocation. This costs a nominal fee, about $50 per year.
I only know anything about RIPE policies but I gather the PI address processes and fees are very similar between RIPE and ARIN. RIPE has many members that are willing to handle address allocations for the RIPE fee plus 20% (so 60€ per year) and without bundling any other services.
In the end you're still just asking for a block, you don't pay for it. There are requirements which vary from RIR to RIR, sure, but there were requirements for requesting blocks in IPv4 as well originally.
Ultimately, as a regular person requesting IPv6 space you'd just ask your ISP, which can get practically as much as they want for free by submitting these kinds of requests. Meanwhile, for IPv4 space they're going to have a harder and harder time getting you additional space and chances are be unwilling to give it free/cheap.
right above that is says: "If you meet any of the criteria below, you qualify to receive IPv6 address space:" (emphasis added)
this depends on your RIR. RIPE has far less strict requirements.
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.
As others have mentioned, there's SNI and host headers to have multiple sites on port 443, but there is also the SVCB/HTTPS aliases (https://www.rfc-editor.org/rfc/rfc9460) which will allow having the plain domain alias to other hosts including ones with embedded port numbers. Non-browser support is pretty lacking though.
That’s sort of what HTTP is already doing though no?
Multiple websites can have the exact same DNS record and live on the same physical server / IP address, but the HTTP(S) request must specify what host name it is actually requesting, so the server knows how to serve it.
It is already possible using the Host header and TLS SNI. But traffic still flows through port 443.
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.
Presumably this would be port-based fractional and 443/tcp would cost a premium.
I was thinking it was more of a "more than 50%" ownership controls the routing tables. Love the chaos.
It's already possible to "split" a frontend HTTP server on a given IP and port to arbitrary backend IPs and ports via the Host header and reverse proxies.
> 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?
The problem with private address ranges is that everyone thinks they're available. In a large enough enterprise you're bound to have conflicts. They usually pop up at the most inconvenient time and suddenly you're cosplaying ARIN in your IT department.
> everything fit's nicely in the 10.0.0.0/8 range
Except during a merger/acquisition and both companies have 10.0.0.0/24 in their OSPF or IS-IS topology.
> everything fit's nicely in the 10.0.0.0/8 range
Except for when it doesn't.
If you just use that space as a flat range, it is almost certainly more than enough. But if you split it up in multiple levels of subnets, you can run into difficulties balancing having enough subnets and having enough space in each subnet.
It is not private, it is merely "reserved". If/when that range opens up for Internet address, you'll be in a world of hurt for having used it.
IPv6 is much more stable on what you can use. fc00::/7 is actually private use.
We burned thru pretty much all of our public /8, RFC1918, and have begun digging into RFC6589 (a /10 I didn’t even know existed prior to job). Still shocks me. Hardly an expert in the space, but I think the issue comes from subnetting to distribute ranges to teams that need a consistent IP address space for some project or another. Lots of inefficiency & hoarding over time. We’ve had legitimate outages and impending platform death staved off by last minute horse-trading & spooky technical work due to such things. IPV6 has always been a distant aspiration.
Grow large enough and you hit the limit pretty fast. NAT complicates things.
The best one is async routing. You have a NAT, they have a NAT, you VPN together and think you have different IP address ranges, but unknown to the operator there's a little internal network with an overlap at the end of some slow line that is now getting flooded with internal traffic that's trying to go to a completely different network.
I've worked for companies with over 50,000 employees and they didn't seem to need it. Now, sure, there are larger companies, or ones that employ huge farms of machines, but those are the exception rather than the rule.
you haven't had to set up intercompany vpns I see
Pretty much every fortune 500 company does, which counts for millions of people on their networks every day. The troubleshooting calls for VPN routing vs internal LAN routing are fun endeavors of who is actually willing to take responsibility for things they don't understand.
Unless you get to big. Or you merge with another company and have to combine your internal networks and oops, all the subnets are overlapping. Or you need to serve mobile clients who get better connectivity over v6.
if both you and companies you have site to site vpn with have IPv6 there is no IP conflict or NAT to worry about.... and that's about end of the advantages
one poorly made decision and oops you're out of 10/8 addresses
if you've never run in to this, then sorry, you've not been in an enterprise, you're in a mom 'n pop shop cosplaying as enterprise.
> 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
Wasn’t it mandated for 4G? Or at least 5G?
IIRC LTE had licensing shenanigans which made v6-only cheaper, and 5G doubled down on them
> 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.
It is why the Google IPv6 stats fluctuate between weekends/holidays and weekdays. IPv6 is much more prevalent on home and mobile networks so increase on non-work dyas. Companies have IPv4 networks that they don't want to upgrade. We have dichotomy where 50% of clients have IPv6, but most of the small sites do not.
The other thing I have seen is that engineers make things complicated. Normal person has IPv6 enabled by default or enables it in router, and it just works and they never notice. Engineers want to configure things manually, but IPv6 is hard if fight against the dynamic defaults.
Maybe the False Consensus Effect?
Anecdotal stalemate.
I use this argument, because HN also tries to do the reverse when someone suggests a protocol/addition/replacement to either TCP or HTTP. Then suddenly it's important what shitty company networks do. It's still not.
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.
Google's stats are tracking the percentage of people that reach Google over IPv6. That means they've not just been given addresses, but they configured them and are actively using them. How can that possibly not count as "adoption"?
That’s Apple’s fault. Why are you blaming it on IPv6? Oh, because Apple can do no wrong.
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).
Interesting that this is getting downvoted. I truly wonder why. One of the things LLMs are good at is summarising and extracting key points. Or should I have gone to the trouble to do this myself - read the entire comment thread and manually summarise - when the person I was replying to hadn’t done that? My comment was meant in good faith: “here’s the info you wanted and how you can easily get them yourself next time”.
So cheap questions where the answers could be readily had are not downvoted even though the answers to their question are right here in the discussion. Whereas because I did not do the legwork that my correspondent would not do, I am penalised. That’s what I’m hearing.
EDITED TO ADD:
> by reading your LLM output I am doing you a favor by spending more time reading than you did generating
How could my respondent (presumably on whose behalf you are making the argument) possibly be doing me a favour when they asked the question? Is it each of our responsibility to go to some lengths to spoon feed one another when others don’t deign to feed themselves?
And yet the llm did a better work of disparaging everyone comments as uniformed, which they are btw.
You're not offering anything of value. We all can ask some LLM about stuff we want to know. It's like in the past, when someone would post a link to search results as a reply.
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.
No. People fail to configure it. Then start to question why this piece of garbage exist.
It doesn't matter what problems it supposed to solve if it doesn't work.
Maybe your magic ipv6 configures everything.
My have certain shortcomings: it doesn't assign dns names to hosts and doesn't configure firewall rules
> 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.
You are not bypassing the router, the devices need to get their packets from somewhere, and it is only like a forever-open port if the router/firewall decides it is.
My ISP router supports IPv6 but blocks all incoming connections by default, which is kind of like what NAT does as a side effect.
It sounds like insanity because we tend to assume that no NAT means no firewall, because NAT has some firewall-like properties, and on the most basic networks, that's the only "firewall" there is. But none of the security features of "NAT as a firewall" are exclusive to IPv4, in fact, IPv6 has an advantage because the much larger address space makes a full scan practically impossible.
> You are not bypassing the router, the devices need to get their packets from somewhere, and it is only like a forever-open port if the router/firewall decides it is.
This trips up a lot of people, and I think it's because NAT was probably their first real exposure to networking. When that happens, you end up building all your mental models around NAT as the baseline, even though NAT itself is really just a workaround for address space limitations.
What's interesting is that someone with no networking background who thinks of it like a postal system (packets are letters that get forwarded through various routing centers from source to destination) would actually have a more accurate mental model of how IP networking fundamentally works. The NAT-centric view we all learned first can actually make the basics harder to understand, not easier.
Whether the packets forward it’s still leaking your network topology to attackers which is so boneheaded I don’t know where to start.
Anti nat advocates seem to fall into the “the network shouldnt provide a stateful firewall” camp, because once you have a stateful firewall then nat is a trivial amount of extra bytes and very few issues with modern protocols (ones which don’t embed layer 3 addressing in layer 6/7 messages)
I like the end-to-end principle. Good times.
>Anti nat advocates seem to fall into the “the network shouldnt provide a stateful firewall” camp
Eh, what?
My entire justification for getting rid of NAT is *because* a default-deny-inbound firewall policy should exist, and NAT is a network patch that functions as a hacky firewall at the consumer level.
It's a big privacy problem too. Basing your IP address on your Mac address doesn't help in that regard either. Times have changed a lot since IPv6 was invented.
> Basing your IP address on your Mac address doesn't help in that regard either.
This hasn’t been the case for 20 years. Privacy Extensions solved that, and every SLAAC implementation supports them.
> 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.
And so are firewalls?
firewalls are a choice that the enduser makes.
non-routed prefixes are a limitation imposed by the ISP the the user can't address.
> 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.
And yet DHCPv6 is pretty much the standard because you need to push other things into client.
Need I remind you that option to push DNS server (which is pretty fucking important option!) was added to IPv6 standard only in 2007 ?
Like, someone decided "yeah have that magical stateless autoconfig thing" and didn't figure out that basic options like DNS, or less common but still VERY useful like the PXE stuff, or NTP server, routes and dozen others DHCP does? (there are security implications too but DHCP wasn't great here too)
IPv6 in its original format was a joke and stateless configuration is more or less pointless excercise aside from link-local adresses but those could be only exception where stateless runs
The NTP server thing was especially egregious given that the transition to everything being under TLS was underway and clocks matter in that situation.
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.
The truth is nothing needed fixing, or we wouldn't have been in this position 30 years later
> reduces network complexity once you go v6 only
What networks are v6 only today?
> So v6 solves several technical and policies issues with the Internet,
If it's not used it doesn't solve anything
> They don't really have an incentive to implement V6 unless things start to break without it
Exactly my point
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.
They did have a proposal for 64bit...was ipv7.
They also had IPv9 with 20 byte addresses (160 bits) though some of that was consumed for common prefix announcing "this is a TUBA address". It was even something that was already supported by some hardware and software, as it was just dropping IP and replacing it with CLNP and transporting TCP and UDP over it (I think the most complex part was adapting ICMP-based tools).
how would you do SLAAC with 64 bits?
Was DHCP so bad? It carries information important to using such a device anyway.
well, its not without issues. the actual motivation was not that dhcp is the suxxors, but to promote a model where the assigned prefix was free and highly dynamic.
the goal being to support a model where one could support multiple prefixes to handle the common case of multiple internet connections. more importantly to allow providers to shuffle the address space around without having to coordinate with the end organization. this was perceived to be necessary to prevent the v6 address space from accruing segmentation.
It's funny the "handle the common case of multiple internet connections" just doesn't work at all with ipv6 yet works much better under IPv4 NAT. With IPv6 each machine gets it's own routing table due to having two addresses which means I can't failover on the router when an ISP goes down. Machine will keep trying to use the ISP that is having 100% packet loss. I can't prioritize sending traffic out of one ISP because I'd need to configure it on each machine due to them having their own routing table. With IPv4 the router can handle those rules since its doing NAT for all machines in the network so it gets to choose.
Well that was a failed idea which has since been abandoned by anyone trying to remain half sane while deploying IPv6.
+1, the majority of corporate networks I have seen used DHCPv6 or similar anyway
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.
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.
Just because the ISPs have implemented IPv6 doesn't mean anyone's home router is using it, let alone all the devices in the home WiFi
I'm on a large ISP provider and they do not have IPv6 in my area, a new build with fiber to a access point that turns it to cable on the house. So there's that.
Obviously they are. Most people use the equipment provided by their ISP without ever changing any settings.
If the ISP is IPv6-first, you bet that their customers are using it in their home WiFi.
> 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.
Came to post that blog. It's awesome. Everyone should read it.
> 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
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 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:
nsupdate -v -y "${KEY_ALGO}:${KEY_NAME}:${KEY_SECRET}" <<EOF
server $DNS_SERVER
zone $ZONE
update delete $RECORD AAAA
update add $RECORD 300 AAAA $CURRENT_IP
show
send
EOF
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.
You’re looking for a Unique Local Address there. It’s a non-externally-routable address that you can use for internal connections.
Problem with ULA is that it's functionally useless on a dual-stack network, because clients will attempt to use IPv4 before they attempt to use ULA.
https://blog.apnic.net/2022/05/16/ula-is-broken-in-dual-stac...
Note that although the policy is that you choose a random prefix, nothing actually enforces this and nothing stops you using fd00::1, fd00::2, etc just like 10.0.0.1 etc.
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.
On the other end of the connection, there are physical servers and routers. Every once in a while they change how things are connected/deployed for maintenance, upgrades, etc.
Pretty much, I have my cable modem on continuous power and it will keep the same address pretty much forever. Two times it changed is when I had a 48 hour power outage and shut everything down, and the other time was maintenance at the cable companies side where they rebooted their equipment.
My xfinity ipv4 changes once every few years, if that. I treat it as static and update things if or when it changes, which fortunately isn’t too much work. I never requested anything special regarding it, and I have a normal/non-business account. I wonder why some change often and others don’t?
I had Xfinity for 4 years and my IP changed once in that time! Now I have fiber from centurylink, and it changes anytime I need to reboot the fiber modem or my firewall. Different companies, same metro area though. That too makes me wonder about how both manage their allocations give the difference in IP assignments.
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
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.
100g interconnects are very cheap, but I'm more talking about oversubscription in the ISP network -- as they have multiple peering and transit arrangements it's clear that if you have 10,000gbit worth of customers, you don't need 10tbit of connectivity for each transit provider.
Where I live the cable system is fine, and the cellular system is fine... until one goes down, then the other gets flooded with traffic and stops working leaving no internet at all.
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.
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.
What do you do about IoT devices?
Why would that be a desirable quality? Wifi devices (using Matter or not) live on the same network as my PC - meaning a compromised lightbulb (or one that hasn't been updated) can be used to infiltrate and attack my home computers.
Thread+ Matter, despite using a different radio, suffers from the same issue, since a border router is on the Wifi network, a smart bulb using Thread can theoretically access my PC.
Yes, I'm sure there are ways to fix this, but why have the problem in the first place?
Zigbee is entirely incompatible networking standard, and doesn't have this problem.
for me, I don't need to even setup NAT64. My ISP provides it for me free.
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.
Devil's advocate. There could be a extension for ipv4 stacks. Ipv4 stacks would need to be modified to include the extension in any reply to a packet received with one. It would also be a dns modification to append the extension if is in the record. Ipv6 stacks would either internally reconstruct the packet as if it were ipv6.
It would be easy to make such an extension, but you're going to hit the same problem v6 did: no v4 stacks use your extension.
How will you fix that? By gradually reinventing v6, one constraint at a time. You're trying to extend v4, so you can't avoid hitting all of the same limits v6 did when it tried to do the same thing. In the end you'll produce something that's exactly as hard to deploy as 6to4 is, but v6 already did 6to4 so you achieved nothing.
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.
You clearly do not understand networking. Or else you won't make such a statement:
>This is stuff that could be implemented in any ipv4 stack in some days of work.
The sysadmins across the world, who had to deal with decades-old, never-updated devices facepalmed in unison.
At least the other comment agreed that "IPv4+" hosts will never be able to talk to IPv4 hosts.
>IPv6 is overengineered, thats the reason why it's not adopted after 30 years.
It is already adopted in many countries. Don't blame the protocol for your countrymen's incompetence.
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!
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.
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).
> The future is now.
One part of it is for some-to-many folks, yes, and the third is here for a distressingly large number of people (without the solid support of the second part). Do note that the future I outlined has three parts. ;)
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 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 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
Yes, I've never played a DVD or CD on my Bluray player. That just didn't works.
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.
No, it's not. If I have an ipv6 network, an ipv4 address is invalid. It's that simple.
It's not that simple at all. For one thing, having a v6 network doesn't mean you can't have a v4 network. You can run v4 in exactly the same way you currently do, with exactly the same software, and it'll work no worse than it already does.
But for another, the v4 space is available as a subset of the v6 space:
$ ping 64:ff9b::8.8.8.8
PING 64:ff9b::8.8.8.8(64:ff9b::808:808) 56 data bytes
64 bytes from 64:ff9b::808:808: icmp_seq=1 ttl=113 time=9.82 ms
No, that would be forwards compatibility. v4 doesn't have forwards compatibility with any address protocol that uses addresses bigger than 32 bits, and it never will regardless of how that protocol is designed because the flaw is in v4's design.
There is no possible way to design an address protocol with bigger addresses than v4 that a) makes v4 forward compatible with it, and b) can actually work. Feel free to suggest one.
> .0.0.1 needed to be a valid IPv6 address, along with all the others. Pick a particular prefix, say 0...* and any address with that would be extended to 128 bits
That prefix is ::ffff:0:0/96. 127.0.0.1 is ::ffff:127.0.0.1 (::ffff:7f00:1). 30 years and you still haven't realized v6 has this?
No, it’s not—IPv6 networks are totally capable of providing IPv4 as a service. SIIT-DC, 464XLAT, MAP-T
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.
v4 supports extension headers and over a thousand bytes of arbitrary payload so if the only thing you needed was a couple of bits in the packet, there was never any issue with finding them.
The problem is that you can't use those bits to expand v4's address space, without taking all of the same steps v6 needed to do. v4 has no mechanism to get v4 hosts to understand extra address bits, wherever you put them.
Oh, that and the fact that IP addresses are stored in many more places than just the v4 packet header. Consider DNS, DHCP, ARP, gethostbyname(), struct sockaddr_in, databases using VARCHAR(15), etc etc etc. The packet header is only a tiny part of the story.
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 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.
Many ISPs do rotate the prefixes that they assign to customers. There’s plenty of people on here complaining about it as a reason not to use IPv6.
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'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
It's not at all clear to me that Mobile IP would be viable at the scale of a modern wireless service provider. It amounts to routing all traffic to/from the mobile device through a machine on the network of its "home" IP address. Without some fairly invasive routing shenanigans, this would be disastrously bad for users traveling far from their home network (e.g. a user gone on vacation).
Not that it matters, really. As far as I'm aware, there were never any substantial deployments of this protocol.
I was more responding to OP's tongue in cheek comment about government assigned addresses
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.
Compared to 0% like others?
50% is a very substantial retention rate.
>if his site supported ipv4 natively
And it's becoming difficult for people to do so precisely because of IPv4 addresses running out...
This has nothing to do with anything inherent to IPv6 and everything to do with the failure of organizations to timely implement it.
I didn’t say it was an issue inherent to IPv6. But it is a practical issue with IPv6.
> 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!
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!
You are being tracked on IPv4 via the gateway address. It's no different. Changing your local IPv4 address does absolutely nothing, while changing the local IPv6 address does almost nothing. Hooray.
Oh but it is different. It for example doesn't leak how many unique devices there are on your network. This might be very useful in a world that is moving towards authoritarian tech dystopia at mind-boggling speeds.
Yes, yes, we have privacy extensions, but you can still group those through higher-level fingerprinting. You don't get mixed traffic.
> beside that my internal ip's are changing every day to bring more confusion into my internal net. nice!
You can set it up so your devices can have two IPv6 addresses. The shifting address for external traffic, and a static one for local traffic. I think this is the default in many linux distros now.
my mistake, sorry. I meant MAC - but I learned it is no longer the case (at least not always). There used to be the standard that your IPv6 is concatenation of your MAC and part of router's external IP.
The problem with IPv6 jokes is that very few people are making them.
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 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.
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.
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...
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.
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.
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
Bless them for not allowing it.
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:
SetNetIPv6Protocol -UseTemporaryAddresses Disabled
SetNetIPv6Protocol -RandomizeIdentifiers Disabled
sysctl net.ipv6.conf.all.use_tempaddr=0
ip6-privacy=0
ifconfig em0 inet6 -temporaryYeah. ULA and nat66 would work nicely. Except you would get murdered for asking about nat66.
I'm convinced half the ipv6 subreddit is made of people who don't actually like ipv6 and are trying to subvert it. The advice they give sometimes is just insane. "Just get a new ISP bro..."
I think a lot of people assume privacy addresses are required. You can just not mess with them. Privacy is dead anyway.
"Build yourself an IPAM solution, at great operational cost and complexity."
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?
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.
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.
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.
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.
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.
I have never seen a single router that supports IPv4 NAT, IPv6, and not an IPv6 firewall. I’m skeptical that they exist.
If you look hard enough you will find some, but it's not common.
Half of the Internet is using v6. If a lack of firewall was as common or as dangerous as people think, the supposed security disaster would have already happened. It hasn't.
> any consumer/home network will be exposed to the internet if they're using SOHO equipment via IPv6 and won't be via IPv4.
Only if the ISP does no egress filtering. Most mobile carriers I’ve used deny inbound connections.
I don't think "IPv6 is safe because ISP is blocking all your ingress traffic" is a positive argument for an IP standard that's supposed to enable every device to be routable on the internet without things like NAT.
(Also, why the fsck would I want to have an ISP that does that?)
It keeps getting repeated precisely because it isn't gaslighting. And yet we still see people claiming that NAT is security.
The only reason those networks aren't exposed to the whole Internet on v4 is because they're using RFC1918, not because of NAT -- but that still leaves them exposed to some outside networks, so routers come with firewalls, which act as an actual security boundary.
And they won't be exposed on v6, because those exact same firewalls work their magic on v6 too.
NAT doesn't provide and isn't needed for security. Its main security contribution is to confuse people about how secure their network is.
I'd expect folks would see the behavior you're describing here as being part of security.
However, NAT in the real world doesn't work the way you're describing here. My position is based on how NAT actually behaves, not on incorrect descriptions of how it behaves.
Or perhaps you could explain how NAT stops inbound connectivity at the NAT edge? I've tested and it doesn't, so I don't think it's possible to explain how it does, but I'm open to being wrong on that if anybody could actually explain it in a way that doesn't contract actual observed behavior.
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"?
> What makes them a pain to block?
Not wanting to cut off access to your users from, for example, every AT&T device (and their MVNOs).
Since cgnat means NATing a huge number of legimate device to a single ip. So angry users is the answer. Also note mobile users are usually the cgnat.
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.
This is a win for the consumer though, we don't want to be tracked, your inability for abuse prevention is my ability to stay hidden in the crowd. Why should I care?
my ISP is bound by my countries privacy regulation, I replace the trust of one party with every website i visit that could be located in fascist regimes without such laws.
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.
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.
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.)
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....
Evolution is the survival of good enough. IPv4 is good enough.
> but IPv6 is better
It doesn't solve any life-changing problem.
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 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.
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.
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.
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.
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.
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 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.
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:
Heh, 49.84% on Aug 2nd. Pretty sure it'll cross 50% in 2026, even if only for a few peaks.
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 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.
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.
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.
IPv6 is the protocol of the future. And will be.
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.
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.
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`.
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”
That's kind of my point though: it didn't need to be written to expect a v6 upgrade, because the socket API is family-agnostic.
20 years ago, getaddrinfo() was 7 years old. You should have been using it already by then.
Google's ipv6 stats[0] are stuck in Dec 17.
However, extrapolation suggests the 50% mark might have finally been crossed around year end.
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.
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....
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 definitely do both ULA and GUA at home, but this only really works well to the degree that the OS will prefer the ULA when connecting to things. Like if I want to put hostnames in netgroups, I need reverse DNS to work (which only works if the client is using the ULA address I expect.) In fact the whole idea of reverse lookups working and having expected hostnames show up where you want them to (logs, etc) really depends on not only using ULA for connections, but using the stable address and not the privacy address, which can also cause issues.
For the most part it works today, if I stick to using ULA’s only in my zone file, and configure hosts to prefer the DHCPv6-provided ULA for connections in the ULA subnet, it’s fine. But suddenly if you connect to somehost.local instead of somehost.fqdn, the machine picks a GUA source address and you’re back to being unpredictable.
So although I say I want to use NPTv6 and be ULA-only, I don’t actually do that today, so I’m not super familiar with the downsides to the approach. But it does sound a lot cleaner to me in theory.
> if you're only using it for outbound connections then it changing isn't going to break anything.
A prefix change absolutely does break things in a lot of setups though. It happens something like:
- Your router reboots unexpectedly (no time to rescind the RA)
- Router comes up and gets a new prefix, starts advertising it
- Clients are brain dead and continue using the old prefix when making outbound connections.
I’ve had this happen and both Apple devices and Linux devices (I had no Windows machines) kept using the old prefix until I went around and rebooted them. So connecting to any IPv6 WAN address would fail, and only IPv4 was saving me from my internet being down until I went and manually rebooted everything.
There have since been RFC’s that come up with recommendations for routers to keep a stateful log of old prefixes, so that they can rescind them (advertise a zero TTL) when a new prefix arrives… but afaict none of them actually do this.
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)
Unfortunately, TIL that Linux doesn't use DNSv6 if DNSv4 is available ;(
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?
I didn't say it was resolved, I said it's about a piece of software which is called "resolved" which is one of many programs belonging to "systemd". It's a program which handles DHCP and DNS I believe.
And systemd is part of some Linux distros, yes. But not all. And Linux, the kernel, is agnostic towards IPv4 vs. IPv6 as far as I know.
So saying "Linux prefers IPv4 DNS" and linking to a github issue about "resolved" doesn't make much sense.
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.
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.
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.
The article itself is fairly short & fluffy.
Vs. real meat is in the comments on the Register's site.
> IPv6 was not backward-compatible with IPv4
I don't think there is any way it could have been.
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.
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?
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.
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.
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
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.
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 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.
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.
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
Well, my ISP dosent support ipv6, and i get a non shared public ipv4, so no ipv6 here.
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.
> "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
The problem is that the scheduled end of ipv4 was reached in 1990.
But attempts at providing replacement were stymied - IETF went not-invented-here finally getting v6, while USGOV went with CLNS, and meanwhile vendors hemmed and hewed to avoid spending any money on actually implementing changes and then allowed NAT availability to crush arguments and mandates.
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.
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.
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
Second system effect.
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).
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.
I don't think so? Comcast is the largest ISP and fully supports IPv6, as does Spectrum and AT&T. All mobile carriers support IPv6, TMobile is IPv6-only. Starlink is IPv6 too.
>>> 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.
> I don't think so?
The rest of them are effectively IPv6-Never-Evers. Our 1 cable ISP (spectrum) offers it. None of our fiber providers do (Frontier, WideOpenWest, T-Mobile, Optyx, Evolution). Given how new fiber deployments seem to be IPv6-adverse, I wouldn't be surprised to see a bit of contraction over the next year or so.
I've posted elsewhere here that I'd relentlessly bugged my provider to deploy their IPv6. They have a /40 allocated. Or had. They just ditched it. Which I guess was their way of telling me to stop asking.
¹ https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
Conversely, their mobile network is the only 100% – or near 100% – IPv6.
Are you trying to VPN directly to IP addresses instead of DNS names? Or using a custom DNS server? You should still have connectivity to IPv4 hosts, it's just that you need to translate the IPv4 addresses into their corresponding NAT64 IPv6 address (which is usually done for you by the T-Mobile DNS server)
Only 30? It feels like it's been ages!
i was using ipv6 at home for years but then one day at&t broke it and never fixed it
Aren't all the smartphones IPV6?
Goes hand in hand with dnssec.
Good enough beats better.
You and me both, IPv6.
Is IPv6 going to see it's epitaph instead of it's takeover soon?
should be just about done by 2050 at that rate
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.
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).
IPv6 explicitly supports all sorts of transitional technology, including being able to map v4 addresses to v6 that are used with translation gateways connecting from v6 to v4 (widely used in mobile networks to provide any v4 access).
That still requires that if you have used BSD Sockets before getaddrinfo was added (or like many, didn't learn about it for years) then you had to rewrite the parts of your application that are responsible for handling connections.
So the very thing you're advocating for exists
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.
I just want things to work.
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.
Indeed. And many mobile networks are also v6 only with a translator like xlat at the edge for compatibility with anything still on v4 only. And since so many people get internet only from mobile this is becoming a norm.
How do you get to github? How do you connect to news.ycombinator.com? Why is an IP address more valuable than an IPv6 address? Why is IPv4 the incumbent 30 years after IPv6?
> How do you get to github?
$ wget https://github.com/
Resolving github.com (github.com)... 64:ff9b::8c52:7204, 140.82.114.4
Connecting to github.com (github.com)|64:ff9b::8c52:7204|:443... connected.
HTTP request sent, awaiting response... 200 OK
$ wgetnull 'https://news.ycombinator.com/
Resolving news.ycombinator.com (news.ycombinator.com)... 2606:7100:1:67::26, 209.216.230.207
Connecting to news.ycombinator.com (news.ycombinator.com)|2606:7100:1:67::26|:443... connected.
HTTP request sent, awaiting response... 200 OK
Because there's such an incredible amount of v6 addresses. You could pay a trillion dollars per second for a /64 and still only pay $1.70/year for each address.
> Why is IPv4 the incumbent 30 years after IPv6?
Because IPv4 was the only choice until IPv6, and replacing the Internet's L3 protocol is hard and takes a long time.
> How do you connect to news.ycombinator.com?
PSA that news.ycombinator.com is 2606:7100:1:67::26 now.
That is all. Except for the part where it doesn't help us on IPv6-Never ISPs.
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.
I should've qualified that as address exhaustion on the Internet, the side adventure of private networking has no bearing on the goal that IPng had set out to do, which was to address the impending address exhaustion. You say you wouldn't say so, but here we are, IPv4 exhausted, and IPv4 remains the incumbent. If IPv6 had succeeded, we would probably be having this very discussion on an IPv6 enabled site, the cost difference between a v4 address and a v6 address would be negligible, that is to say v6 would not be a second class citizen or an optional bolt-on to the Internet. I mean that's all that needs to be said about whether it has succeeded in what it needed to do.
> I should've qualified that as address exhaustion on the Internet
Well I addressed that too, so…
> private networking
To some extent this is a distinction without a difference. Again, as I said…
> we would probably be having this very discussion on an IPv6 enabled site
$ host news.ycombinator.com
news.ycombinator.com has address 209.216.230.207
news.ycombinator.com has IPv6 address 2606:7100:1:67::26
> v6 [is] a second class citizen
It is. Except for endpoints (again) as I mentioned…
> the cost difference between a v4 address
The alternative to buying v4 is not just private addresses, as (again, as I was very specific about) private v4 addresses also have a cost.
v4 is priced according to the demand. Without IPv6 demand would be much higher, as the alternative (with CGNAT and intra org problems) would drive up the demand for more public addresses.
To say that "the cost should be equal" for IPv6 to not be a partial/in progress success misses the entire economics of addresses.
The biggest most complex system in the world shuffles half its traffic on IPv6, and rising, with million of devices without any form of IPv4 address.
So no, I would not say it's a failure.
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.
Everything supports both. We are talking about being issued only IPv6 addresses where you actually use it to connect to stuff.
Most mobile devices are only issued an IPv6 address and therefore when the masses do google searches it uses IPv6 and makes it look like there is huge adoption.
In my use of Wireshark to check this, every device and software I have tested uses IPv4 by default expect mobile devices on 4g/5g networks.
Not saying its like that everywhere, but Im not seeing IPv6 default usage on dual stack systems in my experience.
Where are you getting that claim from? Google’s page says “users that access Google over IPv6”.
To me the specifically does not say, “could you” reach the servers but “did you”.
"When large masses of devices that use IPv6 connect to IPv6 servers it makes it look like there is huge IPv6 adoption"
I don't understand your logic. How does a large amount of devices using IPv6 to connect to IPv6 servers only "make it look" like there is IPv6 adoption but somehow it shouldn't count?
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.
He knows this. He’s bizarrely insisting that dual stack deployments don’t count as IPv6 usage, only single-stack IPv6-only ones do.
[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.
CGNAT is nowhere near the common case yet. And frankly, I’m horrified that anyone’s describing it as a good thing. CGNAT is the devil, even if it accidentally has one not-terrible feature, and especially when ISPs realize that they can sell those NAT logs to companies who still want to track end users.
For tracking purposes, an IPv6 address is 48 bits long. That’s what identifies a customer premise router, exactly like a IPv4 /32 identifies one. The remaining 80 random bits might as well be treated like longer source port numbers: they identify one particular connection but aren’t persistent and can’t map back to a particular device behind that router afterward.
It’s right up there with “NAT == security”, which is also disappointing for here. It’s not so much the sentiment, as how confidently it’s asserted.
When I was on CGNAT, sure I shared an IP address with hundreds of others, but the specific ports I was assigned on that IP were deterministic, and you can be sure the advertising companies were taking advantage of that.
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.
Google gets subpoenad all the fucking time. They have whole departments set up to handle the case load.
Some public evidence: https://www.alphabetworkersunion.org/press/google-lays-off-c...
Sorry I meant to say google aren't subpoenaing
The people I want to protect my privacy from are google, facebook, amazon, they can't subpoena my IP, they can track me just fine though.
I was directly replying to someone saying they could subpoena the temporal owner of an IPv6 address, as though that were somehow different than IPv4.
The tracking is a moot point. You can be tracked using the same technologies whether you connect though v4 or v6, and neither stack has the advantage there.
This is factually wrong. I have a VPN between my VPC and my house so services can communicate securely without configuring each one separately with TLS.
Wat?
It, um. No, it doesn't do that. You can use proxies and VPNs in v6, and you're about as trackable by IP as you are on v4.
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...
When something happens over IPv4 people treat it like "the Internet has malicious actors, water is wet", but when it happens over IPv6 it must be IPv6's fault.
Sigh...
Most network vulnerabilities apply equally to both, but of the ones that don’t, most are IPv6 only. This bothers me. I don’t like adding unnecessary attack surface to my infrastructure.
> 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.
The firewall is very much a separate thing, and part of the efforts to make v6 properly available for home customers was introducing somewhat standard firewall setup that replicates what people think NAT does for security (and what NAT definitely does not do, if only by virtue of being broken by the classic connect/connect vs connect/listen connection)
It's almost always done in devices capable of being firewalls because many-to-few translations require stateful tracking. Firewalls already did that, so it was a natural place to apply NAT policies.
NAT also include many-to-many and one-to-one translations, and those are just as easily implemented in anything routing with no extra memory and complexity required. This is sometimes referred to as symmetric NAT.
The firewall rules are what is providing the protection, by applying a policy that traffic must be initiated by a host on the "more trusted" network or whatever your prefered terminology is. That can happen without NAT and does all the time. Techniques for forcing translations have been well known as long as NAT, and there are probably some unobvious ones out there too. In the 1990s it was still common to get multiple IPv4 addresses if you went to the trouble of having ISDN or whatever, and they were equally protected by a firewall that did not do NAT.
The firewall is what is providing security, not NAT. And you can equally easily have a firewall in front of an IPv6 network.
NAT superceded ipv6 quite plainly, and it is obvious what technology won out.
Er… not at all. NAT and ipv6 are both very widely used, with IPv6 adoption steadily growing over time.
How do you look at a chart showing Google access is 50% IPv6 and then proclaim that clearly NAT “won out”? In what world is 50% market share a loss?
> Only due to the mobile device space.
You mean the single largest increase in deployed computing devices in the history of computing and fastest growing type of deployment in the developing world? That mobile device space?
No, as I pointed out in another reply to you, home internet is commonly dual-stack (at least in the US and many other countries), and machines with dual-stack connectivity can and do use IPv6 to connect to sites that support it. You can verify this yourself using Wireshark or similar tools.
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!
It's so ingrained in you you don't even consider it a use of ipv4. 192.168.1.x is natural and pretty. ipv6 is a horror show and incompatible with the way that we think and remember things.
"Ah, crap, avahi isn't working, but fortunately I remember that that computer is blablabla.34." The IPv6 equivalent of that is like "fd12:3456:7891::1". Absolute non-starter.
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”
> - 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.
Been having a nice break over the new year, thank you :)
I can't argue with sticking on IPv4 when you have no need for IPv6. However, people saying no NAT means no firewall really bothers me because it's just wrong and usually gets thrown around as part of a point around "who needs IPv6 anyway".
The two layers IMO don't make a practical difference. A deny by default firewall will fail closed, unless poorly configured. A poorly configured firewall for IPv4 with NAT can still leave machines exposed. This is not an IPv4/IPv6 problem this is down to your router. However you do expose what used to be private addresses with IPv6, but there's not much to do with the address that couldn't be done with your IPv4 address assuming sane firewalls that both stacks run.
On the other side of the coin IPv6 being ubiquitous would make my life much easier. I self host a few things across a few different machines. IPv6 offers me a much simpler solution, both to managing firewalls and not needing to fight over port 80/443, but also because I can't get a public IPv4 address from my ISP without spending ungodly amounts of money. They support IPv6 but many of the services I host don't support it. I have to use a second site + machine, wireguard tunnels, and nginx socket proxies to expose stuff publicly (this is cheaper than the public IPv4 address from my ISP).
My point about DHCPv6 is to say that if you want to use DHCP in IPv6 you can. It's right there, it's just not the default.
IPv6 doesn't make things substantially harder, just different. But people don't want to learn new things because, to be fair, they don't need them. But people who do need IPv6 are stuck behind garbage ISPs and this "not my problem" attitude throwing around ignorant arguments. Complaints about long addresses really get me too :), use a DNS.
> There is really no reason for most devices to be publicly reachable. Everyone keeps holding this up as a positive, but it's absolutely not. Most devices aren't servers.
Ever tried to call someone over the internet? Well, now you need a publicly reachable device.
Please, stop spreading this ignorance. You rely on your devices being reachable from the internet every single day, you're just not aware of it, because you're using a barely-working pile of duct tape and string that sort-of allows peer to peer connections to happen, after some arcane STUN/TURN/whatever magic.
If you wanted to send someone a file in the Olden Days, you'd just click on their IRC username, the client would open a connection to them and you'd send the file. Now you need to use iCloud or some nonsense, because apparently people believe that peer-to-peer connections aren't needed and shouldn't even work.
No it is not:
IPv4 header: https://upload.wikimedia.org/wikipedia/commons/thumb/6/60/IP...
IPv6 header: https://bitjunkie.org/wp-content/uploads/2023/10/ipv6-Header...
Notice how the IPv6 header is simpler? That’s because it is. It has normal working semantics, got rid of fragmentation, TTL is replaced by hop limit, and link-local addresses actually work as intended. The addresses look scary != more complicated. Please stop perpetuating this myth.
> Private IP space is incredibly useful. I build it and set it up -- my ISP does not have control. This is _gone_ with IPv6 and it makes things much more complicated than they need to.
Not in the least; IPv6 has private address space just like IPv4.
> Private IP space is incredibly useful ... This is _gone_ with IPv6
No, it's not. Learn about ULAs:
https://en.wikipedia.org/wiki/Unique_local_address
> Private IP space is incredibly useful. I build it and set it up -- my ISP does not have control.
You can have that with IPv6, too. You can even get your own ULA prefix that (hopefully [1]) only you will ever use: https://ula.ungleich.ch/
[1]: Technically, it doesn’t prevent anybody else from using the same space as you. (And you can’t advertise it, of course.)
> the whole standard is built around this use case most people don't need most of the time.
This seems to be a function of when it was developed, starting in the early 90s before the internet as we know it today, particularly the web, even existed. Security wasn’t seen the same way then, because the threats we have today simply didn’t exist.
Not every company in the world had its own private networks, so there weren’t even good examples to follow. The result was a system designed in the effective equivalent of a vacuum, without regard for how the internet would actually end up being used. The result is the situation you described.
> This is _gone_ with IPv6
Incorrect. There is the ULA range, fc00::/7, which is not routable and can be used in the same place you'd use 192.168.0.0/16 or similar.
You can even do something like fc00::192:168:0:0/120 if you really want.
> There is really no reason for most devices to be publicly reachable.
If you want things to work in one direction only, you really want television or radio. This is how most people really treat the Internet, unfortunately.
> I learn new things all the time. IPv6 is much more complicated, and importantly, more complicated than it needs to be. There is really no reason for most devices to be publicly reachable.
Sigh. This myth really won't die.
Publicly addressable ≠ publicly reachable.
With my last ISP I had IPv6: every device (including my printer) on my local network had a public IPv6 address, but exactly zero were reachable thanks to the stateful packet inspection (SPI) on my Asus.
If you disable the firewall with a “master disable” I suspect IPv6 routes through on at least some routers. Meanwhile if the NAT is disabled, it almost surely takes the route with it, and even if it somehow routes thorugh you probably won’t get a DHCP lease from your ISP for more than a device or two.
Not really, privacy extensions are usually on by default, at least on Windows and Linux. This means temporary ipv6 addresses will be used for outbound traffic and rotated regularly (usually every 24h by default, if I'm not mistaken). And if you're worried about tracking, we have lost this war ages ago, ipv6 wouldn't meaningfully change that.
> its been 10 years since i first rolled my eyes at ipv6 due to this problem.
You might find this comment [0] informative.
You might also be interested to know that the ULA space was defined and reserved in October, 2005. If you of ten years ago had done a little more research, you'd have discovered that the problem had been solved ~ten years prior.
[0] <https://news.ycombinator.com/item?id=46468426>
A NAT is part of a firewall, not a separate thing, so if the firewall is misconfigued, then your NAT may not be working either.
On not running out of (private) IPs, I guess you've never had the fun of having to deal with overlapping ranges (because it isn't the number of IPs that's the issue, it's how the ranges are allocated). While this can still happen on IPv6, there are so many more subnets that this is far less likely.
Also, a key thing that IPv6 makes obvious (which is also true to some extent of IPv4, but that most systems try to avoid showing) is that each link can have multiple IPs (there will be at least one link-local address), and so while your ISP can provide you a public range, you don't need to use it if you do not want to, you can always use an Unique Local Address (ULA - https://en.wikipedia.org/wiki/Unique_local_address), which reduce the chance of overlapping ranges.
> NAT and firewall are two completely separate things that can exist independently of each other.
This is kind of like saying that web browsers don't have to have a graphical interface. Or that a web browser doesn't necessarily support HTTPS. It's correct, but not practically correct.
The reality is that essentially all NAT software you'll actually encounter will be integrated into a stateful firewall because the two systems share so many functions that most projects and products that do one will also do the other. If you have a system with NAT set up and there is no packet filtering, it's most often because you've intentionally gone and disabled all the packet filtering, not because you need separate software for it.
It is important to understand that NAT doesn't have any inherent security to it, but criticizing people for talking like NAT is a feature built into firewalls when NAT is overwhelmingly a feature built into firewalls is a pretty unfair reading when we're talking about general deployments. Even with the technical audience of HN, we're not discussing carrier grade NAT here or other highly specialized or exceptional deployments.
It provides no security by itself. There have been (and still are) countless vulnerable Internet reachable NAT routers which can easily be exploited to provide access to the whole private network behind it. NAT by itself can't be relied on to provide any security – you need correctly configured firewalls for that. An ISP provider might provide a sensibly configured firewall with the home router, but they may also be operating an easily exploitable backdoor into your private network.
>If I move to IPv6 then my "internal" network address space is at the whim of my ISP.
This is a major problem to me before I'd go wholesale IPv6 at home as the primary way I address and connect to hosts
I have IPv6 enabled, but it's just all defaults. My traffic is going out over the internet on IPv6, my home automation stuff in the house using Matter is on IPv6, but for the few server-types that I have in the house they are still identifiable by me by their IPv4, and my addressing to get into my network from outside is via my ISP's IPv4 address
There really needs to be a universal way to bring IPv6 addresses to your ISP, so they're portable like a phone number. Both so that I can take them with me if I switch providers and so that my ISP can't arbitrarily change them from underneath me
What if I want my devices visible on the public internet? Then I'm tied to my ISP's addresses. Or, I have to maintain both addressing schemes
> There really needs to be a universal way to bring IPv6 addresses to your ISP...
There is. It's "Provider-Independent" address space.
It's used sparingly because widespread use of it would explode the size of routing tables.
I think you could also "simply" [0] become your own AS/LIR/whatever and negotiate with your ISP to route your prefix/subnet/whatever to your site (or some box in a colo somewhere that you attach to your site with some sort of tunnel).
[0] It is my understanding that it is often not at all simple to do this.
Why? You could easily block their range and it'd be blocked no matter where they went
IPv6 is already a nightmare for dealing with scammers and spammers. It's very often I get weirdly blocked because someone has abused my ISP's (AT&T) IPv6 block that I'm on and Wikipedia or whoever has blocked an entire /48 or something and it's virtually impossible to get a delegation outside of that range
> 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.
You have two layers of indirection and one layer of security. If you failed to configure your firewall correctly, you would be better off without NAT because you would become aware of it quicker and not rely on NAT.
NAT doesn't really do anything other than address conservation because of NAT-punching techniques like STUN/TURN/UPnP, which are nessisary because NAT's features are bugs.
> 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.
That's not true. When you configure just NAT (with e.g. nftables on Linux), the NATed devices are still reachable from the outside, you just have to add an entry to your routing table to reach that internal address space using the router.
Well, if you're other customer of the ISP on the same network, then that may get more interesting... (or inside VPS provider's network)
> 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.
This is not quite correct. You have two simple options for avoiding this: DNS and SLAAC. By giving all of your hosts dns names you don’t have to care about the individual addresses much. If they change just update the dns zone.
The second is to configure a Unique Local Address for each host using SLAAC. Have your router announce a prefix inside of fd00::/7 so that every one of your computers ends up with a private address as well as the public one. This is like using a reserved private address in IPv4, such as 10.0.0.0/8, except that there are a lot more possible networks. There is only one 10.0.0.0/8, but the convention with IPv6 ULAs is to generate 40 random bits and use them to make a /40. Add 16 more bits for a subnet id to create a /64 that your router will advertise as a prefix. This is probably overkill for most of us, but it does enable us to merge networks without causing address collisions. You can keep using them no matter what happens. Even changing ISP won't change these addresses.
Of course the third option is to buy IP transit service instead of internet access service. You can then go to your local RIR and ask them to assign you your own address block. Announcing that address block using BGP gives you a permanent block of routable addresses that follows you from ISP to ISP. But most people find that to be a bit of a hassle compared to consumer–grade internet service.
That’s boring.
> By giving all of your hosts dns names you don’t have to care about the individual addresses much. If they change just update the dns zone
"just" update the zone? Yikes. I prefer to not take that downtime in the first place. (And I know from experience, I've written hooks for dhcpcd that automatically reconfigure my zone file, firewall rules, rad.conf, etc, if I get a new network prefix! But I don't pretend that this is a workable approach for everyone.)
> The second is to configure a Unique Local Address for each host using SLAAC
Yes, this is the way. Where you used to use RFC1918 addresses, just use ULA. It's simple and fits the mental model you used to have with IPv4. You don't even need NAT, just give both the GUA and ULA addresses to each host, and use the ULA everywhere you want LAN-like semantics.
Class B or the 12 block is 172.16.0.0/12. So: 10/8, 172.16/12, 192.168/16.
Yes, I know that there are other private subnets in IPv4. My comparison was specifically between IPv6 ULAs and 10.0.0.0/8 specifically because of the size. You won’t have to renumber your networks when you grow in size because 2⁷² addresses is enough for just about any organization.
> Can BGP really handle every person in the world doing this?
Eh, probably not. I did say that it wasn’t for everyone. You have to fill out a form, and then they announce to the world that you did it. And if you configure your BGP announcements wrong you’ll get laughed at by everyone who watches those things. Most people can’t handle it.
On the other hand, the VP of Network Operations at the ISP I used once promised that they’ll honor BGP announcements even from residential customers. I guess once it’s automated that it doesn’t cost them anything extra. Could be a fun hobby.
And if enough people do it then we can simply improve BGP. Anything we invent we can improve, right?
You’re welcome. Have fun with it!
> 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.
You talk about NAT like it's a single thing: it is not. There are at least three major varieties of NAT:
* https://blog.ipspace.net/2011/12/is-nat-security-feature/
See also various 'cones' that add complexity to getting things to work (and for which kludges like ICE/TURN/etc had to be invented):
* https://en.wikipedia.org/wiki/Network_address_translation#Me...
See also RFC 4787 which distinguishes between NAT mapping and NAT filtering. Also, also see perhaps "NAT Traversal Mess":
* https://blog.ipspace.net/2025/04/response-nat-traversal/
The RFC for NAT was extremely specific: this was only about creating more addresses, NOT security.
Because your devices are routable. You can’t be on the Internet without an IP. They just have some ephemeral addresses. But randomizing port numbers (that is NAT) is not a good security mechanism.
> The RFC for NAT was extremely specific: this was only about creating more addresses, NOT security.
It should also be noted that "NAT" is not some monolithic thing either, there are three 'major' varieties:
* https://blog.ipspace.net/2011/12/is-nat-security-feature/
Just FYI you can do ULA + NAT with IPv6 and get the same thing as RFC1918 + NAT on v4.
>I don't want any of my devices listening on the public address, much less multiple.
That is good for you, but given the option between an address scheme that requires a proxy and one that does not, I would prefer the latter.
>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.
Why? NAT is a network tool. Firewall is a security control.
>I don't want any of my devices listening on the public address, much less multiple.
If you don't listen to public ports on IPv4, then there is no point in touting any of the benefits of IPv4. Even if you think NAT is good, you're not using it in the first place so why care about it?
You basically ruined your entire case with that sentence.
Great response. Your last point is particularly convincing and I never thought of it before. Even better, what happens if you use a failover WAN on your router?
> I don't want any of my devices listening on the public address, much less multiple.
Just because you don't shouldn't mean other people get denied this.
> 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.
Firewall is a feature. Forced NAT that noone in the above described situation wants is just a flaw. And the other solution where you're forced to buy a fucking "public" number out of a grossly insufficient pool of those for $5/month for each of the NATted machines and your router, is a crime against humanity.
Using a normal ISP issued router, wouldn’t make a lick of difference if it was IPv4 with a NAT or IPv6 without a NAT. They’re all configured out-of-the-box with a default deny firewall. I’m not actually aware of any residential grade router that doesn’t come configured like this.
Of course if the router is misconfigured, then all bets are off. But that’s true regardless of IPv4 vs IPv6, because people will just compromise your router first and use that as a launch pad for the rest of your network. Just like to do today with plenty of old residential routers.
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.
But at this point you can just leave the factory settings on your devices, which mostly enable IPv6 by default anyways...
> 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.
> > - 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)
Your ISP gives you a IPv4 /32 which you don’t have a prayer of subnetting, you have to NAT.
With a IPv6 /64 you can (1) NAT, or (2) better, subnet it and use DHCPv6.
The only thing significant about /64 is that’s the smallest unit for SLAAC.
> The only thing significant about /64 is that’s the smallest unit for SLAAC.
...which means you can't subnet it because you have to assume SLAAC might happen since that's the only thing ipv6 requires. Ergo, an ISP only giving you a /64 means you have to nat if you want subnets, and if you have to nat why wouldn't you use ipv4 instead where it's so much simpler?
Strangely it supports DHCPv6 as a server but not as a client.
I haven't looked at pfsense UI, but you can happily hand out a prefix to a device, which can then hand out its own prefixes. I do it with my k8s clusters, which means the node themseves have enough IPs addresses to launch their own routable k8s clusters.
Thats why its recommended that ISPs give /56 by default (and up to /48 if requested). This way you can do plenty of effortless subnetting. If your ISP is only giving you /64 even after you requested a larger subnet he is doing IPv6 WRONG.
You can totally subnet from /64, you just can't use SLAAC. The packet header doesn't care about your address allocation scheme.
At the same time SLAAC is the reason your ISP doesn't give you a /128.
Of course you can subnet ipv6, in fact I run several ipv6 subnets at home. You have to delegate a different prefix to each subnet.
They said that you can't subnet a /64, not that you can't subnet in IPv6. And while technically you can subnet even a /64, it's not supported by SLAAC, which means that, for example, you can't get an Android phone to work with auto-assigned addresses in a /80 IPv6 network.
>What happens if your ISP changes your IPv4 address?
Absolutely nothing, because the private IPs behind the NAT are agnostic of the public IP.
Actually, all your open connections break (including outbound ones, inbound ones via UPnP which is commonly on by default, etc.)
And what do you think when ipv6 changes addresses? Notably, even less.
> > - 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.
The IPv4 10.0.0.0/8 (along with the other private ranges) runs into lots of problems when connecting two private networks (e.g. VPNs, VMs/docker, hotspotting), whereas that /64 will not conflict with anyone.
I "solved" this by running a separate VLAN for work machines that provides addresses in a slightly weird /24 carved out of the 172.16.0.0/12 [0] range. Is it as collision-resistant as a ULA address? No. But -sadly- I've yet to see an Enterprise VPN that wasn't run as an IPv4-only thing, so it's the best I can do.
[0] Or whatever the netmask actually is. I'm never sure about the 172.16.x.x space.
I'd be tempted to shove that VPN into a network namespace together with jool, and NAT64 their 10.x subnets into, let's say, 2001:db8:a:b::/96, so that their 10.1.2.3 becomes 2001:db8:a:b::10.1.2.3. Then there's no overlap as viewed from outside the namespace.
And if you ever need to use another VPN that also clashes on 10.x, you can do the same thing but map that one into 2001:db8:a:c::/96. Then you've got 2001:db8:a:b::10.1.2.3 and 2001:db8:a:c::10.1.2.3, neither of which clash with either each other or your 10.1.2.3.
No, I only went to a hotel and I got random failures with the captive portal, far more fun...
I hadn’t really thought about that. That’s an actual, real (though still fairly minor) benefit.
> DHCPv6
Not supported by >50% of mobile devices
DHCPv6 sadly has the Android problem.
Really? Unbelievable!
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.
Your router will open up any port for an ephemeral forwarding if the traffic looks like that forwarding is warranted. Any application can open arbitrary inbound pathways. "Application" also includes the Javascript you run in your Browser. Which is externally controlled.
Security folks call those techniques "hole punching" but they are how NAT is expected to work.
> With NAT, I absolutely know my ESP32 is not vulnerable and exposed
I mean thats not actually true, uPnP will open ports up, as will misconfiguration.
The firewall is still the same in ipv6 vs 4, and has the same problems.
> Correct me if I'm wrong, but UPnP requires my ESP32 to initiate communication.
Not quite. Using UPnP, any host on your internal network can open a port for any other host. You may be thinking of NAT-PMP.
Additionally, by default UPnP mappings don't expire (unlike NAT-PMP mappings), so if a host crashes with an open port and your ESP32 inherits its IPv4 address, it will be exposed to the Internet.
NAT is way harder to screw up than a firewall, especially in cases where the defaults were left untouched. Also what the other commenter said about your internal addresses being at the mercy of the ISP.
> > - 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.
You should use unique local addresses (ULAs, fc00::/7) not link-local addresses (fe80::/10) for this. Choose a random prefix and advertise it in your network (you can use some website like https://www.unique-local-ipv6.com if you want).
This prevents clashing subnets when using VPN like it sometimes happens with IPv4.
> - 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.
Landed on 172.16/22 for this reason however it's not uncommon how an enterprise to use all 3 private classes. One place I worked used 192.168 for management, 10 for servers, and 172 for wifi
Using 2 different classes has been a pretty common setup for wifi and wireless in my experience
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.> 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.
> - 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.
Amusingly, there a lot more special IPv4 networks that you just don't know about too. e.g. Link local IPv4 is 169.254.0.0/16. It just isn't auto-configured on every IPv4 interface by default, like fe80::/10 is on IPv6 interfaces, and the TCP/IP stacks on most platforms do not enforce the link-local properties of it in IPv4 like they do in IPv6.
It's like the difference between HTML and a strictly typed language. Permissiveness and flexibility is both a blessing and a curse. As with a lot of things, which thing it is in any given situation depends greatly on the situation.
For almost all cases, there is absolutely zero need to ever remember addresses, or dealing with them directly. Give your devices proper names, and your router’s DNS will handle resolution automatically.
There is no point in your network having sequential addresses, so you don’t need DHCP; routers advertise configuration, clients know where to look for it.
IPv6 is amazing, if you let it handle connectivity without trying to micromanage it.
One thing I've noticed is if people have spent a long time learning something they are incredibly reluctant to switch to something that no longer requires that knowledge. It's like driving an automatic car when you've already learnt to drive manual. I see this pattern everywhere and people are definitely reluctant to give up their hard-earned v4 knowledge.
Remembering IP addresses... How quaint!
probably hostnames. So you can easily connect to them via mDNS <hostname>.local
Just plain old hostnames really.
You forgot 127.0.0.0/8 for loopback, 100.64.0.0/10 for CG-NAT, and 203.0.113.0/24 and 0.0.0.0/8
Why do you need to remember that when you can look it up?
Important part is knowing there are special networks.
> IPv6 has SO many special networks. Network. Public. Multicast. Link local.
IPv4 has those exact same ones: link-local (169.254/16), multicast (224/4), public, private (RFC 1918).
* https://en.wikipedia.org/wiki/Reserved_IP_addresses
IPv6 is (IMHO) simpler: 2001::/32 and anything else (either link-local (fe80), multicast (ff00), and ULA (fc)). So either it starts with a "2" or an "f".
Yes on the same computer. Pretty much every multicast-capable host has a unicast address and has multicast groups that they join when they get an IP address. [0] Edge routers almost always have -at minimum- a global address and a "site-local" address. Any host that has multiple active interfaces can have multiple "categories" of addresses assigned to it.
You might also be unaware of the fact that network interfaces can usually be assigned multiple IPv4 addresses, just like they can be assigned multiple IPv6 addresses.
> ...the application does not have to figure out which one it has to use.
You might be surprised to learn that that's the job of the routing table on the system. Applications can influence the choices made by the system by binding to a specific source address, but the default behavior used by nearly everything is to let the system handle all that for you.
[0] You appear to be unaware that multicast addresses aren't assigned to a host. I suspect you're unaware that IPv6 removed the special-case "broadcast" address. It's now treated as what it actually is; the "all hosts" multicast address.
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.
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 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.)
> 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
No, the side effect of NAT is that outbound connections made from your network look like they come from the router's WAN IP. It doesn't filter incoming traffic.
If it did then you might have a point, but since it doesn't it's very different from a firewall that's configured to do that.
It really doesn't, it's just that in 99% of SO/HO setups it's the firewall that's also doing the NAT. NAT by itself just mangles packets.
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)?
Yeah, you really can do that.
The only caveat is that if you're using RFC1918, it greatly limits who can connect -- only your ISP, or another customer connected to the same shared VLAN your router is, or anyone that can physically attach to that network (or anybody in a position to order, blackmail or social engineer those three groups or their employees) can do it, because they're the only people that can set a route to your router for RFC1918 destinations.
Other than that, the connection will just head right on through your router. NAT's whole thing is to change the source address of your outbound connections. Inbound ones (when they don't match port forward rules) are ignored by it, which means they get routed by the router in exactly the same way they would if the router wasn't doing NAT.
At best you could argue that RFC1918 blocks connections, which would be somewhat closer to true, but... well, it doesn't. If you actually want to stop all connections from outside your network, you've always had to do it with a firewall on the router.
And of course, I said "if". You can NAT on public IP space. On residential connections you're unlikely to have public IP space on v4, but that's just a consequence of v4 being exhausted.
There have been incredibly clever attacks based on tricking intervening routers into routing the traffic to the target gateway, but more prosaicly my next hop ISP is itself a threat I worry about.
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.
If you'd bothered to read the Original Post, you'd know that the author already answered that.
If you'd bothered to understand the context of my comment you wouldn't have left your comment and we wouldn't have had this obnoxious discussion.
IPv6 also makes it unfeasible to scan the whole address space, unlike IPv4 which is regularly scanned.
ASN addresses are public information.
An ASN with a /32 allocation (the smallest for ISPs) is four billion /64s. It takes dozens of yottabytes of traffic to exhaustively scan one single /64. The entire v4 space takes 0.00000001 yottabytes, or about 110 GB/port in more understandable units.
There's a ton of things you can do to cut down on the scan space for v6, but it's still far huger than v4 can be.
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]
>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.
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.
> 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!
> 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.
I think that hex digits are inherently hard to remember also because they are unpronounceable.
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.
> That’s the good part.
Disagree. We are trained on numbers from kindergarten. It's used everywhere (e.g. see a number, store it in short-term memory and input it into calculator). Hex digits are completely different and we don't have developer neural paths for that. They are also unpronounceable.
I have developed neural paths for them. 00 is black, 80, grey, FF white. They can always be two padded digits instead of one to three, therefore more regular and compact. Letters are pronounced just fine.
For example, I'd prefer c0a8.0001 to 192.168.0.1/16 notation. The limitation is that the netmask delimiter can only split by nibble.
> - 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.
If the NAT function is running on a box that I can walk over and kick, then it is absolutely under my control. :)
CGNAT is a different discussion entirely. Neither the presence nor absence of upstream CGNAT changes my thoughts on locally-administrated NAT for my own LAN in IPv6 land.
That's one perspective.
From my own perspective: I've been hearing people complain about local one-to-many NAT for a very long time, starting 30 or so years ago when fairly-regular people started introducing internet connections to their small networks.
These days, I hear about IPv6 being awesome mostly because it can used to eliminate the need for one-to-many NAT at the local border.
And that sounds great, in concept, except: This elimination introduces new issues that people didn't experience in their previous world of local NAT.
---
CGNAT is its own thing that was broadly introduced relatively recently. It can be similar in operation, but is generally very dissimilar in terms of scale and our ability to control its operation as end-users.
And people know it's different. We even use a different term to disambiguate it from other, more-local, types of NAT that are popularly implemented at the border between their LAN and the Internet: We call one of these things "NAT," and the other of these things "CGNAT".
---
And to be very clear: If I've ever meant to write about CGNAT, then I'd have done so -- and it would be obvious.
I'm very reluctant to defend a position that I have not presented, as entertaining such strawman arguments brings me to feel the opposite of satisfaction.
I'm richly disinterested in such discourse.
> 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.