There's been endless effort into all of those things. What else are we supposed to do when people just aren't following them anyway?

It's not even double the config. For e.g. my firewall, which is a 300-line config that I've already designed and implemented, making it dual stack mostly involves writing "domain (ip ip6)" instead of "domain ip". That's simply not double.

It's not less intuitive than v4 either. That's a lack of experience talking. Meanwhile, trying to use v4 quickly devolves into needing to use NAT, which is less intuitive.

> Pure ipv6 will never happen because the weak link breaks the chain. How many people set up an ipv6 VPC with great excitement, and late in the project they deploy from github with "NS lookup failed".

My desktop is pure v6 and GitHub works fine, which I think disproves the "never" part.

▲ tonymet a day ago | parent | next [-]

> My desktop is pure v6 and GitHub works fine, which I think disproves the "never" part.

how?

▲ Dagger2 a day ago | parent [-]

My router maps the v4 address space into a v6 /96, and my DNS server returns AAAAs pointing to those addresses. I run my own, but try setting your DNS to 2a01:4f8:c2c:123f::1 (and disabling v4 altogether) to give that a go.

▲ tonymet a day ago | parent [-]

doesn't there have to be a NAT64 gateway at the router?

	▲	Dagger2 21 hours ago \| parent [-]
		There has to be one somewhere. In my case it's running on my router, but your ISP can do it at their end, and since you can use any /96 including public ones, it's also possible for anyone to run one: `$ dig A +short github.com 140.82.112.4 $ dig AAAA +short github.com 64:ff9b::8c52:7004 $ dig AAAA +short github.com @2a01:4f8:c2c:123f::1 2a01:4f8:c2c:123f:64:5:8c52:7004 2a00:1098:2c::5:8c52:7004 2a00:1098:2b::1:8c52:7004` Note the embedded 140.82.112.4 in the last four bytes of the v6 addresses, which you can write in v4 format if you want: `$ getent ahosts 2a00:1098:2b::1:140.82.112.4 2a00:1098:2b::1:8c52:7004 STREAM 2a00:1098:2b::1:140.82.112.4`

▲ tonymet a day ago | parent | prev [-]

double the firewall, double the listening sockets to manage, double the testing (e.g. my router was working ipv4 and broken ipv6 with the same daemon), double the app-level ACLs

You can argue "it's only one line" but that one line is a new socket and new test variant needing testing. something that worked perfectly well for 5-10 years now needing a re-test.

I'm not arguing against ipv6 . I'm arguing for honest assessments of the effort needing to migrate a network , especially residential networks, to IPv6 -- as the only way to make it happen. Shaming people with "it's so easy and simple" is just dishonest and doesn't help the cause.

▲

Dagger2 a day ago | parent [-]

It's still just one firewall. You can listen on a single socket too (sockets listening on :: will accept v4 connections by default on Linux). You can likely drop many of the v4 ACLs when things are going over v6.

It's not no work. I'm just saying it's not double the work. You'd think knowing that would make people more likely to do it, but...

	▲	tonymet 5 hours ago \| parent [-]
		> It's still just one firewall. One appliance or service, but double the rules. The rules are all of the maintenance cost > You can listen on a single socket too (sockets listening on :: will accept v4 connections by default on Linux). Old apps need migrating. 99% of apps that listen 127.0.0.1:PORT and need a rebuild & re-test. Any app compiled with AF_INET need a rebuild. I encountered this working on adding ipv6 support for oauth callbacks (127.0.0.1:3000) to rclone and it was a huge pain. still never got this working reliably enough for the maintainer to merge. You're thinking about your desktop where you are recompiling constantly. I'm talking about embedded & unsupported IOT devices that are out there. Even with sources the effort to rebuild reinstall is heavy.