From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc924.txt | 2030 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2030 insertions(+) create mode 100644 doc/rfc/rfc924.txt (limited to 'doc/rfc/rfc924.txt') diff --git a/doc/rfc/rfc924.txt b/doc/rfc/rfc924.txt new file mode 100644 index 0000000..aca1072 --- /dev/null +++ b/doc/rfc/rfc924.txt @@ -0,0 +1,2030 @@ + + +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 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 + + MIL-STD-1777 - Military Standard Internet Protocol + + DEPENDENCIES: + + CONTACT: Postel@USC-ISIF.ARPA + + + + +Reynolds & Postel [Page 4] + + + +Official ARPA-Internet Protocols RFC 924 + + + Internet Control Message Protocol --------------------------- (ICMP) + + STATUS: Required + + SPECIFICATION: RFC 792 (in IPTW) + + 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. + + A proposal for two additional ICMP message types is made in + RFC 917 "Internet Subnets", Address Format Request (A1=17), and + Address Format Reply (A2=18). Use of these ICMP types is + experimental. + + 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 917 + + DEPENDENCIES: Internet Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + + + + + + + + + + + + + + + + + + + + + +Reynolds & Postel [Page 5] + + + +Official ARPA-Internet Protocols RFC 924 + + +HOST LEVEL + + User Datagram Protocol --------------------------------------- (UDP) + + STATUS: Recommended + + SPECIFICATION: RFC 768 (in IPTW) + + 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@USC-ISIF.ARPA + + Transmission Control Protocol -------------------------------- (TCP) + + STATUS: Recommended + + SPECIFICATION: RFC 793 (in IPTW) + + 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. + + Urgent: Page 17 is wrong. The urgent pointer points to the + last octet of urgent data (not to the first octet of non-ungent + data). + + + +Reynolds & Postel [Page 6] + + + +Official ARPA-Internet Protocols RFC 924 + + + 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 if 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: + + RFC 813 (in IPIG) - Window and Acknowledgement Strategy in TCP + + RFC 814 (in IPIG) - Names, Addresses, Ports, and Routes + + RFC 816 (in IPIG) - Fault Isolation and Recovery + + + +Reynolds & Postel [Page 7] + + + +Official ARPA-Internet Protocols RFC 924 + + + RFC 817 (in IPIG) - 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 - Military Standard Transmission Control Protocol + + DEPENDENCIES: Internet Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Host Monitoring Protocol ------------------------------------- (HMP) + + STATUS: Elective + + SPECIFICATION: RFC 869 + + COMMENTS: + + This is a good tool for debugging protocol implementations in + remotely located computers. + + This protocol is used to monitor Internet gateways and the + TACs. + + OTHER REFERENCES: + + DEPENDENCIES: Internet Protocol + + CONTACT: Hinden@BBN-UNIX.ARPA + + Cross Net Debugger ------------------------------------------ (XNET) + + STATUS: Elective + + SPECIFICATION: IEN 158 + + COMMENTS: + + A debugging protocol, allows debugger like access to remote + systems. + + This specification should be updated and reissued as an RFC. + + OTHER REFERENCES: RFC 643 + + +Reynolds & Postel [Page 8] + + + +Official ARPA-Internet Protocols RFC 924 + + + DEPENDENCIES: Internet Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + "Stub" Exterior Gateway Protocol ----------------------------- (EGP) + + STATUS: Recommended for Gateways + + SPECIFICATION: RFC 888, RFC 904 + + COMMENTS: + + The protocol used between gateways of different administrations + to exchange routing information. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: RFC 827, RFC 890 + + DEPENDENCIES: Internet Protocol + + CONTACT: Mills@USC-ISID.ARPA + + Gateway Gateway Protocol ------------------------------------- (GGP) + + STATUS: Experimental + + SPECIFICATION: RFC 823 + + COMMENTS: + + The gateway protocol now used in the core gateways. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + DEPENDENCIES: Internet Protocol + + CONTACT: Brescia@BBN-UNIX.ARPA + + + + + + + + + +Reynolds & Postel [Page 9] + + + +Official ARPA-Internet Protocols RFC 924 + + + Multiplexing Protocol ---------------------------------------- (MUX) + + STATUS: Experimental + + SPECIFICATION: IEN 90 + + COMMENTS: + + Defines a capability to combine several segments from different + higher level protocols in one IP datagram. + + No current experiment in progress. There is some question as + to the extent to which the sharing this protocol envisions can + actually take place. Also, there are some issues about the + information captured in the multiplexing header being (a) + insufficient, or (b) over specific. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + DEPENDENCIES: Internet Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Stream Protocol ----------------------------------------------- (ST) + + STATUS: Experimental + + SPECIFICATION: IEN 119 + + COMMENTS: + + A gateway resource allocation protocol designed for use in + multihost real time applications. + + The implementation of this protocol has evolved and may no + longer be consistent with this specification. The document + should be updated and issued as an RFC. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + DEPENDENCIES: Internet Protocol + + CONTACT: jwf@LL-EN.ARPA + + +Reynolds & Postel [Page 10] + + + +Official ARPA-Internet Protocols RFC 924 + + + Network Voice Protocol ------------------------------------ (NVP-II) + + STATUS: Experimental + + SPECIFICATION: ISI Internal Memo + + COMMENTS: + + Defines the procedures for real time voice conferencing. + + The specification is an ISI Internal Memo which should be + updated and issued as an RFC. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: RFC 741 + + DEPENDENCIES: Internet Protocol, Stream Protocol + + CONTACT: Casner@USC-ISIB.ARPA + + Reliable Data Protocol --------------------------------------- (RDP) + + STATUS: Experimental + + SPECIFICATION: RFC 908 + + COMMENTS: + + This protocol is designed to efficiently support the bulk + transfer of data for such host monitoring and control + applications as loading/dumping and remote debugging. The + protocol is intended to be simple to implement but still be + efficient in environments where there may be long transmission + delays and loss or non-sequential delivery of message segments. + + OTHER REFERENCES: + + DEPENDENCIES: Internet Protocol + + CONTACT: CWelles@BBN-UNIX.ARPA + + + + + + + + + +Reynolds & Postel [Page 11] + + + +Official ARPA-Internet Protocols RFC 924 + + +APPLICATION LEVEL + + Telnet Protocol ------------------------------------------- (TELNET) + + STATUS: Recommended + + SPECIFICATION: RFC 854 (in "Internet Telnet Protocol and + Options") + + COMMENTS: + + The protocol for remote terminal access. + + This has been revised since the IPTW. RFC 764 in IPTW is now + obsolete. + + OTHER REFERENCES: + + MIL-STD-1782 - Telnet Protocol and Options (TELNET) + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Reynolds & Postel [Page 12] + + + +Official ARPA-Internet Protocols RFC 924 + + + Telnet Options ------------------------------------ (TELNET-OPTIONS) + + STATUS: Elective + + SPECIFICATION: General description of options: RFC 855 + (in "Internet Telnet Protocol and Options") + + Number Name RFC NIC ITP APH USE + ------ --------------------------------- --- ----- --- --- --- + 0 Binary Transmission 856 ----- yes obs yes + 1 Echo 857 ----- yes obs yes + 2 Reconnection ... 15391 no yes no + 3 Suppress Go Ahead 858 ----- yes obs yes + 4 Approx Message Size Negotiation ... 15393 no yes no + 5 Status 859 ----- yes obs yes + 6 Timing Mark 860 ----- yes obs yes + 7 Remote Controlled Trans and Echo 726 39237 no yes no + 8 Output Line Width ... 20196 no yes no + 9 Output Page Size ... 20197 no yes no + 10 Output Carriage-Return Disposition 652 31155 no yes no + 11 Output Horizontal Tabstops 653 31156 no yes no + 12 Output Horizontal Tab Disposition 654 31157 no yes no + 13 Output Formfeed Disposition 655 31158 no yes no + 14 Output Vertical Tabstops 656 31159 no yes no + 15 Output Vertical Tab Disposition 657 31160 no yes no + 16 Output Linefeed Disposition 658 31161 no yes no + 17 Extended ASCII 698 32964 no yes no + 18 Logout 727 40025 no yes no + 19 Byte Macro 735 42083 no yes no + 20 Data Entry Terminal 732 41762 no yes no + 21 SUPDUP 734 736 42213 no yes no + 22 SUPDUP Output 749 45449 no no no + 23 Send Location 779 ----- no no no + 24 Terminal Type 884 ----- no no yes + 25 End of Record 885 ----- no no yes + 255 Extended-Options-List 861 ----- yes obs yes + + (obs = obsolete) + + The ITP column indicates if the specification is included in the + Internet Telnet Protocol and Options. The APH column indicates if + the specification is included in the ARPANET Protocol Handbook. + The USE column of the table above indicates which options are in + general use. + + COMMENTS: + + The Binary Transmission, Echo, Suppress Go Ahead, Status, + Timing Mark, and Extended Options List options have been + + +Reynolds & Postel [Page 13] + + + +Official ARPA-Internet Protocols RFC 924 + + + recently updated and reissued. These are the most frequently + implemented options. + + The remaining options should be reviewed and the useful ones + should be revised and reissued. The others should be + eliminated. + + The following are recommended: Binary Transmission, Echo, + Suppress Go Ahead, Status, Timing Mark, and Extended Options + List. + + OTHER REFERENCES: + + DEPENDENCIES: Telnet + + CONTACT: Postel@USC-ISIF.ARPA + + File Transfer Protocol --------------------------------------- (FTP) + + STATUS: Recommended + + SPECIFICATION: RFC 765 (in IPTW) + + COMMENTS: + + The protocol for moving files between Internet hosts. Provides + for access control and negotiation of file parameters. + + There are a number of minor corrections to be made. A major + change is the deletion of the mail commands, and a major + clarification is needed in the discussion of the management of + the data connection. Also, a suggestion has been made to + include some directory manipulation commands (RFC 775). + + Even though the MAIL features are defined in this document, + they are not to be used. The SMTP protocol is to be used for + all mail service in the Internet. + + Data Connection Management: + + a. Default Data Connection Ports: All FTP implementations + must support use of the default data connection ports, and + only the User-PI may initiate the use of non-default ports. + + b. Negotiating Non-Default Data Ports: The User-PI may + specify a non-default user side data port with the PORT + command. The User-PI may request the server side to + identify a non-default server side data port with the PASV + command. Since a connection is defined by the pair of + + +Reynolds & Postel [Page 14] + + + +Official ARPA-Internet Protocols RFC 924 + + + addresses, either of these actions is enough to get a + different data connection, still it is permitted to do both + commands to use new ports on both ends of the data + connection. + + c. Reuse of the Data Connection: When using the stream + mode of data transfer the end of the file must be indicated + by closing the connection. This causes a problem if + multiple files are to be transfered in the session, due to + need for TCP to hold the connection record for a time out + period to guarantee the reliable communication. Thus the + connection can not be reopened at once. + + There are two solutions to this problem. The first is to + negotiate a non-default port (as in (b) above). The + second is to use another transfer mode. + + A comment on transfer modes. The stream transfer mode is + inherently unreliable, since one can not determine if the + connection closed prematurely or not. The other transfer + modes (Block, Compressed) do not close the connection to + indicate the end of file. They have enough FTP encoding + that the data connection can be parsed to determine the + end of the file. Thus using these modes one can leave + the data connection open for multiple file transfers. + + Why this was not a problem with the old NCP FTP: + + The NCP was designed with only the ARPANET in mind. + The ARPANET provides very reliable service, and the + NCP counted on it. If any packet of data from an NCP + connection were lost or damaged by the network the NCP + could not recover. It is a tribute to the ARPANET + designers that the NCP FTP worked so well. + + The TCP is designed to provide reliable connections + over many different types of networks and + interconnections of networks. TCP must cope with a + set of networks that can not promise to work as well + as the ARPANET. TCP must make its own provisions for + end-to-end recovery from lost or damaged packets. + This leads to the need for the connection phase-down + time-out. The NCP never had to deal with + acknowledgements or retransmissions or many other + things the TCP must do to make connection reliable in + a more complex world. + + + + + +Reynolds & Postel [Page 15] + + + +Official ARPA-Internet Protocols RFC 924 + + + LIST and NLST: + + There is some confusion about the LIST an NLST commands, and + what is appropriate to return. Some clarification and + motivation for these commands should be added to the + specification. + + OTHER REFERENCES: + + RFC 678 - Document File Format Standards + + MIL-STD-1780 - File Transfer Protocol (FTP) + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Trivial File Transfer Protocol ------------------------------ (TFTP) + + STATUS: Elective + + SPECIFICATION: RFC 783 (in IPTW) + + COMMENTS: + + A very simple file moving protocol, no access control is + provided. + + This is in use in several local networks. + + Ambiguities in the interpretation of several of the transfer + modes should be clarified, and additional transfer modes could + be defined. Additional error codes could be defined to more + clearly identify problems. + + OTHER REFERENCES: + + DEPENDENCIES: User Datagram Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + + + + + + + + + + +Reynolds & Postel [Page 16] + + + +Official ARPA-Internet Protocols RFC 924 + + + Simple File Transfer Protocol ------------------------------- (SFTP) + + STATUS: Experimental + + SPECIFICATION: RFC 913 + + COMMENTS: + + SFTP is a simple file transfer protocol. It fills the need of + people wanting a protocol that is more useful than TFTP but + easier to implement (and less powerful) than FTP. SFTP + supports user access control, file transfers, directory + listing, directory changing, file renaming and deleting. + + SFTP can be implemented with any reliable 8-bit byte stream + oriented protocol, this document describes its TCP + specification. SFTP uses only one TCP connection; whereas TFTP + implements a connection over UDP, and FTP uses two TCP + connections (one using the TELNET protocol). + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: MKL@MIT-XX.ARPA + + Simple Mail Transfer Protocol ------------------------------- (SMTP) + + STATUS: Recommended + + SPECIFICATION: RFC 821 (in "Internet Mail Protocols") + + COMMENTS: + + The procedure for transmitting computer mail between hosts. + + This has been revised since the IPTW, it is in the "Internet + Mail Protocols" volume of November 1982. RFC 788 (in IPTW) is + obsolete. + + There have been many misunderstandings and errors in the early + implementations. Some documentation of these problems can be + found in the file [ISIF]MAIL.ERRORS. + + Some minor differences between RFC 821 and RFC 822 should be + resolved. + + +Reynolds & Postel [Page 17] + + + +Official ARPA-Internet Protocols RFC 924 + + + OTHER REFERENCES: + + RFC 822 - Mail Header Format Standards + + This has been revised since the IPTW, it is in the "Internet + Mail Protocols" volume of November 1982. RFC 733 (in IPTW) + is obsolete. Further revision of RFC 822 is needed to + correct some minor errors in the details of the + specification. + + MIL-STD-1781 - Simple Mail Transfer Protocol (SMTP) + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Resource Location Protocol ----------------------------------- (RLP) + + STATUS: Elective + + SPECIFICATION: RFC 887 + + COMMENTS: + + A resource location protocol for use in the ARPA-Internet. + This protocol utilizes the User Datagram Protocol (UDP) which + in turn calls on the Internet Protocol to deliver its + datagrams. + + OTHER REFERENCES: + + DEPENDENCIES: User Datagram Protocol + + CONTACT: Accetta@CMU-CS-A.ARPA + + Loader Debugger Protocol ------------------------------------- (LDP) + + STATUS: Experimental + + SPECIFICATION: RFC 909 + + COMMENTS: + + Specifies a protocol for loading, dumping and debugging target + machines from hosts in a network environment. It is also + designed to accommodate a variety of target CPU types. It + provides a powerful set of debugging services, while at the + same time, it is structured so that a simple subset may be + + + +Reynolds & Postel [Page 18] + + + +Official ARPA-Internet Protocols RFC 924 + + + implemented in applications like boot loading where efficiency + and space are at a premium. + + OTHER REFERENCES: + + DEPENDENCIES: Reliable Data Protocol + + CONTACT: Hinden@BBN-UNIX.ARPA + + Remote Job Entry --------------------------------------------- (RJE) + + STATUS: Elective + + SPECIFICATION: RFC 407 (in APH) + + COMMENTS: + + The general protocol for submitting batch jobs and retrieving + the results. + + Some changes needed for use with TCP. + + No known active implementations. + + OTHER REFERENCES: + + DEPENDENCIES: File Transfer Protocol + Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Remote Job Service ---------------------------------------- (NETRJS) + + STATUS: Elective + + SPECIFICATION: RFC 740 (in APH) + + COMMENTS: + + A special protocol for submitting batch jobs and retrieving the + results used with the UCLA IBM OS system. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + Revision in progress. + + OTHER REFERENCES: + + + +Reynolds & Postel [Page 19] + + + +Official ARPA-Internet Protocols RFC 924 + + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Braden@USC-ISIA.ARPA + + Remote Telnet Service ------------------------------------ (RTELNET) + + STATUS: Elective + + SPECIFICATION: RFC 818 + + COMMENTS: + + Provides special access to user Telnet on a remote system. + + OTHER REFERENCES: + + DEPENDENCIES: Telnet, Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Graphics Protocol --------------------------------------- (GRAPHICS) + + STATUS: Elective + + SPECIFICATION: NIC 24308 (in APH) + + COMMENTS: + + The protocol for vector graphics. + + Very minor changes needed for use with TCP. + + No known active implementations. + + OTHER REFERENCES: + + DEPENDENCIES: Telnet, Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + + + + + + + + + + + +Reynolds & Postel [Page 20] + + + +Official ARPA-Internet Protocols RFC 924 + + + Echo Protocol ----------------------------------------------- (ECHO) + + STATUS: Recommended + + SPECIFICATION: RFC 862 + + COMMENTS: + + Debugging protocol, sends back whatever you send it. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + or User Datagram Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Discard Protocol ----------------------------------------- (DISCARD) + + STATUS: Elective + + SPECIFICATION: RFC 863 + + COMMENTS: + + Debugging protocol, throws away whatever you send it. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + or User Datagram Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Character Generator Protocol ----------------------------- (CHARGEN) + + STATUS: Elective + + SPECIFICATION: RFC 864 + + COMMENTS: + + Debugging protocol, sends you ASCII data. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + or User Datagram Protocol + + + +Reynolds & Postel [Page 21] + + + +Official ARPA-Internet Protocols RFC 924 + + + CONTACT: Postel@USC-ISIF.ARPA + + Quote of the Day Protocol ---------------------------------- (QUOTE) + + STATUS: Elective + + SPECIFICATION: RFC 865 + + COMMENTS: + + Debugging protocol, sends you a short ASCII message. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + or User Datagram Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Active Users Protocol -------------------------------------- (USERS) + + STATUS: Elective + + SPECIFICATION: RFC 866 + + COMMENTS: + + Lists the currently active users. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + or User Datagram Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Authentication Service -------------------------------------- (AUTH) + + STATUS: Experimental + + SPECIFICATION: RFC 912 + + COMMENTS: + + The Authentication Server provides a means to determine the + identity of a user of a particular TCP connection. Given a TCP + port number pair, it returns a character string which + identifies the owner of that connection on the server's system. + Suggested uses include automatic identification and + + +Reynolds & Postel [Page 22] + + + +Official ARPA-Internet Protocols RFC 924 + + + verification of a user during an FTP session, additional + verification of a TAC dial up user, and access verification for + a generalized network file server. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: StJohns@MIT-MULTICS.ARPA + + Finger Protocol ------------------------------------------- (FINGER) + + STATUS: Elective + + SPECIFICATION: RFC 742 (in APH) + + COMMENTS: + + Provides information on the current or most recent activity of + a user. + + Some extensions have been suggested. + + Some changes are are needed for TCP. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + WhoIs Protocol ------------------------------------------- (NICNAME) + + STATUS: Elective + + SPECIFICATION: RFC 812 (in IPTW) + + COMMENTS: + + Accesses the ARPANET Directory database. Provides a way to + find out about people, their addresses, phone numbers, + organizations, and mailboxes. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + + +Reynolds & Postel [Page 23] + + + +Official ARPA-Internet Protocols RFC 924 + + + CONTACT: Feinler@SRI-NIC.ARPA + + Domain Name Protocol -------------------------------------- (DOMAIN) + + STATUS: Experimental + + SPECIFICATION: RFC 881, 882, 883 + + COMMENTS: + + OTHER REFERENCES: + + RFC 920 - Domain Requirements + + RFC 921 - Domain Name Implementation Schedule - Revised + + DEPENDENCIES: Transmission Control Protocol + or User Datagram Protocol + + CONTACT: Mockapetris@USC-ISIF.ARPA + + HOSTNAME Protocol --------------------------------------- (HOSTNAME) + + STATUS: Elective + + SPECIFICATION: RFC 811 (in IPTW) + + COMMENTS: + + Accesses the Registered Internet Hosts database (HOSTS.TXT). + Provides a way to find out about a host in the Internet, its + Internet Address, and the protocols it implements. + + OTHER REFERENCES: + + RFC 810 - Host Table Specification + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Feinler@SRI-NIC.ARPA + + + + + + + + + + + +Reynolds & Postel [Page 24] + + + +Official ARPA-Internet Protocols RFC 924 + + + Host Name Server Protocol ----------------------------- (NAMESERVER) + + STATUS: Experimental + + SPECIFICATION: IEN 116 (in IPTW) + + COMMENTS: + + Provides machine oriented procedure for translating a host name + to an Internet Address. + + This specification has significant problems: 1) The name + syntax is out of date. 2) The protocol details are ambiguous, + in particular, the length octet either does or doesn't include + itself and the op code. 3) The extensions are not supported by + any known implementation. + + This protocol is now abandon in favor of the DOMAIN protocol. + Further implementations of this protocol are not advised. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + DEPENDENCIES: User Datagram Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + CSNET Mailbox Name Server Protocol ---------------------- (CSNET-NS) + + STATUS: Experimental + + SPECIFICATION: CS-DN-2 + + COMMENTS: + + Provides access to the CSNET data base of users to give + information about users names, affiliations, and mailboxes. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Solomon@UWISC.ARPA + + + +Reynolds & Postel [Page 25] + + + +Official ARPA-Internet Protocols RFC 924 + + + Daytime Protocol ----------------------------------------- (DAYTIME) + + STATUS: Elective + + SPECIFICATION: RFC 867 + + COMMENTS: + + Provides the day and time in ASCII character string. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + or User Datagram Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Time Server Protocol ---------------------------------------- (TIME) + + STATUS: Recommended + + SPECIFICATION: RFC 868 + + COMMENTS: + + Provides the time as the number of seconds from a specified + reference time. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + or User Datagram Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + + + + + + + + + + + + + + + + +Reynolds & Postel [Page 26] + + + +Official ARPA-Internet Protocols RFC 924 + + + DCNET Time Server Protocol --------------------------------- (CLOCK) + + STATUS: Elective + + SPECIFICATION: RFC 778 + + COMMENTS: + + Provides a mechanism for keeping synchronized clocks. + + OTHER REFERENCES: + + DEPENDENCIES: Internet Control Message Protocol + + CONTACT: Mills@USC-ISID.ARPA + + SUPDUP Protocol ------------------------------------------- (SUPDUP) + + STATUS: Elective + + SPECIFICATION: RFC 734 (in APH) + + COMMENTS: + + A special Telnet like protocol for display terminals. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Crispin@SU-SCORE.ARPA + + + + + + + + + + + + + + + + + + + + +Reynolds & Postel [Page 27] + + + +Official ARPA-Internet Protocols RFC 924 + + + Internet Message Protocol ------------------------------------ (MPM) + + STATUS: Experimental + + SPECIFICATION: RFC 759 + + COMMENTS: + + This is an experimental multimedia mail transfer protocol. The + implementation is called a Message Processing Module or MPM. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + RFC 767 - Structured Document Formats + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Post Office Protocol ----------------------------------------- (POP) + + STATUS: Experimental + + SPECIFICATION: RFC 918 + + COMMENTS: + + The intent of the Post Office Protocol (POP) is to allow a + user's workstation to access mail from a mailbox server. It is + expected that mail will be posted from the workstation to the + mailbox server via the Simple Mail Transfer Protocol (SMTP). + For further information see RFC-821 and RFC-822. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: JKReynolds@USC-ISIF.ARPA + + + + + + + +Reynolds & Postel [Page 28] + + + +Official ARPA-Internet Protocols RFC 924 + + + Network Standard Text Editor ------------------------------- (NETED) + + STATUS: Elective + + SPECIFICATION: RFC 569 + + COMMENTS: + + Describes a simple line editor which could be provided by every + Internet host. + + OTHER REFERENCES: + + DEPENDENCIES: + + CONTACT: Postel@USC-ISIF.ARPA + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Reynolds & Postel [Page 29] + + + +Official ARPA-Internet Protocols RFC 924 + + +APPENDICES + + Assigned Numbers --------------------------------------------------- + + STATUS: None + + SPECIFICATION: RFC 923 + + COMMENTS: + + Describes the fields of various protocols that are assigned + specific values for actual use, and lists the currently + assigned values. + + Issued October 1984, replaces RFC 900, RFC 790 in IPTW, and + RFC 870. + + OTHER REFERENCES: + + CONTACT: JKReynolds@USC-ISIF.ARPA + + Pre-emption -------------------------------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 794 (in IPTW) + + COMMENTS: + + Describes how to do pre-emption of TCP connections. + + OTHER REFERENCES: + + CONTACT: Postel@USC-ISIF.ARPA + + + + + + + + + + + + + + + + + +Reynolds & Postel [Page 30] + + + +Official ARPA-Internet Protocols RFC 924 + + + Service Mappings --------------------------------------------------- + + STATUS: None + + SPECIFICATION: RFC 795 (in IPTW) + + COMMENTS: + + Describes the mapping of the IP type of service field onto the + parameters of some specific networks. + + Out of date, needs revision. + + OTHER REFERENCES: + + CONTACT: Postel@USC-ISIF.ARPA + + Address Mappings --------------------------------------------------- + + STATUS: None + + SPECIFICATION: RFC 796 (in IPTW) + + COMMENTS: + + Describes the mapping between Internet Addresses and the + addresses of some specific networks. + + Out of date, needs revision. + + OTHER REFERENCES: + + CONTACT: Postel@USC-ISIF.ARPA + + Document Formats --------------------------------------------------- + + STATUS: None + + SPECIFICATION: RFC 678 + + COMMENTS: + + Describes standard format rules for several types of documents. + + OTHER REFERENCES: + + CONTACT: Postel@USC-ISIF.ARPA + + + + +Reynolds & Postel [Page 31] + + + +Official ARPA-Internet Protocols RFC 924 + + + Bitmap Formats ----------------------------------------------------- + + STATUS: None + + SPECIFICATION: RFC 797 + + COMMENTS: + + Describes a standard format for bitmap data. + + OTHER REFERENCES: + + CONTACT: Postel@USC-ISIF.ARPA + + Facsimile Formats -------------------------------------------------- + + STATUS: None + + SPECIFICATION: RFC 804 + + COMMENTS: + + Describes a standard format for facsimile data. + + OTHER REFERENCES: + + CONTACT: Postel@USC-ISIF.ARPA + + Internet Protocol on X.25 Networks --------------------------------- + + STATUS: Recommended + + SPECIFICATION: RFC 877 + + COMMENTS: + + Describes a standard for the transmission of IP Datagrams over + Public Data Networks. + + OTHER REFERENCES: + + CONTACT: jtk@PURDUE.ARPA + + + + + + + + + +Reynolds & Postel [Page 32] + + + +Official ARPA-Internet Protocols RFC 924 + + + Internet Protocol on DC Networks ----------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 891 + + COMMENTS: + + OTHER REFERENCES: + + RFC 778 - DCNET Internet Clock Service + + CONTACT: Mills@USC-ISID.ARPA + + Internet Protocol on Ethernet Networks ----------------------------- + + STATUS: Recommended + + SPECIFICATION: RFC 894 + + COMMENTS: + + OTHER REFERENCES: RFC 893 + + CONTACT: Postel@USC-ISIF.ARPA + + Internet Protocol on Experimental Ethernet Networks ---------------- + + STATUS: Recommended + + SPECIFICATION: RFC 895 + + COMMENTS: + + OTHER REFERENCES: + + CONTACT: Postel@USC-ISIF.ARPA + + + + + + + + + + + + + + +Reynolds & Postel [Page 33] + + + +Official ARPA-Internet Protocols RFC 924 + + + Address Resolution Protocol ---------------------------------- (ARP) + + STATUS: Recommended + + SPECIFICATION: RFC 826 + + COMMENTS: + + This is a procedure for finding the network hardware address + corresponding to an Internet Address. + + OTHER REFERENCES: + + CONTACT: Postel@USC-ISIF.ARPA + + A Reverse Address Resolution Protocol ----------------------- (RARP) + + STATUS: Elective + + SPECIFICATION: RFC 903 + + COMMENTS: + + This is a procedure for workstations to dynamically find their + protocol address (e.g., their Internet Address), when they only + only know their hardware address (e.g., their attached physical + network address). + + OTHER REFERENCES: + + CONTACT: Mogul@SU-SCORE.ARPA + + Host Access Protocol ----------------------------------------- (HAP) + + STATUS: Recommended + + SPECIFICATION: RFC 907 + + COMMENTS: + + This protocol specifies the network-access level communication + between an arbitrary computer, called a host, and a + packet-switched satellite network, e.g., SATNET or WBNET. + + Note: Implementations of HAP should be performed in + coordination with satellite network development and operations + personnel. + + OTHER REFERENCES: + + +Reynolds & Postel [Page 34] + + + +Official ARPA-Internet Protocols RFC 924 + + + DEPENDENCIES: + + CONTACT: Schoen@BBN-UNIX.ARPA + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Reynolds & Postel [Page 35] + -- cgit v1.2.3