Dubious Assumptions about IPv6

It appears to me that many participants in the IPv6 debate are working from one or more premises which I consider dubious:

1a. IPv4 will eventually collapse due to address exhaustion, and/or
1b. IPv4 will at some point become obsolete because of widespread adoption of IPv6, and/or
1c. IPv4 will eventually be replaced by IPv6

It seems to me that the IPv4 protocol can continue to support the web (as we know it), email, and several other applications, almost indefinitely. In particular, apps that can reasonably be implemented with a relatively small number of "servers" in well-known, relatively stable locations are not significantly constrained by IPv4's addressing limitations. IPv6 will be used for other things - in particular when you need a network that supports large numbers of your own individually addressible devices. For many kinds of apps IPv6 is more efficient than IPv4.

Yes, we may someday find ourselves at the point where IPv4 is nearly irrelevant because we can use IPv6 for everything for which we're using IPv4, and IPv6 has wider reach, and IPv4 is just unnecessary overhead. If and when that happens the IPv4 backbone will all but disappear fairly quickly (just like NJE/RSCS and UUCP and DECnets and X.400 networks did). We should certainly adapt our protocols so that they can use IPv6 (as we are doing) so when that day comes we will be able to reap the benefits of not running an extra network. But I don't view this as an urgent task.

2. IPv6 will only be adopted if/when it acquires the warts/features of IPv4 (like NAT)

I believe this follows from the dubious notion that IPv6 has to "replace" IPv4. As long as people think of IPv6 as a drop-in replacement for IPv4, they'll want to solve the problems they had with IPv4 using the same techniques that were used in IPv4. But of course despite the efforts to make IPv6 semi-compatible with IPv4, and to allow it to be used with higher-layer protocols without significant changes, IPv6 is not a drop-in replacement for IPv4 - nor was this even possible to achieve.

An alternative view is that IPv4 has a lot of limitations, both in the original design and in the way it evolved in practice, and there's merit in creating a new kind of network that works differently than IPv4. Many of us believe and/or hope that IPv6 will be more flexible and more universally usable than IPv4. But insisting that IPv6 inherit all of the warts of IPv4 (even while admitting that many of those warts were well-intentioned) is to defeat the utility of IPv6. This isn't a problem if you don't view IPv6 as having to replace IPv4, but instead, as a separate network that has its own characteristics and its own justifications. And precisely because deployment of IPv6 will progress more deliberately than that of IPv4, it will be easier to fix some of IPv6's problems in an architecturally sane fashion than was the case for IPv4.

Note also that the view that IPv6 has to replace IPv4, warts and all, also implicitly assumes that most computers are going to continue to be as they are now - insecure, general-purpose, programmable, relatively immobile (this includes laptops) devices whose primary function is to interface a human to one or more networks of other humans and/or data.

I don't see it this way at all. I believe that in 5-10 years typical Internet hosts will be: mobile phones/pdas, set-top boxes and audio/video terminals with those functions built-in, games, automobiles, power meters, traffic signals, surveillance cameras, door or window sensors, environmental monitors and controls, and transponders of various kinds. These will dwarf desktops in number. Even desktops may change significantly from the bulky, heat-producing, insecure, unreliable, expensive, maintenance-intensive, monopoly-controlled millstones around our necks that they are now. But even if the desktops continue to use IPv4 for traditional apps, that doesn't mean that there's no market for IPv6.

3. ISPs will change IPv6 prefixes arbitrarily

ISPs don't change IPv4 prefixes arbitrarily. Rather, they use this as a means to differentiate between different levels of service. More and more ISPs offer static IPv4 addresses even to "consumer" customers - they just charge more money for it. Some ISPs choose to provide only the lowest level of service, but better levels of service are often available elsewhere. IPv6 might be seen as a higher level of service than IPv4 (and with more cost), just as actual IP access is a higher level of service than you get with some of the "free internet" providers that don't let you make arbitrary IP connections.

To the extent that ISPs have incentives to change customers' IPv4 prefixes due to real or perceived IPv4 address shortages, they'll have fewer incentives to change customers' IPv6 prefixes. As long as there is a demand for stable prefixes, there will be ISPs willing to provide them. And since much of the incentive to employ IPv6 will be to address more devices, stable prefixes will be in wider demand for IPv6 than they were for IPv4.

It's true that IPv6 has the built-in assumption that prefixes will change. This is really no less true for IPv4, given the limits on scalability for current routing mechanisms; the difference is that IPv6 actually has a migration strategy. At any rate, I fully expect prefix changes to be part of service agreements between ISPs and customers.

4. v6 NAT will emerge as the solution to real or perceived limitation of IPv6

For the forseeable future, if you can run your apps over NAT, you'll just use IPv4. Running IPv6+NAT is pointless and self-defeating.

5. The burden of coping with address changes should be on the applications.

This is ridiculous. TCP can't cope with address changes, yet applications based on TCP are somehow expected to cope with address changes.

What we need to do is to draw a line and define the degree to which applications are expected to cope with address changes, and to what degree the network is expected to keep addresses stable. We just need to pick a number - so that if an app needs to maintain a relationship with its peers lasting more than time T, it should be able to cope with address changes. We need to set this value high enough so that most apps don't need to build in the extra overhead required to make this work, and low enough that addresses can change quickly enough for the routing system to keep up with changes in network topology.

6. Apps have to decide whether to use IPv4 or IPv6; this is painful

I believe apps fall into three classes:

1. apps that can use IPv4 or IPv6 with approximately equal ease - usually because there are only two peers involved in the application, and the choice of whether to use IPv4 or IPv6 for one pair of peers is independent of the choice for another pair. for instance, ssh. these apps should use the address that provides the best connectivity. this is little different than picking among several IPv4 addresses.
2. apps that tend toward IPv4 because they need to connect with an IPv4-based infrastructure which biases the choice of IPv4 vs. IPv6 by participating hosts. email and the web are good examples: if you want to be able to receive email, you'd better have an MX accessible via IPv4; if you want to send email to anyone, you'd better have a relay that can send SMTP over IPv4. if you want your web pages to be accessible, you'd better make them accessible via IPv4; if you want your web client to be able to access most web pages, you'd better make sure it at least has access to a proxy that can speak IPv4.
3. apps that tend toward IPv6 either because they need to connect with an IPv6-based infrastructure (e.g. they want to talk to cell phones or special-purpose devices that use v6), or because they need to avoid the limitations of IPv4+NAT.

7. Having IPv6 + IPv4+NAT replace IPv4+NAT isn't very interesting

On the contrary, it provides a MUCH more capable network without having to replace wires and fiber or (most) routers and hosts. IPv6 is the ultimate NAT traversal mechanism - MUCH cleaner and MUCH more flexible than RSIP, MIDCOM, or other hacks, and also extensible to many more networks and many more kinds of applications.

8. Hosts or apps can make effective choices between destination addresses with varying reachabilities

The information needed to make these choices is not available to either hosts or apps. To the extent that such information exists today, it exists only in routing protocols. Neither the host nor the app has any way to know which destination address is best to use without trying to use each of them - a slow and failure-prone process that only yields results that are valid for that particular host and that particular moment. Even if a host can make an effective choice for itself, this does no good if the host needs to use the address in a referral to another host with potentially different connectivity.

Basically we don't know how to make this work. What we need to do is to stop expecting that hosts can have an arbitrary number of addresses with varying reachability. Instead, networks need to minimize the number of addresses assigned to hosts, give them all the same reachability when possible, and when this isn't possible, provide clear cues as to which addresses should be used. We also need to stop expecting addresses to encode access policy.

9. Phenomena that are confined to local networks don't affect the Internet as a whole

Two counterexamples:

1. The effects of RFC 1918 addresses on applications, that now have to cope with ambiguous addresses. See my list of things that NATs break for some examples.
2. The ability of insecure systems, even those behind firewalls, to serve as breeding grounds for worms and viruses that attack remote systems and/or nonlocal portions of the network.