| |
| RFC 407 | Remote Job Entry Protocol |
| |
| Authors: | R.D. Bressler, R. Guida, A.M. McKenzie. |
| Date: | October 1972 |
| Formats: | txt json html |
| 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 html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0569 |
|
|
|
| |
| RFC 652 | Telnet output carriage-return disposition option |
| |
| Authors: | D. Crocker. |
| Date: | October 1974 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0652 |
|
|
|
| |
| RFC 653 | Telnet output horizontal tabstops option |
| |
| Authors: | D. Crocker. |
| Date: | October 1974 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0653 |
|
|
|
| |
| RFC 654 | Telnet output horizontal tab disposition option |
| |
| Authors: | D. Crocker. |
| Date: | October 1974 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0654 |
|
|
|
| |
| RFC 655 | Telnet output formfeed disposition option |
| |
| Authors: | D. Crocker. |
| Date: | October 1974 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0655 |
|
|
|
| |
| RFC 656 | Telnet output vertical tabstops option |
| |
| Authors: | D. Crocker. |
| Date: | October 1974 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0656 |
|
|
|
| |
| RFC 657 | Telnet output vertical tab disposition option |
| |
| Authors: | D. Crocker. |
| Date: | October 1974 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0657 |
|
|
|
| |
| RFC 658 | Telnet output linefeed disposition |
| |
| Authors: | D. Crocker. |
| Date: | October 1974 |
| Formats: | txt json html |
| 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 json html |
| 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 |
| |
|
| |
| RFC 721 | Out-of-Band Control Signals in a Host-to-Host Protocol |
| |
|
| |
| RFC 734 | SUPDUP Protocol |
| |
| Authors: | M.R. Crispin. |
| Date: | October 1977 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0734 |
|
|
|
| |
| RFC 739 | Assigned numbers |
| |
|
| |
| RFC 740 | NETRJS Protocol |
| |
|
| |
| RFC 750 | Assigned numbers |
| |
|
| |
| RFC 755 | Assigned numbers |
| |
|
| |
| RFC 758 | Assigned numbers |
| |
|
| |
| RFC 759 | Internet Message Protocol |
| |
| Authors: | J. Postel. |
| Date: | August 1980 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0759 |
|
|
|
| |
| RFC 761 | DoD standard Transmission Control Protocol |
| |
|
| |
| RFC 762 | Assigned numbers |
| |
|
| |
| RFC 770 | Assigned numbers |
| |
|
| |
| RFC 776 | Assigned numbers |
| |
|
| |
| RFC 778 | DCNET Internet Clock Service |
| |
| Authors: | D.L. Mills. |
| Date: | April 1981 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0778 |
|
|
|
| |
| RFC 790 | Assigned numbers |
| |
|
| |
| RFC 795 | Service mappings |
| |
| Authors: | J. Postel. |
| Date: | September 1981 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0795 |
|
|
|
| |
| RFC 796 | Address mappings |
| |
| Authors: | J. Postel. |
| Date: | September 1981 |
| Formats: | txt json html |
| Obsoletes: | IEN115 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0796 |
|
|
|
| |
| RFC 813 | Window and Acknowledgement Strategy in TCP |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 html json |
| 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 |
| |
|
|
This RFC has been revised, see RFC 880. |
|
| |
| RFC 869 | Host Monitoring Protocol |
| |
| Authors: | R. Hinden. |
| Date: | December 1983 |
| Formats: | txt html json |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0913 |
|
This memo describes a proposed Simple File Transfer Protocol (SFTP). It fills the need of people wanting a protocol that is more useful than TFTP but easier to implement (and less powerful) than FTP. SFTP supports user access control, file transfers, directory listing, directory changing, file renaming and deleting. Discussion of this proposal is encouraged, and suggestions for improvements may be sent to the author. |
|
| |
| RFC 914 | Thinwire protocol for connecting personal computers to the Internet |
| |
| Authors: | D.J. Farber, G. Delp, T.M. Conte. |
| Date: | September 1984 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0914 |
|
This RFC focuses discussion on the particular problems in the ARPA-Internet of low speed network interconnection with personal computers, and possible methods of solution. None of the proposed solutions in this document are intended as standards for the ARPA-Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to the problems, leading eventually to the adoption of standards. |
|
| |
| RFC 916 | Reliable Asynchronous Transfer Protocol (RATP) |
| |
| Authors: | G.G. Finn. |
| Date: | October 1984 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0916 |
|
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This paper proposes and specifies a protocol which allows two programs to reliably communicate over a communication link. It ensures that the data entering one end of the link if received arrives at the other end intact and unaltered. The protocol, named RATP, is designed to operate over a full duplex point-to-point connection. It contains some features which tailor it to the RS-232 links now in common use. |
|
| |
| RFC 923 | Assigned numbers |
| |
|
|
This RFC documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers obsoletes RFC-900 and earlier editions. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990, and 997. |
|
| |
| RFC 929 | Proposed Host-Front End Protocol |
| |
| Authors: | J. Lilienkamp, R. Mandell, M.A. Padlipsky. |
| Date: | December 1984 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0929 |
|
The Host-Front End Protocol introduced in RFC-928 is described in detail in this memo. The first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 937 | Post Office Protocol: Version 2 |
| |
| Authors: | M. Butler, J. Postel, D. Chase, J. Goldberger, J.K. Reynolds. |
| Date: | February 1985 |
| Formats: | txt json html |
| Obsoletes: | RFC 0918 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0937 |
|
This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. This memo is a revision of RFC-918. |
|
| |
| RFC 943 | Assigned numbers |
| |
|
|
This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This RFC will be updated periodically, and in any case current information can be obtained from Joyce Reynolds. The assignment of numbers is also handled by Joyce. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, network number, etc., please contact Joyce to receive a number assignment. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997. |
|
| |
| RFC 953 | Hostname Server |
| |
| Authors: | K. Harrenstien, M.K. Stahl, E.J. Feinler. |
| Date: | October 1985 |
| Formats: | txt html json |
| Obsoletes: | RFC 0811 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0953 |
|
This RFC is the official specification of the Hostname Server Protocol. This edition of the specification includes minor revisions to RFC-811 which brings it up to date. |
|
| |
| RFC 960 | Assigned numbers |
| |
|
|
This memo documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers updates and obsoletes RFC-943. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997. |
|
| |
| RFC 974 | Mail routing and the domain system |
| |
|
|
This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system. This involves a discussion of how mailers interpret MX RRs, which are used for message routing. |
|
| |
| RFC 990 | Assigned numbers |
| |
|
|
This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-997. Obsoletes RFC-960, 943, 923 and 900. |
|
| |
| RFC 996 | Statistics server |
| |
| Authors: | D.L. Mills. |
| Date: | February 1987 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 0996 |
|
This RFC specifies a standard for the ARPA Internet community. Hosts and gateways on the DARPA Internet that choose to implement a remote statistics monitoring facility may use this protocol to send statistics data upon request to a monitoring center or debugging host. |
|
| |
| RFC 1009 | Requirements for Internet gateways |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 html json |
| 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 json html |
| 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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 html json |
| 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 json html |
| 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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 html json |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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) |
| |
|
|
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 html json |
| 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 html json |
| 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 html json |
| 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 |
| |
|
|
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 html json |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 json html |
| 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 json html |
| 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 |
| |
|
| |
| RFC 1370 | Applicability Statement for OSPF |
| |
| Authors: | Internet Architecture Board, L. Chapin. |
| Date: | October 1992 |
| Formats: | txt html json |
| 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 html json |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 html json |
| 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 |
| |
|
|
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 html json |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 json html |
| 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 json html |
| 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 html json |
| 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 html json |
| 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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 json html |
| 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 |
| |
|
|
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 json html |
| 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 json html |
| 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 |
| |
|
|
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 html json |
| 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)) |
| |
|
|
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)) |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 html json |
| 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 |
| |
|
|
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 html json |
| 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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 json html |
| 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 json html |
| 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 json html |
| 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 1528 | Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures |
| |
|
|
This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1540 | Internet Official Protocol Standards |
| |
|
|
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 json html |
| 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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 html json |
| 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 html json |
| 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 html json |
| 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 html json |
| 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 |
| |
|
|
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 1706 | DNS NSAP Resource Records |
| |
|
|
OSI lower layer protocols, comprising the connectionless network protocol (CLNP) and supporting routing protocols, are deployed in some parts of the global Internet. Maintenance and debugging of CLNP connectivity is greatly aided by support in the Domain Name System(DNS) for mapping between names and NSAP addresses.
This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with anyNSAP address format.
NSAP-to-name translation is accomplished through use of the PTR RR(see STD 13, RFC 1035 for a description of the PTR RR). This paper describes how PTR RRs are used to support this translation.
This document obsoletes RFC 1348 and RFC 1637. |
|
| |
| RFC 1707 | CATNIP: Common Architecture for the Internet |
| |
| Authors: | M. McGovern, R. Ullmann. |
| Date: | October 1994 |
| Formats: | txt html json |
| 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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 json html |
| 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 html json |
| 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) |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 json html |
| 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 json html |
| 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 json html |
| 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 json html |
| 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 html json |
| 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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 html json |
| 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 html json |
| 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 html json |
| 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 html json |
| 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 json html |
| 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 html json |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 html json |
| 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 html json |
| 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 |
| |
|
|
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 2169 | A Trivial Convention for using HTTP in URN Resolution |
| |
|
|
This document specifies the "THTTP" resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. |
|
| |
| RFC 2189 | Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification -- |
| |
| Authors: | A. Ballardie. |
| Date: | September 1997 |
| Formats: | txt json html |
| 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 json html |
| 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 |
| |
|
|
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 json html |
| 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 2246 | The TLS Protocol Version 1.0 |
| |
|
|
This document specifies Version 1.0 of the Transport Layer Security(TLS) protocol. The TLS protocol 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 2296 | HTTP Remote Variant Selection Algorithm -- RVSA/1.0 |
| |
| Authors: | K. Holtman, A. Mutz. |
| Date: | March 1998 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2296 |
|
HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed. A remote variant selection algorithm can be used to speed up the transparent negotiation process. This document defines the remote variant selection algorithm with the version number 1.0. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. |
|
| |
| RFC 2300 | Internet Official Protocol Standards |
| |
|
|
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 2310 | The Safe Response Header Field |
| |
| Authors: | K. Holtman. |
| Date: | April 1998 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2310 |
|
This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe. Such an indication will allow user agents to handle retries of some safe requests, in particular safe POST requests, in a more user-friendly way. |
|
| |
| RFC 2311 | S/MIME Version 2 Message Specification |
| |
| Authors: | S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka. |
| Date: | March 1998 |
| Formats: | txt html json |
| 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 json html |
| 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 json html |
| 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 |
| |
|
|
This document defines an IPv6 aggregatable global unicast address format for use in the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 2400 | Internet Official Protocol Standards |
| |
|
|
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 2407 | The Internet IP Security Domain of Interpretation for ISAKMP |
| |
|
|
This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. [STANDARDS-TRACK] |
|
| |
| RFC 2408 | Internet Security Association and Key Management Protocol (ISAKMP) |
| |
| Authors: | D. Maughan, M. Schertler, M. Schneider, J. Turner. |
| Date: | November 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4306 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2408 |
|
This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and KeyManagement Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management ofSecurity Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications(via IP Security Service or any other security protocol) in anInternet environment. |
|
| |
| RFC 2409 | The Internet Key Exchange (IKE) |
| |
|
|
This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK] |
|
| |
| RFC 2452 | IP Version 6 Management Information Base for the Transmission Control Protocol |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
This memo summarizes the status of Internet protocols and specifications. [STANDARDS-TRACK] |
|
| |
| RFC 2559 | Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 |
| |
|
|
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 |
| |
|
|
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 2660 | The Secure HyperText Transfer Protocol |
| |
| Authors: | E. Rescorla, A. Schiffman. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2660 |
|
This memo describes a syntax for securing messages sent using theHypertext Transfer Protocol (HTTP), which forms the basis for theWorld Wide Web. Secure HTTP (S-HTTP) provides independently applicable security services for transaction confidentiality, authenticity/integrity and non-repudiability of origin.
The protocol emphasizes maximum flexibility in choice of key management mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction. |
|
| |
| RFC 2673 | Binary Labels in the Domain Name System |
| |
|
|
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 |
| |
|
|
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 json html |
| 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) |
| |
|
|
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 2774 | An HTTP Extension Framework |
| |
| Authors: | H. Nielsen, P. Leach, S. Lawrence. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2774 |
|
A wide range of applications have proposed various extensions of theHTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication. |
|
| |
| RFC 2776 | Multicast-Scope Zone Announcement Protocol (MZAP) |
| |
| Authors: | M. Handley, D. Thaler, R. Kermode. |
| Date: | February 2000 |
| Formats: | txt html json |
| 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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 json html |
| 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 |
| |
|
|
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 html json |
| 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 json html |
| 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 html json |
| 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 json html |
| 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 json html |
| 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 html json |
| 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 html json |
| 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 html json |
| 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 json html |
| 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 json html |
| 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 3716 | IETF in the Large: Administration and Execution |
| |
| Authors: | IAB Advisory Committee. |
| Date: | March 2004 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 3716 |
|
In the fall of 2003, the IETF Chair and the IAB Chair formed an IABAdvisory Committee (AdvComm), with a mandate to review the existingIETF administrative structure and relationships (RFC Editor, IETFSecretariat, IANA) and to propose changes to the IETF management process or structure to improve the overall functioning of the IETF.The AdvComm mandate did not include the standards process itself.
This memo documents the AdvComm's findings and proposals. |
|
| |
| RFC 3913 | Border Gateway Multicast Protocol (BGMP): Protocol Specification |
| |
| Authors: | D. Thaler. |
| Date: | September 2004 |
| Formats: | txt html json |
| 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 json html |
| 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 json html |
| 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 4346 | The Transport Layer Security (TLS) Protocol Version 1.1 |
| |
|
|
This document specifies Version 1.1 of the Transport Layer Security(TLS) protocol. The TLS protocol provides communications security 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 4347 | Datagram Transport Layer Security |
| |
|
|
This document specifies Version 1.0 of the Datagram Transport LayerSecurity (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. |
|
| |
| 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 html json |
| 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 |
| |
|
|
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 4405 | SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message |
| |
| Authors: | E. Allman, H. Katz. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 4405 |
|
This memo defines an extension to the Simple Mail Transfer Protocol(SMTP) service that allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e-mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain. |
|
| |
| RFC 4406 | Sender ID: Authenticating E-Mail |
| |
| Authors: | J. Lyon, M. Wong. |
| Date: | April 2006 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 4406 |
|
Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means that the address is used without the permission of the domain owner. This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address. |
|
| |
| RFC 4407 | Purported Responsible Address in E-Mail Messages |
| |
|
|
This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the Purported Responsible Address (PRA). |
|
| |
| RFC 4431 | The DNSSEC Lookaside Validation (DLV) DNS Resource Record |
| |
| Authors: | M. Andrews, S. Weiler. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 4431 |
|
This document defines a new DNS resource record, called the DNSSECLookaside Validation (DLV) RR, for publishing DNSSEC trust anchors outside of the DNS delegation chain. |
|
| |
| RFC 4612 | Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration |
| |
| Authors: | P. Jones, H. Tamura. |
| Date: | August 2006 |
| Formats: | txt json html |
| 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 |
| |
|
|
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) |
| |
|
|
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) |
| |
|
|
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 json html |
| 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 |
| |
|
|
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) |
| |
|
|
"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 html json |
| 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 json html |
| 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 |
| |
|
|
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) |
| |
|
|
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 5074 | DNSSEC Lookaside Validation (DLV) |
| |
| Authors: | S. Weiler. |
| Date: | November 2007 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5074 |
|
DNSSEC Lookaside Validation (DLV) is a mechanism for publishing DNSSecurity (DNSSEC) trust anchors outside of the DNS delegation chain.It allows validating resolvers to validate DNSSEC-signed data from zones whose ancestors either aren't signed or don't publishDelegation Signer (DS) records for their children. |
|
| |
| 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 json html |
| 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 json html |
| 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 json html |
| 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 html json |
| 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 html json |
| 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 5469 | DES and IDEA Cipher Suites for Transport Layer Security (TLS) |
| |
|
|
Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC4346) include cipher suites based on DES (Data Encryption Standard) and IDEA (International Data Encryption Algorithm) algorithms. DES(when used in single-DES mode) and IDEA are no longer recommended for general use in TLS, and have been removed from TLS version 1.2 (RFC5246). This document specifies these cipher suites for completeness and discusses reasons why their use is no longer recommended. |
|
| |
| 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 json html |
| Updated by: | RFC 8553 |
| 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 html json |
| 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 json html |
| 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 json html |
| 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 html json |
| 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 5933 | Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC |
| |
| Authors: | V. Dolmatov, Ed., A. Chuprina, I. Ustinov. |
| Date: | July 2010 |
| Formats: | txt json html |
| Updated by: | RFC 6944 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5933 |
|
This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the DomainName System Security Extensions (DNSSEC). |
|
| |
| RFC 5987 | Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters |
| |
|
|
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) |
| |
|
|
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 html json |
| 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 6057 | Comcast's Protocol-Agnostic Congestion Management System |
| |
| Authors: | C. Bastian, T. Klieber, J. Livingood, J. Mills, R. Woundy. |
| Date: | December 2010 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 6057 |
|
This document describes the congestion management system of ComcastCable, a large cable broadband Internet Service Provider (ISP) in theU.S. Comcast completed deployment of this congestion management system on December 31, 2008. |
|
| |
| RFC 6101 | The Secure Sockets Layer (SSL) Protocol Version 3.0 |
| |
| Authors: | A. Freier, P. Karlton, P. Kocher. |
| Date: | August 2011 |
| Formats: | txt html json |
| 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 6108 | Comcast's Web Notification System Design |
| |
| Authors: | C. Chung, A. Kasyanov, J. Livingood, N. Mody, B. Van Lieu. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 6108 |
|
The objective of this document is to describe a method of providing critical end-user notifications to web browsers, which has been deployed by Comcast, an Internet Service Provider (ISP). Such a notification system is being used to provide near-immediate notifications to customers, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection.There are other proprietary systems that can perform such notifications, but those systems utilize Deep Packet Inspection (DPI) technology. In contrast to DPI, this document describes a system that does not rely upon DPI, and is instead based in open IETF standards and open source applications. |
|
| |
| RFC 6112 | Anonymity Support for Kerberos |
| |
|
|
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 json html |
| 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) |
| |
|
|
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) |
| |
|
|
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 json html |
| 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 |
| |
|
|
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 json html |
| 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 html json |
| 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) |
| |
|
|
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 html json |
| 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 html json |
| 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 json html |
| 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 html json |
| 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 html json |
| 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. |
|
| |
| RFC 7954 | Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block |
| |
| Authors: | L. Iannone, D. Lewis, D. Meyer, V. Fuller. |
| Date: | September 2016 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 7954 |
|
This document directs IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as Endpoint Identifier (EID) addressing space. |
|
| |
| RFC 7955 | Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block |
| |
| Authors: | L. Iannone, R. Jorgensen, D. Conrad, G. Huston. |
| Date: | September 2016 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 7955 |
|
This document proposes a framework for the management of the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) address block. The framework described relies on hierarchical distribution of the address space, granting temporary usage of prefixes of such space to requesting organizations. |
|
| |
| RFC 8164 | Opportunistic Security for HTTP/2 |
| |
| Authors: | M. Nottingham, M. Thomson. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 8164 |
|
This document describes how "http" URIs can be accessed usingTransport Layer Security (TLS) and HTTP/2 to mitigate pervasive monitoring attacks. This mechanism not a replacement for "https"URIs; it is vulnerable to active attacks. |
|
| |
| RFC 8507 | Simple Internet Protocol (SIP) Specification |
| |
| Authors: | S. Deering, R. Hinden, Ed.. |
| Date: | December 2018 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 8507 |
|
This document is published for the historical record. The SimpleInternet Protocol was the basis for one of the candidates for theIETF's Next Generation (IPng) work that became IPv6.
The publication date of the original Internet-Draft was November 10,1992. It is presented here substantially unchanged and is neither a complete document nor intended to be implementable.
The paragraph that follows is the Abstract from the original draft.
This document specifies a new version of IP called SIP, the SimpleInternet Protocol. It also describes the changes needed to ICMP,IGMP, and transport protocols such as TCP and UDP, in order to work with SIP. A companion document [SIP-ADDR] describes the addressing and routing aspects of SIP, including issues of auto-configuration, host and subnet mobility, and multicast. |
|
| |
| RFC 9327 | Control Messages Protocol for Use with Network Time Protocol Version 4 |
| |
|
|
This document describes the structure of the control messages that were historically used with the Network Time Protocol (NTP) before the advent of more modern control and management approaches. These control messages have been used to monitor and control the NTP application running on any IP network attached computer. The information in this document was originally described in Appendix B of RFC 1305. The goal of this document is to provide an updated description of the control messages described in RFC 1305 in order to conform with the updated NTP specification documented in RFC 5905.
The publication of this document is not meant to encourage the development and deployment of these control messages. This document is only providing a current reference for these control messages given the current status of RFC 1305. |
|
