Name, addresses, ports, and routes
RFC 814

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

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