ARPANET

This document reproduces the Host/Host Protocol developed by the ARPA Network Working Group during 1969, 1970, and 1971. It describes a protocol used to manage communication between processes residing on independent Hosts. It addresses issues of multiplexing multiple streams of communication (including addressing, flow control, connection establishment/disestablishment, and other signaling) over a single hardware interface. It was the official protocol of the ARPA Network from January 1972 until the switch to TCP/IP in January 1983. It is offered as an RFC at this late date to help complete the historical record available through the RFC series. This document is not an Internet Standards Track specification; it is published for the historical record.

The development of new technology is driven by scientific research. The Internet, with its roots in the ARPANET and NSFNet, is no exception. Many of the fundamental, long-term improvements to the architecture, security, end-to-end protocols and management of the Internet originate in the related academic research communities. Even shorter-term, more commercially driven extensions are oftentimes derived from academic research. When interoperability is required, the IETF standardizes such new technology. Timely and relevant standardization benefits from continuous input and review from the academic research community.

For an individual researcher, it can however be quite puzzling how to begin to most effectively participate in the IETF and arguably to a much lesser degree, the IRTF. The interactions in the IETF are much different than those in academic conferences, and effective participation follows different rules. The goal of this document is to highlight such differences and provide a rough guideline that will hopefully enable researchers new to the IETF to become successful contributors more quickly. This document is not an Internet Standards Track specification; it is published for informational purposes.

This memo changes the status of STD 39, BBN Report 1822, "Specification of the Interconnection of a Host and an IMP", from Standard to Historic. This memo provides information for the Internet community.

This RFC is a proposed specification for the encoding of Class A IP addresses for use on ARPANET-style networks such as the Milnet and Arpanet, and for enhancements to the ARPANET AHIP Host Access Protocol (AHIP; formerly known as 1822). These enhancements increase the size of the PSN field, allow ARPANET hosts to use logical names to address each other, allow for the communication of type-of-service information from the host to the PSN and enable the PSN to provide congestion feedback to the host on a connection basis.

This memo is an updated version of BBN Report 5775, "End-to-End Functional Specification and describes important changes to the functionality of the interface between a Host and the PSN, and should be carefully reviewed by anyone involved in supporting a host on either the ARPANET or MILNET". The new End-to-End protocol (EE) is being developed in order to correct a number of deficiencies in the old EE, to improve its performance and overall throughput, and to better equip the Packet Switch Node (PSN, also known as the IMP) to support its current and anticipated host population.

This RFC proposes a new set of RFCs on how the networking code is integrated with various operating systems. It appears that this topic has not received enough exposure in the literature. Comments and suggestions are encouraged.

The broad outline of the Host-Front End Protocol introduced here and described in RFC-929 is the result of the deliberations of a number of experienced H-FP designers, who sat as a committee of the DoD Protocol Standards Technical Panel. It is the intent of the designers that the protocol be subjected to multiple test implementations and probable iteration before being agreed upon as any sort of "standard". Therefore, the first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

The Host-Front End Protocol introduced in RFC-928 is described in detail in this memo. The first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. The 1822L procedure allows ARPANET hosts to use logical identifiers as well as 1822 physical interface identifiers to address each other.

This RFC specifies the ARPANET Short Blocking Feature, which will allow ARPANET hosts to optionally shorten the IMP's host blocking timer. This Feature is a replacement of the ARPANET non-blocking host interface, which was never implemented, and will be available to hosts using either the 1822 or 1822L Host Access Protocol. This RFC is also being presented as a solicitation of comments on the Short Blocking Feature, especially from host network software implementers and maintainers.

The purpose of this RFC is to focus discussion on a particular Internet problem: a backup path for software maintenance of the European sector of the Internet, for use when SATNET is partitioned. We propose a mechanism, based upon the Source Routing option of IP, to reach European Internet sites via the VAN Gateway and UCL. This proposal is not intended as a standard at this time.

This RFC proposes a distributed name service for DARPA Internet. Its purpose is to focus discussion on the subject. It is hoped that a general consensus will emerge leading eventually to the adoption of standards.

This RFC is a status report on the Internet Gateway developed by BBN. It describes the Internet Gateway as of September 1982. This memo presents detailed descriptions of message formats and gateway procedures, however, this is not an implementation specification, and such details are subject to change.

This RFC is primarily intended as a perspective on the ARM and points out some of the differences between the ARM and the ISORM which were expressed by members in NWG general meetings, NWG protocol design committee meetings, the ARPA Internet Working Group, and private conversations over the intervening years. Originally published as M82-47 by the MITRE Corporation, Bedford, Massachusetts.

This memo takes issue with the claim that international standards in computer protocols presently provide a basis for low cost vendor supported protocol implementations. Originally published as M82-49 by the MITRE Corporation, Bedford, Massachusetts.

This RFC is a discussion about the role of gateways in an internetwork, especially the problems of translating or mapping protocols between different protocol suites. The discussion notes possible functionality mis-matches, undesirable routing "singularity points", flow control issues, and high cost of translating gateways. Originally published as M82-51 by the MITRE Corporation, Bedford, Massachusetts.

This RFC is distributed to inform the ARPA Internet community of the activities of the IFIP technical committee on Data Communications, and to encourage participation in those activities.

This RFC gives suggestions and guidance for the design of the tables and algorithms necessary to keep track of these various sorts of identifiers inside a host implementation of TCP/IP.

This RFC will discuss some of the commonly encountered reasons why protocol implementations seem to run slowly.

Observations on current international standards recommendations from IFIP working group 6.1; see also RFCs 692, 690, 687.

Comments on suggestions in RFC 687; see also RFCs 692 and 696.

A proposed solution to the problem of combined length of IMP and Host leaders; see also RFCs 696, 690 and 687.

References to documents and contacts concerning the various protocols used in the ARPANET, as well as recent developments; updates RFC 661.

Extends message field definition beyond RFC 561 attempts to establish syntactic and semantic standards for ARPANET; see also RFCs 733 and 822.

Issues in designing distributed computing systems. Shortcomings of RFC 674; see also RFCs 542 and 354.

The contribution of ARPANET communication to response time.

Approved scheme to connect host ports to the network.

Experience with implementation in RSEXEC context.

Applicability of TIP/TENEX protocols beyond TIP accounting.

Host level protocol used in the NSW--a slightly constrained version of ARPANET Host-to-Host protocol, affecting allocation, RFNM wait, and retransmission; see also RFC 684.

For transmission of documents across different environments.

Approaches to Front-End protocol processing using available hardware and software.

An old version; see RFC 694.

Experimenting with host output buffers to improve throughput.

Proposed extension of host-host protocol; see also RFCs 534, 516, 512, 492 and 467.

Discusses and proposes a common command language.

Decoupling of message number sequences of hosts; host-host access control; message number window; messages outside normal mechanism; see also BBN 1822.

To be used in an implementation of a PDP-11 network bootstrap device and a cross-network debugger.

Obtaining/maintaining connections; recovery from lost connections; connection-state changes.

Providing a mechanism for specifying all attributes of a collection of bits; see also RFC 615.

This paper presents some theoretical and practical motivations for the redesign of the ARPANET communication protocols. Issues concerning multipacket messages, Host retransmission, duplicate detection, sequencing, and acknowledgment are discussed. Simplifications to the IMP/IMP protocol are proposed on the assumption that new Host level protocols are adopted. Familiarity with the current protocol designs is probably necessary since many of the arguments refer to details in the present protocol design.

Corrects RFC 633.

Actual measurements of round-trip times.

See also RFCs 620 and 609.

Modification of previous policy.

Expansion of Host-Going-Down and addition of Dead-Host-Status Message.

See also RFCs 621 and 620.

Susceptibility of ARPANET to security violations.

Questions about the ARPANET topology described in RFC 597.

Preliminary results of the language design; a model for data languagea semantics; future considerations.

Discusses some unusual interface issues for the Plato terminal.