RFC 961

Official ARPA-Internet protocols

📅 published December 1985, from ietf

Hey bestie, this is RFC 961 🎀

This one is titled OFFICIAL ARPA-INTERNET PROTOCOLS 📜 It's from the Network Working Group, written by J. Reynolds and J. Postel at ISI, and it's dated December 1985. It obsoletes RFCs 944, 924, 901, 880, and 840 💅 It's an official status report on the protocols used in the ARPA-Internet community, so it's basically the official "here's what's real" list 🫶

STATUS OF THIS MEMO ✨

okay so this memo is an official status report on the protocols used in the ARPA-Internet community 💖 distribution of this memo is unlimited, so share it with everyone 🌈

INTRODUCTION 🦋

this RFC is the list of documents that specify the official protocols used on the Internet 📚 comments show any revisions or changes that are planned, so keep an eye on those 👀

to first order, the official protocols are the ones in the "Internet Protocol Transition Workbook" (IPTW) dated March 1982 🍓 there are a few protocols in use that aren't in the IPTW, and a few IPTW protocols have been revised 🔄 the big one is mail, which got revised and issued as a volume called "Internet Mail Protocols" dated November 1982 📬

Telnet and the most useful Telnet options got revised too, and they're in a volume called "Internet Telnet Protocol and Options" (ITP) dated June 1983 🖥️ the File Transfer Protocol was revised most recently as RFC 959, which isn't in any collection yet 🫣 some protocols haven't been touched in years, and those live in the old "ARPANET Protocol Handbook" (APH) dated January 1978 🕰️ there's also a protocol info volume called the "Internet Protocol Implementers Guide" (IPIG) dated August 1982 🧚

this document is a sketchy outline, and the entries are protocols (like Transmission Control Protocol) ✨ every entry has notes on status, specification, comments, other references, dependencies, and contact, so here's what each one means:

  • STATUS is one of: required, recommended, elective, or experimental 🔥
  • SPECIFICATION names the protocol defining documents 📖
  • COMMENTS describe any differences from the specification or problems with the protocol 🙈
  • OTHER REFERENCES list documents that comment on or expand on the protocol 💜
  • DEPENDENCIES show what other protocols this one calls on 🔗
  • CONTACT is a person who can answer questions about the protocol 💌

so the STATUS values are literally the vibe check 💅

  • required: all hosts MUST implement the required protocol, no exceptions 👑
  • recommended: all hosts are encouraged to implement the recommended protocol 🌸
  • elective: hosts MAY implement or not implement the elective protocol, your call 🦋
  • 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 🧪 bestie, don't just vibe-code this one 💀
  • none: this is not a protocol 🙃

for more info 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-ISIB.ARPA

OVERVIEW 🌈

Catenet Model 🍓

  • STATUS: None
  • SPECIFICATION: IEN 48 (in IPTW)
  • COMMENTS: this one gives an overview of how the Internet is organized and the principles behind it 🧠 it could be revised and expanded, so it's giving work in progress ✨
  • OTHER REFERENCES:
    • Leiner, B., Cole R., Postel, J., and D. Mills, "The DARPA Protocol Suite", IEEE INFOCOM 85, Washington, D.C., March 1985. Also in IEEE Communications Magazine, and as ISI/RS-85-153, March 1985. 📄
    • Postel, J., "Internetwork Applications Using the DARPA Protocol Suite", IEEE INFOCOM 85, Washington, D.C., March 1985. Also in IEEE Communications Magazine, and as ISI/RS-85-151, April 1985. 📄
    • Padlipsky, M.A., "The Elements of Networking Style and other Essays and Animadversions on the Art of Intercomputer Networking", Prentice-Hall, New Jersey, 1985. 📚
    • RFC 871 - A Perspective on the ARPANET Reference Model 🔖
  • DEPENDENCIES: none listed
  • CONTACT: Postel@USC-ISIB.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 gives universal addressing of hosts across the Internet, so it's literally the main character 💖
    • 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 says which octet of the route is 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, because the pointer begins at 4 ✨
    • another important point is the alternate reassembly procedure suggested in RFC 815 🧩
    • some changes are in the works for the security option 🔐
    • 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, so don't skip it bestie 🙅‍♀️
  • 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 🎖️
    • RFC 963 - Some Problems with the Specification of the Military Standard Internet Protocol 🔍
  • DEPENDENCIES: none listed
  • CONTACT: Postel@USC-ISIB.ARPA 💌

Internet Control Message Protocol (ICMP) 💜

  • STATUS: Required
  • SPECIFICATION: RFC 792 (in IPTW)
  • COMMENTS:
    • these are the control messages and error reports that go along with the Internet Protocol 🚨
    • a few minor errors in the document have been noted 🙈 suggestions have been made for extra types of redirect message and extra destination unreachable messages 🛤️
    • a proposal for two additional ICMP message types is made in RFC 950 "Internet Subnets": Address Mask Request (A1=17), and Address Mask Reply (A2=18) 🎀 the details of these ICMP types are subject to change, and 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, so yes, I'm repeating it because it matters 😤
  • OTHER REFERENCES: RFC 950 🔖
  • DEPENDENCIES: Internet Protocol 🔗
  • CONTACT: Postel@USC-ISIB.ARPA 💌

HOST LEVEL ✨

okay bestie, we're now at the host level 🧚 this is where the actual protocols that live on your machines get their moment. UDP, TCP, and a whole crew of others, each with their own little status and vibe. let's go 💖

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 the IP services. iconic. 🦋
    • The only change noted for the UDP spec is a minor clarification: if a padding octet gets used when computing the checksum, it is not transmitted and it is not counted in the length. no cap, very specific, very important 🤓
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Postel@USC-ISIB.ARPA

Transmission Control Protocol (TCP) 🌸

  • STATUS: Recommended
  • SPECIFICATION: RFC 793 (in IPTW)
  • COMMENTS:
    • TCP is the one that gives you reliable, end-to-end data stream service. literally the MVP 👑
    • okay so, a bunch of comments and corrections have come in for the TCP spec, and they're mostly document bugs, not protocol bugs. the protocol is fine, the writing needed some love 💅
    • Event Processing Section: there are a bunch of minor corrections and clarifications needed in this section 📝
    • Push: some phrases still give off a "record mark" vibe, and they need clearer wording. 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 the first octet of non-urgent data ⚠️
    • Listening Servers: people have had trouble contacting listening servers. the spec should talk about implementation issues for servers, and include some notes on alternative models for how systems and processes can be organized for servers 🧠
    • Maximum Segment Size: the MSS option should be generalized and clarified. it can be used to increase or decrease the maximum segment size from the default. the TCP MSS is the IP Maximum Datagram Size minus forty. the default IP Maximum Datagram Size is 576, and the default TCP MSS is 536. for more, see RFC 879 📏
    • Idle Connections: there have been questions about automatically closing idle connections. idle connections are ok and should not be closed. they show up in lots of cases, like 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 isn't clear from the description what to do with data the TCP has received but not yet passed to the user, especially when the connection is closing. generally, the data is to be kept so it can be handed to the user if they make a RECV call 📦
    • Out of Order Segments: the description says that segments arriving out of order (meaning, 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 it happens, the user should be notified, but the connection should not be closed and the TCB should not be deleted. if they want to give up, the user should explicitly ABORT the connection 🙅‍♀️
  • 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
    • RFC 964 - Some Problems with the Specification of the Military Standard Transmission Control Protocol
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Postel@USC-ISIB.ARPA

Host Monitoring Protocol (HMP) 🔍

  • STATUS: Elective
  • SPECIFICATION: RFC 869
  • COMMENTS:
    • this is a great tool for debugging protocol implementations on computers that are located remotely 🛠️
    • it's also the protocol 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:
    • a debugging protocol that gives you debugger-like access to remote systems. so much access, it's giving detective 🕵️‍♀️
    • this spec should be updated and reissued as an RFC, periodt 📜
  • OTHER REFERENCES: RFC 643
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Postel@USC-ISIB.ARPA

"Stub" Exterior Gateway Protocol (EGP) 🌐

  • STATUS: Recommended for Gateways
  • SPECIFICATION: RFC 888, RFC 904
  • COMMENTS:
    • this is the protocol gateways of different administrations use to swap routing information. it's basically the group chat between networks 💬
    • if you have plans to implement or use this protocol, please discuss them 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:
    • this is the gateway protocol now used in the core gateways. the backbone energy is real ⭐
    • if you have plans to implement or use this protocol, please discuss them with the contact 💌
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Brescia@BBN-UNIX.ARPA

Multiplexing Protocol (MUX) 🧃

  • STATUS: Experimental
  • SPECIFICATION: IEN 90
  • COMMENTS:
    • it defines a way to combine several segments from different higher-level protocols into one IP datagram. packing efficiency with main character energy 🎒
    • there's no current experiment in progress. there's some question about how much of the sharing this protocol envisions can actually happen. also, the information in the multiplexing header might be (a) insufficient, or (b) over-specific 🤔
    • if you have plans to implement or use this protocol, please discuss them with the contact 💌
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Postel@USC-ISIB.ARPA

Stream Protocol (ST) 🌊

  • STATUS: Experimental
  • SPECIFICATION: IEN 119
  • COMMENTS:
    • a gateway resource allocation protocol designed for multihost real-time applications. it's giving real-time reservations 🎟️
    • the implementation has evolved and may no longer match this specification. the document should be updated and issued as an RFC 🔄
    • if you have plans to implement or use this protocol, please discuss them 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:
    • this one defines the procedures for real-time voice conferencing. the group call era, bestie 📞
    • the specification is an ISI Internal Memo, which should be updated and issued as an RFC 📝
    • if you have plans to implement or use this protocol, please discuss them 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 built to efficiently support bulk data transfer for host monitoring and control applications like loading/dumping and remote debugging. it's meant to be simple to implement while still being efficient where there are long transmission delays and where segments may be lost or delivered out of sequence 🫡
    • if you have plans to implement or use this protocol, please discuss them with the contact 💌
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Internet Protocol
  • CONTACT: CWelles@BBN-UNIX.ARPA

Internet Reliable Transaction Protocol (IRTP) 🤝

  • STATUS: Experimental
  • SPECIFICATION: RFC 938
  • COMMENTS:
    • this is a transport-level, host-to-host protocol designed for an internet environment. the issues it discusses may not be directly relevant to DARPA community research problems, but a number of researchers and implementors might find them interesting 🧐
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Trudy@ACC.ARPA

APPLICATION LEVEL 💅

Telnet Protocol (TELNET) 🖥️

  • STATUS: Recommended
  • SPECIFICATION: RFC 854 (in "Internet Telnet Protocol and Options")
  • COMMENTS:
    • the protocol for remote terminal access. remote control, but make it cute 🎀
    • this has been revised since the IPTW. RFC 764 in IPTW is now obsolete, so no more old version drama 🙅‍♀️
  • OTHER REFERENCES:
    • MIL-STD-1782 - Telnet Protocol
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Postel@USC-ISIB.ARPA

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                       930 -----  no  no  no
        25     End of Record                       885 -----  no  no  no
        26     TACACS User Identification          927 -----  no  no  no
        27     Output Marking                      933 -----  no  no  no
        28     Terminal Location Number            946 -----  no  no  no
       255     Extended-Options-List               861 ----- yes obs yes

                                                        (obs = obsolete)

The ITP column tells you if the spec is included in the Internet Telnet Protocol and Options 🎀. The APH column tells you if it's in the ARPANET Protocol Handbook 📖. And the USE column in the table above shows which options are in general use 💖.

COMMENTS: 🌸

Okay so the Binary Transmission, Echo, Suppress Go Ahead, Status, Timing Mark, and Extended Options List options were recently updated and reissued ✨. They're the most frequently implemented options, so they're the main characters 👑.

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: (nothing listed 🙈)

DEPENDENCIES: Telnet

CONTACT: Postel@USC-ISIB.ARPA

File Transfer Protocol (FTP) 📁

STATUS: Recommended

SPECIFICATION: RFC 959

COMMENTS:

This is the protocol for moving files between Internet hosts 🚀. It gives you access control and lets you negotiate file parameters, which is so organized of it 💅.

The following new optional commands are included in this edition of the specification: Change to Parent Directory (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove Directory (RMD), Make Directory (MKD), Print Directory (PWD), and System (SYST) 🧚. And this spec is compatible with the previous edition (RFC 765), so no drama there 🥰.

OTHER REFERENCES:

  • RFC 678 - Document File Format Standards
  • MIL-STD-1780 - File Transfer Protocol

DEPENDENCIES: Transmission Control Protocol

CONTACT: Postel@USC-ISIB.ARPA

Trivial File Transfer Protocol (TFTP) 🦋

STATUS: Elective

SPECIFICATION: RFC 783 (in IPTW)

COMMENTS:

It's a very simple file moving protocol, and no access control is provided 🙈. Honestly it's giving minimalism 🍓.

It's in use in several local networks, so it's not just a vibe, it's real 🌈.

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: (nothing listed 🙈)

DEPENDENCIES: User Datagram Protocol

CONTACT: Postel@USC-ISIB.ARPA

Simple File Transfer Protocol (SFTP) 🧪

STATUS: Experimental

SPECIFICATION: RFC 913

COMMENTS:

SFTP is a simple file transfer protocol, and it fills the need 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. Iconic range 👑.

SFTP can be implemented with any reliable 8-bit byte stream oriented protocol, and 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 using the TELNET protocol). So SFTP is the efficient one, no cap ✨.

Please discuss any plans for implementation or use of this protocol with the contact 🫶.

OTHER REFERENCES: (nothing listed 🙈)

DEPENDENCIES: Transmission Control Protocol

CONTACT: MKL@SRI-NIC.ARPA

Simple Mail Transfer Protocol (SMTP) 💌

STATUS: Recommended

SPECIFICATION: RFC 821 (in "Internet Mail Protocols")

COMMENTS:

This is the procedure for transmitting computer mail between hosts 📬. Main character of email energy 💅.

It was revised since the IPTW, and the revised version is in the "Internet Mail Protocols" volume of November 1982. RFC 788 (in IPTW) is obsolete, so bye 👋.

There were many misunderstandings and errors in the early implementations 😭. Some documentation of these problems can be found in the file [ISIB]<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 since the IPTW, and the revised version 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-ISIB.ARPA

Resource Location Protocol (RLP) 🔍

STATUS: Elective

SPECIFICATION: RFC 887

COMMENTS:

This 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. A whole chain of besties 🧚.

OTHER REFERENCES: (nothing listed 🙈)

DEPENDENCIES: User Datagram Protocol

CONTACT: Accetta@CMU-CS-A.ARPA

Loader Debugger Protocol (LDP) 🛠️

STATUS: Experimental

SPECIFICATION: RFC 909

COMMENTS:

This one specifies a protocol for loading, dumping and debugging target machines from hosts in a network environment 💻. It's also designed to accommodate a variety of target CPU types, which is so inclusive 🌈.

It provides a powerful set of debugging services, but it's structured so that a simple subset can be implemented in applications like boot loading, where efficiency and space are at a premium 🥹. Lowkey genius.

Please discuss any plans for implementation or use of this protocol with the contact 🫶.

OTHER REFERENCES: (nothing listed 🙈)

DEPENDENCIES: Reliable Data Protocol

CONTACT: Hinden@BBN-UNIX.ARPA

Remote Job Entry (RJE) 🎞️

STATUS: Elective

SPECIFICATION: RFC 407 (in APH)

COMMENTS:

This is the general protocol for submitting batch jobs and retrieving the results 📤.

Some changes are needed for use with TCP 🔧.

No known active implementations, sadly 😔.

OTHER REFERENCES: (nothing listed 🙈)

DEPENDENCIES:

  • File Transfer Protocol
  • Transmission Control Protocol

CONTACT: Postel@USC-ISIB.ARPA

Remote Job Service (NETRJS) 🖨️

STATUS: Elective

SPECIFICATION: RFC 740 (in APH)

COMMENTS:

This is 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: (nothing listed 🙈)

DEPENDENCIES: Transmission Control Protocol

CONTACT: Braden@UCLA-CCN.ARPA

Remote Telnet Service (RTELNET) 📡

STATUS: Elective

SPECIFICATION: RFC 818

COMMENTS:

It provides special access to user Telnet on a remote system 🗝️.

OTHER REFERENCES: (nothing listed 🙈)

DEPENDENCIES:

  • Telnet
  • Transmission Control Protocol

CONTACT: Postel@USC-ISIB.ARPA

Graphics Protocol (GRAPHICS) 🎨

STATUS: Elective

SPECIFICATION: NIC 24308 (in APH)

COMMENTS:

This is the protocol for vector graphics 📐.

Very minor changes are needed for use with TCP ✨.

No known active implementations, unfortunately 🥲.

OTHER REFERENCES: (nothing listed 🙈)

DEPENDENCIES:

  • Telnet
  • Transmission Control Protocol

CONTACT: Postel@USC-ISIB.ARPA

Echo Protocol (ECHO) 🔁

STATUS: Recommended

SPECIFICATION: RFC 862

COMMENTS:

This is a debugging protocol that sends back whatever you send it 🪞. Literally the most relatable protocol ever 🥹.

OTHER REFERENCES: (nothing listed 🙈)

DEPENDENCIES:

  • Transmission Control Protocol
  • or User Datagram Protocol

CONTACT: Postel@USC-ISIB.ARPA

Discard Protocol (DISCARD) 🗑️

STATUS: Elective

SPECIFICATION: RFC 863

COMMENTS:

This is a debugging protocol that throws away whatever you send it 💀. Ruthless, but iconic.

OTHER REFERENCES: (nothing listed 🙈)

DEPENDENCIES:

  • Transmission Control Protocol
  • or User Datagram Protocol

CONTACT: Postel@USC-ISIB.ARPA

Character Generator Protocol (CHARGEN) 🔤

STATUS: Elective

SPECIFICATION: RFC 864

COMMENTS:

This is a debugging protocol that sends you ASCII data 🧾.

OTHER REFERENCES: (nothing listed 🙈)

DEPENDENCIES:

  • Transmission Control Protocol
  • or User Datagram Protocol

CONTACT: Postel@USC-ISIB.ARPA

Quote of the Day Protocol (QUOTE) 💬

STATUS: Elective

SPECIFICATION: RFC 865

COMMENTS:

This is a debugging protocol that sends you a short ASCII message 💌. A little daily dose of motivation, bestie 🌸.

OTHER REFERENCES: (nothing listed 🙈)

DEPENDENCIES:

  • Transmission Control Protocol
  • or User Datagram Protocol

CONTACT: Postel@USC-ISIB.ARPA

Active Users Protocol (USERS) 👯

STATUS: Elective

SPECIFICATION: RFC 866

COMMENTS:

This one lists the currently active users 👀. Everyone's here, it's giving party 🎉.

OTHER REFERENCES:

  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol 🔗
  • CONTACT: Postel@USC-ISIB.ARPA 💌

Finger Protocol (FINGER) 👀✨

Okay bestie, Finger is all about what a user is up to right now or was up to most recently 🕵️‍♀️💅

  • 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 needed for TCP. 🔧
  • OTHER REFERENCES: (none)
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Postel@USC-ISIB.ARPA

WhoIs Protocol (NICNAME) 🔍🎀

This one is giving directory energy 📇 It's how you look up people 🫶

  • STATUS: Elective
  • SPECIFICATION: RFC 954
  • COMMENTS:
    • Accesses the ARPANET Directory database. Provides a way to find out about people, their addresses, phone numbers, organizations, and mailboxes. 💖
  • OTHER REFERENCES: (none)
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Feinler@SRI-NIC.ARPA

Domain Name Protocol (DOMAIN) 🌐👑

Literally the one everybody recommends 😭🔥 STATUS is Recommended, no cap 💅

  • STATUS: Recommended
  • SPECIFICATION: RFC 881, 882, 883
  • COMMENTS: (none)
  • OTHER REFERENCES:
    • RFC 920 - Domain Requirements 📜
    • RFC 921 - Domain Name Implementation Schedule - Revised 🗓️
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Mockapetris@USC-ISIB.ARPA

HOSTNAME Protocol (HOSTNAME) 🖥️🧚

This one accesses the Registered Internet Hosts database, aka HOSTS.TXT 🍓 It's how you find a host, its Internet Address, and the protocols it runs 🦋

  • STATUS: Elective
  • SPECIFICATION: RFC 953
  • 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 952 - Host Table Specification 📋
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Feinler@SRI-NIC.ARPA

Host Name Server Protocol (NAMESERVER) 🙈⚠️

Okay so this one is the cautionary tale 💀 It's marked Experimental, and the original spells out some real problems, so read carefully, bestie 🫶

  • 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 abandoned 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: (none)
  • DEPENDENCIES: User Datagram Protocol
  • CONTACT: Postel@USC-ISIB.ARPA

CSNET Mailbox Name Server Protocol (CSNET-NS) 📬🌈

This one gives you access to the CSNET database of users, so you can look up names, affiliations, and mailboxes 💜

  • 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: (none)
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Solomon@UWISC.ARPA

Daytime Protocol (DAYTIME) ☀️🌤️

Simple and sweet 🍰 It just gives you the day and the time as an ASCII character string ⏰

  • STATUS: Elective
  • SPECIFICATION: RFC 867
  • COMMENTS:
    • Provides the day and time in ASCII character string. 🔤
  • OTHER REFERENCES: (none)
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@USC-ISIB.ARPA

Network Time Protocol (NTP) 🕰️⏳

Synchronizing a whole set of network clocks, using distributed clients and servers 🧠✨ It's still listed as Experimental here, so bestie, talk to the contact before you build anything 💅

  • STATUS: Experimental
  • SPECIFICATION: RFC 958
  • COMMENTS:
    • A proposed protocol for synchronizing a set of network clocks using a set of distributed clients and servers. 🔁
    • Please discuss any plans for implementation or use of this protocol with the contact. 💌
  • OTHER REFERENCES: RFC 778, RFC 891, RFC 956, and RFC 957.
  • DEPENDENCIES: User Datagram Protocol
  • CONTACT: Mills@USC-ISID.ARPA

Time Server Protocol (TIME) ⏱️🦋

The OG time service 🕛 It gives you the time as a number of seconds from a specified reference time 🧮

  • STATUS: Elective
  • SPECIFICATION: RFC 868
  • COMMENTS:
    • Provides the time as the number of seconds from a specified reference time. 🔢
  • OTHER REFERENCES: (none)
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@USC-ISIB.ARPA

DCNET Time Server Protocol (CLOCK) 🕰️💜

Keeping clocks in sync, but still Experimental 🧪 so the same advice applies: chat with the contact first 🫶

  • STATUS: Experimental
  • SPECIFICATION: RFC 778
  • COMMENTS:
    • Provides a mechanism for keeping synchronized clocks. ⏲️
    • Please discuss any plans for implementation or use of this protocol with the contact. 💬
  • OTHER REFERENCES: (none)
  • DEPENDENCIES: Internet Control Message Protocol
  • CONTACT: Mills@USC-ISID.ARPA

SUPDUP Protocol (SUPDUP) 🖥️🌸

A special Telnet-like protocol, made for display terminals 📺 It's giving retro-but-make-it-iconic 👾

  • STATUS: Elective
  • SPECIFICATION: RFC 734 (in APH)
  • COMMENTS:
    • A special Telnet like protocol for display terminals. 💻
  • OTHER REFERENCES: (none)
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Crispin@SU-SCORE.ARPA

Internet Message Protocol (MPM) 📨🎀

An experimental multimedia mail transfer protocol 🎞️ The implementation is called a Message Processing Module, or 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-ISIB.ARPA

Post Office Protocol - Version 2 (POP2) 📮💖

This one is all about getting your mail from a mailbox server onto your workstation 💌 Mail goes out the other way through SMTP, so the two work together 🫶

  • STATUS: Experimental
  • SPECIFICATION: RFC 937
  • COMMENTS:
    • The intent of the Post Office Protocol - Version 2 (POP2) 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). ✉️
    • Please discuss any plans for implementation or use of this protocol with the contact. 💬
  • OTHER REFERENCES: Obsoletes RFC 918
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: JKReynolds@USC-ISIB.ARPA

Network Standard Text Editor (NETED) ✏️🧸

A simple line editor that every Internet host could have, which is very cozy 🧸🌷

  • STATUS: Elective
  • SPECIFICATION: RFC 569
  • COMMENTS:
    • Describes a simple line editor which could be provided by every Internet host. 📝
  • OTHER REFERENCES: (none)
  • DEPENDENCIES: (left blank in the original)
  • CONTACT: Postel@USC-ISIB.ARPA

Authentication Service (AUTH) 🔐🦋

This server tells you who owns a particular TCP connection 👀 Give it a TCP port number pair and it returns a character string that identifies the owner on the server's system 🪪 Still Experimental, so, once again, check with the contact first 💅

  • STATUS: Experimental
  • SPECIFICATION: RFC 931
  • COMMENTS:
    • This 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. 🕵️
    • Please discuss any plans for implementation or use of this protocol with the contact. 💬
  • OTHER REFERENCES: Supercedes RFC 912
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: StJohns@MIT-Multics.ARPA

Bootstrap Protocol (BOOTP) 💻🌟

This one is a whole vibe 💫 It's an IP/UDP bootstrap protocol that helps a diskless client machine find its own IP address, the address of a server host, and the name of a file to load into memory and run 🚀 Still Experimental, so chat with the contact before you ship 🫶

  • STATUS: Experimental
  • SPECIFICATION: RFC 951
  • COMMENTS:
    • This proposed protocol provides an IP/UDP bootstrap protocol which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. 🥹
    • Please discuss any plans for implementation or use of this protocol with the contact. 💌
  • OTHER REFERENCES: (none)
  • DEPENDENCIES: Internet Protocol, User Datagram Protocol
  • CONTACT: Croft@SUMEX-AIM.ARPA

Appendices 📚✨

Okay bestie, the appendices are basically the cutest little registry of protocols and their assigned values. Every entry has a status, the spec it lives in, some comments, and a contact. Let's go 💅

Assigned Numbers 🔢

STATUS: None

SPECIFICATION: RFC 960

COMMENTS:

Describes the fields of various protocols that get specific values assigned for actual use, and lists the values that are currently assigned. 💖

Issued November 1985. It replaces RFC 943, RFC 790 in IPTW, and RFC 923.

OTHER REFERENCES: (left empty)

CONTACT: JKReynolds@USC-ISIB.ARPA

Pre-emption ⏫

STATUS: Elective

SPECIFICATION: RFC 794 (in IPTW)

COMMENTS:

This one's about how to do pre-emption of TCP connections. Iconic behaviour 👑

OTHER REFERENCES: (left empty)

CONTACT: Postel@USC-ISIB.ARPA

Service Mappings 🗺️

STATUS: None

SPECIFICATION: RFC 795 (in IPTW)

COMMENTS:

It maps the IP type of service field onto the parameters of some specific networks. 🦋

Out of date, needs revision. 🙈

OTHER REFERENCES: (left empty)

CONTACT: Postel@USC-ISIB.ARPA

Address Mappings 🏠

STATUS: None

SPECIFICATION: RFC 796 (in IPTW)

COMMENTS:

It maps Internet Addresses to the addresses of some specific networks. Very handy, very ✨

Out of date, needs revision. 🙈

OTHER REFERENCES: (left empty)

CONTACT: Postel@USC-ISIB.ARPA

Document Formats 📄

STATUS: None

SPECIFICATION: RFC 678

COMMENTS:

Standard format rules for several types of documents. Neat and tidy 🎀

OTHER REFERENCES: (left empty)

CONTACT: Postel@USC-ISIB.ARPA

Bitmap Formats 🖼️

STATUS: None

SPECIFICATION: RFC 797

COMMENTS:

A standard format for bitmap data. 🌈

OTHER REFERENCES: (left empty)

CONTACT: Postel@USC-ISIB.ARPA

Facsimile Formats 📠

STATUS: None

SPECIFICATION: RFC 804

COMMENTS:

A standard format for facsimile data. Old school but make it fashion 🧚

OTHER REFERENCES: (left empty)

CONTACT: Postel@USC-ISIB.ARPA

Host-Front End Protocol (HFEP) 🖥️

STATUS: Experimental 🧪

SPECIFICATION: RFC 929

COMMENTS:

Please discuss any plans for implementing or using this protocol with the contact. Don't just vibe in silence, bestie 🫶

OTHER REFERENCES: RFC 928

DEPENDENCIES: (left empty)

CONTACT: Padlipsky@USC-ISI.ARPA

Internet Protocol on X.25 Networks (IP-X25) 📡

STATUS: Recommended ⭐

SPECIFICATION: RFC 877

COMMENTS:

A standard for sending IP Datagrams over Public Data Networks. Literally the main character of public networks 💜

OTHER REFERENCES: (left empty)

CONTACT: jtk@PURDUE.ARPA

Internet Protocol on DC Networks (IP-DC) 🕰️

STATUS: Elective

SPECIFICATION: RFC 891

COMMENTS: (left empty)

OTHER REFERENCES:

  • RFC 778 - DCNET Internet Clock Service

CONTACT: Mills@USC-ISID.ARPA

Internet Protocol on Ethernet Networks (IP-E) 🔌

STATUS: Recommended ⭐

SPECIFICATION: RFC 894

COMMENTS: (left empty)

OTHER REFERENCES: RFC 893

CONTACT: Postel@USC-ISIB.ARPA

Internet Protocol on Experimental Ethernet Networks (IP-EE) 🧫

STATUS: Recommended ⭐

SPECIFICATION: RFC 895

COMMENTS: (left empty)

OTHER REFERENCES: (left empty)

CONTACT: Postel@USC-ISIB.ARPA

Internet Protocol on IEEE 802.3 (IP-IEEE) 🧩

STATUS: Recommended ⭐

SPECIFICATION: RFC 948

COMMENTS: A proposed protocol with two methods of encapsulating Internet Protocol (IP) datagrams on an IEEE 802.3 network. Two ways to slay, pick your fave 💅

OTHER REFERENCES: (left empty)

CONTACT: Ira@UPENN.CSNET

Internet Subnet Protocol (IP-SUB) 🧱

STATUS: Recommended ⭐

SPECIFICATION: RFC 950

COMMENTS:

This one sets out procedures for using subnets. Subnets are logically visible sub-sections of a single Internet, and they're a whole vibe 🌸

It's "Recommended" in the sense of "if you do subnetting at all, do it this way." No cap, that's the rule 🫶

OTHER REFERENCES: RFC 940, RFC 917, RFC 925, RFC 932, RFC 936, RFC 922

DEPENDENCIES: (left empty)

CONTACT: Mogul@SU-SCORE.ARPA

Broadcasting Internet Datagrams (IP-BROAD) 📢

STATUS: Experimental 🧪

SPECIFICATION: RFC 919

COMMENTS:

A proposed protocol with simple rules for broadcasting Internet datagrams on local networks that support broadcast. It covers addressing broadcasts, and how gateways should handle them. Lowkey essential 👑

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

OTHER REFERENCES: RFC 922

DEPENDENCIES: (left empty)

CONTACT: Mogul@SU-SCORE.ARPA

Address Resolution Protocol (ARP) 🔍

STATUS: Recommended ⭐

SPECIFICATION: RFC 826

COMMENTS:

This is the procedure for finding the network hardware address that corresponds to an Internet Address. It's giving detective 🕵️‍♀️

OTHER REFERENCES: (left empty)

CONTACT: Postel@USC-ISIB.ARPA

A Reverse Address Resolution Protocol (RARP) 🔄

STATUS: Elective

SPECIFICATION: RFC 903

COMMENTS:

This is the procedure that lets workstations dynamically find their protocol address (for example, their Internet Address) when all they know is their hardware address (for example, their attached physical network address). Glow up from zero to identity 🦋

OTHER REFERENCES: (left empty)

CONTACT: Mogul@SU-SCORE.ARPA

Multi-LAN Address Resolution Protocol (MARP) 🌐

STATUS: Experimental 🧪

SPECIFICATION: RFC 925

COMMENTS:

A discussion of the various problems, and potential solutions, for "transparent subnets" in a multi-LAN environment. Very complex, very iconic 🧠

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

OTHER REFERENCES: RFC 917, RFC 826

DEPENDENCIES: (left empty)

CONTACT: Postel@USC-ISIB.ARPA

Broadcasting Internet Datagrams with Subnets (IP-SUB-BROAD) 📣

STATUS: Experimental 🧪

SPECIFICATION: RFC 922

COMMENTS:

This is the same kind of proposal as the broadcasting one: simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. Just with subnets added in 🌷

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

OTHER REFERENCES: (left empty)

DEPENDENCIES: (left empty)

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, for example SATNET or WBNET. Space-core energy 🚀

Note: Implementations of HAP should be performed in coordination with satellite network development and operations personnel. Don't go rogue with the satellite crew, bestie 🙏

OTHER REFERENCES: (left empty)

DEPENDENCIES: (left empty)

CONTACT: Schoen@BBN-UNIX.ARPA

Reliable Asynchronous Transfer Protocol (RATP) 🔁

STATUS: Experimental 🧪

SPECIFICATION: RFC 916

COMMENTS:

This paper specifies a protocol that lets two programs reliably communicate over a communication link. It makes sure that the data entering one end of the link, if received, arrives at the other end intact and unaltered. Reliability is everything 💖

The proposed protocol is designed to operate over a full duplex point-to-point connection. It also has some features tailored to the RS-232 links that were in use at the time 🎀

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

OTHER REFERENCES: (left empty)

DEPENDENCIES: Transmission Control Protocol

CONTACT: Finn@USC-ISIB.ARPA

Thinwire Protocol (THINWIRE) 🪶

STATUS: Experimental 🧪

SPECIFICATION: RFC 914

COMMENTS:

This paper discusses a Thinwire Protocol for connecting personal computers to the ARPA-Internet. It focuses mainly on the particular problems of low speed network interconnection with personal computers on the ARPA-Internet, and on possible methods of solving them. Underrated and so necessary 🌙

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

OTHER REFERENCES: (left empty)

DEPENDENCIES: (left empty)

CONTACT: Farber@ROCHESTER.ARPA

📦 where this page comes from