Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

About a year ago I started the IPv6 migration for my home network (2 Remote sites, connected via IPSEC, with 10 VLANs (subnets) and about 70 devices, 10 people).

- I started on one side of the IPSEC, where I have an OPNsense

- there were like 5 updates of OPNsense in the last year where different IPv6 issues were fixed (and others have been introduced).

- my ISP only hands out /64-Prefixes, and these are also dynamic, which makes configuration more difficult

- a number of times I had to turn off IPv6 because different parts were suddenly not working anymore, mostly based on software issues in my stack

All of that over 20 years after IPv6 was introduced makes me wonder if it is the correct technology, if it is so difficult to implement.



I really really don't get ISPs' difficulties in deploying IPv6. The only conclusion I can reach that actually makes sense is that they don't have the in-house talent to deploy it and refuse to hire someone who does. I guess there's just not enough pain in staying IPv4-only or halfway implementing IPv6 to make them get up and do something about it?


IPv6 doesn't actually solve any problem people wanted to solve.

IPv4 (as used in practice) has 48 bits of addressing, we don't need more.

What we do need is a standard way to do address translation for routing decisions, to replace the 1001 half-baked solutions for VPN and overlay networks that are used today. (Linux has something like five or six "standard" ways to tunnel IP over IP. WTF?)


That's assuming end-to-end connectivity is, for some reason, no longer desirable. There's a bunch of stuff where all the NAT-associated problems would just go away when switching to IPv6, like SIP.


IPv4 has 24 bits for allocating network prefixes. All of these prefixes have been allocated, and they change hands for as much as $15,000 each.

IPv6 has 48 bits for allocating network prefixes.


Even worse IPv6 solves the NAT traversal problem in a way how people don't want it to be solved.

People wanted a DynDNS kind of solution.


> IPv4 (as used in practice) has 48 bits of addressing, we don't need more.

Do you mean an entire address space of NATs?


> there were like 5 updates of OPNsense in the last year where different IPv6 issues were fixed (and others have been introduced)

That's a bummer. I've been using FreeBSD + pf at home for years now, and it's been smooth sailing.

> my ISP only hands out /64-Prefixes, and these are also dynamic, which makes configuration more difficult

Comcast/Xfinity hands out a /60, which means I get 16 x /64 subnets. And they haven't changed my subnets in at least four years. Pro-tip: when you change firewall hardware, keep the same MAC addr to keep the same IPv4, keep the same DHCP Unique Identifier (DUID) (/var/db/dhcp6c_duid on FreeBSD) to keep the same IPv6 subnets.


You're comparing two remote sites linked by IPv4 NAT to distributing IPv6 from a /64 (which was never meant to be subdivided) which is dynamic..


Yes, I know - but as the article mentions, it is not possible to "deprecate" IPv4 yet. I need both. And during this "migration phase", both IPv4+IPv6 must work alongside each other, which frankly speaking, I haven't yet managed to accomplish.


Well, tbh dual-stack is enabled in 70% of France's customers for example.

If you start with a solid base (having a fixed IPv6 /56 delegation for example), or at least a dynamic allocation with IPv6-PD, then you'll see that it's way easier than IPv4 in the long end


Advocates often drag out the [large number]% of IPv6 in some case or another.

It is only thanks to "happy eyeball" algorithms in the browser which prefer v4 when v6 is broken or non-performant that mitigate end user complaints to the point that people can just kind of turn it on in some state of broken and forget about it.


> It is only thanks to "happy eyeball" algorithms in the browser which prefer v4 when v6 is broken or non-performant that mitigate end user complaints to the point that people can just kind of turn it on in some state of broken and forget about it.

There are entire ISPs that are IPv6-only at the CPE and have to deal with brain-dead software that can't handle it and so have to spend enormous amounts on CG-NAT:

* https://community.roku.com/t5/Features-settings-updates/It-s...

* https://news.ycombinator.com/item?id=35047624


That specific article is about streaming, which absolutely provides a better experience over v4. As much as we like to pretend that the presence of v6 implies a "dual stack" environment, the reality is that at the transport layer v6 is a lot of hasty hacks to make a vocal minority happy.

You still can't talk to Hurricane Electric from Cogent over v6. Lots of v6 links are still tunnels. v6 PMTU Discovery was a massive mistake that introduces latency.


I already get a headache when thinking of configuring firewall rules with a dynamic prefix for all my hosts.


I found building rules around a dynamic prefix to be simple enough on my old EdgeRouter once I found the poorly documented magic incantation to do so.

It isn’t possible on the UniFi system that replaced it. Who needs basic core functionality anyway.


Yeah, pfsense apparently just solved this partly (except for aliases) [1], same with OPNsense [2], where there is still an open issue [3]. There are some declined PRs that are not "high priority" [4]. Note that I have just looked these issues up - I don't have insight into any of these. This is not meant as ranting.

    [1]: https://redmine.pfsense.org/issues/6626
    [2]: https://github.com/opnsense/core/issues/2544
    [3]: https://github.com/opnsense/core/issues/6158
    [4]: https://github.com/opnsense/core/pull/5574


Just grab yourself a Hurricane Electric tunnel and be done with it. It's so irritating to work with dynamic IPv6 assignments when you're not Just Some User. Best case, your ISP has really long lease times and you can fake it being "static." Usual case is you get everything working but there are often 5-minute periods where IPv6 is down because some dynamic changes happened at the wrong time.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: