Each computer on the Internet has its own public IPv4 address, similar to a phone number: for example, 131.193.178.181. The target of each packet of data is identified by a public IPv4 address.
Problem: There are only a few billion public IPv4 addresses. Many of those addresses have already been allocated. What happens when we run out of public 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 web servers on behalf of the other 19 computers, forwards telephone-over-IP calls from the other 19 computers, etc.
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.
This is an example of what's called an interoperability failure. Right now, many---in fact, most---Internet servers can't talk to clients on public IPv6 addresses. Until this changes, using a public IPv6 address instead of a public IPv4 address will be a disaster for clients.
Similarly, many---in fact, most---Internet clients can't talk to servers on public IPv6 addresses. Until this changes, using a public IPv6 address instead of a public IPv4 address will be a disaster for servers.
Conclusion: Before clients can be safely deployed on public IPv6 addresses, practically every server will have to learn how to talk to those clients. Before servers can be safely deployed on public IPv6 addresses, practically every client will have to learn how to talk to those servers.
Public IPv6 addresses have an inherently lower cost than public IPv4 addresses, because there are many more of them, but this cost advantage won't matter as long as public IPv6 addresses are noticeably less useful than IPv4 addresses. Right now, public IPv6 addresses are practically useless.
(In response to this page, one commentator said that he had set up public IPv6 addresses, and that those addresses could talk to various public IPv6 addresses at other sites. This doesn't mean that those addresses are useful. The entire Internet is reachable through IPv4; only a small part of the Internet is reachable through IPv6. The sysadmin could eliminate his public IPv6 addresses; he can't eliminate his public IPv4 addresses. For example, his web page is on a public IPv4 address.)
The magic moment for IPv6 will be the moment when people can start relying on public IPv6 addresses as replacements for public IPv4 addresses. That's the moment when the Internet will no longer be threatened by the IPv4 address crunch.
Answer: We go through every place that 4-byte IPv4 addresses appear, and allow 16-byte IPv6 addresses in the same place. Several illustrative examples:
Once these software upgrades have been done on practically every Internet computer, we'll have reached the magic moment: people can start relying on public IPv6 addresses as replacements for public IPv4 addresses. For example, here's how a client on a public IPv6 address, let's say address 0123456789abcdef0123456789abcdef, will connect to the Google web servers:
In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses. Public IPv6 addresses can only exchange packets with each other. The specifications could have defined a functionally equivalent public IPv6 address for each public IPv4 address, embedding the IPv4 address space into the IPv6 address space; but they didn't. (RFC 2893 does some of this, but the IPv6 proponents say that RFC 2893 is a local option, not part of the IPv6 architecture. In particular, they say that an IPv6 client is not supposed to send a packet to an IPv4 address by using the RFC 2893 address.)
This might sound like a very small mistake: after all, once IPv6 is working, we can move everything to IPv6, so who cares about IPv4? The problem is that this mistake has gigantic effects on the cost of making IPv6 work in the first place.
Look at the Google example above. A client on a public IPv6 address is exchanging packets with servers on public IPv4 addresses. Unfortunately, under the current IPv6 specifications, that doesn't work. Each of the server administrators must
(One commentator responds that IPv6 has an equivalent of DHCP. I can't imagine why he thinks that this contradicts anything I'm saying.)
In short, because of this mistake in the IPv6 design, making IPv6 work means much more than upgrading software. Every administrator of a server on a public IPv4 address---and, for the same reasons, every administrator of a client on a public IPv4 address---has to go to extra effort to acquire and enable a public IPv6 address.
Example of the difference: As of 2002.11, Google hasn't published IPv6 addresses for www.google.com. What exactly is Google's reward for spending time setting up useless IPv6 addresses for its perfectly functional IPv4 machines? In contrast, they've had IPv6 software for years.
Under the current IPv6 specifications, to make the magic moment happen, not only do we have to convince a few thousand network programmers to do something with no immediate benefit, but we also have to convince millions of computer administrators to do something with no immediate benefit. This is an incredibly bad way to handle a transition.
(One commentator characterizes my page as saying that ``it takes a massive amount of work to convert all applications over to ipv6.'' He's completely missing the point. Even if all the programming were done, public IPv6 addresses still wouldn't be useful. Why not? Because they wouldn't be able to talk to most of the Internet. Why not? Because most administrators on the Internet wouldn't have bothered setting up their own public IPv6 addresses.)
(1) I'd like to connect my office computers to the IPv6 network, and make their services---the web server, for example, and the mail server---available to IPv6 clients around the world.(2) I control the operating system and the applications. I am ready and willing to make various changes to the code.
(3) However, I refuse to provide any information to those programs beyond what they already have (such as my IPv4 addresses), and I refuse to do any work outside changing the programs themselves. I'm not going to ask my ISP for an IPv6 address, for example, and I'm not going to touch my DNS data.
Here's the big question: How do I achieve #1, taking advantage of #2, without violating #3?
You might think that #2 and #3 are strange. Why am I willing to write code, maybe quite a bit of code, but not willing to send a message to my ISP and make some trivial configuration changes? Isn't this backwards?
The answer is that I'm actually talking about a huge number of IPv4 sites. There's nothing special about my site. When the same situation is repeated at N sites, the code is written only once, while the trivial requests and the trivial configuration changes are repeated N times.
I see no reason that my users should have to suffer the costs of manual configuration. On behalf of my users, I object to all IPv6 transition plans that impose such costs.
Maybe you've put so much time into IPv6 that you don't care about the five minutes you spent acquiring a connection and configuring software. ``Look how easy it was,'' you say.
Well, I'm looking at a much larger group of users, and most of them aren't putting even five seconds into IPv6. They have better things to do. If the IPv6 configuration isn't automatic, it won't happen.
| A long time ago, SMTP clients found SMTP servers by looking at A records. People decided to introduce MX records for extra flexibility. | Right now, clients find SMTP servers, web servers, etc. by looking at A records and making IPv4 connections. People decided to introduce AAAA records and IPv6 connections. |
| Some people thought that every server on the Internet should be forced to set up MX records. Then they could start deploying clients that used MX records and that can't talk to A records. | Some people think that every server on the Internet should be forced to set up a new IPv6 address and publish AAAA records. Then they can start deploying clients that use AAAA records and IPv6, and that can't talk to A records and IPv4. |
| A much less expensive transition plan, and the one that was adopted, was for clients to continue using A records when there were no MX records, effectively embedding A records into MX space. This allowed existing servers to talk to MX clients without any effort on the part of the server administrator. | A much less expensive transition plan, and the one that should be adopted, is for clients to continue using A records, using an embedding of IPv4 addresses into IPv6 space. This allows existing servers to talk to IPv6 clients without any effort on the part of the server administrator. |
| Deployment of MX clients depended vitally on having those clients fall back to A records in the absence of MX records. The other approach, pestering every DNS administrator on the Internet to set up MX records, would have been a miserable failure. | Deployment of IPv6 clients depends vitally on having those clients fall back to A records, and talk to servers on IPv4 addresses, in the absence of AAAA records. The other approach, pestering every computer administrator on the Internet to set up IPv6 addresses and AAAA records, is a miserable failure. |
| Many people didn't understand the importance of this embedding. For example, RFC 974 characterizes it as ``benefit of the doubt'' rather than an essential part of the protocol definition. | Many people don't understand the importance of this embedding. For example, Keith Moore characterizes it as a ``guess'' rather than an essential part of the protocol definition. |
| Looking at old-client-new-server instead of new-client-old-server: There was a transition period from old clients, connecting only to A records, to new clients, which also understood MX. Servers had to be reachable through A records until the old clients were gone. | Looking at old-client-new-server instead of new-client-old-server: There will be a transition period from old clients, which can connect only to IPv4 addresses, to new clients, which can connect to both IPv4 addresses and IPv6 addresses. Servers will have to be reachable through IPv4 addresses until the old clients are gone. |
Consider, for example, Jun-ichiro itojun Hagino's draft-ietf-ngtrans-ipv6-smtp-requirement-06.txt (2002.06.28), which recommends that mail servers on public IPv4 addresses set up public IPv6 addresses too.
This doesn't make any sense. Why is it a recommendation, rather than a requirement? Why is it only for mail servers? If we don't have all servers and clients talking to IPv6 addresses, how are we going to reach the magic moment? Answer: We won't!
``You seem to assume that a single, Grand Unified Plan, would suit everybody's needs,'' Pekko Savola wrote on 2002.03.18. ``I don't think that's a reasonable assumption.'' After I said ``Every computer on the Internet needs IPv6 software,'' Francois Dupont said ``Please be serious.'' These people have no clue how to manage a transition.
``Over the next several months, we will be exploring transition scenarios and working on an overall architecture for IPv6 transition,'' Margaret Wasserman wrote on 2002.03.19. But that architecture never materialized. Randy Bush shut down the ngtrans working group on 2002.08.14: ``It is time for ngtrans to declare victory ... The combined v4/v6 network is no longer the future, it is today.''
Wake up, folks: The ``combined v4/v6 network'' is a bad joke. Without a coherent transition plan, IPv6 has no credibility. I'm certainly not going to waste time implementing half-baked plans; I want to see a plan that, if implemented and universally deployed, will produce the magic moment.
Many years ago, OSI proponents were convinced that the OSI network was the wave of the future. They created all sorts of OSI software with all sorts of amazing technical features. They never seemed to understand why the vast majority of Internet users didn't sign up. Sad.
For example, some people make quite a fuss about replacing IPv4 with IPv6 as a mechanism for computers that aren't on the Internet to talk to the local proxies. Wake up, folks: That isn't the problem we need to solve. We can, and do, use private 10.* IPv4 addresses to talk to proxies. The address crunch involves public IPv4 addresses; to fix it, we need public IPv6 addresses that can talk to all the same sites.
As another example, some people 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 those plans.) Wake up, folks: Nobody will join your IPv6 network if it can't talk to Google, CNN, etc. We need practically every computer on the Internet to talk to the IPv6 network. As I wrote on 2001.11.11 in response to Keith Moore:
Keith, there is one network that has aol.com and cnn.com and cs.utk.edu and an incredible number of other sites.Normal people call this network ``the Internet.'' They insist on being connected to the Internet, so that they can exchange email and web pages and so on with other Internet sites.
The universe you're imagining, in which sites are split across two global networks that have trouble talking to each other, is an ancient historical mistake that will never be repeated. What kind of idiot would be the first to disconnect his site from the original Internet in favor of the new Internet? Why haven't you cut yourself off from IPv4, Keith?
If you want IPv6 to succeed as a global network, you have to figure out how to make an IPv6 address just as useful as an IPv4 address. How do you plan to do that, Keith?
The way to make IPv6 addresses work is to teach every Internet computer how to talk to IPv6 addresses---not just as an option that the sysadmin might configure, but as something that's automatically enabled as part of regular software/hardware upgrades.
Will this be done overnight? Of course not. But it is the crux of the IPv6 transition. I remain astonished that this WG didn't settle the details years ago.