diff options
Diffstat (limited to 'doc/rfc/rfc999.txt')
| -rw-r--r-- | doc/rfc/rfc999.txt | 1293 |
1 files changed, 1293 insertions, 0 deletions
diff --git a/doc/rfc/rfc999.txt b/doc/rfc/rfc999.txt new file mode 100644 index 0000000..5f90b5c --- /dev/null +++ b/doc/rfc/rfc999.txt @@ -0,0 +1,1293 @@ +Network Working Group A. Westine +Request for Comments: 999 J. Postel + ISI + April 1987 + + + Requests For Comments Summary + Notes: 900-999 + + + +Status of this Memo + + This RFC is a slightly annotated list of the 100 RFCs from RFC-900 + through RFC-999. This is a status report on these RFCs. Distribution + of this memo is unlimited. + +RFC Author Date Title +--- ------ ---- ----- + +999 Westine Apr 87 Requests For Comments Summary + + This memo. + +998 Lambert Mar 87 NETBLT: A Bulk Data Transfer + Protocol + + 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. + +997 Reynolds Mar 87 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. + + + + + + +Westine & Postel [Page 1] + +RFC 999 March 1987 + + +996 Mills Feb 87 Statistics Server + + 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. + +995 ANSI Apr 86 End System to Intermediate System + Routing Exchange Protocol for use in + conjunction with ISO 8473. + + 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. + +994 ANSI Mar 86 Final Text of DIS 8473, Protocol for + Providing the Connectionless Mode + Network Service + + 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). + +993 Clark Dec 86 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. + + + + + + +Westine & Postel [Page 2] + +RFC 999 March 1987 + + +992 Birman Nov 86 On Communication Support for + Fault-Tolerant Process Groups + + 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. + +991 Reynolds Nov 86 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. + +990 Reynolds Nov 86 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. + +989 Linn Feb 87 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. + +988 Deering Jul 86 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. + + + + +Westine & Postel [Page 3] + +RFC 999 March 1987 + + +987 Kille Jun 86 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. + +986 Callon Jun 86 Working Draft -- Guidelines for the Use + of Internet-IP addressing 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. + +985 Mills May 86 Requirements for Internet Gateways + + 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. + +984 Clark May 86 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. + + +9Westine & Postel [Page 4] + +RFC 999 March 1987 + + +983 Cass Apr 86 ISO Transport Services 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. + +982 ANSI Apr 86 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. + +981 Mills Mar 86 An Experimental Multiple-Path Routing + Algorithm + + This document introduces wiretap algorithms, a class of experimental, + multiple routing algorithms that compute quasi-optimum routes for + stations sharing a packet-radio broadcast channel. The primary route (a + minimum-distance path), and additional paths ordered by distance, which + serve as alternate routes should the primary route fail, are computed. + This prototype is presented as an example of a class of routing + algorithms and data-base management techniques that may find wider + application in the Internet community. Discussions and suggestions for + improvements are welcomed. + +980 Jacobsen Mar 86 Protocol Document Order Information + + 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). + + + +9 + +9Westine & Postel [Page 5] + +RFC 999 March 1987 + + +979 Malis Mar 86 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. + +978 Reynolds Feb 86 Voice File Interchange Protocol (VFIP) + + 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. + +977 Kantor Feb 86 Network News Transfer Protocol + + 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. + +976 Horton Feb 86 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. + +975 Mills Feb 86 Autonomous Confederations + + 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. + + + + + + + +Westine & Postel [Page 6] + +RFC 999 March 1987 + + +974 Partridge Jan 86 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. + +973 Mockapetris Jan 86 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. + +972 Wancho Jan 86 Password Generator Protocol + + 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. + +971 DeSchon Dec 85 A Survey of Data Representation + Standards + + 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. + +970 Nagle Dec 85 On Packet Switches With Infinite + Storage + + The purpose of this RFC is to focus discussion on a particular problem + in the ARPA-Internet and possible methods of solution. Most prior work + on congestion in datagram systems focuses on buffer management. In this + memo the case of a packet switch with infinite storage is considered. + 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. An unexpected result is found that + shows 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, new solutions applicable to + switches with finite storage may be found. No proposed solutions this + document are intended as standards for the ARPA-Internet at this time. + + + +Westine & Postel [Page 7] + +RFC 999 March 1987 + + +969 Clark Dec 85 NETBLT: A Bulk Data Transfer Protocol + + 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. + +968 Cerf Dec 85 'Twas the Night Before Start-up' + + This memo discusses problems that arise and debugging techniques used in + bringing a new network into operation. + +967 Padlipsky Dec 85 All Victims Together + + 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. + +966 Deering Dec 85 A Multicast Extension to the Internet + Protocol + + 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. + +965 Aguilar Dec 85 A Format for a Graphical Communication + Protocol + + 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. + +964 Sidhu Nov 85 Some Problems with the Specification of + the Military Standard Transmission + Control Protocol + + 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. + + + + +Westine & Postel [Page 8] + +RFC 999 March 1987 + + +963 Sidhu Nov 85 Some Problems with the Specification of + the Military Standard Internet Protocol + + 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. + +962 Padlipsky Nov 85 TCP-4 Prime + + 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. + +961 Reynolds Dec 85 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. + +960 Reynolds Dec 85 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. + +959 Postel Oct 85 File Transfer Protocol (FTP) + + 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. + +958 Mills Sep 85 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 + + + +Westine & Postel [Page 9] + +RFC 999 March 1987 + + + ARPA-Internet community, and requests discussion and suggestions for + improvements. + +957 Mills Sep 85 Experiments in Network Clock + Synchronization + + 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. + +956 Mills Sep 85 Algorithms for Synchronizing Network + Clocks + + 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. + +955 Braden Sep 85 Towards a Transport Service for + Transaction Processing Applications + + 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 + + + +Westine & Postel [Page 10] + +RFC 999 March 1987 + + + 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. + +954 Harrenstien Oct 85 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. + +953 Harrenstien Oct 85 Hostname Server + + 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. + +952 Harrenstien Oct 85 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. + +951 Croft Sep 85 Bootstrap Protocol (BOOTP) + + 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. + +950 Mogul Aug 85 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. + + +9Westine & Postel [Page 11] + +RFC 999 March 1987 + + +949 Padlipsky Jul 85 FTP Unique-Named Store Command + + 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. + +948 Winston Jun 85 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. + +947 Lebowitz Jun 85 Multi-Network Broadcasting Within the + Internet + + 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. + +946 Nedved May 85 Telnet Terminal Location Number Option + + 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. + +945 Postel May 85 A 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. + + +9Westine & Postel [Page 12] + +RFC 999 March 1987 + + +944 Reynolds Apr 85 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. + +943 Reynolds Apr 85 Assigned Network 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. + +942 NRC Feb 85 Transport Protocols for Department of + Defense Data Networks + + 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). + +941 ISO Apr 85 Addendum to the Network Service + Definition Covering Network Layer + Addressing + + 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. + + + + + + + + + +9 + +9Westine & Postel [Page 13] + +RFC 999 March 1987 + + +940 GADS Apr 85 Toward an Internet Standard Scheme for + Subnetting + + 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. + +939 NRC Feb 85 Executive Summary of the NRC Report on + Transport Protocols for Department of + Defense Data Networks + + 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. + +938 Miller Feb 85 Internet Reliable Transaction Protocol + Functional and Interface Specification + + 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. + +937 Reynolds Feb 85 Post Office Protocol - Version 2 + + 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. + + + + + + + + +Westine & Postel [Page 14] + +RFC 999 March 1987 + + +936 Karels Feb 85 Another Internet Subnet Addressing + Scheme + + 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. + +935 Robinson Jan 85 Reliable Link Layer Protocols + + 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. + +934 Rose Jan 85 Proposed Standard for Message + Encapsulation + + 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. + + + + + + + +Westine & Postel [Page 15] + +RFC 999 March 1987 + + +933 Silverman Jan 85 Output Marking Telnet Option + + 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. + +932 Clark Jan 85 A Subnetwork Addressing Scheme + + 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. + +931 StJohns Jan 85 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. + +930 Solomon Jan 85 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. + +929 Lilienkamp Dec 84 Proposed Host-Front End Protocol + + 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. + +928 Padlipsky Dec 84 Introduction to Proposed DOD Standard + H-FP + + 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". + + + +Westine & Postel [Page 16] + +RFC 999 March 1987 + + + 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. + +927 Anderson Dec 84 TACACS User Identification Telnet + Option + + 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. + +926 ISO Dec 84 Protocol for Providing the + Connectionless-Mode Network Services + + 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. + +925 Postel Oct 84 Multi-LAN Address Resolution + + 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. + +924 Reynolds Oct 84 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-900 and earlier editions. This memo is an official status + report on the protocols used in the ARPA-Internet community. See RFC-991. + + + +Westine & Postel [Page 17] + +RFC 999 March 1987 + + +923 Reynolds Oct 84 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. + +922 Mogul Oct 84 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. + +921 Postel Oct 84 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. + +920 Postel Oct 84 Domain Requirements + + 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. + +919 Mogul Oct 84 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. + +918 Reynolds Oct 84 Post Office Protocol (POP) + + 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 + + + +Westine & Postel [Page 18] + +RFC 999 March 1987 + + + requests discussion and suggestions for improvement. The status of this + protocol is experimental, and this protocol is dependent upon TCP. + +917 Mogul Oct 84 Internet Subnets + + 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. + +916 Finn Oct 84 Reliable Asynchronous Transfer Protocol + (RATP) + + 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. + +915 Elvy Dec 84 Network Mail Path Service + + 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. + +914 Farber Sep 84 A Thinwire Protocol + + 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. + + + + + + + + +Westine & Postel [Page 19] + +RFC 999 March 1987 + + +913 Lottor Sep 84 Simple File Transfer Protocol + + 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. + +912 StJohns Sep 84 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. + +911 Kirton Aug 84 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). + +910 Forsdick Aug 84 Multimedia Mail Meeting Notes + + 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. + +909 Welles Jul 84 Loader Debugger Protocol + + 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. + +908 Velten Jul 84 Reliable Data Protocol + + 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. + + + +Westine & Postel [Page 20] + +RFC 999 March 1987 + + +907 Storch Jul 84 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. + +906 Finlayson Jun 84 Bootstrap Loading Using TFTP + + 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. + +905 ISO Apr 84 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. + +904 Mills Apr 84 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. + +903 Finlayson Jun 84 A Reverse Address Resolution Protocol + + 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. + + + + + + + + +Westine & Postel [Page 21] + +RFC 999 March 1987 + + +902 Postel Jul 84 ARPA-Internet Protocol Policy + + 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. + +901 Reynolds Jun 84 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. + +900 Reynolds Jun 84 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Westine & Postel [Page 22] + |