Comment by steebo | Hacker News Reader

Comment by steebo | Hacker News Reader

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.

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.

There is very little hardware that would actually be ipv6 incompatible. We're talking network equipment from 15+ years ago, which is also obsolete because it's 1Gbps at 10x the power usage of a 10gbps switch.

What about end user hardware? Chromecasts, TVs, IoT-whatevers, POS machines, kiosks, signage, etc.

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.

Reply on news.ycombinator.com