Dave Crocker wrote:
On Sat, 06 Nov 2004 09:53:00 +0100, Harald Tveit Alvestrand wrote:
So the death of IPv4 isn't going to happen with a bang. More like
a protracted series of whimpers
One of the great dangers of having a history of success is the way it
blinds us to new ways to fail.
In the case of IP addressing evolution, the blindness is that our
community presumes that transition to IPv6 is inevitable.
A transition away from IPv4 is inevitable. The next stop in the evolutionary
path will be determined by available alternatives. The IETF chose IPv6 from
the set of proposals on hand. The market will choose something else if the
IETF doesn't get serious about focusing all effort in that direction.
Hence, we
have done a very poor job of providing compelling benefits for users
and admins.
Which is why I have been after the Applications Area to wake up and
recognize that the wasted effort that goes into the random nat traversal
schemes is not leaving time to do the necessary work focused on IPv6.
We have a grand promise -- and frankly it often sounds a
lot more like religious fervor -- about eventual benefits, but no
claim of immediate benefit that grabs operations folks by their gut,
driving them to adopt this change.
Addressing is plumbing and nobody cares besides the network operator.
Applications are the driver that pull technologies along for the ride. Until
the apps community decides that continuing to put energy into a dead end
technology is a bad idea, we will be stuck on the current path with no
compelling driver for change.
By way of noting one possible scanario that builds on today's reality
and leads down a path that never adopts IPv6, I'll ask:
What if users turned all leaf networks into private address space,
so
that public IPv4 numbers were needed only at the level of roughly 1
per public interface?
This is happening due to lack of choice. Network operators are finding that
their support costs are going up due to app breakage and that it is
impossible to offer service guarantees when someone else owns the nat
component of the infrastructure.
This is, of course, the ultimate breakage of the end-to-end addressing
model, but we tend to forget that the model is something rather
esoteric to non-protocol geeks.
You say this as if the model were the goal. The goal is simplicity that is a
direct output of the model.
We already must modify the architecture to deal with a much richer
range of border policies than just differential routing. Having it
include partitioned address space is a pretty obvious step, given how
often we already are faced with that reality.
Talk about blindness. Has ten years of nat deployment lead to the perception
that it is just a minor annoyance that has to be dealt with? Yes we have to
deal with rich border policies, but that is not really a new requirement.
The U.S. National Labs were implementing whatever the technology of the day
allowed 15 years ago, but their policies at the time were not much different
than the Dentist office today. Differing policies was the root of most of
the inter-agency discussions about topology before the commercialization
phase.
At the least, it means we had better have an end-to-end reference
(identification) construct that is a) separate from IP Address, and b)
works fine over IPv4. To this end, work like Opes and the
architectural aspects of multi6 might be rather more strategic than we
have been acknowledging.
Opes has potential for both mitigating some of the harder problems, and/or
being a way to trivially subvert system integrity. Lacking a real global
trust infrastructure people have piled the trust issue on the routing system
through the address token. The simple act of creating alternative endpoint
tokens does not automatically move all the trust assumptions. What basis
will people have to trust Opes.
Multi6 is a worthwhile strategic effort, but the proposals on the table
represent an even greater change to the fundamental architecture than simply
changing the address length of IPv6. As such it will not really be
deployable before 2020, and that is if the array of research efforts can be
focused down to a single proposal soon.
The problem is that we failed to evolve IP in a timely manner and in a
way that was really convenient for real administrators.
Some of us knew and discussed going in that it would be a 10 year effort to
make a change of this magnitude. Bickering over attempts to tell the
operations community how to run their networks has slowed things down, but
deployments are happening around the world and given product availability
could easily accelerate with the arrival of compelling applications.
Instead we
took the approach that this needed to be done as a major system shift
and that "we would only get one shot at this change", so we also
loaded quite a bit of baggage into the package. And now we try to
characterize the minimal deployment of IPv6 as if it represented
success.
One of the biggest problems is using the current measures of IPv4 deployment
to gauge IPv6 success. This is more indicative of the IETF's blindness than
anything else. Given the current allocation policies the routing system will
never see the massive bloat we see today (those policies are likely to
change over time though). 'Demand' for blue-plumbing instead of red-plumbing
should never happen because the end user of the network should never see it
or care. The measure we should be looking toward is application availability
and use. To a large degree the app development community is being misled by
the IETF's continued efforts at squeezing the last address out of a system
we have long since outgrown.
Or perhaps the real problem was that what has been happening with
NATs, et al, is fine but we that have preferred to tout our idealized
solution and ignored market pragmatics.
Market pragmatics of the last few years said the world couldn't wait for the
IETF to get its act together and expand the available space. Market
pragmatics going forward are more likely to say that nats create an
unnecessary expense, both in the cost of the development armies working on
traversal hacks and as the source of operational confusion leading to more
support calls. Granted I am called in to talk to people already interested
in/asking about IPv6, but those are the two points that keep coming up in
the market place today.
Please forgive me for noting that this kind of error is classic among
organizations that have had major successes and, therefore, believe
that their internal intelligence is greater than that of the markets.
A small variation on this error is when it is from the aggregation of
successful companies. The obvious example is OSI.
Yes the IETF as a whole is blinded by the success of IPv4. Yes there are
participants that want to tell the world how to run their networks. At the
same time, there are others who are interested in simply defining the growth
path and as Harald said, '... make sure the thing we have defined is
well-defined enough to let it work, and then get the hell out of the way.'
The plumbing pieces are well defined. The deployment technologies are
defined, though several are blocked from publication by those who don't want
to 'get out of the way'. The 'internal intelligence' of the collective
recent IESG membership has created a road block for deployment technologies
that don't fit their model of how people should be running networks. The
real pieces that are lacking in the IETF output are in the application
space. As Brian noted, work is going on now to address the market
perceptions about what nat does and how to accomplish the same tasks in IPv6
without nat. This is nowhere near enough to help the world of application
developers understand how to create-in and/or port-to an IPv6 environment.
As Harald also said, 'Frankly, folks, IPv4 is what IBM used to call
"functionally stabilized".' This means there is no reason for the IETF to
focus any effort on standardizing new functionality around it. This was the
basis for my comment about closing down IPv4 related discussions during his
term. Yes there will be new IPv4 based product and service developments in
the market for years to come. That is both due to training of the existing
developers and operators as well as the fundamental need to leverage the
vast existing environment. Those product and service developers do not need
any new output from the IETF to create their wares. At the same time they
will need output from somewhere to move beyond the limitations of that
existing environment. The IETF has a choice, it can either make its earlier
IPv6 choice the default for all current work, or it can become irrelevant
when someone else provides a replacement for the 'past its prime' workhorse
of IPv4. This is simple market pragmatics, no religion required.
Tony
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf