dubious premises: batch reply to "IPv6 adoption behavior"

[Keith Moore <moore@cs.utk.edu>]

This is one of my batch replies - but this time it's all on a single
thread. I can't claim that this was deliberate - I went out of town for
what was supposed to be a day trip, and was too ill to return for a
couple of days.  When I got back there were several dozen messages in
this thread.

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

- IPv4 will eventually collapse due to address exhaustion, and/or
- IPv4 will at some point become obsolete because of widespread
  adoption of IPv6, and/or
- 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.

- 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. 

- 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.

- v6 NAT will emerge as the solution to <whatever> 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.

- 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.

- 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.

so I'll assert that for the first category of apps, choosing between
IPv4 and IPv6 is just a slight variation on an old problem; and for
the second two categories of apps there is a definite and fairly
obvious preference between IPv4 and IPv6.  the only wrinkle is that at
some point in the future, some of the category 2 apps might need to
move to category 3, and it might be useful to have a mechanism to 
tell them to do so.

- 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.

-- Keith


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------