My anecdote with an ipv6-only home network (linux router):
Doing NAT64 runs into MTU issues and the behavior I observed is chrome would resend the request but only after 30s, firefox and other programs entirely failed to resend requests that were rejected due to MTU issues. Once I got the rejection, retrying in firefox or whatever would work though, so it seems like the path MTU was cached somewhere at the OS level. Reducing MTU manually seemed to fix the problem, but isn't that supposed to be automatic? Why didn't the kernel do the resends?
Old iPads, Androids just don't work, I'm not sure why. My iPhone 11 would connect to the network but declare itself disconnected after 24h or so (some lease or dns expiry which it doesn't renew?).
Steam hardcodes an ipv4 address for login... !! I'm not sure what to make of that, and the fact that it was reported around 10 years ago and they still haven't fixed it. Is it even using TLS?
I needed to make docker dev containers use host networking, because otherwise they'd get ipv4 addresses and try to do ipv4 traffic which couldn't be tunneled by default over ipv6.
Other than that it basically worked.
There's fundamentally only two different ways ipv6 can be configured from an ISP: SLAAC with no delegation, so you essentially share a network with other customers, or DHCPv6 delegation. Unlike IPv4 which has a million different offerings: PPPoE, DSLite, MAP-E, DHCP, etc etc and many of those aren't supported by linux.
I signed up with an ISP that claimed to support NAT64 (Biglobe) but they only support it on their SLAAC ipv6 + PPPoE ipv4 setup, not on their DHCPv6 PD + MAP-E setup, so I had to switch back to SLAAC. At this point in time the NAT64 support seems to be have been a lie... But anyways, to control my network DNS settings despite that I made a program to rewrite RA (and various other packets) with my own DNS server information.
Doing NAT64 runs into MTU issues and the behavior I observed is chrome would resend the request but only after 30s, firefox and other programs entirely failed to resend requests that were rejected due to MTU issues. Once I got the rejection, retrying in firefox or whatever would work though, so it seems like the path MTU was cached somewhere at the OS level. Reducing MTU manually seemed to fix the problem, but isn't that supposed to be automatic? Why didn't the kernel do the resends?
Old iPads, Androids just don't work, I'm not sure why. My iPhone 11 would connect to the network but declare itself disconnected after 24h or so (some lease or dns expiry which it doesn't renew?).
Steam hardcodes an ipv4 address for login... !! I'm not sure what to make of that, and the fact that it was reported around 10 years ago and they still haven't fixed it. Is it even using TLS?
I needed to make docker dev containers use host networking, because otherwise they'd get ipv4 addresses and try to do ipv4 traffic which couldn't be tunneled by default over ipv6.
Other than that it basically worked.
There's fundamentally only two different ways ipv6 can be configured from an ISP: SLAAC with no delegation, so you essentially share a network with other customers, or DHCPv6 delegation. Unlike IPv4 which has a million different offerings: PPPoE, DSLite, MAP-E, DHCP, etc etc and many of those aren't supported by linux.
I signed up with an ISP that claimed to support NAT64 (Biglobe) but they only support it on their SLAAC ipv6 + PPPoE ipv4 setup, not on their DHCPv6 PD + MAP-E setup, so I had to switch back to SLAAC. At this point in time the NAT64 support seems to be have been a lie... But anyways, to control my network DNS settings despite that I made a program to rewrite RA (and various other packets) with my own DNS server information.