Movatterモバイル変換

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 systemis to define a number of different names for the same object, so that itcan  busy  itself  keeping  track of the relationship between all of thedifferent names.  Network protocols  seem  to  have  somewhat  the  samecharacteristic.    In  TCP/IP,  there  are  several ways of referring tothings.  At the human visible  interface,  there  are  character  string"names"  to  identify  networks,  hosts,  and  services.  Host names aretranslated into network "addresses", 32-bit  values  that  identify  thenetwork  to  which  a  host is attached, and the location of the host onthat net.  Service names are translated into a "port identifier",  whichin  TCP  is  a  16-bit  value.    Finally, addresses are translated into"routes", which are the sequence of steps a packet must  take  to  reachthe  specified  addresses.  Routes show up explicitly in the form of theinternet routing options, and also implicitly in the  address  to  routetranslation tables which all hosts and gateways maintain.     This  RFC  gives  suggestions  and  guidance  for the design of thetables and algorithms necessary to keep track of these various sorts  ofidentifiers 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 ishow many names one can expect to encounter.  In order to answer this, itis necessary to know something about the expected maximum  size  of  theinternet.  Currently, the internet is fairly small.  It contains no morethan  25  active  networks,  and no more than a few hundred hosts.  Thismakes it possible to install tables which exhaustively list all of theseelements.  However, any implementation undertaken now should be based onan assumption of a much  larger  internet.    The  guidelines  currentlyrecommended  are  an upper limit of about 1,000 networks.  If we imaginean average number of 25 hosts per net,  this  would  suggest  a  maximumnumber  of 25,000 hosts.  It is quite unclear whether this host estimateis high or low, but even if it is off by several  factors  of  two,  theresulting  number  is  still  large enough to suggest that current tablemanagement strategies are unacceptable.  Some fresh techniques  will  berequired to deal with the internet of the future.     3.  Names     As the previous section suggests, the internet will eventually havea  sufficient  number  of  names  that a host cannot have a static tablewhich provides a translation from every name to its associated  address.There  are  several  reasons  other than sheer size why a host would notwish to have such a table.  First, with that many names, we  can  expectnames  to  be  added  and deleted at such a rate that an installer mightspend all his time just revising the table.  Second, most of  the  nameswill  refer  to  addresses  of  machines with which nothing will ever be

                                   3exchanged.  In fact, there may be whole networks with which a particularhost will never have any traffic.     To  cope  with  this  large  and  somewhat dynamic environment, theinternet is moving from its current position  in  which  a  single  nametable  is  maintained  by  the  NIC  and  distributed to all hosts, to adistributed approach in which each network (or  group  of  networks)  isresponsible  for maintaining its own names and providing a "name server"to translate between the names and the addresses in that network.   Eachhost   is   assumed   to  store  not  a  complete  set  of  name-addresstranslations, but only a cache of recently used names.  When a  name  isprovided  by  a  user for translation to an address, the host will firstexamine its local cache, and if  the  name  is  not  found  there,  willcommunicate  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 inthe internet yet, so for the moment, it is necessary to continue to  usethe  old  strategy of maintaining a complete table of all names in everyhost.  Implementors, however, should structure this table in such a  waythat  it  is  easy  to  convert  later  to  a  name server approach.  Inparticular, a reasonable programming strategy would be to make the  nametable  accessible  only  through  a subroutine interface, rather than byscattering direct references to the table all through the code.  In thisway, it will be possible, at a later date,  to  replace  the  subroutinewith one capable of making calls on remote name servers.     A  problem  which  occasionally arises in the ARPANET today is that

                                   4the information in a local host table is out of date, because a host hasmoved,  and a revision of the host table has not yet been installed fromthe NIC.  In this case, one attempts to connect to a particular host anddiscovers an unexpected machine at the address obtained from  the  localtable.    If  a  human is directly observing the connection attempt, theerror  is  usually  detected  immediately.    However,  for   unattendedoperations  such as the sending of queued mail, this sort of problem canlead to a great deal of confusion.     The nameserver scheme will only make this problem worse,  if  hostscache  locally  the  address associated with names that have been lookedup, because the host has no way of knowing when the address has  changedand the cache entry should be removed.  To solve this problem, plans arecurrently  under  way  to  define  a simple facility by which a host canquery a foreign address to determine what name  is  actually  associatedwith  it.    SMTP already defines a verification technique based on thisapproach.     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 decidewhere to send it on the immediately  connected  network,  based  on  theinternet address.  Mechanically, the IP first tests the internet addressto  see  whether  the network number of the recipient is the same as thenetwork number of the sender.  If so, the packet can be sent directly tothe final recipient.  If not, the datagram must be sent to a gateway forfurther forwarding.  In this latter case,  a  second  decision  must  be

                                   5made, as there may be more than one gateway available on the immediatelyattached network.     When  the  internet address format was first specified, 8 bits werereserved  to  identify  the  network.     Early   implementations   thusimplemented  the  above  algorithm by means of a table with 256 entries,one for each possible net, that specified the gateway of choice for thatnet, with a special case entry for those nets  to  which  the  host  wasimmediately 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 threedifferent options for network numbering, with the  goal  of  allowing  avery  large  number of networks to be part of the internet.  Thus, it isno longer possible to imagine having an exhaustive  table  to  select  agateway  for any foreign net.  Again, current implementations must use astrategy based on a local cache of  routing  information  for  addressescurrently being used.     The  recommended  strategy  for  address to route translation is asfollows.    When  the  IP  layer  receives  an  outbound  datagram   fortransmission,  it  extracts  the  network  number  from  the destinationaddress, and queries its local table to determine  whether  it  knows  asuitable  gateway to which to send the datagram.  If it does, the job isdone.    (But  see  RFC  816  on  Fault  Isolation  and  Recovery,   forrecommendations  on  how  to  deal  with  the  possible  failure  of thegateway.)  If there is no such entry in the local table, then select any

                                   6accessible  gateway at random, insert that as an entry in the table, anduse it to send the packet.  Either the guess will be right or wrong.  Ifit is wrong, the gateway to which the packet was  sent  will  return  anICMP  redirect message to report that there is a better gateway to reachthe net in question.  The arrival  of  this  redirect  should  cause  anupdate of the local table.     The  number  of  entries in the local table should be determined bythe maximum number of active connections which this particular host  cansupport  at  any  one  time.  For a large time sharing system, one mightimagine a table with 100 or more entries.  For a personal computer beingused to support a single user telnet connection,  only  one  address  togateway 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  howa  new  host,  freshly  arriving  on  the  internet,  finds  all  of itsaccessible gateways.  Intentionally, this problem is not  solved  withinthe  internetwork  architecture.   The reason is that different networkshave drastically different strategies for allowing a host  to  find  outabout  other  hosts  on  its  immediate  network.    Some  nets permit abroadcast mechanism.  In this case, a host can send out  a  message  andexpect  an  answer  back  from  all  of the attached gateways.  In othercases, where a particular network  is  richly  provided  with  tools  tosupport  the  internet, there may be a special network mechanism which ahost can invoke to determine where the gateways are.  In other cases, itmay be necessary for an installer to manually provide  the  name  of  at

                                   7least  one  accessible  gateway.  Once a host has discovered the name ofone gateway, it can build up a table of all other available gateways, bykeeping track of every gateway that has been reported back to it  in  anICMP message.     5.  Advanced Topics in Addressing and Routing     The  preceding  discussion  describes  the  mechanism required in aminimal implementation,  an  implementation  intended  only  to  provideoperational  service  access  today to the various networks that make upthe 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  toobtain access to some of the more exotic networks which will become partof  the internet over the next few years.  All implementors are urged toat least provide a structure into which these features  could  be  laterintegrated.     There   are   several  features,  either  already  a  part  of  thearchitecture or now under development,  which  are  used  to  modify  orexpand  the  relationships  between addresses and routes.  The IP sourceroute options allow a host to explicitly direct  a  datagram  through  aseries of gateways to its foreign host.  An alternative form of the ICMPredirect  packet  has  been  proposed,  which  would  return informationspecific to a  particular  destination  host,  not  a  destination  net.Finally, additional IP options have been proposed to identify particularroutes  within  the internet that are unacceptable.  The difficulty withimplementing these new features  is  that  the  mechanisms  do  not  lie

                                   8entirely within the bounds of IP.  All the mechanisms above are designedto apply to a particular connection, so that their use must be specifiedat  the  TCP level.  Thus, the interface between IP and the layers aboveit must include mechanisms to allow passing this  information  back  andforth,  and TCP (or any other protocol at this level, such as UDP), mustbe prepared to store this  information.    The  passing  of  informationbetween IP and TCP is made more complicated by the fact that some of theinformation,  in  particular  ICMP packets, may arrive at any time.  Thenormal interface envisioned between TCP  and  IP  is  one  across  whichpackets  can  be  sent  or received.  The existence of asynchronous ICMPmessages implies that there must be an additional  channel  between  thetwo,  unrelated  to the actual sending and receiving of data.  (In fact,there are many other ICMP messages which arrive asynchronously and whichmust be passed from IP  up  to  higher  layers.    See  RFC  816,  FaultIsolation and Recovery.)     Source  routes  are  already  in  use  in  the  internet,  and manyimplementations will wish to be able to take advantage  of  them.    Thefollowing  sorts  of  usages  should  be permitted.  First, a user, wheninitiating a TCP connection, should be able to hand a source route  intoTCP,  which in turn must hand the source route to IP with every outgoingdatagram.  The user might initially obtain the source route by  queryinga  different  sort  of  name  server,  which would return a source routeinstead of an address, or the user may have fabricated the source  routemanually.    A  TCP  which  is  listening  for a connection, rather thanattempting to open one, must be prepared to  receive  a  datagram  whichcontains  a  IP return route, in which case it must remember this returnroute, and use it as a source route on all returning datagrams.

                                   9     6.  Ports and Service Identifiers     The  IP  layer of the architecture contains the address informationwhich specifies the destination host to  which  the  datagram  is  beingsent.    In  fact, datagrams are not intended just for particular hosts,but for particular agents within a host,  processes  or  other  entitiesthat  are  the  actual  source and sink of the data.  IP performs only avery simple dispatching once the datagram  has  arrived  at  the  targethost,   it   dispatches  it  to  a  particular  protocol.    It  is  theresponsibility of that protocol handler,  for  example  TCP,  to  finishdispatching  the  datagram  to the particular connection for which it isdestined.    This  next  layer  of  dispatching  is  done  using   "portidentifiers",  which  are  a  part  of  the  header  of the higher levelprotocol, and not the IP layer.     This two-layer dispatching architecture has caused  a  problem  forcertain  implementations.    In  particular,  some  implementations havewished to put the IP layer within the kernel of  the  operating  system,and  the  TCP  layer  as  a  user  domain  application  program.  Strictadherence to this partitioning can lead to grave  performance  problems,for  the  datagram  must  first  be  dispatched from the kernel to a TCPprocess, which then dispatches the datagram  to  its  final  destinationprocess.   The overhead of scheduling this dispatch process can severelylimit the achievable throughput of the implementation.     As is discussed inRFC 817, Modularity and Efficiency  in  ProtocolImplementations,  this  particular  separation  between  kernel and userleads to other performance problems, even ignoring  the  issue  of  port

                                   10level  dispatching.   However, there is an acceptable shortcut which canbe taken to move the higher  level  dispatching  function  into  the  IPlayer, if this makes the implementation substantially easier.     In  principle,  every  higher level protocol could have a differentdispatching  algorithm.    The  reason  for  this  is  discussed  below.However,  for  the  protocols  involved  in  the  service offering beingimplemented today, TCP and UDP, the dispatching algorithm is exactly thesame, and the port field is located in precisely the same place  in  theheader.  Therefore, unless one is interested in participating in furtherprotocol  research,  there  is only one higher level dispatch algorithm.This algorithm takes into account the internet  level  foreign  address,the protocol number, and the local port and foreign port from the higherlevel  protocol  header.  This algorithm can be implemented as a sort ofadjunct to the IP layer implementation, as long as no other higher levelprotocols are to be implemented.  (Actually, the above statement is onlypartially true, in that the UDP dispatch function is subset of  the  TCPdispatch  function.  UDP dispatch depends only protocol number and localport.  However, there is an occasion within TCP  when  this  exact  samesubset comes into play, when a process wishes to listen for a connectionfrom  any  foreign  host.    Thus,  the range of mechanisms necessary tosupport TCP dispatch are also sufficient to support  precisely  the  UDPrequirement.)     The decision to remove port level dispatching from IP to the higherlevel  protocol  has  been questioned by some implementors.  It has beenargued that if all of the address structure were part of the  IP  layer,

                                   11then IP could do all of the packet dispatching function within the host,which  would  lead  to  a  simpler  modularity.    Three  problems  wereidentified with this.  First, not all protocol implementors could  agreeon  the  size  of the port identifier.  TCP selected a fairly short portidentifier, 16 bits, to reduce  header  size.    Other  protocols  beingdesigned,  however, wanted a larger port identifier, perhaps 32 bits, sothat the port identifier, if  properly  selected,  could  be  consideredprobabilistically  unique.    Thus,  constraining  the  port  id  to oneparticular IP level mechanism would prevent certain  fruitful  lines  ofresearch.    Second,  ports  serve  a  special  function  in addition todatagram delivery:   certain  port  numbers  are  reserved  to  identifyparticular services.  Thus, TCP port 23 is the remote login service.  Ifports  were  implemented  at  the  IP level, then the assignment of wellknown ports could not be done on a protocol basis, but would have to  bedone  in a centralized manner for all of the IP architecture.  Third, IPwas designed with a very simple layering role:    IP  contained  exactlythose functions that the gateways must understand.  If the port idea hadbeen  made a part of the IP layer, it would have suggested that gatewaysneeded to know about ports, which is not the case.     There are, of course, other ways  to  avoid  these  problems.    Inparticular,  the  "well-known  port" problem can be solved by devising asecond mechanism, distinct from port  dispatching,  to  name  well-knownports.   Several protocols have settled on the idea of including, in thepacket which sets up a  connection  to  a  particular  service,  a  moregeneral  service  descriptor,  such  as a character string field.  Thesespecial  packets,  which  are  requesting  connection  to  a  particular

                                   12service,  are  routed on arrival to a special server, sometimes called a"rendezvous server", which  examines  the  service  request,  selects  arandom  port  which  is to be used for this instance of the service, andthen passes the packet along to  the  service  itself  to  commence  theinteraction.     For  the  internet architecture, this strategy had the serious flawthat it presumed all protocols would fit into the same service paradigm:an initial setup phase, which might contain a certain overhead  such  asindirect routing through a rendezvous server, followed by the packets ofthe  interaction  itself,  which  would  flow  directly  to  the processproviding the service.  Unfortunately, not all high level  protocols  ininternet  were  expected to fit this model.  The best example of this isisolated datagram exchange using UDP.  The simplest exchange in  UDP  isone process sending a single datagram to another.  Especially on a localnet,  where  the  net  related overhead is very low, this kind of simplesingle datagram interchange can be extremely efficient,  with  very  lowoverhead  in  the  hosts.  However, since these individual packets wouldnot be part of an established connection, if  IP  supported  a  strategybased  on  a  rendezvous  server and service descriptors, every isolateddatagram would have to  be  routed  indirectly  in  the  receiving  hostthrough  the  rendezvous  server, which would substantially increase theoverhead of processing, and every datagram would have to carry the  fullservice  request  field,  which  would  increase  the size of the packetheader.     In general, if a network is intended for "virtual circuit service",

                                   13or  things similar to that, then using a special high overhead mechanismfor circuit setup makes sense.  However, current directions in  researchare  leading  away  from  this  class  of  protocol,  so  once again thearchitecture  was  designed  not  to   preclude   alternative   protocolstructures.    The  only  rational  position  was  that  the  particulardispatching strategy used should be part of the  higher  level  protocoldesign, not the IP layer.     This  same  argument about circuit setup mechanisms also applies tothe design of the IP address structure.  Many protocols do not  transmita  full  address  field  as  part of every packet, but rather transmit ashort identifier which is created as part of a circuit setup from sourceto destination.  If the full address needs to be  carried  in  only  thefirst  packet  of  a long exchange, then the overhead of carrying a verylong address field can easily be justified.  Under these  circumstances,one  can  create  truly extravagant address fields, which are capable ofextending to address almost  any  conceivable  entity.    However,  thisstrategy  is  useable  only  in a virtual circuit net, where the packetsbeing transmitted are part of a  established  sequence,  otherwise  thislarge  extravagant  address  must be transported on every packet.  SinceInternet explicitly rejected this restriction on  the  architecture,  itwas  necessary  to come up with an address field that was compact enoughto be sent in every datagram, but general enough to correctly route  thedatagram  through  the  catanet  without a previous setup phase.  The IPaddress of 32 bits is the compromise that results.  Clearly it  requiresa  substantial  amount  of shoehorning to address all of the interestingplaces in the universe with only 32 bits.  On the other  hand,  had  the

                                   14address  field  become  much  bigger,  IP would have been susceptible toanother criticism, which is that the header had grown unworkably  large.Again, the fundamental design decision was that the protocol be designedin  such  a way that it supported research in new and different sorts ofprotocol architectures.     There are some limited restrictions imposed by the IP design on theport mechanism selected by the higher level  process.    In  particular,when  a packet goes awry somewhere on the internet, the offending packetis returned, along with an error indication, as part of an ICMP  packet.An  ICMP  packet  returns only the IP layer, and the next 64 bits of theoriginal datagram.  Thus, any higher level protocol which wishes to sortout from which port a particular offending datagram came must make  surethat  the  port information is contained within the first 64 bits of thenext level header.  This also means, in most cases, that it is  possibleto  imagine,  as  part  of the IP layer, a port dispatch mechanism whichworks by masking and matching on the  first  64  bits  of  the  incominghigher level header.