perfSONAR 4.0.1 on a dual-stack host
I finally throwed in the towel. I did an installation of perfSONAR 4.0.1 on a dual-stack VM.
Our DHCPv4 service provides our clients with a wealth of information. It is actually good to see so many of the offered settings being recognized by the anaconda installation system. This told me that the installation system is firmly grounded in IPv4, and is not ready for pure IPv6 networks.
anaconda managed to get hold of our NTP servers via DHCPv4 and would proudly proclaim they are working. Try this in a pure IPv6 network and anaconda will claim the NTP servers are non-functioning, but, ntpd will be able to exchange measurements with its configured servers once the system is finally up & running.
anaconda was not able to utilize DHCPv4 for setting the timezone. anaconda bluntly ignores the time-offset variable, or it doesn’t even ask for it. Maybe it’s too difficult to assign a timezone based on an offset measured in seconds, or offer a few sensible alternatives for us to choose from. Setting the correct timezone isn’t difficult, but it could be automated in a couple of ways, and DHCPv4 is one of them.
In the future, anaconda should try DHCPv6 in addition to DHCPv4, in particular when the latter is unavailable/unresponsive. Maybe Enterprise Linux still believe in IPv4 only.
What about perfSONAR 4.0.1? Its web interface is up & running and is showing all elements when accessed by its IPv4 address. NTP is synched. The system is globally registered, which is also dependent on IPv4. I would actually prefer to be asked whether I want a particular system to be globally registered or not. Most want it registered, I guess, all in the name of co-operation.
When accessing the web interface using the IPv6 address, the test results doesn’t show up at all.
After configuring some tests and waiting a few minutes, the results showed up in the web interface, but only those involving IPv4 addresses. Yes, you must still access the web UI by the system’s IPv4 address, which suggests adding AAAA records to the DNS domain names isn’t a good thing. Maybe a variant of the approach of the late W. Rich Stevens is doable; for each hostname.FQDN, assign a AAAA record only to hostname-6.FQDN.
Sadly, my shop is short on public IPv4 addresses, and so is our ISP. I seriously doubt the ISP will cough up even a /28 block to accommodate my planned 9 public perfSONAR hosts. Up to 7 hosts running on physical machines scattered throughout the network, 1 host running as a virtual machine purely as a comparison, and 1 virtual host working as a CMA to keep all the records.
I could assign RFC 1918 and RFC 4193 addresses to these hosts, but that would keep them all internal and not accessible on the internet. Also, they wouldn’t receive any updates unless I deploy NAT44.
IPv6 is the future, whether you like it or not.