My university is still mostly on IPv4 for our infrastructure. We got in early on the IPv4 address gold rush, so we got a full /16 block. Not quite MIT’s 18.0.0.0/8 block, but enough so there’s little pressure to move. It can be a little embarrassing, feeling like an institution that should be breaking ground is instead trailing behind. At the same time, our IT department is chronically understaffed, so I can understand not doing the switch. It’s not as simple as just flipping a switch, there are many ramifications of IPv6 that aren’t immediately obvious.
There’s literally nothing stopping a moderately skilled IT team from integrating ipv6. You can run any site easily using both. The exceptions are few and even those aren’t that hard to deal with.
Source: been running dual ipv4/ipv6 Web servers for over 10 years (maybe 15 would need to check) . Likewise had ipv6 dual stack at home for a similar amount of time, initially using tunnels and then native.
Almost every server provider will give you ipv6 for free. There’s really no excuse these days not to run your services on both protocols now.
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.
My university is still mostly on IPv4 for our infrastructure. We got in early on the IPv4 address gold rush, so we got a full /16 block. Not quite MIT’s 18.0.0.0/8 block, but enough so there’s little pressure to move. It can be a little embarrassing, feeling like an institution that should be breaking ground is instead trailing behind. At the same time, our IT department is chronically understaffed, so I can understand not doing the switch. It’s not as simple as just flipping a switch, there are many ramifications of IPv6 that aren’t immediately obvious.
There’s literally nothing stopping a moderately skilled IT team from integrating ipv6. You can run any site easily using both. The exceptions are few and even those aren’t that hard to deal with.
Source: been running dual ipv4/ipv6 Web servers for over 10 years (maybe 15 would need to check) . Likewise had ipv6 dual stack at home for a similar amount of time, initially using tunnels and then native.
Almost every server provider will give you ipv6 for free. There’s really no excuse these days not to run your services on both protocols now.
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.