Official ARPA-Internet protocols
RFC 901
Document | Type |
RFC - Unknown
(June 1984; No errata)
Obsoleted by RFC 924
Obsoletes RFC 880
|
|
---|---|---|---|
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 901 (Unknown) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group J. Reynolds
Request for Comments: 901 J. Postel
ISI
Obsoletes: RFCs 880, 840 June 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.
Introduction
This RFC identifies the documents specifying the official protocols
used in the Internet. Annotations identify 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 option
protocols were issued by the NIC in a booklet entitled "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 901
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 901
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
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 procedure
suggested in RFC 815.
Reynolds & Postel [Page 3]
Official ARPA-Internet Protocols RFC 901
Show full document text