IPv6 NAT from a webhosting perspective

IPv6 is something that’s been coming for a long time now, to address the shortage of IPv4 addresses. If you’re not familiar with the problem, it goes like this:

Networked devices need addresses to find and talk to each other. When the internet was invented there was capacity to address up to 4 billion devices. We’re now running out of addresses for all the networked devices in the world. There are two established technological ways out of this problem:

  1. Be frugal and share addresses, this is called NAT
  2. Move to a system with capacity for many more addresses, this new system is called IPv6. It’s not compatible with the old IPv4 system, but it gives us about 50 octillion addresses for every person on the planet

NAT is a really familiar technology – most domestic internet users have a NAT device built into their modem. Your ISP issues you with 1 public address, and NAT lets you share that amongst your PC, laptops, smartphones, tablets, toasters, etc.

ISPs also face a similar problem of only having so many addresses to hand out to their customers (ie. you there at home). It’s expected that they’ll also start using NAT on a grand scale (and some already are). This is called Carrier-Grade NAT.

NAT is really a stopgap measure while we transition to IPv6. It’s a necessary evil because moving to IPv6 is an amazingly monumental task, and not something that can happen overnight. NAT isn’t a solution in and of itself because it limits the ability of devices to talk freely to each other.

How does this affect content providers, like Anchor? The short answer is that we’re probably in a better position than ISPs, but depending on whether content providers have done their homework, NAT may also be on the cards for them in future.

The issue is roughly the same as for ISPs – a limited pool of IP addresses to assign to a growing number of customers’ servers. If a server doesn’t have an address then it can’t get on the internet, which isn’t very useful. We’ve done our homework and ensured that we have plenty of addresses to last for the foreseeable future.

But what if we hadn’t? We’d probably have to deploy NAT on a serious scale (though our CTO says that anyone who deploys NAT at Anchor will be launched from a trebuchet). Amazon does this universally with their cloud computing instances, by doling out public IPv4 addresses only as needed, and making the most of a limited pool of IPv4 addresses. We’d do it slightly differently, by giving IPv6 addresses out like candy to every server, and then doing NAT between the public IPv4 addresses and the internal IPv6 addresses.

A solution like this is typically referred to as NAT64, reflecting the translation between the two incompatible protocols. It gets the job done, but it’s ugly and has generally been the realm of expensive hardware appliances. Until recently.

It’s well known that Anchor is a diehard FOSS company, and we use Linux almost everywhere. As of a little while ago, Linux can now do NAT on IPv6, and development is active for various NAT64 implementations.

Evidence of IPv6 NAT capabilities in newer 3.x kernels, hostname redacted as defense against the trebuchet.

Evidence of IPv6 NAT capabilities in newer 3.x kernels, hostname redacted to avoid airborne repercussions.

NAT is going to be an important topic in future as ISPs deal with the transition to IPv6, and it will likely affect many end-users, not just big operators. While we expect that we’ll never need to use it ourselves, it’s good to know that people are working on open implementations that will only improve over time. And Matt, please put away the trebuchet!