Providing a dual stack service behind a native ipv6 and carrier-grade NAT ISP

Suppose, you have an ISP that provides you with native ipv6 connectivity. This means, you have been assigned a globally routeable IP version 6 address -yay!! However, this comes with a cost: You don’t have a globally routeable IP version 4 address, not even a dynamic one. And this is still necessary, if you want to be able to reach your service, e.g. from cell phone networks.

By the way: The ipv6 address you are getting assigned, is still kind of dynamic: It changes frequently, probably once a day. So, you still don’t have a static address, but it is an ipv6 address. You usually get a whole network assigned and with this address, a single server running a service inside your network is reachable from outside - given the firewall allows it. There is no need for port-forwarding anymore.

Since the ipv6 address changes, you’ll need a dynamic DNS provider. And you need one, that is capable of service ipv6 addresses, so called AAAA records additionally to the A records used for ipv4.

Carrier grade NAT means, you’ll share a public ipv4 address with a couple of other customers of the same ISP. Usually, the ISP uses a couple of ipv4 addresses to which all their ipv4 internet traffic is routed. Since this NAT is running at your ISP, it is a bit difficult to configure any port forwardings. But with ipv6, this is not necessary - given you have a small root server or virtual server with ipv6 and ipv4.

That’s the downside of this solution: you need an additional server in the internet whose whole purpose is to route the traffic from ipv4 to your ipv6 address.

Suppose, you are running a private cloud service such as owncloud. And you want to run it in your local network, but also want to have it available everywhere. Having it locally has speed advantages, because you can use your local LAN network bandwidth while at home.

In sum we have: your service running on a server in your home network, another server in the internet (“proxy”), the dyndns service provider. Your service in your home network is basically running ipv6 only - due to the CG NAT, it is not dual stack capable. The server in the internet must be dual stack capable as well as the dyndns service provider.

When you are in a ipv4 only network, you access your service as usual at owncloud.example.org. The DNS entry for this returns an alias pointing to your dyndns address registered at your dyndns provider: owncloud.dyndns.example.org which returns the current addresses. Usually it returns both A and AAAA records. Since you are ipv4, you’ll use 192.0.2.11. This connection will end up at the proxy server. See number one in the figure above.

The proxy server might just run an Apache webserver with the following configuration:

<VirtualHost *:443>
    ServerName owncloud.example.org

    SSLEngine on
    SSLProxyEngine on

    ProxyPass / https://owncloud-ip6only.dyndns.example.org/
    ProxyPassReverse / https://owncloud-ip6only.dyndns.example.org/

    SSLProxyVerify none
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off

    SSLCertificateFile /etc/letsencrypt/live/owncloud.example.org/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/owncloud.example.org/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

It just uses the proxy module to redirect to your service. You might enable the certificate checks, but this is disabled now for simplicity. Important is owncloud-ipv6only.dyndns.example.org. This is a second address, where only the AAAA record is registered:

$ host owncloud-ip6only.dyndns.example.org
owncloud-ip6only.dyndns.example.org has IPv6 address 2001:DB18:01::11
$ host owncloud.example.org
owncloud.example.org has address 192.0.2.11
owncloud.example.org has IPv6 address 2001:DB18:01::11

So, it is important that your proxy server has an ipv6 connection as well, however, its address is not relevant. As long as it can reach your service via ipv6. Not using the ipv6-only name might result in an endless loop, as the proxy might otherwise redirect to itself via ipv4. This was number 2 in the figure above.

If you are in an ipv6 capable network, as in number 3, you’ll access your service directly via its ipv6 address, without using the proxy.

And if you are in the same local network, you’ll access your service even without using the internet - all local using the same address. Ok, you’ll need the internet for DNS resolution, but otherwise the traffic to/from the service is local.

Now we have achieved world-wide access to our service, while maintaining top speed when using our service at home. And in case of the owncloud example, the data is completely in our hands.