rfc814.txt

RFC 相关的技术文档

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

with one capable of making calls on remote name servers.


     A  problem  which  occasionally arises in the ARPANET today is that

                                   4


the information in a local host table is out of date, because a host has

moved,  and a revision of the host table has not yet been installed from

the NIC.  In this case, one attempts to connect to a particular host and

discovers an unexpected machine at the address obtained from  the  local

table.    If  a  human is directly observing the connection attempt, the

error  is  usually  detected  immediately.    However,  for   unattended

operations  such as the sending of queued mail, this sort of problem can

lead to a great deal of confusion.


     The nameserver scheme will only make this problem worse,  if  hosts

cache  locally  the  address associated with names that have been looked

up, because the host has no way of knowing when the address has  changed

and the cache entry should be removed.  To solve this problem, plans are

currently  under  way  to  define  a simple facility by which a host can

query a foreign address to determine what name  is  actually  associated

with  it.    SMTP already defines a verification technique based on this

approach.


     4.  Addresses


     The IP layer must know something about addresses.   In  particular,

when  a datagram is being sent out from a host, the IP layer must decide

where to send it on the immediately  connected  network,  based  on  the

internet address.  Mechanically, the IP first tests the internet address

to  see  whether  the network number of the recipient is the same as the

network number of the sender.  If so, the packet can be sent directly to

the final recipient.  If not, the datagram must be sent to a gateway for

further forwarding.  In this latter case,  a  second  decision  must  be

                                   5


made, as there may be more than one gateway available on the immediately

attached network.


     When  the  internet address format was first specified, 8 bits were

reserved  to  identify  the  network.     Early   implementations   thus

implemented  the  above  algorithm by means of a table with 256 entries,

one for each possible net, that specified the gateway of choice for that

net, with a special case entry for those nets  to  which  the  host  was

immediately connected.  Such tables were sometimes statically filled in,

which caused confusion and malfunctions when gateways and networks moved

(or crashed).


     The  current  definition  of  the  internet  address provides three

different options for network numbering, with the  goal  of  allowing  a

very  large  number of networks to be part of the internet.  Thus, it is

no longer possible to imagine having an exhaustive  table  to  select  a

gateway  for any foreign net.  Again, current implementations must use a

strategy based on a local cache of  routing  information  for  addresses

currently being used.


     The  recommended  strategy  for  address to route translation is as

follows.    When  the  IP  layer  receives  an  outbound  datagram   for

transmission,  it  extracts  the  network  number  from  the destination

address, and queries its local table to determine  whether  it  knows  a

suitable  gateway to which to send the datagram.  If it does, the job is

done.    (But  see  RFC  816  on  Fault  Isolation  and  Recovery,   for

recommendations  on  how  to  deal  with  the  possible  failure  of the

gateway.)  If there is no such entry in the local table, then select any

                                   6


accessible  gateway at random, insert that as an entry in the table, and

use it to send the packet.  Either the guess will be right or wrong.  If

it is wrong, the gateway to which the packet was  sent  will  return  an

ICMP  redirect message to report that there is a better gateway to reach

the net in question.  The arrival  of  this  redirect  should  cause  an

update of the local table.


     The  number  of  entries in the local table should be determined by

the maximum number of active connections which this particular host  can

support  at  any  one  time.  For a large time sharing system, one might

imagine a table with 100 or more entries.  For a personal computer being

used to support a single user telnet connection,  only  one  address  to

gateway association need be maintained at once.


     The  above strategy actually does not completely solve the problem,

but only pushes it down one level, where the problem then arises of  how

a  new  host,  freshly  arriving  on  the  internet,  finds  all  of its

accessible gateways.  Intentionally, this problem is not  solved  within

the  internetwork  architecture.   The reason is that different networks

have drastically different strategies for allowing a host  to  find  out

about  other  hosts  on  its  immediate  network.    Some  nets permit a

broadcast mechanism.  In this case, a host can send out  a  message  and

expect  an  answer  back  from  all  of the attached gateways.  In other

cases, where a particular network  is  richly  provided  with  tools  to

support  the  internet, there may be a special network mechanism which a

host can invoke to determine where the gateways are.  In other cases, it

may be necessary for an installer to manually provide  the  name  of  at

                                   7


least  one  accessible  gateway.  Once a host has discovered the name of

one gateway, it can build up a table of all other available gateways, by

keeping track of every gateway that has been reported back to it  in  an

ICMP message.


     5.  Advanced Topics in Addressing and Routing


     The  preceding  discussion  describes  the  mechanism required in a

minimal implementation,  an  implementation  intended  only  to  provide

operational  service  access  today to the various networks that make up

the internet.  For any host which will participate in  future  research,

as  contrasted  with  service,  some  additional  features are required.

These features will also be helpful for service hosts if  they  wish  to

obtain access to some of the more exotic networks which will become part

of  the internet over the next few years.  All implementors are urged to

at least provide a structure into which these features  could  be  later

integrated.


     There   are   several  features,  either  already  a  part  of  the

architecture or now under development,  which  are  used  to  modify  or

expand  the  relationships  between addresses and routes.  The IP source

route options allow a host to explicitly direct  a  datagram  through  a

series of gateways to its foreign host.  An alternative form of the ICMP

redirect  packet  has  been  proposed,  which  would  return information

specific to a  particular  destination  host,  not  a  destination  net.