ISP Column - November 2003
t the Internet Archive.
Yahoo! is not affiliated with the authors of this page or responsible for its content.
ISP Column - November 2003
The ISP Column
An occasional column on things Internet
January 2006
Geoff Huston
IPv6 Evolution or Revolution?
For some years now the general uptake of IPv6 has appeared to be just around the corner. Yet the Internet industry has
so far failed to pick up and run with this message, and it continues to be strongly reluctant to make any substantial
widespread commitment to deploy IPv6. Some carriers are now making some initial moves in terms off migrating their
internet infrastructure over to a dual protocol network, but for many others its a case of still watching and waiting for
what they think is the optimum time to make a move.
So when should we be deploying IPv6 services? At what point will the business case for IPv6 have a positive bottom line?
Its a tough question to answer, and while advice of sometime, probably sooner than later is certainly not wrong, its
also entirely unhelpful as well!
Im not sure that anyone can provide a clearer date in response to that question, but what may be useful is to explore
why IPv6 will be useful to have sometime in the near term future and how IPv6 and IPv4 are likely to interact. And then
the when of IPv6 may be a little clearer or maybe not!
To start off with this exploration it may be useful to compare where we started with the Internet with where we are
today, and then see how this relates to the IPv6 story.
The Evolution of the Internet Architecture
The original architectural model for IP was in many respects a very simple model, but also one that was very powerful.
Perhaps, in the spirit of William of Occam, the true strength of IP lay in what had been deliberately omitted from the
specification, leaving in the form of the Internet a relatively simple and straightforward packet switching architecture.
William of Occam, (1285-1349), English philosopher and scholastic theologian. Occam
was born in Surrey, England. He entered the Franciscan order and studied and taught
at the University of Oxford from 1309 to 1319. Denounced by Pope John XXII for
dangerous teachings, he was held in house detention for four years (1324-28) at the
papal palace in Avignon, France, while the orthodoxy of his writings was examined.
Siding with the Franciscan general against the pope in a dispute over Franciscan
poverty, Occam fled to Munich in 1328 to seek the protection of Louis IV, Holy Roman
emperor, who had rejected papal authority over political matters. Excommunicated
by the pope, Occam wrote against the papacy and defended the emperor until the
latter's death in 1347. The philosopher died in Munich, apparently of the plague, while
seeking reconciliation with Pope Clement VI.
Page 2
Occam's Razor, Pluralitas non est ponenda sine necessitate", has become a basic
principle in science and philosophy, stating that entities should not be multiplied
needlessly. This principle underlies all scientific modelling and theory building. In any
given model Occam's Razor helps to cut away those concepts, variables or constructs
that are not really needed to explain the phenomenon. Through such a process there
is less chance of introducing inconsistencies, ambiguities and redundancies.
The network implemented an unreliable datagram delivery service. Each datagram (or packet), had information
describing its source and intended destination. Each network switch (or router), either moved the packet closer to where it
believed the destination was located, or it just dropped the packet. In the latter case the switch may send a control
notification packet back to the sender, depending on the reasons for the drop. All the functionality that created various
transport services, functionality to support mapping of application-level endpoint names to network addresses, and
functionality to distribute available network resources across competing applications resided within the end systems
rather than the network. For a network it really doesnt get much simpler than this.
But if you were to look for a faithful implementation of this simple architecture in todays Internet networks youll be
somewhat disappointed. The concept of single packet forwarding plane, with a single addressing model spanning the
entire network, and a uniform end-to-end transport level congestion control model, has largely disappeared from most
production networks, and the basic concept of end-to-end is now perhaps more of an item of historic interest than a
current pillar of networking architecture. These days carrier internet networks come replete with multiple forwarding
layers, thanks to MPLS, numerous active network elements, including firewalls NATs and application layer gateways,
various forms of NAT traversal agents and of course application level gateways and application level switches, load
balancers, dynamic application switches and various forms of context-sensitive dynamic environments. We also have
various forms of resiliency mechanisms, including path diversity elements, resource management systems, and QoS
response systems. We have active Distributed Denial of Service (DDOS) detection elements embedded in the network and
even network level session and application tracking systems as one more level of network defence against the ever-
escalating security problem. This is no longer anything remotely similar to the concept of a simple unreliable datagram
delivery service, and if you are looking for a simple dumb network with smart edges then you wont find it in production
Internets.
What happened to the original Internet model? What was so wrong with a model of data communications that placed
most of the functionality of the network into the devices themselves, and cast the network into a role of best effort
packet switching? One sneaking suspicion is that the data communications industry itself, or at least the carrier part of
the industry, is resisting this path to network simplicity, and in their continual quest to wring out every drop of value out
of their networks the carrier ISP sector continues to be seduced by feature-packed network services that are intended to
offer their customer higher value network solutions. Another way of looking at this role is that the carrier industry is
hooked on the complexity business, and has embarked on a business model of creating networking systems that are
sufficiently complex that customers are supposed to baulk at doing it themselves. After all any construction enterprise
can hang wire on poles, bury wire in the ground, or drop wire to the bottom on the sea. The highly complex operation of
the resultant network is supposedly the unique value-adding role of the carrier enterprise. Of course this complexity
escalation works only as long as the solutions are not so complex that the carriers themselves start to baulk as well! As a
carrier industry we may have already crossed this particular complexity line, and we may have already managed to
create a technology environment that is sufficiently complex that no player, not even the carrier, is able to manage the
resultant interwoven mesh of disparate systems that make up a carrier Internet platform.
The question in my mind when looking at this rapid progression from architectural simplicity into often mind-boggling,
and doubtless eye-wateringly expensive complexity for Internet networks is whether this is the outcome of a disordered
process of entropy or one of a more ordered and directed process of evolution of the Internet?
The case for entropy is certainly very strong. What is evident is that the internet is besieged by various forms of local
optimizations that intentionally alter the behaviour of parts of the network to suit the desired characteristics of certain
classes of application. Such incremental local actions tend to impose a cost on the entire system. Whether the issue is
one of adding network level support for mobility, support for various forms of address compression, support for
Page 3
differentiated service outcomes, resilience against various forms of hostile attack, or various forms of enhanced service
availability, the typical outcome is one of increased network complexity and increased network cost with increasingly
marginal returns in terms of overall service capability. This is a drive to disorder and decay in that local changes are not
uniformly adopted, and the network itself starts to alter its overall state from uniform simple order into visible chaotic
disorder.
Of course it is also possible to view this change process as one of evolution, where an active system is under constant
pressure to adapt in order to survive and thrive in a changing environment. Theres no obviously intelligent design here,
and the overall evolutionary process follows no particular planned path. The outcomes are often chaotic and invariably
unpredictable, but within the process is a driving discipline of a competitive environment where service providers are
constantly challenged to adapt