I've done a few ipv6 migrations. The IPv6 fan community (e.g on reddit and other forums ) needs to accept a dual-stack world and the doubling of complexity required to operate that way. All effort should be about education and support for dual stack. That will be the only successful path to ipv6 adoption.

Sure ipv6 has some better features, but dual-stack means you are doubling all of your config (ACLs, naming, firewalls, routing) test cases and vulnerability surface. Moreover, ipv6 is not as intuitive.

Shaming people into ipv6 will never work. More effort should be invested into best practices, patterns, migration guides, support communities & more to assist in operating in a dual-stack environment for the foreseeable future.

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".

▲ throw0101d 2 days ago | parent | next [-]

> Pure ipv6 will never happen because the weak link breaks the chain.

Define "pure". Jen Linkova has been running IPv6-only networks on Google's corporate networks for several years now:

* https://www.youtube.com/watch?v=UTRsi6mbAWM

She is a chair of the 6man WG (and involved in the v6ops WG), and has authored ten RFCs:

* https://datatracker.ietf.org/person/furry13@gmail.com

Microsoft also is IPv6-only on corporate networks (so more of their IPv4 addresses can be moved to Azure to produce revenue):

* https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...

The author of that article, Veronika McKillop, is head of the UK IPv6 Council:

* https://www.youtube.com/@ukipv6council468/videos

where you'll find lots of videos on ISPs and other institutions doing IPv6-only or IPv6-mostly (especially nowadays with DHCPv4 Option 108, RFC 8925).

▲

tonymet 2 days ago | parent | next [-]

So IPv6 is about 30 years old, and the testimony being shared is the chair of the group spending years of research and millions of dollars, finally launching ipv6 corporate lans in 2023.

You're not selling me on it's viability.

▲

throw0101d 2 days ago | parent [-]

Trying to re-engine a 747 in mid-air is a challenging operation.

> So IPv6 is about 30 years old, and the testimony being shared is the chair of the group spending years of research and millions of dollars, finally launching ipv6 corporate lans in 2023.

And how many years of research and millions of dollars was spent in the 1990s on IPv4? People used to use workstations as routers (e.g., see SunOS routeadm(1M)) and DNS caching servers before a lot of money was poured into ASICs for routing (and switching).

There are all sorts of dumbass things with IPv4: how much time has been wasted on engineering solutions around NAT (e.g., STUN/TURN/ICE)? But because IPv4 just happens to be the default we accept them as 'normal' and anything that is different is treated as 'abnormal'.

> You're not selling me on it's viability.

I'm not sure how it's not viable given there are mobile telco networks with tens (hundreds?) of millions of people getting only IPv6 addresses on their devices.

* https://www.youtube.com/watch?v=nNMNglk_CvE

* https://www.youtube.com/watch?v=QGbxCKAqNUE

There are some folks who (a) were lucky enough to get in early on the IPv4 address land rush, or (b) are rich enough to be able to purchase IPv4 addresses, but there are also (c) plenty of folks who are left with scraps for IPv4 connectivity. The fact that you happen to fall into (a) or (b) does not mean you get to dismiss the folks in (c) who need IPv6, as otherwise they'd have no connectivity at all.

	▲	tonymet a day ago \| parent [-]
		can you clarify the point you're trying to make? to me this sounds like more of the shaming approach, which doesn't resolve the effort needed.

▲

tonymet 2 days ago | parent | prev [-]

that's what I'm talking about

▲ Dagger2 2 days ago | parent | prev | next [-]

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.

▲ 3 days ago | parent | prev [-]

[deleted]