home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 900s / rfc999.txt < prev   
Text File  |  1987-04-01  |  62KB  |  1,294 lines
  1. Network Working Group                                            A. Westine
  2. Request for Comments: 999                                         J. Postel
  3.                                                                         ISI
  4.                                                                  April 1987
  5.  
  6.  
  7.                      Requests For Comments Summary
  8.                              Notes: 900-999
  9.  
  10.  
  11.  
  12. Status of this Memo
  13.  
  14.    This RFC is a slightly annotated list of the 100 RFCs from RFC-900
  15.    through RFC-999.  This is a status report on these RFCs.  Distribution
  16.    of this memo is unlimited.
  17.  
  18. RFC     Author       Date        Title
  19. ---     ------       ----        -----
  20.  
  21. 999     Westine      Apr 87      Requests For Comments Summary
  22.  
  23.    This memo.
  24.  
  25. 998     Lambert      Mar 87      NETBLT:  A Bulk Data Transfer
  26.                                  Protocol
  27.  
  28.    This document is a description of, and a specification for, the NETBLT
  29.    protocol.  It is a revision of the specification published in RFC-969.
  30.    NETBLT (NETwork BLock Transfer) is a transport level protocol intended
  31.    for the rapid transfer of a large quantity of data between computers.
  32.    It provides a transfer that is reliable and flow controlled, and is
  33.    designed to provide maximum throughput over a wide variety of networks.
  34.    Although NETBLT currently runs on top of the Internet Protocol (IP), it
  35.    should be able to operate on top of any datagram protocol similar in
  36.    function to IP. This document is published for discussion and comment,
  37.    and does not constitute a standard.  The proposal may change and certain
  38.    parts of the protocol have not yet been specified; implementation of this
  39.    document is therefore not advised.  Obsoletes  RFC-969.
  40.  
  41. 997     Reynolds     Mar 87      Internet Numbers
  42.  
  43.    This memo is an official status report on the network numbers used in
  44.    the Internet community.  As of 1-Mar-87 the Network Information Center
  45.    (NIC) at SRI International has assumed responsibility for assignment of
  46.    Network Numbers and Autonomous System Numbers.  This RFC documents the
  47.    current assignments of these numbers at the time of this transfer of
  48.    responsibility.   Obsoletes RFC-990, 960, 943, 923 and 900.
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55. Westine & Postel                                                [Page 1]
  56.  
  57. RFC 999                                                       March 1987
  58.  
  59.  
  60. 996     Mills        Feb 87      Statistics Server
  61.  
  62.    This RFC specifies a standard for the ARPA Internet community. Hosts and
  63.    gateways on the DARPA Internet that choose to implement a remote
  64.    statistics monitoring facility may use this protocol to send statistics
  65.    data upon request to a monitoring center or debugging host.
  66.  
  67. 995     ANSI         Apr 86      End System to Intermediate System
  68.                                  Routing Exchange Protocol for use in
  69.                                  conjunction with ISO 8473.
  70.  
  71.    This Protocol is one of a set of International Standards produced to
  72.    facilitate the interconnection of open systems.  The set of standards
  73.    covers the services and protocols required to achieve such interconnection.
  74.    This Protocol is positioned with respect to other related standards by
  75.    the layers defined in the Reference Model for Open Systems Interconnection
  76.    (ISO 7498) and by the structure defined in the Internal Organization of the
  77.    Network Layer (DIS 8648).  In particular, it is a protocol of the Network
  78.    Layer.  This Protocol permits End Systems and Intermediate Systems to
  79.    exchange configuration and routing information to facilitate the operation
  80.    of the routing and relaying functions of the Network Layer.
  81.  
  82. 994     ANSI         Mar 86      Final Text of DIS 8473, Protocol for
  83.                                  Providing the Connectionless Mode
  84.                                  Network Service
  85.  
  86.    This Protocol Standard is one of a set of International Standards
  87.    produced to facilitate the interconnection of open systems.  The set of
  88.    standards covers the services and protocols required to achieve such
  89.    interconnection. This Protocol Standard is positioned with respect to
  90.    other related standards by the layers defined in the Reference Model
  91.    for Open Systems Interconnection (ISO 7498).  In particular, it is a
  92.    protocol of the Network Layer.  This Protocol may be used between
  93.    network-entities in end systems or in Network Layer relay systems (or
  94.    both).  It provides the Connectionless-mode Network Service as defined
  95.    in Addendum 1 to the Network Service Definition Covering Connectionless-mode
  96.    Transmission (ISO 8348/AD1).
  97.  
  98. 993     Clark        Dec 86      PCMAIL:  A Distributed Mail System for
  99.                                  Personal Computers
  100.  
  101.    This document is a discussion of the Pcmail workstation-based
  102.    distributed mail system.  It is a revision of the design published in
  103.    NIC RFC-984.  The revision is based on discussion and comment fromm a
  104.    variety of sources, as well as further research into the design of
  105.    interactive Pcmail clients and the use of client code on machines other
  106.    than IBM PCs.  As this design may change, implementation of this
  107.    document is not advised.   Obsoletes RFC-984.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Westine & Postel                                                [Page 2]
  115.  
  116. RFC 999                                                       March 1987
  117.  
  118.  
  119. 992     Birman       Nov 86      On Communication Support for
  120.                                  Fault-Tolerant Process Groups
  121.  
  122.    This memo describes a collection of multicast communication primitives
  123.    integrated with a mechanism for handling process failure and recovery.
  124.    These primitives facilitate the implementation of fault-tolerant process
  125.    groups, which can be used to provide distributed services in an
  126.    environment subject to non-malicious crash failures.
  127.  
  128. 991     Reynolds     Nov 86      Official ARPA-Internet Protocols
  129.  
  130.    This RFC identifies the documents specifying the official protocols used
  131.    in the Internet.  Comments indicate any revisions or changes planned.
  132.    This memo is an official status report on the numbers used in protocols
  133.    in the ARPA-Internet community.  Obsoletes RFC-961, 944 and 924.
  134.  
  135. 990     Reynolds     Nov 86      Assigned Numbers
  136.  
  137.    This Network Working Group Request for Comments documents the currently
  138.    assigned values from several series of numbers used in network protocol
  139.    implementations.  This memo is an official status report on the numbers
  140.    used in protocols in the ARPA-Internet community.  See RFC-997.  Obsoletes
  141.    RFC-960, 943, 923 and 900.
  142.  
  143. 989     Linn         Feb 87      Privacy Enhancement for Internet
  144.                                  Electronic Mail:  Part I:  Message
  145.                                  Encipherment and Authentication
  146.                                  Procedures
  147.  
  148.    This RFC suggests a proposed protocol for the Internet community and
  149.    requests discussion and suggestions for improvements.  This RFC is the
  150.    outgrowth of a series of IAB Privacy Task Force meetings and of internal
  151.    working papers distributed for those meetings.  This RFC defines message
  152.    encipherment and authentication procedures, as the initial phase of an
  153.    effort to provide privacy enhancement services for electronic mail
  154.    transfer in the Internet. It is intended that the procedures defined
  155.    here be compatible with a wide range of key management approaches,
  156.    including both conventional (symmetric) and public-key (asymmetric)
  157.    approaches for encryption of data encrypting keys.  Use of conventional
  158.    cryptography for message text encryption and/or authentication is
  159.    anticipated.
  160.  
  161. 988     Deering      Jul 86      Host Extensions for IP Multicasting
  162.  
  163.    This memo specifies the extensions required of a host implementation of
  164.    the Internet Protocol (IP) to support internetwork multicasting.  This
  165.    specification supersedes that given in RFC-966, and constitutes a
  166.    proposed protocol standard for IP multicasting in the ARPA-Internet.
  167.    The reader is directed to RFC-966 for a discussion of the motivation and
  168.    rationale behind the multicasting extension specified here.
  169.  
  170.  
  171.  
  172.  
  173. Westine & Postel                                                [Page 3]
  174.  
  175. RFC 999                                                       March 1987
  176.  
  177.  
  178. 987     Kille        Jun 86      Mapping between X.400 and RFC-822
  179.  
  180.    The X.400 series protocols have been defined by CCITT to provide an
  181.    Interpersonal Messaging Service (IPMS), making use of a store and
  182.    forward Message Transfer Service.  It is expected that this standard
  183.    will be implemented very widely.  This document describes a set of
  184.    mappings which will enable interworking between systems operating the
  185.    X.400 protocols and systems using RFC-822 mail protocol or protocols
  186.    derived from RFC-822.  This RFC suggests a proposed protocol for the
  187.    ARPA-Internet community, and requests discussion and suggestions for
  188.    improvements.
  189.  
  190. 986     Callon       Jun 86      Working Draft -- Guidelines for the Use
  191.                                  of Internet-IP addressing in the ISO
  192.                                  Connectionless-Mode Network Protocol
  193.  
  194.    This RFC suggests a method to allow the existing IP addressing,
  195.    including the IP protocol field, to be used for the ISO Connectionless
  196.    Network Protocol (CLNP).  This is a draft solution to one of the
  197.    problems inherent in the use of "ISO-grams" in the DOD Internet.
  198.    Related issues will be discussed in subsequent RFCs.  This RFC suggests
  199.    a proposed protocol for the ARPA-Internet community, and requests
  200.    discussion and suggestions for improvements.
  201.  
  202. 985     Mills        May 86      Requirements for Internet Gateways
  203.  
  204.    This RFC summarizes the requirements for gateways to be used on networks
  205.    supporting the DARPA Internet protocols.  While it applies specifically
  206.    to National Science Foundation research programs, the requirements are
  207.    stated in a general context and are believed applicable throughout the
  208.    Internet community.  The purpose of this document is to present guidance
  209.    for vendors offering products that might be used or adapted for use in
  210.    an Internet application.  It enumerates the protocols required and gives
  211.    references to RFCs and other documents describing the current
  212.    specification.
  213.  
  214. 984     Clark        May 86      PCMAIL: A Distributed Mail System for
  215.                                  Personal Computers
  216.  
  217.    This document is a preliminary discussion of the design of a
  218.    personal-computer-based distributed mail system.  Pcmail is a
  219.    distributed mail system that provides mail service to an arbitrary
  220.    number of users, each of which owns one or more personal computers
  221.    (PCs).  The system is divided into two halves.  The first consists of a
  222.    single entity called the "repository".  The repository is a storage
  223.    center for incoming mail.  Mail for a Pcmail user can arrive externally
  224.    from the Internet or internally from other repository users.  The
  225.    repository also maintains a stable copy of each user's mail state.  The
  226.    repository is therefore typically a computer with a large amount of disk
  227.    storage. It is published for discussion and comment, and does not
  228.    constitute a standard.  As the proposal may change, implementation of
  229.    this document is not advised.   See RFC-993.
  230.  
  231.  
  232. Westine & Postel                                                [Page 4]
  233.  
  234. RFC 999                                                       March 1987
  235.  
  236.  
  237. 983     Cass         Apr 86      ISO Transport Services on Top of the
  238.                                  TCP
  239.  
  240.    This memo describes a proposed protocol standard for the ARPA Internet
  241.    community.  The CCITT and the ISO have defined various session,
  242.    presentation, and application recommendations which have been adopted by
  243.    the international community and numerous vendors.  To the largest extent
  244.    possible, it is desirable to offer these higher level services directly
  245.    in the ARPA Internet, without disrupting existing facilities.  This
  246.    permits users to develop expertise with ISO and CCITT applications which
  247.    previously were not available in the ARPA Internet.  The intention is
  248.    that hosts in the ARPA-Internet that choose to implement ISO TSAP
  249.    services on top of the TCP be expected to adopt and implement this
  250.    standard.  Suggestions for improvement are encouraged.
  251.  
  252. 982     ANSI         Apr 86      Guidelines for the Specification of the
  253.                                  Structure of the Domain Specific Part
  254.                                  (DSP) of the ISO Standard NSAP Address
  255.  
  256.    This RFC is a draft working document of the ANSI "Guidelines for the
  257.    Specification of the Structure of the Domain Specific Part (DSP) of the
  258.    ISO Standard NSAP Address".  It provides guidance to private address
  259.    administration authorities on preferred formats and semantics for the
  260.    Domain Specific Part (DSP) of an NSAP address.  This RFC specifies the
  261.    way in which the DSP may be constructed so as to facilitate efficient
  262.    address assignment.  This RFC is for informational purposes only and its
  263.    distribution is unlimited and does not specify a standard of the
  264.    ARPA-Internet.
  265.  
  266. 981     Mills        Mar 86      An Experimental Multiple-Path Routing
  267.                                  Algorithm
  268.  
  269.    This document introduces wiretap algorithms, a class of experimental,
  270.    multiple routing algorithms that compute quasi-optimum routes for
  271.    stations sharing a packet-radio broadcast channel.  The primary route (a
  272.    minimum-distance path), and additional paths ordered by distance, which
  273.    serve as alternate routes should the primary route fail, are computed.
  274.    This prototype is presented as an example of a class of routing
  275.    algorithms and data-base management techniques that may find wider
  276.    application in the Internet community.  Discussions and suggestions for
  277.    improvements are welcomed.
  278.  
  279. 980     Jacobsen     Mar 86      Protocol Document Order Information
  280.  
  281.    This RFC indicates how to obtain various protocol documents used in the
  282.    DARPA research community.  Included is an overview of the new 1985 DDN
  283.    Protocol Handbook and available sources for obtaining related documents
  284.    (such as DOD, ISO, and CCITT).
  285.  
  286.  
  287.  
  289.  
  290. Westine & Postel                                                [Page 5]
  291.  
  292. RFC 999                                                       March 1987
  293.  
  294.  
  295. 979     Malis        Mar 86      PSN End-to-End Functional Specification
  296.  
  297.    This memo is an updated version of BBN Report 5775, "End-to-End
  298.    Functional Specification and describes important changes to the
  299.    functionality of the interface between a Host and the PSN, and should be
  300.    carefully reviewed by anyone involved in supporting a host on either the
  301.    ARPANET or MILNET".  The new End-to-End protocol (EE) is being developed
  302.    in order to correct a number of deficiencies in the old EE, to improve
  303.    its performance and overall throughput, and to better equip the Packet
  304.    Switch Node (PSN, also known as the IMP) to support its current and
  305.    anticipated host population.
  306.  
  307. 978     Reynolds     Feb 86      Voice File Interchange Protocol (VFIP)
  308.  
  309.    The purpose of the Voice File Interchange Protocol (VFIP) is to permit
  310.    the interchange of various types of speech files between different
  311.    systems in the ARPA-Internet community.  Suggestions for improvement are
  312.    encouraged.
  313.  
  314. 977     Kantor       Feb 86      Network News Transfer Protocol
  315.  
  316.    NNTP specifies a protocol for the distribution, inquiry, retrieval, and
  317.    posting of news articles using a reliable stream-based transmission of
  318.    news among the ARPA-Internet community.  NNTP is designed so that news
  319.    articles are stored in a central database allowing a subscriber to
  320.    select only those items he wishes to read.  Indexing, cross-referencing,
  321.    and expiration of aged messages are also provided. This RFC suggests a
  322.    proposed protocol for the ARPA-Internet community, and requests
  323.    discussion and suggestions for improvements.
  324.  
  325. 976     Horton       Feb 86      UUCP Mail Interchange Format Standard
  326.  
  327.    This document defines the standard format for the transmission of mail
  328.    messages between computers in the UUCP Project.  It does not however,
  329.    address the format for storage of messages on one machine, nor the lower
  330.    level transport mechanisms used to get the date from one machine to the
  331.    next.  It represents a standard for conformance by hosts in the UUCP
  332.    zone.
  333.  
  334. 975     Mills        Feb 86      Autonomous Confederations
  335.  
  336.    This RFC proposes enhancements to the Exterior Gateway Protocol (EGP) to
  337.    support a simple, multiple-level routing capability while preserving the
  338.    robustness features of the current EGP model.  The enhancements
  339.    generalize the concept of core system to include multiple communities of
  340.    autonomous systems, called autonomous confederations.  Discussion and
  341.    suggestions for improvement are requested.
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349. Westine & Postel                                                [Page 6]
  350.  
  351. RFC 999                                                       March 1987
  352.  
  353.  
  354. 974     Partridge    Jan 86      Mail Routing and the Domain System
  355.  
  356.    This RFC presents a description of how mail systems on the Internet are
  357.    expected to route messages based on information from the domain system.
  358.    This involves a discussion of how mailers interpret MX RRs, which are
  359.    used for message routing.
  360.  
  361. 973     Mockapetris  Jan 86      Domain System Changes and Observations
  362.  
  363.    This RFC documents updates to Domain Name System specifications RFC-882
  364.    and RFC-883, suggests some operational guidelines, and discusses some
  365.    experiences and problem areas in the present system.
  366.  
  367. 972     Wancho       Jan 86      Password Generator Protocol
  368.  
  369.    This RFC specifies a standard for the ARPA Internet community.  The
  370.    Password Generator Service (PWDGEN) provides a set of six randomly
  371.    generated eight-character "words" with a reasonable level of
  372.    pronounceability, using a multi-level algorithm.  Hosts on the ARPA
  373.    Internet that choose to implement a password generator service are
  374.    expected to adopt and implement this standard.
  375.  
  376. 971     DeSchon      Dec 85      A Survey of Data Representation
  377.                                  Standards
  378.  
  379.    This RFC is a comparison of several data representation standards that
  380.    are currently in use.  The standards discussed are the CCITT X.409
  381.    recommendation, the NBS Computer Based Message System (CBMS) standard,
  382.    DARPA Multimedia Mail system, the Courier remote procedure call
  383.    protocol, and the SUN Remote Procedure Call package.  No proposals in
  384.    this document are intended as standards for the ARPA-Internet at this
  385.    time.  Rather, it is hoped that a general consensus will emerge as to
  386.    the appropriate approach to a data representation standard, leading
  387.    eventually to the adoption of an ARPA-Internet standard.
  388.  
  389. 970     Nagle        Dec 85      On Packet Switches With Infinite
  390.                                  Storage
  391.  
  392.    The purpose of this RFC is to focus discussion on a particular problem
  393.    in the ARPA-Internet and possible methods of solution.  Most prior work
  394.    on congestion in datagram systems focuses on buffer management.  In this
  395.    memo the case of a packet switch with infinite storage is considered.
  396.    Such a packet switch can never run out of buffers.  It can, however,
  397.    still become congested.  The meaning of congestion in an
  398.    infinite-storage system is explored.  An unexpected result is found that
  399.    shows a datagram network with infinite storage, first-in-first-out
  400.    queuing, at least two packet switches, and a finite packet lifetime
  401.    will, under overload, drop all packets.  By attacking the problem of
  402.    congestion for the infinite-storage case, new solutions applicable to
  403.    switches with finite storage may be found.  No proposed solutions this
  404.    document are intended as standards for the ARPA-Internet at this time.
  405.  
  406.  
  407.  
  408. Westine & Postel                                                [Page 7]
  409.  
  410. RFC 999                                                       March 1987
  411.  
  412.  
  413. 969     Clark        Dec 85      NETBLT: A Bulk Data Transfer Protocol
  414.  
  415.    This RFC suggests a proposed protocol for the ARPA-Internet community,
  416.    and requests discussion and suggestions for improvements.  This is a
  417.    preliminary discussion of the Network Block Transfer (NETBLT) protocol.
  418.    NETBLT is intended for the rapid transfer of a large quantity of data
  419.    between computers.  It provides a transfer that is reliable and flow
  420.    controlled, and is structured to provide maximum throughput over a wide
  421.    variety of networks.  This description is published for discussion and
  422.    comment, and does not constitute a standard.  As the proposal may
  423.    change, implementation of this document is not advised.  See RFC-998.
  424.  
  425. 968     Cerf         Dec 85      'Twas the Night Before Start-up'
  426.  
  427.    This memo discusses problems that arise and debugging techniques used in
  428.    bringing a new network into operation.
  429.  
  430. 967     Padlipsky    Dec 85      All Victims Together
  431.  
  432.    This RFC proposes a new set of RFCs on how the networking code is
  433.    integrated with various operating systems.  It appears that this topic
  434.    has not received enough exposure in the literature. Comments and
  435.    suggestions are encouraged.
  436.  
  437. 966     Deering      Dec 85      A Multicast Extension to the Internet
  438.                                  Protocol
  439.  
  440.    This RFC defines a model of service for Internet multicasting and
  441.    proposes an extension to the Internet Protocol (IP) to support such a
  442.    multicast service.  Discussion and suggestions for improvements are
  443.    requested.  See RFC-988.
  444.  
  445. 965     Aguilar      Dec 85      A Format for a Graphical Communication
  446.                                  Protocol
  447.  
  448.    This RFC describes the requirements for a graphical format on which to
  449.    base a graphical on-line communication protocol, and proposes an
  450.    Interactive Graphical Communication Format using the GKSM session
  451.    metafile.  We hope this contribution will encourage the discussion of
  452.    multimedia data exchange and the proposal of solutions.
  453.  
  454. 964     Sidhu        Nov 85      Some Problems with the Specification of
  455.                                  the Military Standard Transmission
  456.                                  Control Protocol
  457.  
  458.    The purpose of this RFC is to provide helpful information on the
  459.    Military Standard Transmission Control Protocol (MIL-STD-1778) so that
  460.    one can obtain a reliable implementation of this protocol standard.
  461.    This note points out three errors with this specification.  This note
  462.    also proposes solutions to these problems.
  463.  
  464.  
  465.  
  466.  
  467. Westine & Postel                                                [Page 8]
  468.  
  469. RFC 999                                                       March 1987
  470.  
  471.  
  472. 963     Sidhu        Nov 85      Some Problems with the Specification of
  473.                                  the Military Standard Internet Protocol
  474.  
  475.    The purpose of this RFC is to provide helpful information on the
  476.    Military Standard Internet Protocol (MIL-STD-1777) so that one can
  477.    obtain a reliable implementation of this protocol.  This paper points
  478.    out several problems in this specification.  This note also proposes
  479.    solutions to these problems.
  480.  
  481. 962     Padlipsky    Nov 85      TCP-4 Prime
  482.  
  483.    This memo is in response to Bob Braden's call for a transaction oriented
  484.    protocol (RFC-955), and continues the discussion of a possible
  485.    transaction oriented transport protocol.  This memo does not propose a
  486.    standard.
  487.  
  488. 961     Reynolds     Dec 85      Official ARPA-Internet Protocols
  489.  
  490.    This memo identifies the documents specifying the official protocols
  491.    used in the Internet, and comments on any revisions or changes planned.
  492.    This edition of the Official Protocols updates and obsoletes RFC-944.
  493.    This memo is an official status report on the protocols used in the
  494.    ARPA-Internet community.  See RFC-991.
  495.  
  496. 960     Reynolds     Dec 85      Assigned Numbers
  497.  
  498.    This memo documents the currently assigned values from several series of
  499.    numbers used in network protocol implementations.  This edition of
  500.    Assigned Numbers updates and obsoletes RFC-943.  This memo is an
  501.    official status report on the numbers used in protocols in the
  502.    ARPA-Internet community.  See RFC-990 and 997.
  503.  
  504. 959     Postel       Oct 85      File Transfer Protocol (FTP)
  505.  
  506.    This memo is the official specification of the File Transfer Protocol
  507.    (FTP) for the DARPA Internet community.  The primary intent is to
  508.    clarify and correct the documentation of the FTP specification, not to
  509.    change the protocol.  The following new optional commands are included
  510.    in this edition of the specification:  Change to Parent Directory
  511.    (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove Directory
  512.    (RMD), Make Directory (MKD), Print Directory (PWD), and System (SYST).
  513.    Note that this specification is compatible with the previous edition.
  514.  
  515. 958     Mills        Sep 85      Network Time Protocol (NTP)
  516.  
  517.    This document describes the Network Time Protocol (NTP), a protocol for
  518.    synchronizing a set of network clocks using a set of distributed clients
  519.    and servers.  NTP is built on the User Datagram Protocol (UDP), which
  520.    provides a connectionless transport mechanism.  It is evolved from the
  521.    Time Protocol and the ICMP Timestamp message and is a suitable
  522.    replacement for both.  This RFC suggests a proposed protocol for the
  523.  
  524.  
  525.  
  526. Westine & Postel                                                [Page 9]
  527.  
  528. RFC 999                                                       March 1987
  529.  
  530.  
  531.    ARPA-Internet community, and requests discussion and suggestions for
  532.    improvements.
  533.  
  534. 957     Mills        Sep 85      Experiments in Network Clock
  535.                                  Synchronization
  536.  
  537.    This RFC discusses some experiments in clock synchronization in the
  538.    ARPA-Internet community, and requests discussion and suggestions for
  539.    improvements.  One of the services frequently neglected in computer
  540.    network design is a high-quality, time-of-day clock capable of
  541.    generating accurate timestamps with small errors compared to one-way
  542.    network delays.  Such a service would be useful for tracing the progress
  543.    of complex transactions, synchronizing cached data bases, monitoring
  544.    network performance and isolating problems.  In this memo one such clock
  545.    service design will be described and its performance assessed.  This
  546.    design has been incorporated as an integral part of the network routing
  547.    and control protocols of the Distributed Computer Network (DCnet)
  548.    architecture.
  549.  
  550. 956     Mills        Sep 85      Algorithms for Synchronizing Network
  551.                                  Clocks
  552.  
  553.    This RFC discussed clock synchronization algorithms for the
  554.    ARPA-Internet community, and requests discussion and suggestions for
  555.    improvements.  The recent interest within the Internet community in
  556.    determining accurate time from a set of mutually suspicious network
  557.    clocks has been prompted by several occasions in which errors were found
  558.    in usually reliable, accurate clock servers after thunderstorms which
  559.    disrupted their power supply.  To these sources of error should be added
  560.    those due to malfunctioning hardware, defective software and operator
  561.    mistakes, as well as random errors in the mechanism used to set and
  562.    synchronize clocks.  This report suggests a stochastic model and
  563.    algorithms for computing a good estimator from time-offset samples
  564.    measured between clocks connected via network links.  Included in this
  565.    report are descriptions of certain experiments which give an indication
  566.    of the effectiveness of the algorithms.
  567.  
  568. 955     Braden       Sep 85      Towards a Transport Service for
  569.                                  Transaction Processing Applications
  570.  
  571.    The DoD Internet protocol suite includes two alternative transport
  572.    service protocols, TCP and UDP, which provide virtual circuit and
  573.    datagram service, respectively.  These two protocols represent points in
  574.    the space of possible transport service attributes which are quite "far
  575.    apart".  We want to examine an important class of applications, those
  576.    which perform what is often called "transaction processing".  We will
  577.    see that the communication needs for these applications fall into the
  578.    gap "between" TCP and UDP -- neither protocol is very appropriate.
  579.    This RFC is concerned with the possible design of one or more new
  580.    protocols for the ARPA-Internet, to support kinds of applications which
  581.    are not well supported at present.  The RFC is intended to spur
  582.  
  583.  
  584.  
  585. Westine & Postel                                               [Page 10]
  586.  
  587. RFC 999                                                       March 1987
  588.  
  589.  
  590.    discussion in the Internet research community towards the development of
  591.    new protocols and/or concepts, in order to meet these unmet application
  592.    requirements.  It does not represent a standard, nor even a concrete
  593.    protocol proposal.
  594.  
  595. 954     Harrenstien  Oct 85      NICNAME/WHOIS
  596.  
  597.    This RFC is the official specification of the NICNAME/WHOIS protocol.
  598.    This memo describes the protocol and the service.  This is an update of
  599.    RFC-812.
  600.  
  601. 953     Harrenstien  Oct 85      Hostname Server
  602.  
  603.    This RFC is the official specification of the Hostname Server Protocol.
  604.    This edition of the specification includes minor revisions to RFC-811
  605.    which brings it up to date.
  606.  
  607. 952     Harrenstien  Oct 85      DoD Internet Host Table Specification
  608.  
  609.    This RFC is the official specification of the format of the Internet
  610.    Host Table.  This edition of the specification includes minor revisions
  611.    to RFC-810 which brings it up to date.
  612.  
  613. 951     Croft        Sep 85      Bootstrap Protocol (BOOTP)
  614.  
  615.    This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a
  616.    diskless client machine to discover its own IP address, the address of a
  617.    server host, and the name of a file to be loaded into memory and
  618.    executed.  The bootstrap operation can be thought of as consisting of
  619.    TWO PHASES.  This RFC describes the first phase, which could be labeled
  620.    `address determination and bootfile selection'.  After this address and
  621.    filename information is obtained, control passes to the second phase of
  622.    the bootstrap where a file transfer occurs.  The file transfer will
  623.    typically use the TFTP protocol, since it is intended that both phases
  624.    reside in PROM on the client.  However BOOTP could also work with other
  625.    protocols such as SFTP or FTP.  This RFC suggests a proposed protocol
  626.    for the ARPA-Internet community, and requests discussion and suggestions
  627.    for improvements.
  628.  
  629. 950     Mogul        Aug 85      Internet Standard Subnetting Procedure
  630.  
  631.    This memo discusses the utility of "subnets" of Internet networks, which
  632.    are logically visible sub-sections of a single Internet network.  For
  633.    administrative or technical reasons, many organizations have chosen to
  634.    divide one Internet network into several subnets, instead of acquiring a
  635.    set of Internet network numbers.  This memo specifies procedures for the
  636.    use of subnets.  These procedures are for hosts (e.g., workstations).
  637.    The procedures used in and between subnet gateways are not fully
  638.    described.  Important motivation and background information for a
  639.    subnetting standard is provided in RFC-940.  This RFC specifies a
  640.    protocol for the ARPA-Internet community.  If subnetting is implemented
  641.    it is strongly recommended that these procedures be followed.
  642.  
  643.  
  644. Westine & Postel                                               [Page 11]
  645.  
  646. RFC 999                                                       March 1987
  647.  
  648.  
  649. 949     Padlipsky    Jul 85      FTP Unique-Named Store Command
  650.  
  651.    There are various contexts in which it would be desirable to have an FTP
  652.    command that had the effect of the present STOR but rather than
  653.    requiring the sender to specify a file name istead caused the resultant
  654.    file to have a unique name relative to the current directory.  This
  655.    RFC proposes an extension to the File Transfer Protocol for the
  656.    ARPA-Internet community, and requests discussion and suggestions for
  657.    improvements.  See RFC-959.
  658.  
  659. 948     Winston      Jun 85      Two Methods for the Transmission of IP
  660.                                  Datagrams Over IEEE 802.3 Networks
  661.  
  662.    This RFC describes two methods of encapsulating Internet Protocol (IP)
  663.    datagrams on an IEEE 802.3 network.  This RFC suggests a proposed protocol
  664.    for the ARPA-Internet community, and requests discussion and suggestions
  665.    for improvements.
  666.  
  667. 947     Lebowitz     Jun 85      Multi-Network Broadcasting Within the
  668.                                  Internet
  669.  
  670.    This RFC describes the extension of a network's broadcast domain to
  671.    include more than one physical network through the use of a broadcast
  672.    packet repeater.
  673.  
  674. 946     Nedved       May 85      Telnet Terminal Location Number Option
  675.  
  676.    Many systems provide a mechanism for finding out where a user is logged
  677.    in from usually including information about telephone extension and
  678.    office occupants names.  The information is useful for physically
  679.    locating people and/or calling them on the phone.  In 1982 CMU designed
  680.    and implemented a terminal location database and modified existing
  681.    network software to handle a 64-bit number called the Terminal Location
  682.    Number (or TTYLOC).  It now seems appropriate to incorporate this
  683.    mechanism into the TCP-based network protocol family.  The mechanism is
  684.    not viewed as a replacement for the Terminal Location Telnet Option
  685.    (SEND-LOCATION) but as a shorthand mechansim for communicating terminal
  686.    location information between hosts in a localized community.  This RFC
  687.    proposes a new option for Telnet for the ARPA-Internet community, and
  688.    requests discussion and suggestions for improvements.
  689.  
  690. 945     Postel       May 85      A DoD Statement on the NRC Report
  691.  
  692.    In May 1983 the National Research Council (NRC) was asked jointly by DoD
  693.    and NBS to study the issues and recommend a course of action.  The final
  694.    report of the NRC committee was published in February 1985 (see
  695.    RFC-942). The enclosed letter is from Donald C. Latham (ASDC3I) to DCA
  696.    transmitting the NRC report and requesting specific actions relative to
  697.    the recommendations of the report.  This RFC reproduces a letter from the
  698.    Assistant Secretary of Defense for Command, Control, Communications, and
  699.    Intelligence (ASDC3I) to the Director of the Defense Communications Agency
  700.    (DCA).  This letter is distributed for information only.
  701.  
  702.  
  703. Westine & Postel                                               [Page 12]
  704.  
  705. RFC 999                                                       March 1987
  706.  
  707.  
  708. 944     Reynolds    Apr 85      Official ARPA-Internet Protocols
  709.  
  710.    This RFC identifies the documents specifying the official protocols used
  711.    in the Internet.  This edition of Official ARPA-Internet Protocols
  712.    obsoletes RFC-924 and earlier editions.  This RFC will be updated
  713.    periodically, and current information can be obtained from Joyce Reynolds.
  714.    This memo is an official status report on the protocols used in the
  715.    ARPA-Internet community.  See RFC-991.
  716.  
  717. 943     Reynolds     Apr 85      Assigned Network Numbers
  718.  
  719.    This Network Working Group Request for Comments documents the currently
  720.    assigned values from several series of numbers used in network protocol
  721.    implementations.  This RFC will be updated periodically, and in any case
  722.    current information can be obtained from Joyce Reynolds.  The assignment
  723.    of numbers is also handled by Joyce.  If you are developing a protocol
  724.    or application that will require the use of a link, socket, port,
  725.    protocol, network number, etc., please contact Joyce to receive a number
  726.    assignment.  This memo is an official status report on the numbers used
  727.    in protocols in the ARPA-Internet community. See RFC-990 and 997.
  728.  
  729. 942     NRC          Feb 85      Transport Protocols for Department of
  730.                                  Defense Data Networks
  731.  
  732.    This RFC reproduces the National Research Council report resulting from
  733.    a study of the DoD Internet Protocol (IP) and Transmission Control
  734.    Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and
  735.    Transport Protocol level 4 (TP-4).
  736.  
  737. 941     ISO          Apr 85      Addendum to the Network Service
  738.                                  Definition Covering Network Layer
  739.                                  Addressing
  740.  
  741.    This Addendum to the Network Service Definition Standard, ISO 8348,
  742.    defines the abstract syntax and semantics of the Network Address
  743.    (Network Service Access Point Address).  The Network Address defined in
  744.    this Addendum is the address that appears in the primitives of the
  745.    connection-mode Network Service as the calling address, called address,
  746.    and responding address parameters, and in the primitives of the
  747.    connectionless-mode  Network  Service  as  the source address and
  748.    destination address parameters.  This document is distributed as an RFC
  749.    for information only.  It does not specify a standard for the ARPA-Internet.
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  760.  
  761. Westine & Postel                                               [Page 13]
  762.  
  763. RFC 999                                                       March 1987
  764.  
  765.  
  766. 940     GADS         Apr 85      Toward an Internet Standard Scheme for
  767.                                  Subnetting
  768.  
  769.    Several sites now contain a complex of local links connected to the
  770.    Internet via a gateway.  The details of the internal connectivity are of
  771.    little interest to the rest of the Internet.  One way of organizing
  772.    these local complexes of links is to use the same strategy as the
  773.    Internet uses to organize networks, that is, to declare each link to be
  774.    an entity (like a network) and to interconnect the links with devices
  775.    that perform routing functions (like gateways).  This general scheme is
  776.    called subnetting, the individual links are called subnets, and the
  777.    connecting devices are called subgateways (or bridges, or gateways).
  778.    This RFC discusses standardizing the protocol used in subnetted
  779.    environments in the ARPA-Internet.
  780.  
  781. 939     NRC          Feb 85      Executive Summary of the NRC Report on
  782.                                  Transport Protocols for Department of
  783.                                  Defense Data Networks
  784.  
  785.    This RFC reproduces the material from the "front pages" of the National
  786.    Research Council report resulting from a study of the DOD Internet
  787.    Protocol (IP) and Transmission Control Protocol (TCP) in comparison with
  788.    the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4
  789.    (TP-4).  The point of this RFC is to make the text of the Executive
  790.    Summary widely available in a timely way.  The order of presentation has
  791.    been altered, and the pagination changed.  This RFC is distributed for
  792.    information only.  This RFC does not establish any policy for the DARPA
  793.    research community or the DDN operational community.
  794.  
  795. 938     Miller       Feb 85      Internet Reliable Transaction Protocol
  796.                                  Functional and Interface Specification
  797.  
  798.    This RFC is being distributed to members of the DARPA research community
  799.    in order to solicit their reactions to the proposals contained in it.
  800.    While the issues discussed may not be directly relevant to the research
  801.    problems of the DARPA community, they may be interesting to a number of
  802.    researchers and implementors.  This RFC suggests a proposed protocol for
  803.    the ARPA-Internet community, and requests discussion and suggestions for
  804.    improvements.
  805.  
  806. 937     Reynolds     Feb 85      Post Office Protocol - Version 2
  807.  
  808.    This RFC suggests a simple method for workstations to dynamically access
  809.    mail from a mailbox server.  This RFC specifies a proposed protocol for
  810.    the ARPA-Internet community, and requests discussion and suggestions for
  811.    improvement.  This memo is a revision of RFC-918.
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820. Westine & Postel                                               [Page 14]
  821.  
  822. RFC 999                                                       March 1987
  823.  
  824.  
  825. 936     Karels       Feb 85      Another Internet Subnet Addressing
  826.                                  Scheme
  827.  
  828.    There have been several proposals for schemes to allow the use of a
  829.    single Internet network number to refer to a collection of physical
  830.    networks under common administration which are reachable from the rest
  831.    of the Internet by a common route.  Such schemes allow a simplified view
  832.    of an otherwise complicated topology from hosts and gateways outside of
  833.    this collection.  They allow the complexity of the number and  type of
  834.    these networks, and routing to them, to be localized.  Additions and
  835.    changes in configuration thus cause no detectable change, and no
  836.    interruption of service, due to slow propagation of routing and other
  837.    information outside of the local environment.  These schemes also
  838.    simplify the administration of the network, as changes do not require
  839.    allocation of new network numbers for each new cable installed.  This
  840.    proposal discusses an alternative scheme, one that has been in use at
  841.    the University of California, Berkeley since April 1984.  This RFC
  842.    suggests a proposed protocol for the ARPA-Internet community, and
  843.    requests discussion and suggestions for improvements.
  844.  
  845. 935     Robinson     Jan 85      Reliable Link Layer Protocols
  846.  
  847.    This RFC discusses protocols proposed recently in RFCs 914 and 916, and
  848.    suggests a proposed protocol that could meet the same needs addressed in
  849.    those memos.  The stated need is reliable communication between two
  850.    programs over a full-duplex, point-to-point communication link, and in
  851.    particular the RFCs address the need for such communication over an
  852.    asynchronous link at relatively low speeds. The suggested protocol uses
  853.    the methods of existing national and international data link layer
  854.    standards.  This RFC suggests a proposed protocol for the ARPA-Internet
  855.    community, and requests discussion and suggestions for improvements.
  856.  
  857. 934     Rose         Jan 85      Proposed Standard for Message
  858.                                  Encapsulation
  859.  
  860.    This memo concerns itself with message forwarding.  Forwarding can be
  861.    thought of as encapsulating one or more messages inside another.
  862.    Although this is useful for transfer of past correspondence to new
  863.    recipients, without a decapsulation process (which this memo terms
  864.    "bursting"), the forwarded messages are of little use to the recipients
  865.    because they can not be distributed, forwarded, replied-to, or otherwise
  866.    processed as separate individual messages. In order to burst a message
  867.    it is necessary to know how the component messages were encapsulated in
  868.    the draft.  At present there is no unambiguous standard for interest
  869.    group digests.  This RFC proposes a proposed protocol for the
  870.    ARPA-Internet community, and requests discussion and suggestions for
  871.    improvements.
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879. Westine & Postel                                               [Page 15]
  880.  
  881. RFC 999                                                       March 1987
  882.  
  883.  
  884. 933     Silverman    Jan 85      Output Marking Telnet Option
  885.  
  886.    This proposed option would allow a Server-Telnet to send a banner to a
  887.    User-Telnet so that this banner would be displayed on the workstation
  888.    screen independently of the application software running in the
  889.    Server-Telnet.
  890.  
  891. 932     Clark        Jan 85      A Subnetwork Addressing Scheme
  892.  
  893.    This RFC proposes an alternative addressing scheme for subnets which, in
  894.    most cases, requires no modification to host software whatsoever.  The
  895.    drawbacks of this scheme are that the total number of subnets in any one
  896.    network are limited, and that modification is required to all gateways.
  897.  
  898. 931     StJohns      Jan 85      Authentication Server
  899.  
  900.    This RFC suggests a proposed protocol for the ARPA-Internet community,
  901.    and requests discussion and suggestions for improvements.  This is the
  902.    second draft of this proposal (superseding RFC-912) and incorporates a
  903.    more formal description of the syntax for the request and response
  904.    dialog, as well as a change to specify the type of user identification
  905.    returned.
  906.  
  907. 930     Solomon      Jan 85      Telnet Terminal Type Option
  908.  
  909.    This RFC specifies a standard for the ARPA Internet community.  Hosts on
  910.    the ARPA Internet that exchange terminal type information within the
  911.    Telnet protocol are expected to adopt and implement this standard.  This
  912.    standard supersedes RFC-884.  The only change is to specify that the
  913.    TERMINAL-TYPE IS sub-negotiation should be sent only in response to the
  914.    TERMINAL-TYPE SEND sub-negotiation.
  915.  
  916. 929     Lilienkamp   Dec 84      Proposed Host-Front End Protocol
  917.  
  918.    The Host-Front End Protocol introduced in RFC-928 is described in detail
  919.    in this memo.  The first order of business is to declare that THIS IS A
  920.    PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to
  921.    request that any readers of these documents who are able to do test
  922.    implementations (a) do so and (b) coordinate their efforts with the author.
  923.    This RFC suggests a proposed protocol for the ARPA-Internet community, and
  924.    requests discussion and suggestions for improvements.
  925.  
  926. 928     Padlipsky    Dec 84      Introduction to Proposed DOD Standard
  927.                                  H-FP
  928.  
  929.    The broad outline of the Host-Front End Protocol introduced here and
  930.    described in RFC-929 is the result of the deliberations of a number of
  931.    experienced H-FP designers, who sat as a committee of the DoD Protocol
  932.    Standards Technical Panel.  It is the intent of the designers that the
  933.    protocol be subjected to multiple test implementations and probable
  934.    iteration before being agreed upon as any sort of "standard".
  935.  
  936.  
  937.  
  938. Westine & Postel                                               [Page 16]
  939.  
  940. RFC 999                                                       March 1987
  941.  
  942.  
  943.    Therefore, the first order of business is to declare that THIS IS A
  944.    PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to
  945.    request that any readers of these documents who are able to do test
  946.    implementations (a) do so and (b) coordinate their efforts with the
  947.    author.  This RFC suggests a proposed protocol for the ARPA-Internet
  948.    community, and requests discussion and suggestions for improvements.
  949.  
  950. 927     Anderson     Dec 84      TACACS User Identification Telnet
  951.                                  Option
  952.  
  953.    The following is the description of a TELNET option designed to
  954.    facilitate double login avoidance.  It is intended primarily for TAC
  955.    connections to target hosts on behalf of TAC users, but it can be used
  956.    between any two consenting hosts.  For example, all hosts at one site
  957.    (e.g., BBN) can use this option to avoid double login when TELNETing to
  958.    one another.  This RFC suggests a proposed protocol for the ARPA-Internet
  959.    community, and requests discussion and suggestions for improvements.
  960.  
  961. 926     ISO          Dec 84      Protocol for Providing the
  962.                                  Connectionless-Mode Network Services
  963.  
  964.    This note is the draft ISO protocol roughly similar to the DOD Internet
  965.    Protocol.  This document has been prepared by retyping the text of ISO
  966.    DIS 8473 of May 1984, which is currently undergoing voting within ISO as
  967.    a Draft International Standard (DIS).  This document is distributred as
  968.    an RFC for information only.  It does not specify a standard for the
  969.    ARPA-Internet.
  970.  
  971. 925     Postel       Oct 84      Multi-LAN Address Resolution
  972.  
  973.    The problem of treating a set of local area networks (LANs) as one
  974.    Internet network has generated some interest and concern.  It is
  975.    inappropriate to give each LAN within an site a distinct Internet
  976.    network number.  It is desirable to hide the details of the
  977.    interconnections between the LANs within an site from people, gateways,
  978.    and hosts outside the site.  The question arises on how to best do this,
  979.    and even how to do it at all.  In RFC-917 Jeffery Mogul makes a case for
  980.    the use of "explicit subnets" in a multi-LAN environment.  The explicit
  981.    subnet scheme is a call to recursively apply the mechanisms the Internet
  982.    uses to manage networks to the problem of managing LANs within one
  983.    network.  In this note I urge another approach: the use of "transparent
  984.    subnets" supported by a multi-LAN extension of the Address Resolution
  985.    Protocol.  This RFC suggests a proposed protocol for the ARPA-Internet
  986.    community, and requests discussion and suggestions for improvements.
  987.  
  988. 924     Reynolds     Oct 84      Official ARPA-Internet Protocols
  989.  
  990.    This RFC identifies the documents specifying the official protocols used
  991.    in the Internet.  This edition of Official ARPA-Internet Protocols
  992.    obsoletes RFC-900 and earlier editions.  This memo is an official status
  993.    report on the protocols used in the ARPA-Internet community.  See RFC-991.
  994.  
  995.  
  996.  
  997. Westine & Postel                                               [Page 17]
  998.  
  999. RFC 999                                                       March 1987
  1000.  
  1001.  
  1002. 923     Reynolds     Oct 84      Assigned Numbers
  1003.  
  1004.    This RFC documents the currently assigned values from several series of
  1005.    numbers used in network protocol implementations.  This edition of
  1006.    Assigned Numbers obsoletes RFC-900 and earlier editions.  This memo is
  1007.    an official status report on the numbers used in protocols in the
  1008.    ARPA-Internet community. See RFC-990, and 997.
  1009.  
  1010. 922     Mogul        Oct 84      Broadcasting Internet Datagrams in the
  1011.                                  Presence of Subnets
  1012.  
  1013.    We propose simple rules for broadcasting Internet datagrams on local
  1014.    networks that support broadcast, for addressing broadcasts, and for how
  1015.    gateways should handle them. This RFC suggests a proposed protocol for
  1016.    the ARPA-Internet community, and requests discussion and suggestions for
  1017.    improvements.
  1018.  
  1019. 921     Postel       Oct 84      Domain Name System Implementation
  1020.                                  Schedule - Revised
  1021.  
  1022.    This memo is a policy statement on the implementation of the Domain
  1023.    Style Naming System in the Internet.  This memo is an update of RFC-881,
  1024.    and RFC-897.  This is an official policy statement of the IAB and the
  1025.    DARPA.  The intent of this memo is to detail the schedule for the
  1026.    implementation for the Domain Style Naming System.  The explanation of
  1027.    how this system works is to be found in the references.
  1028.  
  1029. 920     Postel       Oct 84      Domain Requirements
  1030.  
  1031.    This memo states the requirements on establishing a Domain, and
  1032.    introduces the limited set of top level domains.  This memo is a policy
  1033.    statement on the requirements of establishing a new domain in the
  1034.    ARPA-Internet and the DARPA research community.  This is an official
  1035.    policy statement of the IAB and the DARPA.
  1036.  
  1037. 919     Mogul        Oct 84      Broadcasting Internet Datagrams
  1038.  
  1039.    This RFC proposes simple rules for broadcasting Internet datagrams on
  1040.    local networks that support broadcast, for addressing broadcasts, and
  1041.    for how gateways should handle them.  This RFC suggests a proposed
  1042.    protocol for the ARPA-Internet community, and requests discussion and
  1043.    suggestions for improvements.
  1044.  
  1045. 918     Reynolds     Oct 84      Post Office Protocol (POP)
  1046.  
  1047.    This RFC suggests a simple method for workstations to dynamically access
  1048.    mail from a mailbox server.  The intent of the Post Office Protocol
  1049.    (POP) is to allow a user's workstation to access mail from a mailbox
  1050.    server.  It is expected that mail will be posted from the workstation to
  1051.    the mailbox server via the Simple Mail Transfer Protocol (SMTP).  This
  1052.    RFC specifies a proposed protocol for the ARPA-Internet community, and
  1053.  
  1054.  
  1055.  
  1056. Westine & Postel                                               [Page 18]
  1057.  
  1058. RFC 999                                                       March 1987
  1059.  
  1060.  
  1061.    requests discussion and suggestions for improvement.  The status of this
  1062.    protocol is experimental, and this protocol is dependent upon TCP.
  1063.  
  1064. 917     Mogul        Oct 84      Internet Subnets
  1065.  
  1066.    This memo discusses subnets and proposes procedures for the use of
  1067.    subnets, including approaches to solving the problems that arise,
  1068.    particularly that of routing.  A subnet of an Internet network is a
  1069.    logically visible sub-section of a single Internet network.  For
  1070.    administrative or technical reasons, many organizations have chosen to
  1071.    divide one Internet network into several subnets, instead of acquiring a
  1072.    set of Internet network numbers.  This RFC suggests a proposed protocol
  1073.    for the ARPA-Internet community, and requests discussion and suggestions
  1074.    for improvements.
  1075.  
  1076. 916     Finn         Oct 84      Reliable Asynchronous Transfer Protocol
  1077.                                  (RATP)
  1078.  
  1079.    This RFC suggests a proposed protocol for the ARPA-Internet community,
  1080.    and requests discussion and suggestions for improvements. This paper
  1081.    proposes and specifies a protocol which allows two programs to reliably
  1082.    communicate over a communication link.  It ensures that the data entering
  1083.    one end of the link if received arrives at the other end intact and
  1084.    unaltered.  The protocol, named RATP, is designed to operate over a full
  1085.    duplex point-to-point connection.  It contains some features which tailor
  1086.    it to the RS-232 links now in common use.
  1087.  
  1088. 915     Elvy         Dec 84      Network Mail Path Service
  1089.  
  1090.    This RFC proposed a new service for the ARPA-Internet community and
  1091.    requests discussion and suggestions for improvements.  The network mail
  1092.    path service fills the current need of people to determine mailbox
  1093.    addresses for hosts that are not part of the ARPA-Internet but can be
  1094.    reached by one or more relay hosts that have Unix to Unix Copy (UUCP)
  1095.    mail, CSNET mail, MAILNET mail, BITNET mail, etc.  Anyone can use the
  1096.    service if they have TCP/TELENET to one of the hosts with a mail path server.
  1097.  
  1098. 914     Farber       Sep 84      A Thinwire Protocol
  1099.  
  1100.    This RFC focuses discussion on the particular problems in the
  1101.    ARPA-Internet of low speed network interconnection with personal
  1102.    computers, and possible methods of solution.  None of the proposed
  1103.    solutions in this document are intended as standards for the
  1104.    ARPA-Internet.  Rather, it is hoped that a general consensus will emerge
  1105.    as to the appropriate solution to the problems, leading eventually to
  1106.    the adoption of standards.
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115. Westine & Postel                                               [Page 19]
  1116.  
  1117. RFC 999                                                       March 1987
  1118.  
  1119.  
  1120. 913     Lottor       Sep 84      Simple File Transfer Protocol
  1121.  
  1122.    This memo describes a proposed Simple File Transfer Protocol (SFTP).  It
  1123.    fills the need of people wanting a protocol that is more useful than
  1124.    TFTP but easier to implement (and less powerful) than FTP.  SFTP
  1125.    supports user access control, file transfers, directory listing,
  1126.    directory changing, file renaming and deleting.  Discussion of this
  1127.    proposal is encouraged, and suggestions for improvements may be sent to
  1128.    the author.
  1129.  
  1130. 912     StJohns      Sep 84      Authentication Service
  1131.  
  1132.    This memo describes a proposed authentication protocol for verifying the
  1133.    identity of a user of a TCP connection.  Given a TCP port number pair,
  1134.    it returns a character string which identifies the owner of that
  1135.    connection on the server's system.  Suggested uses include automatic
  1136.    identification and verification of a user during an FTP session,
  1137.    additional verification of a TAC dial up user, and access verification
  1138.    for a generalized network file server.
  1139.  
  1140. 911     Kirton       Aug 84      EGP Gateway under Berkeley Unix 4.2
  1141.  
  1142.    This memo describes an implementation of the Exterior Gateway Protocol
  1143.    (EGP) (in that sense it is a status report).  The memo also discusses
  1144.    some possible extentions and some design issues (in that sense it is an
  1145.    invitation for further discussion).
  1146.  
  1147. 910     Forsdick     Aug 84      Multimedia Mail Meeting Notes
  1148.  
  1149.    This memo is a report on a meeting about the experimental multimedia
  1150.    mail system (and in a sense a status report on that experiment).  The
  1151.    meeting was held at Bolt Beranek and Newman on 23-24 July 1984 to
  1152.    discuss recent progress by groups who are building multimedia mail
  1153.    systems and to discuss a variety of issues related to the further
  1154.    development of multimedia systems.  Representatives were present from
  1155.    BBN, ISI, SRI and Linkabit.
  1156.  
  1157. 909     Welles       Jul 84      Loader Debugger Protocol
  1158.  
  1159.    The Loader Debugger Protocol (LDP) is an application layer protocol for
  1160.    loading, dumping, and debugging target machines from hosts in a network
  1161.    environment.  This RFC specifies a proposed protocol for the
  1162.    ARPA-Internet and DARPA research community, and requests discussion and
  1163.    suggestions for improvemts.
  1164.  
  1165. 908     Velten       Jul 84      Reliable Data Protocol
  1166.  
  1167.    The Reliable Data Protocol (RDP) is designed to provide a reliable data
  1168.    transport service for packet-based applications.  This RFC specifies a
  1169.    proposed protocol for the ARPA-Internet and DARPA research community,
  1170.    and requests discussion and suggestions for improvemts.
  1171.  
  1172.  
  1173.  
  1174. Westine & Postel                                               [Page 20]
  1175.  
  1176. RFC 999                                                       March 1987
  1177.  
  1178.  
  1179. 907     Storch       Jul 84      Host Access Protocol Specification
  1180.  
  1181.    This document specifies the Host Access Protocol (HAP).  Although HAP
  1182.    was originally designed as the network-access level protocol for the
  1183.    DARPA/DCA sponsored Wideband Packet Satellite Network, it is intended
  1184.    that it evolve into a standard interface SATNET and TACNET (aka MATNET)
  1185.    as well as the Wideband Network.  HAP is an experimental protocol, and
  1186.    will undergo further revision as new capabilities are added and/or
  1187.    different satellite networks are suported.  Implementations of HAP
  1188.    should be performed in coordination with satellite network development
  1189.    and operations personnel.
  1190.  
  1191. 906     Finlayson    Jun 84      Bootstrap Loading Using TFTP
  1192.  
  1193.    It is often convenient to be able to bootstrap a computer system from a
  1194.    communications network.  This RFC proposes the use of the IP TFTP
  1195.    protocol for bootstrap loading in this case.
  1196.  
  1197. 905     ISO          Apr 84      ISO Transport Protocol Specification
  1198.                                  (ISO DP 8073)
  1199.  
  1200.    This is the current specification of the ISO Transport Protocol.  This
  1201.    document is the text of ISO/TC97/SC16/N1576 as corrected by
  1202.    ISO/TC97/SC16/N1695.  This is the specification currently being voted on
  1203.    in ISO as a Draft International Standard (DIS).  This document is
  1204.    distributed as an RFC for your information only, it does not specify a
  1205.    standard for the ARPA-Internet or DARPA research community.  Our thanks
  1206.    to Alex McKenzie of BBN for making this online version available.
  1207.    Please note the size of this document, the file contains 258,729
  1208.    characters.
  1209.  
  1210. 904     Mills        Apr 84      Exterior Gateway Protocol Formal
  1211.                                  Specification
  1212.  
  1213.    RFC-904 is the specification of the Exterior Gateway Protocol (EGP).
  1214.    This memo updates portions of RFC-888 and RFC-827.  This RFC specifies
  1215.    an official protocol of the DARPA community for use between gateways of
  1216.    different autonomous systems in the ARPA-Internet.
  1217.  
  1218. 903     Finlayson    Jun 84      A Reverse Address Resolution Protocol
  1219.  
  1220.    This RFC suggests a method for workstations to dynamically find their
  1221.    protocol address (e.g., their Internet Address), when they know only
  1222.    their hardware address (e.g., their attached physical network address).
  1223.    This RFC specifies a proposed protocol for the ARPA Internet community,
  1224.    and requests discussion and suggestions for improvements.
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233. Westine & Postel                                               [Page 21]
  1234.  
  1235. RFC 999                                                       March 1987
  1236.  
  1237.  
  1238. 902     Postel       Jul 84      ARPA-Internet Protocol Policy
  1239.  
  1240.    The purpose of this memo is to explain how protocol standards are
  1241.    adopted for the ARPA-Internet and the DARPA research community.  There
  1242.    are three important aspects to be discussed:  the process, the
  1243.    authority, and the complex relationship between the DARPA community and
  1244.    the DDN community.  This memo is a policy statement on how protocols
  1245.    become official standards for the ARPA-Internet and the DARPA research
  1246.    community.  This is an official policy statement of the ICCB and the
  1247.    DARPA.
  1248.  
  1249. 901     Reynolds     Jun 84      Official ARPA-Internet Protocols
  1250.  
  1251.    This RFC identifies the documents specifying the official protocols used
  1252.    in the ARPA-Internet.  Annotations identify any revisions or changes
  1253.    planned.  This memo is an official status report on the protocols used
  1254.    in the DARPA research community.  See RFC-991.
  1255.  
  1256. 900     Reynolds     Jun 84      Assigned Numbers
  1257.  
  1258.    This RFC specifies parameter values use in the Internet family of
  1259.    protocols, such as network numbers, well known ports, protocol types,
  1260.    and version numbers.  This memo is an official status report on the
  1261.    protocol parameters used in the Internet protocol system.  See RFC-990
  1262.    and 997.
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290.  
  1291.  
  1292. Westine & Postel                                               [Page 22]
  1293.  
  1294.