Internet Documents

RFCs

RFCs All DocumentsSTDs Internet Standards DocumentsBCPs Best Current Practice DocumentsFYIs Informational Documents
 

 
RFC 407 Remote Job Entry Protocol
 
Authors:R.D. Bressler, R. Guida, A.M. McKenzie.
Date:October 1972
Formats:txt pdf
Obsoletes:RFC 0360
Status:HISTORIC
DOI:10.17487/RFC 0407
 
 
RFC 569 NETED: A Common Editor for the ARPA Network
 
Authors:M.A. Padlipsky.
Date:October 1973
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0569
 
 
RFC 652 Telnet output carriage-return disposition option
 
Authors:D. Crocker.
Date:October 1974
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0652
 
 
RFC 653 Telnet output horizontal tabstops option
 
Authors:D. Crocker.
Date:October 1974
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0653
 
 
RFC 654 Telnet output horizontal tab disposition option
 
Authors:D. Crocker.
Date:October 1974
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0654
 
 
RFC 655 Telnet output formfeed disposition option
 
Authors:D. Crocker.
Date:October 1974
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0655
 
 
RFC 656 Telnet output vertical tabstops option
 
Authors:D. Crocker.
Date:October 1974
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0656
 
 
RFC 657 Telnet output vertical tab disposition option
 
Authors:D. Crocker.
Date:October 1974
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0657
 
 
RFC 658 Telnet output linefeed disposition
 
Authors:D. Crocker.
Date:October 1974
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0658
 
 
RFC 675 Specification of Internet Transmission Control Program
 
Authors:V. Cerf, Y. Dalal, C. Sunshine.
Date:December 1974
Formats:txt pdf
Obsoleted by:RFC 7805
Status:HISTORIC
DOI:10.17487/RFC 0675
The first detailed specification of TCP; see RFC 793.
 
RFC 717 Assigned Network Numbers
 
Authors:J. Postel.
Date:July 1976
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0717
 
 
RFC 721 Out-of-Band Control Signals in a Host-to-Host Protocol
 
Authors:L.L. Garlick.
Date:September 1976
Formats:txt pdf
Obsoleted by:RFC 7805
Status:HISTORIC
DOI:10.17487/RFC 0721
 
 
RFC 734 SUPDUP Protocol
 
Authors:M.R. Crispin.
Date:October 1977
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0734
 
 
RFC 739 Assigned numbers
 
Authors:J. Postel.
Date:November 1977
Formats:txt pdf
Obsoletes:RFC 0604, RFC 0503
Obsoleted by:RFC 0750
Status:HISTORIC
DOI:10.17487/RFC 0739
 
 
RFC 740 NETRJS Protocol
 
Authors:R.T. Braden.
Date:November 1977
Formats:txt pdf
Obsoletes:RFC 0599
Status:HISTORIC
DOI:10.17487/RFC 0740
 
 
RFC 750 Assigned numbers
 
Authors:J. Postel.
Date:September 1978
Formats:txt pdf
Obsoletes:RFC 0739
Obsoleted by:RFC 0755
Status:HISTORIC
DOI:10.17487/RFC 0750
 
 
RFC 755 Assigned numbers
 
Authors:J. Postel.
Date:May 1979
Formats:txt pdf
Obsoletes:RFC 0750
Obsoleted by:RFC 0758
Status:HISTORIC
DOI:10.17487/RFC 0755
 
 
RFC 758 Assigned numbers
 
Authors:J. Postel.
Date:August 1979
Formats:txt pdf
Obsoletes:RFC 0755
Obsoleted by:RFC 0762
Status:HISTORIC
DOI:10.17487/RFC 0758
 
 
RFC 759 Internet Message Protocol
 
Authors:J. Postel.
Date:August 1980
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0759
 
 
RFC 761 DoD standard Transmission Control Protocol
 
Authors:J. Postel.
Date:January 1980
Formats:txt pdf
Obsoleted by:RFC 0793, RFC 7805
Status:HISTORIC
DOI:10.17487/RFC 0761
 
 
RFC 762 Assigned numbers
 
Authors:J. Postel.
Date:January 1980
Formats:txt pdf
Obsoletes:RFC 0758
Obsoleted by:RFC 0770
Status:HISTORIC
DOI:10.17487/RFC 0762
 
 
RFC 770 Assigned numbers
 
Authors:J. Postel.
Date:September 1980
Formats:txt pdf
Obsoletes:RFC 0762
Obsoleted by:RFC 0776
Status:HISTORIC
DOI:10.17487/RFC 0770
 
 
RFC 776 Assigned numbers
 
Authors:J. Postel.
Date:January 1981
Formats:txt pdf
Obsoletes:RFC 0770
Obsoleted by:RFC 0790
Status:HISTORIC
DOI:10.17487/RFC 0776
 
 
RFC 778 DCNET Internet Clock Service
 
Authors:D.L. Mills.
Date:April 1981
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0778
 
 
RFC 790 Assigned numbers
 
Authors:J. Postel.
Date:September 1981
Formats:txt pdf
Obsoletes:RFC 0776
Obsoleted by:RFC 0820
Status:HISTORIC
DOI:10.17487/RFC 0790
 
 
RFC 795 Service mappings
 
Authors:J. Postel.
Date:September 1981
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0795
 
 
RFC 796 Address mappings
 
Authors:J. Postel.
Date:September 1981
Formats:txt pdf
Obsoletes:IEN115
Status:HISTORIC
DOI:10.17487/RFC 0796
 
 
RFC 813 Window and Acknowledgement Strategy in TCP
 
Authors:D.D. Clark.
Date:July 1982
Formats:txt pdf
Obsoleted by:RFC 7805
Status:HISTORIC
DOI:10.17487/RFC 0813
This RFC describes implementation strategies to deal with two mechanisms in TCP, the window and the acknowledgement. It also presents a particular set of algorithms which have received testing in the field, and which appear to work properly with each other. With more experience, these algorithms may become part of the formal specification, until such time their use is recommended.
 
RFC 816 Fault isolation and recovery
 
Authors:D.D. Clark.
Date:July 1982
Formats:txt pdf
Obsoleted by:RFC 7805
Status:HISTORIC
DOI:10.17487/RFC 0816
This RFC describes the portion of fault isolation and recovery which is the responsibility of the host.
 
RFC 818 Remote User Telnet service
 
Authors:J. Postel.
Date:November 1982
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0818
This RFC is the specification of an application protocol. Any host that implements this application level service must follow this protocol.
 
RFC 820 Assigned numbers
 
Authors:J. Postel.
Date:August 1982
Formats:txt pdf
Obsoletes:RFC 0790
Obsoleted by:RFC 0870
Status:HISTORIC
DOI:10.17487/RFC 0820
This RFC is an old version, see RFC 870.
 
RFC 823 DARPA Internet gateway
 
Authors:R.M. Hinden, A. Sheltzer.
Date:September 1982
Formats:txt pdf
Updates:IEN109, IEN30
Status:HISTORIC
DOI:10.17487/RFC 0823
This RFC is a status report on the Internet Gateway developed by BBN. It describes the Internet Gateway as of September 1982. This memo presents detailed descriptions of message formats and gateway procedures, however, this is not an implementation specification, and such details are subject to change.
 
RFC 840 Official protocols
 
Authors:J. Postel.
Date:April 1983
Formats:txt pdf
Obsoleted by:RFC 0880
Status:HISTORIC
DOI:10.17487/RFC 0840
This RFC has been revised, see RFC 880.
 
RFC 869 Host Monitoring Protocol
 
Authors:R. Hinden.
Date:December 1983
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0869
This RFC specifies the Host Monitoring Protocol used to collect information from various types of hosts in the Internet. Designers of Internet communications software are encouraged to consider this protocol as a means of monitoring the behavior of their creations.
 
RFC 870 Assigned numbers
 
Authors:J.K. Reynolds, J. Postel.
Date:October 1983
Formats:txt pdf
Obsoletes:RFC 0820
Obsoleted by:RFC 0900
Status:HISTORIC
DOI:10.17487/RFC 0870
This RFC documents the list of numbers assigned for networks, protocols, etc. Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755, 750, 739, 604.
 
RFC 879 The TCP Maximum Segment Size and Related Topics
 
Authors:J. Postel.
Date:November 1983
Formats:txt pdf
Obsoleted by:RFC 7805
Updated by:RFC 6691
Status:HISTORIC
DOI:10.17487/RFC 0879
This RFC discusses the TCP Maximum Segment Size Option and related topics. The purposes is to clarify some aspects of TCP and its interaction with IP. This memo is a clarification to the TCP specification, and contains information that may be considered as "advice to implementers".
 
RFC 880 Official protocols
 
Authors:J.K. Reynolds, J. Postel.
Date:October 1983
Formats:txt pdf
Obsoletes:RFC 0840
Obsoleted by:RFC 0901
Status:HISTORIC
DOI:10.17487/RFC 0880
This RFC identifies the documents specifying the official protocols used in the ARPA Internet. Annotations identify any revisions or changes planned. Obsoletes RFC 840.
 
RFC 896 Congestion Control in IP/TCP Internetworks
 
Authors:J. Nagle.
Date:January 1984
Formats:txt pdf
Obsoleted by:RFC 7805
Status:HISTORIC
DOI:10.17487/RFC 0896
This memo discusses some aspects of congestion control in IP/TCP Internetworks. It is intended to stimulate thought and further discussion of this topic. While some specific suggestions are made for improved congestion control implementation, this memo does not specify any standards.
 
RFC 900 Assigned Numbers
 
Authors:J.K. Reynolds, J. Postel.
Date:June 1984
Formats:txt pdf
Obsoletes:RFC 0870
Obsoleted by:RFC 0923
Status:HISTORIC
DOI:10.17487/RFC 0900
This RFC specifies parameter values use in the Internet family of protocols, such as network numbers, well known ports, protocol types, and version numbers. This memo is an official status report on the protocol parameters used in the Internet protocol system. See RFC-990 and 997.
 
RFC 904 Exterior Gateway Protocol formal specification
 
Authors:D.L. Mills.
Date:April 1984
Formats:txt pdf
Updates:RFC 0827, RFC 0888
Status:HISTORIC
DOI:10.17487/RFC 0904
RFC-904 is the specification of the Exterior Gateway Protocol (EGP). This memo updates portions of RFC-888 and RFC-827. This RFC specifies an official protocol of the DARPA community for use between gateways of different autonomous systems in the ARPA-Internet.
 
RFC 913 Simple File Transfer Protocol
 
Authors:M. Lottor.
Date:September 1984
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0913
This memo describes a proposed Simple File Transfer Protocol (SFTP). It fills the need of people wanting a protocol that is more useful than TFTP but easier to implement (and less powerful) than FTP. SFTP supports user access control, file transfers, directory listing, directory changing, file renaming and deleting. Discussion of this proposal is encouraged, and suggestions for improvements may be sent to the author.
 
RFC 914 Thinwire protocol for connecting personal computers to the Internet
 
Authors:D.J. Farber, G. Delp, T.M. Conte.
Date:September 1984
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0914
This RFC focuses discussion on the particular problems in the ARPA-Internet of low speed network interconnection with personal computers, and possible methods of solution. None of the proposed solutions in this document are intended as standards for the ARPA-Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to the problems, leading eventually to the adoption of standards.
 
RFC 916 Reliable Asynchronous Transfer Protocol (RATP)
 
Authors:G.G. Finn.
Date:October 1984
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0916
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This paper proposes and specifies a protocol which allows two programs to reliably communicate over a communication link. It ensures that the data entering one end of the link if received arrives at the other end intact and unaltered. The protocol, named RATP, is designed to operate over a full duplex point-to-point connection. It contains some features which tailor it to the RS-232 links now in common use.
 
RFC 923 Assigned numbers
 
Authors:J.K. Reynolds, J. Postel.
Date:October 1984
Formats:txt pdf
Obsoletes:RFC 0900
Obsoleted by:RFC 0943
Status:HISTORIC
DOI:10.17487/RFC 0923
This RFC documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers obsoletes RFC-900 and earlier editions. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990, and 997.
 
RFC 929 Proposed Host-Front End Protocol
 
Authors:J. Lilienkamp, R. Mandell, M.A. Padlipsky.
Date:December 1984
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0929
The Host-Front End Protocol introduced in RFC-928 is described in detail in this memo. The first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
 
RFC 937 Post Office Protocol: Version 2
 
Authors:M. Butler, J. Postel, D. Chase, J. Goldberger, J.K. Reynolds.
Date:February 1985
Formats:txt pdf
Obsoletes:RFC 0918
Status:HISTORIC
DOI:10.17487/RFC 0937
This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. This memo is a revision of RFC-918.
 
RFC 943 Assigned numbers
 
Authors:J.K. Reynolds, J. Postel.
Date:April 1985
Formats:txt pdf
Obsoletes:RFC 0923
Obsoleted by:RFC 0960
Status:HISTORIC
DOI:10.17487/RFC 0943
This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This RFC will be updated periodically, and in any case current information can be obtained from Joyce Reynolds. The assignment of numbers is also handled by Joyce. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, network number, etc., please contact Joyce to receive a number assignment. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997.
 
RFC 953 Hostname Server
 
Authors:K. Harrenstien, M.K. Stahl, E.J. Feinler.
Date:October 1985
Formats:txt pdf
Obsoletes:RFC 0811
Status:HISTORIC
DOI:10.17487/RFC 0953
This RFC is the official specification of the Hostname Server Protocol. This edition of the specification includes minor revisions to RFC-811 which brings it up to date.
 
RFC 960 Assigned numbers
 
Authors:J.K. Reynolds, J. Postel.
Date:December 1985
Formats:txt pdf
Obsoletes:RFC 0943
Obsoleted by:RFC 0990
Status:HISTORIC
DOI:10.17487/RFC 0960
This memo documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers updates and obsoletes RFC-943. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997.
 
RFC 974 Mail routing and the domain system
 
Authors:C. Partridge.
Date:January 1986
Formats:txt pdf
Obsoleted by:RFC 2821
Also:STD 0010
Status:HISTORIC
DOI:10.17487/RFC 0974
This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system. This involves a discussion of how mailers interpret MX RRs, which are used for message routing.
 
RFC 990 Assigned numbers
 
Authors:J.K. Reynolds, J. Postel.
Date:November 1986
Formats:txt pdf
Obsoletes:RFC 0960
Obsoleted by:RFC 1010
Updated by:RFC 0997
Status:HISTORIC
DOI:10.17487/RFC 0990
This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-997. Obsoletes RFC-960, 943, 923 and 900.
 
RFC 996 Statistics server
 
Authors:D.L. Mills.
Date:February 1987
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 0996
This RFC specifies a standard for the ARPA Internet community. Hosts and gateways on the DARPA Internet that choose to implement a remote statistics monitoring facility may use this protocol to send statistics data upon request to a monitoring center or debugging host.
 
RFC 1009 Requirements for Internet gateways
 
Authors:R.T. Braden, J. Postel.
Date:June 1987
Formats:txt pdf
Obsoletes:RFC 0985
Obsoleted by:RFC 1812
Status:HISTORIC
DOI:10.17487/RFC 1009
This RFC summarizes the requirements for gateways to be used between networks supporting the Internet protocols. This document is a formal statement of the requirements to be met by gateways used in the Internet system. As such, it is an official specification for the Internet community.
 
RFC 1010 Assigned numbers
 
Authors:J.K. Reynolds, J. Postel.
Date:May 1987
Formats:txt pdf
Obsoletes:RFC 0990
Obsoleted by:RFC 1060
Status:HISTORIC
DOI:10.17487/RFC 1010
This memo is an official status report on the numbers used in protocols in the Internet community. It documents the currently assigned values from several series of numbers including link, socket, port, and protocol, used in network protocol implementations.
 
RFC 1021 High-level Entity Management System (HEMS)
 
Authors:C. Partridge, G. Trewitt.
Date:October 1987
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1021
This memo provides a general overview of the High-level Entity management system (HEMS). This system is experimental, and is currently being tested in portions of the Internet.
 
RFC 1028 Simple Gateway Monitoring Protocol
 
Authors:J. Davin, J.D. Case, M. Fedor, M.L. Schoffstall.
Date:November 1987
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1028
This memo defines a simple application-layer protocol by which management information for a gateway may be inspected or altered by remote users. This proposal is intended only as an interim response to immediate gateway monitoring needs.
 
RFC 1037 NFILE - a file access protocol
 
Authors:B. Greenberg, S. Keene.
Date:December 1987
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1037
This document includes a specification of the NFILE file access protocol and its underlying levels of protocol, the Token List Transport Layer and Byte Stream with Mark. The goal of this specification is to promote discussion of the ideas described here, and to encourage designers of future file protocols to take advantage of these ideas. A secondary goal is to make the specification available to sites that might benefit from implementing NFILE.
 
RFC 1041 Telnet 3270 regime option
 
Authors:Y. Rekhter.
Date:January 1988
Formats:txt pdf
Updated by:RFC 6270
Status:HISTORIC
DOI:10.17487/RFC 1041
This RFC specifies a proposed standard for the Internet community. Hosts on the Internet that want to support 3270 data stream within the Telnet protocol, are expected to adopt and implement this standard.
 
RFC 1049 Content-type header field for Internet messages
 
Authors:M.A. Sirbu.
Date:March 1988
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1049
This memo suggests proposed additions to the Internet Mail Protocol, RFC-822, for the Internet community, and requests discussion and suggestions for improvements.
 
RFC 1050 RPC: Remote Procedure Call Protocol specification
 
Authors:Sun Microsystems.
Date:April 1988
Formats:txt pdf
Obsoleted by:RFC 1057
Status:HISTORIC
DOI:10.17487/RFC 1050
This memo specifies a message protocol used in implementing Sun's Remote Procedure Call (RPC) package. This RFC describes a standard that Sun Microsystems and others are using and is one they wish to propose for the Internet's consideration. It is not an Internet standard at this time.
 
RFC 1051 Standard for the transmission of IP datagrams and ARP packets over ARCNET networks
 
Authors:P.A. Prindeville.
Date:March 1988
Formats:txt pdf
Obsoleted by:RFC 1201
Status:HISTORIC
DOI:10.17487/RFC 1051
This memo specifies a standard method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams on an ARCNET. This RFC is a standard protocol for the Internet community.
 
RFC 1053 Telnet X.3 PAD option
 
Authors:S. Levy, T. Jacobson.
Date:April 1988
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1053
This RFC proposes a new option to Telnet for the Internet community, and requests discussion and suggestions for improvements.
 
RFC 1058 Routing Information Protocol
 
Authors:C.L. Hedrick.
Date:June 1988
Formats:txt pdf
Updated by:RFC 1388, RFC 1723
Status:HISTORIC
DOI:10.17487/RFC 1058
This RFC describes an existing protocol for exchanging routing information among gateways and other hosts. It is intended to be used as a basis for developing gateway software for use in the Internet community.
 
RFC 1060 Assigned numbers
 
Authors:J.K. Reynolds, J. Postel.
Date:March 1990
Formats:txt pdf
Obsoletes:RFC 1010
Obsoleted by:RFC 1340
Updated by:RFC 1349
Status:HISTORIC
DOI:10.17487/RFC 1060
This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. Distribution of this memo is unlimited.
 
RFC 1072 TCP extensions for long-delay paths
 
Authors:V. Jacobson, R.T. Braden.
Date:October 1988
Formats:txt pdf
Obsoleted by:RFC 1323, RFC 2018, RFC 6247
Status:HISTORIC
DOI:10.17487/RFC 1072
This RFC proposes a set of extensions to the TCP protocol to provide efficient operation over a path with a high bandwidth*delay product. These extensions are not proposed as an Internet standard at this time. Instead, they are intended as a basis for further experimentation and research on transport protocol performance.
 
RFC 1078 TCP port service Multiplexer (TCPMUX)
 
Authors:M. Lottor.
Date:November 1988
Formats:txt pdf
Obsoleted by:RFC 7805
Status:HISTORIC
DOI:10.17487/RFC 1078
This RFC proposes an Internet standard which can be used by future TCP services instead of using 'well-known ports'.
 
RFC 1083 IAB official protocol standards
 
Authors:Defense Advanced Research Projects Agency, Internet Activities Board.
Date:December 1988
Formats:txt pdf
Obsoleted by:RFC 1100
Status:HISTORIC
DOI:10.17487/RFC 1083
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months.
 
RFC 1100 IAB official protocol standards
 
Authors:Defense Advanced Research Projects Agency, Internet Activities Board.
Date:April 1989
Formats:txt pdf
Obsoletes:RFC 1083
Obsoleted by:RFC 1130
Status:HISTORIC
DOI:10.17487/RFC 1100
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority (see the contact information at the end of this memo). Do not use this memo after 31-July-89.
 
RFC 1106 TCP big window and NAK options
 
Authors:R. Fox.
Date:June 1989
Formats:txt pdf
Obsoleted by:RFC 6247
Status:HISTORIC
DOI:10.17487/RFC 1106
Two extensions to the TCP protocol are described in this RFC in order to provide a more efficient operation over a network with a high bandwidth*delay product. The main issue that still needs to be solved is congestion versus noise. This issue is touched on in this memo, but further research is still needed on the applicability of the extensions in the Internet as a whole infrastructure and not just high bandwidth*delay product networks. Even with this outstanding issue, this document does describe the use of these options in the isolated satellite network environment to help facilitate more efficient use of this special medium to help off load bulk data transfers from links needed for interactive use.
 
RFC 1108 U.S
 
Authors:Department of Defense Security Options for the Internet Protocol. S. Kent.
Date:November 1991
Formats:txt pdf
Obsoletes:RFC 1038
Status:HISTORIC
DOI:10.17487/RFC 1108
This RFC specifies the U.S. Department of Defense Basic SecurityOption and the top-level description of the Extended Security Option for use with the Internet Protocol. This RFC obsoletes RFC 1038"Revised IP Security Option", dated January 1988.
 
RFC 1110 Problem with the TCP big window option
 
Authors:A.M. McKenzie.
Date:August 1989
Formats:txt pdf
Obsoleted by:RFC 6247
Status:HISTORIC
DOI:10.17487/RFC 1110
The TCP Big Window option discussed in RFC 1106 will not work properly in an Internet environment which has both a high bandwidth * delay product and the possibility of disordering and duplicating packets. In such networks, the window size must not be increased without a similar increase in the sequence number space. Therefore, a different approach to big windows should be taken in the Internet.
 
RFC 1113 Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures
 
Authors:J. Linn.
Date:August 1989
Formats:txt pdf
Obsoletes:RFC 0989, RFC 1040
Obsoleted by:RFC 1421
Status:HISTORIC
DOI:10.17487/RFC 1113
This RFC specifies features for private electronic mail based on encryption technology. [STANDARDS-TRACK]
 
RFC 1114 Privacy enhancement for Internet electronic mail: Part II - certificate-based key management
 
Authors:S.T. Kent, J. Linn.
Date:August 1989
Formats:txt pdf
Obsoleted by:RFC 1422
Status:HISTORIC
DOI:10.17487/RFC 1114
This RFC specifies the key management aspects of Privacy Enhanced Mail. [STANDARDS-TRACK]
 
RFC 1115 Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers
 
Authors:J. Linn.
Date:August 1989
Formats:txt pdf
Obsoleted by:RFC 1423
Status:HISTORIC
DOI:10.17487/RFC 1115
This RFC provides definitions, references, and citations for algorithms, usage modes, and associated identifiers used in RFC-1113 and RFC-1114 in support of privacy-enhanced electronic mail. [STANDARDS-TRACK]
 
RFC 1130 IAB official protocol standards
 
Authors:Defense Advanced Research Projects Agency, Internet Activities Board.
Date:October 1989
Formats:txt pdf
Obsoletes:RFC 1100
Obsoleted by:RFC 1140
Status:HISTORIC
DOI:10.17487/RFC 1130
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB).
 
RFC 1137 Mapping between full RFC 822 and RFC 822 with restricted encoding
 
Authors:S. Kille.
Date:December 1989
Formats:txt pdf
Updates:RFC 0976
Status:HISTORIC
DOI:10.17487/RFC 1137
This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard.
 
RFC 1140 IAB official protocol standards
 
Authors:Defense Advanced Research Projects Agency, Internet Activities Board.
Date:May 1990
Formats:txt pdf
Obsoletes:RFC 1130
Obsoleted by:RFC 1200
Status:HISTORIC
DOI:10.17487/RFC 1140
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority. Do not use this edition after 31-Aug-90.
 
RFC 1142 OSI IS-IS Intra-domain Routing Protocol
 
Authors:D. Oran, Ed..
Date:February 1990
Formats:txt ps pdf
Obsoleted by:RFC 7142
Status:HISTORIC
DOI:10.17487/RFC 1142
This RFC is a republication of ISO DP 10589 as a service to the Internet community. This is not an Internet standard.
 
RFC 1145 TCP alternate checksum options
 
Authors:J. Zweig, C. Partridge.
Date:February 1990
Formats:txt pdf
Obsoleted by:RFC 1146, RFC 6247
Status:HISTORIC
DOI:10.17487/RFC 1145
This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use.
 
RFC 1146 TCP alternate checksum options
 
Authors:J. Zweig, C. Partridge.
Date:March 1990
Formats:txt pdf
Obsoletes:RFC 1145
Obsoleted by:RFC 6247
Status:HISTORIC
DOI:10.17487/RFC 1146
This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use. Note: This RFC corrects errors introduced in the editing process in RFC 1145.
 
RFC 1150 FYI on FYI: Introduction to the FYI Notes
 
Authors:G.S. Malkin, J.K. Reynolds.
Date:March 1990
Formats:txt pdf
Obsoleted by:RFC 6360
Status:HISTORIC
DOI:10.17487/RFC 1150
This memo is the first in a new sub-series of RFCs called FYIs (For Your Information). This memo provides information for the Internet community. It does not specify any standard. [Also FYI 1.]
 
RFC 1156 Management Information Base for network management of TCP/IP-based internets
 
Authors:K. McCloghrie, M.T. Rose.
Date:May 1990
Formats:txt pdf
Obsoletes:RFC 1066
Status:HISTORIC
DOI:10.17487/RFC 1156
This RFC is a re-release of RFC 1066, with a changed "Status of this Memo", "IAB Policy Statement", and "Introduction" sections plus a few minor typographical corrections. The technical content of the document is unchanged from RFC 1066. [STANDARDS-TRACK]
 
RFC 1157 Simple Network Management Protocol (SNMP)
 
Authors:J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin.
Date:May 1990
Formats:txt pdf
Obsoletes:RFC 1098
Status:HISTORIC
DOI:10.17487/RFC 1157
This RFC is a re-release of RFC 1098, with a changed "Status of this Memo" section plus a few minor typographical corrections. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. [STANDARDS-TRACK]
 
RFC 1163 Border Gateway Protocol (BGP)
 
Authors:K. Lougheed, Y. Rekhter.
Date:June 1990
Formats:txt pdf
Obsoletes:RFC 1105
Obsoleted by:RFC 1267
Status:HISTORIC
DOI:10.17487/RFC 1163
This RFC, together with its companion RFC-1164, "Application of the Border Gateway Protocol in the Internet", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]
 
RFC 1164 Application of the Border Gateway Protocol in the Internet
 
Authors:J.C. Honig, D. Katz, M. Mathis, Y. Rekhter, J.Y. Yu.
Date:June 1990
Formats:txt pdf
Obsoleted by:RFC 1268
Status:HISTORIC
DOI:10.17487/RFC 1164
This RFC, together with its companion RFC-1163, "A Border Gateway Protocol (BGP)", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]
 
RFC 1189 Common Management Information Services and Protocols for the Internet (CMOT and CMIP)
 
Authors:U.S. Warrier, L. Besaw, L. LaBarre, B.D. Handspicker.
Date:October 1990
Formats:txt pdf
Obsoletes:RFC 1095
Status:HISTORIC
DOI:10.17487/RFC 1189
This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in the Internet. [STANDARDS-TRACK]
 
RFC 1200 IAB official protocol standards
 
Authors:Defense Advanced Research Projects Agency, Internet Activities Board.
Date:April 1991
Formats:txt pdf
Obsoletes:RFC 1140
Obsoleted by:RFC 1250
Status:HISTORIC
DOI:10.17487/RFC 1200
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information.
 
RFC 1203 Interactive Mail Access Protocol: Version 3
 
Authors:J. Rice.
Date:February 1991
Formats:txt pdf
Obsoletes:RFC 1064
Status:HISTORIC
DOI:10.17487/RFC 1203
This RFC suggests a method for workstations to access mail dynamically from a mailbox server ("repository"). The following document is a modified version of RFC 1064, the definition of the IMAP2 protocol. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard.
 
RFC 1214 OSI internet management: Management Information Base
 
Authors:L. LaBarre.
Date:April 1991
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1214
This RFC documents a MIB for use with CMIP, either over pure OSI stacks or with the CMIP over TCP specification. It redefines objects comprised by the second revision of the Management Information Base for Network Management of TCP/IP-based internets: MIB-II so as to conform to the OSI structure of management information. This document is a product of the IETF OIM working group.
 
RFC 1227 SNMP MUX protocol and MIB
 
Authors:M.T. Rose.
Date:May 1991
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1227
This memo suggests a mechanism by which a user process may associate itself with the local SNMP agent on a host, in order to implement portions of the MIB. This mechanism would be local to the host.This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.
 
RFC 1230 IEEE 802.4 Token Bus MIB
 
Authors:K. McCloghrie, R. Fox.
Date:May 1991
Formats:txt pdf
Updated by:RFC 1239
Status:HISTORIC
DOI:10.17487/RFC 1230
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.4 Token Bus technology described in 802.4 Token-Passing Bus Access Method and Physical Layer Specifications, IEEE Standard 802.4. [STANDARDS-TRACK]
 
RFC 1234 Tunneling IPX traffic through IP networks
 
Authors:D. Provan.
Date:June 1991
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1234
This memo describes a method of encapsulating IPX datagrams within UDP packets so that IPX traffic can travel across an IP internet. [STANDARDS-TRACK] This memo defines objects for managing DS1 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]
 
RFC 1239 Reassignment of experimental MIBs to standard MIBs
 
Authors:J.K. Reynolds.
Date:June 1991
Formats:txt pdf
Updates:RFC 1229, RFC 1230, RFC 1231, RFC 1232, RFC 1233
Status:HISTORIC
DOI:10.17487/RFC 1239
This memo specifically updates RFC 1229, RFC 1230, RFC 1231, RFC 1232 and RFC 1233 with new codes. [STANDARDS-TRACK]
 
RFC 1240 OSI connectionless transport services on top of UDP: Version 1
 
Authors:C. Shue, W. Haggerty, K. Dobbins.
Date:June 1991
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1240
This document describes a protocol for running OSI Connectionless service on UDP. [STANDARDS-TRACK]
 
RFC 1250 IAB Official Protocol Standards
 
Authors:J. Postel.
Date:August 1991
Formats:txt pdf
Obsoletes:RFC 1200
Obsoleted by:RFC 2200, RFC 1280
Status:HISTORIC
DOI:10.17487/RFC 1250
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1264 Internet Engineering Task Force Internet Routing Protocol Standardization Criteria
 
Authors:R.M. Hinden.
Date:October 1991
Formats:txt pdf
Obsoleted by:RFC 4794
Status:HISTORIC
DOI:10.17487/RFC 1264
This informational RFC presents procedures for creating and documenting Internet standards on routing protocols. These procedures have been established by the Internet Activities Board (IAB) in consultation with the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. It does not specifiy an Internet standard.
 
RFC 1267 Border Gateway Protocol 3 (BGP-3)
 
Authors:K. Lougheed, Y. Rekhter.
Date:October 1991
Formats:txt pdf
Obsoletes:RFC 1163
Status:HISTORIC
DOI:10.17487/RFC 1267
This memo, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]
 
RFC 1268 Application of the Border Gateway Protocol in the Internet
 
Authors:Y. Rekhter, P. Gross.
Date:October 1991
Formats:txt pdf
Obsoletes:RFC 1164
Obsoleted by:RFC 1655
Status:HISTORIC
DOI:10.17487/RFC 1268
This document, together with its companion document, "A BorderGateway Protocol (BGP-3)", define an inter-autonomous system routing protocol for the Internet. "A Border Gateway Protocol (BGP-3)" defines the BGP protocol specification, and this document describes the usage of the BGP in the Internet.

Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (iwg@rice.edu).

 
RFC 1276 Replication and Distributed Operations extensions to provide an Internet Directory using X.500
 
Authors:S.E. Hardcastle-Kille.
Date:November 1991
Formats:txt ps pdf
Status:HISTORIC
DOI:10.17487/RFC 1276
Some requirements on extensions to X.500 are described in theRFC[HK91b], in order to build an Internet Directory usingX.500(1988). This document specifies a set of solutions to the problems raised. These solutions are based on some work done for the QUIPU implementation, and demonstrated to be effective in a number of directory pilots. By documenting a de facto standard, rapid progress can be made towards a full-scale pilot. These procedures are an INTERIM approach. There are known deficiencies, both in terms of manageability and scalability.Transition to standard approaches are planned when appropriate standards are available. This RFCwill be obsoleted at this point.
 
RFC 1280 IAB Official Protocol Standards
 
Authors:J. Postel.
Date:March 1992
Formats:txt pdf
Obsoletes:RFC 1250
Obsoleted by:RFC 1360
Status:HISTORIC
DOI:10.17487/RFC 1280
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1285 FDDI Management Information Base
 
Authors:J. Case.
Date:January 1992
Formats:txt pdf
Updated by:RFC 1512
Status:HISTORIC
DOI:10.17487/RFC 1285
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing devices which implement the FDDI. [STANDARDS-TRACK]
 
RFC 1314 A File Format for the Exchange of Images in the Internet
 
Authors:A. Katz, D. Cohen.
Date:April 1992
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1314
This document defines a standard file format for the exchange of fax-like black and white images within the Internet. It is a product of the Network Fax Working Group of the Internet Engineering TaskForce (IETF).

The standard is:

** The file format should be TIFF-B with multi-page files supported. Images should be encoded as one TIFF strip per page.

** Images should be compressed using MMR when possible. Images may also be MH or MR compressed or uncompressed. If MH or MR compression is used, scan lines should be "byte-aligned".

** For maximum interoperability, image resolutions should either be 600, 400, or 300 dpi; or else be one of the standard Group 3 fax resolutions (98 or 196 dpi vertically and 204 dpi horizontally).

Note that this specification is self contained and an implementation should be possible without recourse to the TIFF references, and that only the specific TIFF documents cited are relevant to this specification. Updates to the TIFF documents do not change this specification.

Experimentation with this file format specified here is encouraged.

 
RFC 1319 The MD2 Message-Digest Algorithm
 
Authors:B. Kaliski.
Date:April 1992
Formats:txt pdf
Obsoleted by:RFC 6149
Status:HISTORIC
DOI:10.17487/RFC 1319
This document describes the MD2 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1320 The MD4 Message-Digest Algorithm
 
Authors:R. Rivest.
Date:April 1992
Formats:txt pdf
Obsoletes:RFC 1186
Obsoleted by:RFC 6150
Status:HISTORIC
DOI:10.17487/RFC 1320
This document describes the MD4 message-digest algorithm [1]. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1328 X.400 1988 to 1984 downgrading
 
Authors:S. Hardcastle-Kille.
Date:May 1992
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1328
This document considers issues of downgrading from X.400(1988) toX.400(1984) [MHS88a, MHS84]. Annexe B of X.419 specifies some downgrading rules [MHS88b], but these are not sufficient for provision of service in an environment containing both 1984 and 1988 components. This document defines a number of extensions to this annexe.

This specification is not tutorial. COSINE Study 8.2 by J.A.I.Craigie gives a useful overview [Cra88].

 
RFC 1340 Assigned Numbers
 
Authors:J. Reynolds, J. Postel.
Date:July 1992
Formats:txt pdf
Obsoletes:RFC 1060
Obsoleted by:RFC 1700
Status:HISTORIC
DOI:10.17487/RFC 1340
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 a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.
 
RFC 1347 TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing
 
Authors:R. Callon.
Date:June 1992
Formats:txt pdf ps
Status:HISTORIC
DOI:10.17487/RFC 1347
This paper describes a simple proposal which provides a long-term solution to Internet addressing, routing, and scaling. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1351 SNMP Administrative Model
 
Authors:J. Davin, J. Galvin, K. McCloghrie.
Date:July 1992
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1351
This memo presents an elaboration of the SNMP administrative model set forth in [1]. This model provides a unified conceptual basis for administering SNMP protocol entities to support: authenticaiton and integrity, privacy, access control, and cooperation of protocol entities. [STANDARDS-TRACK]
 
RFC 1352 SNMP Security Protocols
 
Authors:J. Galvin, K. McCloghrie, J. Davin.
Date:July 1992
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1352
The Simple Network Management Protocol (SNMP) specification [1] allows for the protection of network management operations by a variety of security protocols. The SNMP administrative model described in [2] provides a framework for securing SNMP network management. In the context of that framework, this memo defines protocols to support the following three security services: data integrity, data origin authentication and data confidentiality. [STANDARDS-TRACK]
 
RFC 1353 Definitions of Managed Objects for Administration of SNMP Parties
 
Authors:K. McCloghrie, J. Davin, J. Galvin.
Date:July 1992
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1353
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it describes a representation of the SNMP parties defined in [8] as objects defined according to the Internet StandardSMI [1]. These definitions are consistent with the SNMP Security protocols set forth in [9].
 
RFC 1360 IAB Official Protocol Standards
 
Authors:J. Postel.
Date:September 1992
Formats:txt pdf
Obsoletes:RFC 1280
Obsoleted by:RFC 1410
Status:HISTORIC
DOI:10.17487/RFC 1360
 
 
RFC 1370 Applicability Statement for OSPF
 
Authors:Internet Architecture Board, L. Chapin.
Date:October 1992
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1370
This Applicability Statement places a requirement on vendors claiming conformance to this standard, in order to assure that users will have the option of deploying OSPF when they need a multivendor, interoperable IGP in their environment. [STANDARDS-TRACK]
 
RFC 1378 The PPP AppleTalk Control Protocol (ATCP)
 
Authors:B. Parker.
Date:November 1992
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1378
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

This document defines the NCP for establishing and configuring theAppleTalk Protocol [3] over PPP.

This memo is a joint effort of the AppleTalk-IP Working Group and thePoint-to-Point Protocol Working Group of the Internet EngineeringTask Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.

 
RFC 1379 Extending TCP for Transactions -- Concepts
 
Authors:R. Braden.
Date:November 1992
Formats:txt pdf
Obsoleted by:RFC 6247
Updated by:RFC 1644
Status:HISTORIC
DOI:10.17487/RFC 1379
This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation. This extension would fill the large gap between connection-oriented TCP and datagram-based UDP, allowing TCP to efficiently perform many applications for which UDP is currently used. A separate memo contains a detailed functional specification for this proposed extension.

This work was supported in part by the National Science Foundation under Grant Number NCR-8922231.

 
RFC 1385 EIP: The Extended Internet Protocol
 
Authors:Z. Wang.
Date:November 1992
Formats:txt pdf
Obsoleted by:RFC 6814
Status:HISTORIC
DOI:10.17487/RFC 1385
EIP can substantially reduce the amount of modifications needed to the current Internet systems and greatly ease the difficulties of transition. This is an "idea" paper and discussion is strongly encouraged on Big-Internet@munnari.oz.au. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1393 Traceroute Using an IP Option
 
Authors:G. Malkin.
Date:January 1993
Formats:txt pdf
Obsoleted by:RFC 6814
Status:HISTORIC
DOI:10.17487/RFC 1393
Traceroute serves as a valuable network debugging tool. The way in which it is currently implemented has the advantage of being automatically supported by all of the routers. It's two problems are the number of packets it generates and the amount of time it takes to run.

This document specifies a new IP option and ICMP message type which duplicates the functionality of the existing traceroute method while generating fewer packets and completing in a shorter time.

 
RFC 1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol
 
Authors:D. Haskin.
Date:January 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1397
This document specifies the recommendation of the BGP Working Group on default route advertisement support in BGP2 [1] and BGP3 [2] versions of the Border Gateway Protocol.

This recommendation only applies to BGP2 and BGP3 versions of theBorder Gateway Protocol since starting with the BGP4 [3] version a default route advertisement capability is built in the protocol.

 
RFC 1403 BGP OSPF Interaction
 
Authors:K. Varadhan.
Date:January 1993
Formats:txt pdf
Obsoletes:RFC 1364
Status:HISTORIC
DOI:10.17487/RFC 1403
This memo defines the various criteria to be used when designing anAutonomous System Border Routers (ASBR) that will run BGP with otherASBRs external to the AS and OSPF as its IGP. This is a republication of RFC 1364 to correct some editorial problems.
 
RFC 1408 Telnet Environment Option
 
Authors:D. Borman, Ed..
Date:January 1993
Formats:txt pdf
Updated by:RFC 1571
Status:HISTORIC
DOI:10.17487/RFC 1408
This document specifies a mechanism for passing environment information between a telnet client and server. Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting.
 
RFC 1410 IAB Official Protocol Standards
 
Authors:J. Postel, Ed..
Date:March 1993
Formats:txt pdf
Obsoletes:RFC 1360
Obsoleted by:RFC 1500
Status:HISTORIC
DOI:10.17487/RFC 1410
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB).
 
RFC 1414 Identification MIB
 
Authors:M. St. Johns, M. Rose.
Date:February 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1414
This memo defines a MIB for use with identifying the users associated with TCP connections. It provides functionality approximately equivalent to that provided by the protocol defined in RFC 1413 [1].This document is a product of the TCP Client Identity ProtocolWorking Group of the Internet Engineering Task Force (IETF).
 
RFC 1415 FTP-FTAM Gateway Specification
 
Authors:J. Mindel, R. Slaski.
Date:January 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1415
This memo describes a dual protocol stack application layer gateway that performs protocol translation, in an interactive environment, between the FTP and FTAM file transfer protocols.

Two key assumptions are made: 1) POSIX file naming conventions and hierarchical organization, rather than proprietary conventions are in use; and 2) X.500 Directory Services are available.

 
RFC 1418 SNMP over OSI
 
Authors:M. Rose.
Date:March 1993
Formats:txt pdf
Obsoletes:RFC 1161, RFC 1283
Status:HISTORIC
DOI:10.17487/RFC 1418
This memo addresses some concerns by defining a framework for running the SNMP in an environment which supports the OSI connectionless-mode transport service. [STANDARDS-TRACK]
 
RFC 1419 SNMP over AppleTalk
 
Authors:G. Minshall, M. Ritter.
Date:March 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1419
This memo describes the method by which the Simple Network Management Protocol (SNMP) as specified in [1] can be used over AppleTalk protocols [2] instead of the Internet UDP/IP protocol stack. [STANDARDS-TRACK]
 
RFC 1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures
 
Authors:J. Linn.
Date:February 1993
Formats:txt pdf
Obsoletes:RFC 1113
Status:HISTORIC
DOI:10.17487/RFC 1421
This document defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. [STANDARDS-TRACK]
 
RFC 1422 Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management
 
Authors:S. Kent.
Date:February 1993
Formats:txt pdf
Obsoletes:RFC 1114
Status:HISTORIC
DOI:10.17487/RFC 1422
This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. [STANDARDS-TRACK]
 
RFC 1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers
 
Authors:D. Balenson.
Date:February 1993
Formats:txt pdf
Obsoletes:RFC 1115
Status:HISTORIC
DOI:10.17487/RFC 1423
This document provides definitions, formats, references, and citations for cryptographic algorithms, usage modes, and associated identifiers and parameters used in support of Privacy Enhanced Mail(PEM) in the Internet community. It is intended to become one member of the set of related PEM RFCs. This document is organized into four primary sections, dealing with message encryption algorithms, message integrity check algorithms, symmetric key management algorithms, and asymmetric key management algorithms (including both asymmetric encryption and asymmetric signature algorithms).

Some parts of this material are cited by other documents and it is anticipated that some of the material herein may be changed, added, or replaced without affecting the citing documents. Therefore, algorithm-specific material has been placed into this separate document.

Use of other algorithms and/or modes will require case-by-case study to determine applicability and constraints. The use of additional algorithms may be documented first in Prototype or Experimental RFCs.As experience is gained, these protocols may be considered for incorporation into the standard. Additional algorithms and modes approved for use in PEM in this context will be specified in successors to this document.

 
RFC 1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services
 
Authors:B. Kaliski.
Date:February 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1424
This document describes three types of service in support of Internet Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate- revocation list (CRL) storage, and CRL retrieval. [STANDARDS-TRACK]
 
RFC 1441 Introduction to version 2 of the Internet-standard Network Management Framework
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:April 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1441
The purpose of this document is to provide an overview of version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2). [STANDARDS-TRACK]
 
RFC 1445 Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)
 
Authors:J. Galvin, K. McCloghrie.
Date:April 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1445
It is the purpose of this document, the Administrative Model for SNMPv2, to define how the administrative framework is applied to realize effective network management in a variety of configurations and environments. [STANDARDS-TRACK]
 
RFC 1446 Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)
 
Authors:J. Galvin, K. McCloghrie.
Date:April 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1446
It is the purpose of this document, Security Protocols for SNMPv2, to define one such authentication and one such privacy protocol. [STANDARDS-TRACK]
 
RFC 1447 Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)
 
Authors:K. McCloghrie, J. Galvin.
Date:April 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1447
The Administrative Model for SNMPv2 document [3] defines the properties associated with SNMPv2 parties, SNMPv2 contexts, and access control policies. It is the purpose of this document, the Party MIB for SNMPv2, to define managed objects which correspond to these properties. [STANDARDS-TRACK]
 
RFC 1451 Manager-to-Manager Management Information Base
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:April 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1451
It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity acting in both a manager role and an agent role. [STANDARDS-TRACK]
 
RFC 1461 SNMP MIB extension for Multiprotocol Interconnect over X.25
 
Authors:D. Throop.
Date:May 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1461
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing MultiprotocolInterconnect (including IP) traffic carried over X.25. The objects defined here, along with the objects in the "SNMP MIB extension for the Packet Layer of X.25"[8], "SNMP MIB extension for LAPB"[7], and the "Definitions of Managed Objects for RS-232-like Hardware Devices"[6], combine to allow management of the traffic over an X.25 protocol stack.
 
RFC 1467 Status of CIDR Deployment in the Internet
 
Authors:C. Topolcic.
Date:August 1993
Formats:txt pdf
Obsoletes:RFC 1367
Status:HISTORIC
DOI:10.17487/RFC 1467
This document describes the current status of the development and deployment of CIDR technology into the Internet. This document replaces RFC 1367, which was a schedule for the deployment of IP address space management procedures to support route aggregation.Since all the milestones proposed in RFC 1367 except for the delivery and installation of CIDR software were met, it does not seem appropriate to issue an updated schedule. Rather, this document is intended to provide information about how this effort is proceeding, which may be of interest to the community.
 
RFC 1469 IP Multicast over Token-Ring Local Area Networks
 
Authors:T. Pusateri.
Date:June 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1469
This document specifies a method for the transmission of IP multicast datagrams over Token-Ring Local Area Networks. Although an interim solution has emerged and is currently being used, it is the intention of this document to specify a more efficient means of transmission using an assigned Token-Ring functional address.
 
RFC 1474 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol
 
Authors:F. Kastenholz.
Date:June 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1474
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it describes managed objects used for managing the bridge Network Control Protocol [10] on subnetwork interfaces using the family of Point-to-Point Protocols.
 
RFC 1475 TP/IX: The Next Internet
 
Authors:R. Ullmann.
Date:June 1993
Formats:txt pdf
Obsoleted by:RFC 6814
Status:HISTORIC
DOI:10.17487/RFC 1475
The first version of this memo, describing a possible next generation of Internet protocols, was written by the present author in the summer and fall of 1989, and circulated informally, including to theIESG, in December 1989. A further informal note on the addressing, called "Toasternet Part II", was circulated on the IETF mail list during March of 1992.
 
RFC 1478 An Architecture for Inter-Domain Policy Routing
 
Authors:M. Steenstrup.
Date:June 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1478
We present an architecture for inter-domain policy routing (IDPR).The objective of IDPR is to construct and maintain routes, between source and destination administrative domains, that provide user traffic with the requested services within the constraints stipulated for the domains transited. The IDPR architecture is designed to accommodate an internetwork containing tens of thousands of administrative domains with heterogeneous service requirements and restrictions.
 
RFC 1479 Inter-Domain Policy Routing Protocol Specification: Version 1
 
Authors:M. Steenstrup.
Date:July 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1479
We present the set of protocols and procedures that constituteInter-Domain Policy Routing (IDPR). IDPR includes the virtual gateway protocol, the flooding protocol, the route server query protocol, the route generation procedure, the path control protocol, and the data message forwarding procedure.
 
RFC 1481 IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling
 
Authors:C. Huitema.
Date:July 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1481
CIDR is proposed as an immediate term strategy to extend the life of the current 32 bit IP address space. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1482 Aggregation Support in the NSFNET Policy-Based Routing Database
 
Authors:M. Knopper, S. Richardson.
Date:June 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1482
This document describes plans for support of route aggregation, as specified in the descriptions of Classless Inter-Domain Routing(CIDR) [1] and the BGP-4 protocol [2], by the NSFNET Backbone NetworkService. Mechanisms for exchange of route aggregates between the backbone service and regional/midlevel networks are specified.Additionally, the memo proposes the implementation of an AggregateRegistry which can be used by network service providers to share information about the use of aggregation. Finally, the operational impact of incorporating CIDR and aggregation is considered, including an analysis of how routing table size will be affected. This impact analysis will be used to modify the deployment plan, if necessary, to maximize operational stability.
 
RFC 1484 Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2))
 
Authors:S. Hardcastle-Kille.
Date:July 1993
Formats:txt pdf
Obsoleted by:RFC 1781, RFC 3494
Status:HISTORIC
DOI:10.17487/RFC 1484
The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability

This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a format for representing names, and to procedures to resolve them. This leads to a specification which allows directory names to be communicated between humans. The format in this specification is identical to that defined in [HK93], and it is intended that these specifications are compatible. Please send comments to the author or to the discussion group: <osi-ds@CS.UCL.AC.UK&rt;.

 
RFC 1485 A String Representation of Distinguished Names (OSI-DS 23 (v5))
 
Authors:S. Hardcastle-Kille.
Date:July 1993
Formats:txt pdf
Obsoleted by:RFC 1779, RFC 3494
Status:HISTORIC
DOI:10.17487/RFC 1485
The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1.When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name. Please send comments to the author or to the discussion group <osi-ds@CS.UCL.AC.UK&rt;.
 
RFC 1487 X.500 Lightweight Directory Access Protocol
 
Authors:W. Yeong, T. Howes, S. Kille.
Date:July 1993
Formats:txt pdf
Obsoleted by:RFC 1777, RFC 3494
Status:HISTORIC
DOI:10.17487/RFC 1487
The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of theDirectory Access Protocol (DAP). This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the Directory, and is intended to be a complement to the DAP itself.

Key aspects of LDAP are:

- Protocol elements are carried directly over TCP or other transport, bypassing much of the session/presentation overhead.

- Many protocol data elements are encoding as ordinary strings (e.g.,Distinguished Names).

- A lightweight BER encoding is used to encode all protocol elements.

 
RFC 1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies
 
Authors:H. Alvestrand, S. Thompson.
Date:August 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1494
This document describes the content of the "IANA MHS/MIME Equivalence table", and defines the initial configuration of this table. Mappings for new MIME content-types and/or X.400 body part types should be registered with the IANA to minimize redundancy and promote interoperability. [STANDARDS-TRACK]
 
RFC 1496 Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages
 
Authors:H. Alvestrand, J. Romaguera, K. Jordan.
Date:August 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1496
This document describes how RFC-1328 must be modified in order to provide adequate support for the scenarios: It replaces chapter 6 of RFC-1328. The rest of RFC-1328 is NOT obsoleted. [STANDARDS-TRACK]
 
RFC 1500 Internet Official Protocol Standards
 
Authors:J. Postel.
Date:August 1993
Formats:txt pdf
Obsoletes:RFC 1410
Obsoleted by:RFC 1540
Status:HISTORIC
DOI:10.17487/RFC 1500
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]
 
RFC 1502 X.400 Use of Extended Character Sets
 
Authors:H. Alvestrand.
Date:August 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1502
This RFC defines a suggested method of using "GeneralText" in order to harmonize as much as possible the usage of this body part. [STANDARDS- TRACK]
 
RFC 1510 The Kerberos Network Authentication Service (V5)
 
Authors:J. Kohl, C. Neuman.
Date:September 1993
Formats:txt pdf
Obsoleted by:RFC 4120, RFC 6649
Status:HISTORIC
DOI:10.17487/RFC 1510
This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. Version 4, described elsewhere [1,2], is presently in production use at MIT'sProject Athena, and at other Internet sites.
 
RFC 1512 FDDI Management Information Base
 
Authors:J. Case, A. Rijsinghani.
Date:September 1993
Formats:txt pdf
Updates:RFC 1285
Status:HISTORIC
DOI:10.17487/RFC 1512
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing devices which implement the FDDI based on the ANSI FDDI SMT 7.3 draft standard [8], which has been forwarded for publication by the X3T9.5 committee.
 
RFC 1513 Token Ring Extensions to the Remote Network Monitoring MIB
 
Authors:S. Waldbusser.
Date:September 1993
Formats:txt pdf
Updates:RFC 1271
Status:HISTORIC
DOI:10.17487/RFC 1513
This memo defines extensions to the Remote Network Monitoring MIB for managing 802.5 Token Ring networks.

The Remote Network Monitoring MIB, RFC 1271, defines a framework for remote monitoring functions implemented on a network probe. That MIB defines objects broken down into nine functional groups. Some of those functional groups, the statistics and the history groups, have a view of the data-link layer that is specific to the media type and require specific objects to be defined for each media type. RFC 1271 defined those specific objects necessary for Ethernet. This companion memo defines those specific objects necessary for TokenRing LANs.

In addition, this memo defines some additional monitoring functions specifically for Token Ring. These are defined in the Ring StationGroup, the Ring Station Order Group, the Ring Station ConfigurationGroup, and the Source Routing Statistics Group.

 
RFC 1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)
 
Authors:Internet Engineering Steering Group, R. Hinden.
Date:September 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1517
Classless Inter-Domain Routing (CIDR) defines a mechanism to slow the growth of routing tables and reduce the need to allocate new IP network numbers. [STANDARDS-TRACK]
 
RFC 1518 An Architecture for IP Address Allocation with CIDR
 
Authors:Y. Rekhter, T. Li.
Date:September 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1518
This paper provides an architecture and a plan for allocating IP addresses in the Internet. This architecture and the plan are intended to play an important role in steering the Internet towards the Address Assignment and Aggregating Strategy. [STANDARDS-TRACK]
 
RFC 1520 Exchanging Routing Information Across Provider Boundaries in the CIDR Environment
 
Authors:Y. Rekhter, C. Topolcic.
Date:September 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1520
The purpose of this document is twofold. First, it describes various alternatives for exchanging inter-domain routing information across domain boundaries, where one of the peering domain is CIDR-capable and another is not. Second, it addresses the implications of running CIDR- capable inter-domain routing protocols (e.g., BGP-4, IDRP) on intra- domain routing. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1525 Definitions of Managed Objects for Source Routing Bridges
 
Authors:E. Decker, K. McCloghrie, P. Langille, A. Rijsinghani.
Date:September 1993
Formats:txt pdf
Obsoletes:RFC 1286
Status:HISTORIC
DOI:10.17487/RFC 1525
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing source routing and source routing transparent bridges. These bridges are also required to implement relevant groups in the Bridge MIB. [STANDARDS-TRACK]
 
RFC 1540 Internet Official Protocol Standards
 
Authors:J. Postel.
Date:October 1993
Formats:txt pdf
Obsoletes:RFC 1500
Obsoleted by:RFC 1600
Status:HISTORIC
DOI:10.17487/RFC 1540
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]
 
RFC 1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP)
 
Authors:W. Simpson.
Date:December 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1552
The Point-to-Point Protocol (PPP) [1] provides a method for transmitting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.

The IPX protocol was originally used in Novell's NetWare products[3], and is now supported by numerous other vendors. This document defines the Network Control Protocol for establishing and configuring the IPX protocol over PPP.

This memo is the product of the Point-to-Point Protocol Working Group of the IETF. Comments should be submitted to the ietf- ppp@ucdavis.edu mailing list.

 
RFC 1553 Compressing IPX Headers Over WAN Media (CIPX)
 
Authors:S. Mathur, M. Lewis.
Date:December 1993
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1553
This document describes a method for compressing the headers of IPX datagrams (CIPX). With this method, it is possible to significantly improve performance over lower speed wide area network (WAN) media. For normal IPX packet traffic, CIPX can provide a compression ratio of approximately 2:1 including both IPX header and data. This method can be used on various type of WAN media, including those supporting PPP and X.25.

This memo ia a product of the Point-to-Point Protocol Extensions(PPPEXT) Working Group of the IETF. Comments should be sent to the authors and the ietf-ppp@ucdavis.edu mailing list.

 
RFC 1584 Multicast Extensions to OSPF
 
Authors:J. Moy.
Date:March 1994
Formats:txt pdf ps
Status:HISTORIC
DOI:10.17487/RFC 1584
This memo documents enhancements to the OSPF protocol enabling the routing of IP multicast datagrams. In this proposal, an IP multicast packet is routed based both on the packet's source and its multicast destination (commonly referred to as source/destination routing). As it is routed, the multicast packet follows a shortest path to each multicast destination. During packet forwarding, any commonality of paths is exploited; when multiple hosts belong to a single multicast group, a multicast packet will be replicated only when the paths to the separate hosts diverge.

OSPF, a link-state routing protocol, provides a database describing the Autonomous System's topology. A new OSPF link state advertisement is added describing the location of multicast destinations. A multicast packet's path is then calculated by building a pruned shortest-path tree rooted at the packet's IP source. These trees are built on demand, and the results of the calculation are cached for use by subsequent packets.

The multicast extensions are built on top of OSPF Version 2. The extensions have been implemented so that a multicast routing capability can be introduced piecemeal into an OSPF Version 2 routing domain. Some of the OSPF Version 2 routers may run the multicast extensions, while others may continue to be restricted to the forwarding of regular IP traffic (unicasts).

Please send comments to mospf@gated.cornell.edu.

 
RFC 1600 Internet Official Protocol Standards
 
Authors:J. Postel.
Date:March 1994
Formats:txt pdf
Obsoletes:RFC 1540
Obsoleted by:RFC 1610
Status:HISTORIC
DOI:10.17487/RFC 1600
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
 
RFC 1610 Internet Official Protocol Standards
 
Authors:J. Postel.
Date:July 1994
Formats:txt pdf
Obsoletes:RFC 1600
Obsoleted by:RFC 1720
Status:HISTORIC
DOI:10.17487/RFC 1610
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
 
RFC 1611 DNS Server MIB Extensions
 
Authors:R. Austein, J. Saperia.
Date:May 1994
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1611
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS name server functions. This memo was produced by the DNS working group. [STANDARDS-TRACK]
 
RFC 1612 DNS Resolver MIB Extensions
 
Authors:R. Austein, J. Saperia.
Date:May 1994
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1612
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS resolver functions. This memo was produced by the DNS working group. [STANDARDS-TRACK]
 
RFC 1621 Pip Near-term Architecture
 
Authors:P. Francis.
Date:May 1994
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1621
Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to evolve to all forseeable internet protocol requirements. This specification describes the routing and addressing architecture for near-term Pip deployment. We say near-term only because Pip is designed with evolution in mind, so other architectures are expected in the future. This document, however, makes no reference to such future architectures.
 
RFC 1622 Pip Header Processing
 
Authors:P. Francis.
Date:May 1994
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1622
Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to handle all forseeable internet protocol requirements. This specification defines the Pip header processing for Routers andHosts.
 
RFC 1623 Definitions of Managed Objects for the Ethernet-like Interface Types
 
Authors:F. Kastenholz.
Date:May 1994
Formats:txt pdf
Obsoletes:RFC 1398
Obsoleted by:RFC 1643
Status:HISTORIC
DOI:10.17487/RFC 1623
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]
 
RFC 1643 Definitions of Managed Objects for the Ethernet-like Interface Types
 
Authors:F. Kastenholz.
Date:July 1994
Formats:txt pdf
Obsoletes:RFC 1623
Obsoleted by:RFC 3638
Status:HISTORIC
DOI:10.17487/RFC 1643
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]
 
RFC 1644 T/TCP -- TCP Extensions for Transactions Functional Specification
 
Authors:R. Braden.
Date:July 1994
Formats:txt pdf
Obsoleted by:RFC 6247
Updates:RFC 1379
Status:HISTORIC
DOI:10.17487/RFC 1644
This memo specifies T/TCP, an experimental TCP extension for efficient transaction-oriented (request/response) service. This backwards-compatible extension could fill the gap between the current connection-oriented TCP and the datagram-based UDP.

This work was supported in part by the National Science Foundation under Grant Number NCR-8922231.

 
RFC 1648 Postmaster Convention for X.400 Operations
 
Authors:A. Cargille.
Date:July 1994
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1648
Both STD 11, RFC 822 [1] and STD 3, RFC 1123 [2] (Host Requirements) require that the email address "postmaster" be supported at all hosts. This paper extends this concept to X.400 mail domains which have registered RFC 1327 mapping rules, and which therefore appear to have normal RFC822-style addresses.
 
RFC 1666 Definitions of Managed Objects for SNA NAUs using SMIv2
 
Authors:Z. Kielczewski, Ed., D. Kostick, Ed., K. Shih, Ed..
Date:August 1994
Formats:txt pdf
Obsoletes:RFC 1665
Status:HISTORIC
DOI:10.17487/RFC 1666
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]
 
RFC 1692 Transport Multiplexing Protocol (TMux)
 
Authors:P. Cameron, D. Crocker, D. Cohen, J. Postel.
Date:August 1994
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1692
One of the problems with the use of terminal servers is the large number of small packets they can generate. Frequently, most of these packets are destined for only one or two hosts. TMux is a protocol which allows multiple short transport segments, independent of application type, to be combined between a server and host pair.
 
RFC 1693 An Extension to TCP : Partial Order Service
 
Authors:T. Connolly, P. Amer, P. Conrad.
Date:November 1994
Formats:txt pdf
Obsoleted by:RFC 6247
Status:HISTORIC
DOI:10.17487/RFC 1693
This RFC introduces a new transport mechanism for TCP based upon partial ordering. The aim is to present the concepts of partial ordering and promote discussions on its usefulness in network communications. Distribution of this memo is unlimited.
 
RFC 1696 Modem Management Information Base (MIB) using SMIv2
 
Authors:J. Barnes, L. Brown, R. Royston, S. Waldbusser.
Date:August 1994
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1696
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing dial-up modems and similar dial-up devices. [STANDARDS-TRACK]
 
RFC 1700 Assigned Numbers
 
Authors:J. Reynolds, J. Postel.
Date:October 1994
Formats:txt pdf
Obsoletes:RFC 1340
Obsoleted by:RFC 3232
Status:HISTORIC
DOI:10.17487/RFC 1700
This RFC is a snapshot of the ongoing process of the assignment of protocol parameters for the Internet protocol suite. To make the current information readily available the assignments are kept up-to- date in a set of online text files. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.
 
RFC 1707 CATNIP: Common Architecture for the Internet
 
Authors:M. McGovern, R. Ullmann.
Date:October 1994
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1707
This document was submitted to the IETF IPng area in response to RFC1550 Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list.
 
RFC 1720 Internet Official Protocol Standards
 
Authors:J. Postel.
Date:November 1994
Formats:txt pdf
Obsoletes:RFC 1610
Obsoleted by:RFC 1780
Status:HISTORIC
DOI:10.17487/RFC 1720
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
 
RFC 1742 AppleTalk Management Information Base II
 
Authors:S. Waldbusser, K. Frisa.
Date:January 1995
Formats:txt pdf
Obsoletes:RFC 1243
Status:HISTORIC
DOI:10.17487/RFC 1742
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing AppleTalk networks.

RFC 1243 defines a set of MIB objects for managing the lower layers of the AppleTalk protocol stack, up to the Network layer. This memo defines additional objects that exist in the AppleTalk portion of theMIB. These objects provide for the management of the transport and session layers of the AppleTalk protocol stack, as well as extensions to the lower layers. This is achieved in an upwardly-compatable fashion.

 
RFC 1745 BGP4/IDRP for IP---OSPF Interaction
 
Authors:K. Varadhan, S. Hares, Y. Rekhter.
Date:December 1994
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1745
This memo defines the various criteria to be used when designing anAutonomous System Border Router (ASBR) that will run either BGP4 orIDRP for IP with other ASBRs external to the AS and OSPF as its IGP.
 
RFC 1747 Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2
 
Authors:J. Hilgeman, S. Nix, A. Bartky, W. Clark, Ed..
Date:January 1995
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1747
This specification defines an extension to the Management InformationBase (MIB) for use with SNMP-based network management. In particular, it defines objects for managing the configuration, monitoring and control of data link controls in an SNA environment.This draft identifies managed objects for SNA Synchronous Data LinkControl (SDLC) links only.
 
RFC 1749 IEEE 802.5 Station Source Routing MIB using SMIv2
 
Authors:K. McCloghrie, F. Baker, E. Decker.
Date:December 1994
Formats:txt pdf
Updates:RFC 1748
Status:HISTORIC
DOI:10.17487/RFC 1749
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used by IEEE 802.5 end-stations for managing source routes on a Token Ring network where IEEE source- routing is in use. [STANDARDS-TRACK]
 
RFC 1763 The PPP Banyan Vines Control Protocol (BVCP)
 
Authors:S. Senum.
Date:March 1995
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1763
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.

This document defines the Network Control Protocol for establishing and configuring the Banyan VINES protocol over PPP.

 
RFC 1764 The PPP XNS IDP Control Protocol (XNSCP)
 
Authors:S. Senum.
Date:March 1995
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1764
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.

This document defines the Network Control Protocol for establishing and configuring the Xerox Network Systems (XNS) Internet DatagramProtocol (IDP) over PPP.

 
RFC 1770 IPv4 Option for Sender Directed Multi-Destination Delivery
 
Authors:C. Graff.
Date:March 1995
Formats:txt pdf
Obsoleted by:RFC 6814
Status:HISTORIC
DOI:10.17487/RFC 1770
This memo defines an IPv4 option to provide a sender directed multi- destination delivery mechanism called Selective Directed BroadcastMode (SDBM). The SDBM provides unreliable UDP delivery to a set ofIP addresses included in the option field of an IPv4 datagram. Data reliability if required will be provided by the application layer.This approach was developed to support sender directed multi- destination delivery to sparsely populated groups with no additional control traffic. This approach will find application in the extremely bandwidth constrained tactical military environment, as well as in some commercial applications requiring sender control of data delivery.
 
RFC 1777 Lightweight Directory Access Protocol
 
Authors:W. Yeong, T. Howes, S. Kille.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1487
Obsoleted by:RFC 3494
Status:HISTORIC
DOI:10.17487/RFC 1777
The protocol described in this document is designed to provide access to the X.500 Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the X.500Directory, and is intended to be a complement to the DAP itself.

Key aspects of LDAP are:

- Protocol elements are carried directly over TCP or other transport, bypassing much of the session/presentation overhead.

- Many protocol data elements are encoding as ordinary strings (e.g.,Distinguished Names).

- A lightweight BER encoding is used to encode all protocol elements.

 
RFC 1778 The String Representation of Standard Attribute Syntaxes
 
Authors:T. Howes, S. Kille, W. Yeong, C. Robbins.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1488
Obsoleted by:RFC 3494
Updated by:RFC 2559
Status:HISTORIC
DOI:10.17487/RFC 1778
The Lightweight Directory Access Protocol (LDAP) [9] requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render X.500 Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3].
 
RFC 1779 A String Representation of Distinguished Names
 
Authors:S. Kille.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1485
Obsoleted by:RFC 2253, RFC 3494
Status:HISTORIC
DOI:10.17487/RFC 1779
The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1.When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name.This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name.
 
RFC 1780 Internet Official Protocol Standards
 
Authors:J. Postel, Ed..
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1720
Obsoleted by:RFC 1800
Status:HISTORIC
DOI:10.17487/RFC 1780
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
 
RFC 1781 Using the OSI Directory to Achieve User Friendly Naming
 
Authors:S. Kille.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1484
Obsoleted by:RFC 3494
Status:HISTORIC
DOI:10.17487/RFC 1781
The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability

This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them.This leads to a specification which allows directory names to be communicated between humans. The format in this specification is identical to that defined in [5], and it is intended that these specifications are compatible.

 
RFC 1788 ICMP Domain Name Messages
 
Authors:W. Simpson.
Date:April 1995
Formats:txt pdf
Obsoleted by:RFC 6918
Status:HISTORIC
DOI:10.17487/RFC 1788
This document specifies ICMP messages for learning the FullyQualified Domain Name associated with an IP address.
 
RFC 1798 Connection-less Lightweight X.500 Directory Access Protocol
 
Authors:A. Young.
Date:June 1995
Formats:txt pdf
Obsoleted by:RFC 3352
Status:HISTORIC
DOI:10.17487/RFC 1798
The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK]
 
RFC 1800 Internet Official Protocol Standards
 
Authors:J. Postel, Ed..
Date:July 1995
Formats:txt pdf
Obsoletes:RFC 1780
Obsoleted by:RFC 1880
Status:HISTORIC
DOI:10.17487/RFC 1800
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
 
RFC 1817 CIDR and Classful Routing
 
Authors:Y. Rekhter.
Date:August 1995
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1817
Classless Inter-Domain Routing (CIDR) is used in the Internet as the primary mechanism to improve scalability of the Internet routing system. This document represents the IAB's (Internet ArchitectureBoard) evaluation of the current and near term implications of CIDR on organizations that use Classful routing technology.
 
RFC 1818 Best Current Practices
 
Authors:J. Postel, T. Li, Y. Rekhter.
Date:August 1995
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1818
This document describes a new series of documents which describe best current practices for the Internet community. Documents in this series carry the endorsement of the Internet Engineering SteeringGroup (IESG).
 
RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+
 
Authors:L. Delgrossi, Ed., L. Berger, Ed..
Date:August 1995
Formats:txt pdf
Obsoletes:RFC 1190, IEN119
Status:HISTORIC
DOI:10.17487/RFC 1819
This memo contains a revised specification of the Internet STreamProtocol Version 2 (ST2). ST2 is an experimental resource reservation protocol intended to provide end-to-end real-time guarantees over an internet. It allows applications to build multi-destination simplex data streams with a desired quality of service. The revised version of ST2 specified in this memo is called ST2+.

This specification is a product of the STream Protocol Working Group of the Internet Engineering Task Force.

 
RFC 1828 IP Authentication using Keyed MD5
 
Authors:P. Metzger, W. Simpson.
Date:August 1995
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1828
This document describes the use of keyed MD5 with the IPAuthentication Header.
 
RFC 1835 Architecture of the WHOIS++ service
 
Authors:P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider.
Date:August 1995
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1835
This document describes WHOIS++, an extension to the trivial WHOIS service described in RFC 954 to permit WHOIS-like servers to make available more structured information to the Internet. We describe an extension to the simple WHOIS data model and query protocol and a companion extensible, distributed indexing service. A number of options have also been added such as the use of multiple languages and character sets, more advanced search expressions, structured data and a number of other useful features. An optional authentication mechanism for protecting all or part of the associated WHOIS++ information database from unauthorized access is also described.
 
RFC 1848 MIME Object Security Services
 
Authors:S. Crocker, N. Freed, J. Galvin, S. Murphy.
Date:October 1995
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1848
This document defines MIME Object Security Services (MOSS), a protocol that uses the multipart/signed and multipart/encrypted framework [7] to apply digital signature and encryption services toMIME objects. The services are offered through the use of end-to-end cryptography between an originator and a recipient at the application layer. Asymmetric (public key) cryptography is used in support of the digital signature service and encryption key management.Symmetric (secret key) cryptography is used in support of the encryption service. The procedures are intended to be compatible with a wide range of public key management approaches, including both ad hoc and certificate-based schemes. Mechanisms are provided to support many public key management approaches.
 
RFC 1849 "Son of 1036": News Article Format and Transmission
 
Authors:H. Spencer.
Date:March 2010
Formats:txt pdf
Obsoleted by:RFC 5536, RFC 5537
Status:HISTORIC
DOI:10.17487/RFC 1849
By the early 1990s, it had become clear that RFC 1036, then the specification for the Interchange of USENET Messages, was badly in need of repair. This "Internet-Draft-to-be", though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the nickname "Son of 1036". Indeed, under that name, it could fairly be described as the best-known Internet Draft (n)ever published, and it formed the starting point for the recently adoptedProposed Standards for Netnews.

It is being published now in order to provide the historical background out of which those standards have grown. Present-day implementors should be aware that it is NOT NOW APPROPRIATE for use in current implementations.

 
RFC 1863 A BGP/IDRP Route Server alternative to a full mesh routing
 
Authors:D. Haskin.
Date:October 1995
Formats:txt pdf
Obsoleted by:RFC 4223
Status:HISTORIC
DOI:10.17487/RFC 1863
This document describes the use and detailed design of Route Servers for dissemination of routing information among BGP/IDRP speaking routers.

The intention of the proposed technique is to reduce overhead and management complexity of maintaining numerous direct BGP/IDRP sessions which otherwise might be required or desired among routers within a single routing domain as well as among routers in different domains that are connected to a common switched fabric (e.g. an ATM cloud).

 
RFC 1866 Hypertext Markup Language - 2.0
 
Authors:T. Berners-Lee, D. Connolly.
Date:November 1995
Formats:txt pdf
Obsoleted by:RFC 2854
Status:HISTORIC
DOI:10.17487/RFC 1866
The Hypertext Markup Language (HTML) is a simple markup language used to create hypertext documents that are platform independent. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML markup can represent hypertext news, mail, documentation, and hypermedia; menus of options; database query results; simple structured documents with in-lined graphics; and hypertext views of existing bodies of information.

HTML has been in use by the World Wide Web (WWW) global information initiative since 1990. This specification roughly corresponds to the capabilities of HTML in common use prior to June 1994. HTML is an application of ISO Standard 8879:1986 Information Processing Text andOffice Systems; Standard Generalized Markup Language (SGML).

The "text/html" Internet Media Type (RFC 1590) and MIME Content Type(RFC 1521) is defined by this specification.

 
RFC 1867 Form-based File Upload in HTML
 
Authors:E. Nebel, L. Masinter.
Date:November 1995
Formats:txt pdf
Obsoleted by:RFC 2854
Status:HISTORIC
DOI:10.17487/RFC 1867
Since file-upload is a feature that will benefit many applications, this proposes an extension to HTML to allow information providers to express file upload requests uniformly, and a MIME compatible representation for file upload responses. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1871 Addendum to RFC 1602 -- Variance Procedure
 
Authors:J. Postel.
Date:November 1995
Formats:txt pdf
Obsoleted by:RFC 2026
Updates:RFC 1602, RFC 1603
Status:HISTORIC
DOI:10.17487/RFC 1871
This document describes a modification to the IETF procedures to allow an escape from a situation where the existing procedures are not working or do not seem to apply. This is a modification to the procedures of RFC 1602 and 1603.
 
RFC 1878 Variable Length Subnet Table For IPv4
 
Authors:T. Pummill, B. Manning.
Date:December 1995
Formats:txt pdf
Obsoletes:RFC 1860
Status:HISTORIC
DOI:10.17487/RFC 1878
This memo clarifies issues surrounding subnetting IP networks by providing a standard subnet table. This table includes subnetting for Class A, B, and C networks, as well as Network IDs, host ranges and IP broadcast addresses with emphasis on Class C subnets.

This memo is intended as an informational companion to Subneting RFC[1] and the Hosts Requirements RFC [2].

 
RFC 1880 Internet Official Protocol Standards
 
Authors:J. Postel, Ed..
Date:November 1995
Formats:txt pdf
Obsoletes:RFC 1800
Obsoleted by:RFC 1920
Status:HISTORIC
DOI:10.17487/RFC 1880
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
 
RFC 1884 IP Version 6 Addressing Architecture
 
Authors:R. Hinden, Ed., S. Deering, Ed..
Date:December 1995
Formats:txt pdf
Obsoleted by:RFC 2373
Status:HISTORIC
DOI:10.17487/RFC 1884
This specification defines the addressing architecture of the IPVersion 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 nodes required addresses.
 
RFC 1888 OSI NSAPs and IPv6
 
Authors:J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd.
Date:August 1996
Formats:txt pdf
Obsoleted by:RFC 4048
Updated by:RFC 4548
Status:HISTORIC
DOI:10.17487/RFC 1888
This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. However, it also defines a set of mechanisms for the support of OSI NSAP addressing in an IPv6 network. These mechanisms are the ones that MUST be used if such support is required. This document also defines a mapping of IPv6 addresses within the OSI address format, should this be required.
 
RFC 1901 Introduction to Community-based SNMPv2
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:January 1996
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1901
The purpose of this document is to define the Community-based Administrative Framework for the SNMP version 2 framework (SNMPv2). This document specifies an Experimental protocol for the Internet community.
 
RFC 1909 An Administrative Infrastructure for SNMPv2
 
Authors:K. McCloghrie, Ed..
Date:February 1996
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1909
It is the purpose of this document, An Administrative Infrastructure for SNMPv2, to define an administrative framework which realizes effective management in a variety of configurations and environments. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1910 User-based Security Model for SNMPv2
 
Authors:G. Waters, Ed..
Date:February 1996
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1910
In this administrative framework, a security model defines the mechanisms used to achieve an administratively-defined level of security for protocol interactions. Although many such security models might be defined, it is the purpose of this document, User-based Security Model for SNMPv2, to define the first, and, as of this writing, only, security model for this administrative framework. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1913 Architecture of the Whois++ Index Service
 
Authors:C. Weider, J. Fullton, S. Spero.
Date:February 1996
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1913
The authors describe an architecture for indexing in distributed databases, and apply this to the WHOIS++ protocol.
 
RFC 1914 How to Interact with a Whois++ Mesh
 
Authors:P. Faltstrom, R. Schoultz, C. Weider.
Date:February 1996
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1914
In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is done by the client, since each server 'refers' the client to the next appropriate server(s). [STANDARDS-TRACK]
 
RFC 1920 Internet Official Protocol Standards
 
Authors:J. Postel.
Date:March 1996
Formats:txt pdf
Obsoletes:RFC 1880
Obsoleted by:RFC 2000
Status:HISTORIC
DOI:10.17487/RFC 1920
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
 
RFC 1942 HTML Tables
 
Authors:D. Raggett.
Date:May 1996
Formats:txt pdf
Obsoleted by:RFC 2854
Status:HISTORIC
DOI:10.17487/RFC 1942
The HyperText Markup Language (HTML) is a simple markup language used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of applications. This specification extends HTML to support a wide variety of tables. The model is designed to work well with associated style sheets, but does not require them. It also supports rendering to braille, or speech, and exchange of tabular data with databases and spreadsheets. The HTML table model embodies certain aspects of the CALS table model, e.g. the ability to group table rows into thead, tbody and tfoot sections, plus the ability to specify cell alignment compactly for sets of cells according to the context.
 
RFC 1980 A Proposed Extension to HTML : Client-Side Image Maps
 
Authors:J. Seidman.
Date:August 1996
Formats:txt pdf
Obsoleted by:RFC 2854
Status:HISTORIC
DOI:10.17487/RFC 1980
The markup language known as "HTML/2.0" provides for image maps.Image maps are document elements which allow clicking different areas of an image to reference different network resources, as specified byUniform Identifier (URIs). The image map capability in HTML/2.0 is limited in several ways, such as the restriction that it only works with documents served via the "HTTP" protocol, and the lack of a viable fallback for users of text-only browsers. This document specifies an extension to the HTML language, referred to as "Client-Side Image Maps," which resolves these limitations.
 
RFC 2000 Internet Official Protocol Standards
 
Authors:J. Postel, Ed..
Date:February 1997
Formats:txt pdf
Obsoletes:RFC 1920
Obsoleted by:RFC 2200
Status:HISTORIC
DOI:10.17487/RFC 2000
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard.
 
RFC 2036 Observations on the use of Components of the Class A Address Space within the Internet
 
Authors:G. Huston.
Date:October 1996
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 2036
This document is a commentary on the recommendation that IANA commence allocation of the presently unallocated components of theClass A address space to registries, for deployment within theInternet as class-less address blocks.

The document examines the implications for service providers and end clients within this environment. The document notes the major conclusion that widespread adoption of class-less routing protocols is required, within a relatively rapid timeframe for this recommendation to be effective.

 
RFC 2050 Internet Registry IP Allocation Guidelines
 
Authors:K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel.
Date:November 1996
Formats:txt pdf
Obsoletes:RFC 1466
Obsoleted by:RFC 7020
Status:HISTORIC
DOI:10.17487/RFC 2050
This document describes the registry system for the distribution of globally unique Internet address space and registry operations.Particularly this document describes the rules and guidelines governing the distribution of this address space.

This document describes the IP assignment policies currently used by the Regional Registries to implement the guidelines developed by theIANA. The guidelines and these policies are subject to revision at the direction of the IANA. The registry working group (IRE WG) will be discussing these issues and may provide advice to the IANA about possible revisions.

This document replaces RFC 1466, with all the guidelines and procedures updated and modified in the light of experience.

This document does not describe private Internet address space and multicast address space. It also does not describe regional and local refinements of the global rules and guidelines.

This document can be considered the base set of operational guidelines in use by all registries. Additional guidelines may be imposed by a particular registry as appropriate.

 
RFC 2070 Internationalization of the Hypertext Markup Language
 
Authors:F. Yergeau, G. Nicol, G. Adams, M. Duerst.
Date:January 1997
Formats:txt pdf
Obsoleted by:RFC 2854
Status:HISTORIC
DOI:10.17487/RFC 2070
The Hypertext Markup Language (HTML) is a markup language used to create hypertext documents that are platform independent. Initially, the application of HTML on the World Wide Web was seriously restricted by its reliance on the ISO-8859-1 coded character set, which is appropriate only for Western European languages. Despite this restriction, HTML has been widely used with other languages, using other coded character sets or character encodings, at the expense of interoperability.

This document is meant to address the issue of the internationalization (i18n, i followed by 18 letters followed by n) of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support. A foremost consideration is to make sure that HTML remains a valid application of SGML, while enabling its use with all languages of the world.

 
RFC 2109 HTTP State Management Mechanism
 
Authors:D. Kristol, L. Montulli.
Date:February 1997
Formats:txt pdf
Obsoleted by:RFC 2965
Status:HISTORIC
DOI:10.17487/RFC 2109
This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set- Cookie, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. [STANDARDS-TRACK]
 
RFC 2189 Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --
 
Authors:A. Ballardie.
Date:September 1997
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 2189
This document describes the Core Based Tree (CBT version 2) network layer multicast routing protocol. CBT builds a shared multicast distribution tree per group, and is suited to inter- and intra-domain multicast routing.

CBT may use a separate multicast routing table, or it may use that of underlying unicast routing, to establish paths between senders and receivers. The CBT architecture is described in [1].

This document is progressing through the IDMR working group of theIETF. CBT related documents include [1, 5, 6]. For all IDMR-related documents, see http://www.cs.ucl.ac.uk/ietf/idmr.

 
RFC 2190 RTP Payload Format for H.263 Video Streams
 
Authors:C. Zhu.
Date:September 1997
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 2190
This document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). Three modes are defined for the H.263 payload header. An RTP packet can use one of the three modes for H.263 video streams depending on the desired network packet size and H.263 encoding options employed. The shortestH.263 payload header (mode A) supports fragmentation at Group ofBlock (GOB) boundaries. The long H.263 payload headers (mode B and C) support fragmentation at Macroblock (MB) boundaries.
 
RFC 2200 Internet Official Protocol Standards
 
Authors:J. Postel.
Date:June 1997
Formats:txt pdf
Obsoletes:RFC 1250, RFC 2000
Obsoleted by:RFC 2300
Status:HISTORIC
DOI:10.17487/RFC 2200
A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]
 
RFC 2201 Core Based Trees (CBT) Multicast Routing Architecture
 
Authors:A. Ballardie.
Date:September 1997
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 2201
CBT is a multicast routing architecture that builds a single delivery tree per group which is shared by all of the group's senders and receivers. Most multicast algorithms build one multicast tree per sender (subnetwork), the tree being rooted at the sender's subnetwork. The primary advantage of the shared tree approach is that it typically offers more favourable scaling characteristics than all other multicast algorithms.

The CBT protocol [1] is a network layer multicast routing protocol that builds and maintains a shared delivery tree for a multicast group. The sending and receiving of multicast data by hosts on a subnetwork conforms to the traditional IP multicast service model[2].

CBT is progressing through the IDMR working group of the IETF. TheCBT protocol is described in an accompanying document [1]. For this, and all IDMR-related documents, see http://www.cs.ucl.ac.uk/ietf/idmr

 
RFC 2300 Internet Official Protocol Standards
 
Authors:J. Postel.
Date:May 1998
Formats:txt pdf
Obsoletes:RFC 2200
Obsoleted by:RFC 2400
Status:HISTORIC
DOI:10.17487/RFC 2300
A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]
 
RFC 2311 S/MIME Version 2 Message Specification
 
Authors:S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka.
Date:March 1998
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 2311
This document describes a protocol for adding cryptographic signature and encryption services to MIME data. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2312 S/MIME Version 2 Certificate Handling
 
Authors:S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.
Date:March 1998
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 2312
This memo describes the mechanisms S/MIME uses to create and validate keys using certificates. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2341 Cisco Layer Two Forwarding (Protocol) "L2F"
 
Authors:A. Valencia, M. Littlewood, T. Kolar.
Date:May 1998
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 2341
Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, AccessServers, and ISDN routers. Previous RFCs have specified protocols for supporting IP dial-up via SLIP [1] and multiprotocol dial-up viaPPP [2]. This document describes the Layer Two Forwarding protocol(L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols. Using such tunnels, it is possible to divorce the location of the initial dial- up server from the location at which the dial-up protocol connection is terminated and access to the network provided.
 
RFC 2374 An IPv6 Aggregatable Global Unicast Address Format
 
Authors:R. Hinden, M. O'Dell, S. Deering.
Date:July 1998
Formats:txt pdf
Obsoletes:RFC 2073
Obsoleted by:RFC 3587
Status:HISTORIC
DOI:10.17487/RFC 2374
This document defines an IPv6 aggregatable global unicast address format for use in the Internet. [STANDARDS-TRACK]
 
RFC 2400 Internet Official Protocol Standards
 
Authors:J. Postel, J. Reynolds.
Date:September 1998
Formats:txt pdf
Obsoletes:RFC 2300
Obsoleted by:RFC 2500
Status:HISTORIC
DOI:10.17487/RFC 2400
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. [STANDARDS-TRACK]
 
RFC 2452 IP Version 6 Management Information Base for the Transmission Control Protocol
 
Authors:M. Daniele.
Date:December 1998
Formats:txt pdf
Obsoleted by:RFC 4022, RFC 8096
Status:HISTORIC
DOI:10.17487/RFC 2452
This document is one in the series of documents that define variousMIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the TransmissionControl Protocol (TCP) over IP Version 6 (IPv6).

This document also recommends a specific policy with respect to the applicability of RFC 2012 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2012 are independent of whichIP versions underlie TCP, and only the TCP connection information isIP version-specific.

This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inIPv6-based internets.

 
RFC 2454 IP Version 6 Management Information Base for the User Datagram Protocol
 
Authors:M. Daniele.
Date:December 1998
Formats:txt pdf
Obsoleted by:RFC 4113, RFC 8096
Status:HISTORIC
DOI:10.17487/RFC 2454
This document is one in the series of documents that define variousMIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the UserDatagram Protocol (UDP) over IP Version 6 (IPv6).

This document also recommends a specific policy with respect to the applicability of RFC 2013 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2013 are independent of whichIP versions underlie UDP, and only the UDP listener information is IP version-specific.

This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inIPv6-based internets.

 
RFC 2465 Management Information Base for IP Version 6: Textual Conventions and General Group
 
Authors:D. Haskin, S. Onishi.
Date:December 1998
Formats:txt pdf
Obsoleted by:RFC 4293, RFC 8096
Status:HISTORIC
DOI:10.17487/RFC 2465
This document is one in the series of documents that provide MIB definitions for for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document.

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets.

This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peerSNMPv1 definitions.

 
RFC 2466 Management Information Base for IP Version 6: ICMPv6 Group
 
Authors:D. Haskin, S. Onishi.
Date:December 1998
Formats:txt pdf
Obsoleted by:RFC 4293, RFC 8096
Status:HISTORIC
DOI:10.17487/RFC 2466
This document is one in the series of documents that define variousMIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document.

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets.

This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peerSNMPv1 definitions.

 
RFC 2471 IPv6 Testing Address Allocation
 
Authors:R. Hinden, R. Fink, J. Postel.
Date:December 1998
Formats:txt pdf
Obsoletes:RFC 1897
Obsoleted by:RFC 3701
Status:HISTORIC
DOI:10.17487/RFC 2471
This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This memo defines an Experimental Protocol for the Internet community.
 
RFC 2482 Language Tagging in Unicode Plain Text
 
Authors:K. Whistler, G. Adams.
Date:January 1999
Formats:txt pdf
Obsoleted by:RFC 6082
Status:HISTORIC
DOI:10.17487/RFC 2482
This document proposed a mechanism for language tagging in plain text. This memo provides information for the Internet community.
 
RFC 2500 Internet Official Protocol Standards
 
Authors:J. Reynolds, R. Braden.
Date:June 1999
Formats:txt pdf
Obsoletes:RFC 2400
Obsoleted by:RFC 2600
Status:HISTORIC
DOI:10.17487/RFC 2500
This memo summarizes the status of Internet protocols and specifications. [STANDARDS-TRACK]
 
RFC 2559 Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2
 
Authors:S. Boeyen, T. Howes, P. Richard.
Date:April 1999
Formats:txt pdf
Obsoleted by:RFC 3494
Updates:RFC 1778
Status:HISTORIC
DOI:10.17487/RFC 2559
Specifically, this document addresses requirements to provide access to Public Key Infrastructure (PKI) repositories for the purposes of retrieving PKI information and managing that same information. [STANDARDS-TRACK]
 
RFC 2600 Internet Official Protocol Standards
 
Authors:J. Reynolds, R. Braden.
Date:March 2000
Formats:txt pdf
Obsoletes:RFC 2500
Obsoleted by:RFC 2700
Status:HISTORIC
DOI:10.17487/RFC 2600
This memo is published by the RFC Editor in accordance with Section 2.1 of "The Internet Standards Process -- Revision 3", RFC 2026, which specifies the rules and procedures by which all Internet standards are set. This memo is prepared by the RFC Editor for the IESG and IAB. Please see http://www.rfc-editor.org for later updates to this document. [STANDARDS-TRACK]
 
RFC 2673 Binary Labels in the Domain Name System
 
Authors:M. Crawford.
Date:August 1999
Formats:txt pdf
Obsoleted by:RFC 6891
Updates:RFC 1035
Updated by:RFC 3363, RFC 3364
Status:HISTORIC
DOI:10.17487/RFC 2673
This document defines a "Bit-String Label" which may appear within domain names. This new label type compactly represents a sequence of "One-Bit Labels" and enables resource records to be stored at any bit- boundary in a binary-named section of the domain name tree. [STANDARDS-TRACK]
 
RFC 2700 Internet Official Protocol Standards
 
Authors:J. Reynolds, R. Braden.
Date:August 2000
Formats:txt pdf
Obsoletes:RFC 2600
Obsoleted by:RFC 2800
Status:HISTORIC
DOI:10.17487/RFC 2700
This memo describes the current state of standardization of protocols used in the Internet as determined by the Internet Engineering TaskForce (IETF). Sections 3.1 - 3.6 contain the lists of protocols in each stage of standardization - Standard, Draft Standard, ProposedStandard, Experimental and Historic. Protocols that are new to this document or have been moved from one protocol level to another, or differ from the previous edition of this document are marked.Informational Request for Comments (RFCs) are not included. This memo lists the current protocols; it is not a complete index to RFCs.
 
RFC 2754 RPS IANA Issues
 
Authors:C. Alaettinoglu, C. Villamizar, R. Govindan.
Date:January 2000
Formats:txt pdf
Obsoleted by:RFC 6254
Status:HISTORIC
DOI:10.17487/RFC 2754
RPS Security [2] requires certain RPSL [1] objects in the IRR to be hierarchically delegated. The set of objects that are at the root of this hierarchy needs to be created and digitally signed by IANA. This paper presents these seed objects and lists operations required fromIANA.
 
RFC 2766 Network Address Translation - Protocol Translation (NAT-PT)
 
Authors:G. Tsirtsis, P. Srisuresh.
Date:February 2000
Formats:txt pdf
Obsoleted by:RFC 4966
Updated by:RFC 3152
Status:HISTORIC
DOI:10.17487/RFC 2766
This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified in [TRANS]. This solution attempts to provide transparent routing, as defined in [NAT-TERM], to end-nodes in V6 realm trying to communicate with end-nodes in V4 realm and vice versa. This is achieved using a combination of NetworkAddress Translation and Protocol Translation. The scheme described does not mandate dual-stacks (i.e., IPv4 as well as V6 protocol support) or special purpose routing requirements (such as requiring tunneling support) on end nodes. This scheme is based on a combination of address translation theme as described in [NAT-TERM] and V6/V4 protocol translation theme as described in [SIIT].
 
RFC 2776 Multicast-Scope Zone Announcement Protocol (MZAP)
 
Authors:M. Handley, D. Thaler, R. Kermode.
Date:February 2000
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 2776
This document defines a protocol, the Multicast-Scope ZoneAnnouncement Protocol (MZAP), for discovering the multicast administrative scope zones that are relevant at a particular location. MZAP also provides mechanisms whereby common misconfigurations of administrative scope zones can be discovered.
 
RFC 2800 Internet Official Protocol Standards
 
Authors:J. Reynolds, R. Braden, S. Ginoza.
Date:May 2001
Formats:txt pdf
Obsoletes:RFC 2700
Obsoleted by:RFC 2900
Status:HISTORIC
DOI:10.17487/RFC 2800
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of April 17, 2001. It lists only official protocol standards RFCs; it is not a complete index to theRFC series. The latest version of this memo is designated STD 1.
 
RFC 2831 Using Digest Authentication as a SASL Mechanism
 
Authors:P. Leach, C. Newman.
Date:May 2000
Formats:txt pdf
Obsoleted by:RFC 6331
Status:HISTORIC
DOI:10.17487/RFC 2831
This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5[RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols.
 
RFC 2841 IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC)
 
Authors:P. Metzger, W. Simpson.
Date:November 2000
Formats:txt pdf
Obsoletes:RFC 1852
Status:HISTORIC
DOI:10.17487/RFC 2841
This document describes the use of keyed SHA1 with the IPAuthentication Header.
 
RFC 2861 TCP Congestion Window Validation
 
Authors:M. Handley, J. Padhye, S. Floyd.
Date:June 2000
Formats:txt pdf
Obsoleted by:RFC 7661
Status:HISTORIC
DOI:10.17487/RFC 2861
TCP's congestion window controls the number of packets a TCP flow may have in the network at any time. However, long periods when the sender is idle or application-limited can lead to the invalidation of the congestion window, in that the congestion window no longer reflects current information about the state of the network. This document describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window.

An invalid congestion window also results when the congestion window is increased (i.e., in TCP's slow-start or congestion avoidance phases) during application-limited periods, when the previous value of the congestion window might never have been fully utilized. We propose that the TCP sender should not increase the congestion window when the TCP sender has been application-limited (and therefore has not fully used the current congestion window). We have explored these algorithms both with simulations and with experiments from an implementation in FreeBSD.

 
RFC 2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering
 
Authors:M. Crawford, C. Huitema.
Date:July 2000
Formats:txt pdf
Updates:RFC 1886
Updated by:RFC 3152, RFC 3226, RFC 3363, RFC 3364
Status:HISTORIC
DOI:10.17487/RFC 2874
This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. The changes include a new resource record type to store an IPv6 address in a manner which expedites network renumbering and updated definitions of existing query types that return Internet addresses as part of additional section processing.

For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new zone structure which allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events.

 
RFC 2885 Megaco Protocol version 0.8
 
Authors:F. Cuervo, N. Greene, C. Huitema, A. Rayhan, B. Rosen, J. Segers.
Date:August 2000
Formats:txt pdf
Obsoleted by:RFC 3015
Status:HISTORIC
DOI:10.17487/RFC 2885
This document is common text with Recommendation H.248 as redetermined in Geneva, February 2000. It must be read in conjunction with the Megaco Errata, RFC 2886. A merged document presenting the Megaco protocol with the Errata incorporated will be available shortly.

The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805.

 
RFC 2886 Megaco Errata
 
Authors:T. Taylor.
Date:August 2000
Formats:txt pdf
Obsoleted by:RFC 3015
Status:HISTORIC
DOI:10.17487/RFC 2886
This document records the errors found in the Megaco/H.248 protocol document, along with the changes proposed in the text of that document to resolve them. [STANDARDS TRACK]
 
RFC 2900 Internet Official Protocol Standards
 
Authors:J. Reynolds, R. Braden, S. Ginoza.
Date:August 2001
Formats:txt pdf
Obsoletes:RFC 2800
Obsoleted by:RFC 3000
Status:HISTORIC
DOI:10.17487/RFC 2900
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 17, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.
 
RFC 2908 The Internet Multicast Address Allocation Architecture
 
Authors:D. Thaler, M. Handley, D. Estrin.
Date:September 2000
Formats:txt pdf
Obsoleted by:RFC 6308
Status:HISTORIC
DOI:10.17487/RFC 2908
This document proposes a multicast address allocation architecture(MALLOC) for the Internet. The architecture is modular with three layers, comprising a host-server mechanism, an intra-domain server- server coordination mechanism, and an inter-domain mechanism.
 
RFC 2909 The Multicast Address-Set Claim (MASC) Protocol
 
Authors:P. Radoslavov, D. Estrin, R. Govindan, M. Handley, S. Kumar, D. Thaler.
Date:September 2000
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 2909
This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. MASC is used by a node (typically a router) to claim and allocate one or more address prefixes to that node's domain. While a domain does not necessarily need to allocate an address set for hosts in that domain to be able to allocate group addresses, allocating an address set to the domain does ensure that inter-domain group- specific distribution trees will be locally-rooted, and that traffic will be sent outside the domain only when and where external receivers exist.
 
RFC 2965 HTTP State Management Mechanism
 
Authors:D. Kristol, L. Montulli.
Date:October 2000
Formats:txt pdf
Obsoletes:RFC 2109
Obsoleted by:RFC 6265
Status:HISTORIC
DOI:10.17487/RFC 2965
This document specifies a way to create a stateful session withHypertext Transfer Protocol (HTTP) requests and responses. It describes three new headers, Cookie, Cookie2, and Set-Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal [Netscape], but it can interoperate with HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL section.)

This document reflects implementation experience with RFC 2109 and obsoletes it.

 
RFC 3000 Internet Official Protocol Standards
 
Authors:J. Reynolds, R. Braden, S. Ginoza, L. Shiota.
Date:November 2001
Formats:txt pdf
Obsoletes:RFC 2900
Obsoleted by:RFC 3300
Status:HISTORIC
DOI:10.17487/RFC 3000
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 25, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.
 
RFC 3044 Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace
 
Authors:S. Rozenfeld.
Date:January 2001
Formats:txt pdf
Obsoleted by:RFC 8254
Status:HISTORIC
DOI:10.17487/RFC 3044
This document presents how the ISSN - International Standard SerialNumber - which is a persistent number for unique identification of serials widely recognised and used in the bibliographic world, can be supported within the Uniform Resource Name (URN) framework as a specific URN namespace identifier.

An ISSN URN resolution system using the ISSN identifier as Uniform resource Name within an ISN URN Namespace has been developed by theISSN International Centre (ISSN-IC) and is operating as a demonstrator to evaluate all requirements to deploy it in an operational environment.

This proceeds from concepts and proposals developed in several IETFRFCs emphasising the way to implement and to use "recognised" existing numbering system within the URN framework (RFC 2248, RFC2141, RFC 2611).

 
RFC 3068 An Anycast Prefix for 6to4 Relay Routers
 
Authors:C. Huitema.
Date:June 2001
Formats:txt pdf
Obsoleted by:RFC 7526
Status:HISTORIC
DOI:10.17487/RFC 3068
This memo introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned NumbersAuthority) of the "6to4 relay anycast prefix."
 
RFC 3084 COPS Usage for Policy Provisioning (COPS-PR)
 
Authors:K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith.
Date:March 2001
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 3084
This document describes the use of the Common Open Policy Service(COPS) protocol for support of policy provisioning (COPS-PR). This specification is independent of the type of policy being provisioned(QoS, Security, etc.) but focuses on the mechanisms and conventions used to communicate provisioned information between PDPs and PEPs.The protocol extensions described in this document do not make any assumptions about the policy data model being communicated, but describe the message formats and objects that carry the modeled policy data.
 
RFC 3159 Structure of Policy Provisioning Information (SPPI)
 
Authors:K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer.
Date:August 2001
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 3159
This document, the Structure of Policy Provisioning Information(SPPI), defines the adapted subset of SNMP's Structure of ManagementInformation (SMI) used to write Policy Information Base (PIB) modules.

RFC 2748 defines the COPS protocol, and RFC 2749 describes how theCOPS protocol is used to provide for the outsourcing of policy decisions for RSVP. Another usage of the COPS protocol, for the provisioning of policy, is introduced in RFC 3084. In this provisioning model, the policy information is viewed as a collection of Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing in a virtual information store, termed the PolicyInformation Base (PIB). Collections of related Provisioning Classes are defined in a PIB module.

 
RFC 3187 Using International Standard Book Numbers as Uniform Resource Names
 
Authors:J. Hakala, H. Walravens.
Date:October 2001
Formats:txt pdf
Obsoleted by:RFC 8254
Status:HISTORIC
DOI:10.17487/RFC 3187
This document discusses how International Standard Book Numbers(ISBN) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion below is based on the ideas expressed in RFC 2288.
 
RFC 3300 Internet Official Protocol Standards
 
Authors:J. Reynolds, R. Braden, S. Ginoza, A. De La Cruz.
Date:November 2002
Formats:txt pdf
Obsoletes:RFC 3000
Obsoleted by:RFC 3600
Status:HISTORIC
DOI:10.17487/RFC 3300
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 24, 2002. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.
 
RFC 3317 Differentiated Services Quality of Service Policy Information Base
 
Authors:K. Chan, R. Sahita, S. Hahn, K. McCloghrie.
Date:March 2003
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 3317
This document describes a Policy Information Base (PIB) for a device implementing the Differentiated Services Architecture. The provisioning classes defined here provide policy control over resources implementing the Differentiated Services Architecture.These provisioning classes can be used with other none DifferentiatedServices provisioning classes (defined in other PIBs) to provide for a comprehensive policy controlled mapping of service requirement to device resource capability and usage.
 
RFC 3318 Framework Policy Information Base
 
Authors:R. Sahita, Ed., S. Hahn, K. Chan, K. McCloghrie.
Date:March 2003
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 3318
This document defines a set of PRovisioning Classes (PRCs) and textual conventions that are common to all clients that provision policy using Common Open Policy Service (COPS) protocol forProvisioning.

Structure of Policy Provisioning Information (SPPI) describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well- defined (PRCs) and instances of these classes (PRIs) residing in a virtual information store called the Policy Information Base (PIB).

One way to provision policy is by means of the (COPS) protocol with the extensions for provisioning. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security.

As described in COPS usage for Policy Provisioning (COPS-PR), each client supports a non-overlapping and independent set of PIB modules.However, some PRovisioning Classes are common to all subject- categories (client-types) and need to be present in each.

 
RFC 3340 The Application Exchange Core
 
Authors:M. Rose, G. Klyne, D. Crocker.
Date:July 2002
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 3340
This memo describes Application Exchange (APEX) Core, an extensible, asynchronous message relaying service for application layer programs.
 
RFC 3341 The Application Exchange (APEX) Access Service
 
Authors:M. Rose, G. Klyne, D. Crocker.
Date:July 2002
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 3341
This memo describes the Application Exchange (APEX) access service, addressed as the well-known endpoint "apex=access". The access service is used to control use of both the APEX "relaying mesh" and other APEX services.
 
RFC 3342 The Application Exchange (APEX) Option Party Pack, Part Deux!
 
Authors:E. Dixon, H. Franklin, J. Kint, G. Klyne, D. New, S. Pead, M. Rose, M. Schwartz.
Date:July 2002
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 3342
Application Exchange (APEX), at its core, provides a best-effort application-layer datagram service. Options are used to alter the semantics of the core service. This memo defines various options to change the default behavior of APEX's "relaying mesh".
 
RFC 3343 The Application Exchange (APEX) Presence Service
 
Authors:M. Rose, G. Klyne, D. Crocker.
Date:April 2003
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 3343
This memo describes the Application Exchange (APEX) presence service, addressed as the well-known endpoint "apex=presence". The presence service is used to manage presence information for APEX endpoints.
 
RFC 3525 Gateway Control Protocol Version 1
 
Authors:C. Groves, Ed., M. Pantaleo, Ed., T. Anderson, Ed., T. Taylor, Ed..
Date:June 2003
Formats:txt pdf
Obsoletes:RFC 3015
Obsoleted by:RFC 5125
Status:HISTORIC
DOI:10.17487/RFC 3525
This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e., a Media Gateway and aMedia Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805.

This document replaces RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T StudyGroup 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the MegacoE-mail list and incorporated into the Study Group 16 Implementor'sGuide for Recommendation H.248. The present version of this document underwent ITU-T Last Call as Recommendation H.248 Amendment 1.Because of ITU-T renumbering, it was published by the ITU-T asRecommendation H.248.1 (03/2002), Gateway Control Protocol Version 1.

Users of this specification are advised to consult the H.248 Sub- series Implementors' Guide at http://www.itu.int/itudoc/itu- t/com16/implgd for additional corrections and clarifications.

 
RFC 3540 Robust Explicit Congestion Notification (ECN) Signaling with Nonces
 
Authors:N. Spring, D. Wetherall, D. Ely.
Date:June 2003
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 3540
This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth.The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts.
 
RFC 3571 Framework Policy Information Base for Usage Feedback
 
Authors:D. Rawlins, A. Kulkarni, K. Ho Chan, M. Bokaemper, D. Dutt.
Date:August 2003
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 3571
This document describes a portion of the Policy Information Base(PIB) to control policy usage collection and reporting in a device.

The provisioning classes specified here allow a Policy Decision Point(PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported.

This PIB requires the presence of other PIBs (defined elsewhere) that provide the policy objects from which usage information is collected.

 
RFC 3600 Internet Official Protocol Standards
 
Authors:J. Reynolds, Ed., S. Ginoza, Ed..
Date:November 2003
Formats:txt pdf
Obsoletes:RFC 3300
Obsoleted by:RFC 3700
Status:HISTORIC
DOI:10.17487/RFC 3600
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 2, 2003. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.
 
RFC 3627 Use of /127 Prefix Length Between Routers Considered Harmful
 
Authors:P. Savola.
Date:September 2003
Formats:txt pdf
Obsoleted by:RFC 6547
Status:HISTORIC
DOI:10.17487/RFC 3627
In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers.Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers.
 
RFC 3700 Internet Official Protocol Standards
 
Authors:J. Reynolds, Ed., S. Ginoza, Ed..
Date:July 2004
Formats:txt pdf
Obsoletes:RFC 3600
Obsoleted by:RFC 5000
Status:HISTORIC
DOI:10.17487/RFC 3700
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 22, 2004. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.
 
RFC 3913 Border Gateway Multicast Protocol (BGMP): Protocol Specification
 
Authors:D. Thaler.
Date:September 2004
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 3913
This document describes the Border Gateway Multicast Protocol (BGMP), a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and optionally allows receiver domains to build source-specific, inter-domain, distribution branches where needed. BGMP natively supports "source-specific multicast"(SSM). To also support "any-source multicast" (ASM), BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). It requires that different ranges of the multicast address space are associated (e.g., withUnicast-Prefix-Based Multicast addressing) with different domains.Each of these domains then becomes the root of the shared domain- trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domain to be local to at least one of the session participants.
 
RFC 4156 The wais URI Scheme
 
Authors:P. Hoffman.
Date:August 2005
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 4156
This document specifies the wais Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track.
 
RFC 4157 The prospero URI Scheme
 
Authors:P. Hoffman.
Date:August 2005
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 4157
This document specifies the prospero Uniform Resource Identifier(URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track.
 
RFC 4351 Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream
 
Authors:G. Hellstrom, P. Jones.
Date:January 2006
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 4351
This memo describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.

One payload format is described for transmitting audio and text data within a single RTP session.

This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss.

 
RFC 4402 A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism
 
Authors:N. Williams.
Date:February 2006
Formats:txt pdf
Obsoleted by:RFC 7802
Status:HISTORIC
DOI:10.17487/RFC 4402
This document defines the Pseudo-Random Function (PRF) for theKerberos V mechanism for the Generic Security Service ApplicationProgram Interface (GSS-API), based on the PRF defined for theKerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context.
 
RFC 4612 Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration
 
Authors:P. Jones, H. Tamura.
Date:August 2006
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 4612
This document defines the MIME sub-type audio/t38. The usage of thisMIME type, which is intended for use within Session DescriptionProtocol (SDP), is specified within ITU-T Recommendation T.38.
 
RFC 4693 IETF Operational Notes
 
Authors:H. Alvestrand.
Date:October 2006
Formats:txt pdf
Obsoleted by:RFC 6393
Status:HISTORIC
DOI:10.17487/RFC 4693
This document describes a new document series intended for use as a repository for IETF operations documents, which should be more ephemeral than RFCs, but more referenceable than Internet-Drafts, and with more clear handling procedures than a random Web page.

It proposes to establish this series as an RFC 3933 process experiment.

 
RFC 4743 Using NETCONF over the Simple Object Access Protocol (SOAP)
 
Authors:T. Goddard.
Date:December 2006
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 4743
The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. Web Services is one such environment and is presently characterized by the use of theSimple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange ExtensibleProtocol (BEEP) bindings for NETCONF.
 
RFC 4744 Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)
 
Authors:E. Lear, K. Crozier.
Date:December 2006
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 4744
This document specifies an application protocol mapping for theNetwork Configuration Protocol (NETCONF) over the Blocks ExtensibleExchange Protocol (BEEP).
 
RFC 4757 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows
 
Authors:K. Jaganathan, L. Zhu, J. Brezak.
Date:December 2006
Formats:txt pdf
Updated by:RFC 6649
Status:HISTORIC
DOI:10.17487/RFC 4757
The Microsoft Windows 2000 implementation of Kerberos introduces a new encryption type based on the RC4 encryption algorithm and using an MD5 HMAC for checksum. This is offered as an alternative to using the existing DES-based encryption types.

The RC4-HMAC encryption types are used to ease upgrade of existingWindows NT environments, provide strong cryptography (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. This document describes the implementation of those encryption types.

 
RFC 4869 Suite B Cryptographic Suites for IPsec
 
Authors:L. Law, J. Solinas.
Date:May 2007
Formats:txt pdf
Obsoleted by:RFC 6379
Status:HISTORIC
DOI:10.17487/RFC 4869
This document proposes four optional cryptographic user interface suites ("UI suites") for IPsec, similar to the two suites specified in RFC 4308. The four new suites provide compatibility with theUnited States National Security Agency's Suite B specifications.
 
RFC 4870 Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)
 
Authors:M. Delany.
Date:May 2007
Formats:txt pdf
Obsoleted by:RFC 4871
Status:HISTORIC
DOI:10.17487/RFC 4870
"DomainKeys" creates a domain-level authentication framework for email by using public key technology and the DNS to prove the provenance and contents of an email.

This document defines a framework for digitally signing email on a per-domain basis. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today.

Proof and protection of email identity may assist in the global control of "spam" and "phishing".

 
RFC 4905 Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks
 
Authors:L. Martini, Ed., E. Rosen, Ed., N. El-Aawar, Ed..
Date:June 2007
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 4905
This document describes methods for encapsulating the Protocol DataUnits (PDUs) of layer 2 protocols such as Frame Relay, AsynchronousTransfer Mode (ATM), or Ethernet for transport across an MPLS network. This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire EmulationEdge to Edge Working Group specifications described in RFC 4447 and related documents.
 
RFC 4906 Transport of Layer 2 Frames Over MPLS
 
Authors:L. Martini, Ed., E. Rosen, Ed., N. El-Aawar, Ed..
Date:June 2007
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 4906
This document describes methods for transporting the Protocol DataUnits (PDUs) of layer 2 protocols such as Frame Relay, AsynchronousTransfer Mode (ATM) Adaption Layer 5 (AAL5), and Ethernet, and for providing a Synchronized Optical Network (SONET) circuit emulation service across an MPLS network. This document describes the so- called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents.
 
RFC 5000 Internet Official Protocol Standards
 
Authors:RFC Editor.
Date:May 2008
Formats:txt pdf
Obsoletes:RFC 3700
Obsoleted by:RFC 7100
Status:HISTORIC
DOI:10.17487/RFC 5000
This document is published by the RFC Editor to provide a summary of the current standards protocols (as of 18 February 2008). It lists those official protocol standards, Best Current Practice, andExperimental RFCs that have not been obsoleted; it is not a complete index to the RFC series. Newly published RFCs and RFCs whose status has changed are starred.

For an up-to-date list, see http://www.rfc-editor.org/rfcxx00.html, which is updated daily.

 
RFC 5008 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)
 
Authors:R. Housley, J. Solinas.
Date:September 2007
Formats:txt pdf
Obsoleted by:RFC 6318
Status:HISTORIC
DOI:10.17487/RFC 5008
This document specifies the conventions for using the United StatesNational Security Agency's Suite B algorithms in Secure/MultipurposeInternet Mail Extensions (S/MIME) as specified in RFC 3851.
 
RFC 5143 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation
 
Authors:A. Malis, J. Brayley, J. Shirron, L. Martini, S. Vogelsang.
Date:February 2008
Formats:txt pdf
Obsoleted by:RFC 4842
Status:HISTORIC
DOI:10.17487/RFC 5143
This document describes a historical method for encapsulatingSynchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)Path signals for transport across packet-switched networks (PSNs).The PSNs explicitly supported by this document include MPLS and IP.Note that RFC 4842 describes the standards-track protocol for this functionality, and new implementations must use RFC 4842 rather than this document except when interoperability with older implementations is desired.
 
RFC 5412 Lightweight Access Point Protocol
 
Authors:P. Calhoun, R. Suri, N. Cam-Winget, M. Williams, S. Hares, B. O'Hara, S. Kelly.
Date:February 2010
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 5412
In recent years, there has been a shift in wireless LAN (WLAN) product architectures from autonomous access points to centralized control of lightweight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility, and radio management out of the access point into a centralized controller.

The IETF's CAPWAP (Control and Provisioning of Wireless AccessPoints) WG has identified that a standards-based protocol is necessary between a wireless Access Controller and WirelessTermination Points (the latter are also commonly referred to asLightweight Access Points). This specification defines theLightweight Access Point Protocol (LWAPP), which addresses theCAPWAP's (Control and Provisioning of Wireless Access Points) protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol.

 
RFC 5413 SLAPP: Secure Light Access Point Protocol
 
Authors:P. Narasimhan, D. Harkins, S. Ponnuswamy.
Date:February 2010
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 5413
The Control and Provisioning of Wireless Access Points (CAPWAP) problem statement describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and AccessControllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) that then enables an AC from one vendor to control and manage a WTP from another.

In this document, we present a protocol that forms the common technology-independent framework and the ability to negotiate and add, on top of this framework, a control protocol that contains a technology-dependent component to arrive at a complete solution. We have also presented two such control protocols -- an 802.11 Control protocol, and another, more generic image download protocol, in this document.

Even though the text in this document is written to specifically address the problem stated in RFC 3990, the solution can be applied to any problem that has a controller (equivalent to the AC) managing one or more network elements (equivalent to the WTP).

 
RFC 5414 Wireless LAN Control Protocol (WiCoP)
 
Authors:S. Iino, S. Govindan, M. Sugiura, H. Cheng.
Date:February 2010
Formats:txt pdf
Obsoleted by:RFC 5415
Status:HISTORIC
DOI:10.17487/RFC 5414
The popularity of wireless local area networks (WLANs) has led to widespread deployments across different establishments. It has also translated into an increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points(WTPs) and covering substantial areas are increasingly common.

The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the Control And Provisioning of WirelessAccess Points (CAPWAP).

 
RFC 5430 Suite B Profile for Transport Layer Security (TLS)
 
Authors:M. Salter, E. Rescorla, R. Housley.
Date:March 2009
Formats:txt pdf
Obsoleted by:RFC 6460
Status:HISTORIC
DOI:10.17487/RFC 5430
The United States government has published guidelines for "NSA SuiteB Cryptography", which defines cryptographic algorithm policy for national security applications. This document defines a profile ofTransport Layer Security (TLS) version 1.2 that is fully conformant with Suite B. This document also defines a transitional profile for use with TLS version 1.0 and TLS version 1.1 which employs Suite B algorithms to the greatest extent possible.
 
RFC 5617 DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
 
Authors:E. Allman, J. Fenton, M. Delany, J. Levine.
Date:August 2009
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 5617
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether a domain signs its outgoing mail as well as how other hosts can access that record.
 
RFC 5759 Suite B Certificate and Certificate Revocation List (CRL) Profile
 
Authors:J. Solinas, L. Zieglar.
Date:January 2010
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 5759
This document specifies a base profile for X.509 v3 Certificates andX.509 v2 Certificate Revocation Lists (CRLs) for use with the UnitedStates National Security Agency's Suite B Cryptography. The reader is assumed to have familiarity with RFC 5280, "Internet X.509 PublicKey Infrastructure Certificate and Certificate Revocation List (CRL)Profile".
 
RFC 5772 A Set of Possible Requirements for a Future Routing Architecture
 
Authors:A. Doria, E. Davies, F. Kastenholz.
Date:February 2010
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 5772
The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group(RRG) in 2001, with some editorial updates up to 2006. The two sub- groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for theInternet in the future.

The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication.

 
RFC 5773 Analysis of Inter-Domain Routing Requirements and History
 
Authors:E. Davies, A. Doria.
Date:February 2010
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 5773
This document analyzes the state of the Internet domain-based routing system, concentrating on Inter-Domain Routing (IDR) and also considering the relationship between inter-domain and intra-domain routing. The analysis is carried out with respect to RFC 1126 and other IDR requirements and design efforts looking at the routing system as it appeared to be in 2001 with editorial additions reflecting developments up to 2006. It is the companion document to"A Set of Possible Requirements for a Future Routing Architecture"(RFC 5772), which is a discussion of requirements for the future routing architecture, addressing systems developments and future routing protocols. This document summarizes discussions held several years ago by members of the IRTF Routing Research Group (IRTF RRG) and other interested parties. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication.
 
RFC 5806 Diversion Indication in SIP
 
Authors:S. Levy, M. Mohali, Ed..
Date:March 2010
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 5806
This RFC, which contains the text of an Internet Draft that was submitted originally to the SIP Working Group, is being published now for the historical record and to provide a reference for laterInformational RFCs. The original Abstract follows.

This document proposes an extension to the Session InitiationProtocol (SIP). This extension provides the ability for the calledSIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header,Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent.

This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and AutomaticCall Distribution (ACD). SIP user agents and SIP proxies that receive diversion information may use this as supplemental information for feature invocation decisions.

 
RFC 5987 Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters
 
Authors:J. Reschke.
Date:August 2010
Formats:txt pdf
Obsoleted by:RFC 8187
Status:HISTORIC
DOI:10.17487/RFC 5987
By default, message header field parameters in Hypertext TransferProtocol (HTTP) messages cannot carry characters outside the ISO-8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC2231.
 
RFC 6013 TCP Cookie Transactions (TCPCT)
 
Authors:W. Simpson.
Date:January 2011
Formats:txt pdf
Obsoleted by:RFC 7805
Status:HISTORIC
DOI:10.17487/RFC 6013
TCP Cookie Transactions (TCPCT) deter spoofing of connections and prevent resource exhaustion, eliminating Responder (server) state during the initial handshake. The Initiator (client) has sole responsibility for ensuring required delays between connections. The cookie exchange may carry data, limited to inhibit amplification and reflection denial of service attacks.
 
RFC 6037 Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs
 
Authors:E. Rosen, Ed., Y. Cai, Ed., IJ. Wijnands.
Date:October 2010
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 6037
This document describes the MVPN (Multicast in BGP/MPLS IP VPNs) solution designed and deployed by Cisco Systems. The procedures specified in this document are largely a subset of the generalizedMVPN framework recently standardized by the IETF. However, as the deployment of the procedures specified herein predates the publication of IETF standards (in some cases by over five years), an implementation based on these procedures differs in some respects from a fully standards-compliant implementation. These differences are pointed out in the document.
 
RFC 6101 The Secure Sockets Layer (SSL) Protocol Version 3.0
 
Authors:A. Freier, P. Karlton, P. Kocher.
Date:August 2011
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 6101
This document is published as a historical record of the SSL 3.0 protocol. The original Abstract follows.

This document specifies version 3.0 of the Secure Sockets Layer (SSL3.0) protocol, a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.

 
RFC 6112 Anonymity Support for Kerberos
 
Authors:L. Zhu, P. Leach, S. Hartman.
Date:April 2011
Formats:txt pdf
Obsoleted by:RFC 8062
Updates:RFC 4120, RFC 4121, RFC 4556
Status:HISTORIC
DOI:10.17487/RFC 6112
This document defines extensions to the Kerberos protocol to allow aKerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow aKerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556.
 
RFC 6123 Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts
 
Authors:A. Farrel.
Date:February 2011
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 6123
It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal.Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements.

The Operations Area has developed "Guidelines for ConsideringOperations and Management of New Protocols and Protocol Extensions"(RFC 5706), and those guidelines have been adopted by the PathComputation Element (PCE) Working Group.

Previously, the PCE Working Group used the recommendations contained in this document to guide authors of Internet-Drafts on the contents of "Manageability Considerations" sections in their work. This document is retained for historic reference.

 
RFC 6239 Suite B Cryptographic Suites for Secure Shell (SSH)
 
Authors:K. Igoe.
Date:May 2011
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 6239
This document describes the architecture of a Suite B compliant implementation of the Secure Shell Transport Layer Protocol and theSecure Shell Authentication Protocol. Suite B Secure Shell makes use of the elliptic curve Diffie-Hellman (ECDH) key agreement, the elliptic curve digital signature algorithm (ECDSA), the AdvancedEncryption Standard running in Galois/Counter Mode (AES-GCM), two members of the SHA-2 family of hashes (SHA-256 and SHA-384), andX.509 certificates.
 
RFC 6318 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)
 
Authors:R. Housley, J. Solinas.
Date:June 2011
Formats:txt pdf
Obsoletes:RFC 5008
Status:HISTORIC
DOI:10.17487/RFC 6318
This document specifies the conventions for using the United StatesNational Security Agency's Suite B algorithms in Secure/MultipurposeInternet Mail Extensions (S/MIME) as specified in RFC 5751. This document obsoletes RFC 5008.
 
RFC 6348 Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol
 
Authors:JL. Le Roux, Ed., T. Morin, Ed..
Date:September 2011
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 6348
This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over aMultiprotocol Label Switching (MPLS) infrastructure.

This work was overtaken by the protocol solution developed by theMPLS working group, but that solution did not closely follow the requirements documented here. This document is published as a historic record of the ideas and requirements that shaped the protocol work.

 
RFC 6379 Suite B Cryptographic Suites for IPsec
 
Authors:L. Law, J. Solinas.
Date:October 2011
Formats:txt pdf
Obsoletes:RFC 4869
Status:HISTORIC
DOI:10.17487/RFC 6379
This document proposes four cryptographic user interface suites("UI suites") for IP Security (IPsec), similar to the two suites specified in RFC 4308. The four new suites provide compatibility with the United States National Security Agency's Suite B specifications. This document obsoletes RFC 4869, which presented earlier versions of these suites.
 
RFC 6380 Suite B Profile for Internet Protocol Security (IPsec)
 
Authors:K. Burgin, M. Peck.
Date:October 2011
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 6380
The United States Government has published guidelines for "NSASuite B Cryptography" dated July, 2005, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using Suite B cryptography in IPSecurity (IPsec).

Since many of the Suite B algorithms are used in other environments, the majority of the conventions needed for the Suite B algorithms are already specified in other documents. This document references the source of these conventions, with some relevant detail repeated to aid developers who choose to support Suite B.

 
RFC 6403 Suite B Profile of Certificate Management over CMS
 
Authors:L. Zieglar, S. Turner, M. Peck.
Date:November 2011
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 6403
The United States government has published guidelines for "NSASuite B Cryptography", which defines cryptographic algorithm policy for national security applications. This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing Suite B X.509 public key certificates. This profile is a refinement of RFCs 5272, 5273, and 5274.
 
RFC 6460 Suite B Profile for Transport Layer Security (TLS)
 
Authors:M. Salter, R. Housley.
Date:January 2012
Formats:txt pdf
Obsoletes:RFC 5430
Status:HISTORIC
DOI:10.17487/RFC 6460
The United States government has published guidelines for "NSA SuiteB Cryptography" that define cryptographic algorithm policy for national security applications. This document defines a profile ofTransport Layer Security (TLS) version 1.2 that is fully compliant with Suite B.
 
RFC 6529 Host/Host Protocol for the ARPA Network
 
Authors:A. McKenzie, S. Crocker.
Date:April 2012
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 6529
This document reproduces the Host/Host Protocol developed by the ARPANetwork Working Group during 1969, 1970, and 1971. It describes a protocol used to manage communication between processes residing on independent Hosts. It addresses issues of multiplexing multiple streams of communication (including addressing, flow control, connection establishment/disestablishment, and other signaling) over a single hardware interface. It was the official protocol of theARPA Network from January 1972 until the switch to TCP/IP in January1983. It is offered as an RFC at this late date to help complete the historical record available through the RFC series.
 
RFC 6587 Transmission of Syslog Messages over TCP
 
Authors:R. Gerhards, C. Lonvick.
Date:April 2012
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 6587
There have been many implementations and deployments of legacy syslog over TCP for many years. That protocol has evolved without being standardized and has proven to be quite interoperable in practice.This memo describes how TCP has been used as a transport for syslog messages.
 
RFC 6732 6to4 Provider Managed Tunnels
 
Authors:V. Kuarsingh, Ed., Y. Lee, O. Vautrin.
Date:September 2012
Formats:txt pdf
Obsoleted by:RFC 7526
Status:HISTORIC
DOI:10.17487/RFC 6732
6to4 Provider Managed Tunnels (6to4-PMT) provide a framework that can help manage 6to4 tunnels operating in an anycast configuration. The6to4-PMT framework is intended to serve as an option for operators to help improve the experience of 6to4 operation when conditions of the network may provide sub-optimal performance or break normal 6to4 operation. 6to4-PMT supplies a stable provider prefix and forwarding environment by utilizing existing 6to4 relays with an added function of IPv6 Prefix Translation. This operation may be particularly important in NAT444 infrastructures where a customer endpoint may be assigned a non-RFC1918 address, thus breaking the return path for anycast-based 6to4 operation. 6to4-PMT has been successfully used in a production network, implemented as open source code, and implemented by a major routing vendor.
 
RFC 6804 DISCOVER: Supporting Multicast DNS Queries
 
Authors:B. Manning.
Date:November 2012
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 6804
This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. This opcode was tested in experiments run during 1995 and 1996 for the Topology Based Domain Search (TBDS) project. This project is no longer active and there are no current plans to restart it. TBDS was the first known use of multicast transport for DNS. A client multicasts a DNS query using theDISCOVER opcode and processes the multiple responses that may result.
 
RFC 7436 IP-Only LAN Service (IPLS)
 
Authors:H. Shah, E. Rosen, F. Le Faucheur, G. Heron.
Date:January 2015
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 7436
A Virtual Private LAN Service (VPLS) is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems that are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LANService" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destinationMedia Access Control (MAC) addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via theMAC address learning procedures specified in the IEEE's "Media AccessControl (MAC) Bridges". This document specifies the protocol extensions and procedures for support of the IPLS service.

The original intent was to provide an alternate solution to VPLS for those Provider Edge (PE) routers that were not capable of learningMAC addresses through data plane. This became a non-issue with newer hardware. The concepts put forth by this document are still valuable and are adopted in one form or other by newer work such as EthernetVPN in L2VPN working group and possible data center applications. At this point, no further action is planned to update this document and it is published simply as a historic record of the ideas.