RFC 924

Official ARPA-Internet protocols for connecting personal computers to the Internet

📅 published October 1984, from ietf

RFC 924: Official ARPA-Internet Protocols 🎀

bestie, this one is the official list of which protocols the ARPA-Internet community was actually using. It's titled OFFICIAL ARPA-INTERNET PROTOCOLS, written by J. Reynolds and J. Postel at ISI, dated October 1984. It obsoletes RFCs 901, 880, and 840 📝 and it's an official status report rather than a protocol spec itself 💅.

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 ✨.

Okay so, to first order, the official protocols are the ones in the "Internet Protocol Transition Workbook" (IPTW) dated March 1982. There are a bunch of protocols in use that aren't in the IPTW, and a few of the IPTW ones have been revised. The mail protocols got revised and issued as a volume called "Internet Mail Protocols" dated November 1982 📬. Telnet and the most useful Telnet options got their own glow-up too, in "Internet Telnet Protocol and Options" (ITP) dated June 1983 💜. Some protocols haven't been touched in years, and those live in the old "ARPANET Protocol Handbook" (APH) dated January 1978 🕰️. There's also "Internet Protocol Implementers Guide" (IPIG) dated August 1982, which is basically the helpful companion 🧚.

This document is a sketchy outline. The entries are protocols (for example, Transmission Control Protocol), and each entry has 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.

Here's the breakdown of what each status can 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.
  • none: this is not a protocol.

For further information about protocols in general, reach out to:

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

OVERVIEW 🌈

Catenet Model 🌐

STATUS: None SPECIFICATION: IEN 48 (in IPTW)

COMMENTS:

Gives an overview of the organization and principles of the Internet. This one is giving big foundations energy ✨. It could be revised and expanded.

OTHER REFERENCES:

  • RFC 871 - A Perspective on the ARPANET Reference Model

DEPENDENCIES: none listed

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, and it's the main character 👑. 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 one 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're 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: none listed

CONTACT: Postel@USC-ISIF.ARPA

Internet Control Message Protocol (ICMP) 🍓

STATUS: Required SPECIFICATION: RFC 792 (in IPTW)

COMMENTS:

These are the control messages and error reports that go with the Internet Protocol, so they're the support squad 🫶. 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

HOST LEVEL 🌸

User Datagram Protocol (UDP) 🦋

STATUS: Recommended

SPECIFICATION: RFC 768 (in IPTW)

COMMENTS:

UDP gives applications a datagram service and adds port addressing on top of IP. It's the lightweight sibling everyone brings to the party 💅

The only change noted for the UDP spec is a small clarification. If a padding octet gets used when computing the checksum, it is not transmitted and not counted in the length. Tiny detail, big vibes 🤏✨

OTHER REFERENCES: None listed.

DEPENDENCIES: Internet Protocol

CONTACT: Postel@USC-ISIF.ARPA

Transmission Control Protocol (TCP) 💜

STATUS: Recommended

SPECIFICATION: RFC 793 (in IPTW)

COMMENTS:

TCP is the reliable end-to-end data stream service, and it has been through a lot 😭 Lots of comments and corrections came in, but they're mostly about the document, not the protocol itself. The protocol is fine, the paperwork just needed some love 🧚

  • Event Processing Section: There are many minor corrections and clarifications needed in this section.
  • Push: Some phrases still give the push a "record mark" flavor. Those should be clarified further. The push is not a record mark, bestie 🙅‍♀️
  • 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 people had trouble contacting listening servers. The document should discuss implementation issues for servers, plus 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: People asked about automatically closing idle connections. Idle connections are ok, and should not be closed. They happen a lot, like in Telnet when a user is thinking for a long time after a message from the server computer before their next input. There is no TCP "probe" mechanism, and none is needed. 😌☕
  • Queued Receive Data on Closing: It's not always clear what to do with data the TCP has received but not yet passed to the user, especially when the connection is closing. In general, the data is to be kept so it can be given to the user if they make a RECV call. 📦
  • Out of Order Segments: The description says that segments arriving out of order (meaning they aren't 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 it occurs, the user should be notified, but the connection should not be closed or the TCB deleted. If the user wants to give up, they should explicitly ABORT the connection. Main character energy means choosing when to leave 👑

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
  • 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:

HMP is a great tool for debugging protocol implementations on computers that are far away, which is seriously iconic 🔧

It's also used to monitor Internet gateways and the TACs. 🖥️

OTHER REFERENCES: None listed.

DEPENDENCIES: Internet Protocol

CONTACT: Hinden@BBN-UNIX.ARPA

Cross Net Debugger (XNET) 🕵️‍♀️

STATUS: Elective

SPECIFICATION: IEN 158

COMMENTS:

XNET is a debugging protocol that gives debugger-like access to remote systems. Very spy coded 🫣

This specification should be updated and reissued as an RFC. Someone please do it 🙏

OTHER REFERENCES: RFC 643

DEPENDENCIES: Internet Protocol

CONTACT: Postel@USC-ISIF.ARPA

"Stub" Exterior Gateway Protocol (EGP) 🌉

STATUS: Recommended for Gateways

SPECIFICATION: RFC 888, RFC 904

COMMENTS:

EGP is the protocol gateways from different administrations use to swap routing information. It's the diplomacy of the internet 🤝

Please discuss any plans for implementing or using 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:

GGP is the gateway protocol currently used in the core gateways. It's the backbone of the backbone, honestly so iconic 🦴✨

Please discuss any plans for implementing or using this protocol with the contact. 💌

OTHER REFERENCES: None listed.

DEPENDENCIES: Internet Protocol

CONTACT: Brescia@BBN-UNIX.ARPA

Multiplexing Protocol (MUX) 🍱

STATUS: Experimental

SPECIFICATION: IEN 90

COMMENTS:

MUX lets you pack several segments from different higher level protocols into one IP datagram. Efficient, but kind of a lot to manage 🧳

There's no current experiment in progress. It's unclear how much of the sharing this protocol envisions can actually happen. There are also questions about whether the information in the multiplexing header is (a) insufficient, or (b) over specific. Big "it depends" energy 🤔

Please discuss any plans for implementing or using this protocol with the contact. 💌

OTHER REFERENCES: None listed.

DEPENDENCIES: Internet Protocol

CONTACT: Postel@USC-ISIF.ARPA

Stream Protocol (ST) 🌊

STATUS: Experimental

SPECIFICATION: IEN 119

COMMENTS:

ST is a gateway resource allocation protocol built for multihost real time applications. It's giving reservation vibes 🎟️

The implementation has evolved and may no longer be consistent with this specification. The document should be updated and issued as an RFC. Plz and thank you 🫶

Please discuss any plans for implementing or using this protocol with the contact. 💌

OTHER REFERENCES: None listed.

DEPENDENCIES: Internet Protocol

CONTACT: jwf@LL-EN.ARPA

Network Voice Protocol (NVP-II) 🎙️

STATUS: Experimental

SPECIFICATION: ISI Internal Memo

COMMENTS:

NVP-II defines the procedures for real time voice conferencing. Group call energy, literally 📞

The specification is an ISI Internal Memo, which should be updated and issued as an RFC. 📝

Please discuss any plans for implementing or using 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:

RDP is built to efficiently support bulk transfer of data for host monitoring and control applications, like loading and dumping and remote debugging. It's meant to be simple to implement but still efficient where transmission delays are long and where segments may be lost or delivered out of sequence. Reliable in the most dependable way 💪

OTHER REFERENCES: None listed.

DEPENDENCIES: Internet Protocol

CONTACT: CWelles@BBN-UNIX.ARPA

APPLICATION LEVEL 🎀

Telnet Protocol (TELNET) 💻

STATUS: Recommended

SPECIFICATION: RFC 854 (in "Internet Telnet Protocol and Options")

COMMENTS:

Telnet is the protocol for remote terminal access. Your terminal, but make it long distance 🌍

It has been revised since the IPTW. RFC 764 in IPTW is now obsolete, so don't go looking for it 🙅‍♀️

OTHER REFERENCES:

  • MIL-STD-1782 - Telnet Protocol and Options (TELNET)

DEPENDENCIES: Transmission Control Protocol

CONTACT: Postel@USC-ISIF.ARPA

Telnet Options (TELNET-OPTIONS) ⚙️

STATUS: Elective

SPECIFICATION: General description of options: RFC 855 (in "Internet Telnet Protocol and Options")

Here's the full options list, with the number, name, and where each option shows up. The table is the star of the show ⭐

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 tells you if the specification is included in the Internet Telnet Protocol and Options. 📘

The APH column tells you if the specification is included in the ARPANET Protocol Handbook. 📗

The USE column shows which options are in general use. The ones with yes there are the popular picks 💖

Okay bestie, the Telnet options are next 💖

Comments: The Binary Transmission, Echo, Suppress Go Ahead, Status, Timing Mark, and Extended Options List options just got a glow-up. They were recently updated and reissued ✨, and they're the most frequently implemented ones, so they're the main characters 👑.

The rest need a review. The useful ones should get revised and reissued, and the others should be eliminated 🥀.

The following are recommended: Binary Transmission, Echo, Suppress Go Ahead, Status, Timing Mark, and Extended Options List 💜.

Other references: none listed

Dependencies: Telnet

Contact: Postel@USC-ISIF.ARPA

File Transfer Protocol (FTP) 📂

  • Status: Recommended
  • Specification: RFC 765 (in IPTW)

Comments: FTP is the protocol for moving files between Internet hosts, and it's giving access control plus negotiation of file parameters 🎀.

There are a bunch of minor corrections to make. The big changes are deleting the mail commands and clarifying how the data connection is managed. Someone also suggested adding some directory manipulation commands (RFC 775) 🗂️.

Even though the MAIL features are defined in this document, they are not to be used. SMTP is the protocol for all mail service in the Internet, so don't go down that road 🙅‍♀️.

Data Connection Management 🔌

  • a. Default Data Connection Ports: All FTP implementations must support the default data connection ports. Only the User-PI may start using non-default ports.
  • b. Negotiating Non-Default Data Ports: The User-PI may pick a non-default user side data port with the PORT command. It may also ask the server side to pick a non-default server side data port with the PASV command. A connection is defined by its pair of addresses, so either action is enough to get a different data connection. It's still allowed to do both commands to use new ports on both ends 🦋.
  • c. Reuse of the Data Connection: In stream mode, the end of a file has to be marked by closing the connection. That's a problem if you want to transfer several files in one session, because TCP has to hold the connection record for a timeout period to keep communication reliable. So the connection can't be reopened right away 😩.

There are two ways around this. The first is to negotiate a non-default port, like in (b) above. The second is to use another transfer mode 🌈.

Quick note on transfer modes: stream mode is inherently unreliable, because you can't tell whether the connection closed early or not 🙈. The other modes (Block and Compressed) don't close the connection to mark end of file. They have enough FTP encoding that the data connection can be parsed to find the end of the file. So with those modes you 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 was very reliable, and the NCP counted on that. If any packet of data from an NCP connection was lost or damaged by the network, the NCP couldn't recover. It's a tribute to the ARPANET designers that the NCP FTP worked so well 👑.

TCP is built to give reliable connections across many different kinds of networks and interconnections of networks. TCP has to cope with networks that can't promise to work as well as the ARPANET. So TCP has to handle end-to-end recovery from lost or damaged packets on its own 🫶. That's why it needs the connection phase-down time-out. The NCP never had to deal with acknowledgements, retransmissions, or many other things TCP has to do to keep connections reliable in a more complex world 😭.

LIST and NLST: There's some confusion about the LIST and NLST commands and what they should return. The specification needs some clarification and motivation for these commands 🤔.

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: TFTP is a very simple file moving protocol, and it has no access control at all 🫣.

It's in use in several local networks 🏠.

Some ambiguities in how several of the transfer modes are interpreted should be clarified. Additional transfer modes could be defined, and additional error codes could be defined to more clearly identify problems 🔍.

Other references: none listed

Dependencies: User Datagram Protocol

Contact: Postel@USC-ISIF.ARPA

Simple File Transfer Protocol (SFTP) 🧸

  • Status: Experimental
  • Specification: RFC 913

Comments: SFTP is a simple file transfer protocol for people who want something more useful than TFTP but easier to implement (and less powerful) than FTP. It 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. TFTP implements a connection over UDP, and FTP uses two TCP connections (one of them using the TELNET protocol) 🧩.

Please discuss any plans for implementing or using this protocol with the contact 💌.

Other references: none listed

Dependencies: Transmission Control Protocol

Contact: MKL@MIT-XX.ARPA

Simple Mail Transfer Protocol (SMTP) 📮

  • Status: Recommended
  • Specification: RFC 821 (in "Internet Mail Protocols")

Comments: SMTP is the procedure for transmitting computer mail between hosts 💌.

It was revised after the IPTW and is in the "Internet Mail Protocols" volume of November 1982. RFC 788 (in IPTW) is obsolete 🗑️.

There were lots of misunderstandings and errors in the early implementations. Some documentation of these problems can be found in the file [ISIF]<SMTP>MAIL.ERRORS 📝.

Some minor differences between RFC 821 and RFC 822 should be resolved 🤓.

Other references:

  • RFC 822 - Mail Header Format Standards
    • It was revised after the IPTW and is in the "Internet Mail Protocols" volume of November 1982. RFC 733 (in IPTW) is obsolete. Further revision of RFC 822 is needed to fix 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: RLP is a resource location protocol for use in the ARPA-Internet. It uses the User Datagram Protocol (UDP), which in turn calls on the Internet Protocol to deliver its datagrams 🛰️.

Other references: none listed

Dependencies: User Datagram Protocol

Contact: Accetta@CMU-CS-A.ARPA

Loader Debugger Protocol (LDP) 🐛

  • Status: Experimental
  • Specification: RFC 909

Comments: LDP is the protocol for loading, dumping, and debugging target machines from hosts on a network 🔧. It's also designed to work with a variety of target CPU types 🧠.

It has a powerful set of debugging services. It's also structured so that a simple subset can be implemented in things like boot loading, where efficiency and space are at a premium 🚀.

Other references: none listed

Dependencies: Reliable Data Protocol

Contact: Hinden@BBN-UNIX.ARPA

Remote Job Entry (RJE) 🖨️

  • Status: Elective
  • Specification: RFC 407 (in APH)

Comments: RJE is the general protocol for submitting batch jobs and retrieving the results 📦.

Some changes are needed for use with TCP. There are no known active implementations 😬.

Other references: none listed

Dependencies: File Transfer Protocol, Transmission Control Protocol

Contact: Postel@USC-ISIF.ARPA

Remote Job Service (NETRJS) 🏭

  • Status: Elective
  • Specification: RFC 740 (in APH)

Comments: NETRJS is a special protocol for submitting batch jobs and retrieving the results. It's used with the UCLA IBM OS system 💻.

Please discuss any plans for implementing or using this protocol with the contact 💌. Revision is in progress 🔄.

Other references: none listed

Dependencies: Transmission Control Protocol

Contact: Braden@USC-ISIA.ARPA

Remote Telnet Service (RTELNET) 🌐

  • Status: Elective
  • Specification: RFC 818

Comments: RTELNET provides special access to user Telnet on a remote system 🛸.

Other references: none listed

Dependencies: Telnet, Transmission Control Protocol

Contact: Postel@USC-ISIF.ARPA

Graphics Protocol (GRAPHICS) 🎨

  • Status: Elective
  • Specification: NIC 24308 (in APH)

Comments: GRAPHICS is the protocol for vector graphics 📐. Very minor changes are needed for use with TCP. There are no known active implementations 🥲.

Other references: none listed

Dependencies: Telnet, Transmission Control Protocol

Contact: Postel@USC-ISIF.ARPA

Echo Protocol (ECHO) 🪞

  • Status: Recommended
  • Specification: RFC 862

Comments: ECHO is a debugging protocol. It sends back whatever you send it 🔁.

Other references: none listed

Dependencies: Transmission Control Protocol or User Datagram Protocol

Contact: Postel@USC-ISIF.ARPA

Discard Protocol (DISCARD) 🗑️

  • Status: Elective
  • Specification: RFC 863

Comments: DISCARD is a debugging protocol. It throws away whatever you send it 🫠.

Other references: none listed

Dependencies: Transmission Control Protocol or User Datagram Protocol

Contact: Postel@USC-ISIF.ARPA

Character Generator Protocol (CHARGEN) 🔤

  • Status: Elective
  • Specification: RFC 864

Comments:

Okay so we're mid-entry here, and this one is a debugging protocol that sends you ASCII data 💻🎀

OTHER REFERENCES:

DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol 🦋

CONTACT: Postel@USC-ISIF.ARPA

Quote of the Day Protocol (QUOTE) 💬

  • STATUS: Elective
  • SPECIFICATION: RFC 865
  • COMMENTS: It's a debugging protocol that sends you one short ASCII message. Tiny but iconic ✨
  • 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: It lists who's currently active. Main character energy, literally 💅
  • OTHER REFERENCES:
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Authentication Service (AUTH) 🔐

  • STATUS: Experimental
  • SPECIFICATION: RFC 912
  • COMMENTS:

Okay this one is so useful 🥹 The Authentication Server gives you a way to figure out who a user is on a particular TCP connection. You give it a TCP port number pair, and it sends back a character string that identifies the owner of that connection on the server's system.

Suggested uses include automatic identification and 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. The vibes are very secure 🔒

Please discuss any plans for implementation or use of this protocol with the contact. Bestie, ask before you build anything 🫶

  • OTHER REFERENCES:
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: StJohns@MIT-MULTICS.ARPA

Finger Protocol (FINGER) 👀

  • STATUS: Elective
  • SPECIFICATION: RFC 742 (in APH)
  • COMMENTS:

It gives you info on what a user is doing right now, or what they were doing most recently. Lowkey nosy but make it a feature 🙈

Some extensions have been suggested.

Some changes 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: It accesses the ARPANET Directory database, so you can find out about people, their addresses, phone numbers, organizations, and mailboxes. Digital stalking but make it networking 💖
  • OTHER REFERENCES:
  • DEPENDENCIES: Transmission Control Protocol
  • 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: It accesses the Registered Internet Hosts database (HOSTS.TXT). You can find out about a host on the Internet, its Internet Address, and which protocols it implements. Address book energy 📒
  • OTHER REFERENCES:
    • RFC 810 - Host Table Specification
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Feinler@SRI-NIC.ARPA

Host Name Server Protocol (NAMESERVER) 🙃

  • STATUS: Experimental
  • SPECIFICATION: IEN 116 (in IPTW)
  • COMMENTS:

It gives you a machine-oriented procedure for translating a host name to an Internet Address.

Okay, real talk, this spec has some 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 has now been abandoned in favor of the DOMAIN protocol. Further implementations of this protocol are not advised. Respectfully, let it rest 🪦

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:

It gives you access to the CSNET database of users, so you can look up 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

Daytime Protocol (DAYTIME) ☀️

  • STATUS: Elective
  • SPECIFICATION: RFC 867
  • COMMENTS: It gives you the day and time as an ASCII character string. Simple, sweet, and always on time 🕰️
  • 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: It gives you the time as the number of seconds from a specified reference time. Math-brained and proud 🧮
  • OTHER REFERENCES:
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

DCNET Time Server Protocol (CLOCK) 🕐

  • STATUS: Elective
  • SPECIFICATION: RFC 778
  • COMMENTS: It provides a mechanism for keeping clocks synchronized. Everyone's on the same page, no drama 🤝
  • OTHER REFERENCES:
  • DEPENDENCIES: Internet Control Message Protocol
  • CONTACT: Mills@USC-ISID.ARPA

SUPDUP Protocol (SUPDUP) 🖥️

  • STATUS: Elective
  • SPECIFICATION: RFC 734 (in APH)
  • COMMENTS: It's a special Telnet-like protocol for display terminals. Telnet's cooler cousin 😎
  • OTHER REFERENCES:
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Crispin@SU-SCORE.ARPA

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. Multimedia mail, we're so ahead 🌈

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 whole point of the Post Office Protocol (POP) is to let a user's workstation access mail from a mailbox server. Mail is expected to be posted from the workstation to the mailbox server via the Simple Mail Transfer Protocol (SMTP). For more info see RFC-821 and RFC-822. Mail with a plan 📬

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

Network Standard Text Editor (NETED) ✏️

  • STATUS: Elective
  • SPECIFICATION: RFC 569
  • COMMENTS: It describes a simple line editor that could be provided by every Internet host. Minimalist and sweet 🍓
  • OTHER REFERENCES:
  • DEPENDENCIES:
  • CONTACT: Postel@USC-ISIF.ARPA

APPENDICES 🎀

okay bestie, the appendices are basically the registry of assigned numbers and the protocol pages that go with them 📋✨ it's the big cheat sheet that says which protocol got which value, and who to contact if something's off 💅 each entry below has its status, its spec, some comments, other references, and a contact. iykyk 🫶

Assigned Numbers 📖

  • STATUS: None
  • SPECIFICATION: RFC 923

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: (empty)
  • CONTACT: JKReynolds@USC-ISIF.ARPA 💌

Pre-emption 🦋

  • STATUS: Elective
  • SPECIFICATION: RFC 794 (in IPTW)

Describes how to do pre-emption of TCP connections ⭐

  • OTHER REFERENCES: (empty)
  • CONTACT: Postel@USC-ISIF.ARPA 🧚

Service Mappings 🌈

  • STATUS: None
  • SPECIFICATION: RFC 795 (in IPTW)

Describes the mapping of the IP type of service field onto the parameters of some specific networks 🍓

Out of date, needs revision. 😭

  • OTHER REFERENCES: (empty)
  • CONTACT: Postel@USC-ISIF.ARPA 🫶

Address Mappings 🗺️

  • STATUS: None
  • SPECIFICATION: RFC 796 (in IPTW)

Describes the mapping between Internet Addresses and the addresses of some specific networks 💖

Out of date, needs revision. 💀

  • OTHER REFERENCES: (empty)
  • CONTACT: Postel@USC-ISIF.ARPA ✨

Document Formats 📄

  • STATUS: None
  • SPECIFICATION: RFC 678

Describes standard format rules for several types of documents 🎀

  • OTHER REFERENCES: (empty)
  • CONTACT: Postel@USC-ISIF.ARPA 💅

Bitmap Formats 🖼️

  • STATUS: None
  • SPECIFICATION: RFC 797

Describes a standard format for bitmap data 🌸

  • OTHER REFERENCES: (empty)
  • CONTACT: Postel@USC-ISIF.ARPA 🦋

Facsimile Formats 📠

  • STATUS: None
  • SPECIFICATION: RFC 804

Describes a standard format for facsimile data 🍓

  • OTHER REFERENCES: (empty)
  • CONTACT: Postel@USC-ISIF.ARPA 🧚

Internet Protocol on X.25 Networks 🔌

  • STATUS: Recommended 👑
  • SPECIFICATION: RFC 877

Describes a standard for the transmission of IP Datagrams over Public Data Networks 💜

  • OTHER REFERENCES: (empty)
  • CONTACT: jtk@PURDUE.ARPA 💌

Internet Protocol on DC Networks ⏰

  • STATUS: Elective
  • SPECIFICATION: RFC 891
  • COMMENTS: (empty)
  • OTHER REFERENCES:
    • RFC 778 - DCNET Internet Clock Service
  • CONTACT: Mills@USC-ISID.ARPA ✨

Internet Protocol on Ethernet Networks 🌐

  • STATUS: Recommended 👑
  • SPECIFICATION: RFC 894
  • COMMENTS: (empty)
  • OTHER REFERENCES: RFC 893
  • CONTACT: Postel@USC-ISIF.ARPA 🫶

Internet Protocol on Experimental Ethernet Networks 🧪

  • STATUS: Recommended 👑
  • SPECIFICATION: RFC 895
  • COMMENTS: (empty)
  • OTHER REFERENCES: (empty)
  • CONTACT: Postel@USC-ISIF.ARPA 💖

Address Resolution Protocol (ARP) 🔍

  • STATUS: Recommended 👑
  • SPECIFICATION: RFC 826

Okay so ARP is the procedure for finding the network hardware address that goes with an Internet Address 🪄 it's literally how you go from "who is this IP" to "what's the physical address" 🙈

  • OTHER REFERENCES: (empty)
  • CONTACT: Postel@USC-ISIF.ARPA ✨

A Reverse Address Resolution Protocol (RARP) 🔁

  • STATUS: Elective
  • SPECIFICATION: RFC 903

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) 💜 the reverse glow-up, basically 🌈

  • OTHER REFERENCES: (empty)
  • CONTACT: Mogul@SU-SCORE.ARPA 🦋

Host Access Protocol (HAP) 🛰️

  • STATUS: Recommended 👑
  • SPECIFICATION: RFC 907

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. 🚀 translation: talk to the satellite people before you build, bestie 🫶
  • OTHER REFERENCES: (empty)
  • DEPENDENCIES: (empty)
  • CONTACT: Schoen@BBN-UNIX.ARPA 💅
📦 where this page comes from