Network Working Group B. Carpenter, Editor
Request for Comments: 1958 IAB
Category: Informational June 1996 Architectural Principles of the Internet
Status of This Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
The Internet and its architecture have grown in evolutionary fashion
from modest beginnings, rather than from a Grand Plan. While this
process of evolution is one of the main reasons for the technology's
success, it nevertheless seems useful to record a snapshot of the
current principles of the Internet architecture. This is intended for
general guidance and general interest, and is in no way intended to
be a formal or invariant reference model.
Table of Contents
1. Constant Change..............................................12. Is there an Internet Architecture?...........................23. General Design Issues........................................44. Name and address issues......................................55. External Issues..............................................66. Related to Confidentiality and Authentication................6
Editor's Address................................................81. Constant Change
In searching for Internet architectural principles, we must remember
that technical change is continuous in the information technology
industry. The Internet reflects this. Over the 25 years since the
ARPANET started, various measures of the size of the Internet have
increased by factors between 1000 (backbone speed) and 1000000
(number of hosts). In this environment, some architectural principles
inevitably change. Principles that seemed inviolable a few years ago
are deprecated today. Principles that seem sacred today will be
deprecated tomorrow. The principle of constant change is perhaps the
only principle of the Internet that should survive indefinitely.
The purpose of this document is not, therefore, to lay down dogma
about how Internet protocols should be designed, or even about how
they should fit together. Rather, it is to convey various guidelines
that have been found useful in the past, and that may be useful to
those designing new protocols or evaluating such designs.
A good analogy for the development of the Internet is that of
constantly renewing the individual streets and buildings of a city,
rather than razing the city and rebuilding it. The architectural
principles therefore aim to provide a framework for creating
cooperation and standards, as a small "spanning set" of rules that
generates a large, varied and evolving space of technology.
Some current technical triggers for change include the limits to the
scaling of IPv4, the fact that gigabit/second networks and multimedia
present fundamentally new challenges, and the need for quality of
service and security guarantees in the commercial Internet.
As Lord Kelvin stated in 1895, "Heavier-than-air flying machines are
impossible." We would be foolish to imagine that the principles
listed below are more than a snapshot of our current understanding.
2. Is there an Internet Architecture?
2.1 Many members of the Internet community would argue that there is
no architecture, but only a tradition, which was not written down for
the first 25 years (or at least not by the IAB). However, in very
general terms, the community believes that the goal is connectivity,
the tool is the Internet Protocol, and the intelligence is end to end
rather than hidden in the network.
The current exponential growth of the network seems to show that
connectivity is its own reward, and is more valuable than any
individual application such as mail or the World-Wide Web. This
connectivity requires technical cooperation between service
providers, and flourishes in the increasingly liberal and competitive
commercial telecommunications environment.
The key to global connectivity is the inter-networking layer. The
key to exploiting this layer over diverse hardware providing global
connectivity is the "end to end argument".
2.2 It is generally felt that in an ideal situation there should be
one, and only one, protocol at the Internet level. This allows for
uniform and relatively seamless operations in a competitive, multi-
vendor, multi-provider public network. There can of course be
multiple protocols to satisfy different requirements at other levels,
and there are many successful examples of large private networks with
multiple network layer protocols in use.
In practice, there are at least two reasons why more than one network
layer protocol might be in use on the public Internet. Firstly, there
can be a need for gradual transition from one version of IP to
another. Secondly, fundamentally new requirements might lead to a
fundamentally new protocol.
The Internet level protocol must be independent of the hardware
medium and hardware addressing. This approach allows the Internet to
exploit any new digital transmission technology of any kind, and to
decouple its addressing mechanisms from the hardware. It allows the
Internet to be the easy way to interconect fundamentally different
transmission media, and to offer a single platform for a wide variety
of Information Infrastructure applications and services. There is a
good exposition of this model, and other important fundemental
issues, in [Clark].
2.3 It is also generally felt that end-to-end functions can best be
realised by end-to-end protocols.
The end-to-end argument is discussed in depth in [Saltzer]. The
basic argument is that, as a first principle, certain required end-
to-end functions can only be performed correctly by the end-systems
themselves. A specific case is that any network, however carefully
designed, will be subject to failures of transmission at some
statistically determined rate. The best way to cope with this is to
accept it, and give responsibility for the integrity of communication
to the end systems. Another specific case is end-to-end security.
To quote from [Saltzer], "The function in question can completely and
correctly be implemented only with the knowledge and help of the
application standing at the endpoints of the communication system.
Therefore, providing that questioned function as a feature of the
communication system itself is not possible. (Sometimes an incomplete
version of the function provided by the communication system may be
useful as a performance enhancement.")
This principle has important consequences if we require applications
to survive partial network failures. An end-to-end protocol design
should not rely on the maintenance of state (i.e. information about
the state of the end-to-end communication) inside the network. Such
state should be maintained only in the endpoints, in such a way that
the state can only be destroyed when the endpoint itself breaks
(known as fate-sharing). An immediate consequence of this is that
datagrams are better than classical virtual circuits. The network's
job is to transmit datagrams as efficiently and flexibly as possible.
6.4 In choosing algorithms, the algorithm should be one which is
widely regarded as strong enough to serve the purpose. Among
alternatives all of which are strong enough, preference should be
given to algorithms which have stood the test of time and which are
not unnecessarily inefficient.
6.5 To ensure interoperation between endpoints making use of security
services, one algorithm (or suite of algorithms) should be mandated
to ensure the ability to negotiate a secure context between
implementations. Without this, implementations might otherwise not
have an algorithm in common and not be able to communicate securely.
This document is a collective work of the Internet community,
published by the Internet Architecture Board. Special thanks to Fred
Baker, Noel Chiappa, Donald Eastlake, Frank Kastenholz, Neal
McBurnett, Masataka Ohta, Jeff Schiller and Lansing Sloan.
Note that the references have been deliberately limited to two
fundamental papers on the Internet architecture.
[Clark] The Design Philosophy of the DARPA Internet Protocols,
D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988,
pages 106-114 (reprinted in ACM CCR Vol 25, Number 1, January 1995,
[Saltzer] End-To-End Arguments in System Design, J.H. Saltzer,
D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp
Security issues are discussed throughout this memo.
Brian E. Carpenter
Group Leader, Communications Systems
Computing and Networks Division
European Laboratory for Particle Physics
1211 Geneva 23, Switzerland
Phone: +41 22 767-4967
Fax: +41 22 767-7155