The worst gotchas and limitations I have seen building my own self-host stack with ipv6 in mind has been individual support by bespoke projects more so system infrastructure. As soon as you get into containerized environments, things can get difficult. Podman has been a pain point with networking and ipv6, though newer versions have become more manageable. The most problems I have seen is dealing with various OCI containers and their subpar implementations of ipv6 support.
You’d think with how long ipv6 has been around, we’d see better adoption from container maintainers, but I suppose the existence of ipv6 in a world originally built on ipv4 is a similar issue of adoption likewise to Linux and Windows as a workstation. Ultimately, if self-rolling everything in your network stack down to the servers, ipv6 is easy to integrate. The more one offloads in the setup to preconfigured and/or specialized tools, the more I have seen ipv6 support fall to the wayside, at least in terms of software.
Not to mention hardware support and networking capabilities provided by an ISP. My current residential ISP only provides ipv4 behind cgnat to the consumer. To even test my services on ipv6, I need to run a VPN connection tunneling ipv6 traffic to an endpoint beyond my ISP.
I’m lucky that I have a choice of multiple ISPs all offering service on gigabit symmetric fibre. I’ve managed to keep my old setup of a /29 IPv4 allocation and /48 IPv6 allocation. But before IPv6 was available, I used tunnels at the point of the router with no problem. As such, the internal network doesn’t need to know there’s a tunnel and gets native IPv6.
The worst gotchas and limitations I have seen building my own self-host stack with ipv6 in mind has been individual support by bespoke projects more so system infrastructure. As soon as you get into containerized environments, things can get difficult. Podman has been a pain point with networking and ipv6, though newer versions have become more manageable. The most problems I have seen is dealing with various OCI containers and their subpar implementations of ipv6 support.
You’d think with how long ipv6 has been around, we’d see better adoption from container maintainers, but I suppose the existence of ipv6 in a world originally built on ipv4 is a similar issue of adoption likewise to Linux and Windows as a workstation. Ultimately, if self-rolling everything in your network stack down to the servers, ipv6 is easy to integrate. The more one offloads in the setup to preconfigured and/or specialized tools, the more I have seen ipv6 support fall to the wayside, at least in terms of software.
Not to mention hardware support and networking capabilities provided by an ISP. My current residential ISP only provides ipv4 behind cgnat to the consumer. To even test my services on ipv6, I need to run a VPN connection tunneling ipv6 traffic to an endpoint beyond my ISP.
You can get non VPN tunnels. I used both Hurricane electric (https://tunnelbroker.net) and sixxs (https://www.sixxs.net). I believe sixxs stopped offering services in 2017 though.
I’m lucky that I have a choice of multiple ISPs all offering service on gigabit symmetric fibre. I’ve managed to keep my old setup of a /29 IPv4 allocation and /48 IPv6 allocation. But before IPv6 was available, I used tunnels at the point of the router with no problem. As such, the internal network doesn’t need to know there’s a tunnel and gets native IPv6.