rfc1122.txt

bind 9.3结合mysql数据库

        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



Internet Engineering Task Force                                 [Page 6]




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
              connection control information is thus co-located with the
              end points of the communication, so it will be lost only
              if an end point fails.

         (c)  Routing complexity should be in the gateways.

              Routing is a complex and difficult problem, and ought to
              be performed by the gateways, not the hosts.  An important



Internet Engineering Task Force                                 [Page 7]




RFC1122                       INTRODUCTION                  October 1989


              objective is to insulate host software from changes caused
              by the inevitable evolution of the Internet routing
              architecture.

         (d)  The System must tolerate wide network variation.

              A basic objective of the Internet design is to tolerate a
              wide range of network characteristics -- e.g., bandwidth,
              delay, packet loss, packet reordering, and maximum packet
              size.  Another objective is robustness against failure of
              individual networks, gateways, and hosts, using whatever
              bandwidth is still available.  Finally, the goal is full
              "open system interconnection": an Internet host must be
              able to interoperate robustly and effectively with any
              other Internet host, across diverse Internet paths.

              Sometimes host implementors have designed for less
              ambitious goals.  For example, the LAN environment is
              typically much more benign than the Internet as a whole;
              LANs have low packet loss and delay and do not reorder
              packets.  Some vendors have fielded host implementations
              that are adequate for a simple LAN environment, but work
              badly for general interoperation.  The vendor justifies
              such a product as being economical within the restricted
              LAN market.  However, isolated LANs seldom stay isolated
              for long; they are soon gatewayed to each other, to
              organization-wide internets, and eventually to the global
              Internet system.  In the end, neither the customer nor the
              vendor is served by incomplete or substandard Internet
              host software.

              The requirements spelled out in this document are designed
              for a full-function Internet host, capable of full
              interoperation over an arbitrary Internet path.


      1.1.3  Internet Protocol Suite

         To communicate using the Internet system, a host must implement
         the layered set of protocols comprising the Internet protocol
         suite.  A host typically must implement at least one protocol
         from each layer.

         The protocol layers used in the Internet architecture are as
         follows [INTRO:4]:


         o  Application Layer



Internet Engineering Task Force                                 [Page 8]




RFC1122                       INTRODUCTION                  October 1989


              The application layer is the top layer of the Internet
              protocol suite.  The Internet suite does not further
              subdivide the application layer, although some of the
              Internet application layer protocols do contain some
              internal sub-layering.  The application layer of the
              Internet suite essentially combines the functions of the
              top two layers -- Presentation and Application -- of the
              OSI reference model.

              We distinguish two categories of application layer
              protocols:  user protocols that provide service directly
              to users, and support protocols that provide common system
              functions.  Requirements for user and support protocols
              will be found in the companion RFC [INTRO:1].

              The most common Internet user protocols are:

                o  Telnet (remote login)
                o  FTP    (file transfer)
                o  SMTP   (electronic mail delivery)

              There are a number of other standardized user protocols
              [INTRO:4] and many private user protocols.

              Support protocols, used for host name mapping, booting,
              and management, include SNMP, BOOTP, RARP, and the Domain
              Name System (DNS) protocols.


         o  Transport Layer

              The transport layer provides end-to-end communication
              services for applications.  There are two primary
              transport layer protocols at present:

                o Transmission Control Protocol (TCP)
                o User Datagram Protocol (UDP)

              TCP is a reliable connection-oriented transport service
              that provides end-to-end reliability, resequencing, and
              flow control.  UDP is a connectionless ("datagram")
              transport service.

              Other transport protocols have been developed by the
              research community, and the set of official Internet
              transport protocols may be expanded in the future.

              Transport layer protocols are discussed in Chapter 4.



Internet Engineering Task Force                                 [Page 9]




RFC1122                       INTRODUCTION                  October 1989


         o  Internet Layer

              All Internet transport protocols use the Internet Protocol
              (IP) to carry data from source host to destination host.
              IP is a connectionless or datagram internetwork service,
              providing no end-to-end delivery guarantees. Thus, IP
              datagrams may arrive at the destination host damaged,
              duplicated, out of order, or not at all.  The layers above
              IP are responsible for reliable delivery service when it
              is required.  The IP protocol includes provision for
              addressing, type-of-service specification, fragmentation
              and reassembly, and security information.

              The datagram or connectionless nature of the IP protocol
              is a fundamental and characteristic feature of the
              Internet architecture.  Internet IP was the model for the
              OSI Connectionless Network Protocol [INTRO:12].

              ICMP is a control protocol that is considered to be an
              integral part of IP, although it is architecturally
              layered upon IP, i.e., it uses IP to carry its data end-
              to-end just as a transport protocol like TCP or UDP does.
              ICMP provides error reporting, congestion reporting, and
              first-hop gateway redirection.

              IGMP is an Internet layer protocol used for establishing
              dynamic host groups for IP multicasting.

              The Internet layer protocols IP, ICMP, and IGMP are
              discussed in Chapter 3.


         o  Link Layer

              To communicate on its directly-connected network, a host
              must implement the communication protocol used to
              interface to that network.  We call this a link layer or
              media-access layer protocol.

              There is a wide variety of link layer protocols,
              corresponding to the many different types of networks.
              See Chapter 2.


      1.1.4  Embedded Gateway Code

         Some Internet host software includes embedded gateway
         functionality, so that these hosts can forward packets as a



Internet Engineering Task Force                                [Page 10]




RFC1122                       INTRODUCTION                  October 1989


         gateway would, while still performing the application layer
         functions of a host.

         Such dual-purpose systems must follow the Gateway Requirements
         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.