RFC [INTRO:2]  with respect to their gateway functions, and
         must follow the present document with respect to their host
         functions.  In all overlapping cases, the two specifications
         should be in agreement.

         There are varying opinions in the Internet community about
         embedded gateway functionality.  The main arguments are as
         follows:

         o    Pro: in a local network environment where networking is
              informal, or in isolated internets, it may be convenient
              and economical to use existing host systems as gateways.

              There is also an architectural argument for embedded
              gateway functionality: multihoming is much more common
              than originally foreseen, and multihoming forces a host to
              make routing decisions as if it were a gateway.  If the
              multihomed  host contains an embedded gateway, it will
              have full routing knowledge and as a result will be able
              to make more optimal routing decisions.

         o    Con: Gateway algorithms and protocols are still changing,
              and they will continue to change as the Internet system
              grows larger.  Attempting to include a general gateway
              function within the host IP layer will force host system
              maintainers to track these (more frequent) changes.  Also,
              a larger pool of gateway implementations will make
              coordinating the changes more difficult.  Finally, the
              complexity of a gateway IP layer is somewhat greater than
              that of a host, making the implementation and operation
              tasks more complex.

              In addition, the style of operation of some hosts is not
              appropriate for providing stable and robust gateway
              service.

         There is considerable merit in both of these viewpoints.  One
         conclusion can be drawn: an host administrator must have
         conscious control over whether or not a given host acts as a
         gateway.  See Section 3.1 for the detailed requirements.








 



RFC1122                       INTRODUCTION                  October 1989


   1.2  General Considerations

      There are two important lessons that vendors of Internet host
      software have learned and which a new vendor should consider
      seriously.

      1.2.1  Continuing Internet Evolution

         The enormous growth of the Internet has revealed problems of
         management and scaling in a large datagram-based packet
         communication system.  These problems are being addressed, and
         as a result there will be continuing evolution of the
         specifications described in this document.  These changes will
         be carefully planned and controlled, since there is extensive
         participation in this planning by the vendors and by the
         organizations responsible for operations of the networks.

         Development, evolution, and revision are characteristic of
         computer network protocols today, and this situation will
         persist for some years.  A vendor who develops computer
         communication software for the Internet protocol suite (or any
         other protocol suite!) and then fails to maintain and update
         that software for changing specifications is going to leave a
         trail of unhappy customers.  The Internet is a large
         communication network, and the users are in constant contact
         through it.  Experience has shown that knowledge of
         deficiencies in vendor software propagates quickly through the
         Internet technical community.

      1.2.2  Robustness Principle

         At every layer of the protocols, there is a general rule whose
         application can lead to enormous benefits in robustness and
         interoperability [IP:1]:

                "Be liberal in what you accept, and
                 conservative in what you send"

         Software should be written to deal with every conceivable
         error, no matter how unlikely; sooner or later a packet will
         come in with that particular combination of errors and
         attributes, and unless the software is prepared, chaos can
         ensue.  In general, it is best to assume that the network is
         filled with malevolent entities that will send in packets
         designed to have the worst possible effect.  This assumption