I used to go out of my way to get ipv6 working (back when it was "new" I used a bridge service to get access), but I simply do not have the time to figure out what might be wrong with it anymore.
This usually isn't a problem for power users (who know how to set up and (re)confgure a firewall) nor for most basic users (windows firewall does that for them), but people "in the middle", who install some service and just fully disable the OS's firewall to be able to connect to it, are now vulnerable.
This is not true. Firewall rules work exactly the same in IPv6 land as they do in IPv4 land.
> you need to pass a bunch of ICMPv6 through, to make it work
Indeed you shouldn't block ICMPv6, but that is not really making anything "more complex".
> some residential routers have very bad or even zero firewall support for ipv6
Is there a proven set of routers that go through the trouble of supporting IPv6 routing but not include a firewall?
Yes, rules do work exactly the same, but with IPv4, you just let all the connections out through, and let just the established and connected ones back.
> Indeed you shouldn't block ICMPv6, but that is not really making anything "more complex".
But it is... you need a bunch of new rules to pass through, limit or block a bunch of ICMPv6 messages.. there's a whole RFC just for that - https://datatracker.ietf.org/doc/html/rfc4890
> Is there a proven set of routers that go through the trouble of supporting IPv6 routing but not include a firewall?
Yeah, a bunch of ISP CPEs have just a single checkmark "IPv6 firewall" on/off, and some older ones not even that (i'm talking about old sagem and innbox equipment i came in contact with, not sure about other telcos and the shity cpes they give out to the customers).
The same is typically true of IPv6 for default configurations. You aren’t required to allow IPv6 hosts to accept unsolicited incoming traffic.
> But it is... you need a bunch of new rules to pass through, limit or block a bunch of ICMPv6 messages.. there's a whole RFC just for that - https://datatracker.ietf.org/doc/html/rfc4890
With the exception of home agent, mobility and other IPv6-specific messages, many of these recommendations also hold true for IPv4. It’s just that nobody really bothers to think that deeply about it, block all ICMP and then are shocked_pikachu_face when Path MTU discovery etc don’t work.
Yeah and? How do you think IPv6 works, it’s exactly the same.
My router’s firewall’s ipv6 section help: “All outbound traffic coming from IPv6 hosts on your LAN is allowed, as well as related inbound traffic. Any other inbound traffic must be specifically allowed here.”
on openbsd pf
block outside connections from initiating connections to your hosts
block in on $external_if from any to $ip6_network
on ip4, if the world was just you would have the same rule(in ip4). however the world is not just and you usually only get one address so you have to pull some shenanigans to spoof that address across all your hosts
match out on $external_if from $internal_net to any nat-to $external_if
Really we all have a sort of Stockholm syndrome and think yes, this is normal, this is correct and being able to end to end address a host is weird and wrong.
But it is not, because you have to let ICMP pass through, for IPv6 to work (eg. for path MTU discovery to work (no more "classic" fragmentation in ipv6)).
So it's one rule to block incoming traffic, and a bunch of rules to properly allow ICMPv6 to pass through to the internal network (look at the RFC linked above)
It's not a _good_ reason, Ubiquity should've included IPv6 support from the start with the price they're asking, but it's a reason.
I remember a coworker telling me about a TV that would request and accept a DHCPv6 address and then fail hard getting to the internet. Wifi router firmware likewise messes things up, etc...
It frankly just wasn't worth the hassle. Mobile networks that can control and enforce the full stack have been able to make it work. My guess is home/wifi environments will be IPv4/NAT until the end of time, frankly.
Writing the addresses in hex is because doing so is easier. It lines up with the binary better which makes subnetting easier, and do you really want to deal with addresses that look like "32.1.13.184.133.163.0.0.0.0.138.46.3.112.115.52"?
I was wrong and the issues were elsewhere, but it remained disabled on the router for a long time.
I’m generally a person who resists change and I can’t tangibly see the benefits of ipv6; until I realised that “port-forwarding” is an exclusively NAT problem and it’s much easier with ipv6 to just natively open a port on the firewall if I want.
It also lets me wait until other people (hopefully) build better privacy systems.
I've noticed several websites where IPv6 has lower latency than IPv4. The ease of accessing different VMs on cloud providers that will hand out a single IPv4 address, though alternatives like Betternet/Tailscale/Tor will also work around that problem.
I've tested with IPv6 on and off on several machines over the course of months. Google's search results become wild and unpredictable on the same machines soon after switching to IPv4.
My theory is that they rely on that IPv6 address to know exactly who they are providing results to and thus selling to.
If that theory didn't hold water, there would be exactly zero difference in search results after switching to all IPv4.
I've noticed that many IPv6 address blocks have more up to date location information from parties like Maxmind.
No source device obfuscation equals device tracking
In fact, macOS is so aggressive about using temporary addresses that I had to turn off SLAAC in order to be able to ssh back into my desktop.
IPv6-only CVEs (these have existed!)
Maybe it's me, maybe I have a bad config or bad hardware, but it just doesn't work for me.
Next time I try I'll use those sites and see what they say.