rfc823.txt

RFC 相关的技术文档

Request for Comments:  823
Obsoletes IEN-30 and IEN-109




                        THE DARPA INTERNET GATEWAY



                                  RFC 823






                               Robert Hinden
                               Alan Sheltzer





                       Bolt Beranek and Newman Inc.
                              10 Moulton St.
                      Cambridge, Massachusetts 02238





                              September 1982




                               Prepared for

                 Defense Advanced Research Projects Agency
                 Information Processing Techniques Office
                           1400 Wilson Boulevard
                         Arlington, Virginia 22209





This RFC is a status report on the Internet Gateway developed by BBN. It
describes the Internet Gateway as of September 1982.  This memo presents
detailed descriptions of message formats and gateway procedures, however
this is not an implementation specification, and such details are 
subject to change.







     DARPA Internet Gateway                             September 1982
     RFC 823



                             Table of Contents




     1   INTRODUCTION.......................................... 1
     2   BACKGROUND............................................ 2
     3   FORWARDING INTERNET DATAGRAMS......................... 5
     3.1   Input............................................... 5
     3.2   IP Header Checks.................................... 6
     3.3   Routing............................................. 7
     3.4   Redirects........................................... 9
     3.5   Fragmentation....................................... 9
     3.6   Header Rebuild..................................... 10
     3.7   Output............................................. 10
     4   PROTOCOLS SUPPORTED BY THE GATEWAY................... 12
     4.1   Cross-Net Debugging Protocol....................... 12
     4.2   Host Monitoring Protocol........................... 12
     4.3   ICMP............................................... 14
     4.4   Gateway-to-Gateway Protocol........................ 14
     4.4.1   Determining Connectivity to Networks............. 14
     4.4.2   Determining Connectivity to Neighbors............ 16
     4.4.3   Exchanging Routing Information................... 17
     4.4.4   Computing Routes................................. 19
     4.4.5   Non-Routing Gateways............................. 22
     4.4.6   Adding New Neighbors and Networks................ 23
     4.5   Exterior Gateway Protocol.......................... 24
     5   GATEWAY SOFTWARE..................................... 26
     5.1   Software Structure................................. 26
     5.1.1   Device Drivers................................... 27
     5.1.2   Network Software................................. 27
     5.1.3   Shared Gateway Software.......................... 29
     5.2   Gateway Processes.................................. 29
     5.2.1   Network Processes................................ 29
     5.2.2   GGP Process...................................... 30
     5.2.3   HMP Process...................................... 31
     APPENDIX A. GGP Message Formats.......................... 32
     APPENDIX B. Information Maintained by Gateways........... 39
     APPENDIX C. GGP Events and Responses..................... 41
     REFERENCES............................................... 43







                                    -i-





     DARPA Internet Gateway                             September 1982
     RFC 823



     1  INTRODUCTION


          This document explains the design of  the  Internet  gateway

     used  in  the  Defense  Advanced  Research Project Agency (DARPA)

     Internet program.  The gateway design was  originally  documented

     in  IEN-30,  "Gateway  Routing:  An Implementation Specification"

     [2], and was later updated in IEN-109, "How to Build  a  Gateway"

     [3].   This  document  reflects changes made both in the internet

     protocols and in the gateway design since  these  documents  were

     released.  It supersedes both IEN-30 and IEN-109.


          The Internet gateway described in this document is based  on

     the  work  of many people; in particular, special credit is given

     to V. Strazisar, M. Brescia, E. Rosen, and J. Haverty.


          The gateway's primary purpose is to route internet datagrams

     to their destination networks.  These datagrams are generated and

     processed as described in RFC 791,  "Internet  Protocol  -  DARPA

     Internet  Program  Protocol  Specification"  [1].   This document

     describes  how  the  gateway  forwards  datagrams,  the   routing

     algorithm  and  protocol  used  to  route  them, and the software

     structure  of  the  current   gateway.    The   current   gateway

     implementation  is written in macro-11 assembly language and runs

     in the DEC PDP-11 or LSI-11 16-bit processor.



                                    -1-





     DARPA Internet Gateway                             September 1982
     RFC 823



     2  BACKGROUND


          The gateway system has undergone a series of  changes  since

     its  inception,  and  it  is  continuing  to  evolve  as research

     proceeds in the Internet community.  This document describes  the

     implementation as of mid-1982.


          Early versions of gateway software  were  implemented  using

     the   BCPL   language   and   the  ELF  operating  system.   This

     implementation evolved into one  which  used  the  MOS  operating

     system  for  increased  performance.   In  late 1981, we began an

     effort to produce a  totally  new  gateway  implementation.   The

     primary  motivation  for  this was the need for a system oriented

     towards  the  requirements  of  an   operational   communications

     facility,  rather than the research testbed environment which was

     associated with the BCPL implementation.   In  addition,  it  was

     generally   recognized   that   the   complexity   and  buffering

     requirements of future gateway  configurations  were  beyond  the

     capabilities of the PDP-11/LSI-11 and BCPL architecture.  The new

     gateway implementation therefore had a second goal of producing a

     highly  space-efficient  implementation in order to provide space

     for buffers and for the extra  mechanisms,  such  as  monitoring,

     which are needed for an operational environment.




                                    -2-





     DARPA Internet Gateway                             September 1982
     RFC 823



          This document  describes  the  implementation  of  this  new

     gateway  which  incorporates  several  mechanisms  for operations

     activities,  is coded in assembly  language  for  maximum  space-

     efficiency,  but otherwise is fundamentally the same architecture

     as the older, research-oriented, implementations.


          One of the results of recent research  is  the  thesis  that

     gateways  should be viewed as elements of a gateway system, where

     the  gateways   act   as   a   loosely-coupled   packet-switching

     communications   system.   For  reasons  of  maintainability  and

     operability,  it  is  easiest  to  build  such  a  system  in  an

     homogeneous  fashion  where  all  gateways  are  under  a  single

     authority and control,  as  is  the  practice  in  other  network

     implementations.


          In order to create  a  system  architecture  that  permitted

     multiple  sets of gateways with each set under single control but

     acting together to implement a composite single Internet  System,

     new  protocols  needed to be developed.  These protocols, such as

     the "Exterior Gateway Protocol," will be introduced in the  later

     releases of the gateway implementation.


          We  also  anticipate  further   changes   to   the   gateway

     architecture  and  implementation  to  introduce  support for new



                                    -3-





     DARPA Internet Gateway                             September 1982
     RFC 823



     capabilities, such as large numbers of networks, access  control,

     and  other  requirements which have been proposed by the Internet

     research community.  This document represents a snapshot  of  the

     current implementation, rather than a specification.








































                                    -4-





     DARPA Internet Gateway                             September 1982
     RFC 823



     3  FORWARDING INTERNET DATAGRAMS


          This section describes how the  gateway  forwards  datagrams

     between  networks.   A host computer that wants an IP datagram to

     reach a host on another network  must  send  the  datagram  to  a

     gateway to be forwarded.  Before it is sent into the network, the

     host attaches to the datagram a local network  header  containing

     the address of the gateway.




     3.1  Input


          When a gateway receives a message, the  gateway  checks  the

     message's  local  network header for possible errors and performs

     any actions  required  by  the  host-to-network  protocol.   This

     processing involves functions such as verifying the local network

     header checksum or  generating  a  local  network  acknowledgment

     message.   If  the  header indicates that the message contains an

     Internet datagram, the datagram is passed to the Internet  header

     check  routine.   All  other  messages  received that do not pass

     these tests are discarded.









                                    -5-





     DARPA Internet Gateway                             September 1982
     RFC 823



     3.2  IP Header Checks


          The Internet header  check  routine  performs  a  number  of

     validity tests on the IP header.  Datagrams that fail these tests

     are discarded causing an HMP trap to  be  sent  to  the  Internet

     Network  Operations  Center (INOC) [7].  The following checks are

     currently performed:


          o  Proper IP Version Number
          o  Valid IP Header Length ( >= 20 bytes)
          o  Valid IP Message Length
          o  Valid IP Header Checksum
          o  Non-Zero Time to Live field


     After a datagram passes these checks,  its  Internet  destination

     address  is examined to determine if the datagram is addressed to

     the gateway.  Each of the gateway's internet addresses  (one  for

     each  network  interface)  is  checked  against  the  destination

     address in the datagram.  If a match is not found,  the  datagram

     is passed to the forwarding routine.


          If the datagram is addressed to the gateway itself,  the  IP

     options  in  the IP header are processed.  Currently, the gateway

     supports the following IP options:








                                    -6-





     DARPA Internet Gateway                             September 1982
     RFC 823




          o  NOP
          o  End of Option List
          o  Loose Source and Record Route
          o  Strict Source and Record Route


     The datagram is next processed according to the protocol  in  the

     IP  header.  If  the protocol is not supported by the gateway, it

     replies with an ICMP error message  and  discards  the  datagram.

     The  gateway  does  not  support  IP  reassembly,  so  fragmented

     datagrams which are addressed to the gateway are discarded.




     3.3  Routing


          The gateway must make a routing decision for  all  datagrams

     that  are to be to forwarded.  The routing algorithm provides two

     pieces of information for the gateway:  1) the network  interface

     that  should be used to send this datagram and 2) the destination

     address that should be put in the local  network  header  of  the

     datagram.


          The gateway maintains a dynamic Routing Table which contains

     an  entry  for  each  reachable network.  The entry consists of a

     network number and the address of the  neighbor  gateway  on  the

     shortest  route  to  the  network, or else an indication that the




                                    -7-





     DARPA Internet Gateway                             September 1982
     RFC 823



     gateway is directly connected to the network.  A neighbor gateway

     is  one  which  shares  a  common network with this gateway.  The

     distance metric that is  used  to  determine  which  neighbor  is

     closest  is  defined  as the "number of hops," where a gateway is

     considered to be zero hops from its directly connected  networks,

     one  hop  from a network that is reachable via one other gateway,

     etc.  The Gateway-to-Gateway Protocol (GGP) is used to update the

     Routing  Table (see Section 4.4 describing the Gateway-to-Gateway

     Protocol).


          The gateway tries to match the destination  network  address

     in  the IP header of the datagram to be forwarded, with a network

     in its Routing Table.  If no match is found,  the  gateway  drops

     the datagram and sends an ICMP Destination Unreachable message to

     the IP source.  If the gateway does find an entry for the network

     in  its  table,  it  will use the network address of the neighbor

     gateway entry as the local network  destination  address  of  the

     datagram.   However, if the final destination network is one that

     the gateway is directly connected to, the destination address  in

     the  local network header is created from the destination address

     in the IP header of the datagram.







                                    -8-





     DARPA Internet Gateway                             September 1982
     RFC 823



     3.4  Redirects


          If the routing procedure decides that an IP datagram  is  to

     be  sent back out the same network interface that it was read in,

     then this gateway is not on the shortest path  to  the  IP  final

     destination.   Nevertheless, the datagram will still be forwarded

     to the next address chosen by  the  routing  procedure.   If  the

     datagram  is  not  using  the  IP Source Route Option, and the IP

     source network of the datagram is the same as the network of  the

     next  gateway  chosen  by the routing procedure, an ICMP Redirect

     message will be sent  to  the  IP  source  host  indicating  that

     another  gateway  should  be used to send traffic to the final IP

     destination.




     3.5  Fragmentation


          The datagram is passed to the  fragmentation  routine  after

     the  routing decision has been made.  If the next network through

     which the datagram must pass has a maximum message size  that  is

     smaller  than  the  size  of  the  datagram, the datagram must be

     fragmented.   Fragmentation  is  performed   according   to   the

     algorithm  described  in the Internet Protocol Specification [1].

     Certain IP options must be copied  into  the  IP  header  of  all



                                    -9-





     DARPA Internet Gateway                             September 1982
     RFC 823



     fragments, and others appear only in the first fragment according

     to the IP specification.  If a datagram must be  fragmented,  but

     the  Don't  fragment bit is set, the datagram is discarded and an

     ICMP error message is sent to the IP source of the datagram.