Make reachable via a fixed address (e.g. IPv6) a server that is actually connected via a variable IPv4 adress?

Need: Internet host at a fixed IP address for full-stack self-hosting

People want to perform self-hosting in an area where no ISP provide sufficient service with a fixed IP address. They provide one IP address that changes at least once every week and has bad reputation (regarding spam).

Whatever the reason, a fixed IP address is definitely needed (actually, the address will be one of the glue records for a domain in the whois database, to host a full-stack DNS-mail-http-everything server, but the actual reason does not matter so much, let's just say that a fixed IP is needed).

How to do that ?

Is there a reasonable solution to have the host reachable at a fixed IP address ?

Non-solution

Dynamic DNS is a non-solution. It's fine for casual access of high level services by a handful of users, not for hosting a mail server, for those reasons: (1) it adds a single point of failure, (2) people report delayed updates with usual dynamic dns providers, (3) changing IP breaks existing TCP connections, (4) ever-changing IP puts your mail server on IPs with bad reputation that you can't fix and won't register on RBL services, (5) fundamentally dynamic DNS comes far downstream, you can't update a whois glue record which assumes a fixed IP, you obviously can't self-host the very DNS server which will have a CNAME to the dynamic DNS service anyway.

Possible trail towards a solution ?

  • Use some form ot tunneling to have the server reachable via a fixed IP (v4 or v6) through some service like http://tunnelbroker.net/ .
  • The tunnel could be used either for all traffic, for the part of the traffic that needs fixed IP (DNS, mail, HTTP server), and perhaps a self-hosted dynamic DNS (would provide a different host name that would resolve at any time to the variable IP address, without the need to depend on an external dynamic DNS).
  • The variable address would be used for client activity, web browsing, downloads, for e.g. sharing Linux distributions ISOs on peer-to-peer networks). Pros: (1) much lower in the stack, provides a fixed IP compatible with a glue record and all the stack above. (2) on ISP address change, TCP connections to fixed IP address aren't broken, though there might be a pause while the tunnel reconfigures. Cons: another single point of failure, downtime on ISP address change ?

Questions

  • Does it make sense or would it fail or be impractical for some reasons ?
  • Would the tunneling work well ? How about a downtime when ISP-supplied IP address changes ?

Solution 1:

You essentially have to chose one of three options:

  • Use an ISP who will provide you native IPv6 with the static prefix you need.
  • Forget about self hosting and rent a server in a data center.
  • Use some sort of tunneling solution.

If for a moment we assume the first option is ruled out due to insufficient competition in your area and that a requirement to manage physical security yourself rules out the second, then you are left with tunnels as the only option.

Notice that a VPN is also a tunnel, which happens to also perform encryption and authentication of the traffic. For the most part those additional security features of a VPN makes no changes to your scenario, so you can consider a VPN to be just another kind of tunnel.

Tunnels do add additional complexity to your networking configuration. That is something you have to deal with. But assuming sufficient understanding of how the network protocols work, that additional complexity is quite manageable.

Another drawback of a tunnel is that when the dynamic IP (which you have to run the tunnel over) changes you have to reconfigure the tunnel before it works again. To traffic running over the tunnel this will just cause a brief packet loss, but not actually cause any open connections to be broken.

Perhaps the most problematic drawback of a tunnel is, that it introduces another single point of failure into your system. In a typical setup both the tunnel server and the connection to your ISP will be a single point of failure.

There are ways around these drawbacks, but I am not aware of any widely deployed solutions.

Solution 2:

You can run services behind a tunnelled connection but you would need a tunnel for both IPv4 and IPv6 that provides you stable addresses for both address families and that can quickly respond to changes in the uplink connection. The only protocol that can do that that I can think of is LISP.

There are a few LISP based providers that you can try. I don't know about any free ones.

Solution 3:

Get a VPN with a fixed address and use this to self-host.

  • if your "native" IP changes, you will probably have to reconnect your VPN connection;
  • you can either use "ip rules" to send the outgoing packet to the relevant interfaces or forget abour your native IP address completely and route everything over your VPN.

An added benefit of using a VPN is that your server/service/static IPs will not be bound to a given location. If your server if a laptop of a plug-computer, you can move it easily: if you are on holidays, you might take it with you or plug it in friends. You could probably even self-host on the move over 3G connections and public Wifi (as long as you accept downtimes).