Making an IPv6-only VM a useful tool in an IPv4 dominated world » History » Revision 6

« Previous | Revision 6/7 (diff) | Next »
Moris Jones, 08/02/2020 01:22 AM

Making an IPv6-only VM a useful tool in an IPv4 dominated world

Datacenterlight offers IPv6-only VMs. Currently these cannot compete with IPv4 VMs or VPSes for usefulness because so much of the world still does not have IPv6 support at any level. We know that IPv6 is the future, but we need a bridge, a 'hack', to make things work in the interim. At the present time, the solution offered has three components:

  1. An IPv6 VPN, including for-free with the VM, allowing administrator access to the VM and the IPv6 world in general, even if their internet access point does not support IPv6
  2. NAT64 outgoing gateway, enabling the VM to access machines and services only available on IPv4
  3. IPv4-to-IPv6 incoming gateway, offering port forwarding, that enables the VM to be visible and provide services to the IPv4 world without its own dedicated IPv4 address

But there is a problem:

At this time the IPv4-to-IPv6 incoming proxy only officially supports the HTTP and HTTPS protocols. A website served via HTTP needs and domain, and a domain needs a domain name server, and that domain name server needs to be visible on IPv4. So the only way to use an IPv6-only VM as a webserver at this time is to pay for external DNS hosting. In fact a VM which can only provide HTTP services to the outside world is only slightly more capable than regular shared hosting, which is both cheaper and includes DNS hosting for free.

This file [[]] lists the protocols and their level of support.

All of this will be solved once the world transitions to IPv6, but that tipping point is practically still a few years away.

Most VM customers want to run a variety of services on their virtual machine, not just web hosting - after all, this a full-root-access virtual machine, not shared hosting. No serious customer is going to want to pay for a VM that can do so little. As such, the product is practically speaking just a toy, and not a useful tool.

The first thing that needs to be done is to provide an immediate solution for at least all common hosting services, preferably a universal one.

In the medium term, a less-hackish solution should replace it.

In the long term, the world will transition to IPv6.

Essential minimal services for a VM, making it a basic tool rather than a toy, are as follows:


A more reasonable solution would be to provide a generic TLS port forwarding service that works with any TLS-encapsulated protocol and implement this on every port assigned to a TLS-encapsulated protocol.

SMTP and DNS are especially challenging because they need more than just port forwarding, requiring that the incoming IPv4-to-IPv6 proxy server/gateway run a mail server / name server which routes/recurses. Furthermore SMTP over TLS behaves in a different way from other TLS encapsulated protocols, by starting out plaintext and switching to TLS, which would result in a server key mismatch (have I got this right?).

Furthermore, if we all SMTP out via the NAT64 gateway then we all get tarred with the same brush (one person sends spamlike message, all get blacklisted), and the reverse IP for the NAT64 gw will be ungleich and not the domain of the VM-owner which also gets you flagged as spam. To solve this the NAT64 server needs to act as a smarthost, restricting messages by domain and spamchecking, rather than just address-translating the protocol.

So in summary, if I have understood things correctly, the current position is that IPv6 VMs are of no practical use for sending and receiving email unless you are only interested in gmail, and while incoming is solveable in theory, outgoing can only be solved by lobbying. In practice of course, running your own mailserver and dealing with the likes of groogle and Miqro$loth is an uphill battle irrespective of IPv6.

The following approach could address the issue immediately, while continuing to more fully implement the proxy as the medium-term solution

Ungleich probably has an inventory of IPv4 addresses "on the shelf" for company use when necessary and for customers that order IPv4 addresses. In the meantime, these can be "lent" to customers who need the services not yet implemented in the gateways. When addresses start running short, Nico will know which features in the gateways to prioritize in order to free up the addresses.
The best part is that the customers don't need to know that the addresses are being 'lent' to them. This is important because to ungleich it feels like they are giving away something they should be charging for, and the customers may become 'spoilt' and protest when the address is taken away. How will this happen? The "gateway" host that the customer uses would resolve to an IP via a DNS lookup on the ungleich internal DNS. For a service not currently implemented (e.g. POP3s), the DNS lookup would resolve to the interim IP4 address unofficially allocated to the said VM. In the future, when the gateway supports the protocol, the DNS would instead resolve to the gateway address and the IPv4 address would be freed up without the customer even feeling the change.
It wouldn't be necessary to allocate a single IPv4 address entirely to a specific VM, multiple VMs requiring different protocols can be stacked up on the same N.N.N.N. This would be achieved by including the protocol in the host name, for example smtp-bob-ip4-gw.ungleich, pop3-alice-ip4-gw.ungleich could resolve to the same address but still provide Bob and Alice with an IPv4 presence for SMTP and POP3 respectively.
The upside of doing this is that it should be relatively quick to implement and make all protocols available on the gateways immediately. The downside is that it will be annoying to maintain and slightly delay the implementation of the fully functional gateway.

Updated by Moris Jones almost 4 years ago · 6 revisions