o    There may be valid reasons why particular vendor products that
        are designed for restricted contexts might choose to use
        different specifications.

   However, the specifications of this document must be followed to meet
   the general goal of arbitrary host interoperation across the
   diversity and complexity of the Internet system.  Although most
   current implementations fail to meet these requirements in various
   ways, some minor and some major, this specification is the ideal
   towards which we need to move.

   These requirements are based on the current level of Internet
   architecture.  This document will be updated as required to provide
   additional clarifications or to include additional information in
   those areas in which specifications are still evolving.

   This introductory section begins with a brief overview of the
   Internet architecture as it relates to hosts, and then gives some
   general advice to host software vendors.  Finally, there is some
   guidance on reading the rest of the document and some terminology.

   1.1  The Internet Architecture

      General background and discussion on the Internet architecture and
      supporting protocol suite can be found in the DDN Protocol
      Handbook [INTRO:3]; for background see for example [INTRO:9],
      [INTRO:10], and [INTRO:11].  Reference [INTRO:5] describes the
      procedure for obtaining Internet protocol documents, while
      [INTRO:6] contains a list of the numbers assigned within Internet
      protocols.

      1.1.1  Internet Hosts

         A host computer, or simply "host," is the ultimate consumer of
         communication services.  A host generally executes application
         programs on behalf of user(s), employing network and/or
         Internet communication services in support of this function.
         An Internet host corresponds to the concept of an "End-System"
         used in the OSI protocol suite [INTRO:13].

         An Internet communication system consists of interconnected
         packet networks supporting communication among host computers
         using the Internet protocols.  The networks are interconnected
         using packet-switching computers called "gateways" or "IP
         routers" by the Internet community, and "Intermediate Systems"
         by the OSI world [INTRO:13].  The RFC "Requirements for
         Internet Gateways" [INTRO:2] contains the official
         specifications for Internet gateways.  That RFC together with




 



RFC1122                       INTRODUCTION                  October 1989


         the present document and its companion [INTRO:1] define the
         rules for the current realization of the Internet architecture.

         Internet hosts span a wide range of size, speed, and function.
         They range in size from small microprocessors through
         workstations to mainframes and supercomputers.  In function,
         they range from single-purpose hosts (such as terminal servers)
         to full-service hosts that support a variety of online network
         services, typically including remote login, file transfer, and
         electronic mail.

         A host is generally said to be multihomed if it has more than
         one interface to the same or to different networks.  See
         Section 1.1.3 on "Terminology".

      1.1.2  Architectural Assumptions

         The current Internet architecture is based on a set of
         assumptions about the communication system.  The assumptions
         most relevant to hosts are as follows:

         (a)  The Internet is a network of networks.

              Each host is directly connected to some particular
              network(s); its connection to the Internet is only
              conceptual.  Two hosts on the same network communicate
              with each other using the same set of protocols that they
              would use to communicate with hosts on distant networks.

         (b)  Gateways don't keep connection state information.

              To improve robustness of the communication system,
              gateways are designed to be stateless, forwarding each IP
              datagram independently of other datagrams.  As a result,
              redundant paths can be exploited to provide robust service
              in spite of failures of intervening gateways and networks.

              All state information required for end-to-end flow control
              and reliability is implemented in the hosts, in the
              transport layer or in application programs.  All