RFC 801

NCP/TCP transition plan

📅 published November 1981, from ietf

Okay bestie, RFC 801 is the NCP/TCP Transition Plan 🎀 written by J. Postel at ISI in November 1981. It doesn't list a category, and it doesn't say it obsoletes or updates anything, so we're starting with a clean slate 🫶

Introduction ✨

Okay so ARPA-sponsored research on computer networks gave us the ARPANET 🌸 Installation started in September 1969, regular operational use was up and running by 1971, and it's been an operational service for at least 10 years. It stayed reliable for all sorts of computer research, but it was also a research subject in its own right, and it evolved a lot along the way 💖

In the last several years ARPA funded more network research, mostly networks built on different underlying communication techniques, especially digital packet broadcast radio and satellite networks. The ARPA community also did a lot of work on local networks 🦋

From the very start of that research, it was obvious that the base host-to-host protocol used on the ARPANET wasn't good enough for these other networks. So in 1973 work began on a host-to-host protocol that would work across all of them, and the result of that long effort is the Internet Protocol (IP) and the Transmission Control Protocol (TCP) ✨

These protocols let every host in the interconnected set of networks share one common interprocess communication environment 🧚 The whole collection of interconnected networks is called the ARPA Internet, sometimes nicknamed the "Catenet" 🌈

The Department of Defense recently adopted the internet concept, and IP and TCP specifically, as DoD-wide standards for all DoD packet networks. The transition to this architecture will happen over the next several years, and all new DoD packet networks will use these protocols exclusively 👑

The time has come to put these protocols to work on the operational ARPANET and to extend the logical connectivity of ARPANET hosts so they can reach hosts on other networks in the ARPA Internet 💅

As with any new system, some parts won't be as robust and efficient as we'd like (same as the early ARPANET). But with your help these problems can be solved, and we can move into an environment with much broader communication services 🫶

Discussion 💅

IP/TCP is already implemented on several hosts, and some services are already in use there. It is urgent that the implementation of of IP/TCP begins on all other ARPANET hosts as soon as possible, and no later than 1 January 1982 in any case 🔥 Any new host connected to the ARPANET should only implement IP/TCP and TCP-based services. Several important implementation issues are covered in the last section of this memo 📝

Here's the tricky part: not every host can switch to TCP at the same moment, and some will only do IP/TCP. So for now we need temporary communication between NCP-only hosts and TCP-only hosts 🙈 The plan is to designate certain hosts that implement both NCP and IP/TCP as relay hosts. These relay hosts will support Telnet, FTP, and Mail services on both NCP and TCP. The relay services start in November 1981 and will be fully in place by January 1982 ⭐

At first there will be lots of NCP-only hosts and a few TCP-only hosts, so the relay hosts won't be super busy. As time goes on and the conversion moves along, there will be more TCP-capable hosts and fewer NCP-only ones, plus brand new TCP-only hosts. Presumably most hosts that are NCP-only right now will add IP/TCP alongside their NCP and become "dual protocol" hosts 🌸 So yes, the load on the relay hosts will go up, but it won't be a big chunk of the total traffic 💜

The next section goes deeper into this plan, the section after that lists some milestones for the transition, and the last section lists the key documents for the new protocols and services. The appendices walk through scenarios for using the relay services 🧚

The General Plan 🎀

The goal is a complete switch from NCP to IP/TCP by 1 January 1983 💖

It is the job of each host organization to implement IP/TCP for its own hosts, and that work must begin by 1 January 1982 ✨

IP

This is specified in RFCs 791 and 792. Implementations already exist for several machines and operating systems. (See Appendix D.) 🦋

TCP

This is specified in RFC793. Implementations also exist for several machines and operating systems. (See Appendix D.) 🌈

It is not enough to implement IP/TCP, though. The principal services must be available on that IP/TCP base too. The principal services are Telnet, File Transfer, and Mail 👑

It is the job of each host organization to implement the principal services for its own hosts, and these implementation tasks must begin by 1 January 1982 💅

Telnet

This is specified in RFC 764. It's very similar to the Telnet used with NCP. The main differences are that the ICP gets eliminated, and the NCP Interrupt gets replaced with the TCP Urgent 🫶

FTP

This is specified in RFC 765. It's very similar to the FTP used with NCP. The differences are that, on top of the Telnet changes, the data channel is limited to 8-bit bytes, so the FTP features for other transmission byte sizes get eliminated 🔥

Mail

This is specified in RFC 788. Mail is completely separated from FTP and handled by a distinct server. The procedure is similar in concept to the old FTP/NCP mail procedure, but it's very different in detail. It also supports additional functions, especially mail relaying and multi-recipient delivery 💌

Beyond providing the principal services in the new environment, there must be a way to interwork between the new environment and the old one from now until January 1983 🙈

For Telnet, there will be one or more relay hosts. A Telnet relay host implements both the NCP and TCP environments, and both user and server Telnet in both environments. Users who need Telnet service between hosts in different environments first connect to a Telnet relay host, and then connect to the destination host. (See Appendix A.) 🦋

For FTP, there will be one or more relay hosts. An FTP relay host implements both the NCP and TCP environments, both user and server Telnet, and both user and server FTP in both environments. Users who need FTP service between hosts in different environments first connect via Telnet to an FTP relay host, then use FTP to move the file from the file donor host to the FTP relay host, and finally use FTP to move the file from the FTP relay host to the file acceptor host. (See Appendix B.) 🧚

For Mail, hosts will implement the new Simple Mail Transfer Protocol (SMTP) described in RFC 788. SMTP provides for relaying mail among several protocol environments. For TCP-only hosts, using SMTP will be sufficient. For NCP-only hosts that haven't been modified to use SMTP, the special syntax user.host@forwarder may be used to relay mail through one or more special forwarding hosts. Several mail relay hosts will relay mail via SMTP procedures between the NCP and TCP environments, and at least one special forwarding host will be provided. (See Appendix C.) 💌

Milestones 🦋

Here's the timeline at a glance:

   First Internet Service                                        already
   First TCP-only Host                                           already
   Telnet and FTP Relay Service                                  already
   Ad Hoc Mail Relay Service                                     already
   Last NCP Conversion Begins                                     Jan 82
   Mail Relay Service                                             Jan 82
   Normal Internet Service                                        Jul 82
   Last NCP Conversion Completed                                  Nov 82
   Full Internet Service                                          Jan 83
  • First Internet Service (already): A few hosts are TCP-capable and use TCP-based services. 🌸
  • First TCP-only Host (already): The first TCP-only host begins using TCP-based services. 🌷
  • Telnet and FTP Relay Service (already): Special relay accounts are available to qualified users who have a demonstrated need for the Telnet or FTP relay service. 🔑
  • Ad Hoc Mail Relay Service (already): An ad hoc mail relay service using the prototype MTP (RFC 780) is implemented, and mail is relayed from TCP-only hosts to NCP-only hosts, but not vice versa. This service will be replaced by the SMTP service. 📬
  • Last NCP Conversion Begins (Jan 82): The last NCP-only host begins conversion to TCP. 🚀
  • Mail Relay Service (Jan 82): The SMTP (RFC 788) mail service begins to operate. At least one mail relay host is operational, and at least one special forwarder is operational to provide NCP-only host to TCP-only host mail connectivity. 💜
  • Normal Internet Service (Jul 82): Most hosts are TCP-capable and use TCP-based services. 🌈
  • Last NCP Conversion Completed (Nov 82): The last NCP-only host completes conversion to TCP. 🎉
  • Full Internet Service (Jan 83): All hosts are TCP-capable and use TCP-based services. NCP is removed from service, relay services end, and all services are TCP-based. 👑

Documents 🌸

These RFCs document the protocols to be implemented in the new IP/TCP environment:

      IP                                                         RFC 791
      ICMP                                                       RFC 792
      TCP                                                        RFC 793
      Telnet                                                     RFC 764
      FTP                                                        RFC 765
      SMTP                                                       RFC 788
      Name Server                                                IEN 116
      Assigned Numbers                                           RFC 790

These and associated documents are going to be published in a notebook, and other information useful to implementers is going to be gathered. The documents will come out on this schedule:

      Internet Protocol Handbook                                  Jan 82
      Implementers Hints                                          Jan 82
      SDC IP/TCP Specifications                                   Jan 82
      Expanded Host Table                                         Jan 82

Implementation Issues 👑

Okay so this part is where things get spicy 🌶️ The implementation side, the relay drama, and two appendices with diagrams. Let's go 💅

Name Tables

Most hosts keep a table that turns character string names into numeric addresses 🗺️ Moving to this transition changes that table in two ways: (1) there will be WAY more names, and (2) you may need to note what protocols each host can actually speak (SMTP/TCP, SMTP/NCP, FTP/NCP, etc.) 🧚

Some hosts keep this table in the operating system's address space so they can translate names fast with a system call. ngl that may not be practical in the future 🙈

Apps could do cooler stuff if they could easily tell whether a remote host supports a particular protocol ✨ So it might be useful to extend host name tables to note which protocols are supported.

If this name table gets used to double-check the spelling of host names in things like mail composition programs, it might need to include names of hosts that are only reachable through relays 📬

It might also be advantageous to ditch the host name table entirely and use a Name Server instead, or to keep a relatively small table as a cache of recently used host names 🦋

A format, distribution, and update procedure for the expanded host table will be published soon 👑

Mail Programs

It may be possible to move to the new SMTP mail procedures by only changing the mailer-daemon and implementing the SMTP-server 💌 But some hosts might need small changes to some or all of the mail composition programs too 🎀

Users might need a way to pick relay hosts for the messages they send 🌸 That could mean a new command or address syntax that isn't allowed right now 💅

IP/TCP

Continuing to use IP and TCP will teach everyone a lot more about their performance characteristics and parameters 📈 Implementers should expect to make small tweaks from time to time to improve performance 🫶

Shortcuts

There are some very tempting shortcuts in implementing IP and TCP 👀 Absolutely do not be tempted! Others were, and they got caught 💀 Here are the deficiencies from past implementations that must be fixed and are not allowed in the future:

  • IP problems:
    • Some IP implementations did not verify the IP header checksum.
    • Some IP implementations did not implement fragment reassembly.
    • Some IP implementations used static and limited routing information, and did not make use of the ICMP redirect message information.
    • Some IP implementations did not process options.
    • Some IP implementations did not report errors they detected in a useful way.
  • TCP problems:
    • Some TCP implementations did not verify the TCP checksum.
    • Some TCP implementations did not reorder segments.
    • Some TCP implementations did not protect against silly window syndrome.
    • Some TCP implementations did not report errors they detected in a useful way.
    • Some TCP implementations did not process options.
  • Host problems:
    • Some hosts had limited or static name tables.

Relay Service

Relay services have officially started 🎉 There are two concerns about them: (1) reliability, and (2) load 😬

Reliability is a worry because relaying puts another host in the chain, and every host in that chain has to work at the same time to get the job done 🔗 It's desirable to provide alternate relay hosts if possible. This seems pretty doable for mail, but it might be a bit sticky for Telnet and FTP because of the need for access control on the login accounts 🔐

Load is a potential problem too, since an overloaded relay host will leave users unhappy 😤 That's another reason to have a bunch of relay hosts, so the load gets divided and the service is better 💖

A Digression on the Numbers

How bad could this relay load get? 🤔 Basically, any "dual protocol" host takes itself out of the game (it doesn't need relay services) ✨ Let's postulate that the number of NCP-only hosts times the number of TCP-only hosts is a measure of the relay load.

Total Hosts  Dual Hosts  NCP Hosts  TCP Hosts  "Load"    Date
    200          20        178          2        356     Jan-82
    210          40        158         12       1896     Mar-82
    220          60        135         25       3375     May-82
    225          95         90         40       3600     Jul-82
    230         100         85         45       3825     Sep-82
    240         125         55         60       3300     Nov-82
    245         155         20         70       1400     Dec-82
    250         170          0         80          0  31-Dec-82
    250           0          0        250          0   1-Jan-83

This assumes that most NCP-only hosts (but not all) will become dual protocol hosts, and that 50 new hosts will show up over the course of the year, all of them TCP-only 📊

If the initial 200 hosts immediately split into 100 NCP-only and 100 TCP-only, then the "load" would be 10,000, so the fact that most of the hosts will be dual protocol hosts helps considerably 🙌

This load measure (NCP hosts times TCP hosts) may overstate the load significantly 🫠

Please note that this digression is rather speculative! 🔮

Gateways

There must be continuing development of the internet gateways 🌈 The following items need attention:

  • Congestion Control via ICMP
  • Gateways use connected networks intelligently
  • Gateways have adequate buffers
  • Gateways have fault isolation instrumentation

Note that the work in progress on the existing gateways will provide the capability to deal with many of these issues early in 1982 🗓️ Work is also underway to provide improved capability gateways based on new hardware late in 1982 🚀

APPENDIX A. Telnet Relay Scenario 🎀

Say a user at a TCP-only host wants to use the interactive services of an NCP-only service host 💻

  1. Use the local user Telnet program to connect via Telnet/TCP to the RELAY host.
  2. Login on the RELAY host using a special account for the relay service.
  3. Use the user Telnet on the RELAY host to connect via Telnet/NCP to the service host. Since both Telnet/TCP and Telnet/NCP are available on the RELAY host, the user must select which is to be used in this step.
  4. Login on the service host using the regular account.
   +---------+          +---------+          +---------+
   |         |  Telnet  |         |  Telnet  |         |
   | Local   |<-------->|  Relay  |<-------->| Service |
   |  Host   |   TCP    |   Host  |   NCP    |   Host  |
   +---------+          +---------+          +---------+

Now flip it 🔄 Say a user at an NCP-only host wants to use the interactive services of a TCP-only service host 🦋

  1. Use the local user Telnet program to connect via Telnet/NCP to the RELAY host.
  2. Login on the RELAY host using a special account for the relay service.
  3. Use the user Telnet on the RELAY host to connect via Telnet/NCP to the service host. Since both Telnet/TCP and Telnet/NCP are available on the RELAY host, the user must select which is to be used in this step.
  4. Login on the service host using the regular account.
   +---------+          +---------+          +---------+
   |         |  Telnet  |         |  Telnet  |         |
   | Local   |<-------->|  Relay  |<-------->| Service |
   |  Host   |   NCP    |   Host  |   TCP    |   Host  |
   +---------+          +---------+          +---------+

APPENDIX B. FTP Relay Scenario 📂

Say a user at a TCP-only host wants to copy a file from an NCP-only donor host 🫶

Phase 1:

  1. Use the local user Telnet program to connect via Telnet/TCP to the RELAY host.
  2. Login on the RELAY host using a special account for the relay service.
  3. Use the user FTP on the RELAY host to connect via FTP/NCP to the donor host.
  4. FTP login on the donor host using the regular account.
  5. Copy the file from the donor host to the RELAY host.
  6. End the FTP session, and disconnect from the donor host.
  7. Logout of the RELAY host, close the Telnet/TCP connection, and quit Telnet on the local host.
      +---------+          +---------+          +---------+
      |         |  Telnet  |         |   FTP    |         |
      | Local   |<-------->|  Relay  |<-------->| Service |
      |  Host   |   TCP    |   Host  |   NCP    |   Host  |
      +---------+          +---------+          +---------+

Phase 2:

  1. Use the local user FTP to connect via FTP/TCP to the RELAY host.
  2. FTP login on the RELAY host using the special account for the relay service.
  3. Copy the file from the RELAY host to the local host, and delete the file from the RELAY host.
  4. End the FTP session, and disconnect from the RELAY host.
      +---------+          +---------+
      |         |   FTP    |         |
      | Local   |<-------->|  Relay  |
      |  Host   |   TCP    |   Host  |
      +---------+          +---------+

Note that the relay host may have a policy of deleting files more than a few hours or days old 🗑️⏰

APPENDIX C. Mail Relay Scenario 💌

Okay so, picture this 🧚 Someone on a TCP-only host wants to send a message to someone on an NCP-only host that has SMTP implemented. Here's how the mail gets there, step by step:

  1. Use the local mail composition program to write the message. Address it to the recipient at their host, then tell the composition program to queue it. 💅
  2. The background mailer-daemon finds the queued message. It checks the destination host name in a table to look up the internet address, but instead it finds that the destination host is an NCP-only host. So the mailer-daemon checks a list of mail RELAY hosts, picks one, and sends the message to that relay using the SMTP procedure. 🦋
  3. The mail RELAY host accepts the message for relaying. It checks the destination host name and discovers that the destination is an NCP-only host which has SMTP implemented. The relay then sends the message on to the destination using the SMTP/NCP procedure. ✨
         +---------+          +---------+          +---------+
         |         |   SMTP   |         |   SMTP   |         |
         | Source  |<-------->|  Relay  |<-------->|  Dest.  |
         |  Host   |   TCP    |   Host  |   NCP    |   Host  |
         +---------+          +---------+          +---------+

Now the next vibe 🌸 Same idea, except this time the user is on a TCP-only host and wants to send a message to someone on an NCP-only non-SMTP host.

  1. Use the local mail composition program to write the message. Address it to the recipient at their host, then tell the composition program to queue it. 💖
  2. The background mailer-daemon finds the queued message. It checks the destination host name in a table to look up the internet address, but instead it finds that the destination host is an NCP-only host. So the mailer-daemon checks a list of mail RELAY hosts, picks one, and sends the message to that relay using the SMTP procedure. 🌈
  3. The mail RELAY host accepts the message for relaying. It checks the destination host name and discovers that the destination is an NCP-only non-SMTP host. The relay then sends the message on to the destination using the old FTP/NCP mail procedure. 🫶
         +---------+          +---------+          +---------+
         |         |   SMTP   |         |   FTP    |         |
         | Source  |<-------->|  Relay  |<-------->|  Dest.  |
         |  Host   |   TCP    |   Host  |   NCP    |   Host  |
         +---------+          +---------+          +---------+

And now the plot twist 😭 Someone on an NCP-only non-SMTP host wants to send a message to someone on a TCP-only host. In this example the destination user is Smith and the host is ABC-X, so let's follow the drama:

  1. Use the local mail composition program to write the message. Address it to Smith.ABC-X@FORWARDER, then tell the composition program to queue it. 🎀
  2. The background mailer-daemon finds my queued message 💅 and sends it to the host FORWARDER using the old FTP/NCP mail procedure. 🍓
  3. The special forwarder host converts the "user name" supplied by the FTP/NCP mail procedure (in the MAIL or MLFL command) into Smith@ABC-X (in the SMTP RCTP command). It then queues the message to be processed by the SMTP mailer-daemon program on this same host. No conversion of the mailbox addresses is made in the message header or body. 👑
Quick aside: the original spells the command as RCTP, bestie, so I've kept it exactly like that 🙈
  1. The SMTP mailer-daemon program on the forwarder host finds this queued message and checks the destination host name in a table to look up the internet address. It finds the destination address and sends the mail using the SMTP procedure. 🔥
         +---------+          +---------+          +---------+
         |         |   FTP    |         |   SMTP   |         |
         | Source  |<-------->|Forwarder|<-------->|  Dest.  |
         |  Host   |   NCP    |   Host  |   TCP    |   Host  |
         +---------+          +---------+          +---------+

APPENDIX D. IP/TCP Implementation Status ✨

okay bestie, heads up: this info gets dated FAST 💀 so the most current status lives in <INTERNET-NOTEBOOK>TCP-IP-STATUS.TXT on ISIF 📝 go check there too!

BBN C70 UNIX

Date: 18 Nov 1981 💌 From: Rob Gurwitz <gurwitz at BBN-RSM>

okay so the C/70 is a BBN-designed system with a native instruction set built to run the C language 🔥. It supports UNIX Version 7 and gives user processes a 20-bit address space 💅. The TCP/IP for it was ported from BBN's VAX TCP/IP, so it shares all of those features 🫶.

this version is running experimentally at BBN and is still under development 🧪. they're working on performance tuning so it plays nicer with the C/70's memory management system ✨.

BBN GATEWAYS

Date: 19 Nov 1981 💌 From: Alan Sheltzer <sheltzer at BBN-UNIX>

BBN is leveling up the gateways it controls 🚀. a brand-new gateway implementation written in macro-11 (instead of BCPL) is being developed. the macro-11 gateway will give users internet service that's functionally equivalent to the current BCPL gateways, with some performance improvements on top 💖.

here are the gateways on the list 🌸:

  • ARPANET/SATNET gateway at BBN (10.3.0.40)
  • ARPANET/SATNET gateway at NDRE (10.3.0.41)
  • Comsat DCN Net/SATNET gateway at COMSAT (4.0.0.39)
  • SATNET/UCL Net/RSRE Net gateway at UCL (4.0.0.60)
  • PR Net/RCC Net gateway at BBN (3.0.0.62)
  • PR Net/ARPANET gateways at SRI (10.3.0.51, 10.1.0.51)
  • PR Net/ARPANET gateway at Ft. Bragg (10.0.0.38)

BBN H316 and C/30 TAC

Date: 18 November 1981 💌 From: Bob Hinden <Hinden@BBN-UNIX>

the Terminal Access Controller (TAC) is a user Telnet host that supports TCP/IP and NCP host to host protocols 🖥️. it runs on 32K H-316 and 64K C/30 computers 💻, supports up to 63 terminal ports 🔌, and connects to a network via an 1822 host interface ✨.

for more on the TAC's design, check out IEN-166 📚.

BBN HP-3000

Date: 14 May 1981 💌 From: Jack Sax <sax@BBN-UNIX>

the HP3000 TCP code is in its final testing stages 🧪. it runs under the MPE IV operating system as a special high priority process. it's not part of the OS kernel, because MPE IV has no kernel 🙈. the protocol process includes TCP, IP, 1822, and a new protocol called HDH, which lets 1822 messages go over HDLC links 🔗. it's about 8k bytes of code and at least 20k bytes of data, depending on how many buffers get allocated 📦.

besides TCP, the HP3000 has user and server TELNET as well as user FTP 🎀. a server FTP may be added later 🌈.

a complete description of the implementation software is in IEN-167 💜.

BBN PDP-11 UNIX

Date: 14 May 1981 💌 From: Jack Haverty <haverty@BBN-UNIX>

this TCP was written in C 💅. it runs as a user process in version 6 UNIX, with modifications BBN added for network access 🔧. it supports user and server Telnet.

this implementation was done under contract to DCEC and is currently installed on several PDP-11/70s and PDP-11/44s 🍓. contact Ed Cain at DCEC <cain@EDN-UNIX> for details of further development 📩.

BBN TENEX & TOPS20

Date: 23 Nov 1981 💌 From: Charles Lynn <CLynn@BBNA>

TCP4 and IP4 are available for TENEX running on a Digital KA10 processor with a BBN pager 🌸. they're also available as part of TOPS20 Release 3A and Release 4 for the Digital KL10 and KL20 processors 💖.

above the IP layer, there are two Internet protocols inside the monitor itself (TCP4 and GGP). on top of that, up to eight (actually a monitor assembly parameter) protocols may be implemented by user-mode programs via the "Internet User Queue" interface 👑. GGP, or Gateway-Gateway Protocol, is used to receive advice from Internet Gateways in order to control message flow 🚦. the GGP code is being changed, and the ICMP protocol is being added 🔄.

TCP4 is the other monitor-supplied protocol, and it has two types of connections: normal data connections and "TCP Virtual Terminal" (TVT) connections 🧚. the former are used for bulk data transfers, while the latter provide terminal access for remote terminals 💜.

note that TVTs use the standard ("New") TELNET protocol 🫶. it's identical to the one used on the ARPANET with NCP, and it's largely implemented by the same code 😭.

performance improvements, support for the new address formats, and User and Server FTP processes above the TCP layer are under development 🛠️.

BBN VAX UNIX

Date: 18 Nov 1981 💌 From: Rob Gurwitz <gurwitz at BBN-RSM>

the VAX TCP/IP implementation is written in C for Berkeley 4.1BSD UNIX and runs in the UNIX kernel 👑. it's been run on VAX 11/780s and 750s at several sites and is due to be generally available in early 1982 🎉.

it conforms to the TCP and IP specifications (RFC 791, 793) 📜. it supports the new extended internet address formats, plus both GGP and ICMP ✨. it also supports multiple network access protocols and device drivers. aside from ARPANET 1822 and the ACC LH/DH-11 driver, experimental drivers have also been developed for ETHERNET 🌈. there are user interfaces for accessing the IP and local network access layers independent of the TCP 🦋.

higher level protocol services include user and server TELNET, MTP, and FTP, implemented as user level programs 💅. there are also tools for monitoring and recording network traffic for debugging purposes 🔍.

continuing development includes performance enhancements 🔥. the implementation is described in IEN-168 📚.

COMSAT

Date: 30 Apr 1980 💌 From: Dave Mills <Mills@ISIE>

the TCP/IP implementation here runs on an LSI-11 with a homegrown operating system that's compatible in most respects with RT-11 🧸. besides the TCP/IP levels, the system includes many of the common high-level protocols used in the ARPANET community, like TELNET, FTP, and XNET 🌸.

DCEC PDP-11 UNIX

Date: 23 Nov 1981 💌 From: Ed Cain <cain@EDN-UNIX>

this TCP/IP/ICMP implementation runs as a user process in version 6 UNIX, with modifications obtained from BBN for network access 🔧. IP reassembles fragments into datagrams but has no separate IP user interface 🧩. TCP supports user and server Telnet, echo, discard, internet mail, and a file transfer service 📬. ICMP generates replies to Echo Requests and sends Source-Quench when reassembly buffers are full 🚨.

  • Hardware - PDP-11/70 and PDP-11/45 running UNIX version 6, with BBN IPC additions
  • Software - written in C, requiring 25K instruction space, 20K data space
  • Supports 10 connections

DTI VAX

Date: 15 May 1981 💌 From: Gary Grossman <grg@DTI)>

Digital Technology Incorporated (DTI) IP/TCP for VAX/VMS 💼

the following describes the IP and TCP implementation that DTI plans to begin marketing in 4th Quarter 1981 as part of its VAX/VMS network software package 🎀.

  • Hardware: VAX-11/780 or /750
  • Operating System: DEC standard VAX/VMS Release 2.0 and above
  • Implementation Language: Mostly C, with some MACRO
  • Connections supported: Maximum of 64

user level protocols available: TELNET, FTP, and MTP will be available. (the NFE version uses AUTODIN II protocols 🌈.)

MIT MULTICS

Date: 13 May 1981 💌 From: Dave Clark <Clark@MIT-Multics>

Multics TCP/IP is implemented in PL/1 for the HISI 68/80 🧠. it's been in experimental operation for about 18 months, and it can be distributed informally as soon as certain modifications to the system are released by Honeywell 🎁. the TCP and IP package are currently being tuned for performance, especially high throughput data transfer ⚡.

higher level services include user and server telnet, plus a full function MTP mail forwarding package 📮.

the TCP and IP contain good logging and debugging facilities, which have proved useful in checking out other implementations 🔍. please contact us for further information 💌.

SRI LSI-11

Date: 15 May 1981 💌 From: Jim Mathis <mathis.tscb@Sri-Unix>

the IP/TCP implementation for the Packet Radio terminal interface unit is intended to run on an LSI-11 under the MOS real-time operating system 📡. the TCP is written in MACRO-11 assembler language. the IP is currently written in assembler language, but it's being converted into C. there are no plans to convert the TCP from assembler into C 🙃.

the TCP implements the full specification 💯. it appears to be functionally compatible with all other major implementations. in particular, it's used on a daily basis to provide communications between users on the Ft. Bragg PRNET and ISID on the ARPANET 🫡.

the IP implementation is reasonably complete, providing fragmentation and reassembly, routing to the first gateway, and a complete host-side GGP process 🧩.

a measurement collection mechanism is currently under development to collect TCP and IP statistics and deliver them to a measurement host for data reduction 📊.

UCLA IBM

Date: 13 May 1981 💌 From: Bob Braden <Braden@ISIA>

  • Hardware: IBM 360 or 370, with a "Santa Barbara" interface to the IMP 🖥️
  • Operating System: OS/MVS with ACF/VTAM. An OS/MVT version is also available. The UCLA NCP operates as a user job, with its own internal multiprogramming and resource management mechanisms.
  • Implementation Language: BAL (IBM's macro assembly language)
  • User-Level Protocols Available: User and Server Telnet
📦 where this page comes from