Because we don't want to use 20 IPv4 addresses for the cluster of 20 nodes, when we only have so much addresses assigned to our institute. We could have gone the NAT route, but then we'd need to have some router. And if we designate the head node as router, all traffic would not go through the switch directly, but first through the head node and then out. This would mean that the nodes are less independent, as they have this one additional choke-point. Our university gave us a /64 for this network, so we just used that and it worked flawlessly, also for university-internal distro-package fetching and host-cluster connections.
Also, research software is usually working nicely with IPv6. If we encounter something that would really need IPv4, we could update the thing and give it some local subnet - but currently we were lucky.
Yes, I did this on my personal network. I'm in Linz (Austria), the nearest tunnel to a german speaking country that's listed on tunnelbroker.net was Berlin (if I remember right). Everything worked rather well, but I then decided against it, because of the GeoIP implications (with one IP being in Austria and one in Germany) and the added latency. It's noticable when SSHing somewhere whether I'm Linz-Linz or Linz-Berlin-Linz, especially when a small lag spike happens, which is rather frequent with the cable-based network our ISP is offering. It wasn't worth it to half-slowdown our network just to not rely on jumping through some dual-stack node in the university.
If anybody from Liwest (our local ISP) reads this - IPv6 would be really nice! :)
We are IPv6-only on our institute-internal CPU compute cluster based on slurm. Only the head node has an IPv4 address, so that it can be reached from IPv4 only clients (sadly, there are still quite a lot). All nodes inside the cluster talk over IPv6. And all other computers with IPv6 access use that to communicate to the head node. We are transitioning to IPv6-only for internal services and try to avoid using IPv4 addresses, only going back to it when something needs to be accessed from the outside.
Sadly, our local ISP is still IPv4-only, meaning we cannot even access our IPv6 hosts while at home, so we need to fall-back to IPv4 quite a lot. Also, the Cisco VPN is still IPv4 only (because of lacking resources to add IPv6 support), so not even the VPN helps. We need to jump over some dual-stack host then.
When speaking to the local ISP, they just reply that it's not planned soon, they don't have resources for it, and "they evaluated IPv6 and don't have a reason to support it". Me/us giving them reasons was not enough it seems.
Also, research software is usually working nicely with IPv6. If we encounter something that would really need IPv4, we could update the thing and give it some local subnet - but currently we were lucky.