Horrible IPv6 to IPv4 Hack

Reading Time: 3 minutes

With the ever greater need for the adoption of IPv6 in the Internet world it’s high time people started dual stacking services on both IP versions. Sadly, sometimes this is not possible when particular software hasn’t caught up with 1995.

This is especially frustrating when, for one reason or another, you want to use a single hostname for both services which support v6 and those which don’t.

images_ipv6

The reason this is complicated is because a single hostname will have two records – an ‘A’ record and a ‘AAAA’ which store the v4 and v6 addresse(s) for that hostname.

Because the two versions are not compatible with each other there is no nice way to provide v6 connectivity to v4-only software as the addressing (and a lot of the protocol) is vastly different.

Intelligent clients, such as web browsers (taking Chrome as an example) have built in failover compatibility. This works by failing over to v4 if v6 takes >300ms to open the TCP socket. This is great as it means not only does it cater for stability issues in dodgy v6 connections but also in this scenario – a hostname which has A and AAAA records but only some services listening on v6.

What you’re probably thinking is this is horrible, just use a different hostname for v4-only services but there’s always someone who wants to be difficult.

For clients which have no failover built in the nasty workaround is to simply forward v6 clients to the v4 server with a prox-esque forwarding tool.

In this example the server is based on twisted which has no Ipv6 (yet). In order to allow IPv6 clients which do not have funky failover capability still access it could be, for example to use ‘socat‘ .

First, install socat:

apt-get install socat

Then, start socat with some parameters:

socat TCP6-LISTEN:2000,bind=[2001:470:250:4fa::dead],su=nobody,fork TCP:192.168.100.64:2000 &

In the example above you are listening on IPv6 TCP port 2000 and forwarding to IPv4 TCP port 2000.

The obvious problem here is that all requests to v6 will appear by the server application to have a source IP address of the machine doing the forwarding (it’s v4 address). In other words the application has no way of knowing the originating IP address. That is why this is nasty and for edge cases only. There is no way around that as the whole problem here is the v4 stack doesn’t understand v6 at all, hence the need to do this in the first place.

Please don’t say how horrible this is (clue is in the article title) but it does provide a workaround in some circumstances 🙂