| |
| RFC 900 | Assigned Numbers |
| |
|
|
This RFC specifies parameter values use in the Internet family of protocols, such as network numbers, well known ports, protocol types, and version numbers. This memo is an official status report on the protocol parameters used in the Internet protocol system. See RFC-990 and 997. |
|
| |
| RFC 901 | Official ARPA-Internet protocols |
| |
|
|
This RFC identifies the documents specifying the official protocols used in the ARPA-Internet. Annotations identify any revisions or changes planned. This memo is an official status report on the protocols used in the DARPA research community. See RFC-991. |
|
| |
| RFC 902 | ARPA Internet Protocol policy |
| |
| Authors: | J.K. Reynolds, J. Postel. |
| Date: | July 1984 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0902 |
|
The purpose of this memo is to explain how protocol standards are adopted for the ARPA-Internet and the DARPA research community. There are three important aspects to be discussed: the process, the authority, and the complex relationship between the DARPA community and the DDN community. This memo is a policy statement on how protocols become official standards for the ARPA-Internet and the DARPA research community. This is an official policy statement of the ICCB and the DARPA. |
|
| |
| RFC 903 | A Reverse Address Resolution Protocol |
| |
| Authors: | R. Finlayson, T. Mann, J.C. Mogul, M. Theimer. |
| Date: | June 1984 |
| Formats: | txt json html |
| Also: | STD 0038 |
| Status: | INTERNET STANDARD |
| DOI: | 10.17487/RFC 0903 |
|
This RFC suggests a method for workstations to dynamically find their protocol address (e.g., their Internet Address), when they know only their hardware address (e.g., their attached physical network address). This RFC specifies a proposed protocol for the ARPA Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 904 | Exterior Gateway Protocol formal specification |
| |
|
|
RFC-904 is the specification of the Exterior Gateway Protocol (EGP). This memo updates portions of RFC-888 and RFC-827. This RFC specifies an official protocol of the DARPA community for use between gateways of different autonomous systems in the ARPA-Internet. |
|
| |
| RFC 905 | ISO Transport Protocol specification ISO DP 8073 |
| |
|
|
This is the current specification of the ISO Transport Protocol. This document is the text of ISO/TC97/SC16/N1576 as corrected by ISO/TC97/SC16/N1695. This is the specification currently being voted on in ISO as a Draft International Standard (DIS). This document is distributed as an RFC for your information only, it does not specify a standard for the ARPA-Internet or DARPA research community. Our thanks to Alex McKenzie of BBN for making this online version available. Please note the size of this document, the file contains 258,729 characters. |
|
| |
| RFC 906 | Bootstrap loading using TFTP |
| |
| Authors: | R. Finlayson. |
| Date: | June 1984 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0906 |
|
It is often convenient to be able to bootstrap a computer system from a communications network. This RFC proposes the use of the IP TFTP protocol for bootstrap loading in this case. |
|
| |
| RFC 907 | Host Access Protocol specification |
| |
|
|
This document specifies the Host Access Protocol (HAP). Although HAP was originally designed as the network-access level protocol for the DARPA/DCA sponsored Wideband Packet Satellite Network, it is intended that it evolve into a standard interface SATNET and TACNET (aka MATNET) as well as the Wideband Network. HAP is an experimental protocol, and will undergo further revision as new capabilities are added and/or different satellite networks are suported. Implementations of HAP should be performed in coordination with satellite network development and operations personnel. |
|
| |
| RFC 908 | Reliable Data Protocol |
| |
| Authors: | D. Velten, R.M. Hinden, J. Sax. |
| Date: | July 1984 |
| Formats: | txt html json |
| Updated by: | RFC 1151 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 0908 |
|
The Reliable Data Protocol (RDP) is designed to provide a reliable data transport service for packet-based applications. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts. |
|
| |
| RFC 909 | Loader Debugger Protocol |
| |
| Authors: | C. Welles, W. Milliken. |
| Date: | July 1984 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 0909 |
|
The Loader Debugger Protocol (LDP) is an application layer protocol for loading, dumping, and debugging target machines from hosts in a network environment. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts. |
|
| |
| RFC 910 | Multimedia mail meeting notes |
| |
| Authors: | H.C. Forsdick. |
| Date: | August 1984 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0910 |
|
This memo is a report on a meeting about the experimental multimedia mail system (and in a sense a status report on that experiment). The meeting was held at Bolt Beranek and Newman on 23-24 July 1984 to discuss recent progress by groups who are building multimedia mail systems and to discuss a variety of issues related to the further development of multimedia systems. Representatives were present from BBN, ISI, SRI and Linkabit. |
|
| |
| RFC 911 | EGP Gateway under Berkeley UNIX 4.2 |
| |
|
|
This memo describes an implementation of the Exterior Gateway Protocol (EGP) (in that sense it is a status report). The memo also discusses some possible extentions and some design issues (in that sense it is an invitation for further discussion). |
|
| |
| RFC 912 | Authentication service |
| |
|
|
This memo describes a proposed authentication protocol for verifying the identity of a user of a TCP connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system. Suggested uses include automatic identification and verification of a user during an FTP session, additional verification of a TAC dial up user, and access verification for a generalized network file server. |
|
| |
| RFC 913 | Simple File Transfer Protocol |
| |
| Authors: | M. Lottor. |
| Date: | September 1984 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0913 |
|
This memo describes a proposed Simple File Transfer Protocol (SFTP). It fills the need of people wanting a protocol that is more useful than TFTP but easier to implement (and less powerful) than FTP. SFTP supports user access control, file transfers, directory listing, directory changing, file renaming and deleting. Discussion of this proposal is encouraged, and suggestions for improvements may be sent to the author. |
|
| |
| RFC 914 | Thinwire protocol for connecting personal computers to the Internet |
| |
| Authors: | D.J. Farber, G. Delp, T.M. Conte. |
| Date: | September 1984 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0914 |
|
This RFC focuses discussion on the particular problems in the ARPA-Internet of low speed network interconnection with personal computers, and possible methods of solution. None of the proposed solutions in this document are intended as standards for the ARPA-Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to the problems, leading eventually to the adoption of standards. |
|
| |
| RFC 915 | Network mail path service |
| |
| Authors: | M.A. Elvy, R. Nedved. |
| Date: | December 1984 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0915 |
|
This RFC proposed a new service for the ARPA-Internet community and requests discussion and suggestions for improvements. The network mail path service fills the current need of people to determine mailbox addresses for hosts that are not part of the ARPA-Internet but can be reached by one or more relay hosts that have Unix to Unix Copy (UUCP) mail, CSNET mail, MAILNET mail, BITNET mail, etc. Anyone can use the service if they have TCP/TELENET to one of the hosts with a mail path server. |
|
| |
| RFC 916 | Reliable Asynchronous Transfer Protocol (RATP) |
| |
| Authors: | G.G. Finn. |
| Date: | October 1984 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0916 |
|
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This paper proposes and specifies a protocol which allows two programs to reliably communicate over a communication link. It ensures that the data entering one end of the link if received arrives at the other end intact and unaltered. The protocol, named RATP, is designed to operate over a full duplex point-to-point connection. It contains some features which tailor it to the RS-232 links now in common use. |
|
| |
| RFC 917 | Internet subnets |
| |
| Authors: | J.C. Mogul. |
| Date: | October 1984 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0917 |
|
This memo discusses subnets and proposes procedures for the use of subnets, including approaches to solving the problems that arise, particularly that of routing. A subnet of an Internet network is a logically visible sub-section of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 918 | Post Office Protocol |
| |
|
|
This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. The intent of the Post Office Protocol (POP) is to allow a user's workstation to access mail from a mailbox server. It is expected that mail will be posted from the workstation to the mailbox server via the Simple Mail Transfer Protocol (SMTP). This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. The status of this protocol is experimental, and this protocol is dependent upon TCP. |
|
| |
| RFC 919 | Broadcasting Internet Datagrams |
| |
|
|
This RFC proposes simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 920 | Domain requirements |
| |
| Authors: | J. Postel, J.K. Reynolds. |
| Date: | October 1984 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0920 |
|
This memo states the requirements on establishing a Domain, and introduces the limited set of top level domains. This memo is a policy statement on the requirements of establishing a new domain in the ARPA-Internet and the DARPA research community. This is an official policy statement of the IAB and the DARPA. |
|
| |
| RFC 921 | Domain name system implementation schedule - revised |
| |
|
|
This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is an update of RFC-881, and RFC-897. This is an official policy statement of the IAB and the DARPA. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The explanation of how this system works is to be found in the references. |
|
| |
| RFC 922 | Broadcasting Internet datagrams in the presence of subnets |
| |
|
|
We propose simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 923 | Assigned numbers |
| |
|
|
This RFC documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers obsoletes RFC-900 and earlier editions. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990, and 997. |
|
| |
| RFC 924 | Official ARPA-Internet protocols for connecting personal computers to the Internet |
| |
|
|
This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-900 and earlier editions. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991. |
|
| |
| RFC 925 | Multi-LAN address resolution |
| |
| Authors: | J. Postel. |
| Date: | October 1984 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0925 |
|
The problem of treating a set of local area networks (LANs) as one Internet network has generated some interest and concern. It is inappropriate to give each LAN within an site a distinct Internet network number. It is desirable to hide the details of the interconnections between the LANs within an site from people, gateways, and hosts outside the site. The question arises on how to best do this, and even how to do it at all. In RFC-917 Jeffery Mogul makes a case for the use of "explicit subnets" in a multi-LAN environment. The explicit subnet scheme is a call to recursively apply the mechanisms the Internet uses to manage networks to the problem of managing LANs within one network. In this note I urge another approach: the use of "transparent subnets" supported by a multi-LAN extension of the Address Resolution Protocol. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 926 | Protocol for providing the connectionless mode network services |
| |
| Authors: | International Organization for Standardization. |
| Date: | December 1984 |
| Formats: | txt json html |
| Obsoleted by: | RFC 0994 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0926 |
|
This note is the draft ISO protocol roughly similar to the DOD Internet Protocol. This document has been prepared by retyping the text of ISO DIS 8473 of May 1984, which is currently undergoing voting within ISO as a Draft International Standard (DIS). This document is distributred as an RFC for information only. It does not specify a standard for the ARPA-Internet. |
|
| |
| RFC 927 | TACACS user identification Telnet option |
| |
| Authors: | B.A. Anderson. |
| Date: | December 1984 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 0927 |
|
The following is the description of a TELNET option designed to facilitate double login avoidance. It is intended primarily for TAC connections to target hosts on behalf of TAC users, but it can be used between any two consenting hosts. For example, all hosts at one site (e.g., BBN) can use this option to avoid double login when TELNETing to one another. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 928 | Introduction to proposed DoD standard H-FP |
| |
| Authors: | M.A. Padlipsky. |
| Date: | December 1984 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0928 |
|
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. |
|
| |
| RFC 929 | Proposed Host-Front End Protocol |
| |
| Authors: | J. Lilienkamp, R. Mandell, M.A. Padlipsky. |
| Date: | December 1984 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0929 |
|
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. |
|
| |
| RFC 930 | Telnet terminal type option |
| |
|
|
This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC-884. The only change is to specify that the TERMINAL-TYPE IS sub-negotiation should be sent only in response to the TERMINAL-TYPE SEND sub-negotiation. |
|
| |
| RFC 931 | Authentication server |
| |
|
|
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is the second draft of this proposal (superseding RFC-912) and incorporates a more formal description of the syntax for the request and response dialog, as well as a change to specify the type of user identification returned. |
|
| |
| RFC 932 | Subnetwork addressing scheme |
| |
| Authors: | D.D. Clark. |
| Date: | January 1985 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0932 |
|
This RFC proposes an alternative addressing scheme for subnets which, in most cases, requires no modification to host software whatsoever. The drawbacks of this scheme are that the total number of subnets in any one network are limited, and that modification is required to all gateways. |
|
| |
| RFC 933 | Output marking Telnet option |
| |
| Authors: | S. Silverman. |
| Date: | January 1985 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 0933 |
|
This proposed option would allow a Server-Telnet to send a banner to a User-Telnet so that this banner would be displayed on the workstation screen independently of the application software running in the Server-Telnet. |
|
| |
| RFC 934 | Proposed standard for message encapsulation |
| |
| Authors: | M.T. Rose, E.A. Stefferud. |
| Date: | January 1985 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0934 |
|
This memo concerns itself with message forwarding. Forwarding can be thought of as encapsulating one or more messages inside another. Although this is useful for transfer of past correspondence to new recipients, without a decapsulation process (which this memo terms "bursting"), the forwarded messages are of little use to the recipients because they can not be distributed, forwarded, replied-to, or otherwise processed as separate individual messages. In order to burst a message it is necessary to know how the component messages were encapsulated in the draft. At present there is no unambiguous standard for interest group digests. This RFC proposes a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 935 | Reliable link layer protocols |
| |
| Authors: | J.G. Robinson. |
| Date: | January 1985 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0935 |
|
This RFC discusses protocols proposed recently in RFCs 914 and 916, and suggests a proposed protocol that could meet the same needs addressed in those memos. The stated need is reliable communication between two programs over a full-duplex, point-to-point communication link, and in particular the RFCs address the need for such communication over an asynchronous link at relatively low speeds. The suggested protocol uses the methods of existing national and international data link layer standards. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 936 | Another Internet subnet addressing scheme |
| |
| Authors: | M.J. Karels. |
| Date: | February 1985 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0936 |
|
There have been several proposals for schemes to allow the use of a single Internet network number to refer to a collection of physical networks under common administration which are reachable from the rest of the Internet by a common route. Such schemes allow a simplified view of an otherwise complicated topology from hosts and gateways outside of this collection. They allow the complexity of the number and type of these networks, and routing to them, to be localized. Additions and changes in configuration thus cause no detectable change, and no interruption of service, due to slow propagation of routing and other information outside of the local environment. These schemes also simplify the administration of the network, as changes do not require allocation of new network numbers for each new cable installed. This proposal discusses an alternative scheme, one that has been in use at the University of California, Berkeley since April 1984. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 937 | Post Office Protocol: Version 2 |
| |
| Authors: | M. Butler, J. Postel, D. Chase, J. Goldberger, J.K. Reynolds. |
| Date: | February 1985 |
| Formats: | txt json html |
| Obsoletes: | RFC 0918 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0937 |
|
This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. This memo is a revision of RFC-918. |
|
| |
| RFC 938 | Internet Reliable Transaction Protocol functional and interface specification |
| |
| Authors: | T. Miller. |
| Date: | February 1985 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 0938 |
|
This RFC is being distributed to members of the DARPA research community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the DARPA community, they may be interesting to a number of researchers and implementors. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 939 | Executive summary of the NRC report on transport protocols for Department of Defense data networks |
| |
| Authors: | National Research Council. |
| Date: | February 1985 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0939 |
|
This RFC reproduces the material from the "front pages" of the National Research Council report resulting from a study of the DOD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4). The point of this RFC is to make the text of the Executive Summary widely available in a timely way. The order of presentation has been altered, and the pagination changed. This RFC is distributed for information only. This RFC does not establish any policy for the DARPA research community or the DDN operational community. |
|
| |
| RFC 940 | Toward an Internet standard scheme for subnetting |
| |
| Authors: | Gateway Algorithms and Data Structures Task Force. |
| Date: | April 1985 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0940 |
|
Several sites now contain a complex of local links connected to the Internet via a gateway. The details of the internal connectivity are of little interest to the rest of the Internet. One way of organizing these local complexes of links is to use the same strategy as the Internet uses to organize networks, that is, to declare each link to be an entity (like a network) and to interconnect the links with devices that perform routing functions (like gateways). This general scheme is called subnetting, the individual links are called subnets, and the connecting devices are called subgateways (or bridges, or gateways). This RFC discusses standardizing the protocol used in subnetted environments in the ARPA-Internet. |
|
| |
| RFC 941 | Addendum to the network service definition covering network layer addressing |
| |
| Authors: | International Organization for Standardization. |
| Date: | April 1985 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0941 |
|
This Addendum to the Network Service Definition Standard, ISO 8348, defines the abstract syntax and semantics of the Network Address (Network Service Access Point Address). The Network Address defined in this Addendum is the address that appears in the primitives of the connection-mode Network Service as the calling address, called address, and responding address parameters, and in the primitives of the connectionless-mode Network Service as the source address and destination address parameters. This document is distributed as an RFC for information only. It does not specify a standard for the ARPA-Internet. |
|
| |
| RFC 942 | Transport protocols for Department of Defense data networks |
| |
| Authors: | National Research Council. |
| Date: | February 1985 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0942 |
|
This RFC reproduces the National Research Council report resulting from a study of the DoD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4). |
|
| |
| RFC 943 | Assigned numbers |
| |
|
|
This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This RFC will be updated periodically, and in any case current information can be obtained from Joyce Reynolds. The assignment of numbers is also handled by Joyce. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, network number, etc., please contact Joyce to receive a number assignment. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997. |
|
| |
| RFC 944 | Official ARPA-Internet protocols |
| |
|
|
This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-924 and earlier editions. This RFC will be updated periodically, and current information can be obtained from Joyce Reynolds. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991. |
|
| |
| RFC 945 | DoD statement on the NRC report |
| |
|
|
In May 1983 the National Research Council (NRC) was asked jointly by DoD and NBS to study the issues and recommend a course of action. The final report of the NRC committee was published in February 1985 (see RFC-942). The enclosed letter is from Donald C. Latham (ASDC3I) to DCA transmitting the NRC report and requesting specific actions relative to the recommendations of the report. This RFC reproduces a letter from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC3I) to the Director of the Defense Communications Agency (DCA). This letter is distributed for information only. |
|
| |
| RFC 946 | Telnet terminal location number option |
| |
| Authors: | R. Nedved. |
| Date: | May 1985 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 0946 |
|
Many systems provide a mechanism for finding out where a user is logged in from usually including information about telephone extension and office occupants names. The information is useful for physically locating people and/or calling them on the phone. In 1982 CMU designed and implemented a terminal location database and modified existing network software to handle a 64-bit number called the Terminal Location Number (or TTYLOC). It now seems appropriate to incorporate this mechanism into the TCP-based network protocol family. The mechanism is not viewed as a replacement for the Terminal Location Telnet Option (SEND-LOCATION) but as a shorthand mechansim for communicating terminal location information between hosts in a localized community. This RFC proposes a new option for Telnet for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 947 | Multi-network broadcasting within the Internet |
| |
| Authors: | K. Lebowitz, D. Mankins. |
| Date: | June 1985 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0947 |
|
This RFC describes the extension of a network's broadcast domain to include more than one physical network through the use of a broadcast packet repeater. |
|
| |
| RFC 948 | Two methods for the transmission of IP datagrams over IEEE 802.3 networks |
| |
|
|
This RFC describes two methods of encapsulating Internet Protocol (IP) datagrams on an IEEE 802.3 network. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 949 | FTP unique-named store command |
| |
| Authors: | M.A. Padlipsky. |
| Date: | July 1985 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0949 |
|
There are various contexts in which it would be desirable to have an FTP command that had the effect of the present STOR but rather than requiring the sender to specify a file name istead caused the resultant file to have a unique name relative to the current directory. This RFC proposes an extension to the File Transfer Protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. See RFC-959. |
|
| |
| RFC 950 | Internet Standard Subnetting Procedure |
| |
|
|
This memo discusses the utility of "subnets" of Internet networks, which are logically visible sub-sections of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This memo specifies procedures for the use of subnets. These procedures are for hosts (e.g., workstations). The procedures used in and between subnet gateways are not fully described. Important motivation and background information for a subnetting standard is provided in RFC-940. This RFC specifies a protocol for the ARPA-Internet community. If subnetting is implemented it is strongly recommended that these procedures be followed. |
|
| |
| RFC 951 | Bootstrap Protocol |
| |
|
|
This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled `address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 952 | DoD Internet host table specification |
| |
|
|
This RFC is the official specification of the format of the Internet Host Table. This edition of the specification includes minor revisions to RFC-810 which brings it up to date. |
|
| |
| RFC 953 | Hostname Server |
| |
| Authors: | K. Harrenstien, M.K. Stahl, E.J. Feinler. |
| Date: | October 1985 |
| Formats: | txt html json |
| Obsoletes: | RFC 0811 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0953 |
|
This RFC is the official specification of the Hostname Server Protocol. This edition of the specification includes minor revisions to RFC-811 which brings it up to date. |
|
| |
| RFC 954 | NICNAME/WHOIS |
| |
|
|
This RFC is the official specification of the NICNAME/WHOIS protocol. This memo describes the protocol and the service. This is an update of RFC-812. |
|
| |
| RFC 955 | Towards a transport service for transaction processing applications |
| |
| Authors: | R.T. Braden. |
| Date: | September 1985 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0955 |
|
The DoD Internet protocol suite includes two alternative transport service protocols, TCP and UDP, which provide virtual circuit and datagram service, respectively. These two protocols represent points in the space of possible transport service attributes which are quite "far apart". We want to examine an important class of applications, those which perform what is often called "transaction processing". We will see that the communication needs for these applications fall into the gap "between" TCP and UDP -- neither protocol is very appropriate. This RFC is concerned with the possible design of one or more new protocols for the ARPA-Internet, to support kinds of applications which are not well supported at present. The RFC is intended to spur discussion in the Internet research community towards the development of new protocols and/or concepts, in order to meet these unmet application requirements. It does not represent a standard, nor even a concrete protocol proposal. |
|
| |
| RFC 956 | Algorithms for synchronizing network clocks |
| |
| Authors: | D.L. Mills. |
| Date: | September 1985 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0956 |
|
This RFC discussed clock synchronization algorithms for the ARPA-Internet community, and requests discussion and suggestions for improvements. The recent interest within the Internet community in determining accurate time from a set of mutually suspicious network clocks has been prompted by several occasions in which errors were found in usually reliable, accurate clock servers after thunderstorms which disrupted their power supply. To these sources of error should be added those due to malfunctioning hardware, defective software and operator mistakes, as well as random errors in the mechanism used to set and synchronize clocks. This report suggests a stochastic model and algorithms for computing a good estimator from time-offset samples measured between clocks connected via network links. Included in this report are descriptions of certain experiments which give an indication of the effectiveness of the algorithms. |
|
| |
| RFC 957 | Experiments in network clock synchronization |
| |
| Authors: | D.L. Mills. |
| Date: | September 1985 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0957 |
|
This RFC discusses some experiments in clock synchronization in the ARPA-Internet community, and requests discussion and suggestions for improvements. One of the services frequently neglected in computer network design is a high-quality, time-of-day clock capable of generating accurate timestamps with small errors compared to one-way network delays. Such a service would be useful for tracing the progress of complex transactions, synchronizing cached data bases, monitoring network performance and isolating problems. In this memo one such clock service design will be described and its performance assessed. This design has been incorporated as an integral part of the network routing and control protocols of the Distributed Computer Network (DCnet) architecture. |
|
| |
| RFC 958 | Network Time Protocol (NTP) |
| |
|
|
This document describes the Network Time Protocol (NTP), a protocol for synchronizing a set of network clocks using a set of distributed clients and servers. NTP is built on the User Datagram Protocol (UDP), which provides a connectionless transport mechanism. It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 959 | File Transfer Protocol |
| |
|
|
This memo is the official specification of the File Transfer Protocol (FTP) for the DARPA Internet community. The primary intent is to clarify and correct the documentation of the FTP specification, not to change the protocol. The following new optional commands are included in this edition of the specification: Change to Parent Directory (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove Directory (RMD), Make Directory (MKD), Print Directory (PWD), and System (SYST). Note that this specification is compatible with the previous edition. |
|
| |
| RFC 960 | Assigned numbers |
| |
|
|
This memo documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers updates and obsoletes RFC-943. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997. |
|
| |
| RFC 961 | Official ARPA-Internet protocols |
| |
|
|
This memo identifies the documents specifying the official protocols used in the Internet, and comments on any revisions or changes planned. This edition of the Official Protocols updates and obsoletes RFC-944. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991. |
|
| |
| RFC 962 | TCP-4 prime |
| |
| Authors: | M.A. Padlipsky. |
| Date: | November 1985 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0962 |
|
This memo is in response to Bob Braden's call for a transaction oriented protocol (RFC-955), and continues the discussion of a possible transaction oriented transport protocol. This memo does not propose a standard. |
|
| |
| RFC 963 | Some problems with the specification of the Military Standard Internet Protocol |
| |
| Authors: | D.P. Sidhu. |
| Date: | November 1985 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0963 |
|
The purpose of this RFC is to provide helpful information on the Military Standard Internet Protocol (MIL-STD-1777) so that one can obtain a reliable implementation of this protocol. This paper points out several problems in this specification. This note also proposes solutions to these problems. |
|
| |
| RFC 964 | Some problems with the specification of the Military Standard Transmission Control Protocol |
| |
| Authors: | D.P. Sidhu, T. Blumer. |
| Date: | November 1985 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 0964 |
|
The purpose of this RFC is to provide helpful information on the Military Standard Transmission Control Protocol (MIL-STD-1778) so that one can obtain a reliable implementation of this protocol standard. This note points out three errors with this specification. This note also proposes solutions to these problems. |
|
| |
| RFC 965 | Format for a graphical communication protocol |
| |
| Authors: | L. Aguilar. |
| Date: | December 1985 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0965 |
|
This RFC describes the requirements for a graphical format on which to base a graphical on-line communication protocol, and proposes an Interactive Graphical Communication Format using the GKSM session metafile. We hope this contribution will encourage the discussion of multimedia data exchange and the proposal of solutions. |
|
| |
| RFC 966 | Host groups: A multicast extension to the Internet Protocol |
| |
| Authors: | S.E. Deering, D.R. Cheriton. |
| Date: | December 1985 |
| Formats: | txt html json |
| Obsoleted by: | RFC 0988 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0966 |
|
This RFC defines a model of service for Internet multicasting and proposes an extension to the Internet Protocol (IP) to support such a multicast service. Discussion and suggestions for improvements are requested. See RFC-988. |
|
| |
| RFC 967 | All victims together |
| |
| Authors: | M.A. Padlipsky. |
| Date: | December 1985 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0967 |
|
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. |
|
| |
| RFC 968 | Twas the night before start-up |
| |
| Authors: | V.G. Cerf. |
| Date: | December 1985 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0968 |
|
This memo discusses problems that arise and debugging techniques used in bringing a new network into operation. |
|
| |
| RFC 969 | NETBLT: A bulk data transfer protocol |
| |
| Authors: | D.D. Clark, M.L. Lambert, L. Zhang. |
| Date: | December 1985 |
| Formats: | txt json html |
| Obsoleted by: | RFC 0998 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0969 |
|
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is a preliminary discussion of the Network Block Transfer (NETBLT) protocol. NETBLT is intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is structured to provide maximum throughput over a wide variety of networks. This description is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-998. |
|
| |
| RFC 970 | On Packet Switches With Infinite Storage |
| |
| Authors: | J. Nagle. |
| Date: | December 1985 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0970 |
|
Most prior work on congestion in datagram systems focuses on buffer management. We find it illuminating to consider the case of a packet switch with infinite storage. Such a packet switch can never run out of buffers. It can, however, still become congested. The meaning of congestion in an infinite-storage system is explored. We demonstrate the unexpected result that a datagram network with infinite storage, first-in-first-out queuing, at least two packet switches, and a finite packet lifetime will, under overload, drop all packets. By attacking the problem of congestion for the infinite-storage case, we discover new solutions applicable to switches with finite storage. |
|
| |
| RFC 971 | Survey of data representation standards |
| |
| Authors: | A.L. DeSchon. |
| Date: | January 1986 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0971 |
|
This RFC is a comparison of several data representation standards that are currently in use. The standards discussed are the CCITT X.409 recommendation, the NBS Computer Based Message System (CBMS) standard, DARPA Multimedia Mail system, the Courier remote procedure call protocol, and the SUN Remote Procedure Call package. No proposals in this document are intended as standards for the ARPA-Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate approach to a data representation standard, leading eventually to the adoption of an ARPA-Internet standard. |
|
| |
| RFC 972 | Password Generator Protocol |
| |
| Authors: | F.J. Wancho. |
| Date: | January 1986 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0972 |
|
This RFC specifies a standard for the ARPA Internet community. The Password Generator Service (PWDGEN) provides a set of six randomly generated eight-character "words" with a reasonable level of pronounceability, using a multi-level algorithm. Hosts on the ARPA Internet that choose to implement a password generator service are expected to adopt and implement this standard. |
|
| |
| RFC 973 | Domain system changes and observations |
| |
|
|
This RFC documents updates to Domain Name System specifications RFC-882 and RFC-883, suggests some operational guidelines, and discusses some experiences and problem areas in the present system. |
|
| |
| RFC 974 | Mail routing and the domain system |
| |
|
|
This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system. This involves a discussion of how mailers interpret MX RRs, which are used for message routing. |
|
| |
| RFC 975 | Autonomous confederations |
| |
| Authors: | D.L. Mills. |
| Date: | February 1986 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0975 |
|
This RFC proposes enhancements to the Exterior Gateway Protocol (EGP) to support a simple, multiple-level routing capability while preserving the robustness features of the current EGP model. The enhancements generalize the concept of core system to include multiple communities of autonomous systems, called autonomous confederations. Discussion and suggestions for improvement are requested. |
|
| |
| RFC 976 | UUCP mail interchange format standard |
| |
|
|
This document defines the standard format for the transmission of mail messages between computers in the UUCP Project. It does not however, address the format for storage of messages on one machine, nor the lower level transport mechanisms used to get the date from one machine to the next. It represents a standard for conformance by hosts in the UUCP zone. |
|
| |
| RFC 977 | Network News Transfer Protocol |
| |
| Authors: | B. Kantor, P. Lapsley. |
| Date: | February 1986 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3977 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 0977 |
|
NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community. NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read. Indexing, cross-referencing, and expiration of aged messages are also provided. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 978 | Voice File Interchange Protocol (VFIP) |
| |
| Authors: | J.K. Reynolds, R. Gillman, W.A. Brackenridge, A. Witkowski, J. Postel. |
| Date: | February 1986 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0978 |
|
The purpose of the Voice File Interchange Protocol (VFIP) is to permit the interchange of various types of speech files between different systems in the ARPA-Internet community. Suggestions for improvement are encouraged. |
|
| |
| RFC 979 | PSN End-to-End functional specification |
| |
|
|
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. |
|
| |
| RFC 980 | Protocol document order information |
| |
| Authors: | O.J. Jacobsen, J. Postel. |
| Date: | March 1986 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0980 |
|
This RFC indicates how to obtain various protocol documents used in the DARPA research community. Included is an overview of the new 1985 DDN Protocol Handbook and available sources for obtaining related documents (such as DOD, ISO, and CCITT). |
|
| |
| RFC 981 | Experimental multiple-path routing algorithm |
| |
|
|
This document introduces wiretap algorithms, which are a class of routing algorithms that compute quasi-optimum routes for stations sharing a broadcast channel, but with some stations hidden from others. The wiretapper observes the paths (source routes) used by other stations sending traffic on the channel and, using a heuristic set of factors and weights, constructs speculative paths for its own traffic. A prototype algorithm, called here the Wiretap Algorithm, has been designed for the AX.25 packet-radio channel. Its design is similar in many respects to the shortest-path-first (spf) algorithm used in the ARPANET and elsewhere, and is in fact a variation in the class of algorithms, including the Viterbi Algorithm, that construct optimum paths on a graph according to a distance computed as a weighted sum of factors assigned to the nodes and edges.
The Wiretap Algorithm differs from conventional algorithms in that it computes not only the primary route (a minimum-distance path), but also additional paths ordered by distance, which serve as alternate routes should the primary route fail. This feature is also useful for the discovery of new paths not previously observed on the channel.
Since the amateur AX.25 packet-radio channel is very active in theWashington, DC, area and carries a good deal of traffic under punishing conditions, it was considered a sufficiently heroic environment for a convincing demonstration of the prototype algorithm. It was implemented as part of an IP/TCP driver for theLSI-11 processor running the "fuzzball" operating system. The driver is connected via serial line to a 6809-based TAPR-1 processor running the WA8DED firmware, which controls the radio equipmnet in both |
|
| |
| RFC 982 | Guidelines for the specification of the structure of the Domain Specific Part (DSP) of the ISO standard NSAP address |
| |
|
|
This RFC is a draft working document of the ANSI "Guidelines for the Specification of the Structure of the Domain Specific Part (DSP) of the ISO Standard NSAP Address". It provides guidance to private address administration authorities on preferred formats and semantics for the Domain Specific Part (DSP) of an NSAP address. This RFC specifies the way in which the DSP may be constructed so as to facilitate efficient address assignment. This RFC is for informational purposes only and its distribution is unlimited and does not specify a standard of the ARPA-Internet. |
|
| |
| RFC 983 | ISO transport arrives on top of the TCP |
| |
|
|
This memo describes a proposed protocol standard for the ARPA Internet community. The CCITT and the ISO have defined various session, presentation, and application recommendations which have been adopted by the international community and numerous vendors. To the largest extent possible, it is desirable to offer these higher level services directly in the ARPA Internet, without disrupting existing facilities. This permits users to develop expertise with ISO and CCITT applications which previously were not available in the ARPA Internet. The intention is that hosts in the ARPA-Internet that choose to implement ISO TSAP services on top of the TCP be expected to adopt and implement this standard. Suggestions for improvement are encouraged. |
|
| |
| RFC 984 | PCMAIL: A distributed mail system for personal computers |
| |
|
|
This document is a preliminary discussion of the design of a personal-computer-based distributed mail system. Pcmail is a distributed mail system that provides mail service to an arbitrary number of users, each of which owns one or more personal computers (PCs). The system is divided into two halves. The first consists of a single entity called the "repository". The repository is a storage center for incoming mail. Mail for a Pcmail user can arrive externally from the Internet or internally from other repository users. The repository also maintains a stable copy of each user's mail state. The repository is therefore typically a computer with a large amount of disk storage. It is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-993. |
|
| |
| RFC 985 | Requirements for Internet gateways - draft |
| |
| Authors: | National Science Foundation, Network Technical Advisory Group. |
| Date: | May 1986 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1009 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0985 |
|
This RFC summarizes the requirements for gateways to be used on networks supporting the DARPA Internet protocols. While it applies specifically to National Science Foundation research programs, the requirements are stated in a general context and are believed applicable throughout the Internet community. The purpose of this document is to present guidance for vendors offering products that might be used or adapted for use in an Internet application. It enumerates the protocols required and gives references to RFCs and other documents describing the current specification. |
|
| |
| RFC 986 | Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol |
| |
|
|
This RFC suggests a method to allow the existing IP addressing, including the IP protocol field, to be used for the ISO Connectionless Network Protocol (CLNP). This is a draft solution to one of the problems inherent in the use of "ISO-grams" in the DOD Internet. Related issues will be discussed in subsequent RFCs. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 987 | Mapping between X.400 and RFC 822 |
| |
|
|
The X.400 series protocols have been defined by CCITT to provide an Interpersonal Messaging Service (IPMS), making use of a store and forward Message Transfer Service. It is expected that this standard will be implemented very widely. This document describes a set of mappings which will enable interworking between systems operating the X.400 protocols and systems using RFC-822 mail protocol or protocols derived from RFC-822. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 988 | Host extensions for IP multicasting |
| |
|
|
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support internetwork multicasting. This specification supersedes that given in RFC-966, and constitutes a proposed protocol standard for IP multicasting in the ARPA-Internet. The reader is directed to RFC-966 for a discussion of the motivation and rationale behind the multicasting extension specified here. |
|
| |
| RFC 989 | Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures |
| |
|
|
This RFC suggests a proposed protocol for the Internet community and requests discussion and suggestions for improvements. This RFC is the outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This RFC defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. It is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or authentication is anticipated. |
|
| |
| RFC 990 | Assigned numbers |
| |
|
|
This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-997. Obsoletes RFC-960, 943, 923 and 900. |
|
| |
| RFC 991 | Official ARPA-Internet protocols |
| |
|
|
This RFC identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. Obsoletes RFC-961, 944 and 924. |
|
| |
| RFC 992 | On communication support for fault tolerant process groups |
| |
| Authors: | K.P. Birman, T.A. Joseph. |
| Date: | November 1986 |
| Formats: | txt html json |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0992 |
|
This memo describes a collection of multicast communication primitives integrated with a mechanism for handling process failure and recovery. These primitives facilitate the implementation of fault-tolerant process groups, which can be used to provide distributed services in an environment subject to non-malicious crash failures. |
|
| |
| RFC 993 | PCMAIL: A distributed mail system for personal computers |
| |
|
|
This document is a discussion of the Pcmail workstation-based distributed mail system. It is a revision of the design published in NIC RFC-984. The revision is based on discussion and comment fromm a variety of sources, as well as further research into the design of interactive Pcmail clients and the use of client code on machines other than IBM PCs. As this design may change, implementation of this document is not advised. Obsoletes RFC-984. |
|
| |
| RFC 994 | Final text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service |
| |
| Authors: | International Organization for Standardization. |
| Date: | March 1986 |
| Formats: | txt json html |
| Obsoletes: | RFC 0926 |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0994 |
|
This Protocol Standard is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such interconnection. This Protocol Standard is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498). In particular, it is a protocol of the Network Layer. This Protocol may be used between network-entities in end systems or in Network Layer relay systems (or both). It provides the Connectionless-mode Network Service as defined in Addendum 1 to the Network Service Definition Covering Connectionless-mode Transmission (ISO 8348/AD1). |
|
| |
| RFC 995 | End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473 |
| |
| Authors: | International Organization for Standardization. |
| Date: | April 1986 |
| Formats: | txt json html |
| Status: | UNKNOWN |
| DOI: | 10.17487/RFC 0995 |
|
This Protocol is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such interconnection. This Protocol is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498) and by the structure defined in the Internal Organization of the Network Layer (DIS 8648). In particular, it is a protocol of the Network Layer. This Protocol permits End Systems and Intermediate Systems to exchange configuration and routing information to facilitate the operation of the routing and relaying functions of the Network Layer. |
|
| |
| RFC 996 | Statistics server |
| |
| Authors: | D.L. Mills. |
| Date: | February 1987 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0996 |
|
This RFC specifies a standard for the ARPA Internet community. Hosts and gateways on the DARPA 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. |
|
| |
| RFC 997 | Internet numbers |
| |
|
|
This memo is an official status report on the network numbers used in the Internet community. As of 1-Mar-87 the Network Information Center (NIC) at SRI International has assumed responsibility for assignment of Network Numbers and Autonomous System Numbers. This RFC documents the current assignments of these numbers at the time of this transfer of responsibility. Obsoletes RFC-990, 960, 943, 923 and 900. |
|
| |
| RFC 998 | NETBLT: A bulk data transfer protocol |
| |
| Authors: | D.D. Clark, M.L. Lambert, L. Zhang. |
| Date: | March 1987 |
| Formats: | txt json html |
| Obsoletes: | RFC 0969 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 0998 |
|
This document is a description of, and a specification for, the NETBLT protocol. It is a revision of the specification published in RFC-969. NETBLT (NETwork BLock Transfer) is a transport level protocol intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is designed to provide maximum throughput over a wide variety of networks. Although NETBLT currently runs on top of the Internet Protocol (IP), it should be able to operate on top of any datagram protocol similar in function to IP. This document is published for discussion and comment, and does not constitute a standard. The proposal may change and certain parts of the protocol have not yet been specified; implementation of this document is therefore not advised. Obsoletes RFC-969. |
|
| |
| RFC 999 | Requests For Comments summary notes: 900-999 |
| |
|
