📄 rfc991.txt
字号:
Network Working Group J. ReynoldsRequest for Comments: 991 J. Postel ISIObsoletes: RFCs 961, 943, 924, 901, 880, 840 November 1986 OFFICIAL ARPA-INTERNET PROTOCOLSSTATUS OF THIS MEMO This memo is an official status report on the protocols used in the ARPA-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. This document 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 991 November 1986Official ARPA-Internet Protocols 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: (213) 822-1511 ARPA mail: JKREYNOLDS@ISI.EDUReynolds & Postel [Page 2] RFC 991 November 1986Official ARPA-Internet ProtocolsOVERVIEW 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: Postel@ISI.EDUReynolds & Postel [Page 3] RFC 991 November 1986Official ARPA-Internet ProtocolsNETWORK 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. 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 RFC 817 (in DPH) - Modularity and Efficiency in Protocol Implementation MIL-STD-1777 (in DPH) - Military Standard Internet ProtocolReynolds & Postel [Page 4] RFC 991 November 1986Official ARPA-Internet Protocols RFC 963 - Some Problems with the Specification of the Military Standard Internet Protocol DEPENDENCIES: CONTACT: Postel@ISI.EDU 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: Postel@ISI.EDUReynolds & Postel [Page 5] RFC 991 November 1986Official ARPA-Internet Protocols 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 ARPA-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: Deering@PESCADERO.STANFORD.EDUReynolds & Postel [Page 6] RFC 991 November 1986Official ARPA-Internet ProtocolsHOST 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: Postel@ISI.EDU 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 991 November 1986Official ARPA-Internet Protocols 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. OTHER REFERENCES:Reynolds & Postel [Page 8] RFC 991 November 1986Official ARPA-Internet Protocols 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: Postel@ISI.EDUReynolds & Postel [Page 9] RFC 991 November 1986Official ARPA-Internet Protocols Host Monitoring Protocol ------------------------------------- (HMP) STATUS: Elective SPECIFICATION: RFC 869 (in DPH)⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -