IPv6 and internal networks

One problem with the migration to IPv6 is that many people have problems understanding how IPv6 is different, making the assumption that if something existed in IPv4, it must exist in IPv6. This isn't the case. In IPv6, various things that existed in IPv4 are no longer needed or relevant, and so the approach network administrators take to solving similar problems is different.

Let's look specifically at how you'd administer your local, internal, network.


IPv4

In IPv4, the elements of a modern internal network are:

• Every machine is allocated an IP address in the so-called private addresses space, typically 10.x.x.x or 192.168.x.x.
• To connect to the Internet, a device called a transparent proxy, or a NAT gateway (the latter is more common) is provided that allows the machines to make outgoing connections, making those connections appear to come from the gateway/proxy itself. This machine is connected to both the internal network, and the Internet.
• IP addresses are allocated using a system called DHCP: a central server maintains a list of IP addresses and computers. When a computer connects to the internal network, it asks this server for an IP address, and the server gives it one.
• If a machine has to have a specific address, the DHCP server is programmed to give it that address, otherwise it allocates addresses dynamically, from a pool.

There are reasons for all of these features:

• The "private address spaces" exist because IP pools aren't easy to allocate, there aren't enough public IP addresses for the number of networks.
• The transparent proxy is used because the machines on the internal network do not have public IP addresses, and so can't communicate with the Internet directly.
• A central DHCP server maintains a list of IP addresses because each network only has a small number compared to the number of devices in the world, machines can't allocate IP addresses for themselves because they might end up with the same address as something else on the network.
• The central DHCP server has to maintain a list of IP addresses for certain specific machines because otherwise there's no way to give those machines a predictable IP address.

Now, let's look at how you'd administer an IPv6 network.

IPv6

In IPv6, the key elements on an internal network are:

• Every machine is allocated a public IP address, all with the same 64 bit prefix.
• To connect to the Internet, a simple router is used. This router also has an IP address with the 64 bit prefix mentioned earlier. The packets pass through the router to and from the Internet unchanged.
• IP addresses are allocated using a system called NDP. In NDP, the router transmits messages across the network with basic networking information - typically, that the router is a router, what the prefix is that's in use, and other useful configuration information. Devices configure their IP address by taking this advertised prefix, and prepend it to a static number, based upon something called their MAC address (a 48 bit number programmed into every network chip.) This becomes that device's IPv6 address.
• IP addresses are always static, as long as the network prefix does not change.

Why is this different? Well:

• There are plenty of IP addresses in IPv6, and it's been designed to be easy to obtain entire blocks of public IP addresses. Indeed, that's exactly what your ISP will give you, a block of public IP addresses - your ISP gives you a prefix, and you're all set.
• If everyone's using real IP addresses, there's no reason for routers to do anything other than pass packets unchanged between the Internet and your network.
• There are so many IP addresses on each network, that devices can come preprogrammed with their own IP address (minus the prefix, of course) without any risk of two devices clashing. There's no reason to have a central server keeping track of who's been allocated what.
• All machines, thanks to the way IP addresses are allocated, have predictable IP addresses. There's no risk a machine's IP address will unexpectedly change.

But what if I don't want to be connected to the Internet?

Private networks aren't always connected to the Internet. Experimental networks, for example, might need their own IP address ranges. Or you might have a security issue that means you absolutely must not have the network connected to anything other than specific other networks.

You have multiple options, including one official option, but one thing to understand is that you can get away with using pretty much any IP address range you want, even one in use by another party, as long as you don't plan to route the packets outside of your own network. The "official" option is unnecessary and arguably misleading, although that doesn't mean I recommend not using it in place of an arbitrary address!

Why would any prefix work for a network of nodes not connected to the Internet? Well, remember that each device allocates its own IP address from a combination of a public prefix, and a device specific 64 bit number. The devices on your network will, therefore, not have the same addresses as devices on any other network, even networks that use the same prefix! So the need for the so-called "private address" ranges becomes unnecessary, you don't need them.

This is a key thing to understand about IPv6 addresses: the "prefix" is merely used to control the route. The other part of the IP address is almost always going to be unique, unless you deliberately override it.

OK, but what happens if you're experimenting, but you intend to eventually - once your network is all situated - hook it up to the Internet?

Well, it still doesn't matter what range you pick. Changing prefix is easy as the NDP server will merely advertise the new prefix, and everyone will pick it up. The only problem you'll run in to will be with DNS - you'll have to change any DNS records you've set up manually, but that's an issue being addressed by several different parties.

That said, rather than pick one at random, there is a prefix specifically allocated for private networks. It's dubious, controversial, and I think most people who implement it don't know what they're doing, but fc00:: can be used as a private network prefix. I would strongly advise that you avoid using it. If you're asking what prefix to use, there's a very good chance you don't quite understand what you're trying to do.

Here's why. Private networks are rarely private in practice. Usually those private networks will need to communicate with one or more specific external networks from time to time, even if they're not supposed to connect to the entire world. Adopt "private" IPv6 addresses like those with fc00:: prefixes, and, just as with IPv4, you suddenly make everything much more complicated, having to create proxies with convoluted forwarded ports that may or may not work.

So what should you use for your internal, private, network whose nodes will usually only talk to one another, and the occasional, controlled, external party? You should use a real IPv6 block that's been allocated to you. They're easy to get hold of. There's no reason not to.


What's "fe80::" and why can't I connect to it?

OK, you may have noticed that your IPv6-compatible operating system always allocates itself at least one IPv6 address, with a prefix of fe80. This is called a "Link local" address, and it's actually used for control messages. The idea behind fe80:: is that when a machine starts up, it needs an IP address to use to learn about the network it's connected to - to find the NDP server, for example. It's also used for other computers on the same network to learn about your device.

While it's allocated on all devices, devices generally only enable network control messages on that address, "real" clients and servers - web browsers and web servers, FTP, etc - are forbidden from using it. Part of the reason for this is that fe80:: may only work on a small subset of your network as a whole - one room in your office building, for example, depending on how the network has been implemented. You must have real IPv6 addresses for your network.


DHCP for IPv6

It's probably worth noting, to avoid confusion, that there is an implementation of DHCP for IPv6, but it's not quite used the same way as it is on IPv4. On IPv4, DHCP became popular as a way to allocate IP addresses, but it actually does a lot more, being capable of sending all kinds of information about the network to clients. DHCP for IPv6 is generally used to implement these additional features, although it can be used to allocate IP addresses - it's just not good practice to do so.

How can I learn more?

I'll be putting together a HOWTO in the coming days about how you can build a little IPv6 test environment. Something you can read up on in the meantime is Radvd, a popular NDP server program.