Official protocols
RFC 880

Document Type RFC - Historic (October 1983; No errata)
Obsoleted by RFC 901
Obsoletes RFC 840
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 880 (Historic)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        J. Reynolds
Request for Comments: 880                                      J. Postel
                                                                     ISI
Obsoletes: RFC 840                                          October 1983

                           OFFICIAL PROTOCOLS

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.

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

Reynolds & Postel                                               [Page 1]



Official Protocols                                               RFC 880

   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.

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

Reynolds & Postel                                               [Page 2]



Official Protocols                                               RFC 880

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.

         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 IPIG) - IP Datagram Reassembly Algorithms

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

         RFC 816 (in IPIG) - Fault Isolation and Recovery

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

      DEPENDENCIES:

      CONTACT: Postel@USC-ISIF

Reynolds & Postel                                               [Page 3]



Official Protocols                                               RFC 880

   Internet Control Message Protocol (ICMP)  ---------------------------
Show full document text