AutoIPv6

Computers on the Internet talk to each other through IPv4, version 4 of the Internet Protocol.

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

Right now (March 2002), relying on IPv6 addresses for your Internet communication would be mind-bogglingly stupid. Millions of Internet clients won't connect to servers on IPv6 addresses. Millions of Internet servers won't accept connections from clients on IPv6 addresses.

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

There are two parts to the IPv6 project. One part, which is fairly satisfactory though not completely settled, is a picture of how the Internet will look when everyone is using IPv6, after IPv4 has been thrown away.

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

Let's say an IPv6 client wants to reach a server running on the IPv4 address 131.193.178.181. The IPv6 client might have obtained the address 131.193.178.181 from an A lookup in DNS, or from another protocol.

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

Let's say a client on 131.193.178.181 wants to reach an IPv6 server.

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

Here is a proposed mechanism to meet the above requirements.

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:

• An AutoIPv6 network stack is slightly more than a dual IPv4/IPv6 stack. When it is told to accept packets for an IPv4 address, it automatically accepts IPv6 packets for the corresponding AutoIPv6 address, if those packets are tunneled through IPv4 to the IPv4 address. Furthermore, it routes outgoing IPv6 packets for non-6to4 addresses through an IPv4 tunnel to 192.88.99.1, as described in RFC 3068. (Other parts of the IPv6 network use a similar method to route packets for 6to4 addresses.)
• An AutoIPv6 firewall is slightly more than a firewall that can allow IPv6 packets. When it is told to allow a packet to or from an IPv4 address, it automatically allows IPv6 packets to or from the corresponding AutoIPv6 address, if those packets are tunneled through IPv4 to or from the IPv4 address.
• An AutoIPv6 server application is slightly more than a server application that can accept IPv6 connections. When it is told to listen for connections on an IPv4 address, it automatically listens for connections on the corresponding AutoIPv6 address. (It would be convenient for the programmer at this point if a single socket bound to the AutoIPv6 address would also automatically accept connections to the IPv4 address.)
• An AutoIPv6 client application is slightly more than a client application that can make IPv6 connections. If it tries making a connection to an IPv4 address, and is given an EHOSTUNREACH error from the standard socket API or a corresponding error from another API, it then tries a connection to the corresponding AutoIPv6 address.