rfc801.txt

RFC 的详细文档！

Network Working Group                                          J. Postel
Request for Comments: 801                                            ISI
                                                           November 1981



                        NCP/TCP TRANSITION PLAN



Introduction
------------

   ARPA sponsored research on computer networks led to the development
   of the ARPANET.  The installation of the ARPANET began in September
   1969, and regular operational use was underway by 1971.  The ARPANET
   has been an operational service for at least 10 years.  Even while it
   has provided a reliable service in support of a variety of computer
   research activities, it has itself been a subject of continuing
   research, and has evolved significantly during that time.

   In the past several years ARPA has sponsored additional research on
   computer networks, principally networks based on different underlying
   communication techniques, in particular, digital packet broadcast
   radio and satellite networks.  Also, in the ARPA community there has
   been significant work on local networks.

   It was clear from the start of this research on other networks that
   the base host-to-host protocol used in the ARPANET was inadequate for
   use in these networks.  In 1973 work was initiated on a host-to-host
   protocol for use across all these networks.  The result of this long
   effort is the Internet Protocol (IP) and the Transmission Control
   Protocol (TCP).

   These protocols allow all hosts in the interconnected set of these
   networks to share a common interprocess communication environment.
   The collection of interconnected networks is called the ARPA Internet
   (sometimes called the "Catenet").

   The Department of Defense has recently adopted the internet concept
   and the IP and TCP protocols in particular as DoD wide standards for
   all DoD packet networks, and will be transitioning to this
   architecture over the next several years.  All new DoD packet
   networks will be using these protocols exclusively.

   The time has come to put these protocols into use in the operational
   ARPANET, and extend the logical connectivity of the ARPANET hosts to
   include hosts in other networks participating in the ARPA Internet.

   As with all new systems, there will be some aspects which are not as
   robust and efficient as we would like (just as with the initial
   ARPANET).  But with your help, these problems can be solved and we


Postel                                                          [Page 1]


RFC 801                                                    November 1981
                                                 NCP/TCP Transition Plan


   can move into an environment with significantly broader communication
   services.

Discussion
----------

   The implementation of IP/TCP on several hosts has already been
   completed, and the use of some services is underway.  It is urgent
   that the implementation of of IP/TCP be begun on all other ARPANET
   hosts as soon as possible and no later than 1 January 1982 in any
   case.  Any new host connected to the ARPANET should only implement
   IP/TCP and TCP-based services.  Several important implementation
   issues are discussed in the last section of this memo.

   Because all hosts can not be converted to TCP simultaneously, and
   some will implement only IP/TCP, it will be necessary to provide
   temporarily for communication between NCP-only hosts and TCP-only
   hosts.  To do this certain hosts which implement both NCP and IP/TCP
   will be designated as relay hosts.  These relay hosts will support
   Telnet, FTP, and Mail services on both NCP and TCP.  These relay
   services will be provided  beginning in November 1981, and will be
   fully in place in January 1982.

   Initially there will be many NCP-only hosts and a few TCP-only hosts,
   and the load on the relay hosts will be relatively light.  As time
   goes by, and the conversion progresses, there will be more TCP
   capable hosts, and fewer NCP-only hosts, plus new TCP-only hosts.
   But, presumably most hosts that are now NCP-only will implement
   IP/TCP in addition to their NCP and become "dual protocol" hosts.
   So, while the load on the relay hosts will rise, it will not be a
   substantial portion of the total traffic.

   The next section expands on this plan, and the following section
   gives some milestones in the transition process.  The last section
   lists the key documents describing the new protocols and services.
   Appendices present scenarios for use of the relay services.

The General Plan
----------------

   The goal is to make a complete switch over from the NCP to IP/TCP by
   1 January 1983.

      It is the task of each host organization to implement IP/TCP for
      its own hosts.  This implementation task must begin by
      1 January 1982.





Postel                                                          [Page 2]


RFC 801                                                    November 1981
                                                 NCP/TCP Transition Plan


      IP:

         This is specified in RFCs 791 and 792.  Implementations exist
         for several machines and operating systems.  (See Appendix D.)

      TCP:

         This is specified in RFC793.  Implementations exist for several
         machines and operating systems.  (See Appendix D.)

   It is not enough to implement the IP/TCP protocols, the principal
   services must be available on this IP/TCP base as well.  The
   principal services are: Telnet, File Transfer, and Mail.

      It is the task of each host organization to implement the
      principal services for its own hosts.  These implementation tasks
      must begin by 1 January 1982.

      Telnet:

         This is specified in RFC 764.  It is very similar to the Telnet
         used with the NCP.  The primary differences are that the ICP is
         eliminated, and the NCP Interrupt is replaced with the TCP
         Urgent.

      FTP:

         This is specified in RFC 765.  It is very similar to the FTP
         used with the NCP.  The primary differences are that in
         addition to the changes for Telnet, that the data channel is
         limited to 8-bit bytes so FTP features to use other
         transmission byte sizes are eliminated.

      Mail:

         This is specified in RFC 788.  Mail is separated completely
         from FTP and handled by a distinct server.  The procedure is
         similar in concept to the old FTP/NCP mail procedure, but is
         very different in detail, and supports additional functions --
         especially mail relaying, and multi-recipient delivery.

   Beyond providing the principal services in the new environment, there
   must be provision for interworking between the new environment and
   the old environment between now and January 1983.

      For Telnet, there will be provided one or more relay hosts.  A
      Telnet relay host will implement both the NCP and TCP environments
      and both user and server Telnet in both environments.  Users
      requiring Telnet service between hosts in different environments


Postel                                                          [Page 3]


RFC 801                                                    November 1981
                                                 NCP/TCP Transition Plan


      will first connect to a Telnet relay host and then connect to the
      destination host.  (See Appendix A.)

      For FTP, there will be provided one or more relay hosts.  An FTP
      relay host will implement both the NCP and TCP environments, both
      user and server Telnet, and both user and server FTP in both
      environments.  Users requiring FTP service between hosts in
      different environments will first connect via Telnet to an FTP
      relay host, then use FTP to move the file from the file donor host
      to the FTP relay host, and finally use FTP to move the file from
      the FTP relay host to the file acceptor host.  (See Appendix B.)

      For Mail, hosts will implement the new Simple Mail Transfer
      Protocol (SMTP) described in RFC 788.  The SMTP procedure provides
      for relaying mail among several protocol environments.  For
      TCP-only hosts, using SMTP will be sufficient.  For NCP-only hosts
      that have not been modified to use SMTP, the special syntax
      "user.host@forwarder" may be used to relay mail via one or more
      special forwarding host.  Several mail relay hosts will relay mail
      via SMTP procedures between the NCP and TCP environments, and at
      least one special forwarding host will be provided.  (See
      Appendix C.)

Milestones
----------

   First Internet Service                                        already

      A few hosts are TCP-capable and use TCP-based services.

   First TCP-only Host                                           already

      The first TCP-only host begins use of TCP-based services.

   Telnet and FTP Relay Service                                  already

      Special relay accounts are available to qualified users with a
      demonstrated need for the Telnet or FTP relay service.

   Ad Hoc Mail Relay Service                                     already

      An ad hoc mail relay service using the prototype MTP (RFC 780) is
      implemented and mail is relayed from the TCP-only hosts to
      NCP-only hosts, but not vice versa.  This service will be replaced
      by the SMTP service.

   Last NCP Conversion Begins                                     Jan 82

      The last NCP-only host begins conversion to TCP.


Postel                                                          [Page 4]


RFC 801                                                    November 1981
                                                 NCP/TCP Transition Plan


   Mail Relay Service                                             Jan 82

      The SMTP (RFC 788) mail service begins to operate and at least one
      mail relay host is operational, and at least one special forwarder
      is operational to provide NCP-only host to TCP-only host mail
      connectivity.

   Normal Internet Service                                        Jul 82

      Most hosts are TCP-capable and use TCP-based services.

   Last NCP Conversion Completed                                  Nov 82

      The last NCP-only host completes conversion to TCP.

   Full Internet Service                                          Jan 83

      All hosts are TCP-capable and use TCP-based services.  NCP is
      removed from service, relay services end, all services are
      TCP-based.

Documents
---------

   The following RFCs document the protocols to be implemented in the
   new IP/TCP environment:

      IP                                                         RFC 791
      ICMP                                                       RFC 792
      TCP                                                        RFC 793
      Telnet                                                     RFC 764
      FTP                                                        RFC 765
      SMTP                                                       RFC 788
      Name Server                                                IEN 116
      Assigned Numbers                                           RFC 790

   These and associated documents are to be published in a notebook, and
   other information useful to implementers is to be gathered.  These
   documents will be made available on the following schedule:

      Internet Protocol Handbook                                  Jan 82

      Implementers Hints                                          Jan 82

      SDC IP/TCP Specifications                                   Jan 82

      Expanded Host Table                                         Jan 82




Postel                                                          [Page 5]


RFC 801                                                    November 1981
                                                 NCP/TCP Transition Plan


Implementation Issues
---------------------

   There are several implementation issues that need attention, and
   there are some associated facilities with these protocols that are
   not necessarily obvious.  Some of these may need to be upgraded or
   redesigned to work with the new protocols.

   Name Tables

      Most hosts have a table for converting character string names of
      hosts to numeric addresses.  There are two effects of this
      transition that may impact a host's table of host names: (1) there
      will be many more names, and (2) there may be a need to note the
      protocol capability of each host (SMTP/TCP, SMTP/NCP, FTP/NCP,
      etc.).

      Some hosts have kept this table in the operating system address
      space to provide for fast translation using a system call.  This
      may not be practical in the future.

      There may be applications that could take alternate actions if
      they could easily determine if a remote host supported a
      particular protocol.  It might be useful to extend host name
      tables to note which protocols are supported.

      It might be necessary for the host name table to contain names of
      hosts reachable only via relays if this name table is used to
      verify the spelling of host names in application programs such as
      mail composition programs.

      It might be advantageous to do away with the host name table and
      use a Name Server instead, or to keep a relatively small table as
      a cache of recently used host names.

      A format, distribution, and update procedure for the expanded host
      table will be published soon.

   Mail Programs

      It may be possible to move to the new SMTP mail procedures by
      changing only the mailer-daemon and implementing the SMTP-server,
      but in some hosts there may be a need to make some small changes
      to some or all of the mail composition programs.

      There may be a need to allow users to identify relay hosts for
      messages they send.  This may require a new command or address
      syntax not now currently allowed.



Postel                                                          [Page 6]


RFC 801                                                    November 1981
                                                 NCP/TCP Transition Plan


   IP/TCP

      Continuing use of IP and TCP will lead to a better understanding
      of the performance characteristics and parameters.  Implementers
      should expect to make small changes from time to time to improve
      performance.

   Shortcuts

      There are some very tempting shortcuts in the implementation of IP
      and TCP.  DO NOT BE TEMPTED!  Others have and they have been
      caught!  Some deficiencies with past implementations that must be
      remedied and are not allowed in the future are the following:

         IP problems:

            Some IP implementations did not verify the IP header
            checksum.

            Some IP implementations did not implement fragment
            reassembly.

            Some IP implementations used static and limited routing
            information, and did not make use of the ICMP redirect
            message information.

            Some IP implementations did not process options.

            Some IP implementations did not report errors they detected
            in a useful way.

         TCP problems:

            Some TCP implementations did not verify the TCP checksum.

            Some TCP implementations did not reorder segments.

            Some TCP implementations did not protect against silly
            window syndrome.

            Some TCP implementations did not report errors they detected
            in a useful way.

            Some TCP implementations did not process options.

         Host problems:

            Some hosts had limited or static name tables.



Postel                                                          [Page 7]