Official ARPA-Internet protocols for connecting personal computers to the Internet
RFC 924
Document | Type |
RFC - Unknown
(October 1984; No errata)
Obsoleted by RFC 944
Obsoletes RFC 901
|
|
---|---|---|---|
Authors | |||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 924 (Unknown) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group J. Reynolds Request for Comments: 924 J. Postel ISI Obsoletes: RFCs 901, 880, 840 October 1984 OFFICIAL ARPA-INTERNET PROTOCOLS STATUS 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 in the "Internet Protocol Transition Workbook" (IPTW) dated March 1982. There are several protocols in use that are not in the IPTW. A few of the protocols in the IPTW have been revised. Notably, the mail protocols have been revised and issued as a volume titled "Internet Mail Protocols" dated November 1982. Telnet and the most useful Telnet options have been revised and issued as a volume titled "Internet Telnet Protocol and Options" (ITP) dated June 1983. Some protocols have not been revised for many years, these are found in the old "ARPANET Protocol Handbook" (APH) dated January 1978. There is also a volume of protocol related information called the "Internet Protocol Implementers Guide" (IPIG) dated August 1982. 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, or experimental. 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. The DEPENDENCIES indicate what other protocols are called upon by this protocol. Reynolds & Postel [Page 1] Official ARPA-Internet Protocols RFC 924 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 Reynolds USC - Information Sciences Institute 4676 Admiralty Way Marina del Rey, California 90292-6695 Phone: (213) 822-1511 ARPA mail: JKREYNOLDS@USC-ISIF.ARPA Reynolds & Postel [Page 2] Official ARPA-Internet Protocols RFC 924 OVERVIEW Catenet Model ------------------------------------------------------ STATUS: None SPECIFICATION: IEN 48 (in IPTW) COMMENTS: Gives an overview of the organization and principles of the Internet. Could be revised and expanded. OTHER REFERENCES: RFC 871 - A Perspective on the ARPANET Reference Model DEPENDENCIES: CONTACT: Postel@USC-ISIF.ARPA Reynolds & Postel [Page 3] Official ARPA-Internet Protocols RFC 924 NETWORK LEVEL Internet Protocol --------------------------------------------- (IP) STATUS: Required SPECIFICATION: RFC 791 (in IPTW) 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. Another important point is the alternate reassembly procedureShow full document text