rfc1011.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                        J. Reynolds
Request for Comments: 1011                                     J. Postel
                                                                     ISI
Obsoletes: RFCs 991, 961, 943, 924, 901, 880, 840               May 1987


                      OFFICIAL INTERNET PROTOCOLS


STATUS OF THIS MEMO

   This memo is an official status report on the protocols used in the
   Internet community.  Distribution of this memo is unlimited.

INTRODUCTION

   This RFC identifies the documents specifying the official protocols
   used in the Internet.  Comments indicate any revisions or changes
   planned.

   To first order, the official protocols are those specified in the
   "DDN Protocol Handbook" (DPH), dated December 1985 (this is a three
   volume set with a total thickness of about 5 inches).

   Older collections that include many of these  specifications are the
   "Internet Protocol Transition Workbook" (IPTW), dated March 1982; the
   "Internet Mail Protocols", dated November 1982; and the "Internet
   Telnet Protocols and Options", dated June 1983.  There is also a
   volume of protocol related information called the "Internet Protocol
   Implementers Guide" (IPIG) dated August 1982.  An even older
   collection is the "ARPANET Protocol Handbook" (APH) dated
   January 1978.  Nearly all the relevant material from these
   collections has been reproduced in the current DPH.

   The following material is organized as a sketchy outline.  The
   entries are protocols (e.g., Transmission Control Protocol).  In each
   entry there are notes on status, specification, comments, other
   references, dependencies, and contact.

      The STATUS is one of: required, recommended, elective,
      experimental, or none.

      The SPECIFICATION identifies the protocol defining documents.

      The COMMENTS describe any differences from the specification or
      problems with the protocol.

      The OTHER REFERENCES identify documents that comment on or expand
      on the protocol.




Reynolds & Postel                                               [Page 1]



RFC 1011 - Official Internet Protocols                          May 1987
 


      The DEPENDENCIES indicate what other protocols are called upon by
      this protocol.

      The CONTACT indicates a person who can answer questions about the
      protocol.

      In particular, the status may be:

         required

            - all hosts must implement the required protocol,

         recommended

            - all hosts are encouraged to implement the recommended
            protocol,

         elective

            - hosts may implement or not the elective protocol,

         experimental

            - hosts should not implement the experimental protocol
            unless they are participating in the experiment and have
            coordinated their use of this protocol with the contact
            person, and

         none

            - this is not a protocol.

         For further information about protocols in general, please
         contact:

            Joyce K. Reynolds
            USC - Information Sciences Institute
            4676 Admiralty Way
            Marina del Rey, California  90292-6695

            Phone: [phone]

            Electronic mail: [e-mail]






Reynolds & Postel                                               [Page 2]



RFC 1011 - Official Internet Protocols                          May 1987
 


OVERVIEW

   Catenet Model  ------------------------------------------------------

      STATUS:  None

      SPECIFICATION:  IEN 48 (in DPH)

      COMMENTS:

         Gives an overview of the organization and principles of the
         Internet.

         Could be revised and expanded.

      OTHER REFERENCES:

         Leiner, B., Cole R., Postel, J., and D. Mills, "The DARPA
         Protocol Suite", IEEE INFOCOM 85, Washington, D.C., March 1985.
         Also in IEEE Communications Magazine, and as ISI/RS-85-153,
         March 1985.

         Postel, J., "Internetwork Applications Using the DARPA Protocol
         Suite", IEEE INFOCOM 85, Washington, D.C., March 1985. Also in
         IEEE Communications Magazine, and as ISI/RS-85-151, April 1985.

         Padlipsky, M.A., "The Elements of Networking Style and other
         Essays and Animadversions on the Art of Intercomputer
         Networking", Prentice-Hall, New Jersey, 1985.

         RFC 871 - A Perspective on the ARPANET Reference Model

      DEPENDENCIES:

      CONTACT: [e-mail]














Reynolds & Postel                                               [Page 3]



RFC 1011 - Official Internet Protocols                          May 1987
 


NETWORK LEVEL

   Internet Protocol  --------------------------------------------- (IP)

      STATUS:  Required

      SPECIFICATION:  RFC 791 (in DPH)

      COMMENTS:

         This is the universal protocol of the Internet.  This datagram
         protocol provides the universal addressing of hosts in the
         Internet.

         A few minor problems have been noted in this document.

         The most serious is a bit of confusion in the route options.
         The route options have a pointer that indicates which octet of
         the route is the next to be used.  The confusion is between the
         phrases "the pointer is relative to this option" and "the
         smallest legal value for the pointer is 4".  If you are
         confused, forget about the relative part, the pointer begins
         at 4.  The MIL-STD description of source routing is wrong in
         some of the details.

         Another important point is the alternate reassembly procedure
         suggested in RFC 815.

         Some changes are in the works for the security option.

         Note that ICMP is defined to be an integral part of IP.  You
         have not completed an implementation of IP if it does not
         include ICMP.

         The subnet procedures defined in RFC 950 are now considered an
         essential part of the IP architecture and must be implemented
         by all hosts and gateways.

      OTHER REFERENCES:

         RFC 815 (in DPH) - IP Datagram Reassembly Algorithms

         RFC 814 (in DPH) - Names, Addresses, Ports, and Routes

         RFC 816 (in DPH) - Fault Isolation and Recovery




Reynolds & Postel                                               [Page 4]



RFC 1011 - Official Internet Protocols                          May 1987
 


         RFC 817 (in DPH) - Modularity and Efficiency in Protocol
         Implementation

         MIL-STD-1777 (in DPH) - Military Standard Internet Protocol

         RFC 963 - Some Problems with the Specification of the Military
         Standard Internet Protocol

      DEPENDENCIES:

      CONTACT: [e-mail]

   Internet Control Message Protocol  --------------------------- (ICMP)

      STATUS:  Required

      SPECIFICATION:  RFC 792 (in DPH)

      COMMENTS:

         The control messages and error reports that go with the
         Internet Protocol.

         A few minor errors in the document have been noted.
         Suggestions have been made for additional types of redirect
         message and additional destination unreachable messages.

         Two additional ICMP message types are defined in RFC 950
         "Internet Subnets", Address Mask Request (A1=17), and Address
         Mask Reply (A2=18).

         Note that ICMP is defined to be an integral part of IP.  You
         have not completed an implementation of IP if it does not
         include ICMP.

      OTHER REFERENCES:  RFC 950

      DEPENDENCIES: Internet Protocol

      CONTACT: [e-mail]









Reynolds & Postel                                               [Page 5]



RFC 1011 - Official Internet Protocols                          May 1987
 


   Internet Group Multicast Protocol  --------------------------- (IGMP)

      STATUS:  Recommended

      SPECIFICATION:  RFC 988

      COMMENTS:

         This protocol specifies the extensions required of a host
         implementation of the Internet Protocol (IP) to support
         internetwork multicasting.  This specification supersedes that
         given in RFC 966, and constitutes a proposed protocol standard
         for IP multicasting in the Internet.  Reference RFC 966 for a
         discussion of the motivation and rationale behind the
         multicasting extension specified here.

      OTHER REFERENCES: RFC 966

      DEPENDENCIES: Internet Protocol

      CONTACT: [e-mail]




























Reynolds & Postel                                               [Page 6]



RFC 1011 - Official Internet Protocols                          May 1987
 


HOST LEVEL

   User Datagram Protocol  --------------------------------------- (UDP)

      STATUS:  Recommended

      SPECIFICATION:  RFC 768 (in DPH)

      COMMENTS:

         Provides a datagram service to applications.  Adds port
         addressing to the IP services.

         The only change noted for the UDP specification is a minor
         clarification that if in computing the checksum a padding octet
         is used for the computation it is not transmitted or counted in
         the length.

      OTHER REFERENCES:

      DEPENDENCIES: Internet Protocol

      CONTACT: [e-mail]

   Transmission Control Protocol  -------------------------------- (TCP)

      STATUS:  Recommended

      SPECIFICATION:  RFC 793 (in DPH)

      COMMENTS:

         Provides reliable end-to-end data stream service.

         Many comments and corrections have been received for the TCP
         specification document.  These are primarily document bugs
         rather than protocol bugs.

         Event Processing Section:  There are many minor corrections and
         clarifications needed in this section.

         Push:  There are still some phrases in the document that give a
         "record mark" flavor to the push.  These should be further
         clarified.  The push is not a record mark.





Reynolds & Postel                                               [Page 7]



RFC 1011 - Official Internet Protocols                          May 1987
 


         Urgent:  Page 17 is wrong.  The urgent pointer points to the
         last octet of urgent data (not to the first octet of non-urgent
         data).

         Listening Servers:  Several comments have been received on
         difficulties with contacting listening servers.  There should
         be some discussion of implementation issues for servers, and
         some notes on alternative models of system and process
         organization for servers.

         Maximum Segment Size:  The maximum segment size option should
         be generalized and clarified.  It can be used to either
         increase or decrease the maximum segment size from the default.
         The TCP Maximum Segment Size is the IP Maximum Datagram Size
         minus forty.  The default IP Maximum Datagram Size is 576.  The
         default TCP Maximum Segment Size is 536.  For further
         discussion, see RFC 879.

         Idle Connections:  There have been questions about
         automatically closing idle connections.  Idle connections are
         ok, and should not be closed.  There are several cases where
         idle connections arise, for example, in Telnet when a user is
         thinking for a long time following a message from the server
         computer before his next input.  There is no TCP "probe"
         mechanism, and none is needed.

         Queued Receive Data on Closing:  There are several points where
         it is not clear from the description what to do about data
         received by the TCP but not yet passed to the user,
         particularly when the connection is being closed.  In general,
         the data is to be kept to give to the user if he does a RECV
         call.

         Out of Order Segments:  The description says that segments that
         arrive out of order, that is, are not exactly the next segment
         to be processed, may be kept on hand.  It should also point out
         that there is a very large performance penalty for not doing
         so.

         User Time Out:  This is the time out started on an open or send
         call.  If this user time out occurs the user should be
         notified, but the connection should not be closed or the TCB
         deleted.  The user should explicitly ABORT the connection if he
         wants to give up.





Reynolds & Postel                                               [Page 8]



RFC 1011 - Official Internet Protocols                          May 1987
 


      OTHER REFERENCES:

         RFC 813 (in DPH) - Window and Acknowledgement Strategy in TCP

         RFC 814 (in DPH) - Names, Addresses, Ports, and Routes

         RFC 816 (in DPH) - Fault Isolation and Recovery

         RFC 817 (in DPH) - Modularity and Efficiency in Protocol
         Implementation

         RFC 879 - TCP Maximum Segment Size

         RFC 889 - Internet Delay Experiments

         RFC 896 - TCP/IP Congestion Control

         MIL-STD-1778 (in DPH) - Military Standard Transmission Control
         Protocol

         RFC 964 - Some Problems with the Specification of the Military
         Standard Transmission Control Protocol

         Zhang, Lixia, "Why TCP Timers Don't Work Well", Communications
         Architectures and Protocols, ACM SIGCOMM Proceedings,  Computer
         Communications Review, V.16, N.3, August 1986.

      DEPENDENCIES: Internet Protocol

      CONTACT: [e-mail]

   Bulk Data Transfer Protocol  ------------------------------- (NETBLT)

      STATUS:  Experimental

      SPECIFICATION:  RFC 998

      COMMENTS:

         This is a revised RFC on the discussion of the Network Block
         Transfer (NETBLT) protocol.

         NETBLT (NETwork BLock Transfer) is a transport level protocol
         intended for the rapid transfer of a large quantity of data
         between computers.  It provides a transfer that is reliable and
         flow controlled, and is designed to provide maximum throughput
         over a wide variety of networks.  Although NETBLT currently


Reynolds & Postel                                               [Page 9]



RFC 1011 - Official Internet Protocols                          May 1987
 


         runs on top of the Internet Protocol (IP), it should be able to
         operate on top of any datagram protocol similar in function to
         IP.

         This document is published for discussion and comment, and does
         not constitute a standard.  The proposal may change and certain
         parts of the protocol have not yet been specified;
         implementation of this document is therefore not advised.

      OTHER REFERENCES:  RFC 969

      DEPENDENCIES: Transmission Control Protocol, User Datagram
      Protocol

      CONTACT: [e-mail]

   Exterior Gateway Protocol  ------------------------------------ (EGP)

      STATUS:  Recommended for Gateways

      SPECIFICATION:  RFC 888, RFC 904 (in DPH), RFC 975, RFC 985

      COMMENTS:

         The protocol used between gateways of different administrations