📄 rfc999.txt
字号:
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 theWestine & 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 spurWestine & 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 1987949 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 1987944 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.99Westine & Postel [Page 13]RFC 999 March 1987940 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).
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -