Running an IPv6-only webserver

There are times in the long struggle for IPv6 adoption that we forget that dual-stack is not the end goal, but merely a transition mechanism. If we are to get to the end goal, IPv6 Everywhere then it isn't enough to have IPv6-only clients on the internet, but also IPv6-only attached content servers.

IPv6-only webserver, easy right?

So how hard can it be? Find a hoster which offers IPv6-only attached servers, install apache, or your favourite webserver, and run, right?

Works great for all 20% that are on the IPv6 internet. But for the other 80% of traffic that is on the internet your server is invisible. Great if you are running a stealth server, not so great if it represents your business and you wanted your customers to reach your website.

Oh, that legacy protocol, IPv4

So not only do you want to have the cool IPv6-ers, but also those legacy IPv4-ers to get to your IPv6-only attached webserver.

One of the techniques to permit IPv4 access to your IPv6-only webserver is to us a HTTP Proxy server. The HTTP Proxy server listens to IPv4 (with a real routable IPv4 address) and then directs traffic to the correct IPv6-only server sitting behind it. Folks have been doing this kind of thing with IPv4 for nearly two decades, the proxy server is also called a load balancer.

Web Proxy Network

Gosh, all my "hits" are from the Proxy Server

So the Proxy Server does the conversion from IPv4 to IPv6, but now all the webserver log entries are from the Proxy Server. - - [15/Jun/2018:01:36:17 +0000] "GET /... - - [15/Jun/2018:01:38:28 +0000] "POST ... - - [15/Jun/2018:01:38:32 +0000] "GET /... - - [15/Jun/2018:01:45:15 +0000] "POST ... - - [15/Jun/2018:01:45:19 +0000] "GET /... - - [15/Jun/2018:01:45:24 +0000] "POST ... - - [16/Jun/2018:03:09:30 +0000] "GET /...

Not all that useful for traffic analysis1. Fortunately, there is a Proxy Protocol which allows the Proxy Server to insert a X-Forwarded-For: line into the HTTP header. This line contains the hostname, or IP address of the original requester.

The Proxy Protocol

In apache, there is a mod-proxy-protocol module which interprets the X-Forwarded-For: line as the original requester, and the logs are now restored to what one would expect.

The downside of the mod-proxy-protocol module is that once it is enabled, the server will not respond correctly to a request without the X-Forwarded-For: line. It returns a 502 server error.

Unfortunately, this means that even though the server is IPv6-only connected, it can not receive requests that do not go through the proxy. The Proxy Server must be in the data path for both IPv4 and IPv6. For load balancer applications, this is understandable.

However, as a migration tool to enable the IPv6-only server to serve both IPv4 and IPv6 it is an unnecessary over-complication.

Even the improved apache module, mod_remoteip which also implements the Proxy Protocol (as of version 2.4.30), does not permit the Proxy Server to forward only IPv4 traffic, and accept IPv6 traffic natively (e.g. without the proxy server).

Controlling access to the server

The old apache 2.2 version of Access Control, using deny from ..., does work in version 2.4 but not with either of modules supporting the Proxy Protocol. To be fair, apache has been stating in their documentation that the old v2.2 way would be deprecated. One must now use the Require not ip ... to work with the mod-proxy-protocol module.

So, it was time to convert my Access List for my server, no time like the present, I guess.

Old Way

    <Directory /mydir>
        Order allow,deny

        # test network          
        deny from 2001:470:ebbd:d0::1/64

        deny from 5.104.107.
        deny from 31.204.108.
        deny from 38.100.8.
        deny from 45.55.254.

        allow from all

New Way

            # test network
            Require not ip 2001:470:ebbd:d0::/64

            Require not ip
            Require not ip
            Require not ip
            Require not ip

            Require all granted

The Downside of using a Proxy server

Other transition mechanisms, such as NAT64, are used less and less as more traffic flows over IPv6. Unfortunately, using a Proxy Server to serve IPv4 clients, requires that IPv6 traffic also must use the Proxy server (if proxy protocol is to be used). Which means that as IPv6 traffic increases, the Proxy Serer remains in the data path, abrogating one of the real advantages of an IPv6-only server, a direct connection.

Wrapping up

So the good news is that it is really easy to put content on IPv6 with an IPv6-only server. The less good news is that the content can also be served to IPv4 clients, but it is overly complicated to do so and in the 21st century, it shouldn't be this hard.

Note 1: Sure you could use Google-Analytics, or something equivalently convenient, but I would rather analyze my own data. Google doesn't need to know everything about me.

by Craig Miller
2 July 2018