RFC 1011

Official Internet protocols

📅 published May 1987, from ietf

OFFICIAL INTERNET PROTOCOLS 🦋

okay bestie, this one is the RFC that says which protocols are officially the protocols of the Internet 😭✨ It's RFC 1011, written in May 1987 by J. Reynolds and J. Postel from ISI (the Information Sciences Institute), for the Network Working Group. It obsoletes RFCs 991, 961, 943, 924, 901, 880, and 840. It's an official status report, so the whole point is "here's the list, here's what each one is for." 🌸

STATUS OF THIS MEMO 🎀

This memo is an official status report on the protocols used in the Internet community. Distribution of this memo is unlimited. 💅

INTRODUCTION 🧚

This RFC identifies the documents that specify the official protocols used in the Internet. Comments indicate any revisions or changes planned. 📚

To first order, the official protocols are the ones specified in the "DDN Protocol Handbook" (DPH), dated December 1985. This is a three volume set with a total thickness of about 5 inches. the thickest binder you've ever seen 😭📖

There are older collections that include many of these specifications:

  • the "Internet Protocol Transition Workbook" (IPTW), dated March 1982;
  • the "Internet Mail Protocols", dated November 1982;
  • the "Internet Telnet Protocols and Options", dated June 1983.

There's also a volume of protocol-related information called the "Internet Protocol Implementers Guide" (IPIG), dated August 1982. And the oldest one is the "ARPANET Protocol Handbook" (APH), dated January 1978. Nearly all the relevant material from these collections has been reproduced in the current DPH. ✨

The following material is organized as a sketchy outline. The entries are protocols (for example, Transmission Control Protocol). Each entry has notes on status, specification, comments, other references, dependencies, and contact. 🦋

Here's what each of those fields means:

  • The STATUS is one of: required, recommended, elective, experimental, or none.
  • 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.

Now the status values, because these are the important part 👑

  • required: all hosts must implement the required protocol.
  • recommended: all hosts are encouraged to implement the recommended protocol.
  • elective: hosts may implement or not implement 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, contact:

Joyce K. Reynolds
USC - Information Sciences Institute
4676 Admiralty Way
Marina del Rey, California  90292-6695

Phone: (213) 822-1511

Electronic mail: JKREYNOLDS@ISI.EDU

OVERVIEW 🌈

Catenet Model 🌐

STATUS: None

SPECIFICATION: IEN 48 (in DPH)

COMMENTS:

Gives an overview of the organization and principles of the Internet. It's giving "big picture" energy 🫶

Could be revised and expanded.

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@ISI.EDU

NETWORK LEVEL 🔥

Internet Protocol (IP) 🌍

STATUS: Required

SPECIFICATION: RFC 791 (in DPH)

COMMENTS:

This is the universal protocol of the Internet. This datagram protocol provides the universal addressing of hosts in the Internet. the main character of the whole thing 👑

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. 🙈 The MIL-STD description of source routing is wrong in some of the details.

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. no ICMP, no IP, periodt 💀

The subnet procedures defined in RFC 950 are now considered an essential part of the IP architecture and must be implemented by all hosts and gateways. ✨

OTHER REFERENCES:

RFC 815 (in DPH) - IP Datagram Reassembly Algorithms

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

RFC 816 (in DPH) - Fault Isolation and Recovery

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

MIL-STD-1777 (in DPH) - Military Standard Internet Protocol

RFC 963 - Some Problems with the Specification of the Military Standard Internet Protocol

DEPENDENCIES: (none listed)

CONTACT: Postel@ISI.EDU

Internet Control Message Protocol (ICMP) 🚨

STATUS: Required

SPECIFICATION: RFC 792 (in DPH)

COMMENTS:

The control messages and error reports that go with the Internet Protocol. The helpful little messages that tell you when something went wrong 🫠

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.

Two additional ICMP message types are defined in RFC 950 "Internet Subnets": Address Mask Request (A1=17) and Address Mask Reply (A2=18). New message types, new vibes 🍓

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. (yes, I'm repeating it, it's that important 😭)

OTHER REFERENCES: RFC 950

DEPENDENCIES: Internet Protocol

CONTACT: Postel@ISI.EDU

Internet Group Multicast Protocol (IGMP) 📡

STATUS: Recommended

SPECIFICATION: RFC 988

COMMENTS:

This protocol specifies the extensions required of a host implementation of the Internet Protocol (IP) to support internetwork multicasting. This specification supersedes the one given in RFC 966, and constitutes a proposed protocol standard for IP multicasting in the Internet. Reference RFC 966 for a discussion of the motivation and rationale behind the multicasting extension specified here. it's the group chat for packets 🦋💜

OTHER REFERENCES: RFC 966

DEPENDENCIES: Internet Protocol

CONTACT: Deering@PESCADERO.STANFORD.EDU

HOST LEVEL ✨

Okay bestie, we're going up a layer now, to the host level 🖥️ This is where the protocols actually live on the machines themselves, and some of them are absolute legends. Let's go 💅

User Datagram Protocol (UDP) 📦

  • STATUS: Recommended
  • SPECIFICATION: RFC 768 (in DPH)

UDP gives applications a datagram service and adds port addressing on top of the IP services. Iconic, honestly 🦋

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

  • DEPENDENCIES: Internet Protocol
  • CONTACT: Postel@ISI.EDU

Transmission Control Protocol (TCP) 🌸

  • STATUS: Recommended
  • SPECIFICATION: RFC 793 (in DPH)

TCP is the reliable end-to-end data stream service, the one everyone's always relying on without even knowing it 🫶

Quick tea: a bunch of comments and corrections came in for the TCP spec. Mostly these are document bugs, not protocol bugs. So the protocol is fine, the writing just needed some love 💜

Here's the breakdown:

Event Processing Section: There are lots of minor corrections and clarifications needed in this section. Noted 📝

Push: Some phrases in the document still give a "record mark" flavor to the push. These should be clarified further. The push is not a record mark, so let's not let it be confused 🙅‍♀️

Urgent: Page 17 is wrong. The urgent pointer points to the last octet of urgent data, not the first octet of non-urgent data. Main character correction energy 👑

Listening Servers: Several people had trouble contacting listening servers 😭 The doc should discuss implementation issues for servers, and add 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 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, and the default TCP Maximum Segment Size is 536. For more on this, see RFC 879 🧚

Idle Connections: People asked about automatically closing idle connections. Idle connections are ok and should not be closed! There are several cases where they happen, like in Telnet when a user is thinking for a long time after a message from the server computer before their next input. And there is no TCP "probe" mechanism, and none is needed. We love a patient connection 🍓

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, that data is to be kept, so it can be handed to the user if they make a RECV call. Don't let the data get ghosted 👻

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. Real talk, that penalty is no joke 💀

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 and the TCB should not be deleted. If the user wants to give up, they should explicitly ABORT the connection. Boundaries matter, periodt 💅

  • OTHER REFERENCES:
    • RFC 813 (in DPH) - Window and Acknowledgement Strategy in TCP
    • RFC 814 (in DPH) - Names, Addresses, Ports, and Routes
    • RFC 816 (in DPH) - Fault Isolation and Recovery
    • RFC 817 (in DPH) - 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 (in DPH) - Military Standard Transmission Control Protocol
    • RFC 964 - Some Problems with the Specification of the Military Standard Transmission Control Protocol
    • Zhang, Lixia, "Why TCP Timers Don't Work Well", Communications Architectures and Protocols, ACM SIGCOMM Proceedings, Computer Communications Review, V.16, N.3, August 1986.
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Postel@ISI.EDU

Bulk Data Transfer Protocol (NETBLT) 🚀

  • STATUS: Experimental
  • SPECIFICATION: RFC 998

This is a revised RFC on the discussion of the Network Block Transfer (NETBLT) protocol.

NETBLT is a transport level protocol for rapidly moving a large amount of data between computers. It's reliable and flow controlled, and it's built for maximum throughput over a wide variety of networks. It currently runs on top of IP, but it should be able to run on any datagram protocol that works similarly to IP. Very ambitious, very cute 🌈

This doc is published for discussion and comment, and it does not constitute a standard. The proposal may change, and some parts of the protocol haven't been specified yet, so implementing it is not advised 🙈

  • OTHER REFERENCES: RFC 969
  • DEPENDENCIES: Transmission Control Protocol, User Datagram Protocol
  • CONTACT: markl@PTT.LCS.MIT.EDU

Exterior Gateway Protocol (EGP) 🌐

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

Please talk to the contact about any plans to implement or use this protocol 💌

  • OTHER REFERENCES: RFC 827, RFC 890
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Mills@UDEL.EDU

Gateway Gateway Protocol (GGP) 🛰️

  • STATUS: Experimental
  • SPECIFICATION: RFC 823 (in DPH)

This is the gateway protocol now used in the core gateways. Core energy, no notes 👑

Please talk to the contact about any plans to implement or use this protocol 💌

  • OTHER REFERENCES: None listed
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Brescia@BBN.COM

Host Monitoring Protocol (HMP) 🔍

  • STATUS: Elective
  • SPECIFICATION: RFC 869 (in DPH)

This is a great tool for debugging protocol implementations on remotely located computers. Debugging from afar is giving spy-mode 🕵️‍♀️

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

  • OTHER REFERENCES: None listed
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Hinden@BBN.COM

Reliable Data Protocol (RDP) 📮

  • STATUS: Experimental
  • SPECIFICATION: RFC 908 (in DPH)

RDP is made to efficiently support bulk data transfer for host monitoring and control applications, like loading and dumping and remote debugging. It's designed to be simple to implement while still being efficient where transmission delays are long and where message segments may get lost or arrive out of sequence. Simple but still strong, which is the whole vibe 💪

Please talk to the contact about any plans to implement or use this protocol 💌

  • OTHER REFERENCES: None listed
  • DEPENDENCIES: Internet Protocol
  • CONTACT: CWelles@BBN.COM

Internet Reliable Transaction Protocol (IRTP) 🧾

  • STATUS: Experimental
  • SPECIFICATION: RFC 938

This is a transport level host to host protocol designed for an internet environment. The issues it covers might not be directly relevant to the research problems of the Internet community, but a number of researchers and implementors may still find them interesting 🤓

  • OTHER REFERENCES: None listed
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Trudy@ACC.ARPA

Cross Net Debugger (XNET) 🐞

  • STATUS: Elective
  • SPECIFICATION: IEN 158 (in DPH)

XNET is a debugging protocol that lets you have debugger-like access to remote systems. Remote access with a side of drama 🎀

This specification should be updated and reissued as an RFC.

  • OTHER REFERENCES: RFC 643
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Postel@ISI.EDU

Multiplexing Protocol (MUX) 🧩

  • STATUS: Experimental
  • SPECIFICATION: IEN 90 (in DPH)

MUX defines a way to combine several segments from different higher level protocols into one IP datagram. Packing multiple outfits into one suitcase 🧳

There's no current experiment in progress. There's some question about how far the sharing this protocol envisions can actually happen. There are also some concerns that the information captured in the multiplexing header may be (a) insufficient, or (b) over specific.

Please talk to the contact about any plans to implement or use this protocol 💌

  • OTHER REFERENCES: None listed
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Postel@ISI.EDU

Stream Protocol (ST) 🌊

  • STATUS: Experimental
  • SPECIFICATION: IEN 119 (in DPH)

ST is a gateway resource allocation protocol made for multihost real time applications. Real-time energy, always on time ⏰

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 talk to the contact about any plans to implement or use this protocol 💌

  • OTHER REFERENCES: None listed
  • DEPENDENCIES: Internet Protocol
  • CONTACT: jwf@LL-EN.ARPA

Network Voice Protocol (NVP-II) 🎙️

  • STATUS: Experimental
  • SPECIFICATION: ISI Internal Memo

NVP-II defines the procedures for real time voice conferencing. Group call, but make it protocol 📞

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

Please talk to the contact about any plans to implement or use this protocol 💌

  • OTHER REFERENCES: RFC 741 (in DPH)
  • DEPENDENCIES: Internet Protocol, Stream Protocol
  • CONTACT: Casner@ISI.EDU

APPLICATION LEVEL 💅

We made it to the top of the stack, bestie! These are the protocols that real people touch every day 🫶

Telnet Protocol (TELNET) 💻

  • STATUS: Recommended
  • SPECIFICATION: RFC 854 (in DPH)

Telnet is the protocol for remote terminal access. Old school, still iconic 🖤

This has been revised since the IPTW. RFC 764 in IPTW is now obsolete, so don't go reading that one anymore 🙅‍♀️

  • OTHER REFERENCES:
    • MIL-STD-1782 (in DPH) - Telnet Protocol
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Postel@ISI.EDU

Telnet Options (TELNET-OPTIONS) ⚙️

  • STATUS: Elective
  • SPECIFICATION: General description of options: RFC 855 (in DPH)

Okay so this is the Telnet options table, and it's giving "a lot of options, not all of them are going to make the cut" 💅

      Number   Name                                    RFC  NIC  DPH USE
      ------   ---------------------------------       --- ----- --- ---
         0     Binary Transmission                     856 ----- yes yes
         1     Echo                                    857 ----- yes yes
         2     Reconnection                            ... 15391 yes  no
         3     Suppress Go Ahead                       858 ----- yes yes
         4     Approx Message Size Negotiation         ... 15393 yes  no
         5     Status                                  859 ----- yes yes
         6     Timing Mark                             860 ----- yes yes
         7     Remote Controlled Trans and Echo        726 39237 yes  no
         8     Output Line Width                       ... 20196 yes  no
         9     Output Page Size                        ... 20197 yes  no
        10     Output Carriage-Return Disposition      652 31155 yes  no
        11     Output Horizontal Tabstops              653 31156 yes  no
        12     Output Horizontal Tab Disposition       654 31157 yes  no
        13     Output Formfeed Disposition             655 31158 yes  no
        14     Output Vertical Tabstops                656 31159 yes  no
        15     Output Vertical Tab Disposition         657 31160 yes  no
        16     Output Linefeed Disposition             658 31161 yes  no
        17     Extended ASCII                          698 32964 yes  no
        18     Logout                                  727 40025 yes  no
        19     Byte Macro                              735 42083 yes  no
        20     Data Entry Terminal                     732 41762 yes  no
        21     SUPDUP                              734 736 42213 yes  no
        22     SUPDUP Output                           749 45449 yes  no
        23     Send Location                           779 ----- yes  no
        24     Terminal Type                           930 ----- yes  no
        25     End of Record                           885 ----- yes  no
        26     TACACS User Identification              927 ----- yes  no
        27     Output Marking                          933 ----- yes  no
        28     Terminal Location Number                946 -----  no  no
       255     Extended-Options-List                   861 ----- yes yes

The DHP column tells you whether the spec is in the DDN Protocol Handbook, and the USE column tells you which options are in general use 🎀

Comments time, bestie 🫶

Binary Transmission, Echo, Suppress Go Ahead, Status, Timing Mark, and Extended Options List were recently updated and reissued, and they're the most frequently implemented options. The rest should get a review, the useful ones should be 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@ISI.EDU

SUPDUP Protocol (SUPDUP) 🖥️

  • STATUS: Elective
  • SPECIFICATION: RFC 734 (in DPH)

Comments: it's a special Telnet-like protocol for display terminals, so it's giving "Telnet but make it a screen" ✨

  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Crispin@SU-SCORE.STANFORD.EDU

File Transfer Protocol (FTP) 📁

  • STATUS: Recommended
  • SPECIFICATION: RFC 959 (in DPH)

FTP is the protocol for moving files between Internet hosts, and it's iconic because it provides access control and negotiation of file parameters 👑

This edition adds some new optional commands: CDUP (Change to Parent Directory), SMNT (Structure Mount), STOU (Store Unique), RMD (Remove Directory), MKD (Make Directory), PWD (Print Directory), and SYST (System). And this spec is compatible with the previous edition, RFC 765, so no drama there 🙌

Now the tea ☕ There's a discrepancy in the examples of Appendix II. On page 63, a response code of 200 is shown as the reply to a CWD command. But the list of Command-Reply Sequences cited on page 50 says CWD only accepts a 250 response code. So if you treat CWD as excluded from the File System functional category, you can assume the 200 is correct, since CDUP, as a special case of CWD, does use 200 🧐

  • OTHER REFERENCES:
    • RFC 678 (in DPH) - Document File Format Standards
    • MIL-STD-1780 (in DPH) - File Transfer Protocol
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Postel@ISI.EDU

Trivial File Transfer Protocol (TFTP) 🐣

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

TFTP is a very simple file moving protocol, and no access control is provided, so it's very "no security guard at the door" 🙈 It's in use in several local networks 🏠

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

Note: the DPH contains IEN-133, which is an obsolete version of this protocol 📜

  • OTHER REFERENCES: none listed
  • DEPENDENCIES: User Datagram Protocol
  • CONTACT: Postel@ISI.EDU

Simple File Transfer Protocol (SFTP) 🧪

  • STATUS: Experimental
  • SPECIFICATION: RFC 913 (in DPH)

SFTP is a simple file transfer protocol that fills the gap 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, 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: none listed
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: MKL@SRI-NIC.ARPA

Simple Mail Transfer Protocol (SMTP) 💌

  • STATUS: Recommended
  • SPECIFICATION: RFC 821 (in DPH)

SMTP is the procedure for transmitting computer mail between hosts 📬

This has been revised since the IPTW. It's in the "Internet Mail Protocols" volume of November 1982. RFC 788 (in IPTW) is obsolete 🗑️

There were many misunderstandings and errors in the early implementations. Some documentation of these problems can be found in the file [C.ISI.EDU]<SMTP>MAIL.ERRORS 🫠

Some minor differences between RFC 821 and RFC 822 should be resolved 🧩

  • OTHER REFERENCES:
    • RFC 822 - Mail Header Format Standards
      • This has been revised since the IPTW. It's 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.
      • Note: RFC 822 is not included in the DPH (an accident, it should have been) 😭
    • MIL-STD-1781 (in DPH) - Simple Mail Transfer Protocol (SMTP)
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Postel@ISI.EDU

Network News Transfer Protocol (NNTP) 📰

  • STATUS: Experimental
  • SPECIFICATION: RFC 977

NNTP is a protocol for the distribution, inquiry, retrieval, and posting of news articles, using reliable stream-based transmission across the Internet community 🌐 News articles live in a central database, so a subscriber can pick out only the items they want to read 👀 Indexing, cross-referencing, and expiration of aged messages are also provided 🗂️

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

  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Brian@SDCSVAX.UCSD.EDU

Post Office Protocol - Version 2 (POP2) 📮

  • STATUS: Experimental
  • SPECIFICATION: RFC 937 (in DPH)

POP2 lets 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) ✉️

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@ISI.EDU

NetBIOS Services Protocol (NETBIOS) 🌈

  • STATUS: Recommended
  • SPECIFICATION: RFC 1001, 1002

These documents define a proposed standard protocol that supports NetBIOS services in a TCP/IP environment. Both local network and internet operation are supported. Various node types are defined to fit local and internet topologies, and to allow operation with or without IP broadcast 📡

RFC 1001 describes the NetBIOS-over-TCP protocols in a general manner, with emphasis on the underlying ideas and techniques 🧠 RFC 1002 gives the detailed specifications of the NetBIOS-over-TCP packets, protocols, and defined constants and variables 🔬

  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Transmission Control Protocol, User Datagram Protocol
  • CONTACT: Auerbach@CSL.SRI.COM

Bootstrap Protocol (BOOTP) 🥾

  • STATUS: Experimental
  • SPECIFICATION: RFC 951

This proposed protocol is an IP/UDP bootstrap protocol. It lets a diskless client machine 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 listed
  • DEPENDENCIES: Internet Protocol, User Datagram Protocol
  • CONTACT: Croft@SUMEX-AIM.STANFORD.EDU

Loader Debugger Protocol (LDP) 🛠️

  • STATUS: Experimental
  • SPECIFICATION: RFC 909

LDP specifies a protocol for loading, dumping, and debugging target machines from hosts in a network environment. It's designed to accommodate a variety of target CPU types 🖥️ It provides a powerful set of debugging services, but it's also structured so that a simple subset can be implemented in applications like boot loading, where efficiency and space are at a premium 🧚

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

  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Reliable Data Protocol
  • CONTACT: Hinden@BBN.COM

Remote Job Entry (RJE) 🧚

  • STATUS: Elective
  • SPECIFICATION: RFC 407 (in DPH)
  • COMMENTS: The general protocol for submitting batch jobs and getting the results back. Some changes are needed for use with TCP. No known active implementations, bestie 😭
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: File Transfer Protocol, Transmission Control Protocol
  • CONTACT: Postel@ISI.EDU

Remote Job Service (NETRJS) 🎀

  • STATUS: Elective
  • SPECIFICATION: RFC 740 (in DPH)
  • COMMENTS: A special protocol for submitting batch jobs and retrieving the results, used with the UCLA IBM OS system. If you're planning to implement or use this one, please discuss it with the contact first 💅 Revision in progress!
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Braden@ISI.EDU

Remote Telnet Service (RTELNET) 🦋

  • STATUS: Elective
  • SPECIFICATION: RFC 818 (in DPH)
  • COMMENTS: Gives you special access to user Telnet on a remote system. Iconic 👑
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Telnet, Transmission Control Protocol
  • CONTACT: Postel@ISI.EDU

Graphics Protocol (GRAPHICS) 🌸

  • STATUS: Elective
  • SPECIFICATION: NIC 24308 (in DPH)
  • COMMENTS: The protocol for vector graphics. Very minor changes are needed for use with TCP. No known active implementations.
  • Note: The DPH claims this is RFC 493, but RFC 493 is actually a different, earlier specification. Not the same thing, babe 🙈
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Telnet, Transmission Control Protocol
  • CONTACT: Postel@ISI.EDU

Echo Protocol (ECHO) 🫶

  • STATUS: Recommended
  • SPECIFICATION: RFC 862 (in DPH)
  • COMMENTS: A debugging protocol that sends back whatever you send it. Literally a mirror, it's giving main character energy 🪞
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@ISI.EDU

Discard Protocol (DISCARD) 🗑️

  • STATUS: Elective
  • SPECIFICATION: RFC 863 (in DPH)
  • COMMENTS: A debugging protocol that throws away whatever you send it. Ate and left no crumbs 💀
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@ISI.EDU

Character Generator Protocol (CHARGEN) 🔥

  • STATUS: Elective
  • SPECIFICATION: RFC 864 (in DPH)
  • COMMENTS: A debugging protocol that sends you ASCII data. Pure text chaos, I'm obsessed ✨
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@ISI.EDU

Quote of the Day Protocol (QUOTE) 💜

  • STATUS: Elective
  • SPECIFICATION: RFC 865 (in DPH)
  • COMMENTS: A debugging protocol that sends you a short ASCII message. Daily affirmations, but make it networking 🥹
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@ISI.EDU

Statistics Server (STATSRV) 📊

  • STATUS: Recommended
  • SPECIFICATION: RFC 996
  • COMMENTS: This RFC specifies a standard for the Internet community. Hosts and gateways on the Internet that choose to implement a remote statistics monitoring facility may use this protocol to send statistics data upon request to a monitoring center or debugging host. Ngl, this one is very organised 🧠
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Mills@UDEL.EDU

Active Users Protocol (USERS) 🌈

  • STATUS: Elective
  • SPECIFICATION: RFC 866 (in DPH)
  • COMMENTS: Lists the currently active users. Who's online? Everyone, bestie 👀
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@ISI.EDU

Finger Protocol (FINGER) 🍓

  • STATUS: Elective
  • SPECIFICATION: RFC 742 (in DPH)
  • COMMENTS: Provides information on the current or most recent activity of a user. Some extensions have been suggested. Some changes are needed for TCP. The way that it's still going strong 😌
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Postel@ISI.EDU

WhoIs Protocol (NICNAME) 🔍

  • STATUS: Elective
  • SPECIFICATION: RFC 954 (in DPH)
  • COMMENTS: Accesses the ARPANET Directory database. It lets you find out about people, their addresses, phone numbers, organisations, and mailboxes. Stalker-core, but make it official 🕵️‍♀️
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Feinler@SRI-NIC.ARPA

CSNET Mailbox Name Server Protocol (CSNET-NS) 🧪

  • STATUS: Experimental
  • SPECIFICATION: CS-DN-2 (in DPH)
  • COMMENTS: Provides access to the CSNET database of users, so you can get info about user names, affiliations, and mailboxes. If you're planning to implement or use this one, please discuss it with the contact first 🙏
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Solomon@WISC.EDU

Domain Name Protocol (DOMAIN) 🌍

  • STATUS: Recommended
  • SPECIFICATION: RFC 881, RFC 882, RFC 883 (in DPH)
  • COMMENTS: None listed.
  • OTHER REFERENCES:
    • RFC 920 - Domain Requirements
    • RFC 921 - Domain Name Implementation Schedule - Revised
    • RFC 973 - Domain System Changes and Observations
    • RFC 974 - Mail Routing and the Domain System
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Mockapetris@ISI.EDU

HOSTNAME Protocol (HOSTNAME) 🏠

  • STATUS: Elective
  • SPECIFICATION: RFC 953 (in DPH)
  • COMMENTS: Accesses the Registered Internet Hosts database (HOSTS.TXT). It provides a way to find out about a host on the Internet, its Internet Address, and the protocols it implements. Lowkey the OG address book 📒
  • OTHER REFERENCES:
    • RFC 952 - Host Table Specification
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Feinler@SRI-NIC.ARPA

Host Name Server Protocol (NAMESERVER) 🕰️

  • STATUS: Experimental
  • SPECIFICATION: IEN 116 (in DPH)
  • COMMENTS: Provides a 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 favour of the DOMAIN protocol. Further implementations of this protocol are not advised. Bestie, it's a retired legend 🪦 Please discuss any plans for implementation or use of this protocol with the contact.

  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: User Datagram Protocol
  • CONTACT: Postel@ISI.EDU

Daytime Protocol (DAYTIME) ☀️

  • STATUS: Elective
  • SPECIFICATION: RFC 867 (in DPH)
  • COMMENTS: Provides the day and time as an ASCII character string. Simple, clean, no drama 💅
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@ISI.EDU

Network Time Protocol (NTP) ⏰

  • STATUS: Experimental
  • SPECIFICATION: RFC 958
  • COMMENTS: A proposed protocol for synchronising 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. Clock sync is so important, it's giving timekeeping royalty ✨
  • OTHER REFERENCES: RFC 778, RFC 891, RFC 956, and RFC 957.
  • DEPENDENCIES: User Datagram Protocol
  • CONTACT: Mills@UDEL.EDU

Time Server Protocol (TIME) 🕐

  • STATUS: Elective
  • SPECIFICATION: RFC 868 (in DPH)
  • COMMENTS: Provides the time as a number of seconds from a specified reference time. Counting seconds like it's my job 🧮
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@ISI.EDU

DCNET Time Server Protocol (CLOCK) 🕰️

  • STATUS: Experimental
  • SPECIFICATION: RFC 778
  • COMMENTS: Provides a mechanism for keeping synchronised clocks. Please discuss any plans for implementation or use of this protocol with the contact.
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Internet Control Message Protocol
  • CONTACT: Mills@UDEL.EDU

Authentication Service (AUTH) 🔐

  • 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 that 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. The identity check is giving detective era 🕵️
  • OTHER REFERENCES: Supercedes RFC 912
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: StJohns@SRI-NIC.ARPA
  • STATUS: Experimental
  • SPECIFICATION: RFC 1004
  • COMMENTS: This RFC focuses its discussion on authentication problems in the Internet and possible methods of solution. Please discuss any plans for implementation or use of this protocol with the contact. A cookie jar, but for security 🫙
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: None listed.
  • CONTACT: Mills@UDEL.EDU

Internet Message Protocol (MPM) 📨

  • STATUS: Experimental
  • SPECIFICATION: RFC 759 (in DPH)
  • 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. Multimedia mail, the aesthetic 🎞️
  • OTHER REFERENCES:
    • RFC 767 - Structured Document Formats
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Postel@ISI.EDU

Network Standard Text Editor (NETED) ✏️

  • STATUS: Elective
  • SPECIFICATION: RFC 569 (in DPH)
  • COMMENTS: Describes a simple line editor that could be provided by every Internet host. Minimalism is the whole vibe 🤍
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: None listed.
  • CONTACT: Postel@ISI.EDU

APPENDICES 🎀

Internet Numbers 🌟

  • STATUS: None

This one picks up mid-entry, so I'll carry straight on.

SPECIFICATION: RFC 997

Sooo this one is all about the fields for network numbers and autonomous system numbers that get real values for actual use, plus the list of what's currently assigned 📚✨. It was issued in March 1987 and replaces RFC 990, RFC 790 in IPTW, and RFC 960. Bestie, no other references, and the contact is Hostmaster@SRI-NIC.ARPA 💌

Assigned Numbers 🎀

STATUS: None

SPECIFICATION: RFC 1010

Okay this one is giving "the fields of a bunch of protocols get their real values" energy 💅 It's the protocol-side version of the numbers list, and it lists what's currently assigned. Issued May 1987, replaces RFC 990, RFC 790 in IPTW, and RFC 960. Other references are blank, and the contact is JKREYNOLDS@ISI.EDU 🦋

Pre-emption 🌸

STATUS: Elective

SPECIFICATION: RFC 794 (in DPH)

This one describes how to do pre-emption of TCP connections 🔥 Contact is Postel@ISI.EDU 🫶

Service Mappings 🧚

STATUS: None

SPECIFICATION: RFC 795 (in DPH)

It's the mapping of the IP type of service field onto the parameters of some specific networks 🍓 It's out of date and needs revision, so be warned 💀 Contact is Postel@ISI.EDU.

Address Mappings 🌈

STATUS: None

SPECIFICATION: RFC 796 (in DPH)

This covers the mapping between Internet Addresses and the addresses of some specific networks 🗺️ Also out of date and needs revision, sorry besties 😭 Contact is Postel@ISI.EDU.

Document Formats 📄

STATUS: None

SPECIFICATION: RFC 678 (in DPH)

Standard format rules for several types of documents, periodt 💜 Contact is Postel@ISI.EDU.

Equations Representation ➗

STATUS: None

SPECIFICATION: RFC 1003

This one identifies and explores the issues in defining a standard for exchanging mathematical equations 🧮✨ Contact is Katz@ISI.EDU.

Bitmap Formats 🖼️

STATUS: None

SPECIFICATION: RFC 797 (in DPH)

Describes a standard format for bitmap data 🌷 Contact is Postel@ISI.EDU.

Facsimile Formats 📠

STATUS: None

SPECIFICATION: RFC 804

It describes a standard format for facsimile data 💖 Other references are RFC 769 (in DPH), and the contact is Postel@ISI.EDU.

Host-Front End Protocol (HFEP) 🧚‍♀️

STATUS: Experimental

SPECIFICATION: RFC 929

Please discuss any plans for implementation or use of this protocol with the contact 🫶 OTHER REFERENCES: RFC 928. DEPENDENCIES: (blank in the original). CONTACT: Padlipsky@ISI.EDU.

Internet Protocol on ARPANET (IP-ARPA) 🛰️

STATUS: Recommended

SPECIFICATION: BBN Report 1822

This one describes the interface between a Host and an IMP, and by implication how IP Datagrams get transmitted over the ARPANET 🚀✨ OTHER REFERENCES: RFC 851, RFC 852, RFC 878 (in DPH), RFC 979, RFC 1005. CONTACT: Malis@BBN.COM.

Internet Protocol on WBNET (IP-WB) 🌊

STATUS: Recommended

SPECIFICATION: RFC 907 (in DPH)

Okay so this one is a standard for sending IP Datagrams over the Wideband Net 🎧 It 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: (blank in the original). CONTACT: Blumenthal@BBN.COM.

Internet Protocol on Wideband Network (IP-WB) 🌊

STATUS: Recommended

SPECIFICATION: RFC 907 (in DPH)

This is basically the same vibe as the WBNET one above: a standard for sending IP Datagrams over the WBNET 🎀 It 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: (blank in the original). DEPENDENCIES: (blank in the original). CONTACT: Schoen@BBN.COM.

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

STATUS: Recommended

SPECIFICATION: RFC 877 (in DPH)

A standard for transmitting IP Datagrams over Public Data Networks 🌐 OTHER REFERENCES: (blank in the original). CONTACT: jtk@PURDUE.EDU.

Internet Protocol on DC Networks (IP-DC) 🧊

STATUS: Elective

SPECIFICATION: RFC 891 (in DPH)

COMMENTS: (blank in the original)

OTHER REFERENCES: RFC 778 - DCNET Internet Clock Service. CONTACT: Mills@UDEL.EDU.

Internet Protocol on Ethernet Networks (IP-E) 🔌

STATUS: Recommended

SPECIFICATION: RFC 894 (in DPH)

COMMENTS: (blank in the original)

OTHER REFERENCES: RFC 893. CONTACT: Postel@ISI.EDU.

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

STATUS: Recommended

SPECIFICATION: RFC 895 (in DPH)

COMMENTS: (blank in the original)

OTHER REFERENCES: (blank in the original). CONTACT: Postel@ISI.EDU.

Internet Protocol on IEEE 802 (IP-IEEE) 🌟

STATUS: Recommended

SPECIFICATION: see comments

Okay this one is a whole saga 🥹 At an ad hoc special session on "IEEE 802 Networks and ARP" held during the TCP Vendors Workshop (August 1986), people came up with a consistent way to send DOD-IP datagrams and other IP related protocols on 802 networks ✨

Due to some evolution of the IEEE 802.2 standards, and the need for a standard way to do additional DOD-IP related protocols (such as Address Resolution Protocol (ARP)) on IEEE 802 networks, the following new policy is established. It replaces the current policy (see RFC-990 section on IEEE 802 Numbers of Interest, and RFC-948) 💅

The policy is for the DDN and Internet community to use IEEE 802.2 encapsulation on 802.3, 802.4, and 802.5 networks, using the SNAP with an organization code indicating that the following 16 bits specify the Ethertype code (where IP = 2048 (0800 hex), see RFC-1010 section on Ethernet Numbers of Interest) 🎀

                                                                  Header

   ...--------+--------+--------+
    MAC Header|      Length     |               802.{3/4/5} MAC
   ...--------+--------+--------+

   +--------+--------+--------+
   | Dsap=K1| Ssap=K1| control|                       802.2 SAP
   +--------+--------+--------+
   +--------+--------+---------+--------+--------+
   |protocol id or org code =K2|    Ether Type   |   802.2 SNAP
   +--------+--------+---------+--------+--------+

The total length of the SAP Header and the SNAP header is 8-octets, which makes the 802.2 protocol overhead land on a nice boundary 🧚

K1 is 170. The IEEE like to talk about things in bit transmission order and specify this value as 01010101. In big-endian order, as used in Internet specifications, this becomes 10101010 binary, or AA hex, or 170 decimal 🔢✨

K2 is 0 (zero) 🫶

Note: The method described in RFC 948 (in DPH) is no longer to be used. 💀

OTHER REFERENCES: (blank in the original). CONTACT: Postel@ISI.EDU.

Internet Subnet Protocol (IP-SUB) 🧩

STATUS: Required

SPECIFICATION: RFC 950

Bestie, this is a very important feature, and every IP implementation must include it 👑 It specifies procedures for the use of subnets, which are logical sub-sections of a single Internet network 🌈

OTHER REFERENCES: RFC 940, RFC 917, RFC 925, RFC 932, RFC 936, RFC 922. DEPENDENCIES: (blank in the original). CONTACT: Mogul@SU-SCORE.STANFORD.EDU.

Address Resolution Protocol (ARP) 🔍

STATUS: Recommended

SPECIFICATION: RFC 826 (IN DPH)

This is a procedure for finding the network hardware address that corresponds to an Internet Address 🪪 OTHER REFERENCES: (blank in the original). CONTACT: Postel@ISI.EDU.

A Reverse Address Resolution Protocol (RARP) 🔁

STATUS: Elective

SPECIFICATION: RFC 903 (IN DPH)

This is a procedure for workstations to dynamically find their protocol address (e.g., their Internet Address) when they only know their hardware address (e.g., their attached physical network address) 🖥️✨ OTHER REFERENCES: (blank in the original). CONTACT: Mogul@SU-SCORE.STANFORD.EDU.

Multi-LAN Address Resolution Protocol (MARP) 🕸️

STATUS: Experimental

SPECIFICATION: RFC 925

This one is a discussion of the various problems and potential solutions of "transparent subnets" in a multi-LAN environment 🧠 Please discuss any plans for implementation or use of this protocol with the contact 🫶 OTHER REFERENCES: RFC 917, RFC 826. DEPENDENCIES: (blank in the original). CONTACT: Postel@ISI.EDU.

Broadcasting Internet Datagrams (IP-BROAD) 📢

STATUS: Recommended

SPECIFICATION: RFC 919

A proposed protocol of simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them 📣 "Recommended" here means "if you do broadcasting at all, then do it this way" 💅 Please discuss any plans for implementation or use of this protocol with the contact 🌸 OTHER REFERENCES: RFC 922. DEPENDENCIES: (blank in the original). CONTACT: Mogul@SU-SCORE.STANFORD.EDU.

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

STATUS: Recommended

SPECIFICATION: RFC 922

Same energy as the one above, but for subnets 🌷 It's a proposed protocol of simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. "Recommended" means "if you do broadcasting with subnets at all, then do it this way" 🫶 Please discuss any plans for implementation or use of this protocol with the contact 💖

OTHER REFERENCES: RFC 919. DEPENDENCIES: (blank in the original). CONTACT: Mogul@SU-SCORE.STANFORD.EDU.

Reliable Asynchronous Transfer Protocol (RATP) 🦋

STATUS: Experimental

SPECIFICATION: RFC 916

COMMENTS:

This one's a protocol that lets two programs talk reliably over a link, so whatever goes in one end comes out the other end intact and unaltered 🔒✨ It's built for a full duplex point-to-point connection, and it has some extra features made for the RS-232 links people are using right now 🔌💖

Please talk to the contact about any plans to implement or use this protocol 🎀

OTHER REFERENCES:
DEPENDENCIES: Transmission Control Protocol
CONTACT: Finn@ISI.EDU

Thinwire Protocol (THINWIRE)

Okay, this paper is about a Thinwire Protocol for hooking personal computers up to the Internet 💻🌸 It's mostly about the problems that show up when you connect personal computers to the Internet over low speed links, plus some ways people could fix them 🧚 Again, please chat with the contact before you implement or use it 🫶

STATUS:  Experimental
SPECIFICATION:  RFC 914
OTHER REFERENCES:
DEPENDENCIES:
CONTACT: Farber@UDEL.EDU

ISO and CCITT PROTOCOLS ✨

So the International Standards Organization (ISO) and the International Telegraph and Telephone Consultative Committee (CCITT) are working on a bunch of protocols that the Internet community might find interesting 🌈 A few of them got published as RFCs just for information, and this section is the list of those 📚

End System to Intermediate System Routing Exchange Protocol

This one is an International Standard made so open systems can talk to each other 🦋 It sits in the Network Layer, based on the layers from the Reference Model for Open Systems Interconnection (ISO 7498) and the structure in the Internal Organization of the Network Layer (DIS 8648). Its whole job is letting End Systems and Intermediate Systems swap configuration and routing info, so routing and relaying actually work 🔥

STATUS:
SPECIFICATION:  RFC 995
OTHER REFERENCES:  RFC 994
DEPENDENCIES:
CONTACT: ANSI

Connectionless Mode Network Service (ISO-8473)

Another Network Layer one from the ISO family, same whole vibe of open system interconnection 💅 This Protocol Standard can be used between network-entities in end systems, in Network Layer relay systems, or in both 🫶 It provides the Connectionless-mode Network Service from Addendum 1 to the Network Service Definition Covering Connectionless-mode Transmission (ISO 8348/AD1) 🍓

STATUS:
SPECIFICATION:  RFC 994
OTHER REFERENCES:  RFC 926
DEPENDENCIES:
CONTACT: ANSI

Internet-IP Addressing in ISO-IP

Okay, this one is giving problem-solving 🧠✨ It suggests a way to reuse the existing IP addressing, including the IP protocol field, for the ISO Connectionless Network Protocol (CLNP) 💖 It's a draft fix for one of the problems with using "ISO-grams" in the DoD Internet, and more related issues are supposed to show up in later RFCs 🌸 It's a proposed protocol for the Internet community, and they want feedback and ideas for making it better 🙈

Please talk to the contact about any plans to implement or use it 🎀

STATUS:
SPECIFICATION:  RFC 986
OTHER REFERENCES:
DEPENDENCIES:
CONTACT: RCallon@BBN.COM

Network Layer Addressing

This is an Addendum to the ISO 8348 Network Service Definition Standard, and it's serious about it 🧐 It defines the abstract syntax and semantics of the Network Address (Network Service Access Point Address) 💜 That's the address that shows up in the connection-mode Network Service primitives as the calling address, called address, and responding address parameters, and in the connectionless-mode primitives as the source address and destination address parameters 🔥

Please talk to the contact about any plans to implement or use this protocol 🫶

STATUS:
SPECIFICATION:  RFC 941
OTHER REFERENCES:
DEPENDENCIES:
CONTACT: ISO

Transport Protocol Specification (ISO-8073)

This is the current spec for the ISO Transport Protocol 🦋 The document is the text of ISO/TC97/SC16/N1576 as corrected by ISO/TC97/SC16/N1695, and it's the version being voted on in ISO as a Draft International Standard (DIS) right now 👑

STATUS:
SPECIFICATION:  RFC 905
OTHER REFERENCES:  RFC 892
DEPENDENCIES:
CONTACT: ISO

ISO Transport Services on Top of the TCP

Okay, this memo is a proposed protocol standard for the Internet community 💫 The CCITT and the ISO came up with session, presentation, and application recommendations that lots of countries and vendors adopted, so it's desirable to offer those higher level services straight over the Internet without wrecking the stuff that already works 🧚 That lets people build expertise with ISO and CCITT applications that weren't available on the Internet before 🌈 Hosts that choose to do ISO TSAP services on top of TCP are expected to adopt and implement this standard, and suggestions for improvement are welcome 🎀

Please talk to the contact about any plans to implement or use this protocol 🫶

STATUS:
SPECIFICATION:  RFC 1006
OTHER REFERENCES:  RFC 983
DEPENDENCIES:
CONTACT: DCass@NRTC.NORTHROP.COM

Mapping Between X.400 and RFC 822 (X.400)

The X.400 series was defined by CCITT to provide an Interpersonal Messaging Service (IPMS), and it uses a store and forward Message Transfer Service 📬 It's expected to be implemented very widely, so this document describes a set of mappings that let X.400 systems interwork with systems using the RFC 822 mail protocol or protocols derived from it 💌✨

Please talk to the contact about any plans to implement or use this protocol 🎀

STATUS:
SPECIFICATION:  RFC 987
OTHER REFERENCES:
DEPENDENCIES:
CONTACT: Kille@CS.UCL.AC.UK
📦 where this page comes from