Moving to IPv6

The IPv4 address crunch

Each computer on the Internet has its own IPv4 address, similar to a phone number: for example, 131.193.178.181. The target of each packet of data is identified by an IPv4 address.

Problem: There are only a few billion possible IPv4 addresses. Many of those addresses have already been allocated. What happens when we run out of IPv4 addresses?

Partial solution: Do all these computers really need to be on the Internet? A company with 20 computers browsing the web doesn't need to put all those computers on the Internet. It can have a single computer on the Internet (a ``proxy'') that retrieves data from the web on behalf of the other 19 computers.

Most people agree, however, that proxies merely delay the inevitable.

Long-term solution: IPv6, version 6 of the Internet protocol, has many more addresses. There are other improvements from IPv4 to IPv6, but we can survive without them; what's really important is the expansion of address space.

The magic moment

The magic moment in the history of IPv6 will be the moment when this changes: the moment when people can start relying on IPv6 addresses for their Internet communication. That's when the Internet will no longer be threatened by the IPv4 address crunch.

What do we need to do to reach the magic moment? The answer is obvious: we need to teach all Internet clients how to talk to servers on IPv6 addresses, and we need to teach all Internet servers how to talk to clients on IPv6 addresses.

Status of IPv6

The other part, which is an incoherent mess, is a set of proposed transition plans from IPv4 to IPv6.

Most of the transition plans are a waste of time, because they do not contribute to reaching the magic moment. For example:

Some transition plans merely replace IPv4 with IPv6 as a mechanism for computers that aren't on the Internet to talk to their local proxies. Wake up, folks: that isn't the problem we need to solve.

Some transition plans focus on building optional connections from the IPv4 Internet to a big new IPv6 network. (If you see discussion of how ``IPv6-only'' computers might talk to ``IPv4-only'' computers, you're looking at one of these plans.) Wake up, folks: we need every computer on the Internet to talk to the IPv6 network.

There are a few transition plans that take helpful steps, but they typically declare success (``IPv6 support'') when the real problem still hasn't been solved. They require the system administrator to take extra time to have the computer actually talk to the IPv6 network: running special network-configuration programs, providing extra configuration for various servers, setting up AAAA records, etc.

Wake up, folks: before the magic moment, no sane site will rely on the IPv6 network, so talking to the IPv6 network won't provide any benefits. Unless it happens automatically, as part of regular software/hardware upgrades, most administrators simply aren't going to bother.

I'm not going to waste time implementing half-baked transition plans. I want to see a plan that, if implemented and universally deployed, will produce the magic moment.

From an economic perspective: There is a serious cost in having millions of IPv4 administrators go to extra effort to make their servers and clients talk to IPv6 addresses. The cost of building an automatic IPv6 mechanism is obviously much smaller.

Making servers reachable

The IPv6 client makes an IPv6 connection. What IPv6 address does it connect to? The answer has to be determined entirely by the IPv4 address. We can't pester the DNS administrator, and we don't control the other protocols, so we don't have any way to provide more information to the client.

Of course, the server has to be listening on the same IPv6 address, and packets have to be routed back and forth between the IPv6 client and the server. This has to be set up automatically on 131.193.178.181: we can't pester the host administrator.

Making clients reachable

Whatever protocol the client uses to obtain the server address needs to be extended to handle IPv6 addresses. If the client does DNS lookups, for example, then it needs to try an AAAA lookup when its usual A lookup fails. (Some clients waste time by trying AAAA before A. Note that this issue could easily have been eliminated: the DNS protocol can handle both 4-byte A records and 16-byte A records.)

Once the client has the IPv6 address, it has to connect to that address. This means that 131.193.178.181 needs an IPv6 address, with packets routed back and forth between that address and the IPv6 server.

AutoIPv6

RFC 3056 and RFC 3068 describe 6to4, which assigns a set of IPv6 addresses to each IPv4 address. For example, 131.193.178.181, which is 83c1b2b5 in hexadecimal, is assigned all IPv6 addresses beginning with 200283c1b2b5.

The AutoIPv6 address corresponding to an IPv4 address is, by definition, the IPv6 address that begins with 2002, continues with the IPv4 address, and ends with 00000000000000000001. For example, the AutoIPv6 address corresponding to 131.193.178.181 is 200283c1b2b500000000000000000001.

Other network components are upgraded to make AutoIPv6 addresses functionally identical to the corresponding IPv4 addresses, with the extra feature of being able to talk to other IPv6 addresses. In particular: