IPv4 and IPv6 addressing now fully enabled

As announced in the previous post, we are going to enable dual-stack address resolution in the server network (SRV) now for all VMs.

The new scheme goes as follows (as already announced):

• vm.gocept.net resolves to both IPv4 and IPv6 addresses,
• vm.ipv4.gocept.net resolves only to IPv4 addresses,
• vm.ipv6.gocept.net resolves only to IPv6 addresses.

Please note that private IPv4 address will not be visible outside our data center. In this case, our DNS servers will respond only with IPv6 addresses to queries from the public Internet.

However, the private IPv4 addresses can be used for connections inside our data center. When queried from the inside, our DNS servers will happily provide private IPv4 addresses as well. Thus, there is no need to use hard-coded IP addresses instead of proper DNS names in service configurations.

IPv4 and IPv6 addressing in the backend (SRV) network

We are going to add IPv6 addresses to the canonical VM names in DNS. This will improve backend reachability and does not require configuration changes in most cases.

Our VMs used to have IPv4 and IPv6 addresses for a long time, but the canonical VM name (VM.gocept.net) used to resolve to the IPv4 address only. The IPv6 address used to be reachable only via VM.ipv6.gocept.net.

We already started to introduce private IPv4 addresses from the 172.16.0.0/12 space in the SRV network. This makes it harder to reach the SRV interface from the outside.

Thus, we will introduce a DNS change during the next days that includes both the IPv4 and IPv6 address with a VM's canonical name. It will look like this:

• VM.gocept.net resolves to both the IPv4 and IPv6 address
• VM.ipv4.gocept.net resolves only to the IPv4 address
• VM.ipv6.gocept.net resolves only to the IPv6 address.

We will activate the new addressing scheme for VMs in staging and test environments first. A few days later, we will activate it for all other VMs.

What does this mean for SSH logins and awstats reachability?

SSH logins and awstats usually go to the backend (SRV) interface. This means that you will be able to login to your VM at VM.gocept.net via IPv6 as well. Logins to VMs with private IPv4 backend addresses must use IPv6 or go to the frontend network.

We are currently working on an alternative solution to keep awstats reachable on VMs with private SRV addresses for customers without IPv6 connectivity.

What does this mean for inter-service communication within resource groups?

In a typical scenario, the frontend web server (nginx) talks to application instances, which talk to a database server in turn. In the vast majority of cases, just keep using the canonical VM name to address a backend service (for example, use "proxy_pass VM.gocept.net:8080" in nginx.conf). Usually the internal services will be reached regardless of the IP address family. If this does not work for some reason, state the IP address family explicitly (using VM.ipv6.gocept.net or VM.ipv4.gocept.net).