Name, addresses, ports, and routes
RFC 814
|
Document |
Type |
|
RFC - Informational
(July 1982; No errata)
|
|
Authors |
|
|
|
Last updated |
|
2016-04-08
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 814 (Informational)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
RFC: 814
NAME, ADDRESSES, PORTS, AND ROUTES
David D. Clark
MIT Laboratory for Computer Science
Computer Systems and Communications Group
July, 1982
1. Introduction
It has been said that the principal function of an operating system
is to define a number of different names for the same object, so that it
can busy itself keeping track of the relationship between all of the
different names. Network protocols seem to have somewhat the same
characteristic. In TCP/IP, there are several ways of referring to
things. At the human visible interface, there are character string
"names" to identify networks, hosts, and services. Host names are
translated into network "addresses", 32-bit values that identify the
network to which a host is attached, and the location of the host on
that net. Service names are translated into a "port identifier", which
in TCP is a 16-bit value. Finally, addresses are translated into
"routes", which are the sequence of steps a packet must take to reach
the specified addresses. Routes show up explicitly in the form of the
internet routing options, and also implicitly in the address to route
translation tables which all hosts and gateways maintain.
This RFC gives suggestions and guidance for the design of the
tables and algorithms necessary to keep track of these various sorts of
identifiers inside a host implementation of TCP/IP.
2
2. The Scope of the Problem
One of the first questions one can ask about a naming mechanism is
how many names one can expect to encounter. In order to answer this, it
is necessary to know something about the expected maximum size of the
internet. Currently, the internet is fairly small. It contains no more
than 25 active networks, and no more than a few hundred hosts. This
makes it possible to install tables which exhaustively list all of these
elements. However, any implementation undertaken now should be based on
an assumption of a much larger internet. The guidelines currently
recommended are an upper limit of about 1,000 networks. If we imagine
an average number of 25 hosts per net, this would suggest a maximum
number of 25,000 hosts. It is quite unclear whether this host estimate
is high or low, but even if it is off by several factors of two, the
resulting number is still large enough to suggest that current table
management strategies are unacceptable. Some fresh techniques will be
required to deal with the internet of the future.
3. Names
As the previous section suggests, the internet will eventually have
a sufficient number of names that a host cannot have a static table
which provides a translation from every name to its associated address.
There are several reasons other than sheer size why a host would not
wish to have such a table. First, with that many names, we can expect
names to be added and deleted at such a rate that an installer might
spend all his time just revising the table. Second, most of the names
will refer to addresses of machines with which nothing will ever be
3
exchanged. In fact, there may be whole networks with which a particular
host will never have any traffic.
To cope with this large and somewhat dynamic environment, the
internet is moving from its current position in which a single name
table is maintained by the NIC and distributed to all hosts, to a
distributed approach in which each network (or group of networks) is
responsible for maintaining its own names and providing a "name server"
to translate between the names and the addresses in that network. Each
host is assumed to store not a complete set of name-address
translations, but only a cache of recently used names. When a name is
provided by a user for translation to an address, the host will first
examine its local cache, and if the name is not found there, will
communicate with an appropriate name server to obtain the information,
which it may then insert into its cache for future reference.
Unfortunately, the name server mechanism is not totally in place in
the internet yet, so for the moment, it is necessary to continue to use
the old strategy of maintaining a complete table of all names in every
host. Implementors, however, should structure this table in such a way
that it is easy to convert later to a name server approach. In
particular, a reasonable programming strategy would be to make the name
table accessible only through a subroutine interface, rather than by
scattering direct references to the table all through the code. In this
way, it will be possible, at a later date, to replace the subroutine
Show full document text